Hello Gents,
So I've been able to confirm that the WDT is not related to this issue as indeed, changing the debug level to something smaller does not change anything to my problem.
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?
Anyone of you encountered this issue? I have searched for a bit on google, but not much I could find about this besides unanswered posts.
Any help would be greatly appreciated.
Arnaud
Myles Watson wrote:
I'm no expert on this board.
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 don't think so. This is a long time after RAM gets set up.
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 think more information here could be helpful.
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.
To see if the problem is the WDT, set the log level lower (less output) and see if it reboots at a different place. It will boot much faster with less output.
A last thing is a bit before in the log is the following :
...
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?
I think this line means that it's setting the option, so that when there is a power failure it will power back on. It doesn't mean that there's been a power failure.
Thanks, Myles
* *