make the cache_as_ram_auto for init.o to use printk now,
#if CONFIG_USE_INIT printk_debug("linxbios_ram.bin length = %08x\r\n", olen); #else print_debug("linxbios_ram.bin length = "); print_debug_hex32(olen); print_debug("\r\n"); #endif
there is some space for optimize code for the raminit and ht init in auto ......
The 8 way system get most benefit from the cache-as-ram solution. 1. with romcc, the compile time may need 5 minutes and can not enable vga support 2. win cache as ram and gcc, compile only need 23 seconds. ( the same as four way and two way), and vga support is already enabled.
the system with multi CK804 as slaves can get some benefits too.
YH
-----Original Message----- From: YhLu Sent: Tuesday, June 14, 2005 4:58 PM To: Ronald G. Minnich; Eric W. Biederman; 'Stefan Reinauer'; Li-Ta Lo Cc: LinuxBIOS Subject: RE: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram.
AMD cache_as_ram first stage done.
current status
- use gcc to produce auto.inc or init.o 2. it can reboot in
fallback 3. it can reboot from fallback to normal 4. it can reboot in normal....
I'm using auto.c for romcc version cache_as_ram_auto.c for gcc and via auto.inc version cache_as_ram_auto.c for gcc and via init.o version
next stage:
- convert cache_as_ram_init.c version.
- it will use the printk_debug to substitue print_debug 3.
create compressed init.o version???? could spare 10k bytes....
YH
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
Ron,
It turns out that Cache as Ram can work in intel xeon too. The only difference is AMD need to set some bits in SYSCFG_MSR.
So final cache as ram support for x86 will be cpu/x86/car/cache_as_ram.inc cpu/x86/car/cache_as_ram_post.c cpu/x86/car/copy_and_run.c
there is special version for AMD cpu/amd/car/cache_as_ram.inc cpu/amd/car/cache_as_ram_post.c
in MB dir cache_as_ram_auto.c it will include old failover.c and auto.c and corresponding cache_as_ram_post.c and copy_and_run.c
the cache_as_ram_post.c will stop the cache as ram and switch to ram stack. copy_and_run will decode linuxbios_ram to memory, and jmp to it.
USE_DCACHE_RAM ---> use romcc or gcc for auto.c... CONFIG_USE_INIT ----> use init or not.
the code can coexist with romcc .....
If it is ok, I will check in cache as ram support for s2735 and s2885/s2891/s2895 tomorrow.
Also I would help to verify that on other x86 platform.
YH
yhlu yinghailu@gmail.com writes:
Ron,
It turns out that Cache as Ram can work in intel xeon too. The only difference is AMD need to set some bits in SYSCFG_MSR.
So final cache as ram support for x86 will be cpu/x86/car/cache_as_ram.inc cpu/x86/car/cache_as_ram_post.c cpu/x86/car/copy_and_run.c
We may have something here, especially code to do the copy once the are is initialized but this can never be completely generic.
there is special version for AMD cpu/amd/car/cache_as_ram.inc cpu/amd/car/cache_as_ram_post.c
in MB dir cache_as_ram_auto.c it will include old failover.c and auto.c and corresponding cache_as_ram_post.c and copy_and_run.c
the cache_as_ram_post.c will stop the cache as ram and switch to ram stack. copy_and_run will decode linuxbios_ram to memory, and jmp to it.
USE_DCACHE_RAM ---> use romcc or gcc for auto.c... CONFIG_USE_INIT ----> use init or not.
the code can coexist with romcc .....
Cool.
If it is ok, I will check in cache as ram support for s2735 and s2885/s2891/s2895 tomorrow.
Also I would help to verify that on other x86 platform.
If it's not intrusive I don't mind. But in general for developments like this I would like to put the code on a branch in the public tree first before merging it. That way multiple people can look at and test the code before it merges and potentially breaks something.
I'm probably the worst offender though :) So Ron if someone wants to remind me later...
Eric