Bug#985578: arduino-core-avr: Flashing bootloader fails due to invalid size

[Gregor Riepl]

Package: arduino-core-avr
Version: 1.8.3+dfsg1-1
Severity: important
X-Debbugs-Cc: ***@gmail.com

Dear Maintainer,

The Arduino bootloader binaries shipped in Debian cannot be flashed to Arduino
devices, because they are too big. I tested only with the Arduino Uno, but
others may be affected as well.

Trying to flash leads to the following error:

$ /usr/bin/avrdude -v -patmega328p -cusbtiny
-Uflash:w:/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.hex:i

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be
performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: Using SCK period of 10 usec
avrdude: reading input file
"/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.hex"
avrdude: ERROR: address 0x8010 out of range at line 33 of
/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.hex
avrdude: read from file
'/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.hex'
failed

Running avr-size on this file returns:

avr-size
/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.hex
text data bss dec hex filename
0 534 0 534 216
/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.hex

The maximum size for the Arduino Uno bootloader is 512 bytes, at least that's
what the boards.txt has configured by default. Larger loaders are possible, but
require manual modifications of the fuse bits, the Arduino board configuration
and the offsets in the .hex file.

Please ensure that this bootloader does not exceed 512 bytes when building the
package. It's likely that the increase in size was caused by a recently updated
avr-gcc. I don't know if there are any compiler options or patches to reduce
the size to less than 512 bytes again. As a workaround, it may be possible to
set the start address to 0x7c00 (from 0x7e00) and change the sizes and fuse
bits in boards.txt to accommodate the larger bootloader.

Thank you.

-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-
debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages arduino-core-avr depends on:
ii avr-libc 1:2.0.0+Atmel3.6.2-1.1
ii gcc-avr 1:5.4.0+Atmel3.6.2-1+b1

arduino-core-avr recommends no packages.

arduino-core-avr suggests no packages.

-- no debconf information

-- debsums errors found:

[Carsten Schoenert]

Hello Gregor,

Am Sat, Mar 20, 2021 at 11:33:48AM +0100 schrieb Gregor Riepl:
...

Post by Gregor Riepl
Please ensure that this bootloader does not exceed 512 bytes when building the
package. It's likely that the increase in size was caused by a recently updated
avr-gcc. I don't know if there are any compiler options or patches to reduce
the size to less than 512 bytes again. As a workaround, it may be possible to
set the start address to 0x7c00 (from 0x7e00) and change the sizes and fuse
bits in boards.txt to accommodate the larger bootloader.

you hit some more issue we currently have with these files.
A lot of them we can't currently rebuild at all and due this we can't
ship them.

We have written some notes about the known problems to
/usr/share/doc/arduino-core-avr/README.Debian and it seems this should
get extended about this new issue.

So far I know upstream is aware about the underlying problem that all
build targets needs to get adjusted to current avr-gcc versions, if I
remember right there is some issue about this in on GitHub within the
Git tree.
The Debian version of avr-gcc is lacking maintenance regarding newer
versions. Due this I wont spend time on potential bug fixing, it's more
efficient to pick the original .hex file from the Git tree of
arduino-core-avr. Without the help from Arduino devs or some more
experienced users I see no fixing of the reported problem in the near
future. Sorry about this probably not satisfying answer.

Regards
Carsten

[Gregor Riepl]

Post by Carsten Schoenert
you hit some more issue we currently have with these files.
A lot of them we can't currently rebuild at all and due this we can't
ship them.
We have written some notes about the known problems to
/usr/share/doc/arduino-core-avr/README.Debian and it seems this should
get extended about this new issue.
So far I know upstream is aware about the underlying problem that all
build targets needs to get adjusted to current avr-gcc versions, if I
remember right there is some issue about this in on GitHub within the
Git tree.
The Debian version of avr-gcc is lacking maintenance regarding newer
versions. Due this I wont spend time on potential bug fixing, it's more
efficient to pick the original .hex file from the Git tree of
arduino-core-avr. Without the help from Arduino devs or some more
experienced users I see no fixing of the reported problem in the near
future. Sorry about this probably not satisfying answer.

Yes, I have found a few references that relate to this problem:
https://github.com/thseiler/embedded/issues/9
https://stackoverflow.com/questions/32540418/avr-gcc-compiles-too-large-optiboot-hex-to-suit/32541098#32541098
https://forum.arduino.cc/index.php?topic=128752.0
https://forum.arduino.cc/index.php?topic=657971.0
https://web.archive.org/web/20160817171346/http://code.google.com/p/optiboot/issues/detail?id=54

The hint given in the first and second link (use an older avr-gcc) is
not really feasible in Debian, sadly. And the others are from very long
ago, so they may not even be relevant any more.

