Provide bootloader-hash tool

[stefanrueger]

This bash script computes the hash-sum of stk500v1 bootloaders to ease the guesswork of -c urclock. The -c urclock programmer is compatible with -c arduino, but needs to know the size of the bootloader as it protects it externally from being overwritten. In contrast to urboot, optiboot et al binaries do not advertise its size and properties. Hence, urclock.c maintains a table with hash-sums of popular bootloaders that are out there in the wild, so the user doesn't have to know, let alone specify, the size of the bootloader on their devices. This utility computes the table entry from a .hex files in the directory.

[mcuee]

This pull request seems to be good.

 MINGW64 /c/work/avr/avrdude_test/others/optiboot_flash/bootloaders/atmega328p/16000000L
$ ../bootloader-hash
    {  512, 0, 0xc0e0c9aa, 0x9442ebc2 }, // optiboot_flash_atmega328p_UART0_1000000_16000000L_B5.hex
    {  512, 0, 0xc0e0c9aa, 0x2cbe3881 }, // optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex
    {  512, 0, 0xc0e0c9aa, 0x724d0f9f }, // optiboot_flash_atmega328p_UART0_19200_16000000L_B5.hex
    {  512, 0, 0xc0e0c9aa, 0x71500052 }, // optiboot_flash_atmega328p_UART0_250000_16000000L_B5.hex
    {  512, 0, 0xc0e0c9aa, 0x073cb866 }, // optiboot_flash_atmega328p_UART0_38400_16000000L_B5.hex
    {  512, 0, 0xc0e0c9aa, 0xececd8d3 }, // optiboot_flash_atmega328p_UART0_500000_16000000L_B5.hex
    {  512, 0, 0xc0e0c9aa, 0x264469ac }, // optiboot_flash_atmega328p_UART0_9600_16000000L_B5.hex

[mcuee]

@stefanrueger
But I found an issue when testing this pull request. We may need to increase the Windows drain timeout value from 80ms to 150ms for -c urclock.
#1171 (comment)

PS C:\work\avr\avrdude_test\avrdude_main> git diff
diff --git a/src/urclock.c b/src/urclock.c
index 7bfb2d7..f58a2d7 100644
--- a/src/urclock.c
+++ b/src/urclock.c
@@ -2154,7 +2154,11 @@ static int urclock_open(PROGRAMMER *pgm, const char *port) {
     usleep((80+ur.delay)*1000); // Wait until board comes out of reset

   // Drain any extraneous input
+#ifndef WIN32
   serial_drain_timeout = 80;    // ms
+#else
+  serial_drain_timeout = 150;    // ms
+#endif
   serial_drain(&pgm->fd, 0);

   if(urclock_getsync(pgm) < 0)

I am not so sure if you want to include the small change to this PR. or you want to creae a new PR.

[mcuee]

@stefanrueger

Going back to this PR. The only thing is that the user will have to rebuild avrdude if they want to include more optiboot bootloaders. I am thinking we can extend avrdude.conf and user can add more entries with the help of bootloader-hash tool so that -c urclock can be used for more optiboot bootloader hex files.

For example, I hope adding (at least the 115200bps version) of all the optiboot_flash hex files from @MCUdude should not slow down avrdude.

[mcuee]

The only thing is that the user will have to rebuild avrdude if they want to include more optiboot bootloaders. I am thinking we can extend avrdude.conf and user can add more entries with the help of bootloader-hash tool so that -c urclock can be used for more optiboot bootloader hex files.
For example, I hope adding (at least the 115200bps version) of all the optiboot_flash hex files from @MCUdude should not slow down avrdude.

@stefanrueger and @MCUdude

I am thinking that urboot will take time to go into more main stream use. Once avrdude 7.1 is released, maybe @MCUdude can try to add urboot and urclock to his popular Arduino Core (eg: MiniCore, MightyCore and MegaCore). In that case, we will be able to reach many more users.

I understand that Arduino will take time to adopt new version of avrdude (they have not officially adopted 7.0 yet). But I think we can already build good static link avrdude version using the Arduino provided infrastructure, for Linux, macOS and Windows. So it may not be a big issue any more.

• To add arduino avrdude-packing github action to create binary for Linux, macOS and Windows #1162

[stefanrueger]

For example, I hope adding (at least the 115200bps version) of all the optiboot_flash hex files from @MCUdude should not slow down avrdude.

The intention with the hashes of a few popular bootloaders is to make it easy to change from -c arduino to -c urboot. Whilst it would not slow down avrdude (or make it noticeably bigger) to record 12-byte table entries for 10,000 bootloaders, I think it would be unseemly to have these externally in avrdude.conf. Maybe an option to add a couple of them in a private avrdude.conf is OK, though, but there would need to be a mechanism for the users to figure out what they need to put into ~/.avrduderc. The standalone tool is not an option for this; it is meant for developers (and so we don't forget how the hash table was created).

The way I think about this is that arduino's distributed bootloaders should be recognised amongst which is the v4.4 optiboot (that's probably on millions of chips all over the world). People who download and install custom bootloaders, eg, from @MCUdude's repository should be able to cope with an extra parameter -xbootsize=... and be able to hide this in their workflow.

[mcuee]

@stefanrueger

I see your point. Thanks.

I think this PR is good to go now.