[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.
Jordan
More information about the coreboot
mailing list