440GX MMU problem

440GX MMU problem

[Barbier, Renaud (GE Infrastructure)]

I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
>From U-boot I can see the whole memory.
If I boot Linux, unless I set the boot parameter mem=3D256M (or less).
it will not boot. Linux does not seem to go further than the MMU_setup.

Any idea why it cannot use 512MB?

thanks.

Re: 440GX MMU problem

[Eugene Surovegin]

On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE Infrastructure) wrote:
> 
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=256M (or less).
> it will not boot. Linux does not seem to go further than the MMU_setup.
> 
> Any idea why it cannot use 512MB?

Incorrect SDRAM setup? Try running at least simple memory tests.

--
Eugene

Re: 440GX MMU problem

[Matt Porter]

On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE Infrastructure) wrote:
> 
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=256M (or less).
> it will not boot. Linux does not seem to go further than the MMU_setup.

Verified that the 440GX eval with 512MB works on both 2.4.26 and current
2.4. Works For Me(tm).
 
> Any idea why it cannot use 512MB?

A broken board port would do it. If you deviate for any reason
from the stock kernel configuration you can shoot yourself in the
foot real fast. If you can provide some details on your custom
board and port, somebody may be able to help you.

-Matt

RE: 440GX MMU problem

[Barbier, Renaud (GE Infrastructure)]

the memory test from U-boot does not complain as well as vxWorks.

I will do my own test anyway.

-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]
Sent: Friday, December 03, 2004 5:40 PM
To: Barbier, Renaud (GE Infrastructure)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 440GX MMU problem


On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE =
Infrastructure) wrote:
>=20
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=3D256M (or less).
> it will not boot. Linux does not seem to go further than the =
MMU_setup.
>=20
> Any idea why it cannot use 512MB?

Incorrect SDRAM setup? Try running at least simple memory tests.

--
Eugene

Re: 440GX MMU problem

[Matt Porter]

On Fri, Dec 03, 2004 at 11:45:25AM -0600, Barbier, Renaud (GE Infrastructure) wrote:
> the memory test from U-boot does not complain as well as vxWorks.
> 
> I will do my own test anyway.

>From experience, these simple memory tests are often not
sufficient...i.e. they can pass even with incorrect timing.

-Matt

RE: 440GX MMU problem

[Barbier, Renaud (GE Infrastructure)]

actually, I just loaded linux at memory offset 0x10000000(above 256MB)
and in this case it is able to boot and use the full 512MB.
there maybe indeed something broken.

Originally, U-boot did not map the full 512MB but only 256MB.
I wonder if that could be a possible source of my problem.



-----Original Message-----
From: Matt Porter [mailto:mporter@kernel.crashing.org]
Sent: Friday, December 03, 2004 6:06 PM
To: Barbier, Renaud (GE Infrastructure)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 440GX MMU problem


On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE =
Infrastructure) wrote:
>=20
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=3D256M (or less).
> it will not boot. Linux does not seem to go further than the =
MMU_setup.

Verified that the 440GX eval with 512MB works on both 2.4.26 and current
2.4. Works For Me(tm).
=20
> Any idea why it cannot use 512MB?

A broken board port would do it. If you deviate for any reason
from the stock kernel configuration you can shoot yourself in the
foot real fast. If you can provide some details on your custom
board and port, somebody may be able to help you.

-Matt

RE: 440GX MMU problem

[VanBaren, Gerald (AGRE)]

> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=0D
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=0D
> Barbier, Renaud (GE Infrastructure)
> Sent: Friday, December 03, 2004 3:53 PM
> To: Matt Porter
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: 440GX MMU problem
>=0D
> actually, I just loaded linux at memory offset=0D
> 0x10000000(above 256MB) and in this case it is able to boot=0D
> and use the full 512MB.
> there maybe indeed something broken.
>=0D
> Originally, U-boot did not map the full 512MB but only 256MB.
> I wonder if that could be a possible source of my problem.

Disclaimer: I don't have experience with the 4xx family, but won't stop
me from speculating (which drives Wolfgang crazy when I guess wrong ;-).

On the 82xx u-boot uses BATs to map memory.  On the 82xx, BATs are
limited to 256MBytes per BAT.  I'm guessing you are running into this.
Somewhere in your u-boot it doesn't know how to go beyond the 256MByte
boundary.

On u-boot, check out the use of "CONFIG_VERY_BIG_RAM".  It doesn't look
like it applies directly to your board/processor, but you may be able to
enhance your system using it or a similar concept.

gvb


******************************************
I apologize for the following message brought to you by the Lawyers'
League of IdioSpeak:

******************************************
The information contained in, or attached to, this e-mail, may contain=
 confidential information and is intended solely for the use of the=
 individual or entity to whom they are addressed and may be subject to=
 legal privilege.  If you have received this e-mail in error you should=
 notify the sender immediately by reply e-mail, delete the message from=
 your system and notify your system manager.  Please do not copy it for any=
 purpose, or disclose its contents to any other person.  The views or=
 opinions presented in this e-mail are solely those of the author and do=
 not necessarily represent those of the company.  The recipient should=
 check this e-mail and any attachments for the presence of viruses.  The=
 company accepts no liability for any damage caused, directly or=
 indirectly, by any virus transmitted in this email.
******************************************