Bug #1917
closed
I'm facing the same, with binutils 2.28. Is there any known workaround? Looking at the patch above there doesn't seem to be an option to disable that check.
Besides that, could someone point out why those overlaps aren't a real bug to begin with?
niklas wrote:
I'm facing the same, with binutils 2.28. Is there any known workaround?
One can resolve the issue straight ahead by editing `ram.lds` and other LD segment definition files lying under `osmocom-bb/src/target/firmware/board/` so that the memory segments don't overlap, yet point to the same addresses as before.
While I did manage to make the linker happy, the resulting binaries don't make the phone appear alive (yet?).
Hello,
Just got the same error. What must be the right binutils version to overcome this issue? I am planning to downgrade my binutils 2.29 to a older one.
0x00 wrote:
Hello,
Just got the same error. What must be the right binutils version to overcome this issue? I am planning to downgrade my binutils 2.29 to an older one.
I had tried to get this to work in the laforge/binutils
branch of osmocom-bb.git a long time ago but never found the time to complete and/or verify it. But it mightt be a good pointer if anyone wants to contribute a real fix.
libomnomnom-dev wrote:
One can resolve the issue straight ahead by editing `ram.lds` and other LD segment definition files lying under `osmocom-bb/src/target/firmware/board/` so that the memory segments don't overlap, yet point to the same addresses as before.
The entire point of those linker scripts is to produce overlapping segments/mappings/adresses. They are essential and required :)
I have the same problem on Debian 9.4 with binutils 2.28
I used precompiled arm toolchain from debian stretch repo's (binutils-arm-none-eabi gcc-arm-none-eabi gdb-arm-none-eabi libstdc++-arm-none-eabi-newlib
)
Does anybody know a crutch helping to solve this problem?
ok i found this crutch. It is can be compiled in Debian 9.4 x86_64 with gcc 4.9.4, binutils 2.21.1a and newlib 1.19.0
- Category set to OsmocomBB Firmware
- Status changed from New to Feedback
- Assignee set to fixeria
- Priority changed from Normal to High
- % Done changed from 0 to 90
Please see: https://gerrit.osmocom.org/#/c/osmocom-bb/+/14006/
I've tested the patch from Harald with the recent (9.1.0-1) cross compiler, as well as some older (4.5.2, 4.8.2) ones.
The firmware builds just fine, and works on my Compal E88 board (Motorola C118).
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Patch is merged, the issue should have been fixed now. Please (re)open if not.
Also available in: Atom
PDF