ARM9 boot up

Hello,

I'm in for a porting U-Boot on the ARM926EJ-S based system-on-chip. I worked 
before with ARM7, arm9 is my first experience -- therefore I'm looking for a 
description of boot-up process. Tried to find some on 
http://infocenter.arm.com but with no luck so far. Probably this is chip 
specific information?

I've checked ARM9 realated parts in U-Boot source tree, and found hat upon 
reset what it usually does is:
- flush on-chip caches
- disable MMU and caches
- initialize of RAM controller
- relocate boot image to RAM
....

Can it be considered a common sequence of operations or, as I noted above, 
this is entirely platfrom specific?
Thanks.

Best regards, Roman Mashak 

On Sep 5, 9:52=A0pm, "Roman Mashak" <m...@tusur.ru> wrote:
> Hello,
>
> I'm in for a porting U-Boot on the ARM926EJ-S based system-on-chip. I wor=
ked
> before with ARM7, arm9 is my first experience -- therefore I'm looking fo=
r a
> description of boot-up process. Tried to find some onhttp://infocenter.ar=
m.combut with no luck so far. Probably this is chip
> specific information?
>
> I've checked ARM9 realated parts in U-Boot source tree, and found hat upo=
n
> reset what it usually does is:
> - flush on-chip caches
> - disable MMU and caches
> - initialize of RAM controller
> - relocate boot image to RAM
> ....
>
> Can it be considered a common sequence of operations or, as I noted above=
,
> this is entirely platfrom specific?
> Thanks.
>
> Best regards, Roman Mashak

The processor always starts at the reset vector. This may depend on
the boot pins. The MMU is off when the processor is reset.

Following is the typical sequence of initialization: (assuming that
the bootloader is burned on and is running from a non-volatile memory
like NOR flash.)
1. Initialize the SDRAM controller.
2. Set up the stacks for various (ARM) processor modes. (undef, irq,
fiq ... )
3. Clear up the BSS space. (uninitialized variables)
4. Relocate the code to run from RAM (not always necessary).
5. Copy the .data section (initialized variables) to RAM.
6. Jump to C code.
7. Initialize the external bus controller for various address spaces
(chip selects). This depends on what devices you have connected to the
bus and what are their timing parameters.
8. Initialize various devices. (by calling their init functions)
9. Load the filesystem driver.
10. Search for the kernel.
11. Copy kernel to RAM. Set up command line parameters for the
kernel.
12 Jump to kernel entry point.

Depending on the kernel requirements the bootloader may also init the
MMU before calling the kernel.

Op Fri, 05 Sep 2008 11:20:49 +0200 schreef ksashtekar@gmail.com  
<ksashtekar@gmail.com>:
> On Sep 5, 9:52&#4294967295;pm, "Roman Mashak" <m...@tusur.ru> wrote:
>> [...] I'm looking for a
>> description of boot-up process. [...]
>
> The processor always starts at the reset vector. This may depend on
> the boot pins. The MMU is off when the processor is reset.

Note that this doesn't necessarily mean that the MMU is off when the reset  
vector is executed, e.g. when doing:
	MOV	R0, #0
	BX	R0

> Following is the typical sequence of initialization: (assuming that
> the bootloader is burned on and is running from a non-volatile memory
> like NOR flash.)

0. Depending on the desired start-up duration and the default clock  
selection, the very first thing to do might be PLL set-up.

> 1. Initialize the SDRAM controller.
> 2. Set up the stacks for various (ARM) processor modes. (undef, irq,
> fiq ... )
> 3. Clear up the BSS space. (uninitialized variables)
> 4. Relocate the code to run from RAM (not always necessary).
> 5. Copy the .data section (initialized variables) to RAM.
> 6. Jump to C code.
> 7. Initialize the external bus controller for various address spaces
> (chip selects). This depends on what devices you have connected to the
> bus and what are their timing parameters.
> 8. Initialize various devices. (by calling their init functions)

Unless the device driver processes do that themselves (it can be argued  
that they _should_ do this).

> 9. Load the filesystem driver.
> 10. Search for the kernel.
> 11. Copy kernel to RAM. Set up command line parameters for the
> kernel.
> 12 Jump to kernel entry point.
>
> Depending on the kernel requirements the bootloader may also init the
> MMU before calling the kernel.



-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

