[U-Boot-Users] booting elf images from flash

[Wolfgang Denk]

In message <6.1.1.1.0.20050320092926.01e43d08 at ptg1.spd.analog.com> you wrote:
> I know that U-boot currently supports booting compressed binary images from 

Compressed or uncompressed images.

> flash via the instructions in the README

I understand that you are talking about Linux images only, right?

> In our system architecture (Blackfin) SDRAM (133MHz) is at 0x0 to0x07FFFFFF 
> (128Meg), and on chip Instruction SRAM (runs at core speed - up to 600MHz) 
> exists at 0xFFA00000 to 0xFFA13FFFF (64k). Some of our kernel drivers need 
> to put code snippets in SDRAM at 0xFFA00000.

What you say shall be done: Your kernel  drivers  need  to  put  code
snippets in SDRAM. This is IMHO not really a task of the boot loader.

> Today - we did this by modifying the lds, and letting the linker manage 
> everything. However, this breaks ${CROSS_COMPILE}-objcopy as it tries to 
> dump ~4.0Gig into the bin file...

objcopy should be capable of doing this - even if you probably  don't
like the result ;-)

>   - revert back to have drivers copy their information into SRAM (which 

This is the most natural thing to do: the drivers need this code,  so
it is the responsibility of the drivers to load it.

> makes kernel maintenance a problem - as all kernel modules writers need to 
> know where everyone else is doing things, so they won't copy over each other)

Ummm... and you think it  would  be  better  if  the  kernel  modules
writers  do NOT know where everyone else is doing things? I seriously
doubt that.

>   - give more options to objcopy, and make 2 bins (one for SDRAM (kernel), 
> one for SRAM (drivers)), load these separately, and execute from kernel. I 
> am assuming that this wouldn't be much different than loading a ramdisk 
> separately from kernel images.

It should be pretty straightforward to  put  all  this  code  into  a
separate segment and create a separate image which contains only this
segment.

>   - write a patch to accept compressed elf files in U-boot, rather than 
> just compressed bins.

U-Boot already understands how to deal with  ELF  images.  It's  just
that  we  don't  use  ELF images for the Linux kernel, as there is no
need to do so, and no advantages (but several disadvantages).

Don't try to fix a problem in U-Boot that needs to be solved  in  the
Linux kernel. Just assume that some other boot loader will be used to
boot your Linux kernel images.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He who hesitates is not only lost, but miles from the next exit.