this week work on KBOOT

[Wolfgang Spraul]

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