eric's line is
diff -r freebios_lnxi/src/arch/i386/init/ldscript.lb ../freebios2/src/arch/i386/init/ldscript.lb 45,49d44 < /* Move up the location counter if the start of the rom section is < * too low. < */ < . = ( ( ( _ROMBASE + ROM_IMAGE_SIZE - 1 ) == 0xffffffff ) && ( . < 0xffff0000 ) ) ? 0xffff0000 : . ; <
On 6/27/05, yhlu yinghailu@gmail.com wrote:
There is two case
- auto.inc create by romcc is very big (because no call in romcc allowed), So entry32.inc+fallback.inc+auto.inc+c_start.S will be bigger than
64k, the _start in entry32.inc will lower than 0xffff0000, that is not allowd because some SB only allow 64k in ROM can be accessed. 2. Current linuxbios_ram.rom + linuxbios_rom.rom could be greater 0x64k, some time if you set ROM_IMAGE_SIZE too big, and linuxbios_ram.rom is not bigger enough, it will _start in entry32.inc lower than 0xffff0000. That is more easy happen when you are trying to enable VGA CONSOLE so increase the value, but when you disable that and forget change ROM_IMAGE_SIZE back.
Solution will be for 2. Eric added one line in ldsripts.lds to force linuxbios_rom.rom start only from 0xffff0000, if the ROM_IMAGE_SIZE is set to big.
for 1. esp for four way and 8 way system, my solution is auto.inc+(jmp to c_start.s)+entry32.inc+fallback.inc+(jmp to auto.c)+c_start.S So we can keep _start in entry32.inc still high than 0xffff0000. and fallback.inc will enable the 4M space from ROM access. You can not together 1 with 2 solution.
Fortunely, when using cache_as_ram, even enable every debug info and in 8 way system, the entry32.inc+auto.c+c_start.s (inc mode) and init mode will never be great than 64k bytes. So we can put eric's line in ldsscript.lds. but if someone still like romcc for four way and 8 way system you need to remove that line.
Hope it is clear enough.
YH
On 6/27/05, Ronald G. Minnich rminnich@lanl.gov wrote:
On Mon, 27 Jun 2005, Steve Magnani wrote:
On an editorial note, it's nice that the build system catches this problem, but I really wish it did it in a way that made it more obvious what the problem is.
you are absolutely right. This is on a list of things we are fixing this summer.
ron
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios