I'm trying to enable the CAR for opteron.
1. create failover.inc and auto.inc with gcc -S 2. change the label in failover.inc from .L --> .fL 3. change section name in failover.inc and auto.c .text --> .rom.text .rodata--> .rom.data .rodata.str...-> .rom.data.str... 4. using following cache_as_ram.inc, and it will be executed after entry.inc at last it will call amd64 in failover.inc or auto.inc 5. current it will die after post code 0x22
I wonder how to make the cpu using the stack in cache....
movl $(CacheBase>>4), %eax movl %eax, %ss
is enough?
Also how to using gcc parammetor to do 2, and 3....
YH
/* cache_as_ram.c */ #define CacheBase 0x60000
#include <cpu/x86/mtrr.h> #include <cpu/amd/mtrr.h>
/* Save the BIST result */ movl %eax, %ebp
CacheAsRam:
xorl %eax, %eax # clear %eax and %edx xorl %edx, %edx # movl $fixed_mtrr_msr, %esi
enable_fixed_mtrr_dram_modify: movl $SYSCFG_MSR, %ecx rdmsr orl $SYSCFG_MSR_MtrrFixDramModEn, %eax wrmsr
/*Clear all MTRRs */ clear_fixed_var_mtrr: lodsl (%esi), %eax testl %eax, %eax jz clear_fixed_var_mtrr_out
movl %eax, %ecx xorl %eax, %eax wrmsr
jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out:
/* enable mtrr dram enable */ enable_fixed_var_mtrr_dram: movl $SYSCFG_MSR, %ecx rdmsr orl $(7<<18), %eax wrmsr
/* enable caching for 64K using variable mtrr */ movl $0x200, %ecx xorl %edx, %edx movl $(CacheBase | MTRR_TYPE_WRBACK), %eax wrmsr
movl $0x201, %ecx movl $0x000000ff, %edx # AMD 40 bit movl $((~((CacheBase + 0x10000) - 1)) | 0x800), %eax wrmsr
/* make it to be IO by clearing RD Dram and WR Dram */ movl $IORR0_BASE, %ecx xorl %edx, %edx movl $CacheBase, %eax # bit 3, and bit = 0 mean clear RD ram and ER ram wrmsr
movl $IORR0_MASK, %ecx movl $0x000000ff, %edx movl $(~((CacheBase + 0x10000) - 1) | 0x800), %eax wrmsr
/* enable cache */ movl %cr0, %eax andl $0x9fffffff,%eax movl %eax, %cr0
intel_chip_post_macro(0x21) /* post 21 */ #if 1 /* we zerod it above */ /* consistency: clear stack */ movl $(CacheBase+0x5000), %edi movl $0x100, %ecx xorl %eax, %eax rep stosl #endif
intel_chip_post_macro(0x22) /* post 22 */
// movl $(CacheBase+0x10000-4), %esp movl $(CacheBase>>4), %eax movl %eax, %ss
/* Load a different set of data segments */ #if 0 movw $CACHE_RAM_DATA_SEG, %ax movw %ax, %ds movw %ax, %es movw %ax, %ss #endif
lout: /* Restore the BIST result */ movl %ebp, %eax jmp _start_init
fixed_mtrr_msr: .long 0x250, 0x258, 0x259 .long 0x268, 0x269, 0x26A .long 0x26B, 0x26C, 0x26D .long 0x26E, 0x26F var_mtrr_msr: .long 0x200, 0x201, 0x202, 0x203 .long 0x204, 0x205, 0x206, 0x207 .long 0x208, 0x209, 0x20A, 0x20B .long 0x20C, 0x20D, 0x20E, 0x20F var_iorr_msr: .long 0xC0010016, 0xC0010017, 0xC0010018, 0xC0010019 mem_top: .long 0xC001001A, 0xC001001D .long 0x000 /* NULL, end of table */ _start_init: cli
intel_chip_post_macro(0x23) /* post 23 */ call amd64_main intel_chip_post_macro(0x24) /* post 24 */
I just figure out, the ss don't need to be changed. and only need to set the esp.
It can get into amd64_main in failover.
the it seems even the 64 range in cache can be read and write, but the result is not right. It means when clear all of range, the readout will still be 0xff....
#if 1 movl $CacheBase, %edi cld movl $04000, %ecx xorl %eax, %eax rep stosl #endif movl $CacheBase, %esi movl (%esi), %eax .testx: outb %al, $0x80 jmp .testx
intel_chip_post_macro(0x22) /* post 22 */
Ollie, are you sure that your code can use 300 bytes in cache?
YH
On Mon, 2005-06-06 at 21:02 -0700, yhlu wrote:
I just figure out, the ss don't need to be changed. and only need to set the esp.
It can get into amd64_main in failover.
the it seems even the 64 range in cache can be read and write, but the result is not right. It means when clear all of range, the readout will still be 0xff....
#if 1 movl $CacheBase, %edi cld movl $04000, %ecx xorl %eax, %eax rep stosl #endif movl $CacheBase, %esi movl (%esi), %eax .testx: outb %al, $0x80 jmp .testx
intel_chip_post_macro(0x22) /* post 22 */
The AMD doc says you have to use REP MOVS to read from IO space. It looks like you are using REP STOS.
Ollie, are you sure that your code can use 300 bytes in cache?
Yea, I am sure it uses less than 448 bytes.
You didn't reuse the ldscript and .inc files in the .tgz I sent, right?
YH
448 bytes should be enough, the first 448 or last 448 in 64k range.
I tried your code it doesn't work too.
The reason for using auto.inc and failover.inc, i don't want to set cs, ds, es....second time. Also I wonder it will need go back to crt0.s to start from __main ...
YH
Some good news,
it die at "Clearing initial memory region: ", I guess some code that enable mtrr or cache in raminit.c need to move out .c and put into crt0.S directly.
Another question: Now the auto.inc is generated with gcc, the problem there should some way to modify section name. i mean .text ---> .section .rom.text .section .rodat ---> .section .rom.data
If the gcc can not do that, any one can tell me how to do that via perl or python....
YH
LinuxBIOS-1.1.8_s2891_Fallback Thu Jun 9 18:03:24 PDT 2005 starting... 02 nodes initialized. ht reset -
LinuxBIOS-1.1.8_s2891_Fallback Thu Jun 9 18:03:24 PDT 2005 starting... 02 nodes initialized. SMBus controller enabled Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Clearing initial memory region:
Some good news,
it die at "Clearing initial memory region: ", I guess some code that enable mtrr or cache in raminit.c need to move out .c and put into crt0.S directly.
Another question: Now the auto.inc is generated with gcc, the problem there should some way to modify section name. i mean .text ---> .section .rom.text .section .rodat ---> .section .rom.data
If the gcc can not do that, any one can tell me how to do that via perl or python....
Are you using inline asm in gcc code? What is your asm in C looks like? You can still use .section directive in the inline asm AFIAK.
Ollie
"Li-Ta Lo" ollie@lanl.gov writes:
Are you using inline asm in gcc code? What is your asm in C looks like? You can still use .section directive in the inline asm AFIAK.
You can and you can even explicitly tell gcc the section. The problem is that you have to tell gcc everywhere...
Eric
yhlu yinghailu@gmail.com writes:
Some good news,
it die at "Clearing initial memory region: ", I guess some code that enable mtrr or cache in raminit.c need to move out .c and put into crt0.S directly.
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.
Another question: Now the auto.inc is generated with gcc, the problem there should some way to modify section name. i mean .text ---> .section .rom.text .section .rodat ---> .section .rom.data
If the gcc can not do that, any one can tell me how to do that via perl or python....
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.
Eric
p.s.
Anyone know why I did not receive a copy of this message on the mailing list?
p.p.s.
YH I just got a look at your auto routing hypertransport code and while it looks to be a good step in the right direction I had always imagined topology discovery in there. More tommorrow after I have slept.
Eric
On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman ebiederman@lnxi.com
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...
YH
On Fri, Jun 10, 2005 at 09:26:27AM -0700, yhlu wrote:
On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman ebiederman@lnxi.com
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...
This is an option in Mailman, the same thing happened to me and I also want the message from the list. Enter subscribed email address and password on http://www.openbios.org/mailman/options/linuxbios/ and down at the bottom of the page select No for the "Avoid duplicate copies of messages?" option. I also like to disable the password reminder a few options up.
//Peter
On Fri, Jun 10, 2005 at 08:16:12PM +0200, Peter Stuge wrote:
also want the message from the list. Enter subscribed email address and password on http://www.openbios.org/mailman/options/linuxbios/ and down at the bottom of the page select No for the "Avoid duplicate
^ - next
Must log in first to show the options page, sorry, could have been clearer.
//Peter
On Fri, 2005-06-10 at 09:26 -0700, yhlu wrote:
On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman ebiederman@lnxi.com
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
- change cache_lbmem in raminit.c to 512k only
- 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.
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Peter Stuge -
YhLu -
yhlu