Fix writing to eMMC in U-Boot on Green #3412
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When Green starts, there is an error indicating the MMC write failed when saving the bootstate: storing env... MMC write: dev # 0, block # 1214464, count 64 ... mmc write failed 0 blocks written: ERROR This results in the boot count not being updated properly if the boot fails. Seems to be a known issue for this platform, disabling the DDR52 mode (which is the same what upstream does for other RK356x boards [1]) fixes the issues and the bootstate is updated correctly. [1] https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
Merged
sairon
added a commit
that referenced
this pull request
Aug 8, 2024
Apply the same patch we applied in #3412 for Green. At that time I thought the patch was already applied upstream for M1 and haven't checked, but it turns out it wasn't true. Apply it here before we get U-Boot with that patch series [1] included. [1] https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/
sairon
added a commit
that referenced
this pull request
Aug 8, 2024
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in the original patch series we took inspiration from that HS200 works more reliably, so enable it in Green's defconfig by amending the patch.
sairon
added a commit
that referenced
this pull request
Aug 8, 2024
Apply the same patch we applied in #3412 for Green. At that time I thought the patch was already applied upstream for M1 and haven't checked, but it turns out it wasn't true. Apply it here before we get U-Boot with that patch series [1] included. [1] https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/
sairon
added a commit
that referenced
this pull request
Aug 8, 2024
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in the original patch series we took inspiration from that HS200 works more reliably, so enable it in Green's defconfig by amending the patch.
sairon
added a commit
that referenced
this pull request
Aug 8, 2024
Apply the same patch we applied in #3412 for Green. At that time I thought the patch was already applied upstream for M1 and haven't checked, but it turns out it wasn't true. Apply it here before we get U-Boot with that patch series [1] included. [1] https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ (cherry picked from commit d6fa83a)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When Green starts, there is an error indicating the MMC write failed when saving the bootstate:
This results in the boot count not being updated properly if the boot fails.
Seems to be a known issue for this platform, disabling the DDR52 mode (which is the same what upstream does for other RK356x boards [1]) fixes the issues and the bootstate is updated correctly.
[1] https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/