[coreboot] 8 GB DIMMs on Nehalem (Arrandale)

[Zoran Stojsavljevic]

Hello Stefan,

Let me ask you for some other stuff, since I would like to put what I wrote
initially to hold (sleep state, for now).

You wrote: *The official specs are not trustworthy IMHO and cpuid(1) and
/proc/cpuinfo **show the same physical address width of 36 bits (which
would indicate a **maximum of 64 GB).*

Question to you: are you dealing with i686 kernel, (32 bit)? It seems to me
that you have Nehalem which complies in IA32 with PAE HW extension, don't
you?!

What is PAE? Here: https://en.wikipedia.org/wiki/Physical_Address_Extension

In computing <https://en.wikipedia.org/wiki/Computing>, *Physical Address
Extension* (*PAE*), sometimes referred to as *Page Address Extension*, is a
memory management feature for the IA-32
<https://en.wikipedia.org/wiki/IA-32> architecture. *PAE was first
introduced in the **Pentium Pro
<https://en.wikipedia.org/wiki/Pentium_Pro>. It defines a page table
<https://en.wikipedia.org/wiki/Page_table> hierarchy of three levels, with
table entries of 64 bits each instead of 32, allowing these CPUs to access
a physical address space
<https://en.wikipedia.org/wiki/Address_space> larger than 4 gigabytes
<https://en.wikipedia.org/wiki/Gigabyte> (232** bytes)*.

This is very important -> *Enabling PAE (by setting bit 5, PAE, of the
system register CR4) causes major changes to this scheme...*

Thank you,
Zoran

On Sat, Jan 28, 2017 at 3:10 PM, Stefan Tauner <
stefan.tauner at alumni.tuwien.ac.at> wrote:

> On Sun, 22 Jan 2017 12:33:08 +0100
> Zoran Stojsavljevic <zoran.stojsavljevic at gmail.com> wrote:
>
> > Hello Stefan,
> >
> > In addition what Charlotte wrote to you, I would advise you the following
> > (as general approach for mem problems):
> > [1] Please, for testing the memory, use secondary Coreboot payload called
> > MEMTEST:
> > [user at localhost coreboot]$ cat .config | grep MEMTEST
> > CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
> > CONFIG_MEMTEST_STABLE=y
> > # CONFIG_MEMTEST_MASTER is not set
> >
> > Instead going to SeaBIOS or GRUB2 as payloads. This memtest86+ could (my
> > best guess) show to you what is wrong with your memory configuration.
> >
> > [2] You can also (since you are able to in some cases go to Linux) stop
> in
> > GRUB2, after installing from Linux memtest86+ package into the GRUB2 boot
> > options (this can also help too, my best guess).
> >
> > (extra advise: if you use legacy/CSM ON, which is in Coreboot in 99.999%
> > cases used, it would be much easier for you to deal with memtest86+)
>
> Hi Zoran,
>
> I am not exactly sure what you are trying to convey. I mentioned
> that memtest did lock up after some seconds with the vendor firmware in
> my previous mail. Of course it's the first thing to try when memory
> problems arise - I just tried to boot Linux to retrieve the e820 map
> because Nico requested it on IRC. I presume that using memtest as
> primary or secondary payload or booted from GRUB2 would not produce
> different results (unless the binaries are different of course), no?
>
> --
> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170128/12f27cc1/attachment.html>