From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 05 Feb 2024 21:49:32 +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 1rX5uE-004jFD-39 for lore@lore.pengutronix.de; Mon, 05 Feb 2024 21:49:32 +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 1rX5uF-0006XL-NV; Mon, 05 Feb 2024 21:49:31 +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 1rX5u5-0006Ww-8V for ptxdist@pengutronix.de; Mon, 05 Feb 2024 21:49:21 +0100 Received: from mout17.gn-server.de ([87.238.194.244]) by mout39.gn-server.de with esmtp (Exim 4.92) (envelope-from ) id 1rX5u4-00058f-NB; Mon, 05 Feb 2024 20:49:20 +0000 Received: from pp2.greatnet.de ([178.254.50.206]) by mout17.gn-server.de with esmtp (Exim 4.92) (envelope-from ) id 1rX5u4-0002Ob-65; Mon, 05 Feb 2024 20:49:20 +0000 Received: from localhost (089144195134.atnat0004.highway.a1.net [89.144.195.134]) by pp2.greatnet.de (Postfix) with ESMTPSA id ABFF541C5014; Mon, 5 Feb 2024 21:49:18 +0100 (CET) Authentication-Results: pp2.greatnet.de; spf=pass (sender IP is 89.144.195.134) smtp.mailfrom=sebastian.muxel@entner-electronics.com smtp.helo=localhost Received-SPF: pass (pp2.greatnet.de: connection is authenticated) Date: Mon, 5 Feb 2024 21:49:16 +0100 From: Sebastian Muxel To: ptxdist@pengutronix.de, christian.melki@t2data.com Message-ID: <3zf2idbmoykcvgqcjdd25hq3q43uui2teou6naqpwxqgxhogn2@lbpoiotzoupu> References: <20240205201844.65771-2-sebastian.muxel@entner-electronics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-PPP-Message-ID: <20240205204919.27687.12048@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.9 required=4.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [ptxdist] [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 >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 Regards, Sebastian