CyberCircuits / optiboot

Automatically exported from code.google.com/p/optiboot
0 stars 0 forks source link

BIGBOOT=1 results in section overlapping #108

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I'm trying to compile optiboot with EEPROM support for m328. Enabling BIG_BOOT 
results in an error by the linker complaining about a section overlap. Has this 
been tested by someone lately?

What steps will reproduce the problem?
What is the expected output? What do you see instead?

[johnpatcher@vpcs optiboot]$ make BIGBOOT=1 ENV=arduino atmega328
avr-gcc (GCC) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

BAUD RATE CHECK: Desired: 115200, Real: 117647, UBRRL = 16, Error=-2.1%
../../../tools/avr/bin/avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax 
-mmcu=atmega328p -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=3 
-DBIGBOOT=1       -c -o optiboot.o optiboot.c
optiboot.c:300:2: warning: #warning BAUD_RATE error greater than -2%
../../../tools/avr/bin/avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax 
-mmcu=atmega328p -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=3 
-DBIGBOOT=1     -Wl,--section-start=.text=0x7e00 
-Wl,--section-start=.version=0x7ffe -Wl,--relax -nostartfiles -nostdlib -o 
optiboot_atmega328.elf optiboot.o -lc
/home/johnpatcher/arduino-1.0.5/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../.
./../avr/bin/ld: section .version [0000000000007ffe -> 0000000000007fff] 
overlaps section .text [0000000000007e00 -> 0000000000008045]
Makefile:498: recipe for target 'optiboot_atmega328.elf' failed
make: *** [optiboot_atmega328.elf] Error 1
rm optiboot.o

What version of the product are you using? On what operating system?

Current revision from the repository (1eeecd3a4bac6923664f15caff7fb7b945b97506) 
on Linux. Tried both, avr-gcc 4.9 and as well as the one provided with arduino 
itself (4.3.2).

Original issue reported on code.google.com by johnpatc...@googlemail.com on 31 Jul 2014 at 12:08

GoogleCodeExporter commented 9 years ago
Hi,
Got the same problem, I think I found why, this is because the text section 
defined for the linker on the Makefile does not take into account the new size 
and start program at 0x7e00 :

atmega328: LDSECTIONS  = -Wl,--section-start=.text=0x7e00 
-Wl,--section-start=.version=0x7ffe

may be it should be replaced by 

atmega328: LDSECTIONS  = -Wl,--section-start=.text=0x7c00 
-Wl,--section-start=.version=0x7ffe

To work in both case, try this but in this case you need to pass BIGBOOT=1 to 
the command line parameter and let the optiboot.c source code untouched

ifdef BIGBOOT
atmega328: LDSECTIONS  = -Wl,--section-start=.text=0x7c00 
-Wl,--section-start=.version=0x7ffe
else
atmega328: LDSECTIONS  = -Wl,--section-start=.text=0x7e00 
-Wl,--section-start=.version=0x7ffe
endif

I'm not sure, need to be tested, let me know ;-)

Original comment by ch.hall...@gmail.com on 7 Aug 2014 at 9:11

GoogleCodeExporter commented 9 years ago
Yes; currently BIGBOOT doesn't adjust the start addresses, and only works if 
the part has a bigger boot section by default; it's more designed to go with 
the other chip targets (644, 1280, etc.)

Original comment by wes...@gmail.com on 14 Aug 2014 at 6:28