this week work on KBOOT

Werner Almesberger werner at
Mon Jun 2 20:03:26 CEST 2008

Andy Green wrote:
> Right, it's a "what first" question for xiangfu.

I wonder if he should get sidetracked by u-boot and the partitioning
concept in the first place, particularly since there's extremely little
to do in terms of implementation.

Specifically, I'd see the following items:

- add a hard-coded partition table to the default environment
- for good measure, disable the dynpart and dynenv commands
- use a hardcoded offset for the environment instead
- remove dynpart and friends from DM1
- add a "do we have enough non-bad blocks ?" test to DMx (*)
- update the documentation :-)
- consider simplifying the "FINAL" step

So most of the real work would be in DMx, not in u-boot proper.

(*) Using something like

> It just seems we get teleported to a better win by reducing the
> bootloader to the minimum first.

Can we phrase this as "not doing weird things in our architecture" ? ;-)
"Reducing the boot loader" sounds like a great waste of time on u-boot.

For kboot, I'd rather see a simple loader written from scratch. Where
we decide to use u-boot to speed up development, it should already do
what we need. Otherwise, this means just sinking more resources into

> We have to differentiate between possible GTA01/02 reformat and GTA03
> usage.  All I am worrying about is GTA03.

Yeah, I wouldn't consider such sweeping changes to GTA01/GTA02,
except for prototyping.

> On GTA03 we are in a neat position that Linux does not have to support
> NAND.  The bootloader alone can be responsible for write and read of

Hmm, accessing NAND per se isn't a big deal. In fact, even with u-boot,
it would be better to do NAND updates from Linux, since it's much easier
to build the framework. (User interface, integrity check, etc.)

> So for GTA03, yes I think we could throw out the bad block table.

Okay, so we need to check if kernel and u-boot don't mind as well.
I'm sure the factory will be very happy if we drop "createbbt" :-)

In fact, if we get to remove the bad block table, we might even be
able to program the NAND offline. That would be a massive process
improvement. (Heh, we could have done with the NOR in GTA02.)

- Werner

More information about the openmoko-kernel mailing list