[LinuxBIOS] Patch quality

[ron minnich]

On 11/1/07, Myles Watson <myles at pel.cs.byu.edu> wrote:
> On 10/30/07, Jordan Crouse <jordan.crouse at amd.com> wrote:
> > On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
> > > An important issue will be to get the code compiling. I was not
> > > successful doing so due to the old ld overlapping sections friend.
> >
> > We've seen this before -  Whats happening here is that the ld script
> > snippet for .id is going into the ld script after the snippet for .reset,
> > so to LD, the current pointer appears to jump backwards, and it can't figure
> > out the math correctly.  The immediately work around is to re-arrange
> > the order of the .id and the .reset snippets in the script.  I believe this
> > was fixed in later versions of ld - I can't get it to happen on my trusty
> > Ubuntu Gutsy box.
>
> When I get this error, it is because my ROM_IMAGE_SIZE is set too
> small. Increasing it fixes the problem for me.


It turns out none of these was the problem, for me, and I just figured
it out this morning. Also, I am not totally convinced the .reset and
.id section ordering in the ldscript is really a problem -- the start
of each is pretty clearly laid out in the ldscript, and that code has
been running that way for many years now. Were you folks seeing .reset
and .id overlap, or .reset and .data? Do you have output I can see?

In my case I was getting overlapping sections of .reset and .data.

There should be no .data sections in the rom code. That's the first
hint of trouble. A quick grep of .data in normal/cache_as_ram_auto.inc
was enough to find the problem.

There are several u8 arrays in the sis southbridge early smbus code.
This code is compiled into cache_as_ram_auto.c. Because it is not
declared const, it gets passed through and compiled as a .data
section. ld does not know where to put it, since the ldscript for the
cache as ram code (ldscript.ld) only deals with .rom.text, .rom.data,
and so on.

The fix is simple: declare the u8 arrays as const. This gets them
passed in as rom.data, and all the conflicts on this board disappear.
The board is building just fine for me now, and I have checked the
last 16 bytes and can see the jump to the start of the rom code. In
other words linuxbios.rom looks good.

I will test again tomorrow morning (or tonight, who knows) with
Morgan's patches to 2925.

thanks

ron