EmbeddedRelated.com
Forums

booting the Linux on bare metal board.

Started by piyushpandey March 21, 2013
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