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.

Hello Gregor,

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

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

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.

al@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.
al@legion:~/src$ cd optiboot.git/optiboot/bootloaders/optiboot/
al@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ mv
optiboot_atmega328.hex optiboot_atmega328.hex.orig
al@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ make clean
rm -rf *.o *.elf *.lst *.map *.sym *.lss *.eep *.srec *.bin *.hex *.tmp.sh
al@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
al@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ diff -u
optiboot_atmega328.hex.orig optiboot_atmega328.hex
al@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ cat
optiboot_atmega328.hex | awk -v FS="" '/^:027FFE00/{print $13 "."
$11}'
8.3

al@legion:~/src/optiboot.git/optiboot/bootloaders/optiboot$ cd
/usr/share/arduino/hardware/arduino/avr/bootloaders/optiboot
al@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
al@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.

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,