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

[Carl-Daniel Hailfinger]

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).

> 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.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/