booting the Linux on bare metal board.

Hi guys 


I was studying about the JTAG and than I all of sudden I got few questions
in my mind regarding the linux booting on the embedded hardware.

Actually I know the procedure of how the linux boots on the hardware in
embedded  world and lots of stuff is available all over on the internet.

But what I do not found is that how it begins, I mean the procedure is
something  like this:


1  --  Primary Bootloader

2  --  Secondary Bootloader. (optional in most of the cases as I read.)

3  --  Uboot.

4  -- Linux Kernel.

5  -- Rootfs.

please correct me if I am wrong somewhere.

Now the question is that the primary bootloader loads the uboot than uboot
loads the Linux kernel and so on.

But what about the primary bootloader , I mean who loads it as it is the
first program on the bare metal which is encontered.

actually I am asking this because I am using the Linux development kits
which comes up with the preinstalled bootloader and through the serial
communication I am able to download the uboot,Linux kernel and the rootfs
image on the hardware. 

But how this primary or the first bootloader is loaded on the system , how
it is downloaded in the system.

This is what I am searching for couple of days and after not getting
satisfactory answer I turned to you guys.

Maybe the reason of not getting what I want to get on the google is that I
am not certain of the words to be used for searching the query which I am
asking you people.

So please guys tell me that how should I converge my search result as much
precise as possible , please tell me the words to be used for it, like till
now I am using the words like " Running the Linux on the baremetal" etc and
something like that.


Also if any of you guys have good documentation on this please do try to
share that with me and links also if you have any.

Actually this seems to be something like chicken and egg problem to me ,
that's why I want clear understanding about it.

some of you guys have explained in detail my previous queries and that
saved my lots of precious time and also put me on right track.

that's why I seek for help from you people as you are ahead on this track,
so you can guide me better and in best way.


Thanks and Regards	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

>-----< piyushpandey >
> But what about the primary bootloader , I mean who loads it as it is the
> first program on the bare metal which is encontered.

A processor has HW provisions to in effect start execution at a fix 
address, where the board designer has placed a ROM or flash memory.

-- 
Fredrik &Ouml;stman

>>-----< piyushpandey >
>
>A processor has HW provisions to in effect start execution at a fix 
>address, where the board designer has placed a ROM or flash memory.
>


Hi fredrick

you mean that the primary bootloader which I have mentioned over here is
basically a hardware bootloader and we don't have to load it, and also does
it mean that we have not to write the assembly code of the primary
bootloader.

Can you please explain in little bit detail.

Thanks	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

>-----< piyushpandey >
> you mean that the primary bootloader which I have mentioned over here is
> basically a hardware bootloader and we don't have to load it

No. The primary bootloader is present in non-volatile memory at a 
location known by the HW. It is either loaded into RAM and executed there 
or executed directly. Refer to the reference manual of your processor for 
details.

-- 
Fredrik &Ouml;stman

On 2013-03-21, piyushpandey <82952@embeddedrelated> wrote:

> But what about the primary bootloader , I mean who loads it as it is the
> first program on the bare metal which is encontered.

In many processors the primary bootloader is in masked ROM built-in to
the processor.  In addition to loading a secondary bootloader from
external memory, the primary bootloader will sometimes support a
number of commands that allow you to interact with the CPU via serial
port or even USB port to do things like read/write memory or registers.

In other processors, there is no primary bootloader and the CPU just
starts executing at one fixed address that it expects to be
implemented externally (typically by EPROM or FLASH).

-- 
Grant Edwards               grant.b.edwards        Yow! FOOLED you!  Absorb
                                  at               EGO SHATTERING impulse
                              gmail.com            rays, polyester poltroon!!

>>>>> Grant Edwards <invalid@invalid.invalid> writes:
>>>>> On 2013-03-21, piyushpandey <82952@embeddedrelated> wrote:

 >> But what about the primary bootloader, I mean who loads it as it is
 >> the first program on the bare metal which is encontered.

 > In many processors the primary bootloader is in masked ROM built-in
 > to the processor.

	I'm curious about specific examples.  Could you please name a
	few?

[...]

 > In other processors, there is no primary bootloader and the CPU just
 > starts executing at one fixed address that it expects to be
 > implemented externally (typically by EPROM or FLASH).

	... Or several such fixed addresses, as implemented in certain
	8-bit AVR MCU's.  (The address actually used then depends on the
	values of the MCU's programmable "fuse" bytes.)

-- 
FSF associate member #7257

On Thu, 21 Mar 2013 19:07:13 +0000
Ivan Shmakov <oneingray@gmail.com> wrote:

> >>>>> Grant Edwards <invalid@invalid.invalid> writes:
> >>>>> On 2013-03-21, piyushpandey <82952@embeddedrelated> wrote:
> 
>  >> But what about the primary bootloader, I mean who loads it as it is
>  >> the first program on the bare metal which is encontered.
> 
>  > In many processors the primary bootloader is in masked ROM built-in
>  > to the processor.
> 
> 	I'm curious about specific examples.  Could you please name a
> 	few?
> 

LPC3250.  The 16K mask ROM takes over after power-up and attempts to
locate a bootable image on the SPI port, then the external memory bus
on CS0, and finally the NAND flash port.  In each case, it tries to read
a fixed preamble from address 0 of that device.  If it gets the right
preamble it then reads length of data to copy into the on-die SRAM,
copies the data to RAM address 0, and jumps to it.  Alternatively, it
presents a serial port on UART5 at a baud rate that assumes a 13 MHz
input clock, and provides a limited serial console. 

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

