chrp mmu and booting.

chrp mmu and booting.

[Sven Luther]

Hello,

I have just a question about what the mmu status is supposed to be while
booting a chrp kernel.

I know that the chrp kernel starts at 0x10000, and that a of/mmu
translate call is used to discover it.

Now, does this mean that the chrp of does enable the mmu before booting,
and does program it in a way so that the translate (0) call will result
in 0x10000, or do i miss something ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Peter Bergner]

On Fri, 2004-01-23 at 05:17, Sven Luther wrote:
> Now, does this mean that the chrp of does enable the mmu before booting,
> and does program it in a way so that the translate (0) call will result
> in 0x10000, or do i miss something ?

On IBM CHRP hardware, OF executes in real mode (ie, relocate off).  It
then branches to yaboot/kernel still in real mode.  It's not until a
fair ways into the kernel boot that we turn relocate on (after we're
done making calls to OF).  This also means that Yaboot executes in
real mode as well on IBM CHRP machines.


Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Sven Luther]

On Fri, Jan 23, 2004 at 12:44:10PM -0600, Peter Bergner wrote:
> On Fri, 2004-01-23 at 05:17, Sven Luther wrote:
> > Now, does this mean that the chrp of does enable the mmu before booting,
> > and does program it in a way so that the translate (0) call will result
> > in 0x10000, or do i miss something ?
>
> On IBM CHRP hardware, OF executes in real mode (ie, relocate off).  It
> then branches to yaboot/kernel still in real mode.  It's not until a
> fair ways into the kernel boot that we turn relocate on (after we're
> done making calls to OF).  This also means that Yaboot executes in
> real mode as well on IBM CHRP machines.

Yeah, but in my case, i have no yaboot, and i know that these boxes are
also capable of booting from the OF.

But then, how comes the OF translate call is able to map the address 0
to the 0x10000 address ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Peter Bergner]

On Fri, 2004-01-23 at 12:54, Sven Luther wrote:
> Yeah, but in my case, i have no yaboot, and i know that these boxes are
> also capable of booting from the OF.

Yes, you can boot any 32-bit ELF binary from OF.  Yaboot and the zImage
wrapper for the 64-bit kernel are both 32-bit ELF binaries, so you can
boot either of these.  Note that you cannot boot a plain PPC64 vmlinux,
as the OF ELF loader doesn't support 64-bit ELF binaries.


> But then, how comes the OF translate call is able to map the address 0
> to the 0x10000 address ?

In real mode, there is no address mapping done.  When the kernel starts
executing, we are not loaded where we were linked at, so we must be very
careful about what we touch.  You'll see in arch/ppc64/kernel/prom.c,
that we use the RELOC() macro to access global data.  It essentially
maps the virtual/effective address the kernel expects things to be at
to the physical address it's actually loaded at.  The ppc32 kernel was
able to remove the RELOC() macro, but for various reasons, the PPC64
kernel is still stuck using it.


Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Benjamin Herrenschmidt]

On Sat, 2004-01-24 at 07:49, Peter Bergner wrote:

> In real mode, there is no address mapping done.  When the kernel starts
> executing, we are not loaded where we were linked at, so we must be very
> careful about what we touch.  You'll see in arch/ppc64/kernel/prom.c,
> that we use the RELOC() macro to access global data.  It essentially
> maps the virtual/effective address the kernel expects things to be at
> to the physical address it's actually loaded at.  The ppc32 kernel was
> able to remove the RELOC() macro, but for various reasons, the PPC64
> kernel is still stuck using it.

