Hi,
attached patch drops console/console.c and pc80/serial.c from the mainboards' romstage.c. console/console.h is included instead.
On CAR builds, console/console.c is built separately and linked to the romstage, on romcc builds, this includes console/console.c from within console/console.h. The romcc variant helps with uniformity.
In the same way, pc80/serial.c is eliminated from romstage.c. The necessary prototypes were already included via some other paths.
Both files needs to include arch/io.h for separate compilation, so it finds outb, so it's moved outside the #ifndef __PRE_RAM__ in console.c and added in serial.c
The patch also removes two superfluous ARRAY_SIZE definitions (in amd/db800 and winent/pl6064)
It's abuild tested and
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
On 5/8/10 12:13 AM, Patrick Georgi wrote:
-#initobj-y += serial.o +initobj-$(CONFIG_USE_DCACHE_RAM) += serial.o subdirs-y += vga
Awesome... the less .c file includes we have in romstage.c the better..
This way works in the case of converting code that was previously always compiled in.
But how should we handle things in case of other conditions?
Acked-by: Stefan Reinauer stepan@coresystems.de
Stefan
Am Samstag, den 08.05.2010, 10:25 +0200 schrieb Stefan Reinauer:
On 5/8/10 12:13 AM, Patrick Georgi wrote:
-#initobj-y += serial.o +initobj-$(CONFIG_USE_DCACHE_RAM) += serial.o subdirs-y += vga
Awesome... the less .c file includes we have in romstage.c the better..
This way works in the case of converting code that was previously always compiled in.
But how should we handle things in case of other conditions?
We could stuff all of the initobjs into an initobj.a, and use that for linking. ld will only pick up the object files that are actually needed then. This means we probably compile a serial port thingy too many, but they're rather small.
For chipset specific stuff (once we get there), it can be initobj-$(CONFIG_SOUTHBRIDGE_X_Y) += ...
Patrick
On Sat, May 08, 2010 at 10:34:23AM +0200, Patrick Georgi wrote:
Am Samstag, den 08.05.2010, 10:25 +0200 schrieb Stefan Reinauer:
On 5/8/10 12:13 AM, Patrick Georgi wrote:
-#initobj-y += serial.o +initobj-$(CONFIG_USE_DCACHE_RAM) += serial.o subdirs-y += vga
Awesome... the less .c file includes we have in romstage.c the better..
This way works in the case of converting code that was previously always compiled in.
But how should we handle things in case of other conditions?
We could stuff all of the initobjs into an initobj.a, and use that for linking. ld will only pick up the object files that are actually needed then. This means we probably compile a serial port thingy too many, but they're rather small.
I think coreboot should try to avoid using .a files.
The latest version of gcc (v4.5) contains the -flto feature. This can provide significant benefits to coreboot code generation because it allows the entire romstage (and ramstage) to be analyzed as a whole. The resulting binaries are significantly smaller because unused code can be eliminated and more functions can be inlined. Unfortunately, the standard linker can't handle -flto with .a files.
-Kevin
Am 08.05.2010 17:56, schrieb Kevin O'Connor:
I think coreboot should try to avoid using .a files.
The latest version of gcc (v4.5) contains the -flto feature. This can provide significant benefits to coreboot code generation because it allows the entire romstage (and ramstage) to be analyzed as a whole. The resulting binaries are significantly smaller because unused code can be eliminated and more functions can be inlined. Unfortunately, the standard linker can't handle -flto with .a files.
Our build system is advanced enough that this can be an option based on compiler version.
Thanks for the notice, but I guess we should support non-lto builds until gcc4.5 is the lowest common denominator, or even better the next version, so we can assume that bugs are fixed.
Patrick
On 5/8/10 5:56 PM, Kevin O'Connor wrote:
I think coreboot should try to avoid using .a files.
The latest version of gcc (v4.5) contains the -flto feature. This can provide significant benefits to coreboot code generation because it allows the entire romstage (and ramstage) to be analyzed as a whole. The resulting binaries are significantly smaller because unused code can be eliminated and more functions can be inlined. Unfortunately, the standard linker can't handle -flto with .a files.
The reason we used .a files to begin with was because the linker can smartly drop unused objects files "linked" into a static library, significantly decreasing code size.
Going to -flto introduces one code size reduction mechanism by rendering another one unusable. That's only half-baked, especially since many optimizations making -flto useful are still known broken in gcc 4.5. We should keep this in mind. Last time I checked -flto on a coreboot image it would not gain more than 1-2kb on a 1MB image. Didn't benchmark the 4.5 release yet though.
Being curious: Will gold cope with .a files and flto?
On Sat, May 08, 2010 at 06:22:54PM +0200, Stefan Reinauer wrote:
On 5/8/10 5:56 PM, Kevin O'Connor wrote:
I think coreboot should try to avoid using .a files.
The latest version of gcc (v4.5) contains the -flto feature. This can provide significant benefits to coreboot code generation because it allows the entire romstage (and ramstage) to be analyzed as a whole. The resulting binaries are significantly smaller because unused code can be eliminated and more functions can be inlined. Unfortunately, the standard linker can't handle -flto with .a files.
The reason we used .a files to begin with was because the linker can smartly drop unused objects files "linked" into a static library, significantly decreasing code size.
Yeah, but I've not had much luck with that optimization because it's too easy to inadvertently pull in .o files. I've had more success with enabling -ffunction-sections / -fdata-sections and giving ld the --gc-sections option.
Going to -flto introduces one code size reduction mechanism by rendering another one unusable. That's only half-baked, especially since many optimizations making -flto useful are still known broken in gcc 4.5. We should keep this in mind. Last time I checked -flto on a coreboot image it would not gain more than 1-2kb on a 1MB image. Didn't benchmark the 4.5 release yet though.
I use -fwhole-program in seabios and find it quite useful. I haven't done much with -flto, but it is supposed to allow -fwhole-program without having to completely restructure the build process. It's more than just a size optimization, though I suspect that's the biggest impact coreboot would see.
Being curious: Will gold cope with .a files and flto?
Yes (according to the gcc documentation).
See the -flto description at:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Optimize-Options.html#Optimize-O...
-Kevin
-
Kevin O'Connor -
Patrick Georgi -
Stefan Reinauer