[coreboot] Time for a new project

[Carl-Daniel Hailfinger]

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.


Regards,
Carl-Daniel