RE: fallback reset_vector offset
Yes the posion in rom Linbios_ram.rom auto.c entry failover reset_vector just need to make sure entry/failover is in 64k limit. So enable_rom in failover can be executed. YH > Progress however unless I am mistaken this will fail > miserably on an 8111 that only enables 64KiB of ROM by default. > > I think all of failover.c needs to be put in the magic > position, if we are going to allow arbitrary memory size code. > > Eric > ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback reset_vector offset
YhLu <[EMAIL PROTECTED]> writes: > The problem solved. > > I switch the auto.c... before reset.inc in MB Config.lb > > Also add two inc in it > > mainboardinit arch/i386/lib/jmp_auto_out.inc > after auto.c segment > > mainboardinit arch/i386/lib/jmp_auto.inc > in old auto.c position > > please advise where to put these two inc. > > jmp_auto_out.inc > /* -*- asm -*- */ > > /* clear boot_complete flag */ > xorl%ebp, %ebp > jmp __main > > jmp_auto.inc > > /* -*- asm -*- */ > jmp __fpu_start Progress however unless I am mistaken this will fail miserably on an 8111 that only enables 64KiB of ROM by default. I think all of failover.c needs to be put in the magic position, if we are going to allow arbitrary memory size code. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
RE: fallback reset_vector offset
The problem solved. I switch the auto.c... before reset.inc in MB Config.lb Also add two inc in it mainboardinit arch/i386/lib/jmp_auto_out.inc after auto.c segment mainboardinit arch/i386/lib/jmp_auto.inc in old auto.c position please advise where to put these two inc. jmp_auto_out.inc /* -*- asm -*- */ /* clear boot_complete flag */ xorl%ebp, %ebp jmp __main jmp_auto.inc /* -*- asm -*- */ jmp __fpu_start YH > -Original Message- > From: ebiederman@lnxi.com [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 25, 2005 12:31 AM > To: YhLu > Cc: Ronald G. Minnich; linuxbios@clustermatic.org > Subject: Re: fallback reset_vector offset > > YhLu <[EMAIL PROTECTED]> writes: > > > in reset16.lds > > > > _ROMTOP = (_start >= 0x) ? 0xfff0 : 0x8; > > > > > > 0x8 ? > > And from the line above. > /* Trigger an error if I have an unuseable start > address */ That is exactly what happens correct? 0xfff8 > does not work does it? > > Show me a less confusing way and I will use it. > > Eric > ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
RE: fallback reset_vector offset
I mean 0x8 is 36 bit. and the ld will take 0x. YH > -Original Message- > From: ebiederman@lnxi.com [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 25, 2005 12:31 AM > To: YhLu > Cc: Ronald G. Minnich; linuxbios@clustermatic.org > Subject: Re: fallback reset_vector offset > > YhLu <[EMAIL PROTECTED]> writes: > > > in reset16.lds > > > > _ROMTOP = (_start >= 0x) ? 0xfff0 : 0x8; > > > > > > 0x8 ? > > And from the line above. > /* Trigger an error if I have an unuseable start > address */ That is exactly what happens correct? 0xfff8 > does not work does it? > > Show me a less confusing way and I will use it. > > Eric > ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
RE: fallback reset_vector offset
Thanks. I found the reason. the crt0.s (from reset16.failoverauto...) is too big. So the _start is across the 0x. unless move reset16 and entry16 near reset_vector. We have to make crt0.s is in 64K. the linuxbios_ram.rom could cross the 64K limit above the crt0.s YH > -Original Message- > From: Ronald G. Minnich [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 25, 2005 7:40 AM > To: YhLu > Cc: linuxbios@clustermatic.org > Subject: Re: fallback reset_vector offset > > send me the config file you are using. This is weird. > > ron > ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback reset_vector offset
send me the config file you are using. This is weird. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback reset_vector offset
YhLu <[EMAIL PROTECTED]> writes: > in reset16.lds > > _ROMTOP = (_start >= 0x) ? 0xfff0 : 0x8; > > > 0x8 ? And from the line above. /* Trigger an error if I have an unuseable start address */ That is exactly what happens correct? 0xfff8 does not work does it? Show me a less confusing way and I will use it. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
RE: fallback reset_vector offset
in reset16.lds _ROMTOP = (_start >= 0x) ? 0xfff0 : 0x8; 0x8 ? ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
RE: fallback reset_vector offset
you are right. in linuxbios.map _start become to 0xfffeeecc and ROM_TOP and reset_vector become to 0xfff. YH ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback reset_vector offset
YhLu <[EMAIL PROTECTED]> writes: > sometime the linuxbios.strip for fallback reset_vector will have 15 more > offset. > > here I set ROM_IMAGE_SIZE 0x19200, and the linuxbios.strip will be 15 bytes > longer. weird? > > 00191f0: e900 > 0019200: eeca fffe e900 ef18 fffe You are probably exceeding the 64K jump limit, to the start of the romcc code. I trigger a very weird ld case when that happens so the code will not compile. It was the best I could do. If you want to look at what it would take to arbitrarily relax that limit be my guest. If I could get a linker section to allocate space backwards this would be trivial to fix, as it is... Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
