In message [EMAIL PROTECTED] you wrote:
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
On Wed, Jul 09, 2008 at 09:05:24AM +0200, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
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
Hi Wolfgang,
thanks again for your quick response. This is really encouraging me to
continue merging/submitting at the same pace ;)
On Wed, Jul 09, 2008 at 10:04:47AM +0200, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
How do you create the partition table? Do you use the
On Tue, Jul 08, 2008 at 11:12:31PM +0200, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] 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
On Mon, Jul 07, 2008 at 01:47:24PM -0500, Scott Wood wrote:
On Mon, Jul 07, 2008 at 12:28:12AM +0800, Harald Welte wrote:
I've first sent this on Feb 17, 2007. Unfortunately no reply was
received. I think this is a quite useful feature, since a compile time
offset into the NAND flash for
Hi!
I've first sent this on Feb 17, 2007. Unfortunately no reply was
received. I think this is a quite useful feature, since a compile time
offset into the NAND flash for the environment just doesn't work well
with bad blocks ;)
This is the current version of the patch. I'd love to see it