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