Am 30.07.2010 23:20, schrieb austinro(a)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.