From: Sebastian Muxel <sebastian.muxel@entner-electronics.com>
To: ptxdist@pengutronix.de, christian.melki@t2data.com
Subject: Re: [ptxdist] *****POSSIBLE SPAM***** Re: [PATCH] u-boot: Allow specification of padding byte for custom env images
Date: Thu, 15 Feb 2024 11:35:23 +0100 [thread overview]
Message-ID: <x4qfnnbdbyj4jblycboo4w7jz2qiumfzyb6v6rcxnof5mdhnp5@7vcli4lnycw3> (raw)
In-Reply-To: <20240215-support-broiling-d6d2720bfcfd@thorsis.com>
Hello Alexander,
>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.
Thanks for the feedback, i'll keep it in mind with the next patch i'll
send in.
>Interesting. So this env image does not stay standalone, but will be
>integrated in some other packaging? I'm pretty sure U-Boot itself
>does not care about those padding bytes at runtime. Maybe it's a
>thing the flashing tool checks?
It doesn't stay standalone, no, it's bundled together with various other images
into a "full-firmware" image (i.e. env, SPL, FIT image, config) which then get's
flashed onto the device.
>Probably not. If you let a raw NAND flash chip erase itself with the
>proper command, you get all 0xFF afterwards. An intelligent flash
>tool would recognize larger blocks of 0xFF in an image and then just
>not touch the flash in that areas. Writing 0xFF on already erased
>blocks gains nothing. Writing non 0xFF padding is just useless write
>operations and will only decrease the lifetime of the flash.
The padding stops existing inside of the firmware image, so it doesn't
actually get to the point where it would try to write 0x00 onto the NAND
flash.
I honestly thought it's less of a obscure hacky parameter considering
it's one of the few mkenvimage provides but i'll take that it's not of
much use to most people.
Regards,
Sebastian
prev parent reply other threads:[~2024-02-15 10:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 20:16 [ptxdist] " Sebastian Muxel
2024-02-05 20:30 ` Christian Melki
2024-02-05 20:49 ` Sebastian Muxel
2024-02-05 21:07 ` Christian Melki
2024-02-09 17:23 ` Sebastian Muxel
2024-02-15 10:03 ` Alexander Dahl
2024-02-15 10:35 ` Sebastian Muxel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x4qfnnbdbyj4jblycboo4w7jz2qiumfzyb6v6rcxnof5mdhnp5@7vcli4lnycw3 \
--to=sebastian.muxel@entner-electronics.com \
--cc=christian.melki@t2data.com \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox