Skip to content

Rt1010 sdphost always write to flash#98

Merged
hathach merged 2 commits into
masterfrom
rt1010-sdphost-overwrite
Mar 19, 2021
Merged

Rt1010 sdphost always write to flash#98
hathach merged 2 commits into
masterfrom
rt1010-sdphost-overwrite

Conversation

@hathach
Copy link
Copy Markdown
Member

@hathach hathach commented Mar 19, 2021

Use bootmode from SRC->SBMR2 to determine whether we are in Serial Download mode. If so write the tinyuf2 image to flash. So basically everytime SDPHost is uesd, it will write contents to flash. This works better as

  • recovery method or when reworking components swapping mcu and/or flash chip.
  • prototyping/simulate other boards e.g using evk board without actually drag & drop uf2 once loaded via SDP
  • At worse, user load SDP with the same image on flash, the write caching will compare with existing contents and won't perform any erase/write op.

@nxf58843 @gsteiert would you mind reviewing the PR, also please accept the contributor invitation, it make requesting you as reviewer much easier in the future

@hathach hathach changed the title Rt1010 sdphost overwrite Rt1010 sdphost always write to flash Mar 19, 2021
@hathach hathach requested a review from nxf58843 March 19, 2021 15:16
Copy link
Copy Markdown
Collaborator

@nxf58843 nxf58843 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try to check on hardware this weekend.

Note1: `sdphost` executable binaries for common platforms (windows/mac/linux) are included in sdphost folder. If you have issue with executable permission, just manually give it permission to run. The source code for sdphost tool is also included just in case binaries for your host platform is not included (e.g ARM, RISC-V etc ...)

Note2: Since SDP with BootROM doesn't requires external debugger and always exists regardless of the external flash, this method can also be used to de-brick your board should it needs.
Note2: Since SDP with BootROM doesn't requires external debugger and always exists regardless of the external flash, this method can also be used to de-brick your board should it needs.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"should it be necessary" or "should it be needed" would be better grammatically

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will fix it.

Comment on lines +60 to +61
uint32_t const boot_mode = (SRC->SBMR2 & SRC_SBMR2_BMOD_MASK) >> SRC_SBMR2_BMOD_SHIFT;
if (boot_mode == 1)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we check the revision to prevent accidentally downgrading?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought of this, however there is actually no need to check against SDP. SDP is either production mode or the desperate mode. When used it should just overwrite whatever on the flash.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is safest for de-bricking. There is an outside chance that they grab an older .bin than was previously loaded on the board but if they switched to serial download mode it is probably safer to let them load it anyway.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, for version stepping, it is doable in much easier way with drag & drop update-tinyuf2.uf2 is really the de-brick move when user accidentally corrupt flash config and/or bootloader

@hathach
Copy link
Copy Markdown
Member Author

hathach commented Mar 19, 2021

@nxf58843 thank you for reviewing, I have tried it locally and it works well. Since there are several folks at Adafruit working on and need this to test out the prototype hardware. I will merge it now, should there is any issues, we will fix it with follow up PR.

@hathach hathach merged commit c0ead30 into master Mar 19, 2021
@hathach hathach deleted the rt1010-sdphost-overwrite branch March 19, 2021 16:21
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

Successfully merging this pull request may close these issues.

2 participants