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
Reply by Ulf Samuelsson●April 11, 20132013-04-11
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
Reply by Grant Edwards●April 6, 20132013-04-06
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
Reply by Ulf Samuelsson●April 5, 20132013-04-05
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!
>
>
Reply by Theo Markettos●March 21, 20132013-03-21
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
Reply by Grant Edwards●March 21, 20132013-03-21
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??
Reply by Jon Kirwan●March 21, 20132013-03-21
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.)
Reply by Rob Gaddi●March 21, 20132013-03-21
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.
Reply by Ivan Shmakov●March 21, 20132013-03-21
>>>>> 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
Reply by Grant Edwards●March 21, 20132013-03-21
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!!