On 11/1/07, Myles Watson myles@pel.cs.byu.edu wrote:
On 10/30/07, Jordan Crouse jordan.crouse@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