On Sep 5, 2:34=A0pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> Op Fri, 05 Sep 2008 11:20:49 +0200 schreef ksashte...@gmail.com =A0
> <ksashte...@gmail.com>:
>
> > On Sep 5, 9:52=A0pm, "Roman Mashak" <m...@tusur.ru> wrote:
> >> [...] I'm looking for a
> >> description of boot-up process. [...]
>
> > The processor always starts at the reset vector. This may depend on
> > the boot pins. The MMU is off when the processor is reset.
>
> Note that this doesn't necessarily mean that the MMU is off when the rese=
t =A0
> vector is executed, e.g. when doing:
> =A0 =A0 =A0 =A0 MOV =A0 =A0 R0, #0
> =A0 =A0 =A0 =A0 BX =A0 =A0 =A0R0
>
> > Following is the typical sequence of initialization: (assuming that
> > the bootloader is burned on and is running from a non-volatile memory
> > like NOR flash.)
>
> 0. Depending on the desired start-up duration and the default clock =A0
> selection, the very first thing to do might be PLL set-up.
>
> > 1. Initialize the SDRAM controller.
> > 2. Set up the stacks for various (ARM) processor modes. (undef, irq,
> > fiq ... )
> > 3. Clear up the BSS space. (uninitialized variables)
> > 4. Relocate the code to run from RAM (not always necessary).
> > 5. Copy the .data section (initialized variables) to RAM.
> > 6. Jump to C code.
> > 7. Initialize the external bus controller for various address spaces
> > (chip selects). This depends on what devices you have connected to the
> > bus and what are their timing parameters.
> > 8. Initialize various devices. (by calling their init functions)
>
> Unless the device driver processes do that themselves (it can be argued =
=A0
> that they _should_ do this).

How can they do this by themselves? Are you proposing that their init
functions
be kept in the .init section ? I am not sure whether this will work
because the bootloader is flashed to the boot device in binary format
and not in ELF format.

>
> > 9. Load the filesystem driver.
> > 10. Search for the kernel.
> > 11. Copy kernel to RAM. Set up command line parameters for the
> > kernel.
> > 12 Jump to kernel entry point.
>
> > Depending on the kernel requirements the bootloader may also init the
> > MMU before calling the kernel.
>
> --
> Gemaakt met Opera's revolutionaire e-mailprogramma: =A0http://www.opera.c=
om/mail/

Op Fri, 05 Sep 2008 11:51:18 +0200 schreef ksashtekar@gmail.com  
<ksashtekar@gmail.com>:
> On Sep 5, 2:34&#4294967295;pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>> Op Fri, 05 Sep 2008 11:20:49 +0200 schreef ksashte...@gmail.com &#4294967295;
>> <ksashte...@gmail.com>:
>> > On Sep 5, 9:52&#4294967295;pm, "Roman Mashak" <m...@tusur.ru> wrote:
>> > 8. Initialize various devices. (by calling their init functions)
>>
>> Unless the device driver processes do that themselves (it can be argued  
>> that they _should_ do this).
>
> How can they do this by themselves?

After kernel startup, when the kernel starts up all processes, the first  
thing that the device driver processes will do, is initialize themselves.   
Of course this assumes that your kernel is not a (Unix-like) monolith,  
where device drivers often don't have their own process.






-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Hello, ksashtekar@gmail.com!
You wrote  on Fri, 5 Sep 2008 02:20:49 -0700 (PDT):

 k> The processor always starts at the reset vector. This may depend on
 k> the boot pins. The MMU is off when the processor is reset.

Can we say that MMU must be off at CPU reset, it's mandatory and there's no 
other way it can be?

 k> Following is the typical sequence of initialization: (assuming that
 k> the bootloader is burned on and is running from a non-volatile memory
 k> like NOR flash.)
 k> 1. Initialize the SDRAM controller.

I got it.

 k> 2. Set up the stacks for various (ARM) processor modes. (undef, irq,
 k> fiq ... )
 k> 3. Clear up the BSS space. (uninitialized variables)
 k> 4. Relocate the code to run from RAM (not always necessary).
 k> 5. Copy the .data section (initialized variables) to RAM.
 k> 6. Jump to C code.

Resembles me the process of boot-up in arm7 based chips, for example Atmel's 
SAM7 series. And you didn't mention about cash operations during this 
process -- at what stage is it invovled?

