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(a)coresystems.de>
Regards,
Patrick Georgi