[U-Boot] [PATCH v2 3/6] cm-t35: add EEPROM module and pass Linux a serial number

[Tom Rini <trini@ti.com>]

On 02/17/2012 02:50 AM, Albert ARIBAUD wrote:
> Hi Igor,
>
> Le 07/02/2012 09:01, Igor Grinberg a ?crit :
>> Hi Albert,
>>
>> On 02/07/12 00:56, Albert ARIBAUD wrote:
>>> Le 09/01/2012 09:30, Nikita Kiryanov a ?crit :
>>>> On 01/05/2012 04:56 PM, Wolfgang Denk wrote:
>>>>> Dear Igor Grinberg,
>>>>>
>>>>> In message<1325764937-7342-1-git-send-email-grinberg@compulab.co.il>
>>>>> you wrote:
>>>>>> From: Nikita Kiryanov<nikita@compulab.co.il>
>>>>>>
>>>>>> Add board specific EEPROM handling module,
>>>>>> read the serial number from the EEPROM and pass it to Linux.
>>>>> ...
>>>>>
>>>>>> * Fix strange linker warning: ".bss section overlaps previous
>>>>>> sections"
>>>>>> by changing the type of the eeprom_layout static global variable
>>>>>> to int
>>>>>> (probably this is a compiler bug).
>>>>> Probably it is now. Did you inspect the linke rmap?
>>>>
>>>> u-boot.map shows the bss section aligning perfectly with the start of
>>>> rel.dyn.
>>>>
>>>> The difference between the original "working" version and the version
>>>> with the warning
>>>> was an additional byte added by uchar eeprom_layout to the size of
>>>> libcm_t35.o.
>>>> This shouldn't be a problem because the bss section is followed by an
>>>> ALIGN(4), but
>>>> we decided to try changing eeprom_layout to an int and the problem went
>>>> away.
>>>> When we tried to define 4 uchars the problem reappeared.
>>>>
>>>> This suggests that this might be a compiler bug.
>>>>
>>>> There's been some discussion about this in the following threads:
>>>> http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/114646
>>>> http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/90723
>>>> and we're not aware of any fix to the issue.
>>>
>>> Which prompted me to test --no-check-sections with CS 2009q1.
>>> Adding it to LDFLAGS_u-boot does reduce the annoyance from errors to
>>> a warning,
>>> but there is no way to completely make it disappear.
>>
>> So the conclusion is still a tool chain bug, right?
>> Probably it doesn't hurt besides the annoying warning.
>
> Sorry for being slow.
>
> Yes, it seems to be a toolchain bug and limited to a spurious warning.
> However, spurious warnings are always a pain when doing a MAKEALL arm,
> because the board is listed among the unclean and failed builds and then
> one must go through these individually and remember that this specific
> warning is both unimportant and unavoidable.

Have we gone and bugged any toolchain folks about what caused / fixed 
this problem so that perhaps we can option around it or otherwise squash 
this?

-- 
Tom