Good afternoon gents,
The ECC enable code has been fixed. It does enable the ECC when the DIMM
has ECC.
I did enable the RAM check and indeed this showed miserable results.
I've been trying to figure out
the correct settings but so far they are not there! Trying a few
BSEL/VSEL jumper settings with a
couple of different DIMM we have here showed some decent results, the
value I read back starts
to look as the value I send.
I've tried a reverse engineer approach. Plug a DIMM into the system and
launch Linux with the
legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the
settings doctored by the
legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the
coreboot RAM init code.
Not much differences so far. But anyway I've seen quite a lot of
difference around the ODT register
and such. So there is still some hope.
I will keep you guys updated as soon it is moving forward.
One thing I cannot figure out so far, is what the peripheral 0.8.0 is.
This seems to be an non existing
peripheral, this is the assumption I make so far. It is not documented
in the EP80579 documentation.
I am referring to raminit_ep80579.c function spd_set_drt_attributes().
val = (magic[index]);
print_debug("magic = ");
print_debug_hex32(val);
print_debug("\r\n");
pci_write_config32(PCI_DEV(0, 0x08, 0), 0xcc, val);
So what is this magic value about and what the devnbr8 on bus0 is are
the thing I would love to hear from
you guys. It is clear that the magic value is different for given DDR
memory frequency.
Thank you,
Arnaud
Ed Swierk wrote:
On Mon, Jun 22, 2009 at 5:06 AM, Arnaud Maye<[email protected]> wrote:
I've narrowed down the problem to the mtrr.c file in src/cpu/x86/mtrr/ in
the function set_fixed_mtrrs().
The first time disable_cache() is called, the CPU gets "lost". It either
hang or jump back to some code
to hang a bit after.
Am not 100% sure but I would say that as soon we disable the cache, the
processor is "forced" to
execute from RAM and not from the cache itself, having this strange behavior
here can still mean the
memory controller settings are not correct, right?
That does seems like symptom of memory controller misconfiguration.
I'd recommend you proceed by disabling ECC (comment out the "Set the
ECC mode" line in raminit_ep80579.c) and enabling the ram_fill() and
ram_verify() steps in auto.c. Adjust the parameters to fill and verify
the entire memory range. This is a very simple test that should pass
reliably before you try anything fancy like booting a payload.
--Ed
*
*
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
