Hi.
I have a Jetway 7F4K1G5S-LF board I'm trying to get working.
When I build coreboot using the J7f24 target, it doesn't get past "doing early_mtrr".
I added a few print statements (and included console.h) to try to track it down, and in "include/cpu/x86/cache.h" in disable_cache it will print the statement before
write_cr0(cr0);
but not the one after it. I don't know what to try next.
I'm doing this on a 32-bit sidux box, with gcc 4.4.4.
Any ideas?
Thanks,
Rob Austin
Am 30.07.2010 19:35, schrieb austinro@msu.edu:
I have a Jetway 7F4K1G5S-LF board I'm trying to get working.
Just to make things clear - that's a Via C7 board, yes?
Any ideas?
We moved the C7 boards over to CAR (cache as RAM), but couldn't test all of them (due to availability etc). Disabling cache before RAM is available (and all data structures, esp. the stack are moved to RAM) makes the system hang.
From looking at the board's romstage.c, it seems that early_mtrr_init is
ran before RAM init, but after CAR enable.
Do you get further after disabling early_mtrr_init (which disables caching to activate the new MTRR config) completely?
Regards, Patrick
Quoting Patrick Georgi patrick@georgi-clan.de:
Am 30.07.2010 19:35, schrieb austinro@msu.edu:
I have a Jetway 7F4K1G5S-LF board I'm trying to get working.
Just to make things clear - that's a Via C7 board, yes?
Yes.
Any ideas?
We moved the C7 boards over to CAR (cache as RAM), but couldn't test all of them (due to availability etc). Disabling cache before RAM is available (and all data structures, esp. the stack are moved to RAM) makes the system hang.
From looking at the board's romstage.c, it seems that early_mtrr_init is ran before RAM init, but after CAR enable.
Do you get further after disabling early_mtrr_init (which disables caching to activate the new MTRR config) completely?
Commenting out the call to early_mtrr_init() lets coreboot run to completion.
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")?
...
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.
(Thanks Patrick!)
On Fri, Jul 30, 2010 at 2:20 PM, austinro@msu.edu wrote:
Quoting Patrick Georgi patrick@georgi-clan.de:
Am 30.07.2010 19:35, schrieb austinro@msu.edu:
I have a Jetway 7F4K1G5S-LF board I'm trying to get working.
Just to make things clear - that's a Via C7 board, yes?
Yes.
Any ideas?
We moved the C7 boards over to CAR (cache as RAM), but couldn't test all of them (due to availability etc). Disabling cache before RAM is available (and all data structures, esp. the stack are moved to RAM) makes the system hang.
From looking at the board's romstage.c, it seems that early_mtrr_init is ran before RAM init, but after CAR enable.
Do you get further after disabling early_mtrr_init (which disables caching to activate the new MTRR config) completely?
Commenting out the call to early_mtrr_init() lets coreboot run to completion.
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")?
...
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.
Can you send me a boot log, with output level set to DEBUG or SPEW level?
Thanks, Corey
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
Patch attached to remove the call to early_mtrr_init(), provide a little more feedback on the amount of ram that's been found, and correct the ram initialization order and clarify a comment on an old hack. I don't have any hardware to test this patch on.
On Sat, Jul 31, 2010 at 1:33 AM, Patrick Georgi patrick@georgi-clan.de wrote:
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
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
austinro＠msu.edu -
Corey Osgood -
Patrick Georgi