On 9/27/07, Ben Warren bwarren@qstreams.com wrote:
E Robertson wrote:
On 9/27/07, Stefan Roese sr@denx.de wrote:
Hi Matthias,
On Thursday 27 September 2007, Matthias Fuchs wrote:
What kind of CPU are you using? Please note that 4xx U-Boot ports have the cache disabled. Without cache booting a Spartan 3E in SS-mode may take very very :-(
Only 44x have cache disabled. 40x has icache enabled.
BTW: I'm still waiting for the patch to enable the cache on 44x systems... ;)
Viele Grüße, Stefan
I'm using an NXP ARM9 'A404 and can disable cache on my platform. Due to my hardware fool-up, I'll have to use a bit banging method. I'm also concern about loading error and recovery and I'm considering instead to do the programming in the kernel. If there is a problem for some reason and the FPGA needs to be reloaded, I'll have to do it in the kernel anyway. I'm not sure about embedding a bin file in the kernel driver either but It's worth pursuing.
If your design can wait until Linux is booted before programming the FPGA, you have a world of possibilities available. In my designs, I have a simple char driver with a 'write' method that bit-bangs the image in. This way you can keep your image as a file in the file system and can add whatever encryption, wrapper or whatever your heart desires. It makes trying different FPGA images a breeze.
I'm actually in the middle of doing that with a simple char device driver. I have'n't got to the bit banging write part yet but I'll appreciate a code snip that actually parses the file for the bits. I'm assuming it'll be some sort of shift right for a char read increment or some sort of XOR operation. I haven't thought through that part yet but is that how is normally done?