Re: check MMU state

Re: check MMU state

[Benjamin Herrenschmidt]

On Sat, 2003-04-05 at 17:35, Thomas Gleixner wrote:
> Hi !
>
> Is there a clean way to check, if the MMU is enabled on kernel entry ? I have
> to port Linux to a PMC-module, where the bootloader code should not be
> changed.

The kernel entry can cope with both cases, provided that early_init
properly returns the physical address where the kernel is loaded,
regardless of the translations setup by the bootloader. Also, the
kernel has to be contiguous in physical memory.

Ben.

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

Re: check MMU state

[Benjamin Herrenschmidt]

On Sat, 2003-04-05 at 18:15, Thomas Gleixner wrote:
> On Saturday 05 April 2003 16:49, Benjamin Herrenschmidt wrote:
> > > Is there a clean way to check, if the MMU is enabled on kernel entry ? I
> > > have to port Linux to a PMC-module, where the bootloader code should not
> > > be changed.
> >
> > The kernel entry can cope with both cases, provided that early_init
> > properly returns the physical address where the kernel is loaded,
> > regardless of the translations setup by the bootloader. Also, the
> > kernel has to be contiguous in physical memory.
> I don't reach early_init. The CPU is a 860 and I'm using 2.4.20-ben8. I get
> lost in initial_mmu. If I turn off the mmu before "bl initial_mmu" everything
> is fine.

Ah well, I was talking about the "common" CPU case (CONFIG_6xx), I don't
know about 8xx but since the first thing the code  in head_8xx.S does is
"tlbia", I think you are in a bad situation running that with
translation enabled and no vectors around to handle the TLB miss...

For machines without BATs, I tend to think that a bootloader loading
you with MMU on shall be shot. What I'd suggest is that you hack a piggy
back loader in the zImage wrapper that shuts MMU off before entering the
kernel. If you _have_ to run vmlinux as is, then stuff a bl to some code
to disable the MMU before reaching initial_mmu in head_8xx.S

Ben.


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

check MMU state

[Thomas Gleixner]

Hi !

Is there a clean way to check, if the MMU is enabled on kernel entry ? I have
to port Linux to a PMC-module, where the bootloader code should not be
changed.

--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de


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

Re: check MMU state

[Benjamin Herrenschmidt]

On Sat, 2003-04-05 at 18:23, Thomas Gleixner wrote:
> On Saturday 05 April 2003 17:24, Benjamin Herrenschmidt wrote:
> > On Sat, 2003-04-05 at 18:15, Thomas Gleixner wrote:
> > > On Saturday 05 April 2003 16:49, Benjamin Herrenschmidt wrote:
> > > > > Is there a clean way to check, if the MMU is enabled on kernel entry
> > > > > ? I have to port Linux to a PMC-module, where the bootloader code
> > > > > should not be changed.
> > > >
> > > > The kernel entry can cope with both cases, provided that early_init
> > > > properly returns the physical address where the kernel is loaded,
> > > > regardless of the translations setup by the bootloader. Also, the
> > > > kernel has to be contiguous in physical memory.
> > >
> > > I don't reach early_init. The CPU is a 860 and I'm using 2.4.20-ben8. I
> > > get lost in initial_mmu. If I turn off the mmu before "bl initial_mmu"
> > > everything is fine.
> >
> > Ah well, I was talking about the "common" CPU case (CONFIG_6xx), I don't
> > know about 8xx but since the first thing the code  in head_8xx.S does is
> > "tlbia", I think you are in a bad situation running that with
> > translation enabled and no vectors around to handle the TLB miss...
> >
> > For machines without BATs, I tend to think that a bootloader loading
> > you with MMU on shall be shot. What I'd suggest is that you hack a piggy
> > back loader in the zImage wrapper that shuts MMU off before entering the
> > kernel. If you _have_ to run vmlinux as is, then stuff a bl to some code
> > to disable the MMU before reaching initial_mmu in head_8xx.S
> I have done this already, but just wanted to know, if there is a way to check
> the mmu-state in case that the bootloader code is corrected some day.

Just check MSR:IR/DR

Ben.


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

Re: check MMU state

[Thomas Gleixner]

On Saturday 05 April 2003 16:49, Benjamin Herrenschmidt wrote:
> > Is there a clean way to check, if the MMU is enabled on kernel entry ? I
> > have to port Linux to a PMC-module, where the bootloader code should not
> > be changed.
>
> The kernel entry can cope with both cases, provided that early_init
> properly returns the physical address where the kernel is loaded,
> regardless of the translations setup by the bootloader. Also, the
> kernel has to be contiguous in physical memory.
I don't reach early_init. The CPU is a 860 and I'm using 2.4.20-ben8. I get
lost in initial_mmu. If I turn off the mmu before "bl initial_mmu" everything
is fine.

--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de


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

Re: check MMU state

[Thomas Gleixner]

