From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harald Welte Date: Wed, 9 Jul 2008 08:23:57 +0800 Subject: [U-Boot-Users] [PATCH, resend] Support dynamic/patched NAND ENV offset In-Reply-To: <20080708211231.DD52E242FF@gemini.denx.de> References: <48739036.2080806@freescale.com> <20080708211231.DD52E242FF@gemini.denx.de> Message-ID: <20080709002357.GS25698@prithivi.gnumonks.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Jul 08, 2008 at 11:12:31PM +0200, Wolfgang Denk wrote: > In message <48739036.2080806@freescale.com> you wrote: > > > > > I also have another patchset for what I call 'dynpart' support, i.e. the > > > dynamic calculation of a unit-specific partition table that ensures the > > > net size of partitions are as per spec, no matter how many of the > > > factory default blocks are located where. So it would even support > > > NAND devices with a worse spec than the ones that we were using. > > > > Interesting... Would such a patch eliminate the need for this one, by > > making the environment a dynamic partition? Is there any (plan for) > > Linux support? > > What's the relation of this to the mtdparts handling in U-Boot and > Linux? see my other mail in this thread (just posted). More precisely, the flow of events in a full dynenv + dynpart setup (like the three openmoko devices so far) is: 1) u-boot creates a bad block table as part of the production process of the device 2) afterwards, the device-unique partition table is created (net partition sizes as per board-level spec), including an environment partition. 3) the standard regular partition table is stored in the environment 4) the environment including the mtdparts variable is saved to the env partition 5) the nand flash offset to the environment partition is stored in the out-of-band area of the first (known-always-good) nand flash block During boot, the regular mechanism of passing 'mtdparts' to the kernel is used. This was the most elegant scheme that I could come up with to support a large number of factory-bad blocks at any given location in the flash while still keeping the amount of overhead per partition low. Cheers, -- - Harald Welte http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone