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
*
*
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
