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

overall option code rework #927

Merged
merged 10 commits into from Apr 19, 2020

Conversation

grevaillot
Copy link
Collaborator

hi,

Continuing my work on g4 fixes, i added support for g0/g4 chips option read/write, and spend a bit of time on option code cleanup/rework.

basically, I moved some device specific code out of st-flash util, aligned api regarding option/read write device specific code and added device specific parameter to chipid database, allowing some sanity checks before writing and some generic option read code. all devices are now using the same code to flash option, not depending on st-flash parameters.

  • write --area-option "option integer in hex"
  • write option.bin "option address" (not documented afaik)
  • read --area-option

note that current option write code mostly only support writing the first 32bits of option bytes, nor reading more, so this need some more reviews / rework to be safe, but i think this is not less safe than previously - currently option size is hardcoded to 32bits for concerned/not tested chips.

I can maybe split pr, this went a bit wild while attempting to add my stuff..

@grevaillot
Copy link
Collaborator Author

derp, merge issue, lemme see..

User could get a wrong "stlink_fread()" error in case of bad stlink_read_option_foo..
use g0 code, same logic with different base address.
also cleanup some duplicate lock/unlock code.
unify option bytes read/write, interface, use chipid db to store size and base
to provide some write sanity check and generic option read code.
current opt parse code can make bad cmdline parameter attempt to flash bad
flash option.

ie: calling st-flash write --area=option a_file.bin

will make parser attempt to translate "a_file.bon" to an uint32 and will return 0..,
avoid some potential issues later.
@grevaillot
Copy link
Collaborator Author

pushed force, better, not sure what happened

@Nightwalker-87
Copy link
Member

Great! Give me some time to review. I don't mind though if you add further commits in the meanwhile, if you feel like it. To me PRs don't necessarily need to stay below a certain size as long as they focus on one topic. Keep up the good work! 👍

src/common.c Outdated Show resolved Hide resolved
src/common.c Outdated Show resolved Hide resolved
@Nightwalker-87 Nightwalker-87 moved this from In progress to Review in progress in Release v1.6.1 Apr 16, 2020
@grevaillot
Copy link
Collaborator Author

i've got a bigger patch to come with more refactoring, but this will need some testing and a bit of time .. that one can be merged i think

Release v1.6.1 automation moved this from Review in progress to Reviewer approved Apr 19, 2020
@Nightwalker-87 Nightwalker-87 merged commit fc72b92 into stlink-org:develop Apr 19, 2020
Release v1.6.1 automation moved this from Reviewer approved to Done Apr 19, 2020
@Nightwalker-87
Copy link
Member

Thank you!

@stlink-org stlink-org locked as resolved and limited conversation to collaborators May 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants