this week work on KBOOT
werner at openmoko.org
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.)
More information about the openmoko-kernel