On Saturday 05 April 2003 17:24, Benjamin Herrenschmidt wrote:
> On Sat, 2003-04-05 at 18:15, Thomas Gleixner wrote:
> > On Saturday 05 April 2003 16:49, Benjamin Herrenschmidt wrote:
> > > > Is there a clean way to check, if the MMU is enabled on kernel entry
> > > > ? I have to port Linux to a PMC-module, where the bootloader code
> > > > should not be changed.
> > >
> > > The kernel entry can cope with both cases, provided that early_init
> > > properly returns the physical address where the kernel is loaded,
> > > regardless of the translations setup by the bootloader. Also, the
> > > kernel has to be contiguous in physical memory.
> >
> > I don't reach early_init. The CPU is a 860 and I'm using 2.4.20-ben8. I
> > get lost in initial_mmu. If I turn off the mmu before "bl initial_mmu"
> > everything is fine.
>
> Ah well, I was talking about the "common" CPU case (CONFIG_6xx), I don't
> know about 8xx but since the first thing the code  in head_8xx.S does is
> "tlbia", I think you are in a bad situation running that with
> translation enabled and no vectors around to handle the TLB miss...
>
> For machines without BATs, I tend to think that a bootloader loading
> you with MMU on shall be shot. What I'd suggest is that you hack a piggy
> back loader in the zImage wrapper that shuts MMU off before entering the
> kernel. If you _have_ to run vmlinux as is, then stuff a bl to some code
> to disable the MMU before reaching initial_mmu in head_8xx.S
I have done this already, but just wanted to know, if there is a way to check
the mmu-state in case that the bootloader code is corrected some day.

--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de


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

Re: check MMU state

[Dan Malek]

Benjamin Herrenschmidt wrote:

> Ah well, I was talking about the "common" CPU case (CONFIG_6xx), I don't
> know about 8xx but since the first thing the code  in head_8xx.S does is
> "tlbia", I think you are in a bad situation running that with
> translation enabled and no vectors around to handle the TLB miss...

Well, it's worse then that.....if you have the MMU enabled and require
taking tlb misses, I'm surprised you get to initial_mmu because we already
wrote over the exception vectors.

> For machines without BATs, I tend to think that a bootloader loading
> you with MMU on shall be shot.

We could do like some of the 60x/7xxx processors do.  They boot with
the MMU enabled, using BATs mapped 1:1 to get certain cache attributes in
memory spaces (DINK does this).  If you are using large pages on 8xx mapped 1:1
for the same cache attributes, it's OK.  If _any_ powerpc boots with the MMU
enabled and not 1:1 mapping (on memory of interest), you are hosed.

> .... What I'd suggest is that you hack a piggy
> back loader in the zImage wrapper that shuts MMU off before entering the
> kernel.

Yep, and it should be done right away before any of the decompress is
done so the cache management works correctly.

> .... If you _have_ to run vmlinux as is,

You can't on 8xx and most embedded systems.  You need some kind of piggyback
loader to create the environment variables so Linux will boot properly.


	-- Dan


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

Re: check MMU state

[Thomas Gleixner]

On Saturday 05 April 2003 20:31, Dan Malek wrote:
> Benjamin Herrenschmidt wrote:
> > Ah well, I was talking about the "common" CPU case (CONFIG_6xx), I don't
> > know about 8xx but since the first thing the code  in head_8xx.S does is
> > "tlbia", I think you are in a bad situation running that with
> > translation enabled and no vectors around to handle the TLB miss...
>
> Well, it's worse then that.....if you have the MMU enabled and require
> taking tlb misses, I'm surprised you get to initial_mmu because we already
> wrote over the exception vectors.
>
> > For machines without BATs, I tend to think that a bootloader loading
> > you with MMU on shall be shot.
>
> We could do like some of the 60x/7xxx processors do.  They boot with
> the MMU enabled, using BATs mapped 1:1 to get certain cache attributes in
> memory spaces (DINK does this).  If you are using large pages on 8xx mapped
> 1:1 for the same cache attributes, it's OK.  If _any_ powerpc boots with
> the MMU enabled and not 1:1 mapping (on memory of interest), you are hosed.
>
> > .... What I'd suggest is that you hack a piggy
> > back loader in the zImage wrapper that shuts MMU off before entering the
> > kernel.
>
> Yep, and it should be done right away before any of the decompress is
> done so the cache management works correctly.
>
> > .... If you _have_ to run vmlinux as is,
>
> You can't on 8xx and most embedded systems.  You need some kind of
> piggyback loader to create the environment variables so Linux will boot
> properly.
I'm working on a PMC board, where I can't modify the bootloader for now. So I
had to go through this. The kernel is loaded via PCI as a plain vmlinux, for
initrd applies the same.

I had to fight some time, but finaly i got it to work. :)

--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de


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

Re: check MMU state

[Dan Malek]

Thomas Gleixner wrote:

> I'm working on a PMC board, where I can't modify the bootloader for now.

One of us doesn't understand the other :-)

The 'piggyback' loaders are in arch/ppc/boot.  These are wrappers around
a compressed kernel.  Their purpose is to take a boot environment, that
you likely can't modify, and convert it to something suitable for linux
before uncompressing/booting the kernel.

> I had to fight some time, but finaly i got it to work. :)

I don't understand how.  The 8xx has internal boot parameters that must
get initialized by a piggyback loader.  How did you do that?

Thanks.


	-- Dan


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