New subject: [PATCH]es: eliminate several code includes, refactor copy_and_run

29 Apr 2009


      Hi,
the attached patchset has the goal to refactor copy_and_run so that it 
uses a single code base instead of 3 (with one of them way too much 
assembler code).
On the way, I had to make some changes to the way the code is built, 
which is an effort I want to expand over time.
Right now, large portions of the in-ROM part of coreboot is compiled as 
a single file, with lots of .c files including other .c files.
That has its justification for pre-raminit code, but it also affects 
lots of post-raminit code (memcpy doesn't really make sense before 
raminit, or at least CAR)
The coreboot_apc code (AMD boards) gained some .c includes because I 
don't know that part of the code enough to really rework it and only 
have limited possibilities to test it. The includes should give an 
identical situation for this part of the code.
The code (all patches together) was abuild tested (all boards), and boot 
tested (into FILO) on:
- via/vt8454c
- kontron/986lcd-m
- amd/serengeti_cheetah (simnow)
- emulation/qemu-x86
- a romcc target
What the patches do in particular:
-- cbfs-xor-elfboot:
elfboot doesn't really make sense for a CBFS formatted image, so drop 
it. It also drops the *_stream family for CBFS.
-- modular-crt0
Add .rodata.* to the linker scripts, so multiple object files can be 
linked into the early code part. Unless someone comes up with a good 
reason why .rodata* is renamed .rom.* all the time, I'll drop that 
renaming business eventually. It looks as if it's a workaround for a 
linker bug in binutils 0.5 on linux 1.3 with libc5. But not this time.
-- separate-build-units
Kick the mem* functions and print* functions out of the main compilation 
unit and compile them separately, then link them together at the end
-- eliminate-some-assembler-in-copy_and_run
As the name implies, there was some assembler code in that file that 
isn't really needed. Replace it with C code
-- move-disable-CAR-out-of-copy_and_run
Two boards and the intel CPUs deactivated CAR somewhere in the 
copy-and-run code.
-- single-copy_and_run-kernel-for-all
Refactor the - now quite similar - copy_and_run implementations. This 
includes the ASM version, used by ROMCC targets. At that time, there 
(hopefully) is RAM, so C can be used.
As with the via code recently, I picked 64MB as stack address. As with 
the via code, there has to be a better way to determine a suitable place 
for the stack. Alas, I have no idea what to pick.
All of these are
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Regards,
Patrick Georgi