[coreboot] coreboot halts at "doing early_mtrr"
patrick at georgi-clan.de
Sat Jul 31 07:33:37 CEST 2010
Am 30.07.2010 23:20, schrieb austinro at msu.edu:
> Commenting out the call to early_mtrr_init() lets coreboot run to
I suspect that call is a left-over from pre-CAR times on C7.
Please provide a patch. See
Do you need any more changes to get your board to run? After all, that's
a different board than listed by coreboot - it would be nice to support
your board explicitely, too.
> That's odd. I assumed the call to "write_cr0(cr0)" in cache.h was
> responsible somehow, since that was where it stopped when
> "early_mtrr_init" called "disable_cache", but I left the print
> statements in disable_cache, and they were all printed repeatedly this
> time, so "write_cr0" only causes a problem when called early (during
The problem is that write_cr0 is the function that actually disables the
While in early_mtrr_init, the only memory coreboot has to work in _is_
the cache (Cache as RAM configures the CPU to map the cache to some RAM
addresses and locks it to prevent eviction).
If you disable the cache at this point, there's no memory to use. In
particular, the stack is gone, so the next time a function is called or
left, the CPU doesn't know where to go.
On later occassions of disable_cache(), RAM is configured and used, so
disabling the cache merely slows the system down a bit, but doesn't
entirely prevent it from working.
> Tried it again and with memtest as the payload and it doesn't see any
> memory. Memtest pops up on the screen :
> L1 cache: 64K
> L2 cache: 128K
> L3 cache: none
> Memory : 0K
> (That last one is a zero K).
This might be a matter of issues with the various tables. The fact that
you can run up to memtest indicates that there _is_ RAM. :-)
For testing you could try to disable HAVE_HIGH_TABLES - if memtest works
then, your memtest doesn't know the forwarder entry we introduced last
year or so.
More information about the coreboot