Andy, Werner,
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.
Easy, because weeks ago I believe Werner thought this might be
something interesting to work on.
After many many mails with brutally complicated English, I'm sure you
two left Xiangfu in a state of total confusion.
Let's try this: Please settle on a specific u-boot/Kboot/Kexec task
for Xiangfu. He has a gta01 and gta02.
Explain it in simple English. Do not argue with each other.
If you two are unable to do this, I will try to find a task from our
long list of open issues, and then don't complain 'for whatever
reason' :-)
Wolfgang
On Jun 3, 2008, at 2:25 AM, Andy Green wrote:
-----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-----
