[coreboot] EP80579 Mainboard support

[Arnaud Maye]

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<arnaud.maye at 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
>
>   

*
*