Hi,
I'm trying to adopt the AMD Quartet target to the new config scheme completely, but until now I failed when using the code I checked into CVS. The static tables and structures like the mem_controller cpu[] are twice as big as with the HDAMA most of the time, so the image does not fit in 64k anymore:
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: section .reset [00000000fffffff0 -> 00000000ffffffff] overlaps section .payload [00000000ffffb5b0 -> 00000001000008ca] /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: section .id [00000000ffffffd8 -> 00000000ffffffef] overlaps section .payload [00000000ffffb5b0 -> 00000001000008ca]
When I set the image size to 128k (ROM_IMAGE_SIZE), I get /home/stepan/LinuxBIOS/freebios2/src/cpu/i386/reset16.inc:16:3: #error _ROMBASE is an unsupported value
Is there any solution except stripping down?
Best regards, Stefan Reinauer
Stefan Reinauer stepan@suse.de writes:
Hi,
I'm trying to adopt the AMD Quartet target to the new config scheme completely, but until now I failed when using the code I checked into CVS. The static tables and structures like the mem_controller cpu[] are twice as big as with the HDAMA most of the time, so the image does not fit in 64k anymore:
Ouch.
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: section .reset [00000000fffffff0 -> 00000000ffffffff] overlaps section .payload [00000000ffffb5b0 -> 00000001000008ca] /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: section .id [00000000ffffffd8 -> 00000000ffffffef] overlaps section .payload [00000000ffffb5b0 -> 00000001000008ca]
When I set the image size to 128k (ROM_IMAGE_SIZE), I get /home/stepan/LinuxBIOS/freebios2/src/cpu/i386/reset16.inc:16:3: #error _ROMBASE is an unsupported value
Is there any solution except stripping down?
Fixing romcc so it does not inline everything.
There are a lot of good reasons for keeping LinuxBIOS within 64K. The two top ones are to limit code bloat and because startup is very tricky if you don't fit into 64K.
One thing you can look at is to strip down the debugging messages from the romcc code. That has at times made a large difference.
Eric
* Eric W. Biederman ebiederman@lnxi.com [030910 14:38]:
Is there any solution except stripping down?
Fixing romcc so it does not inline everything.
This sounds like it's going to be pretty complex
There are a lot of good reasons for keeping LinuxBIOS within 64K. The two top ones are to limit code bloat and because startup is very tricky if you don't fit into 64K.
ack
One thing you can look at is to strip down the debugging messages from the romcc code. That has at times made a large difference.
I got it compiling now with a log level of 7, but unfortunately it doesnt produce much output with that: LinuxBIOS-1.1.4.0Fallback Mit Sep 10 15:13:38 CEST 2003 starting...
LinuxBIOS-1.1.4.0Fallback Mit Sep 10 15:13:38 CEST 2003 starting...
Looks like it at least attempts to reset when doing ht init ... I'll switch as much debug on as possible again now..
Stefan
On Wed, 10 Sep 2003, Stefan Reinauer wrote:
I got it compiling now with a log level of 7, but unfortunately it doesnt produce much output with that: LinuxBIOS-1.1.4.0Fallback Mit Sep 10 15:13:38 CEST 2003 starting...
what are you trying to debug? What I've done is this:
set MAXIMUM_CONSOLE_LOGLEVEL and DEFAULT_CONSOLE_LOGLEVEL in auto.c directly, if that is where your trouble is. So leave them low in Config.lb, and in auto.c, set them high. Then things fit.
Mostly you need that high level in auto.c anyway, it's where all the problems will happen if you have any.
ron
On 10 Sep 2003, Eric W. Biederman wrote:
There are a lot of good reasons for keeping LinuxBIOS within 64K. The two top ones are to limit code bloat and because startup is very tricky if you don't fit into 64K.
true, but ... :-)
One thing you can look at is to strip down the debugging messages from the romcc code. That has at times made a large difference.
see if your auto.c has a high debug message level ... yes, this has helped me a lot.
ron
* ron minnich rminnich@lanl.gov [030910 16:32]:
One thing you can look at is to strip down the debugging messages from the romcc code. That has at times made a large difference.
see if your auto.c has a high debug message level ... yes, this has helped me a lot.
right.. i was stupid. The results are rather less good though.. Something seems to be severely wrong with the ht setup on quartet.
LinuxBIOS-1.1.4.0Fallback Mit Sep 10 17:08:05 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling SMP settings setup_remote_node setup_remote_done Renaming current temp node to 00000001 done. Enabling routing table for node 00000001 done. Renaming current temp node to 00000002
LinuxBIOS-1.1.4.0Fallback Mit Sep 10 17:08:05 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling SMP settings setup_remote_node
Stefan
Eric W. Biederman wrote:
startup is very tricky if you don't fit into 64K.
Maybe you can amplify on this. I can see it for older chipsets, but for modern ones, if we go into 32-bit mode immediately, why is this a problem?
-Steve
On Wed, 10 Sep 2003, Stefan Reinauer wrote:
Is there any solution except stripping down?
we need a way to set it up so the linuxbios compressed payload is BELOW linuxbios in memory.
That would buy a lot of room. I have not looked at this yet.
ron
-
ebiederman＠lnxi.com -
ron minnich -
Stefan Reinauer -
Steve Gehlbach