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

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

[Sascha Hauer]

Hi all,

There is several new stuff in the V2 tree, so here is an overview about
whats changed:

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

- Blackfin support. Currently tested with a BF561, other Blackfins will
  need some adjustments.

- Module support. The module support is mainly the same as in the Linux
  kernel. It is possible to add new commands and drivers via modules so
  people can extend U-Boot without changing the whole loader. Symbols
  are exported via EXPORT_SYMBOL, just like in the kernel.

- Many bugs fixed (probably by introducing new ones ;)

- The environment now can not only handle files but also directories.

- A default environment can be compiled in. Similar to U-Boot v1 it is
  used when the environment sector is corrupted.

As usual the tree can be cloned / pulled here:

git clone git://www.denx.de/git/u-boot-v2.git


Sascha

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

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

[Robert Schwebel]

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.

> - Blackfin support. Currently tested with a BF561, other Blackfins will
>   need some adjustments.

There's still an issue that the BF randomly hangs when "Uncompressing
kernel". Maybe the Analog people have an idea?

> - Module support. The module support is mainly the same as in the Linux
>   kernel. It is possible to add new commands and drivers via modules so
>   people can extend U-Boot without changing the whole loader. Symbols
>   are exported via EXPORT_SYMBOL, just like in the kernel.

... which is a very cool feature. It is now possible to write extensions
to u-boot without having the old object files around.

We'd like to prepare a first numbered snapshot release during the tech
week, in order to have a well defined base for people to play with.

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

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

[Grant Likely]

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

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.  Maintain the
stability of the existing board ports or provide time between changes
to fix breakage.  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).

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
2. It doesn't have as many board ports and so probably demands more
effort when bringing up a new board.
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.

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

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

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

[Wolfgang Denk]

In message <20071011072523.GA23573@pengutronix.de> you wrote:
>
> > 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.

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

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

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.

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

No, this is definitely not my decision. It's up to the community to
decide where they will gather and throw forces at.


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

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I am a computer. I am dumber than any human and smarter than any  ad-
ministrator.

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

[Robert Schwebel]

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
-- 
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de

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

[Wolfgang Denk]

Dear Sascha,

in message <20071010085520.GE11231@pengutronix.de> you wrote:
> 
> There is several new stuff in the V2 tree, so here is an overview about
> whats changed:

Here is a formal comment: can you (and the other's of your team)
please:

1) use valid committer's mail addresses:
   Juergen Beisert <jbe@isonoe.(none)> or
   sascha <sascha@nomad.localdomain>   or
   Robert Schwebel (Laptop) <rsc@thebe.(none)> 
   are not acceptable.
2) sign-off your commits.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Summit meetings tend to be like panda matings. The expectations  are
always high, and the results usually disappointing."   - Robert Orben