[coreboot] EP80579 Mainboard support
arnaud.maye at 4dsp.com
Mon Jun 22 14:06:32 CEST 2009
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.
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
>> 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.
More information about the coreboot