simple ELF bootloader for embedded xilinx linux ?

[rimas]

On Mon, 11 Sep 2006 14:20:49 -0700
  Michael Galassi <mgalassi at c-cor.com> wrote:
>>whats the best/easiest way for me to boot from an ELF file in the  
>>flash ? i'm aware of u-boot but it seems like overkill for this  
>>application.  however if it would work and the footprint is  
>>relatively small i could give it a try.  i imagine i could write my  
>>own bootloader, i just thought i'd ask first to avoid reinventing the  
>>wheel.
> 
> If you're using the zImage file the only bootloader you need is an
> unconditional, unlinked branch to the first instruction you want to
> execute in the zImage located at -4 (0xfffffffc).  To save a few extra
> bytes you can strip the ELF header from the zImage, then you flash it
> at the same address you jump to.  I do that with objcopy:
>    make zImage && \
>    ppc_405-objcopy -O binary arch/ppc/boot/images/zImage.elf zImage.bin
> 
> Remember that the first instruction of the kernel must reside within
> your relative jump limit if you take this approach.  If you place your 3
> meg kernel right below the branch instruction you'll have no problems
> with this at all.  If you prefer mapping your flash lower down and use a
> blockram (or whatever) for your boot-code you can branch a dozen bytes
> backward in the instruction at -4 and have an absolute branch there
> which could reach anyplace in your address space.

Thanks for clarifying that for me !  Using objcopy to create a binary file, 
flashing the binary file and then jumping to the start of the flash works 
perfectly.

> 
>>another somewhat related question is whether i can use a portion of  
>>the flash (the part thats left over after the kernel/root fs image is  
>>programmed) as nonvolatile storage using the JFFS2 filesystem ?   
>>anyone have any pointers to information on how to set this up ?
> 
> Most flash must be erased in 128K blocks, once two are paired to yield
> a 32bit wide data bus you'll find yourself segmenting your space into
> 256K blocks.  I use an integral number of these blocks for a cramfs
> image, I see no reason you shouldn't do the same for a jffs2.  Just be
> careful not to accidentally write past the space you allocate to your
> filesystem and onto your boot-code, kernel, and what ever else you place
> in flash.  Since bricking(*) a system is viewed as a bad thing we don't
> allow writes to the filesystem in flash, we instead write entire images
> at once in carefully controlled conditions.
> 

Thanks for pointing out the potential risks in using the same flash as a 
read/write filesystem and storage for the kernel/root filesystem/etc. I hadn't 
considered that.  I only need minimal low speed non volatile storage so maybe 
I'll use an eeprom or something instead for the sake of reliability.

-rimas

> An over-simplified flash map ends up looking something like:
>    "size-4bytes"     branch instruction to "top-4meg"
>    "size-4meg"	      kernel stripped of elf header
>    "size-20meg"      filesystem image
>    "0"		      bitstream loaded into FPGA at power-up
> 
> Adjust the sizes to fit your kernel size, filesystem size, bistream
> size, and to accommodate the flash size you're using and other data
> you might with to store in flash.
> 
> (*) brick (verb) to render functionally brick-like
> 
> -michael