From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C1E2C433EF for ; Thu, 30 Sep 2021 16:35:45 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7C20461250 for ; Thu, 30 Sep 2021 16:35:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7C20461250 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4F88080F5F; Thu, 30 Sep 2021 18:35:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="uNuxIRxU"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C95D780F6A; Thu, 30 Sep 2021 18:35:40 +0200 (CEST) Received: from ssl.serverraum.org (ssl.serverraum.org [176.9.125.105]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 1569480F16 for ; Thu, 30 Sep 2021 18:35:38 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 4A9C622172; Thu, 30 Sep 2021 18:35:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1633019737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bbTT1q10kZ7pV/hneHMgb6/XXpseS+Cn1ogs0WL2nxw=; b=uNuxIRxUjqCLycCbqNth5uESu15PqMQ2ya+OKL9tg6ULZB//UQ5Ztwt4EhoP1tp+sFBx5z M+Ccv79FmN0rRjXTJyUyplxbAH5tZPfLVD9go9kcWGmi0Pro7hTjpaGOxK/VSwqbjZ/+0u hO5OMmbKumK7P5kAoJGY1u7fFpSItDY= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 Sep 2021 18:35:37 +0200 From: Michael Walle To: Frieder Schrempf Cc: u-boot@lists.denx.de, Heiko Thiery , Frieder Schrempf , Bin Meng , Jagan Teki , Pratyush Yadav , Sean Anderson , Simon Glass Subject: Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update' In-Reply-To: <20210930161926.2748887-1-frieder@fris.de> References: <20210930161926.2748887-1-frieder@fris.de> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <92ca13e960f4e862c0fdd83373255301@walle.cc> X-Sender: michael@walle.cc X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Am 2021-09-30 18:19, schrieb Frieder Schrempf: > In order to support unaligned updates, we simply read the first full > block and check only the requested part of the block for changes. If > necessary, the block is erased, the first (unchanged) part of the block > is written back together with the second part of the block (updated > data). I'm not sure what I should think of this. You might loose that unchanged part if there is an power loss in the middle, even worse, you likely don't have this part anymore because it isn't part of the data you want to write to the flash. Maybe add an parameter for allow (unsafe) unaligned updates? Now you might argue, that with "sf erase, sf write" you can do the same harm, to which i reply: but then it is intentional ;) Because "sf erase" just works on sector boundaries (which isn't really checked in the command, i just realized, but at least my driver returns EINVAL) and then the user has to include the "unchanged part" for the arguments on the commandline. -michael