Am 30.07.2010 23:20, schrieb austinro@msu.edu:
Commenting out the call to early_mtrr_init() lets coreboot run to completion.
I suspect that call is a left-over from pre-CAR times on C7.
Please provide a patch. See http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for our rules.
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 "early_mtrr_init")?
The problem is that write_cr0 is the function that actually disables the cache. 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).
Hmmm.
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.
Patrick