hexls improvement to deal better with optiboot hex files

[mcuee]

I am not so sure if this is easy or not as we may need to understand more about optiboot. Right now only limited attributes are printed.

C:\work\avr\urboot\src\all [main ≡ +22 ~1286 -448 !]> perl ..\hexls .\bigboot_328.hex
710 1024 o8.3 -.s-.-r-- .\bigboot_328.hex
C:\work\avr\urboot\src\all [main ≡ +22 ~1286 -448 !]> perl ..\hexls .\optiboot_atmega328.hex
474 512 o8.3 -.s-.-r-- .\optiboot_atmega328.hex

[stefanrueger]

The dot . means hexls is unable to tell from the binary whether the bootloader has that feature.

$ hexls -md "" all/optiboot_atmega328.hex 
|Size|Usage|Version|Features|Hex file|
|:-:|:-:|:-:|:-:|:--|
|474|512|o8.3|`-.s-.-r--`|all/optiboot_atmega328.hex|

- **Size:** Bootloader code size including small table at top end
- **Usage:** How many bytes of flash are needed, ie, HW boot section or a multiple of the page size
- **Version:** For example, u7.6 is an urboot version, o5.2 is an optiboot version
- **Features:**
  + `s` uses skeleton of STK500v1 protocol (deprecated); `-c urclock` and `-c arduino` both work
  + `r` preserves reset flags for the application in the register R2
  + `.` unable to tell from .hex file whether this feature is present
  + `-` corresponding feature not present
- **Hex file:** typically MCU name, oscillator frequency (16 MHz default) and baud rate (115200 default) followed by

Remember the questions we asked Bill Westfield? https://github.com/avrdudes/avrdude/pull/1171#issuecomment-1312760476

I don't think there is an easy answer, and hashing known bootloaders is too complex (and frankly, undesirable) for this little helper file hexls that I wrote to ease development.

[mcuee]

Faire enough. I will close this issue.

[mcuee]

Still @WestfW, just wondering if you can answer the question from @stefanrueger. Thanks.

From: https://github.com/avrdudes/avrdude/pull/1171#issuecomment-1312760476 @WestfW In order to better support the existing optiboot bootloaders from, say, version 4.1 that are out there on millions of chips

• How can AVRDUDE tell how many pages the optiboot binary occupies?
• How can AVRDUDE tell whether the optiboot binary can read/write EEPROM?
• How can AVRDUDE tell whether the optiboot binary is a vector bootloader or not? If so, which vector was used?

(as background, AVRDUDE can read all flash locations of the connected MCU. Currently it detects the presence of optiboot by the last byte in flash being between 4 and 55; the major version number that optiboot puts there; urboot uses that byte to pack both major and minor version number in there so that this byte is between 56 and 254).