From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 15 Feb 2024 11:35:43 +0100 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1raZ5j-007JSB-0Z for lore@lore.pengutronix.de; Thu, 15 Feb 2024 11:35:43 +0100 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1raZ5i-0007tK-Kj; Thu, 15 Feb 2024 11:35:42 +0100 Received: from mout39.gn-server.de ([87.238.197.45]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1raZ5R-0007sy-Aw for ptxdist@pengutronix.de; Thu, 15 Feb 2024 11:35:26 +0100 Received: from mout17.gn-server.de ([87.238.194.244]) by mout39.gn-server.de with esmtp (Exim 4.92) (envelope-from ) id 1raZ5Q-0000AC-Mb; Thu, 15 Feb 2024 10:35:24 +0000 Received: from pp2.greatnet.de ([178.254.50.206]) by mout17.gn-server.de with esmtp (Exim 4.92) (envelope-from ) id 1raZ5Q-0004qP-GP; Thu, 15 Feb 2024 10:35:24 +0000 Received: from localhost (unknown [91.112.117.82]) by pp2.greatnet.de (Postfix) with ESMTPSA id 8AA1841C023B; Thu, 15 Feb 2024 11:35:23 +0100 (CET) Authentication-Results: pp2.greatnet.de; spf=pass (sender IP is 91.112.117.82) smtp.mailfrom=sebastian.muxel@entner-electronics.com smtp.helo=localhost Received-SPF: pass (pp2.greatnet.de: connection is authenticated) Date: Thu, 15 Feb 2024 11:35:23 +0100 From: Sebastian Muxel To: ptxdist@pengutronix.de, christian.melki@t2data.com Message-ID: References: <20240205201844.65771-2-sebastian.muxel@entner-electronics.com> <3zf2idbmoykcvgqcjdd25hq3q43uui2teou6naqpwxqgxhogn2@lbpoiotzoupu> <20240215-support-broiling-d6d2720bfcfd@thorsis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20240215-support-broiling-d6d2720bfcfd@thorsis.com> X-PPP-Message-ID: <20240215103523.20490.43268@pp2.greatnet.de> X-PPP-Vhost: entner-electronics.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.whiteo.stw.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-1.4 required=4.0 tests=AWL,BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [ptxdist] *****POSSIBLE SPAM***** Re: [PATCH] u-boot: Allow specification of padding byte for custom env images X-BeenThere: ptxdist@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de Sender: "ptxdist" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ptxdist-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false 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