In the meantime, I think it would be ok with binaries from upstream in
Debian contrib (I assume they would be ok there, as the source code is
covered by the DFSG). Not the best solution for people who want to just
"use" Arduino, but at least it will unbreak the package.

Feel free to lower the severity of the issue if you like.

[Alexander Buzin]

***@legion:~/src$ git clone https://github.com/Optiboot/optiboot.git optiboot.git
Cloning into 'optiboot.git'...
remote: Enumerating objects: 1965, done.
remote: Counting objects: 100% (240/240), done.
remote: Compressing objects: 100% (127/127), done.
remote: Total 1965 (delta 137), reused 178 (delta 86), pack-reused 1725
Receiving objects: 100% (1965/1965), 1.40 MiB | 4.93 MiB/s, done.
Resolving deltas: 100% (1048/1048), done.
***@legion:~/src$ cd optiboot.git/optiboot/bootloaders/optiboot/
***@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ mv
optiboot_atmega328.hex optiboot_atmega328.hex.orig
***@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ make clean
rm -rf *.o *.elf *.lst *.map *.sym *.lss *.eep *.srec *.bin *.hex *.tmp.sh
***@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ make atmega328
avr-gcc (GCC) 5.4.0
Copyright (C) 2015 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, Difference=2.1%
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p
-DF_CPU=16000000L -DBAUD_RATE=115200 -DLED_START_FLASHES=3
-c -o optiboot.o optiboot.c
optiboot.c:429:2: warning: #warning BAUD_RATE off by greater than 2% [-Wcpp]
#warning BAUD_RATE off by greater than 2%
^
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p
-DF_CPU=16000000L -DBAUD_RATE=115200 -DLED_START_FLASHES=3
-Wl,-Tlink_optiboot.ld -Wl,--relax -nostartfiles -o
optiboot_atmega328.elf optiboot.o
avr-size optiboot_atmega328.elf
text data bss dec hex filename
474 0 0 474 1da optiboot_atmega328.elf
avr-objcopy -j .text -j .data -j .version --set-section-flags
.version=alloc,load -O ihex optiboot_atmega328.elf
optiboot_atmega328.hex
avr-objdump -h -S optiboot_atmega328.elf > optiboot_atmega328.lst
rm optiboot.o
***@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ diff -u
optiboot_atmega328.hex.orig optiboot_atmega328.hex
***@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ cat
optiboot_atmega328.hex | awk -v FS="" '/^:027FFE00/{print $13 "."
$11}'
8.3

***@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ cd
/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot
***@legion:/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot$
avr-size optiboot_atmega328.hex
text data bss dec hex filename
0 534 0 534 216 optiboot_atmega328.hex
***@legion:/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot$
cat optiboot_atmega328.hex | awk -v FS="" '/^:027FFE00/{print $13 "."
$11}'
4.4

My system is Debian bullseye+backports. No foreign apps.
It seems that Debian includes an ancient version of optiboot (v.4.4 of
January 2012). It is unusable because the size of the resulting
bootloader is too big. Current version (v.8.3) can be compiled with
our default toolchain and produces a hex file which has correct size
and is identical to the one on the optiboot github (see the line above
with diff).
Maybe this information will be of some use, because the current
situation with non working bootloader is quite inconvenient.

Kind regards,
Alex.

[Rock Storm]

Post by Alexander Buzin
My system is Debian bullseye+backports. No foreign apps.
It seems that Debian includes an ancient version of optiboot (v.4.4 of
January 2012). It is unusable because the size of the resulting
bootloader is too big. Current version (v.8.3) can be compiled with
our default toolchain and produces a hex file which has correct size
and is identical to the one on the optiboot github (see the line above
with diff).
Maybe this information will be of some use, because the current
situation with non working bootloader is quite inconvenient.

Thank you for you addition here.

I apologise in advance, I lack the knowledge/time to thoroughly test
this. But reading this got me thinking.

Open question to all list readers, am I right in thinking that:

- Current avr-gcc toolchain is able to successfully compile the latest
optiboot (i.e. v8.0?)

- Current arduino package (version 2:1.8.16+dfsg1-1~bpo11+1) is happy
with the hex files generated above.

Since we simply ship the very optiboot version that Arduino ships on
its ArduinoCore-avr repository. I'd conclude there is no other solution
than to request upstream the latest optiboot be shipped in the next
release? It's probably been requested already as in [1] but has seen no
movement in 4 years. Are there any big regression issues between
optiboot's versions 4.4 and 8.0?

[1]: https://github.com/arduino/ArduinoCore-avr/issues/121

Regards,

--
Rock Storm
Open PGP: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD