[coreboot] r1026 - in coreboot-v3: mainboard/kontron/986lcd-m southbridge/intel/i82801gx

Jordan Crouse jordan at cosmicpenguin.net
Fri Nov 14 20:49:22 CET 2008

Carl-Daniel Hailfinger wrote:
> On 14.11.2008 19:54, Jordan Crouse wrote:
>> Carl-Daniel Hailfinger wrote:
>>> On 14.11.2008 19:06, Stefan Reinauer wrote:
>>>> ron minnich wrote:
>>>>> On Fri, Nov 14, 2008 at 9:53 AM, Stefan Reinauer
>>>>> <stepan at coresystems.de> wrote:
>>>>>> Carl-Daniel Hailfinger wrote:
>>>>>>> On 14.11.2008 18:14, svn at coreboot.org wrote:
>>>>>>>> Author: rminnich
>>>>>>>> New Revision: 1026
>>>>>>>> /home/rminnich/coreboot-v3/build/coreboot.initram_partiallylinked.o:
>>>>>>>> section .data.rel.ro.local: dual_channel_slew_group_lookup.3242
>>>>>>>> single_channel_slew_group_lookup.3243
>>>>>>> Basic rule: If you want to have arrays of pointers in initram,
>>>>>>> you lose.
>>>>>>> Pointers are not relocatable by definition. const is not going to
>>>>>>> help
>>>>>>> you there.
>>>>>> Hm. This is bad. 'nother regression in v3 that wasn't in v2.
>>>>> it's not acceptable as a rule. We have to fix it one way or another.
>>>>> Why gcc is marking it as writeable is a puzzle but points to a bug
>>>>> somewhere.
>>>> We could try and use indices instead of pointers. That's the easiest
>>>> rewrite i can think of to get the problem done without wasting the
>>>> code.
>>>> This is clearly a gcc weakness. This stuff should not happen when
>>>> compiling PIC. That's what PIC is for.
>>> We're missing one crucial piece which is necessary to get PIC to work:
>>> The linker. PIC code must be linked _after_ its location is known. That
>>> means a linker would have to pass over the final LAR archive. Right now,
>>> we circumvent that requirement by using early linker tricks and by
>>> prohibiting the use of arrays of pointers.
>>> If we insist on using arrays of pointers, we must either run a linker
>>> over the final LAR archive or abandon LAR completely and go for v2
>>> linker magic.
>> Fully agreed.  If we run a linker over the final LAR archive, then we
>> will need a way to run the linker every single time the LAR has
>> changed (including, mind you, on target, if we are going to go for the
>> "replace stages on the fly" thing).  Does not sound appetizing at
>> all.  I also don't like abandoning LAR - it is useful for payloads and
>> such.
> Yes, I'd like to keep LAR and I'd also like to avoid linker runs on the
> final LAR.
>> But I don't think thats what you meant - I think you meant to say that
>> we should "abandon the stages concept".
> Abandoning stages won't fix this, unfortunately. The problem is PIC in a
> LAR. (Okay, if we merged initram into the boot block, it would work, but
> that would kill the ability to have fallback/normal initram).

Yep, it sure would.

>> And you know what - with all due respect to Ron, I tend to be in favor
>> of that option.  Stages continue to be rather painful.  Just one guy's
>> opinion.
> I found stages rather useful, but that's only my personal opinion.

There is a difference between theoretically useful and technologically 
feasible.  As it stands, we are starting to have to make serious 
compromises between the code we want to write, and the design we want to 
keep.  And even more unfortunately, we are starting to dip in to the 
issues that we cannot easily protect against until the linker dies with 
an error of questionable usefulness.

The problem is that our good intentions are revealing an ugly side - 
kind of like the mercury in a florescent light bulb.  Everything we have 
been taught about embedded programming says that we need to share as 
much code as possible.  And there is code that we want to share between 
stages.  And we want to use standard C constructs such as pointers 
throughout the code.  All this with the pesky constraint that we have 
"memory" but we don't actually have memory.

Everything we know about the coreboot design in v2 is that we want 
stages.  And everything we know about the v2 design says that we don't 
like linker scripts, and we hate home grown compiler tools.  We want to 
pull everything off with just a $(CC) call, but it is clear we are 
quickly exposing the limitations of the compiler.

So we are in a no-mans land.  We want to share code and data between 
stages, but we want stages to be completely separate.  And we want to do 
this without reinventing any wheels from POSIX and adding many K of 
infrastructure to the ROM to do it.  Eventually, something is going to 
give.  There will be a sacrifice.  I advocate removing stages all 
together and instituting a single binary loader to rule them all, but I 
am biased since I have not yet personally had a need for a fallback 
kernel nor am I at all interested in updating individual stages on the 
fly.  Certainly, the HPC folks have a dramatically different opinion - 
these are debates that can be held assuming the community universally 
agrees that a compromise is needed.


More information about the coreboot mailing list