From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lithops.sigma-star.at ([195.201.40.130]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1ghwAh-0001cu-TG for linux-mtd@lists.infradead.org; Fri, 11 Jan 2019 12:44:25 +0000 From: Richard Weinberger To: Shibin George , linux-mtd@lists.infradead.org Subject: Re: gluebi vs. ubi-volume mapping Date: Fri, 11 Jan 2019 13:44:12 +0100 Message-ID: <1835331.mx3o4XuZP5@blindfold> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Am Freitag, 11. Januar 2019, 13:42:11 CET schrieb Shibin George: > > BTW: Why are you using glubi+mtdblock at all? To support squashfs we > > have ubiblock. > > That way you can use read-only block-based filesystems directly on top > > of UBI without glubi > > and mtdblock. > ubiblock, being read-only, didn't satisfy my requirement. > The device I am working on needs to have block-level software upgrade > capability. > So gluebi was the best solution that I could find that can run block-based > filesystem. Usually you don't want such a deep stacking on an embedded system. But you are aware of ubiupdatevol? Thanks, //richard