simple ELF bootloader for embedded xilinx linux ?

[Michael Galassi]

>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.

>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.

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