From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 15 Feb 2024 11:03:51 +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 1raYat-007I6w-1R for lore@lore.pengutronix.de; Thu, 15 Feb 2024 11:03:51 +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 1raYas-0004mO-R8; Thu, 15 Feb 2024 11:03:50 +0100 Received: from mail.thorsis.com ([92.198.35.195]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1raYae-0004m3-Rx for ptxdist@pengutronix.de; Thu, 15 Feb 2024 11:03:38 +0100 Date: Thu, 15 Feb 2024 11:03:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thorsis.com; s=default; t=1707991416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type:in-reply-to:in-reply-to: references:references; bh=rjib7EQ2Z3bZzrL0G5J0yyxjpDcWZOwbKUjZDyGr+Xc=; b=RDkUTTzGh/VGSnDyDPhJQGDJatxeWjO0cZV1E1qq3RGR2QKJZJqofUEqftE3Agp0pRedNd rpCOB+s1OuROmR8pTjgLLlhzQOfpzMpSjIS+qa7ojoytLyOBv+pdFOcZHGR7g95NxW/3Up Qb6WQCTZLWCmruao9mirb4qc1FK7PoQbEJ3BOXUdHL8uVN+Zh9hGCRJWxzC4qLi2/NWT7H 8PDLnO3yfk4Q4bSgxvJwTwgKq9CNvdEVNHwCb8grzk/+KeVIlTzpijYFKbpimxFOHICQXl KTf9ezK9B85/B7Ud09MJLC9IOZTcMzutssxbBrbUGXYP2NG9Wj1XC0Pf3jT0DQ== From: Alexander Dahl To: Sebastian Muxel Message-ID: <20240215-support-broiling-d6d2720bfcfd@thorsis.com> Mail-Followup-To: Sebastian Muxel , ptxdist@pengutronix.de, christian.melki@t2data.com References: <20240205201844.65771-2-sebastian.muxel@entner-electronics.com> <3zf2idbmoykcvgqcjdd25hq3q43uui2teou6naqpwxqgxhogn2@lbpoiotzoupu> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3zf2idbmoykcvgqcjdd25hq3q43uui2teou6naqpwxqgxhogn2@lbpoiotzoupu> 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=-2.8 required=4.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Cc: christian.melki@t2data.com, 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 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