[coreboot] EP80579 Mainboard support
arnaud.maye at 4dsp.com
Fri Jun 19 15:03:52 CEST 2009
Hello Again ED and others.
I've been able to go further but still a few strange things I am seeing.
This is the last part of my log :
PNP: 004e.4 init
PNP: 004e.5 init
PCI: 00:1f.2 init
PCI: 00:1f.4 init
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Intel device 10650
CPU: family 06, model 15, stepping 00
Setting fixed MTRRs(0-88) Type: UC
After this either it hang or jump back to "Uncompressing coreboot to
RAM" and then hang. It can as
well loop "Uncompressing coreboot to RAM".
Could it still be related to wrong timing value set on the memory
controller? I doubt about this because
I have tried a lot of different DIMMs as well but the result same.
Memory can be ECC or not, not
I've tried both FSB (400 and 533MHz) and both SKU ( 600 and 1200MHz
(forced to 1060 as well).
What I can say as well is that depending where the PCIe GFX card is
connected the boot process
is very unstable. I know the build does not even use GFX output.
Connecting the GFX card on the
x16 PCIe slot is the more stable vector. By more stable I mean no
strange unhandled exceptions.
I was trying to find in the sources where the hardware watchdog timer is
enabled or disabled. Am not
sure if this is something you have been taking care about during your
dev or not, did you enable and
set a value in the WDT or not.
Could you let as well which SKU you have been using, the 600 or 1200 and
jumper selection you have on your board.
I would say that this is not related to the memory controller,
especially because several FSB speeds,
processor speed and memory speed does not make much difference.
The ep80579 raminit source file does write a "magic" value to the BUS0,
DEV8 and FN 0 to the
register 0xCC. Higher the DDR frequency is, higher the "magic" value is.
I could not find anywhere
in the EP80579 datasheet what is this "magic" peripheral.
A last thing is a bit before in the log is the following :
Root Device init
PCI: 00:00.0 init
PCI: 00:00.1 init
PCI: 00:01.0 init
PCI: 00:1d.0 init
PCI: 00:1d.7 init
PCI: 00:1f.0 init
set power on after power fail
The power did not fail, the voltage did not even drop, I've been
measuring this with an oscilloscope
in here. Is it expected?
Probably a lot of people around here might answer these questions, if
so, feel free to do so!
With my best regards,
Ed Swierk wrote:
> On Tue, Jun 16, 2009 at 7:24 AM, Arnaud Maye<arnaud.maye at 4dsp.com> wrote:
>> I've just received my UART dongle and I could see that indeed something has
>> been sent over UART.
>> The first error seen was about the fact only ECC DIMMs are allowed, in the
>> devkit they provide
>> non-ecc memory. Is it normal coreboot only supports ECC DIMMs?
> No, but I never got around to implementing support for non-ECC DIMMs
> in the EP80579 raminit code. It shouldn't be too hard--I think you
> just need to note whether the DIMMs are ECC, and refrain from enabling
> ECC mode if they are. (You may want to keep ECC disabled anyway during
> debugging; until the DRAM is stable, ECC only makes the error behavior
> more complicated.)
>> I've then plugged some nice kingston DIMM with ecc and what I get then is an
>> exception :
>> Unexpected Exception: 13 @ 10:00002f08 - Halting
>> Code: 4096 eflags: 00010282
>> eax: 002163b6 ebx: 0000c000 ecx: 0000227e edx: fffffffe
>> edi: 0000eb02 esi: 0000f444 ebp: 0000bebc esp: 0000bebc
>> As soon I get this exception, the 7 segments display : FF
>> I guess if this is the first thing I get, coreboot has a problem not the
>> payload, right?
>> Could you tell me which coreboot version from the 1.3 tree you have been
>> using when you
>> validated the port?
> I did the work somewhere around revision 3650 of the coreboot-v2 tree.
> However, I tested only a very limited number of DIMMs, and only at 667
> speed, so I'm not surprised a random one doesn't work. Unfortunately
> there's no substitute for spending some quality time with the
> datasheet, beating the raminit settings into submission.
More information about the coreboot