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 :
TC Init PNP: 004e.4 init PNP: 004e.5 init PCI: 00:1f.2 init SATA init SATA Enabled PCI: 00:1f.4 init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor Intel device 10650 CPU: family 06, model 15, stepping 00 Enabling cache
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 much differences.
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 which BSEL/VSEL 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 :
Initializing devices... 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 RTC Init
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,
Arnaud
Ed Swierk wrote:
On Tue, Jun 16, 2009 at 7:24 AM, Arnaud Mayearnaud.maye@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.
--Ed
* *