booting the Linux on bare metal board.

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 Östman

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

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 Östman

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

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

[...]

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

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.

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

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

[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

The BootROM does not support booting from parallel NOR Flash. You use the Boot Mode Select Pin for that. A cool feature of the SAM9G20 bootROM is its ability to boot from TWO SPI memories. First it tries chip select 0, and if that fails, it tries chip select 1. A proper implementation, would connect the SPI flash to chip select 1, and the chip select 0, would be available on a connector. To program a board, you just connect an external dataflash to the connector, and press reset. At that time, there were dataflashcards, with a dataflash in an SD-Card physical format.

The feature could of course also be used to recover a dead system, without all these bloody jumpers. The idea was developed by me, together with Prof Hoegl from Fachhochschule in Augsburg to make a development board "Student-Proof", and was first implemented in the SAM9260. Whatever the student did to the flash of the board, the professor could recover just by inserting a card, followed by a reset. At the request of a major Danish Toy manufacturer, the SD-Card boot was added to the AT91.

The latest crop of chips, the SAM9x5 and the new Cortex-A5 chip has an even more advanced bootROM, supporting programmable bootorder. (You have 8 possible variants). The Boot Order is stored in a battery backed up area.

Many chips does not support a boot order, instead they configure the boot using external straps, which is kinda stupid, since then it is no way to recover without opening a box.

If the AT91 bootROM does not detect any viable boot sources, it will enter SAM-BA boot, allowing the chip to be programmed through its USB or UART interface.

I added a feature to U-boot allowing me to reset the chip into SAM-BA boot, without fiddling around with Jumpers. Quite nice - Hate Jumpers!

One improvement which never got into the bootROM was a fully programmable boot order. There is a three bit register to determine the boot order, and if this was extended to a 32 bit register, with 8 fieds of

4 bits, each value defining a boot source, then you could select any order, just like a PC BIOS. Alternatively, you could store the bootorder in a small EEPROM.

BR Ulf Samuelsson

I tried to figure out how to do that (I wanted to do it from the bootstrap in the case where U-Boot was missing). I asked our FAE if there was a way for code in bootstrap or U-Boot to re-start the ROMBoot code, but I never got any response from him (we're not a very big customer).

--
Grant

It only works on newer chips like the SAM9x5, SAM9N12 and SAMA5D3x. There is a battery backed up register, which defines the boot order. If you modify the bootorder to only enter SAM-BA boot, and then reset, it will work.

BR Ulf Samuelsson

Ah, I see. Thanks for the response. I was hoping it was as simple as jumping to the correct address (assuming that the boot ROM exists in the normal address space visible to the bootstrap).

--
Grant Edwards               grant.b.edwards        Yow! Are we wet yet? 
                                  at                
                              gmail.com