Re: MVME5100: kernel hangs in dcache_init

On Fri, Feb 16, 2001 at 04:37:42PM +0100, Stefano Coluccini wrote:

quoted

Did you make sure it's getting the correct memory size?

I think the problem is not there because the printks before the hang shows
the correct value (I have inserted the printouts of my boot process at the
bottom of the message)

quoted

 Assuming you're
trying to port into the existing prep_* framework, it does use residual
data to determine memory size.  That used to be reasonable but the
newer MCG boards are not providing any useful information in
residual data, I'd imagine this is also the case with the 5100.  That's
why the new MCG ports in the development tree no longer rely on residual
data.

Yes, I'm working on prep_* framework, but the residual seems significant and
correct (to my un-expert eyes :-)

Ok, well, it was just a guess.  To be honest, I'd throw my Abatron on
there at this point.  The alternative is a liberal sprinkling of
printk's and/or kgdb unless somebody else has a strong clue as to the
source of the problem.

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

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

Ok, well, it was just a guess.  To be honest, I'd throw my Abatron on
there at this point.  The alternative is a liberal sprinkling of
printk's and/or kgdb unless somebody else has a strong clue as to the
source of the problem.

 ... mmmhhh, I have not a commercial debugger and I have never used kgdb,
also, I've tried to compile the kernel with the kgdb support but it does not
finish the compilation. At the moment my unique debugging technique is
printk, do you think is necessary to setup kgdb ?
With printk, in this case, I don't understand what I can print because there
are not a lot of values to print. I suppose the problem is in the
initialization of MMU or IRQ and this problem is a side effect. For example,
in prep_setup.c there is a write to 8000081c to enable the L2 cache, but in
the MVME5100 programmers manual I haven't find the address of the
corresponding register so I'm not sure of the effect of this write.

You might want to see the MCPN765 and PrPMC750 ports that are in
in the 2_5 tree.  They're examples of what I'm working on with the
2300/2400/2600/2700/3600/4600, MTX variants, and MCP(N)750.

Excuse me ... but where I can find that *VITAL* helps ?
Thank you very much.

Stefano.


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