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

Add GNU Build ID to identify firmware #219

Merged
merged 2 commits into from
Jun 6, 2019

Conversation

salkinium
Copy link
Member

This uses the GNU Build ID to properly identify firmware and uses this mechanism instead of CRC32 for the coredump functionality added in #52.

Adds 32 bytes containing a 160-bit SHA1 to the firmware.
Inspired by https://interrupt.memfault.com/blog/gnu-build-id-for-firmware.

cc @dergraaf: This solves my dependence on objcopy and reads the data directly from the ELF file.

@salkinium
Copy link
Member Author

The build id should also be added for AVRs

@strongly-typed
Copy link
Collaborator

Are you aware that for the NXP chips there shall be a checksum in the hexfile?
openocd complains (and fixes it before writing to the flash). Verification fails

** Programming Started **
Warn : Verification will fail since checksum in image (0x000004e9) to be written to flash is different from calculated vector checksum (0xefffd63e).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
** Programming Finished **

Could the calculation of this checksum already be added here?

@salkinium
Copy link
Member Author

What fresh hell is this?!?
This can’t work of course since both checksums would change each other.
Maybe putting the GNU ID section to the very end could help? Checking the source code for GNU LD for NXP targets could help, since this checksum must be explicitly coded?

@salkinium
Copy link
Member Author

salkinium commented Jun 1, 2019

Note: This checksum is calculated from the contents of the vector table, not the whole image. For more details please see the user manual for the MCU that you are using.

But hang on, the GNU ID doesn’t change the vector table, the 0x4e9 value is probably the address to the Undefined_Handler. The checksum is probably never computed, so this seems like a separate issue.

@salkinium
Copy link
Member Author

The build id should also be added for AVRs

I didn't get this to work. The .note.gnu.build-id section doesn't contain any program headers, so avrdude doesn't load this section. Unfortunately all AVR linkerscripts predefine this section outside of the flash memory, so I cannot overwrite that with our custom linkerscript addition.
For hosted-darwin the linker does not support GNU LD flags anyways, and for hosted-linux I cannot reference the section, since the assembler does not accept the hyphen in build-id from the section name 🙄.

I'll leave this unimplemented for AVR and Hosted (for now).

@salkinium salkinium merged commit a607613 into modm-io:develop Jun 6, 2019
@salkinium salkinium deleted the feature/build_id branch July 11, 2019 06:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants