Sorry, I meant a processor can never boot with MMU _on_ . Kaustubh
ARM9 boot up
Started by ●September 4, 2008
Reply by ●September 8, 20082008-09-08
Reply by ●September 8, 20082008-09-08
On Sun, 7 Sep 2008 20:47:11 -0700 (PDT), "ksashtekar@gmail.com" <ksashtekar@gmail.com> wrote:>On Sep 7, 1:22�am, "Roman Mashak" <m...@tusur.ru> wrote: >> Hello, ksashte...@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? > >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. >There is no reason that a processor can't create default page tables during initialization, and so boot with the MMU on. <snip> -- 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.
Reply by ●September 8, 20082008-09-08
On Sep 8, 9:23=A0am, ArarghMail809NOS...@NOT.AT.Arargh.com wrote:> On Sun, 7 Sep 2008 20:47:11 -0700 (PDT), "ksashte...@gmail.com" > > > > <ksashte...@gmail.com> wrote: > >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. > > There is no reason that a processor can't create default page tables > during initialization, and so boot with the MMU on.Can you please, name a processor which boots with MMU on?> > <snip> > -- > 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.Kaustubh
Reply by ●September 8, 20082008-09-08
On Sun, 07 Sep 2008 23:23:15 -0500, ArarghMail809NOSPAM@NOT.AT.Arargh.com wrote:>There is no reason that a processor can't create default page tables >during initialization, and so boot with the MMU on.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
Reply by ●September 8, 20082008-09-08
On Sep 8, 8:44=A0pm, "Roman Mashak" <m...@tusur.ru> wrote:> Hello, > You wrote =A0on Sat, 6 Sep 2008 08:28:49 -0700 (PDT): > > =A0??>> Resembles me the process of boot-up in arm7 based chips, for exam=ple> =A0??>> Atmel's SAM7 series. And you didn't mention about cash operations > =A0??>> 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" ?I guess ARM Architecture Reference Manual.> > As I mentioned in the original post, I was looking for information onhttp=://infocenter.arm.combut didn't find.> > l> through the MMU. MMU off at POR =3D> cache off at POR. > Thank you, it's clear now. > > Best regards, Roman Mashak
Reply by ●September 8, 20082008-09-08
ksashtekar@gmail.com wrote:> On Sep 5, 9:52 pm, "Roman Mashak" <m...@tusur.ru> wrote: >> 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 onhttp://infocenter.arm.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 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 > > 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.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.
Reply by ●September 8, 20082008-09-08
On Sun, 7 Sep 2008 21:43:21 -0700 (PDT), "ksashtekar@gmail.com" <ksashtekar@gmail.com> wrote:>On Sep 8, 9:23�am, ArarghMail809NOS...@NOT.AT.Arargh.com wrote: >> On Sun, 7 Sep 2008 20:47:11 -0700 (PDT), "ksashte...@gmail.com" >> <ksashte...@gmail.com> wrote: >> >On Sep 7, 1:22�am, "Roman Mashak" <m...@tusur.ru> wrote: >> >> Hello, ksashte...@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? >> >> >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. >> >> There is no reason that a processor can't create default page tables >> during initialization, and so boot with the MMU on. > >Can you please, name a processor which boots with MMU on? >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.
Reply by ●September 8, 20082008-09-08
On Mon, 08 Sep 2008 08:08:09 +0300, Paul Keinanen <keinanen@sci.fi> wrote:>On Sun, 07 Sep 2008 23:23:15 -0500, >ArarghMail809NOSPAM@NOT.AT.Arargh.com wrote: > >>There is no reason that a processor can't create default page tables >>during initialization, and so boot with the MMU on. > >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 :-). >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.
Reply by ●September 9, 20082008-09-09
Op Mon, 08 Sep 2008 05:41:45 +0200 schreef ksashtekar@gmail.com <ksashtekar@gmail.com>:> On Sep 5, 4:57�pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote: >> Op Fri, 05 Sep 2008 11:51:18 +0200 schreef ksashte...@gmail.com � >> <ksashte...@gmail.com>: >> >> > On Sep 5, 2:34�pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote: >> >> Op Fri, 05 Sep 2008 11:20:49 +0200 schreef ksashte...@gmail.com � >> >> <ksashte...@gmail.com>: >> >> > On Sep 5, 9:52�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. > > 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.In your "typical sequence of initialization" you went up to>>>>> 12. Jump to kernel entry point.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/
