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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Nov 14 19:58:16 CET 2008


On 14.11.2008 19:40, ron minnich wrote:
> On Fri, Nov 14, 2008 at 10:37 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>>> for now I'm fixing it with a section attribute.
>>>
>>>       
>> Compilation may work, but RAMinit will fail during runtime if you do that.
>>
>>     
>
> ok, why would that be? It's being placed into that section ... what will fail?
>   

The section is not the problem. Let's look at the code to make this a
bit clearer (edited for clarity):

static const u32 dq2030[] = {
        0x08070706, 0x0a090908, 0x0d0c0b0a, 0x12100f0e
};
static const u32 nc[] = {
        0x00000000, 0x00000000, 0x00000000, 0x00000000
};
static const u32 const * const dual_channel_slew_group_lookup[] = {
        dq2030, nc
};


dq2030 is const and will be placed in section ".rodata". Same for nc.
The addresses of dq2030 and nc need to be calculated during runtime
because their location is not known during early link time (this is PIC,
remember?). That works fine if dq2030 and nc are accessed from code
because code can calculate the addresses.
dual_channel_slew_group_lookup is a completely different beast. You
claim the pointers are const, but they are unknown until we know the
location of initram inside the ROM and that's during runtime. So we need
to modify the pointers stored in dual_channel_slew_group_lookup during
runtime. That's _not_ const by definition.

I think I can propose a fixup, though.


> second question, this is failling:
> STAGE2_CHIPSET_SRC += \
> 			$(src)/southbridge/intel/i82801gx/smmrelocate.S \
>
> note the .S: I get this error:
>
>   LD      build/coreboot.stage2
> /home/rminnich/coreboot-v3/southbridge/intel/i82801gx/smmrelocate.S:
> file not recognized: File format not recognized
>
> how do we do assembly?
>   

You need to run "as" on ssmrelocate.S to get an object file. The linker
won't handle assembly directly.


Regards,
Carl-Daniel

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





More information about the coreboot mailing list