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 Mayearnaud.maye@4dsp.com 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
* *