Re: [ptxdist] *****POSSIBLE SPAM***** Re: [PATCH] u-boot: Allow specification of padding byte for custom env images
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
Re: [ptxdist] [PATCH] u-boot: Allow specification of padding byte for custom env images
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 09:49:16PM +0100 schrieb Sebastian Muxel: > 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? 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? > I honestly haven't put much further thought into it and assumed it's due > to the way NAND erasure works 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. Greets Alex
[ptxdist] [PATCH] mesalib: version bump 23.3.5 -> 24.0.1
https://docs.mesa3d.org/relnotes/24.0.0.html https://docs.mesa3d.org/relnotes/24.0.1.html Signed-off-by: Philipp Zabel --- rules/host-mesalib.make | 1 + rules/mesalib.in| 12 rules/mesalib.make | 8 ++-- 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/rules/host-mesalib.make b/rules/host-mesalib.make index 5a26a798077e..f353f8f434e8 100644 --- a/rules/host-mesalib.make +++ b/rules/host-mesalib.make @@ -20,6 +20,7 @@ HOST_MESALIB_CONF_OPT := \ $(HOST_MESON_OPT) \ -Dallow-kcmp=enabled \ -Dandroid-libbacktrace=disabled \ + -Dandroid-strict=true \ -Dandroid-stub=false \ -Dbuild-aco-tests=false \ -Dbuild-tests=false \ diff --git a/rules/mesalib.in b/rules/mesalib.in index fbadcef9a528..0c911d2166aa 100644 --- a/rules/mesalib.in +++ b/rules/mesalib.in @@ -192,6 +192,18 @@ config MESALIB_VIDEO_H265ENC bool prompt "H.265 encoding" +config MESALIB_VIDEO_AV1DEC + bool + prompt "AV1 decoding" + +config MESALIB_VIDEO_AV1ENC + bool + prompt "AV1 encoding" + +config MESALIB_VIDEO_VP9DEC + bool + prompt "VP9 decoding" + endmenu endif diff --git a/rules/mesalib.make b/rules/mesalib.make index 23ff34c5a6ec..091d425b8c94 100644 --- a/rules/mesalib.make +++ b/rules/mesalib.make @@ -14,8 +14,8 @@ PACKAGES-$(PTXCONF_MESALIB) += mesalib # # Paths and names # -MESALIB_VERSION:= 23.3.5 -MESALIB_MD5:= 47c97505ed37d81e848545671654d887 +MESALIB_VERSION:= 24.0.1 +MESALIB_MD5:= 9e7fa53b68fa6b60dba0bbfa8da7d0a9 MESALIB:= mesa-$(MESALIB_VERSION) MESALIB_SUFFIX := tar.xz MESALIB_URL:= \ @@ -97,6 +97,9 @@ MESALIB_VIDEO_CODECS-$(PTXCONF_MESALIB_VIDEO_H264DEC) += h264dec MESALIB_VIDEO_CODECS-$(PTXCONF_MESALIB_VIDEO_H264ENC) += h264enc MESALIB_VIDEO_CODECS-$(PTXCONF_MESALIB_VIDEO_H265DEC) += h265dec MESALIB_VIDEO_CODECS-$(PTXCONF_MESALIB_VIDEO_H265ENC) += h265enc +MESALIB_VIDEO_CODECS-$(PTXCONF_MESALIB_VIDEO_AV1DEC) += av1dec +MESALIB_VIDEO_CODECS-$(PTXCONF_MESALIB_VIDEO_AV1ENC) += av1enc +MESALIB_VIDEO_CODECS-$(PTXCONF_MESALIB_VIDEO_VP9DEC) += vp9dec ifdef PTXCONF_ARCH_X86 MESALIB_VULKAN_DRIVERS-$(PTXCONF_MESALIB_VULKAN_AMD) += amd @@ -144,6 +147,7 @@ MESALIB_CONF_OPT:= \ $(CROSS_MESON_USR) \ -Dallow-kcmp=enabled \ -Dandroid-libbacktrace=disabled \ + -Dandroid-strict=true \ -Dandroid-stub=false \ -Dbuild-aco-tests=false \ -Dbuild-tests=false \ -- 2.39.2
