Re: [ptxdist] [PATCH] u-boot: Allow specification of padding byte for custom env images

[Christian Melki <christian.melki@t2data.com>]

On 2/5/24 21:49, Sebastian Muxel wrote:
> [Du f?r inte e-post ofta fr?n sebastian.muxel@entner-electronics.com. L?s om varf?r det h?r ?r viktigt p? https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello
> 
>> Just curious. In what situation would you need to alter the default
>> padding bytes? 0xff suits most (if not all) NVM types. Flash transition
>> layers usually just give an illusion of the traditional zero:ed block on
>> flash to block translation?
> 
> I had to tweak it to 0x00 after noticing that the env image generated by
> our vendor supplied SDK has specified it in it's make process. Keeping
> it at 0xFF wouldn't allow me to generate a firmware image. It could likely
> be that it's a hard requirement of their image generation/flashing tool?
> I honestly haven't put much further thought into it and assumed it's due
> to the way NAND erasure works
> 

0x0 looks wrong to me w.r.t most flash media. Also not sure I understand
why 0xff would stop anything from generating a firmware image? That
said, I don't think it matters a lot. It just risks excessive erases the
first time a block is written on media that hasn't got a smart(er) FTL.
It's really not a common thing to want to change, hence the question. :)

For me it's usually the opposite. I want to make sure I don't get fills
with anything else than 0xff.

> Regards,
> Sebastian