Re: MVME5100: kernel hangs in dcache_init

Re: MVME5100: kernel hangs in dcache_init

[Matt Porter]

On Fri, Feb 16, 2001 at 12:45:49PM +0100, Stefano Coluccini wrote:
>
> Hi everyone,
>
>   I'm trying to run Debian linux 2.2.18 on a MVME5100 board. I've done some
> change:
>  - changed addresses of UART registers in arch/ppc/boot/ns16550.h
>  - changed BAT settings in arch/ppc/mm/init.c to map IO region 0xf0000000 to
> 0xffffffff
> and some other things.
> Now the kernel hangs in the dcache_init routine in init/main.c and it seems
> to me that the problem is related to memory management, but I'm not sure.
> If I comment out the the routine calls from dcache_init to check_bugs(), the
> kernel go on a little showing me some infos about PCI devices.
>
> Anyone of you can help me ?

Did you make sure it's getting the correct memory size?  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.

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

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

MVME5100: kernel hangs in dcache_init

[Stefano Coluccini]

Hi everyone,

  I'm trying to run Debian linux 2.2.18 on a MVME5100 board. I've done some
change:
 - changed addresses of UART registers in arch/ppc/boot/ns16550.h
 - changed BAT settings in arch/ppc/mm/init.c to map IO region 0xf0000000 to
0xffffffff
and some other things.
Now the kernel hangs in the dcache_init routine in init/main.c and it seems
to me that the problem is related to memory management, but I'm not sure.
If I comment out the the routine calls from dcache_init to check_bugs(), the
kernel go on a little showing me some infos about PCI devices.

Anyone of you can help me ?

Thanks in advance.
Stefano.


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

Re: MVME5100: kernel hangs in dcache_init

[Gabriel Paubert]

On Fri, 16 Feb 2001, Matt Porter wrote:

>
> On Fri, Feb 16, 2001 at 12:45:49PM +0100, Stefano Coluccini wrote:
> >
> > Hi everyone,
> >
> >   I'm trying to run Debian linux 2.2.18 on a MVME5100 board. I've done some
> > change:
> >  - changed addresses of UART registers in arch/ppc/boot/ns16550.h
> >  - changed BAT settings in arch/ppc/mm/init.c to map IO region 0xf0000000 to
> > 0xffffffff
> > and some other things.
> > Now the kernel hangs in the dcache_init routine in init/main.c and it seems
> > to me that the problem is related to memory management, but I'm not sure.
> > If I comment out the the routine calls from dcache_init to check_bugs(), the
> > kernel go on a little showing me some infos about PCI devices.
> >
> > Anyone of you can help me ?
>
> Did you make sure it's getting the correct memory size?  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.

Don't tell me that the residual data can no moree be used even for this !
So ok, residual data is 100% useless and should be thrown away. At least I
expected this kind of basic information to be available.

At this point, let us get rid of PPCBUG and flash our firmware !

	Regards,
	Gabriel.


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

RE: MVME5100: kernel hangs in dcache_init

[Stefano Coluccini]

>
> 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)

>  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 :-)


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

Re: MVME5100: kernel hangs in dcache_init

[Matt Porter]

On Fri, Feb 16, 2001 at 04:27:22PM +0100, Gabriel Paubert wrote:
>
>
> On Fri, 16 Feb 2001, Matt Porter wrote:
>
> >
> > On Fri, Feb 16, 2001 at 12:45:49PM +0100, Stefano Coluccini wrote:
> > >
> > > Hi everyone,
> > >
> > >   I'm trying to run Debian linux 2.2.18 on a MVME5100 board. I've done some
> > > change:
> > >  - changed addresses of UART registers in arch/ppc/boot/ns16550.h
> > >  - changed BAT settings in arch/ppc/mm/init.c to map IO region 0xf0000000 to
> > > 0xffffffff
> > > and some other things.
> > > Now the kernel hangs in the dcache_init routine in init/main.c and it seems
> > > to me that the problem is related to memory management, but I'm not sure.
> > > If I comment out the the routine calls from dcache_init to check_bugs(), the
> > > kernel go on a little showing me some infos about PCI devices.
> > >
> > > Anyone of you can help me ?
> >
> > Did you make sure it's getting the correct memory size?  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.
>
> Don't tell me that the residual data can no moree be used even for this !
> So ok, residual data is 100% useless and should be thrown away. At least I
> expected this kind of basic information to be available.
>
> At this point, let us get rid of PPCBUG and flash our firmware !

:)

I've taken the approach that PPCBUG is just a glorified tool to load
a linear array of bits into memory and light them up. :)

One personal project of mine is to pull all of the MCG board support
out of prep_*.c into it's own option.  The major reason is that they
are nearly unmaintainable with all the hacks in there.

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.

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

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

Re: MVME5100: kernel hangs in dcache_init

[Matt Porter]

On Fri, Feb 16, 2001 at 04:37:42PM +0100, Stefano Coluccini wrote:
> >
> > 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)
>
> >  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/

RE: MVME5100: kernel hangs in dcache_init

[Stefano Coluccini]

>
> 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/