read the uboot source code, then try to forget it :)
--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
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.
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
Google is your friend. Try searching for "Booting ARM Linux" or
"bootloader ARM Linux".
Here is a good starting place:
http://www.arm.linux.org.uk/developer/booting.php
As Vladimir says, u-Boot source code is also a good place to start,
but you need some background information to interpret what is going on
in u-Boot and other loaders. The "tip of the spear", so to speak is
in u-Boot code at "../arch/arm/lib/bootm.c". This is where the
"ATAGs" are set up to pass parameters to the kernel and the kernel is
called.
Regards:
Mike Nelson, http://michaeltnelson.com
mobile: 1-650-291-7343
office: 1-650-257-7565
On Wed, Dec 15, 2010 at 2:44 PM, Vamsi Krishna Baratam
<vam...@gmail.com> wrote:
> 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).
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/
On Dec 15, 2010, at 7:19 PM, aos...@gmail.com wrote:
> I tried this a few years ago. The documentation is shotty at best. Bear in mind that you're more or less running on metal. Try looking into toy operating systems, they'll touch on bootloaders at least a little.
Take a look at PuppyBits and x-loader for some minimalist examples.