[coreboot] how much more const could it be?

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Nov 14 18:50:04 CET 2008

On 14.11.2008 18:41, Jordan Crouse wrote:
> Myles Watson wrote:
>> On Fri, Nov 14, 2008 at 9:24 AM, ron minnich <rminnich at gmail.com> wrote:
>>>        static const u32 const * const
>>> dual_channel_slew_group_lookup[] = {
>>>        static const u32 const * const
>>> single_channel_slew_group_lookup[] =
>>> {
>>> /home/rminnich/coreboot-v3/build/coreboot.initram_partiallylinked.o:
>>> section .data.rel.ro.local: dual_channel_slew_group_lookup.3240
>>> single_channel_slew_group_lookup.3241
>>> what's it looking for here?
> It wants to put the data in a special segment that likely isn't being
> included in the linker scripts.  We've had this problem before.  The
> linker script should be using wildcards - probably .data.rel.* or
> .data.rel.ro.* to pull in the subsections.

I'm pretty sure this is a bug spotted by my section checker. .data.rel.*
must not (as in the RFC meaning) be present in initram before linking.

>> I don't really have an answer, but I have a question:
>> Is it a types problem?
>> static const u32 nc[] = {...};
>> static const u32 const * const dual_channel_slew_group_lookup[] = {
>> nc, nc
>> };
>> I think maybe it doesn't like having unconstrained pointers with this
>> many
>> levels.  Could you try a typedef or something like that?  I was
>> looking at
>> southbridge/amd/cs5536/cs5536.c and they don't need nearly as many
>> consts as
>> you had.
>> I could be way off :)
> Hmm - I think it looks right though.  In the first line, you want the
> array to be constant, so thats correct.  In the second line, you want
> the array to be const, you want the contents to be const u32s, and you
> want the pointer itself to be a const.  So the first 'const u32' is
> the contents of the array, the second const is making the array itself
> constant, and the third const is making the pointer constant.

Unless someone wants to implement a linker in coreboot, arrays of
pointers will be a problem in initram because initram is PIC. A possible
solution for fixed absolute pointers inside initram has been outlined in
one of my previous mails in this thread.



More information about the coreboot mailing list