hd-image: add support for specifying byte value used for filling

[Villemoes]

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.

[Villemoes]

So I realized I might want to force writing zeroes, which this won't enable. So I'm considering three alternatives: (1) Change the fill partition option to tristate no/yes/force (2) Add a default true sparse boolean option to the partition options (so fill=true + sparse=false would be the same as option (1) fill=force), (3) building on top of this MR, let the fill-value be 0x100 and use the low eight bits as the byte value and the extra high bit to indicate "force". The latter is easiest to wire up, as it just means storing the fill value in a uint instead of a uchar, passing that through from insert_image to write_bytes, and then in write_bytes add one more condition to the list of "can we do sparse". But it is also the most hacky.

I'd like to know which of these you'd prefer before I try coding it.

[michaelolbrich]

I think a 'sparse' option makes sense. But that should not just apply to 'fill' but also undo holes from source images.
And if you don't have an actual use-case for a different fill value, I'd prefer to skip that right now.

And please don't do magic with the upper bits. Maye turn part->fill into part->flags variable with bits for fill and sparse.