7400 mmu_init problem

7400 mmu_init problem

[Greg Griffes]

Hello,

I am trying to port linuxppc_2_4_devel to a custom 750 design.
Using the GNU binutils and gcc-core-2.95.3 tools.

After ppc_md.progress reports "MMU: exit" in mm/init.c::mmu_init()
the kernel goes into panic() and dies there.

I have been using a lousy, unreliable JTAG debugger. Today, I have a
BDI2000 and will be learning how to use it and GDB :-))

Has anyone experienced this in the past?
Does anyone have a rough idea of the cause of the problem?
My guess is that it could be many possible problems, but, it has to
be something that I did wrong in <my>_setup.c I haven't changed
much in the kernel itself.

The low level IO is mapped at 0xEC00_0000; could that be a problem?

The kernel is configured very slim, could I be excluding necessary
functionality?

Thanks for listening,

Greg Griffes

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

Re: 7400 mmu_init problem

[Matt Porter]

On Fri, Apr 05, 2002 at 05:45:08AM -0500, Greg Griffes wrote:
>
> Hello,
>
> I am trying to port linuxppc_2_4_devel to a custom 750 design.
> Using the GNU binutils and gcc-core-2.95.3 tools.

7400 (subject line) or 750? :)  It doesn't matter though.

> After ppc_md.progress reports "MMU: exit" in mm/init.c::mmu_init()
> the kernel goes into panic() and dies there.
>
> I have been using a lousy, unreliable JTAG debugger. Today, I have a
> BDI2000 and will be learning how to use it and GDB :-))

Even with a bad debugger you should be able to dump log_buf to
see the oops message.

> Has anyone experienced this in the past?

If I had a nickel for every time...

> Does anyone have a rough idea of the cause of the problem?
> My guess is that it could be many possible problems, but, it has to
> be something that I did wrong in <my>_setup.c I haven't changed
> much in the kernel itself.

We can only guess since we don't know your hardware and can't see
your board specific code.  However, you made it out of MMU_init
and most likely got to start_kernel:setup_arch.  I can only guess
that you access an unmapped area in your <board>_setup_arch.

> The low level IO is mapped at 0xEC00_0000; could that be a problem?

What low level IO?  Are you attempting to map and use it early on?
We need more details to help further.

> The kernel is configured very slim, could I be excluding necessary
> functionality?

Not really.

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: 7400 mmu_init problem

[Greg Griffes]

Matt,

Thanks a ton for the advice.  Looking at log_buf did the trick.
The Oops logs helped me to track down each access violation
and troubleshoot the rest of my bugs.  I'm getting text from
printk now!  I am sooo excited :-))

The BDI2000 wouldn't work with my hardware for some reason.
It complained that it could not break on the boot vector.
Tried it with both hard and soft breaks.  Booting from flash, so,
maybe that has something to do with it.

Question.  How do you recommend mapping in hardware that is
common to mach_dep code and drivers?
Specifically, the ASIC is mapped using ioremap in setup_arch so
that functions like get_irq will work.  The ASIC also has the serial
ports.  So, for the tty driver, it seems wasteful to map the ASIC
again in the driver init code.  What I did, was to put serial_in
and serial_out into myboard_setup.c where the pre-initialized
virtual address is stored.  Is there a better approach?

Greg

To answer your questions...

> 7400 (subject line) or 750? :)

The board actually supports either as you hinted.  Right now, I have a 750
version.

> and most likely got to start_kernel:setup_arch.  I can only guess
> that you access an unmapped area in your <board>_setup_arch.

BINGO!  I had some ppc_md.progress calls after mmu_init() and before the ioremap
calls.


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

Re: 7400 mmu_init problem

[Matt Porter]

On Sat, Apr 06, 2002 at 07:47:11PM -0500, Greg Griffes wrote:
> Matt,
>
> Thanks a ton for the advice.  Looking at log_buf did the trick.
> The Oops logs helped me to track down each access violation
> and troubleshoot the rest of my bugs.  I'm getting text from
> printk now!  I am sooo excited :-))

Ahh yes, I call it "bringup euphoria". :)  Quite fun.

> The BDI2000 wouldn't work with my hardware for some reason.
> It complained that it could not break on the boot vector.
> Tried it with both hard and soft breaks.  Booting from flash, so,
> maybe that has something to do with it.

Hrm.  Have you talked to Abatron's support?  They are quite good
and can probably give you some hints or debug enabled firmware to
see what signals may be causing the problem on your hardware.

> Question.  How do you recommend mapping in hardware that is
> common to mach_dep code and drivers?
> Specifically, the ASIC is mapped using ioremap in setup_arch so
> that functions like get_irq will work.  The ASIC also has the serial
> ports.  So, for the tty driver, it seems wasteful to map the ASIC
> again in the driver init code.  What I did, was to put serial_in
> and serial_out into myboard_setup.c where the pre-initialized
> virtual address is stored.  Is there a better approach?

Well, if you ioremap both (and each set of regs is confined to a
single 4KB page...I hope for a simple PIC and UART) then you
end up with two TLB entries in constant use.  You *could* use
an io block mapping to cover it with a BAT, if you are concerned
about TLB starvation but I suspect you won't see a recognizable
difference in performance.

Look at the use of <board>_progress and early_serial_setup() to
configure UARTs in some other ports (mcpn765, gt64260, ebony).
A useful hack is to cover your UART with a BAT in head.S.  In
<board>_setup_arch you then use early_serial_setup() with
ioremap (or the address from the optional block mapped method)
to do the real mapping of your UARTs.

> To answer your questions...
>
> > 7400 (subject line) or 750? :)
>
> The board actually supports either as you hinted.  Right now, I have a 750
> version.

Aha! :)

> > and most likely got to start_kernel:setup_arch.  I can only guess
> > that you access an unmapped area in your <board>_setup_arch.
>
> BINGO!  I had some ppc_md.progress calls after mmu_init() and before the ioremap
> calls.

Cool.  Sounds like you are moving right along.

Good luck,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: 7400 mmu_init problem

[Wolfgang Denk]

On Sat, Apr 06, 2002 at 07:47:11PM -0500, Greg Griffes wrote:
>
> The BDI2000 wouldn't work with my hardware for some reason.
> It complained that it could not break on the boot vector.
> Tried it with both hard and soft breaks.  Booting from flash, so,
> maybe that has something to do with it.

This is usually because of an incorrect (not  sufficiently  adjusted)
BDI2000 config file. Pay special attention to the BOOTADDR parameter;
depending   on   your  board  configuration  this  is  0x00000100  or
0xFFF00100. If it is set incorrectly, you may hang the  CPU  and  the
BDI will not work.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.

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