Best regards, Roman Mashak 

On Sep 6, 4:22=A0pm, "Roman Mashak" <m...@tusur.ru> wrote:

> Resembles me the process of boot-up in arm7 based chips, for example Atme=
l's
> SAM7 series. And you didn't mention about cash operations during this
> process -- at what stage is it invovled?

Jeez, have you even bothered to read the ARM ARM? Cache is enabled
through the MMU. MMU off at POR =3D> cache off at POR.

Hello,
You wrote  on Sat, 6 Sep 2008 08:28:49 -0700 (PDT):

 ??>> Resembles me the process of boot-up in arm7 based chips, for example
 ??>> Atmel's SAM7 series. And you didn't mention about cash operations
 ??>> during this process -- at what stage is it invovled?
l> Jeez, have you even bothered to read the ARM ARM? Cache is enabled
What is "ARM ARM" ?

As I mentioned in the original post, I was looking for information on 
http://infocenter.arm.com but didn't find.

l> through the MMU. MMU off at POR => cache off at POR.
Thank you, it's clear now.

Best regards, Roman Mashak 

On Sep 5, 4:57=A0pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> Op Fri, 05 Sep 2008 11:51:18 +0200 schreef ksashte...@gmail.com =A0
> <ksashte...@gmail.com>:
>
> > On Sep 5, 2:34=A0pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> >> Op Fri, 05 Sep 2008 11:20:49 +0200 schreef ksashte...@gmail.com =A0
> >> <ksashte...@gmail.com>:
> >> > On Sep 5, 9:52=A0pm, "Roman Mashak" <m...@tusur.ru> wrote:
> >> > 8. Initialize various devices. (by calling their init functions)
>
> >> Unless the device driver processes do that themselves (it can be argue=
d =A0
> >> that they _should_ do this).
>
> > How can they do this by themselves?
>
> After kernel startup, when the kernel starts up all processes, the first =
=A0
> thing that the device driver processes will do, is initialize themselves.=
 =A0
> Of course this assumes that your kernel is not a (Unix-like) monolith, =
=A0
> where device drivers often don't have their own process.

If read the first post above (the original question) you will notice
that nowhere the person asks about a kernel. He is concerned with the
porting of UBoot bootloader and a bootloader has no concept of
processes. Its a simple collection of functions glued together to boot
whatever OS the embedded system runs.

>
> --
> Gemaakt met Opera's revolutionaire e-mailprogramma: =A0http://www.opera.c=
om/mail/

On Sep 7, 1:22=A0am, "Roman Mashak" <m...@tusur.ru> wrote:
> Hello, ksashte...@gmail.com!
> You wrote =A0on Fri, 5 Sep 2008 02:20:49 -0700 (PDT):
>
> =A0k> The processor always starts at the reset vector. This may depend on
> =A0k> the boot pins. The MMU is off when the processor is reset.
>
> Can we say that MMU must be off at CPU reset, it's mandatory and there's =
no
> other way it can be?

Roman, AFAIK, an processor can never boot with MMU off. This is
because the processor/MMU depends on the data structures called page
tables. This page tables are created by the software in the RAM.
Hence, the processor starts with MMU off. The code which runs the will
create the page tables in RAM and then s/w ON the MMU.

>
> =A0k> Following is the typical sequence of initialization: (assuming that
> =A0k> the bootloader is burned on and is running from a non-volatile memo=
ry
> =A0k> like NOR flash.)
> =A0k> 1. Initialize the SDRAM controller.
>
> I got it.
>
> =A0k> 2. Set up the stacks for various (ARM) processor modes. (undef, irq=
,
> =A0k> fiq ... )
> =A0k> 3. Clear up the BSS space. (uninitialized variables)
> =A0k> 4. Relocate the code to run from RAM (not always necessary).
> =A0k> 5. Copy the .data section (initialized variables) to RAM.
> =A0k> 6. Jump to C code.
>
> Resembles me the process of boot-up in arm7 based chips, for example Atme=
l's
> SAM7 series. And you didn't mention about cash operations during this
> process -- at what stage is it invovled?

You can enable the cache anytime you want. However, it must be flushed
and invalidated
just before starting the MMU. (This is a little bit platform/chip
dependant. It depends on the location of the cache and whether it is
physically tagged ...)

>
> Best regards, Roman Mashak