YES
LinuxBIOS-1.1.8_s2891_Fallback Fri Jun 10 22:56:51 PDT 2005 starting... (0,1) link=01 (1,0) link=00 02 nodes initialized. SBLink=00 NC node|link=00 NC node|link=02 busn=06 ht reset -
LinuxBIOS-1.1.8_s2891_Fallback Fri Jun 10 22:56:51 PDT 2005 starting... (0,1) link=01 (1,0) link=00 02 nodes initialized. SBLink=00 NC node|link=00 NC node|link=02 busn=06 SMBus controller enabled Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Ram4 Clearing initial memory region: No cache as ram now - Use Ram as Stack now -
-----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Friday, June 10, 2005 10:58 PM To: yhlu Cc: Eric W. Biederman; YhLu; Ronald G. Minnich; Stefan Reinauer; LinuxBIOS Subject: Re: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram.
On Fri, 2005-06-10 at 09:26 -0700, yhlu wrote:
On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman
Potentially. It might simply be that we are
reprogramming top_mem
or the iorrs to define what memory is and messing up the early definition.
It seems top_mem....I will double check that.
The trivial way is to include an asm directive at the beginning. I had actually expected to use something like the init directive that is used on the PPC, and let gcc generate the .o
files. At that
point a trivial linker script could place everything in .rom.text and .rom.data if needed.
That could be next step, in asm make it more easier to debug. Current I could not get out of auto.c, I guess i will 1. change cache_lbmem in raminit.c to 512k only 2. covert copy or decode in crt0.S to c and call directly after ram is initialized. 3. use init.o like Ollie wanted....and change to use new
print_debug
to printk_debug....
p.s.
Anyone know why I did not receive a copy of this message on the mailing list?
Stefan must leave your out of linuxbios list in openbios...
Did you do HT reset after CAR but before DRAM? In my old implementation, HT reset will mess up CAR.
-- Li-Ta Lo ollie@lanl.gov Los Alamos National Lab