[coreboot] Time for a new project

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sun Apr 13 01:29:18 CEST 2008

On 13.04.2008 00:59, Segher Boessenkool wrote:
>> Some Linux kernel verification mechanisms have caught compiler bugs in
>> the past. That's why I considered the possibility to do this as well.
> The only ones that I am aware of are *generic* sanity checks in the
> kernel, that manage to trip on something that turned out to be a 
> compiler
> bug.  Adding specific sanity checks for every piece of code that only
> checks for compiler bugs is foolishness (hint: it's impossible to ever
> get even 1% cover; and that check code itself is run through that same
> compiler anyway!)

Well, possibly catching compiler bugs would have been a nice (yet
improbable) side effect. The decompression of a large chunk of data is
probably taxing memory a bit more than our current simple memtest
implementation and checksumming the result may have uncovered bugs in
RAM configuration.
But we can postpone/skip that.

> If there is a *specific* compiler bug that you are aware of, it is
> nicer to catch it at build time, if possible, or just refuse to build
> with the broken compiler.
>>> At some point the entry point to a blob was at the beginning of the
>>> file. Adding the flexibility to begin with moved complexity from
>>> compile time to run time -- guess what, that was a bad idea.
>> Unless you fork gcc, having the entry point at the beginning of initram
>> is not possible. It worked by accident in the past and I'm pretty sure
>> Segher will confirm that we can't rely on that.
> No, I confirm you *can* rely on that: just set up your linker script
> and your crt.o so this works.  Something like
>          .start : { crt0.o(*) }
>          .text : { *(.text) }
>          .data : { *(.data) }
> will guarantee that all of crt0 ends up before anything else (and there
> is no need to make it a separate section, FWIW).

Hm. Does that really apply to the initram binary we produce in v3? AFAIK
we don't link any crt0 into that binary. Here are the commands used to
generate coreboot.initram:

$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c -combine $(INITRAM_OBJ) -o $(obj)/coreboot.initram_partiallylinked.o
$(LD) -Ttext 0 --entry main -N -R $(obj)/stage0-prefixed.o $(obj)/coreboot.initram_partiallylinked.o -o $(obj)/coreboot.initram

The entry point(main) has to end up at byte 0 of coreboot.initram if
we want to avoid storing it outside the file. Don't let yourself be
confused by $(INITRAM_OBJ) - the variable refers to a few source files.


More information about the coreboot mailing list