>>1. Should we add a "gunzip" command to U-Boot?
>>2. Should we add a command (similar to bootm) that takes an image, decompresses
>>it and checks CRC etc.?
>>3. Or should we put this into the "fpga load" command?
>>I would go for the first. Maybe the second. Third seems to be too limited.
> Yes, why implement things that are already there? See our
> documentation for exactly this problem. I know, it takes some
> courage to use "bootm" to uncompress, but hey, it works...
Aah. Yes. I tought about that. I actually just try the following:
1. Create a new image typ "FPGA Data"
2. Hack cmd_bootm.c to handle this and to directly call fpga_load()
DAB4K2> bootm 40040000
## Booting image at 40040000 ...
Image Name: DAB4K_TEST-
Created: 2003-09-22 8:20:19 UTC
Image Type: FPGA Data Image (gzip compressed)
Data Size: 56098 Bytes = 54.8 kB
Load Address: 00200000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing FPGA Image ... OK
Calling fpga_load( 0, 0x200000, 166965)...
ACEX1K_load: Launching Passive Serial Loader
ACEX1K_ps_load: start with interface functions @ 0x00ffa034
Loading FPGA Device 0...
The "Load Address" could be used as a free RAM Address for decompressing.
The "Start Address" could be the number of the FPGA device (first argument for
fpga_load) so we could handle more than one FPGA in one Multi-Image file.
What do you think?
Is it worth it to go that way. Or is the you suggested way preferred as you
could do the rest using simple scripts...?
How could I get the uncompressed size??? Does bootm update $filesize?
fpga_load needs a size. So if I use bootm only for uncompressing how could I
pass the lenght to fpga_load()???