[beagleboard] Writing a Bootloader???

GoogleGroups
1

I'm not sure there's a lot of good documentation on writing bootloaders
as it is somewhat of a specialist subject, and many people do it differently
depending on what they are after and how their system/soc works.

It sort of breaks down as so:

1) The system gets the initial code from somewhere, and this depends on
   not only the SoC but also the configuration that the board may have
   done. Some people even have weird setups which have a secondary CPU
   to bootstrap the code into the primary.... these people can however
   be safely ignored as nutters.

2) The code loaded in step 1 (by the SoC) usually has nothing it can rely
   on and needs to ensure the minimum hardware seyup for the CPU core and
   any periphreals it needs to load the next stage of the bootloader.

   It will also ensure that the external memory is setup so that the
   next step has somewhere to put the code to run.

   Oftenn this code is only a killobyte or two in size, just to get
   enough state to start loading the next part of the bootloader.

3) The next part is to load the rest of the bootloader, usually from the
   same source as part 2. Once the code has loaded, the first loader will
   start executing this new coe.

4) Now that part 3 has downloaded some more code into the main RAM, it
   can now go about doing the rest of the initial setup ready to do
   something useful for the user. At this stage there are multiple
   choices of what to do.

   A) Do minimal hardware setup, and directly execute a linux kernel
   B) Load another bootloader from a different source and execute that
   C) Run the main bootloader and continue.

2

Mark, Mike & Ben,

Thanks all for your prompt responses.
I would like to know why exactly do you about choosing two bootloaders for the board(like we have two in the case of Beagleboard) and when dont you need it? And for now I want to concentrate on Uboot. Whats the approach for writing a bootloader(uboot) for a board that is not being supported currently by uboot, for instance a raw board? Look forward to hearing from you people.

Thanks

3

http://omappedia.org/wiki/Bootloader_Project

4

Hi Vamsi,

Mark, Mike & Ben,

Thanks all for your prompt responses.
I would like to know why exactly do you about choosing two bootloaders for
the board(like we have two in the case of Beagleboard) and when dont you
need it? And for now I want to concentrate on Uboot. Whats the approach for
writing a bootloader(uboot) for a board that is not being supported
currently by uboot, for instance a raw board? Look forward to hearing from
you people.

When the chip starts up, the SDRAM is typically not initialized. This
means that you need to load a small bootloader which will fit into
some internal RAM (sometimes you can lock down the cache for this) and
this small bootloader will then initialize SDRAM and load the next
stage of bootloader.

If your internal RAM is big enough, you might only need one stage of bootloader.

I've worked on chips where you only get 8K or 16K of internal SRAM,
which is nowhere big enough to load something like uboot.

It also depends on whether you have NOR flash (which you can execute
from) or NAND flash (which you can't execute from).

5

Dave Hylands said
<<ve worked on chips where you only get 8K or 16K of internal SRAM,
<<whichs nowhere big enough to load something like uboot.

I worked on 25K COTS boards that had 64K Internal RAM and cost is not an issue

In that case the bootRom contained multipe u-boot images and the the bootloader(u-boot) could be reflashed and protection against bricking the board

Uboot used the internal RAM for stack and initialized DDR all peripherals and loaded the image into DDR. This level of functionality would be a tight fit in internal RAM of OMAP

My point these high end boards needed no xloader but this same at a cost

u-boot initialized DDR handled USB,ethernet tftp etc etc

To people coming from high cost systems x-loader looks like its redundant(why 2 loaders)

Actually x-loaders need is more subtle

In OMAPx the probale reason for going with an x-loader was for

  1. maximum flexibility ,
    2)ow cost(no boot flash required) and yes
  2. less than 64k of Internal RAM which also serves as stack and data area

u-boot for cost sensitive handheld device is different than that used
in a 25K COTS VME baord used to process radar to shoot down missles