ARM9 boot up

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

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

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

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

t =A0

=A0

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.

om/mail/

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,

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

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

l's

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, snipped-for-privacy@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

d =A0

=A0

=A0

=A0

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.

om/mail/

no

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.

ry

,

l's

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

Sorry, I meant a processor can never boot with MMU _on_ .

Kaustubh

There is no reason that a processor can't create default page tables during initialization, and so boot with the MMU on.

--
ArarghMail809 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

on

's no

Can you please, name a processor which boots with MMU on?

Kaustubh

What would the default virtual/logical to physical be ?

The only one that I can think of is the 1:1 mapping, which of course looks very much like disabling the MMU :-).

Paul

ple

I guess ARM Architecture Reference Manual.

://infocenter.arm.combut didn't find.

on

with no luck so far. Probably this is chip

I'd organize the first 7 steps a little differently (I haven't used the ARM9, but it's the same principle regardless of the cpu). The ordering may have to be a little different if your chip does not have any internal ram.

1. Enable internal ram (if possible) and set the stack pointer.
2. Jump to C (note - at this stage, static variables are not initialised or zeroed, and probably not even accessible. Stick to local variables, preferably register-only. If there is no internal ram for a stack, use inlined functions only).
3. Set up the clock.
4. Initialise the SDRAM and other critical bus setup.
5. Initialise the MMU and/or cache.
6. Copy the code into SDRAM and jump to this copy.
7. Clear the BSS, and perhaps other block initialisation (small data blocks, etc.). Set up the real stack(s). Now you are in a "real" C environment.

8... as in the quoted post.

The point is to get to a minimal C environment as fast as possible. You don't need much to get C working - typically just a half-dozen assembly instructions to get a basic stack ready (and even that is not strictly necessary). It's a somewhat crippled C, with no access to static or dynamic memory, and perhaps not even non-register variables or function calls (if you have no stack), and you'll want to check the generated assembly manually. But it's still often much easier to generate smaller and faster code this way, unless you are particularly fond of assembly programming on the platform in question.

I never said or even implied that I knew of one, just that was no reason that one couldn't exist.

However, it may be that some of the DG Nova Processors would qualify. IIRC, they didn't have memory based tables. I would have to find some manuals to find out just how they worked, though.

--
ArarghMail809 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

Yes, but that would still be ON, though ineffective.

--
ArarghMail809 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

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

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

In your "typical sequence of initialization" you went up to

This made me assume that 1..12 was all part of initialization, and not part of normal U-Boot operation. This was logically followed by the assumption that U-Boot contains a kernel. Which is wrong, obviously.

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