[U-Boot-Users] U-Boot-v2 updates

[Robert Schwebel]

On Wed, Oct 10, 2007 at 02:57:01PM -0600, Grant Likely wrote:
> On 10/10/07, Robert Schwebel <r.schwebel at pengutronix.de> wrote:
> > On Wed, Oct 10, 2007 at 10:55:20AM +0200, Sascha Hauer wrote:
> > > There is several new stuff in the V2 tree, so here is an overview about
> > > whats changed:
> >
> > We'll really encourage people to look into that tree, it'ts really
> > amazing stuff. Next week we'll have a Technology Week with the
> > Pengutronix crew (only net, no phone :-) which will probably be used for
> > heavy u-boot-v2 hacking. So any ideas from the community are welcome!
> >
> > > - Cleaned up the tree. Most board supports and currently not supported
> > >   architectures and drivers have been removed. Of course it can go back
> > >   in once it is working again. This step seemed necessary to see what's
> > >   currently expected to be working and what's not.
> >
> > I think this is the only sane maintenance strategy. We want to have a
> > clean tree, so anything which is ready for v2 must be reviewed anyway.
>
> At the risk of creating a very long mailing list thread, I must say
> that I disagree.

No need for a flame war :-)

> I do think that the v2 tree is interesting from the point of view of
> where U-boot can go, but I don't think it has much chance of becoming
> the new u-boot mainline.

Well, it doesn't necessarily have to; IMHO, v1 and v2 can develop in
parallel for quite some time. At the moment, v2 is not even ready for
all arcitectures v1 supports, and it has only a minimum set of
functionality. So we agree on your view regarding "where it can go".

> The mainline u-boot tree may not be as pretty as the v2 tree; but it
> is the focus of active development which is even speeding up due to
> the recent changes in development process.
>
> You want to show us a better U-Boot; GREAT! Show us how to get there
> then. Merge in the -v2 changes in a stepwise fashion.

It won't work. At least not with a sane ammount of ressources.

> Maintain the stability of the existing board ports or provide time
> between changes to fix breakage.

You know that this doesn't work out. U-Boot is highly hardware related,
and it won't even be possible to *test* all the boards in the tree.

> Don't ask us to make a wholesale leap over to another tree, especially
> if you're not able to explain how you got there (ie. not able to show
> the progression).

What kind of information are you interested in? The way how we got there
is basically this:

- We started with "u-boot is the best bootloader available on the market
  - seen from a user's point of view" somewhen in the late 90ies.

- We all know that every piece of software of a given size will bit rot
  if being developed over 10 years. It has happened with u-boot as well.
  The whole ifdeffery, the hundrets of copies of flash drivers and the
  whole design are come from a time where we all didn't know how to do
  it better.

- We had "writing a *good* bootloader" on our agenda for years, because
  in the day-by-day work on customer systems, u-boot has shown us all
  the problems which arise from the current design.

- Sascha has sat down somewhen and has started to develop a "how u-boot
  would look like if it was started today" thing, which is what we
  now have in the v2 tree.

- The whole design follows these principles:

	* Follow the u-boot "look-and-feel" where ever it is possible.
	  Users are used to it and we don't want to make something
	  completely new for them.

	* Use Linux' & POSIX abstractions. Driver model, devices,
	  scripts, file system, but following the u-boot philosophy
	  of stripping down things to what a bootloader needs.

> The reality for me is that as much as I might be interested in what
> -v2 can do, I'm most likely not going to look at it for the following
> reasons:
>
> 1. I can't easily see the difference between mainline and -v2 so it is
> effectively a separate project (highly diverged fork) and so requires
> more effort to understand

It effectively is a redesign. In practise, it evolved from the v1
codebase, but with very radical steps, i.e. no such thing like a
bisectable patch flow.

It does not follow more effort to understand. If you had taken some time
to look at the code, you would have seen that it feels very naturall to
everyone who is familiar with the Linux design.

We have internally discussed for a long time if it wouldn't be better to
make a completely new project for it. In fact, some of our colleagues
still think that it would be better. But we finally agree that we all
strongly think that community split-up is a bad thing and u-boot has
ever been *the* project for this kind of work, so we want to do the work
in this community whenever possible.

> 2. It doesn't have as many board ports and so probably demands more
> effort when bringing up a new board.

Our current projects show a different behaviour. All colleagues who
started working on v2 had working BSPs after a few days of familiarizing
with the new tree.

> 3. It contains many architectural changes but there has been very
> little discussion of them on the list and so I know almost nothing
> about it.

It's really that simple as outlined above. We'll be pleased to answer
your questions, so just post them here on the mailing list. We'll also
improve the documentation, probably during the Pengutronix Tech Week in
the next week.

> I don't say this to slam the -v2 tree or the work that Sascha has
> done. Quite the contrary; I think that work is great.

You didn't look at it, so you cannot know 8-)

> But with the amount of divergence and the inability to easily review
> and migrate those changes back into mainline, it is effectively a
> separate project.

Well, in the end it will be up to Wolfgang's decision if he wants to see
this effort being developed under the roof of the u-boot project.

We definitely think that what we have in mind won't work with gradual
steps, at least not with maintainable effort and without an endless
ammount of developer time. So the agenda for v2 is

1) create a sane code base for the infrastructure (almost done) and do
   the designs right

2) migrate boards over to v2 when they have to be touched anyway.
   For a single board it is easy (but surely will uncover deficies
   in 2), which may need further steps in the infracturcture).

And it surely doesn't mean that everyone has to step to v2 at once. In
fact, there's nothing speaking against v1 and v2 coexisting for quite
some time.

Robert
-- 
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de