On 2/5/24 21:49, Sebastian Muxel wrote: > [Du f?r inte e-post ofta fr?n [email protected]. 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
