this week work on KBOOT

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| 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.

We can't start on it without the new bootloader partitioning method.

|> 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.

U-Boot is configurable... but ripping it out down to the minimum what
you're calling Kboot sounds good to me, not wasting time?  Kexec is what
we can't leverage right now.

| 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
| u-boot.

No actually xingfu got started really well on that, he identified 3
files out of U-Boot that he needed to make a minimal bootloader.  He
just got stuck compiling them into an actual bootloader.  If we were to
write our own minimal bootloader from scratch, we would probably raid
the same 3 files for minimal working stuff.  Right?

|> 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.

For whatever reason, that is what Wolfgang started this off with.

|> 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
|> NAND,
|
| 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.)

Hum.  Please give it some thought before we go back down this path of
block devices with unreliable blocks, etc, in Linux.  We can actually
dodge it all right now.  We're only going to use this whole raft of
support in Linux to update the bootloader + backup rootfs?  We surely
have better things to work on :-(

|> 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.)

I already know the answer to this because I discussed it with Milosch
the other week: if there is no BBT then MTD stuff in Linux creates one.
~ But please think about this, we don't need to support this whole thing
in Linux.


For using U-Boot, fine for now if it is configured so far down that it
actually is the minimal set that we would rip out anyway.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhEOwAACgkQOjLpvpq7dMq/wACfb5+/IK98xAcJULbp9OwWO/k7
bpQAn3u1+jrjkp8KHcAtr+sLfHYIuLVG
=qrYr
-----END PGP SIGNATURE-----