From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com ([134.134.136.65]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XgDJN-0007Xz-QF for linux-mtd@lists.infradead.org; Mon, 20 Oct 2014 13:47:50 +0000 Message-ID: <1413812845.7906.291.camel@sauron.fi.intel.com> Subject: Re: UBI: ignore/overwrite old data/PEBs after flashing From: Artem Bityutskiy Reply-To: dedekind1@gmail.com To: =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= Date: Mon, 20 Oct 2014 16:47:25 +0300 In-Reply-To: References: <1413454168.7906.154.camel@sauron.fi.intel.com> <1413456043.7906.164.camel@sauron.fi.intel.com> <1413458869.7906.199.camel@sauron.fi.intel.com> <1413460486.7906.216.camel@sauron.fi.intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: Felix Fietkau , "linux-mtd@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2014-10-16 at 15:51 +0200, Rafał Miłecki wrote: > Unfortunately this won't work if we flash the same firmware twice (it > will contain the same sequence). Imagine someone flashing a stable > OpenWrt release, then breaking something and flashing the same image > again. It'll contain the same sequence number and my magic driver > won't clean the old data :( Yes, flashing with ubiformat would be fine, because it changes the sequence number on-the-fly. With industial flashers, you'd need to erase the flash. Now you say you do not have the erase operation. You idea of a "IMAGE_ENDS_HERE" bit seems to be nice, and you could implement it, but you should think about the fastmap case too. Probably you need to do nothing, because fastmap will only refer the PEBs within the image, and the PEBs outside of the image will be scheduled for erasure. But you should verify this. Artem.