On 2013-03-21, Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>>> Grant Edwards <invalid@invalid.invalid> writes:
>>>>>> On 2013-03-21, piyushpandey <82952@embeddedrelated> wrote:
>
> >> But what about the primary bootloader, I mean who loads it as it is
> >> the first program on the bare metal which is encontered.
>
> > In many processors the primary bootloader is in masked ROM built-in
> > to the processor.
>
> 	I'm curious about specific examples.  Could you please name a
> 	few?

Atmel ARM9 processors like the AT91SAM9G20 and it's relatives.

Since the OP was asking about booting Linux, and the Atmel SAM9 parts
are very popular for embedded Linux, they're probably a good example.

The way Linux boots on a SAM9 part is:

  1) The "ROMboot" primary bootloader executes from internal masked
     ROM.

  2) The primary bootloader checks for the existence of a secondary
     bootloader (referred to as a "bootstrap" in Atmel docs) in a
     variety of media in some pre-defined order which I probably
     don't have right:
     
       SPI flash
       Atmel serial "dataflash"       
       parallel NOR flash
       NAND flash
       SD-Card
       USB mass storage?  (not sure about this one).

     If secondary bootloader program header bytes are found, then the
     secondary bootloader (max size of 8 or 16 KB depending on the
     part) is loaded into internal SRAM and executed.

     If a secondary bootloader isn't found, the ROMBoot primary
     bootloader waits for commands from the debug serial UART or a
     USB-seral port that it implements.

  3) The secondary bootloader (bootstrap), typically configures and
     enables the SDRAM controller and either the NAND flash controller
     the SD-Card controller, the SPI controller, and loads U-Boot from
     NAND/EPROM/SCARD/SPI-flash into SDRAM and starts it.

  4) U-Boot loads the compressed Linux kernel (and possibly the root
     filesystem) from NAND, SD-Card, Ethernet, USB, wherever into
     SDRAM and jumps to the compress kernel.

  5) The Linux kernel un-compress wrapper uncompresses the actual
     kernel into SDRAM and jumps to it.

  6) Linux is now running!
       

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having an
                                  at               EMOTIONAL OUTBURST!!  But,
                              gmail.com            uh, WHY is there a WAFFLE
                                                   in my PAJAMA POCKET??

On Thu, 21 Mar 2013 19:07:13 +0000, Ivan Shmakov
<oneingray@gmail.com> wrote:

>>>>>> Grant Edwards <invalid@invalid.invalid> writes:
>>>>>> On 2013-03-21, piyushpandey <82952@embeddedrelated> wrote:
>
> >> But what about the primary bootloader, I mean who loads it as it is
> >> the first program on the bare metal which is encontered.
>
> > In many processors the primary bootloader is in masked ROM built-in
> > to the processor.
>
>	I'm curious about specific examples.  Could you please name a
>	few?

The ones I know about are usually used for serial
bootloading, since that is a very common desire. I can name a
specific example that doesn't do that. The Analog Devices'
ADSP-21xx DSP processor has several different kinds of
booting modes depending on the values of a pin or two just
after reset. Since it has no flash, just ram, inside it uses
this to boot from an external EPROM type device, for example,
that has been specifically formatted (field values needed by
the bootloader built into each device are read in and control
the loading process.)

There may be others I'm not aware of.

In any case, if I were doing this on a processor that didn't
have a rom'd bootloader of any kind in it but had flash then
I'd just use my programming tool to download a short one into
its flash located at the correct location that would be
executed after power-on reset completes. I would imagine it
would be a very simple bit of code, given the possibility of
merely having it load a secondary bootloader you can get from
the web (if I understood you correctly, before.)

Keep in mind that the primary bootloader (as you describe it)
is the piece of code that marries a specific and unique CPU
architecture with a generic and more abstract booting process
of a general purpose operating system. It's difficult to
write a universal version of that, which is why I think you
are having some trouble finding lots of discussion about it.
Chances are, people just "write it" and don't complain,
knowing that the rest of the booting process, once the
specific hardware details are properly configured so that the
general booting process makes sense, will go with far less of
a hitch.

For example, on the x86 I'd expect the primary bootloader
(BIOS, probably) to deal with the chipset dynamic mapping of
the DRAM, the MTRR (memory type and range registers) to set
up the memory layout and configuration, and the security and
power saving arrangements before starting the secondary
bootstrap. Stuff like this may vary from cpu to cpu (old vs
newer, for example) and it's better to shoehorn those details
into the primary bootloader so that the rest of the steps can
vary less and focus more on the larger goals ahead.

Just as an educated guess, not as someone who knows about the
details specifically.

Jon

>
>[...]
>
> > In other processors, there is no primary bootloader and the CPU just
> > starts executing at one fixed address that it expects to be
> > implemented externally (typically by EPROM or FLASH).
>
>	... Or several such fixed addresses, as implemented in certain
>	8-bit AVR MCU's.  (The address actually used then depends on the
>	values of the MCU's programmable "fuse" bytes.)

Grant Edwards <invalid@invalid.invalid> wrote:
> Since the OP was asking about booting Linux, and the Atmel SAM9 parts
> are very popular for embedded Linux, they're probably a good example.
> 
> The way Linux boots on a SAM9 part is:
[snip]

That's pretty much how a Raspberry Pi boots too:
1. Primary bootloader = mask ROM
2. Firmware for the GPU is loaded off SD card and executed
3. The GPU loads a kernel image for the ARM CPU from SD into ARM RAM and executes it
   (meanwhile the GPU is already doing its thing)
4. The kernel image can be Linux itself (or RISC OS or *BSD or...) or U-boot
5. U-boot can then boot a kernel off a medium that isn't SD

Theo