[coreboot] r3085 build service

Marc Karasek Marc.Karasek at Sun.COM
Tue Jan 29 14:22:50 CET 2008


Sorry about that...

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:marc.karasek at sun.com
ph:770.360.6415
*********************/



Marc Karasek wrote:
>
> Here is my message about the .id bug in binutils
>
> /***************************************************
>
> After some more investigating I think I have found the core problem 
> with the id.lds file.
> I think this is a bug in binutils.   if you look at the link below you 
> will see an explanation.  I have checked and I am using 2.17.50 on my 
> system. this could explain the problem I am seeing with linking.  It 
> seems a check within ld is not working properly for sections that are 
> at the top of an image/memory. (base+size = 0).  Looks like a fix has 
> been put into binutils already.
>
> My question is do we leave the patch in place or just make a note 
> somewhere that if you see this problem :
> 1) Upgrade binutils (if possible)
> or
> 2) Make changes to id.lds
>
>
> http://www.nabble.com/binutils-2.18-and-U-Boot-td14266866.html
>
> /*********************************************************
>
>
> Here is the message from the person who tested the 2.18 binutils :
>
> /**************************************************
> Quoting joe at smittys.pointclark.net:
>
>> Quoting Marc Karasek <Marc.Karasek at Sun.COM>:
>>
>>> It was not specifically x86_64 related.  It was however fedora 8
>>> related.  I think in my research that it has to do with the version of
>>> binutils.  I had sent out a mail to the reflector with a link to
>>> another discussion group regarding binutils and a bug that looked like
>>> it was this.  According to the thread, a patch had been submitted to
>>> the binutils tree  to fix this issue. The version of binutils I have
>>> that shows this problem is  2.17.50.0.18-1 2007073.  I am looking to
>>> upgrade to 2.18 as soon as it is avail (rpm) to see if this is fixed.
>>>
>> I found someone that built binutils-2.18.50.0.3-1 rpms here:
>>
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=27856
>>
>> I will try it out and report back
>>
> SWEET:-) I rpm -Uvh 'd the three packages from the above link 
> (binutils, binutils-devel, binutils-debuginfo) and everything is 
> working great now, coreboot builds with no problems. Back in business 
> again.
>
> Thanks - Joe
>
> /*******************************************
>
>
>
> Jordan Crouse wrote:
>> On 28/01/08 21:38 +0100, Carl-Daniel Hailfinger wrote:
>>   
>>> On 28.01.2008 21:12, coreboot information wrote:
>>>     
>>>> revision 3085
>>>>
>>>> Build Log:
>>>> Compilation of amd:serengeti_cheetah has been fixed
>>>> Compilation of amd:serengeti_cheetah_fam10 is still broken
>>>> See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3085&device=serengeti_cheetah_fam10&vendor=amd
>>>>   
>>>>       
>>> And we need another 2461 bytes increase due to the new compiler. Just in
>>> case anyone wonders which compiler causes continuous size increases:
>>>
>>> gcc version 4.3.0 20080117 (experimental) [trunk revision 131592] (SUSE Linux)
>>>     
>>
>> Nak.  This is a more serious problem:
>>
>> My system is:
>> gcc version 4.1.3 20070929 (prerelease) (Ubuntu4.1.2-16ubuntu2)
>>
>> My sections are as follows:
>> .ram start 0xfffc0000 size 0x10098
>> .rom start 0xfffd0098 size 0xfac8
>> .id  start 0xfffefd2 
>>
>> On the log from abuild, we can interpolate the results.  .ram start is
>> hardcoded, and .rom starts immediately after .ram.  So, based on this 
>> line:
>>
>> Section .id [00000000ffffefd2 -> 00000000ffffefef] overlaps section .rom
>> [00000000fffedd7c -> 00000000fffff96f]
>>
>> We see that the .ram is (0xfffedd7c - 0xfffd0098) 122084 bytes larger on
>> the abuild machine then it is on my machine.   That certainly isn't because
>> of little changes in the compiler.  And .rom too has an increase,
>> (0xfffff96f - 0xfffedd7c = 72691), which is 8491 bytes larger then my box.
>>
>> Something is amiss here, and I need to put my head down with Stefan and 
>> figure it out.  But in the meantime, hiding the problem isn't going to help
>> anybody.
>>
>> Jordan
>>
>>   




More information about the coreboot mailing list