How to test RAM beyond 640 kByte boundary

[llandre]

I have a question about the ram_check function.
All the board specific codes invoke it like this:

ram_check(0x00000000, 640 * 1024);

I had a look with JTAG debugger and indeed the RAM beyond 640 KByte 
boundary is not accessible. Why? Is it possible to enable and test all 
the RAM available?

TIA,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&[e-mail]

[Peter Stuge]

On Wed, May 21, 2008 at 11:57:02AM +0200, llandre wrote:
> I have a question about the ram_check function.
> All the board specific codes invoke it like this:
>
> ram_check(0x00000000, 640 * 1024);
>
> I had a look with JTAG debugger and indeed the RAM beyond 640 KByte
> boundary is not accessible. Why? Is it possible to enable and test
> all the RAM available?

I would like to remove this function from our codebase.

Please note that this is not a useful RAM test.

Please build coreboot with a memtest86 payload in order to test your
RAM setup.

ram_check() is ONLY useful for _very early_ testing of the RAM setup.

Even successful ram_check() does not indicate that RAM is completely
correctly set up. You have to run a burn-in test like memtest86 for
a long time to have reliable results.

//Peter

[llandre]

> > I have a question about the ram_check function.
> > All the board specific codes invoke it like this:
> >
> > ram_check(0x00000000, 640 * 1024);
> >
> > I had a look with JTAG debugger and indeed the RAM beyond 640 KByte
> > boundary is not accessible. Why? Is it possible to enable and test
> > all the RAM available?
>
> I would like to remove this function from our codebase.
>
> Please note that this is not a useful RAM test.
>
> Please build coreboot with a memtest86 payload in order to test your
> RAM setup.
>
> ram_check() is ONLY useful for _very early_ testing of the RAM setup.
>
> Even successful ram_check() does not indicate that RAM is completely
> correctly set up. You have to run a burn-in test like memtest86 for
> a long time to have reliable results.

I see.
Why is the RAM physically unaccessible beyond 640 KByte at this stage? 
Is it a specific (legacy) memory controller mode?

[Uwe Hermann]

On Wed, May 21, 2008 at 12:44:15PM +0200, llandre wrote:
> Why is the RAM physically unaccessible beyond 640 KByte at this stage?

Which chipset / board? It's not necessarily unaccessible.

You have to be careful to not check the range from 640kb to 1MB,
after that it should be ok again.

E.g. try this if you have 64MB or RAM:

ram_check(0, 640 * 1024);
ram_check(1024 * 1024, 64 * 1024 * 1024);

If this does not work, then you likely have a RAM setup problem.
The fact that the 640kb-1mb range doesn't work with ram_check()
is sort of expected.
> Is it a specific (legacy) memory controller mode?

The northbridge / RAM controller has some registers which allow
you to control what happens with the accesses from 640KB to 1MB,
I think it depends on that config...

Uwe.

[llandre]

> > Why is the RAM physically unaccessible beyond 640 KByte at this stage?
>
> Which chipset / board? It's not necessarily unaccessible.

AMD Geode LX/CS5536
> You have to be careful to not check the range from 640kb to 1MB,
> after that it should be ok again.
>
> E.g. try this if you have 64MB or RAM:
>
> ram_check(0, 640 * 1024);
> ram_check(1024 * 1024, 64 * 1024 * 1024);

I see.
> If this does not work, then you likely have a RAM setup problem.
> The fact that the 640kb-1mb range doesn't work with ram_check()
> is sort of expected.

Ok.
> > Is it a specific (legacy) memory controller mode?
>
> The northbridge / RAM controller has some registers which allow
> you to control what happens with the accesses from 640KB to 1MB,
> I think it depends on that config...

I'll have a look at datasheet.

Thank you very much,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&[e-mail]

[llandre]

> > > Why is the RAM physically unaccessible beyond 640 KByte at this stage?
> >
> > Which chipset / board? It's not necessarily unaccessible.
>
> AMD Geode LX/CS5536

I forgot to mention that is a custom board.

[Marc Jones]

llandre wrote:
> > > > Why is the RAM physically unaccessible beyond 640 KByte at this stage?
> > >
> > > Which chipset / board? It's not necessarily unaccessible.
> >
> > AMD Geode LX/CS5536
>
> I forgot to mention that is a custom board.

The 640-1MB area is covered by a basemask descriptor (A0000-BFFFFh) 
setup and used by graphics and a swisscheese descriptor (C0000h-FFFFFh) 
for the legacy shadow memory hole. In 
northbridge/amd/lx/northbridgeinit.c see the gliutables structures.

In both tables you could change the swisscheese to allow reads and 
writes to memory like this:

{.desc_name = MSR_GLIU0_SHADOW,.desc_type = SC_SHADOW,.hi = MSR_MC + 
0xFFFF,.lo = 0xFFFF0003},

Marc