I ran into something like this not long ago. It might be that _start is too far away from the top of memory. Try editing src/cpu/x86/16bit/reset16.lds and change this:
_ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xffffffff8;
to this:
_ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xffffffff0;
Then re-build. If it builds successfully, that's the problem, and you'll have to juggle your code or reduce it so that _start ends up at 0xFFFF0000 or greater.
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.
Steve
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
There is two case 1. 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
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
eric line in reset16.lds diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds ../freebios2/src/cpu/x86/16bit/reset16.lds 8,9c8 < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please decrease ROM_IMAGE_SIZE"); < _ROMTOP = 0xfffffff0; ---
_ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8;
So i suggest we put the line in reset16.lds and dont accept the line in ldscript.lb
YH
On 6/27/05, yhlu yinghailu@gmail.com wrote:
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
On Mon, 27 Jun 2005, yhlu wrote:
eric line in reset16.lds diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds ../freebios2/src/cpu/x86/16bit/reset16.lds 8,9c8 < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please decrease ROM_IMAGE_SIZE");
< _ROMTOP = 0xfffffff0;
_ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8;So i suggest we put the line in reset16.lds and dont accept the line in ldscript.lb
at best this is a temporary fix. Putting computations into the ldscript is going to cause us trouble later.
ron
long term solution will depend still using romcc for 4 way and 8 way Opteron system?, if we are using cache_as_ram we don't have a chance to make entry32.inc+auto.inc+crt0.S bigger than 64K.
or we reorginze the map to linuxbios_ram auto.inc -->init section ----> it will jmp to linuxbios_ram entry32.inc+fallback.inc----> it will call real_main at last
problem is to make use gcc to produce auto.inc and avoid the duplicate Label problm, i already merge auto.c and failback.c into cache_as_ram.c
YH
On 6/27/05, Ronald G. Minnich rminnich@lanl.gov wrote:
On Mon, 27 Jun 2005, yhlu wrote:
eric line in reset16.lds diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds ../freebios2/src/cpu/x86/16bit/reset16.lds 8,9c8 < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please decrease ROM_IMAGE_SIZE");
< _ROMTOP = 0xfffffff0;
_ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8;So i suggest we put the line in reset16.lds and dont accept the line in ldscript.lb
at best this is a temporary fix. Putting computations into the ldscript is going to cause us trouble later.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Mon, 27 Jun 2005, yhlu wrote:
eric line in reset16.lds diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds ../freebios2/src/cpu/x86/16bit/reset16.lds 8,9c8 < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please decrease ROM_IMAGE_SIZE");
< _ROMTOP = 0xfffffff0;
_ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8;So i suggest we put the line in reset16.lds and dont accept the line in ldscript.lb
at best this is a temporary fix. Putting computations into the ldscript is going to cause us trouble later.
Ron it sounds like you have an idea in mind, could you elaborate.
Currently all I am computing are things that the linker needs to deal with. The selection of addresses of specific files.
The ASSERT is especially useful as it turns a very mysterious error message into something readable and comprehensible. It is weird that you have to assign ASSERT to a variable to have the declaration work in nested linker scripts but hey it works.
Eric
-
ebiederman＠lnxi.com -
Ronald G. Minnich -
Steve Magnani -
yhlu