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 A0FC3C433F5 for ; Thu, 30 Sep 2021 21:08:34 +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 F21C96135E for ; Thu, 30 Sep 2021 21:08:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F21C96135E 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 6AE9580F5F; Thu, 30 Sep 2021 23:08:29 +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="Jp3jPDXH"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AB15180F6A; Thu, 30 Sep 2021 23:08:27 +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 8187880F1A for ; Thu, 30 Sep 2021 23:08:24 +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 B5C6622172; Thu, 30 Sep 2021 23:08:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1633036104; 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=x5GBAY2NZqhHLgz3q/FcAF5SPwOpwqMvSUyksGziLzA=; b=Jp3jPDXHGx8k9SI5KT8KfLQtU0DAKsRefgRFI6IJSMbNs2L6D76jXBpw/L+PV/sbhnc+Jm hDP9xHt7UulnOi8yjKjgHnCTWK++XdUlu4rU0+FKGDbwag/IzcAJGf7frCkE0m0IULXwLs +OuKdg6PDGJj9u1ZuKcWh78fCHGGtVM= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 Sep 2021 23:08:22 +0200 From: Michael Walle To: Frieder Schrempf Cc: Frieder Schrempf , u-boot@lists.denx.de, Heiko Thiery , 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: <0b725bbb-0bc6-2ce3-d861-18bbd8f34059@kontron.de> References: <20210930161926.2748887-1-frieder@fris.de> <92ca13e960f4e862c0fdd83373255301@walle.cc> <0b725bbb-0bc6-2ce3-d861-18bbd8f34059@kontron.de> User-Agent: Roundcube Webmail/1.4.11 Message-ID: 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 19:17, schrieb Frieder Schrempf: > On 30.09.21 18:35, Michael Walle wrote: >> 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. > > True, but "sf update" already is "unsafe" even without supporting > unaligned start offsets. The code already handles partial sector writes > for the last sector in the same way (read, erase, write), which is also > prone to data loss in case of power loss. Ah, I missed that. Yes, in this case, we don't loose anything. Agreed. > So this patch in fact just adds support for partial sector updates for > the first sector. It is slightly more probable to loose data, but it > doesn't introduce new "unsafe" behavior. > > Maybe we could cover this by adding a warning to the documentation, or > even printing a warning? Heh, although I was using "sf update" all the time, I wasn't aware of the read - "partly modify" - write cycle. Maybe it's just me being over cautious. Printing a warning might scare users, though. I'd prefer to fix the online help, where only "erase and write" is mentioned. -michael