Hello Sebastian,
regarding your patch itself, please check indentation in Kconfig help.
Maybe run `ptxdist lint` before submitting, IIRC that problem is
checked by the linter. The indentation is strange there with tabs
first and two spaces then.
(more comments below)
Am Mon, Feb 05, 2024 at
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?
The tooling screams at me when i don't set it up this way. I'm 100%
certain it's a unfortunate requirement i had to comply with.
You could argue that the
On 2/5/24 21:49, Sebastian Muxel wrote:
> [Du f?r inte e-post ofta fr?n sebastian.mu...@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
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
On 2/5/24 21:16, Sebastian Muxel wrote:
> [Du får inte e-post ofta från sebastian.mu...@entner-electronics.com. Läs om
> varför det här är viktigt på https://aka.ms/LearnAboutSenderIdentification ]
>
> The env image is currently always padded with the default bytes 0xFF.
> New configuration
The env image is currently always padded with the default bytes 0xFF.
New configuration U_BOOT_ENV_IMAGE_CUSTOM_PADDING_BYTES is added
to allow specification for custom env images.
Signed-off-by: Sebastian Muxel
---
platforms/u-boot.in | 9 +
rules/u-boot.make | 1 +
2 files changed,
