hd-image: add support for specifying byte value used for filling #274
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
Today I was fooled by the combination of (1) util.c being quite clever/aggressive with respect to creating sparse images and avoiding writing zeroes explicitly and (2) using bmaptool to populate an SD card, thus being aware of unwritten regions of the image. Specifically, I had a U-Boot environment partition where I now set "fill = true", so that any trace of the previous environment should be gone, and U-Boot on first boot should just use its default/static environment. But that was not what I observed: After writing the sd card, the U-Boot partition still has its old content, meaning that the new U-Boot ended up using a completely wrong environment. In order to be sure that such a partition is definitely overwritten, allow specifiyng the byte value used for filling. Any non-zero value should work fine. Alternatively/additionally, we could consider relaxing the sparseness, so that, say, the first 4096 bytes of the padding are always explicitly written. But I don't know if bmaptool is so "smart" that it checks whether it has a full 4096 bytes of zeroes and then turning that into a sparse write anyway. Signed-off-by: Rasmus Villemoes <[email protected]>
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.
Today I was fooled by the combination of (1) util.c being quite clever/aggressive with respect to creating sparse images and avoiding writing zeroes explicitly and (2) using bmaptool to populate an SD card, thus being aware of unwritten regions of the image.
Specifically, I had a U-Boot environment partition where I now set "fill = true", so that any trace of the previous environment should be gone, and U-Boot on first boot should just use its default/static environment.
But that was not what I observed: After writing the sd card, the U-Boot partition still has its old content, meaning that the new U-Boot ended up using a completely wrong environment.
In order to be sure that such a partition is definitely overwritten, allow specifiyng the byte value used for filling. Any non-zero value should work fine.
Alternatively/additionally, we could consider relaxing the sparseness, so that, say, the first 4096 bytes of the padding are always explicitly written. But I don't know if bmaptool is so "smart" that it checks whether it has a full 4096 bytes of zeroes and then turning that into a sparse write anyway.