Date: Wed, 02 Aug 2006 08:52:02 -0600 (MDT) From: Warner Losh <imp@bsdimp.com> To: henrik@brixandersen.dk Cc: bugs@FreeBSD.ORG, phk@phk.freebsd.dk, freebsd-embedded@FreeBSD.ORG Subject: Re: misc/101228: [nanobsd] [patch] Two more entries for FlashDevice.sub Message-ID: <20060802.085202.74685303.imp@bsdimp.com> In-Reply-To: <20060802140628.GL17004@osgiliath.opasia.dk> References: <20060802.073232.-494097392.imp@bsdimp.com> <17702.1154526225@critter.freebsd.dk> <20060802140628.GL17004@osgiliath.opasia.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Henrik Brix Andersen <henrik@brixandersen.dk> Subject: Re: misc/101228: [nanobsd] [patch] Two more entries for FlashDevice.sub Date: Wed, 2 Aug 2006 16:06:28 +0200 > On Wed, Aug 02, 2006 at 01:43:45PM +0000, Poul-Henning Kamp wrote: > > I'm afraid I have to agree with Warner here. > > > > I was hoping that the vendors would standardize on a limited number > > of geometries, but it seems that yet again my faith in the wisdom > > of hardware vendors is not supported by evidence. > > So what should happen with the existing entries in FlashDevice.sub? > Should we deprecate it alltogether - or leave it as a half-baked > solution? In our operation, we burn each flash from a tarball after taking that flash's geometry into account. This allows us to get the maximium amount of space on our 'hog' partitions, but does mean we don't put an actual image onto the part. We don't use nanobsd, btw, since our solution is home-grown before nanobsd was even thought of by phk. nanobsd is an image based solution, so it should pick numbers that are a little smaller than the typical part (eg use 510,000 bytes for the size of the image of a 512MB flash) and use those for everything. Nanobsd is not setup to optimize to a level higher than this. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060802.085202.74685303.imp>