booting the Linux on bare metal board.

Grant Edwards skrev 2013-03-21 20:23:
> 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).

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

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

On 2013-04-05, Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> wrote:

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

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

On 2013-04-06 17:10, Grant Edwards wrote:
> On 2013-04-05, Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> wrote:
>
>> 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!
>
> 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).
>

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

On 2013-04-11, Ulf Samuelsson <ulf@invalid.com> wrote:
> On 2013-04-06 17:10, Grant Edwards wrote:
>> On 2013-04-05, Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> wrote:
>>
>>> 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!
>>
>> 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).
>>
>
> 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.

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