Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hexls improvement to deal better with optiboot hex files #9

Closed
mcuee opened this issue Nov 23, 2022 · 3 comments
Closed

hexls improvement to deal better with optiboot hex files #9

mcuee opened this issue Nov 23, 2022 · 3 comments

Comments

@mcuee
Copy link

mcuee commented Nov 23, 2022

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
Copy link
Owner

stefanrueger commented Nov 23, 2022

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? avrdudes/avrdude#1171 (comment)

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
Copy link
Author

mcuee commented Nov 23, 2022

Faire enough. I will close this issue.

@mcuee mcuee closed this as completed Nov 23, 2022
@mcuee
Copy link
Author

mcuee commented Nov 23, 2022

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

From: avrdudes/avrdude#1171 (comment)
@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants