[LinuxBIOS] digitallogic/adl855pc will not link

[Jon Dufresne]

When I try to make the digitallogic/adl855pc target I receive an error
with the following message.

/usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section
.rom [fffd632e -> fffe1d7f]
/usr/bin/ld: section .id [fffdffce -> fffdffef] overlaps section .rom
[fffd632e -> fffe1d7f]
/usr/bin/ld: linuxbios: section .id lma 0xfffdffce overlaps previous sections
/usr/bin/ld: linuxbios: section .text lma 0xfffdfff0 overlaps previous sections
/usr/bin/ld: linuxbios: section .data lma 0xfffdfff0 overlaps previous sections
/usr/bin/ld: linuxbios: section .reset lma 0xfffdfff0 overlaps
previous sectionscollect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
make[1]: Leaving directory
`/root/temp/LinuxBIOSv2/targets/digitallogic/adl855pc/adl855pc/normal'
make: *** [normal/linuxbios.rom] Error 1

When I use abuild it says that it builds fine. Any idea why I can't
get this to link using make?

Also, is the linuxbios.rom file in the abuild directory good? Or do
you suspect that it has the same linking error I get when I use make.

Thanks,
Jon

[ron minnich]

You have run out of room. What is your flash size and payload?

ron

[Jon Dufresne]

I did not modify the digitallogic/adl855pc target, I just wanted to
see if I could biuld it before modifying it. This is straight from
svn.

Jon

On 11/20/06, ron minnich  wrote:
> You have run out of room. What is your flash size and payload?
>
> ron

[Uwe Hermann]

On Mon, Nov 20, 2006 at 03:20:20PM -0500, Jon Dufresne wrote:
> I did not modify the digitallogic/adl855pc target, I just wanted to
> see if I could biuld it before modifying it. This is straight from
> svn.

Confirmed. I get the same results.

Uwe.

[Jon Dufresne]

Any suggestion on how I could attempt to fix this would be appreciated.

On 11/20/06, Uwe Hermann  wrote:
> On Mon, Nov 20, 2006 at 03:20:20PM -0500, Jon Dufresne wrote:
> > I did not modify the digitallogic/adl855pc target, I just wanted to
> > see if I could biuld it before modifying it. This is straight from
> > svn.
>
> Confirmed. I get the same results.
> Uwe.
>
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFFYhaeXdVoV3jWIbQRAimLAKCjgI7TIehjHxehS37JlGPb5l5ezwCcDouG
> Oa4j9QankD0dIqox39P6xqA=
> =tAyS
> -----END PGP SIGNATURE-----

[ron minnich]

On 11/20/06, Jon Dufresne  wrote:
> Any suggestion on how I could attempt to fix this would be appreciated.

[rminnich@q adl855pc]$ pwd
/home/rminnich/src/LinuxBIOSv2/targets/digitallogic/adl855pc
[rminnich@q adl855pc]$ more Config.lb
# Sample config file for adl855pc
# This will make a target directory of ./adl855pc

target adl855pc
mainboard digitallogic/adl855pc

option DEFAULT_CONSOLE_LOGLEVEL=10
option MAXIMUM_CONSOLE_LOGLEVEL=10

set to 3

ron

[Jon Dufresne]

Is there a way to get a "map" of sorts , or any kind of description,
of how buildrom allocates the memory for different parts of the rom. I
have a feeling that parts starting to late or too early and wanted to
know if there was a convenient tool to analyze this.

Thanks,
Jon

[ron minnich]

On 11/20/06, Jon Dufresne  wrote:
> I did not modify the digitallogic/adl855pc target, I just wanted to
> see if I could biuld it before modifying it. This is straight from
> svn.

blast. Something has changed. This target never worked, due to lack of
chipset info from the vendor. I apologize for this, but you're going
to have to dig a little.

thanks

ron

[Jon Dufresne]

So are you saying this is an bug in the chipset software or the
mainboard software?

Thanks for the help!

On 11/20/06, ron minnich  wrote:
> On 11/20/06, Jon Dufresne  wrote:
> > I did not modify the digitallogic/adl855pc target, I just wanted to
> > see if I could biuld it before modifying it. This is straight from
> > svn.
>
> blast. Something has changed. This target never worked, due to lack of
> chipset info from the vendor. I apologize for this, but you're going
> to have to dig a little.
>
> thanks
>
> ron

[Stefan Reinauer]

* Jon Dufresne  [061120 20:39]:
> /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section
> .rom [fffd632e -> fffe1d7f]

This looks like a linker bug in the Debian linker. Why is it putting
.reset at 0xfffdfff0 instead of 0xfffffff0 ?
> When I use abuild it says that it builds fine. Any idea why I can't
> get this to link using make?

Please compare the Config.lb generated by abuild with the one you are
using.. It's different configurations.
> Also, is the linuxbios.rom file in the abuild directory good? Or do
> you suspect that it has the same linking error I get when I use make.

Not unless you build it with a payload

svn co svn://linuxbios.org/repos/trunk/LinuxBIOSv2
cd LinuxBIOSv2/util/abuild
svn co svn://linuxbios.org/testsystem/LinuxBIOS-payloads
./abuild -t digitallogic/adl855pc -p `pwd`/LinuxBIOS-payloads

[Richard Smith]

Stefan Reinauer wrote:
> Jon Dufresne  [061120 20:39]:
> > /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section
> > .rom [fffd632e -> fffe1d7f]
>
> This looks like a linker bug in the Debian linker. Why is it putting
> .reset at 0xfffdfff0 instead of 0xfffffff0 ?
> > When I use abuild it says that it builds fine. Any idea why I can't
> > get this to link using make?

Jon,  Sorry it took me a while to get back to you on this.  I've been
Traveling.

This is the classic out-of-room in the linuxbios IMAGE error.  Not to be
confused with out-of-room in your ROM.

You can fix this by increasing your ROM_IMAGE_SIZE.

Note that this option is sort of misnamed.  Very non-obvious as to what
it does. This controls the size of the area we allocate out for the
Linuxbios+payload.

Try:

option ROM_IMAGE_SIZE=0x16000

Rather than 0x10000 as in Config.lb

0x16000 is what abuild is using. It can probably be smaller.  In fact a
good exercise for the reader is to find out how small it can be and
still contain a FILO payload.

Stefan:

Why is abuild preferring to use its own custom Config.lb rather than the
 Config.lb that is in the target directory?

[Jon Dufresne]

Success! Thanks so much for everyone that gave me help, I really appreciate it.

So if ROM_IMAGE_SIZE = LB + payload what does ROM_SIZE mean? I assume
it means the entire size of the ROM, which in my case is 512KB. How is
this different than ROM_IMAGE_SIZE. What does the ROM hold in addition
to LB + payload.

Richard: No need to apologize, you're under no obligation to help. I
consider everything I get a bonus to the already written software.

-Jon

On 11/21/06, Richard Smith  wrote:
> Stefan Reinauer wrote:
> > Jon Dufresne  [061120 20:39]:
> > > /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section
> > > .rom [fffd632e -> fffe1d7f]
> >
> > This looks like a linker bug in the Debian linker. Why is it putting
> > .reset at 0xfffdfff0 instead of 0xfffffff0 ?
> > > When I use abuild it says that it builds fine. Any idea why I can't
> > > get this to link using make?
>
> Jon,  Sorry it took me a while to get back to you on this.  I've been
> Traveling.
>
> This is the classic out-of-room in the linuxbios IMAGE error.  Not to be
> confused with out-of-room in your ROM.
>
> You can fix this by increasing your ROM_IMAGE_SIZE.
>
> Note that this option is sort of misnamed.  Very non-obvious as to what
> it does. This controls the size of the area we allocate out for the
> Linuxbios+payload.
>
> Try:
>
> option ROM_IMAGE_SIZE=0x16000
>
> Rather than 0x10000 as in Config.lb
>
> 0x16000 is what abuild is using. It can probably be smaller.  In fact a
> good exercise for the reader is to find out how small it can be and
> still contain a FILO payload.
>
> Stefan:
>
> Why is abuild preferring to use its own custom Config.lb rather than the
>  Config.lb that is in the target directory?

[Peter Stuge]

On Tue, Nov 21, 2006 at 11:47:29AM -0500, Jon Dufresne wrote:
> So if ROM_IMAGE_SIZE = LB + payload what does ROM_SIZE mean? I
> assume it means the entire size of the ROM, which in my case is
> 512KB.

Yes, correct.
> How is this different than ROM_IMAGE_SIZE. What does the ROM hold
> in addition to LB + payload.

It can hold a VGA BIOS for example. Or a VSA binary image for the
Geodes. Maybe in the future an option ROM image for your SCSI card.

I'm guessing that ROM_IMAGE_SIZE came from the linuxbios_rom
label/section/filename.

It's a bit complicated.. While people (rightly) only care about the
size of their flash chip, the various binary images that can be
included have to be arranged to fit together somehow..

//Peter

[Segher Boessenkool]

> > /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section
> > .rom [fffd632e -> fffe1d7f]
>
> This looks like a linker bug in the Debian linker. Why is it putting
> .reset at 0xfffdfff0 instead of 0xfffffff0 ?

Run the linker with the -M flag to find out.

Segher