Hi,
attached patch implements my tinybootblock concept (formerly known as newfailover) in Kconfig. It's designed to be non-instrusive, so boards will continue to build as usual unless they're changed to use the feature. As a proof of concept (which I used for development), emulation/qemu-x86 is changed to tinybootblock, but other boards will require more changes, so it not a complete example on how to convert a board.
Objectives of tinybootblock (when fully implemented): - Fix Fam10 boards on Kconfig, which require >64kb for raminit. That should help with replacing newconfig with kconfig completely. newconfig requires the failover mechanism on those boards to work around this limit, and this solves it similarily by splitting the code in a top-64k block and "the rest".
- Use CBFS The newconfig failover mechanism uses the pre-CBFS image layout (cat(1)ing files together and relying on magic offsets to determine entry points). CBFS provides a clean solution for that.
- Provide a framework to build image selection logic In newconfig, most boards have their own code to select the image. The goal in this layout is to have generic decision routines to take care of that, and encourage their use.
- Push as much as possible out of the bootblock The failover mechanism so far did CAR in the bootblock and raminit in the later stage. With tinybootblock, CAR is supposed to end up outside the bootblock. "Safe updates", once we provide them, will be able to update CAR support for new CPU types, too.
Code flow in tinybootblock: - 16bit reset vector (0xfffffff0) - jump to 32bit mode - Do whatever is necessary to have the entire ROM around (C code, compiled with romcc) - Look up fallback/romstage in CBFS (this can be extended with selection logic if desired) ("selection logic" is C, compiled with romcc, lookup is assembly) - Fetch the entry point which is stored in the romstage's header - Jump to the entry point. fallback/romstage is linked for the address where it finally resides in the image, so it's execute in place. - fallback/romstage is the original bootblock code (except for ROM enable): Setup CAR if available, do raminit, call coreboot_ram
Current issues: - No support for rom enable sequences yet. QEmu doesn't need them, but they're what I do next.
- The bootblock isn't exactly tiny, it's 64kb. Most of it is empty (on qemu, it's ~400 used bytes including id section and reset vector, ~350 byte for all code). To be done after rom enable works.
- There might be better places to push files to (both in the sources and in the build tree)
- There's some problem with the various section types in ELF which I worked around in cbfstool: If the section starts earlier than the desired load address, strip the bytes before the load address. This is no problem in automatic operation but can have lead to mistakes in manual operation.
Future developments: - At some point we might want to have various variants of the bootblock: Unconditionally loading a given romstage (what we have now), selecting between fallback/normal by CMOS (as in newconfig), enabling a rescue flash routine on GPIO, etc.
As mentioned, ROM enable support is still missing. Once this is done, tinybootblock should be useful for a broader audience (eg. to port boards), but I wanted to get the current state out now, as it finally works.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Hi again,
It was brought to my attention that svn didn't track the file copies in the diff. The following copies are necessary: cp src/arch/i386/init/crt0.S.lb src/arch/i386/init/bootblock_prologue.c cp src/arch/i386/Makefile.inc src/arch/i386/Makefile.tinybootblock.inc cp src/arch/i386/Makefile.inc src/arch/i386/Makefile.bigbootblock.inc
Then, the patch will work.
I'm sorry for the trouble, Patrick
On Tue, Dec 22, 2009 at 2:27 PM, Patrick Georgi patrick@georgi-clan.dewrote:
- Provide a framework to build image selection logic
In newconfig, most boards have their own code to select the image. The goal in this layout is to have generic decision routines to take care of that, and encourage their use.
Is it possible to have it be generic? Won't we have to unify CMOS layouts for that to happen?
- Push as much as possible out of the bootblock
The failover mechanism so far did CAR in the bootblock and raminit in the later stage. With tinybootblock, CAR is supposed to end up outside the bootblock. "Safe updates", once we provide them, will be able to update CAR support for new CPU types, too.
Code flow in tinybootblock:
- 16bit reset vector (0xfffffff0)
- jump to 32bit mode
- Do whatever is necessary to have the entire ROM around (C code,
compiled with romcc)
I think it would be a mistake to bring romcc to targets that don't need it now.
- Look up fallback/romstage in CBFS (this can be extended with selection
logic if desired) ("selection logic" is C, compiled with romcc, lookup is assembly)
It's more important to me to avoid assembly than to have the absolute minimum size bootblock. Especially for K8 & Fam10, there's plenty of space to not have to do this.
Picky detail: Since CONFIG_TINY_BOOTBLOCK is referenced in a Makefile that isn't board specific, the Kconfig entry for it should go there too (with a default n). There should just be a "select" in qemu-x86/Kconfig
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
I think it's a good start, and since it doesn't break anything until it's used...
Acked-by: Myles Watson mylesgw@gmail.com
Am 22.12.2009 23:17, schrieb Myles Watson:
On Tue, Dec 22, 2009 at 2:27 PM, Patrick Georgi <patrick@georgi-clan.de mailto:patrick@georgi-clan.de> wrote:
- Provide a framework to build image selection logic In newconfig, most boards have their own code to select the image. The goal in this layout is to have generic decision routines to take care of that, and encourage their use.
Is it possible to have it be generic? Won't we have to unify CMOS layouts for that to happen?
In a way, it's just the do_normal_boot() code in src/pc80/mc146818rtc_early.c. We already have everything in the tree to make it all generic, but we didn't properly use it. Maybe because the generic code came after the copied versions and no-one dared to refactor things.
It's not simply a port because of the intrusive change of moving CAR out of the bootblock, and this time, the generic code will be around from the start, so it has a chance to be used.
I think it would be a mistake to bring romcc to targets that don't need it now.
The alternative at that point is to do that code in assembly, or to move CAR to the bootblock again. romcc works quite fine for small code, and the code in the bootblock is supposed to be small.
- Look up fallback/romstage in CBFS (this can be extended with selection logic if desired) ("selection logic" is C, compiled with romcc, lookup is assembly)
It's more important to me to avoid assembly than to have the absolute minimum size bootblock. Especially for K8 & Fam10, there's plenty of space to not have to do this.
Among the reasons: The way it is done now, it's always exactly one copy of the tree walker. If it's written in C and compiled with romcc, it could end up several times in the bootblock, if there are various calls (fallback, normal, ...), probably giving the register allocator a harder time.
Picky detail: Since CONFIG_TINY_BOOTBLOCK is referenced in a Makefile that isn't board specific, the Kconfig entry for it should go there too (with a default n). There should just be a "select" in qemu-x86/Kconfig
Fixed, thanks for the reminder. I wanted to keep things minimal and forgot about it. It's not a big issue, as in Makefiles, missing variables simply expand to the empty string, but it's cleaner the way you proposed.
Acked-by: Myles Watson <mylesgw@gmail.com mailto:mylesgw@gmail.com>
Thanks, r4989
On Tue, Dec 22, 2009 at 10:27:19PM +0100, Patrick Georgi wrote:
attached patch implements my tinybootblock concept (formerly known as newfailover) in Kconfig.
Very nice!
Thanks. -Kevin