Yup :( Anton, Paulus and I have been scratching our heads to find
a way to kill it, not as simple as ppc32 but we'll eventually do it :)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Geert Uytterhoeven]

On Fri, 23 Jan 2004, Peter Bergner wrote:
> On Fri, 2004-01-23 at 12:54, Sven Luther wrote:
> > Yeah, but in my case, i have no yaboot, and i know that these boxes are
> > also capable of booting from the OF.
>
> Yes, you can boot any 32-bit ELF binary from OF.  Yaboot and the zImage
> wrapper for the 64-bit kernel are both 32-bit ELF binaries, so you can
> boot either of these.  Note that you cannot boot a plain PPC64 vmlinux,
> as the OF ELF loader doesn't support 64-bit ELF binaries.

Indeed, when porting Linux to the LongTrail, my first program on the box was a
small assembler program to print `Hello, world!' to the serial port, compiled
to a plain ELF binary and loaded from OF.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Segher Boessenkool]

> Yes, you can boot any 32-bit ELF binary from OF.  Yaboot and the zImage
> wrapper for the 64-bit kernel are both 32-bit ELF binaries, so you can
> boot either of these.  Note that you cannot boot a plain PPC64 vmlinux,
> as the OF ELF loader doesn't support 64-bit ELF binaries.

This is OF implementation dependent -- for example, the Apple one will
load 64-bit ELF just fine (iirc).


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Benjamin Herrenschmidt]

> Yeah, but in my case, i have no yaboot, and i know that these boxes are
> also capable of booting from the OF.
>
> But then, how comes the OF translate call is able to map the address 0
> to the 0x10000 address ?

If you are talking about non-IBM HW, then you can't rely on what happens
on IBM CHRP as a reference :) Any OF implementation does things differently
(and for example, Apple's one runs in virtual mode, not in real mode, thus
the translate call is useful in case you are loaded at a non-1:1 address).

What prom.c is expected to return is at what physical address the kernel
was loaded. If you have MMU off or 1:1 mapping, the reloc "offset" is
usually enough, but if OF have setup some kind of non-1:1 MMU mapping
then you need the translate call.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Sven Luther]

On Sat, Jan 24, 2004 at 12:08:19PM +1100, Benjamin Herrenschmidt wrote:
>
> > Yeah, but in my case, i have no yaboot, and i know that these boxes are
> > also capable of booting from the OF.
> >
> > But then, how comes the OF translate call is able to map the address 0
> > to the 0x10000 address ?
>
> If you are talking about non-IBM HW, then you can't rely on what happens
> on IBM CHRP as a reference :) Any OF implementation does things differently
> (and for example, Apple's one runs in virtual mode, not in real mode, thus
> the translate call is useful in case you are loaded at a non-1:1 address).

Well, as you know, we were forced on pegasos to force the start
address to 0X10000, since the translate call returned 0. I spoke with
the OF guy, and he said that it is normal that translate would return 0
if you send it 0, which probably means that the translation is just
plain doing nothing, which made me believe that the MMU must be of, or
doing a plain identify translation or something.

I was wondering if this is how it is supposed to be or not, and as i
have access to the OF source code, i wondered if it was something worth
fixing.

> What prom.c is expected to return is at what physical address the kernel
> was loaded. If you have MMU off or 1:1 mapping, the reloc "offset" is
> usually enough, but if OF have setup some kind of non-1:1 MMU mapping
> then you need the translate call.

mmm.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Benjamin Herrenschmidt]

> Well, as you know, we were forced on pegasos to force the start
> address to 0X10000, since the translate call returned 0. I spoke with
> the OF guy, and he said that it is normal that translate would return 0
> if you send it 0, which probably means that the translation is just
> plain doing nothing, which made me believe that the MMU must be of, or
> doing a plain identify translation or something.

I have to dbl check the code, we should translate our current offset
actually, not 0. (To get your current offset, bl <something>, then
mflr r3; blr)

> I was wondering if this is how it is supposed to be or not, and as i
> have access to the OF source code, i wondered if it was something worth
> fixing.
>
> > What prom.c is expected to return is at what physical address the kernel
> > was loaded. If you have MMU off or 1:1 mapping, the reloc "offset" is
> > usually enough, but if OF have setup some kind of non-1:1 MMU mapping
> > then you need the translate call.
>
> mmm.
>
> Friendly,
>
> Sven Luther
>
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: chrp mmu and booting.

[Segher Boessenkool]

> If you are talking about non-IBM HW, then you can't rely on what
> happens
> on IBM CHRP as a reference :) Any OF implementation does things
> differently
> (and for example, Apple's one runs in virtual mode, not in real mode,
> thus
> the translate call is useful in case you are loaded at a non-1:1
> address).

Any compliant PowerPC OF implementation is required to be able to run in
both real- and virtual mode.  Apple's OF runs in virtual mode by
default;
IBM's in real mode.  And neither runs very well in the "other" mode, as
it
is seldom (if ever) tested...


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/