All,
When building SeaBIOS in the context of QEMU v2.3-rc0 using various openSUSE versions we found that some recent versions overflowed the 128K limit imposed for bios.bin. The Makefile fails with the suggestion of using a more recent toolset or of eliminating some features to make it fit. Neither of those are options in this case.
Of course another option is to review the code for places where variables or strings can be reduced in size without changing functionality. That doesn't buy us all that much, but enough for all of our cases except the oldest toolset. I'll post the patches I came up with during this review of the SeaBIOS code shortly to see what people think.
The 128K bios.bin needed by older QEMU machine types doesn't need new functionality, but some future SeaBIOS changes will undoubtedly still cause it to continue to grow a bit. Since we are right at the boundary of overflowing 128K, I thought it was worth investing some effort in backing away from that limit so we don't have to constantly worry about every small change causing an issue there.
In addition to the above mentioned data size reductions, another thing I noticed was that the e820 array is 32 entries, as given by BUILD_MAX_E820. It appears that QEMU only will ever fill 16 of those entries, so perhaps it would make sense to reduce that size when the usage is for QEMU only.
As a more general query, I was wondering if anyone else knew of places where the size of SeaBIOS could be reduced? I'd be happy to try to help make that happen.
Thanks,
Bruce Rogers
On Tue, Mar 24, 2015 at 10:22:13AM -0600, Bruce Rogers wrote:
All,
When building SeaBIOS in the context of QEMU v2.3-rc0 using various openSUSE versions we found that some recent versions overflowed the 128K limit imposed for bios.bin. The Makefile fails with the suggestion of using a more recent toolset or of eliminating some features to make it fit. Neither of those are options in this case.
The 128K build should only be needed with older machine types on QEMU, and one should be able to compile without all the hardware device drivers there.
Of course another option is to review the code for places where variables or strings can be reduced in size without changing functionality. That doesn't buy us all that much, but enough for all of our cases except the oldest toolset. I'll post the patches I came up with during this review of the SeaBIOS code shortly to see what people think.
The 128K bios.bin needed by older QEMU machine types doesn't need new functionality, but some future SeaBIOS changes will undoubtedly still cause it to continue to grow a bit. Since we are right at the boundary of overflowing 128K, I thought it was worth investing some effort in backing away from that limit so we don't have to constantly worry about every small change causing an issue there.
In addition to the above mentioned data size reductions, another thing I noticed was that the e820 array is 32 entries, as given by BUILD_MAX_E820. It appears that QEMU only will ever fill 16 of those entries, so perhaps it would make sense to reduce that size when the usage is for QEMU only.
As a more general query, I was wondering if anyone else knew of places where the size of SeaBIOS could be reduced? I'd be happy to try to help make that happen.
There are a few areas I'm aware of:
- go to 32bit only hardware drivers - see https://github.com/KevinOConnor/seabios/tree/testing-32bit-drivers right now many hardware drivers are compiled in both 16bit mode and 32bit mode, so compiling them only in 32bit mode is a notable size reduction. Unfortunately, it causes compatibility problems for really old DOS-era programs (emm386). There is an SMI handler to work around this, but it's only supported on QEMU TCG (not coreboot, csm, or kvm).
- string merging between modes. Right now, if a string is used in both 16bit mode and 32bit mode, it is copied into the final binary twice, but they could share the same copy. I haven't figured out a way to get the linker to do this though.
- reducing debugging strings on failure paths. There are a lot of places where a custom debug message is outputted on rare failure paths. It should be possible to replace a number of these locations with warn_internal_error(), warn_noalloc(), warn_timeout() etc. (Reducing code size is the reason for these warn_xxx() functions.)
- increase the debug level of many dprintf calls. There is no standard for what log level to use in dprintf calls, and it would probably be good to have a standard. I suspect a number of calls could be moved out of the default debug level of 1.
- it may be possible to avoid using space for bss variables in the rom. I suspect this is too complex to be worthwhile though.
-Kevin
On 3/24/2015 at 11:50 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Tue, Mar 24, 2015 at 10:22:13AM -0600, Bruce Rogers wrote:
All,
When building SeaBIOS in the context of QEMU v2.3-rc0 using various openSUSE versions we found that some recent versions overflowed the 128K limit imposed for bios.bin. The Makefile fails with the suggestion of using a more recent toolset or of eliminating some features to make it fit. Neither of those are options in this case.
The 128K build should only be needed with older machine types on QEMU, and one should be able to compile without all the hardware device drivers there.
Of course another option is to review the code for places where variables or strings can be reduced in size without changing functionality. That doesn't buy us all that much, but enough for all of our cases except the oldest toolset. I'll post the patches I came up with during this review of the SeaBIOS code shortly to see what people think.
The 128K bios.bin needed by older QEMU machine types doesn't need new functionality, but some future SeaBIOS changes will undoubtedly still cause it to continue to grow a bit. Since we are right at the boundary of overflowing 128K, I thought it was worth investing some effort in backing away from that limit so we don't have to constantly worry about every small change causing an issue there.
In addition to the above mentioned data size reductions, another thing I noticed was that the e820 array is 32 entries, as given by BUILD_MAX_E820. It appears that QEMU only will ever fill 16 of those entries, so perhaps it would make sense to reduce that size when the usage is for QEMU only.
As a more general query, I was wondering if anyone else knew of places where the size of SeaBIOS could be reduced? I'd be happy to try to help make that happen.
There are a few areas I'm aware of:
go to 32bit only hardware drivers - see https://github.com/KevinOConnor/seabios/tree/testing-32bit-drivers right now many hardware drivers are compiled in both 16bit mode and 32bit mode, so compiling them only in 32bit mode is a notable size reduction. Unfortunately, it causes compatibility problems for really old DOS-era programs (emm386). There is an SMI handler to work around this, but it's only supported on QEMU TCG (not coreboot, csm, or kvm).
string merging between modes. Right now, if a string is used in both 16bit mode and 32bit mode, it is copied into the final binary twice, but they could share the same copy. I haven't figured out a way to get the linker to do this though.
reducing debugging strings on failure paths. There are a lot of places where a custom debug message is outputted on rare failure paths. It should be possible to replace a number of these locations with warn_internal_error(), warn_noalloc(), warn_timeout() etc. (Reducing code size is the reason for these warn_xxx() functions.)
increase the debug level of many dprintf calls. There is no standard for what log level to use in dprintf calls, and it would probably be good to have a standard. I suspect a number of calls could be moved out of the default debug level of 1.
it may be possible to avoid using space for bss variables in the rom. I suspect this is too complex to be worthwhile though.
-Kevin
Thanks, I'll look into these.
Bruce
On 24/03/2015 17:22, Bruce Rogers wrote:
All,
When building SeaBIOS in the context of QEMU v2.3-rc0 using various openSUSE versions we found that some recent versions overflowed the 128K limit imposed for bios.bin. The Makefile fails with the suggestion of using a more recent toolset or of eliminating some features to make it fit. Neither of those are options in this case.
This is the Fedora config file for 128K:
CONFIG_QEMU=y CONFIG_ROM_SIZE=128 CONFIG_XEN=n CONFIG_USB_XHCI=n CONFIG_USB_UAS=n
An alternative is to leave in XHCI and UAS, and disable CONFIG_PVSCSI, CONFIG_ESP_SCSI and CONFIG_LSI_SCSI.
Paolo
Of course another option is to review the code for places where variables or strings can be reduced in size without changing functionality. That doesn't buy us all that much, but enough for all of our cases except the oldest toolset. I'll post the patches I came up with during this review of the SeaBIOS code shortly to see what people think.
The 128K bios.bin needed by older QEMU machine types doesn't need new functionality, but some future SeaBIOS changes will undoubtedly still cause it to continue to grow a bit. Since we are right at the boundary of overflowing 128K, I thought it was worth investing some effort in backing away from that limit so we don't have to constantly worry about every small change causing an issue there.
In addition to the above mentioned data size reductions, another thing I noticed was that the e820 array is 32 entries, as given by BUILD_MAX_E820. It appears that QEMU only will ever fill 16 of those entries, so perhaps it would make sense to reduce that size when the usage is for QEMU only.
As a more general query, I was wondering if anyone else knew of places where the size of SeaBIOS could be reduced? I'd be happy to try to help make that happen.
Thanks,
Bruce Rogers
-
Bruce Rogers -
Kevin O'Connor -
Paolo Bonzini