On Wed, Oct 10, 2007 at 02:57:01PM -0600, Grant Likely wrote:

On 10/10/07, Robert Schwebel r.schwebel@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

On Thu, Oct 11, 2007 at 12:17:12PM +0200, Wolfgang Denk wrote:

...

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

With sane amount of resourcs you are thinking about your group at Pengutronix only, or about the whole community that stands behind U-Boot development?

I cannot speak for others here, but I don't think that our out-of- daytime-business ressources will be enough to go through the well known process for u-boot.

I, too, was thinking that getting rid of the old bitmask way for command selection or introducing a better config/build system was much too much effort on one side, and much to evasive for an evolutinary approach on the other side. Yet just a few months after initial discussion one has been completed, and the other is on the verge of being merged.

Did you have a look at the code yet? What is your estimation, how much effort could it be? I'm not generally against a gradual move, but I simply doubt that it will work.

There have always beeb unmaintained boards, that's true.

But most of the boards are in a pretty good shape with mor eor less active maintainers behind them who *do* test the code.

My experience is that board vendors tend to make it once and then forget about the whole think, because they have something they can sell with their products. But it may be just a personal experience, based on the part of the market we serve.

...

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

I tend to disagree here. It may work for many pretty basic ports. But for any "real" projects like what we're seeing in our everyday work too many essential features are missing.

Can you outline which ones?

OK, you will argument that this is a good chance to port these into the new code - but we neither have time nor resources to do that on our own, and we cannot easily sell this to a customer when the same features are available for free in the context of the existing code.

Our top priority is source code quality and maintainability. "Features" has never been a negative argument with the v1 code.

And I can once again encourage everyone to have a look at the code and outline what is really missing. In the end, this is Open Source, and with v1 we have a very feature rich code base to gain synergy effects from.

We have done the first business critical projects with the v2 codebase. Our experience is that it doesn't take more time to make a board support package than with v1, at least not for the "standard case". So there is nothing really "extra" which has to be sold. Again - this is from the perspective of our projects, which is mostly SoC based.

...

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.

Agree. Time and community will decide.

If we can agree on that, I'm fine.

Robert