Hi Dave (and all),
Well its you lucky day,
By the time I you will need it I will already be done with it and you will have it.
I am using the a custom board with a MPC8548 as its main processor.. so you should be able to convert it to your use with real ease.
the strategy, software wise, is: 1. not touch fpga.c /fpga.h 2. Add the needed enums to altera.h / switch cases to altera.c 3. Add an StratixII.c / StratixII.h general purpose driver 4. Add a vendor specific /board/{VENDOR}}/yourname_fpga.c that contain the board specific function (like enabling gpio and stuff, raise the whatshellwecallit bit, ect. )
hardware wise: we do not have TSEC2 on our board... so by setting the right bits we can its legs as gpio...
once its ready I will post a patch (against 1.1.6 stable) and will ready to help if there are any problems.
On 5/18/07, David Hawkins dwh@ovro.caltech.edu wrote:
Hi Liberty,
I am already knee deep in adding Altera Stratix II support to the u-boot via the fpga command (currently xlinix & acex1k are supported)...
of course I will re-post when i am done.
My only question is,
Am i reinventing the wheel? Is it already implemented anywhere?
If i am, where can I find a reference to the work already done?
If not I will soon give you one :)
I haven't looked for it yet, but I plan to add support too eventually (= months from now when I get boards).
I haven't looked at the code, but here's how I plan to configure my FPGAs. Your method may be different, so perhaps between us we can come up with a consistent API.
any changes between our boards will be placed in the board specific file, so no worries there.
The board I am designing will contain an MPC8349E, and Altera Stratix II system controller FPGA on the processor local bus, and then 4 other programmable FPGAs. A board placement PDF is here;
I have a 3 FPGA on the local bus system so its pretty close.
http://www.ovro.caltech.edu/~dwh/carma_board/carma_board_placement.pdf
and engineering documents are here
http://www.ovro.caltech.edu/~dwh/carma_board/
The system controller FPGA will boot from Flash, a MAX II CPLD will configure it on power-up, and then it'll bring the PPC out of reset, which will then boot through Flash located off the system controller FPGA (hence the system controller comes to life before the processor). The other four FPGAs will be programmed as the application dictates.
I am going to cut expanses on the CPLD (have it now but intend to solder it out). So the Uboot will reset the FPGA and than program it.
So given U-Boot running, I'd imagine tftp'ing RBF (raw binary format) files generated by Quartus over to the board. I'd then copy the files to a block of memory which maps in my system controller to a fast-passive-parallel (FPP) programmer. That state machine then programs the FPGAs. In Linux the same procedure would be hidden behind a driver so I could dd the RBFs into /dev/fgpa_fpp or /sys/.../firmware.
I am going to add the Fast Passive Parallel loading style, so again you have a tight fit here.
The point of mapping the FPP programmer into a block of local bus memory addresses is so that I can use the MPC8349E DMA controller to DMA the RBF files from SDRAM memory to the programmer memory (eg. from files in a RAM filesystem). According to the datasheet MPC8349E DMA controller won't burst with a fixed destination address (FIFO mode), so I'll just fake it out and let it DMA to what it thinks is an incrementing address location.
Here we are differ... I intend to do it as simple as possible. This is a rare operation, done only once on start up event. If your up time is so crucial go ahead and DMA it. I can spare the extra 3 sec on directly putting the stuff on the bus.
How are you planning on programming your FPGA?
Cheers Dave
Having said all that... I am still not too proud to stop right now and take someone elses already made job, if anyone will show me it. again, Is There already an implementation for Altera Startix II out there hidden from me?
Liberty