[U-Boot] [ANNOUNCE] Kconfig support

[U-Boot] [ANNOUNCE] Kconfig support

[Jean-Christophe PLAGNIOL-VILLARD]

Hi all,

	I've upload on the u-boot-arm tree in kconfig branch
	some patch on which I work to all us to use Kconfig

	It's a dev branch not all patch are perfect
	but it will be nice if other could help to finish it
	and help me to create all the Kconfig files

Best Regards,
J.

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Saturday 18 April 2009 12:25:30 Jean-Christophe PLAGNIOL-VILLARD wrote:
> 	I've upload on the u-boot-arm tree in kconfig branch
> 	some patch on which I work to all us to use Kconfig
>
> 	It's a dev branch not all patch are perfect
> 	but it will be nice if other could help to finish it
> 	and help me to create all the Kconfig files

i thought this was one of the points of u-boot-2 ?
-mike

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090418162530.GD1413@game.jcrosoft.org> you wrote:
> 
> 	I've upload on the u-boot-arm tree in kconfig branch
> 	some patch on which I work to all us to use Kconfig

If you want to see code review and testing take place, then please
follow the documented procedures and post patches on the mailing
list.

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
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Mike,

In message <200904181429.56281.vapier@gentoo.org> you wrote:
> > 	I've upload on the u-boot-arm tree in kconfig branch
> > 	some patch on which I work to all us to use Kconfig
...
> i thought this was one of the points of u-boot-2 ?

u-boot-v2 is an interesting approach in several aspects, but since it
was made publicly visible nearly two years ago it did not collect
much of a community around it. From my (strictly personal) point of
view, one show stopper is that there is no migration path - if you
want to go u-boot-v2, you have to throw away all what is in mainline.
And there is a lot of things that are not available in v2.

So it does make perfect sense to me to add features like Kconfig
support to mainline.

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
The night sky over the planet Krikkit is the least interesting  sight
in the entire Universe.
                 - Douglas Adams _Life, the Universe, and Everything_

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Saturday 18 April 2009 14:54:41 Wolfgang Denk wrote:
> In message Mike wrote:
> > > 	I've upload on the u-boot-arm tree in kconfig branch
> > > 	some patch on which I work to all us to use Kconfig
>
> ...
>
> > i thought this was one of the points of u-boot-2 ?
>
> u-boot-v2 is an interesting approach in several aspects, but since it
> was made publicly visible nearly two years ago it did not collect
> much of a community around it. From my (strictly personal) point of
> view, one show stopper is that there is no migration path - if you
> want to go u-boot-v2, you have to throw away all what is in mainline.
> And there is a lot of things that are not available in v2.

so, does it make sense to look at the feature set that v2 brings to the table 
and get it into u-boot v1 ?  ive never personally looked at v2, but if it 
means i need to redo all of my Blackfin core/board code, that doesnt sound 
very appealing at all ...

> So it does make perfect sense to me to add features like Kconfig
> support to mainline.

i'm not saying it doesnt make sense, just wanted to make sure i wasnt missing 
anything obvious.
-mike

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Mike,

In message <200904181518.33357.vapier@gentoo.org> you wrote:
> 
> so, does it make sense to look at the feature set that v2 brings to the table 
> and get it into u-boot v1 ?  ive never personally looked at v2, but if it 
> means i need to redo all of my Blackfin core/board code, that doesnt sound 
> very appealing at all ...

As long as we can make it an evolutionary process, i. e. one that does
not force us to throw away all existing code and restart from scratch,
then adapting design ideas and features from v2 is indeed worthwhile.

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
The light at the end of the tunnel is usually a "No Exit" sign.

[U-Boot] [ANNOUNCE] Kconfig support

[Kumar Gala]

On Apr 18, 2009, at 11:25 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:

> Hi all,
>
> 	I've upload on the u-boot-arm tree in kconfig branch
> 	some patch on which I work to all us to use Kconfig
>
> 	It's a dev branch not all patch are perfect
> 	but it will be nice if other could help to finish it
> 	and help me to create all the Kconfig files

Beyond adding Kconfig's what's left to be done?

- k

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote:
> u-boot-v2 is an interesting approach in several aspects, but since it
> was made publicly visible nearly two years ago it did not collect much
> of a community around it.

Right; part of the reason is it was always something we used to solve
our problems, and we didn't do much marketing around it. Nevertheless,
it *does* solve our problems very well, and each time we have to work
with v1 again it's weaknesses show up again and again.

> From my (strictly personal) point of view, one show stopper is that
> there is no migration path - if you want to go u-boot-v2, you have to
> throw away all what is in mainline.

That was one of the design criteria - starting with a clean code base,
in order to get rid of all the old ugglyness.

> And there is a lot of things that are not available in v2.

Right; from what we need in our daytime projects, the most important
feature which is currently missing is PCI support. There are several
others which are surely also important (like i2c) but could be added
with very low effort if needed.

> So it does make perfect sense to me to add features like Kconfig
> support to mainline.

Right; if v2 inspires someone to take the ideas and bring them into v1,
it's perfectly fine - in the end, it's one of the reasons we started the
whole thing.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Sat, Apr 18, 2009 at 03:18:32PM -0400, Mike Frysinger wrote:
> so, does it make sense to look at the feature set that v2 brings to
> the table and get it into u-boot v1? ive never personally looked at
> v2, but if it means i need to redo all of my Blackfin core/board code,
> that doesnt sound very appealing at all ...

We have even Blackfin support in v2, and that for almost all of the time
it is actually there. Sure - if you need feature completeness, you'll
have to stay with v1. Our aim is a sane design, and I'm still not
convinced that this is even possible with v1 any more.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Kumar Gala]

On Apr 19, 2009, at 2:48 PM, Robert Schwebel wrote:

> On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote:
>> u-boot-v2 is an interesting approach in several aspects, but since it
>> was made publicly visible nearly two years ago it did not collect  
>> much
>> of a community around it.
>
> Right; part of the reason is it was always something we used to solve
> our problems, and we didn't do much marketing around it. Nevertheless,
> it *does* solve our problems very well, and each time we have to work
> with v1 again it's weaknesses show up again and again.

What's the summary of features that v2 has that v1 doesnt?

- k

[U-Boot] [ANNOUNCE] Kconfig support

[Sascha Hauer]

On Sun, Apr 19, 2009 at 04:59:41PM -0500, Kumar Gala wrote:
>
> On Apr 19, 2009, at 2:48 PM, Robert Schwebel wrote:
>
>> On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote:
>>> u-boot-v2 is an interesting approach in several aspects, but since it
>>> was made publicly visible nearly two years ago it did not collect  
>>> much
>>> of a community around it.
>>
>> Right; part of the reason is it was always something we used to solve
>> our problems, and we didn't do much marketing around it. Nevertheless,
>> it *does* solve our problems very well, and each time we have to work
>> with v1 again it's weaknesses show up again and again.
>
> What's the summary of features that v2 has that v1 doesnt?

- Kconfig support
- Linux Build support
- Clean device registration and driver matching, so there can always be
  multiple instances of a device
- filesystem support. U-Boot starts by mounting a ramfs on /, populating
  a devfs under /dev and load the environemt to /env. Use the normal
  commands like cd, ls, rm, cat,...
- mount: there is no mmc_ls and mmc_load and stuff like that. Just mount
  your device and use ls
- The environment is not limited to a variable store, instead it's a
  ramfs which can store variables, scripts, splashimages or whatever
- module support
- One image for all storage types. Well, the hardware has to support it,
  but on i.MX27 the same image can start from RAM, Nor Flash and NAND
  Flash.
- USB Network support
- A network phy device layer, so phys are handled in a generic way.
  Their registers can be showed with md -s /dev/phy0 (and of course
  changed with mw)
- A much simpler clock implementation (Linux clocksource). So basically
  what an architecture needs to do is to specify the timer resolution
  and provide a read_timer function which returns the raw timer value.
- getopt support, so there is no need for positional arguments
- A simple editor to edit scripts
- readline usable on the command line to allow for interactive scripts
- a sandbox port to run U-Boot on the host including tap ethernet
- different bugs to hunt for

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Sunday 19 April 2009 15:50:46 Robert Schwebel wrote:
> On Sat, Apr 18, 2009 at 03:18:32PM -0400, Mike Frysinger wrote:
> > so, does it make sense to look at the feature set that v2 brings to
> > the table and get it into u-boot v1? ive never personally looked at
> > v2, but if it means i need to redo all of my Blackfin core/board code,
> > that doesnt sound very appealing at all ...
>
> We have even Blackfin support in v2, and that for almost all of the time
> it is actually there. Sure - if you need feature completeness, you'll
> have to stay with v1. Our aim is a sane design, and I'm still not
> convinced that this is even possible with v1 any more.

unless it's the code that ive been committing to mainline via the blackfin git 
tree, then it really doesnt matter (and it looks that way) since, as you say, 
it is not even close to feature parity.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090420/e38f54be/attachment.pgp 

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Sun, Apr 19, 2009 at 04:59:41PM -0500, Kumar Gala wrote:
> What's the summary of features that v2 has that v1 doesnt?

http://git.denx.de/?p=u-boot/u-boot-v2.git;a=blob;f=README;hb=HEAD

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Mon, Apr 20, 2009 at 12:56:53AM -0400, Mike Frysinger wrote:
> > We have even Blackfin support in v2, and that for almost all of the
> > time it is actually there. Sure - if you need feature completeness,
> > you'll have to stay with v1. Our aim is a sane design, and I'm still
> > not convinced that this is even possible with v1 any more.
>
> unless it's the code that ive been committing to mainline via the
> blackfin git tree, then it really doesnt matter (and it looks that
> way) since, as you say, it is not even close to feature parity.

You missed the point, please re-read what I've written. If you aim for
feature completeness, use v1 and don't care about v2. v2 is for people
who care about *design*.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:38 Sun 19 Apr     , Kumar Gala wrote:
>
> On Apr 18, 2009, at 11:25 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
>> Hi all,
>>
>> 	I've upload on the u-boot-arm tree in kconfig branch
>> 	some patch on which I work to all us to use Kconfig
>>
>> 	It's a dev branch not all patch are perfect
>> 	but it will be nice if other could help to finish it
>> 	and help me to create all the Kconfig files
>
> Beyond adding Kconfig's what's left to be done?
I've write a first batch of the generic Kconfig
for commmands, env, fs, disk, lib_generic and drivers

I've start to add the at91 arm arch Kconfig files

currently you can generate a .config and su defconfig

the autoconf.h header is generated
and the Kconfig customisation is started also

I've in mind to start by adding a arm arch with its boards
and merge them to the defconfig instead of the old way
but it's not already integreated

it will be nice to help me by doing the same for other arch
and improve the kconfig integeration and generic file

Best Regards,
J.

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Monday 20 April 2009 02:52:44 Robert Schwebel wrote:
> On Mon, Apr 20, 2009 at 12:56:53AM -0400, Mike Frysinger wrote:
> > > We have even Blackfin support in v2, and that for almost all of the
> > > time it is actually there. Sure - if you need feature completeness,
> > > you'll have to stay with v1. Our aim is a sane design, and I'm still
> > > not convinced that this is even possible with v1 any more.
> >
> > unless it's the code that ive been committing to mainline via the
> > blackfin git tree, then it really doesnt matter (and it looks that
> > way) since, as you say, it is not even close to feature parity.
>
> You missed the point, please re-read what I've written.

i didnt miss the point.  notice how i wrote "as you say".

> If you aim for
> feature completeness, use v1 and don't care about v2. v2 is for people
> who care about *design*.

so v2 is good for thinking about things while v1 is good for people who want 
to do real work.  if that's the standpoint, then it looks like v2 is destined 
to die and ideas should be fitted onto v1.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090420/496eaade/attachment.pgp 

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Mon, Apr 20, 2009 at 09:49:38AM -0400, Mike Frysinger wrote:
> > If you aim for feature completeness, use v1 and don't care about v2.
> > v2 is for people who care about *design*.
>
> so v2 is good for thinking about things while v1 is good for people
> who want to do real work. if that's the standpoint, then it looks
> like v2 is destined to die and ideas should be fitted onto v1.

Well, it is Open Source, so you are free to do whatever you want to do.

U-Boot-v2 is used here to do real work in our projects. If it isn't what
you need, it is perfectly fine if you ignore it.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Monday 20 April 2009 10:04:14 Robert Schwebel wrote:
> On Mon, Apr 20, 2009 at 09:49:38AM -0400, Mike Frysinger wrote:
> > > If you aim for feature completeness, use v1 and don't care about v2.
> > > v2 is for people who care about *design*.
> >
> > so v2 is good for thinking about things while v1 is good for people
> > who want to do real work. if that's the standpoint, then it looks
> > like v2 is destined to die and ideas should be fitted onto v1.
>
> Well, it is Open Source, so you are free to do whatever you want to do.
>
> U-Boot-v2 is used here to do real work in our projects. If it isn't what
> you need, it is perfectly fine if you ignore it.

my concern isnt really narrow to the Blackfin port.  i was using it as a 
practical example.  we've talked about v2 in the past as the answer to many of 
our problems and so we dont bother doing it in v1.  but that approach looks to 
be wrong as v2 is of little practical importance.  instead we should be doing 
what Jean-Christophe is doing: poaching good ideas until we get to the point 
where v2 can simply die.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090420/8f6d24b2/attachment-0001.pgp 

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
> > U-Boot-v2 is used here to do real work in our projects. If it isn't
> > what you need, it is perfectly fine if you ignore it.
>
> my concern isnt really narrow to the Blackfin port. i was using it as
> a practical example. we've talked about v2 in the past as the answer
> to many of our problems and so we dont bother doing it in v1. but that
> approach looks to be wrong as v2 is of little practical importance.
> instead we should be doing what Jean-Christophe is doing: poaching
> good ideas until we get to the point where v2 can simply die.

If you mean "you" while saying "we", then yes, it may be correct that
this is your plan. "We" don't have any plans to let v2 die.

Should we be mindful of the future? But not at the expense of the
moment. Be mindful of the living Force, my young Padawan.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Jerry Van Baren]

Robert Schwebel wrote:
> On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
>>> U-Boot-v2 is used here to do real work in our projects. If it isn't
>>> what you need, it is perfectly fine if you ignore it.
>> my concern isnt really narrow to the Blackfin port. i was using it as
>> a practical example. we've talked about v2 in the past as the answer
>> to many of our problems and so we dont bother doing it in v1. but that
>> approach looks to be wrong as v2 is of little practical importance.
>> instead we should be doing what Jean-Christophe is doing: poaching
>> good ideas until we get to the point where v2 can simply die.
> 
> If you mean "you" while saying "we", then yes, it may be correct that
> this is your plan. "We" don't have any plans to let v2 die.
> 
> Should we be mindful of the future? But not at the expense of the
> moment. Be mindful of the living Force, my young Padawan.
> 
> rsc

To quote Yogi Berra, "When you come to a fork in the road... take it."[1]

Maybe V1 lives on.  Maybe V1 runs out of gas, gets overwhelmed by 
legacy, and V2 becomes the continuing u-boot (think linux's ppc -> 
powerpc).  Maybe the two will meet up again at the far side of the circle.

Regardless, you have a choice.  You can and should pick the branch that 
best solves your problem.  Viva la OSS!

Best regards,
gvb

[1] Legend has it, Yogi was giving directions to his house which was on 
a circular road, so it really *didn't* matter which fork you took.

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Monday 20 April 2009 10:53:39 Robert Schwebel wrote:
> On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
> > > U-Boot-v2 is used here to do real work in our projects. If it isn't
> > > what you need, it is perfectly fine if you ignore it.
> >
> > my concern isnt really narrow to the Blackfin port. i was using it as
> > a practical example. we've talked about v2 in the past as the answer
> > to many of our problems and so we dont bother doing it in v1. but that
> > approach looks to be wrong as v2 is of little practical importance.
> > instead we should be doing what Jean-Christophe is doing: poaching
> > good ideas until we get to the point where v2 can simply die.
>
> If you mean "you" while saying "we", then yes, it may be correct that
> this is your plan. "We" don't have any plans to let v2 die.
>
> Should we be mindful of the future? But not at the expense of the
> moment. Be mindful of the living Force, my young Padawan.

i never said "kill it now"; quite the opposite really.  in fact, it looks like 
you really arent taking your own saying to heart.  my point is to look to the 
future and stop wasting resources.  if v1 incorporates all the features of v2, 
then v2 has no purpose at all except to split development and waste peoples 
time.  the approach set out originally was to keep v1 usable while we look at 
getting v2 up to feature parity of v1.  but apparently v2 has no interest at 
all with the larger community to actually make that happen.  that doesnt sound 
like the open source spirit, that sounds like "i'll play with my toys over 
here and everyone else can do what they like".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090420/f7e21276/attachment.pgp 

[U-Boot] Kconfig support - menuconfig broken?

[Kumar Gala]

When I try to do a make menuconfig I get:

[galak at blarg u-boot-85xx]$ make menuconfig
make -C scripts/kconfig menuconfig
make[1]: Entering directory `/local/home/galak/git/u-boot-85xx/scripts/ 
kconfig'
gcc -I/usr/include/ncurses -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/ 
local/home/galak/git/u-boot-85xx/scripts/kconfig -lncursesw -I/usr/ 
include/ncurses -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/local/home/ 
galak/git/u-boot-85xx/scripts/kconfig -O -c -o zconf.tab.o zconf.tab.c
zconf.tab.c:166:24: error: zconf.hash.c: No such file or directory
zconf.tab.c: In function 'zconfparse':
zconf.tab.c:1660: error: 'kconf_id_strings' undeclared (first use in  
this function)
zconf.tab.c:1660: error: (Each undeclared identifier is reported only  
once
zconf.tab.c:1660: error: for each function it appears in.)
zconf.tab.c:1768: warning: initialization makes pointer from integer  
without a cast
zconf.tab.c: In function 'zconf_endtoken':
zconf.tab.c:2305: error: 'kconf_id_strings' undeclared (first use in  
this function)
zconf.tab.c:2484:23: error: lex.zconf.c: No such file or directory
In file included from zconf.tab.c:2486:
confdata.c: In function 'conf_get_default_confname':
confdata.c:73: error: 'PATH_MAX' undeclared (first use in this function)
confdata.c: In function 'conf_split_config':
confdata.c:636: error: 'errno' undeclared (first use in this function)
confdata.c:636: error: 'ENOENT' undeclared (first use in this function)
make[1]: *** [zconf.tab.o] Error 1
make[1]: Leaving directory `/local/home/galak/git/u-boot-85xx/scripts/ 
kconfig'
make: *** [menuconfig] Error 2

[U-Boot] [ANNOUNCE] Kconfig support

[Sascha Hauer]

On Mon, Apr 20, 2009 at 11:20:50AM -0400, Mike Frysinger wrote:
> On Monday 20 April 2009 10:53:39 Robert Schwebel wrote:
> > On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
> > > > U-Boot-v2 is used here to do real work in our projects. If it isn't
> > > > what you need, it is perfectly fine if you ignore it.
> > >
> > > my concern isnt really narrow to the Blackfin port. i was using it as
> > > a practical example. we've talked about v2 in the past as the answer
> > > to many of our problems and so we dont bother doing it in v1. but that
> > > approach looks to be wrong as v2 is of little practical importance.
> > > instead we should be doing what Jean-Christophe is doing: poaching
> > > good ideas until we get to the point where v2 can simply die.
> >
> > If you mean "you" while saying "we", then yes, it may be correct that
> > this is your plan. "We" don't have any plans to let v2 die.
> >
> > Should we be mindful of the future? But not at the expense of the
> > moment. Be mindful of the living Force, my young Padawan.
> 
> i never said "kill it now"; quite the opposite really.  in fact, it looks like 
> you really arent taking your own saying to heart.  my point is to look to the 
> future and stop wasting resources.  if v1 incorporates all the features of v2, 
> then v2 has no purpose at all except to split development and waste peoples 
> time.

Well as you said at the moment there is not much community around
u-boot-v2, so it's basically *our* time which we waste, and we are free
to do so. At the moment it seems you're wasting *your* time by warming
up this stupid discussion which Jerry already led to a nice ending.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] Kconfig support - menuconfig broken?

[Kumar Gala]

On Apr 20, 2009, at 10:26 AM, Kumar Gala wrote:

> When I try to do a make menuconfig I get:
>
> [galak at blarg u-boot-85xx]$ make menuconfig
> make -C scripts/kconfig menuconfig
> make[1]: Entering directory `/local/home/galak/git/u-boot-85xx/ 
> scripts/
> kconfig'
> gcc -I/usr/include/ncurses -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/
> local/home/galak/git/u-boot-85xx/scripts/kconfig -lncursesw -I/usr/
> include/ncurses -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/local/home/
> galak/git/u-boot-85xx/scripts/kconfig -O -c -o zconf.tab.o zconf.tab.c
> zconf.tab.c:166:24: error: zconf.hash.c: No such file or directory
> zconf.tab.c: In function 'zconfparse':
> zconf.tab.c:1660: error: 'kconf_id_strings' undeclared (first use in
> this function)
> zconf.tab.c:1660: error: (Each undeclared identifier is reported only
> once
> zconf.tab.c:1660: error: for each function it appears in.)
> zconf.tab.c:1768: warning: initialization makes pointer from integer
> without a cast
> zconf.tab.c: In function 'zconf_endtoken':
> zconf.tab.c:2305: error: 'kconf_id_strings' undeclared (first use in
> this function)
> zconf.tab.c:2484:23: error: lex.zconf.c: No such file or directory
> In file included from zconf.tab.c:2486:
> confdata.c: In function 'conf_get_default_confname':
> confdata.c:73: error: 'PATH_MAX' undeclared (first use in this  
> function)
> confdata.c: In function 'conf_split_config':
> confdata.c:636: error: 'errno' undeclared (first use in this function)
> confdata.c:636: error: 'ENOENT' undeclared (first use in this  
> function)
> make[1]: *** [zconf.tab.o] Error 1
> make[1]: Leaving directory `/local/home/galak/git/u-boot-85xx/scripts/
> kconfig'
> make: *** [menuconfig] Error 2

The problem is we aren't generating lex.zconf.c or zconf.hash.c.   
Seems like your makefile doesn't have the rules to generate these files.

Also:

make: -E: Command not found

is from HOSTCC not being defined.

- k

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Monday 20 April 2009 11:34:33 Sascha Hauer wrote:
> On Mon, Apr 20, 2009 at 11:20:50AM -0400, Mike Frysinger wrote:
> > On Monday 20 April 2009 10:53:39 Robert Schwebel wrote:
> > > On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
> > > > > U-Boot-v2 is used here to do real work in our projects. If it isn't
> > > > > what you need, it is perfectly fine if you ignore it.
> > > >
> > > > my concern isnt really narrow to the Blackfin port. i was using it as
> > > > a practical example. we've talked about v2 in the past as the answer
> > > > to many of our problems and so we dont bother doing it in v1. but
> > > > that approach looks to be wrong as v2 is of little practical
> > > > importance. instead we should be doing what Jean-Christophe is doing:
> > > > poaching good ideas until we get to the point where v2 can simply
> > > > die.
> > >
> > > If you mean "you" while saying "we", then yes, it may be correct that
> > > this is your plan. "We" don't have any plans to let v2 die.
> > >
> > > Should we be mindful of the future? But not at the expense of the
> > > moment. Be mindful of the living Force, my young Padawan.
> >
> > i never said "kill it now"; quite the opposite really.  in fact, it looks
> > like you really arent taking your own saying to heart.  my point is to
> > look to the future and stop wasting resources.  if v1 incorporates all
> > the features of v2, then v2 has no purpose at all except to split
> > development and waste peoples time.
>
> Well as you said at the moment there is not much community around
> u-boot-v2, so it's basically *our* time which we waste, and we are free
> to do so. At the moment it seems you're wasting *your* time by warming
> up this stupid discussion which Jerry already led to a nice ending.

you seem intent on doing your own thing and nuts to anyone else.  now that we 
all know this, we can stop looking at v2 as an answer to anything.  if we want 
something realistic, then we implement it in v1 after perhaps checking to see 
if v2 implemented something at the theoretical level (so we at least have an 
idea if something is going to work).

Jerry's point was that the open source license allows you to do this.  i never 
said otherwise.  my point was that this isnt how open source *communities* 
work.  the spirit is to *work together* not say screw everyone else.

considering your stance, i wonder why you even call it "u-boot v2".  clearly 
it has no relation to u-boot, neither in source code, intent, nor plans, so 
the more appropriate label would be "the pengutronix bootloader".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090420/5f118a3f/attachment.pgp 

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090420120239.GC19818@game.jcrosoft.org> you wrote:
>
> > Beyond adding Kconfig's what's left to be done?
> I've write a first batch of the generic Kconfig
> for commmands, env, fs, disk, lib_generic and drivers
> 
> I've start to add the at91 arm arch Kconfig files
> 
> currently you can generate a .config and su defconfig
> 
> the autoconf.h header is generated
> and the Kconfig customisation is started also
> 
> I've in mind to start by adding a arm arch with its boards
> and merge them to the defconfig instead of the old way
> but it's not already integreated
> 
> it will be nice to help me by doing the same for other arch
> and improve the kconfig integeration and generic file

Can you please start SMALL?

I mean: don't implement EVERYTHING before you post anything. You run
the risk that one of your basic assumptions in the very first patch
might not be accepted, and all the remaining effort is lost and has to
be redone.

Publish your stuff EARLY!!!

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
An Elephant is a mouse with an Operating System.              - Knuth

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200904201042.10253.vapier@gentoo.org> you wrote:
>
> my concern isnt really narrow to the Blackfin port.  i was using it as a 
> practical example.  we've talked about v2 in the past as the answer to many of 
> our problems and so we dont bother doing it in v1.  but that approach looks to 
> be wrong as v2 is of little practical importance.  instead we should be doing 
> what Jean-Christophe is doing: poaching good ideas until we get to the point 
> where v2 can simply die.

Full ACK.

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
While most peoples' opinions change, the conviction of their correct-
ness never does.

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Mike,

In message <200904201120.51435.vapier@gentoo.org> you wrote:
>
> i never said "kill it now"; quite the opposite really.  in fact, it looks like 
> you really arent taking your own saying to heart.  my point is to look to the 
> future and stop wasting resources.  if v1 incorporates all the features of v2, 
> then v2 has no purpose at all except to split development and waste peoples 
> time.  the approach set out originally was to keep v1 usable while we look at 
> getting v2 up to feature parity of v1.  but apparently v2 has no interest at 

In my understanding, this has never been the goal for Sascha or
Pengutronix.

> all with the larger community to actually make that happen.  that doesnt sound 
> like the open source spirit, that sounds like "i'll play with my toys over
> here and everyone else can do what they like".

But this is a perfectly legal attitude with free software - it  gives
you the freedom to do even that.

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
The most difficult thing in the world is to know how to  do  a  thing
and to watch someone else doing it wrong, without commenting.
                                                        -- T.H. White

[U-Boot] [ANNOUNCE] Kconfig support

[Kumar Gala]

On Apr 20, 2009, at 2:08 PM, Wolfgang Denk wrote:

> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090420120239.GC19818@game.jcrosoft.org> you wrote:
>>
>>> Beyond adding Kconfig's what's left to be done?
>> I've write a first batch of the generic Kconfig
>> for commmands, env, fs, disk, lib_generic and drivers
>>
>> I've start to add the at91 arm arch Kconfig files
>>
>> currently you can generate a .config and su defconfig
>>
>> the autoconf.h header is generated
>> and the Kconfig customisation is started also
>>
>> I've in mind to start by adding a arm arch with its boards
>> and merge them to the defconfig instead of the old way
>> but it's not already integreated
>>
>> it will be nice to help me by doing the same for other arch
>> and improve the kconfig integeration and generic file
>
> Can you please start SMALL?
>
> I mean: don't implement EVERYTHING before you post anything. You run
> the risk that one of your basic assumptions in the very first patch
> might not be accepted, and all the remaining effort is lost and has to
> be redone.
>
> Publish your stuff EARLY!!!
>
> Best regards,
>
> Wolfgang Denk

I agree with Wolfgang.  There are some discussion points (for example  
generation of src files vs pre-gen files being committed).

- k

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Mon, Apr 20, 2009 at 02:29:32PM -0400, Mike Frysinger wrote:
> [stupid attempt of a flame war deleted]

For the audience which is wondering about what's going on here, I have
no idea.

The idea behind B-Boot-v2 is: U-Boot itself is a *great* bootloader from
the user's poing of view. It is the best thing we have in the open
source market place, and it is especially *much* better than all the
redboots, grubs whatever.

When we started the v2 effort, we saw that U-Boot has a problem with
it's inner design. It was great when the U-Boot project started, but it
has (successfully) grown over the years, and as with every project that
has not been reworked over more than a decade, it is almost impossible
to fix design decisions without breaking all the boards out there. Yes,
it works with the Linux kernel, but compare the size of the communities.

So our intention was and is:

1. Wolfgang has a focus on stability and gradual changes. We respect this
   political position because it is a *good* one.

2. We need something else four our ARM, PowerPC, Blackfin and x86
   projects. The technical features I'm talking about are in the README
   document. The focus is on a modern design, extensability and
   testability, not on feature completeness.

3. It was an active decision from our team *not* to fork and call it
   something else than U-Boot(-v2) when we started. We see that the
   U-Boot community is strong, it has long term aims and last but not
   least, it has a *great* bootloader. We talked to Wolfgang before
   doing so, and Wolfgang's position was in the spirit of "go ahead,
   here is a git tree, and let the community decide".

4. v2 has been designed with much of the technical ideas of modern Linux
   kernels in mind; most probably v1 would have done the same if it had
   started 10 years later. So we think our work fits perfectly into the
   spirit of the U-Boot project.

4. Yes, community splitup is bad. But if one community has overlapping
   aims which can be worked on under the same roof - why on earth should
   we not do this?

5. It may happen that the v1 people take features from v2 and bring them
   into v1 over the time. Great than - v2 would have done it's job then.

6. It may happen that the v2 community grows over the time and more and
   more boards will be added. Great then - users would have a choice
   *within* the U-Boot community, up to a gradual change to the new code
   base.

What ever will happen - I don't see *any* reason for whatever Mike is
trying to enforce here.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Daniel Stenberg]

On Tue, 21 Apr 2009, Robert Schwebel wrote:

> What ever will happen - I don't see *any* reason for whatever Mike is trying 
> to enforce here.

I don't see how Mike is trying to nor can enforce anything like that. He's a 
single person expressing his views.

But I do second the notion that good ideas could (and should?) be copied from 
v2 to v1 since v2 isn't an available option for lots of u-booters (yeah 
that's the name of users using u-boot! ;-).

-- 

  / daniel.haxx.se

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Robert,

just to put a few points right:

In message <20090421070431.GX5367@pengutronix.de> you wrote:
>
> So our intention was and is:
> 
> 1. Wolfgang has a focus on stability and gradual changes. We respect this
>    political position because it is a *good* one.

This is not quite correct. What  I  consider  important  is  an  evo-
lutionary path - this may include bigger changes and reorganizations,
but  I  consider  it a bad idea to not provide a reasonable migration
path for larger parts of the existing community.


> 3. It was an active decision from our team *not* to fork and call it
>    something else than U-Boot(-v2) when we started. We see that the
>    U-Boot community is strong, it has long term aims and last but not
>    least, it has a *great* bootloader. We talked to Wolfgang before
>    doing so, and Wolfgang's position was in the spirit of "go ahead,
>    here is a git tree, and let the community decide".

This is actually wrong. When we talked about these  things,  you  had
already  performed  a  split, and had a up-and-running implementation
behind your (kind of closed) doors. It was me who asked you  to  make
this existing code openly available.

What I missed, and what I  still  consider  a  big  chance  that  was
missed, is any public discussion about such a new design - before the
actual  work  was  started,  or  at  least  before  such  irrevocable
decisions were made as not to consider any form of an upgrade path.

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
Anything free is worth what you pay for it.

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Tue, Apr 21, 2009 at 04:40:04PM +0200, Wolfgang Denk wrote:
> > 1. Wolfgang has a focus on stability and gradual changes. We respect this
> >    political position because it is a *good* one.
>
> This is not quite correct. What  I  consider  important  is  an  evo-
> lutionary path - this may include bigger changes and reorganizations,
> but  I  consider  it a bad idea to not provide a reasonable migration
> path for larger parts of the existing community.

An evolutionary path in limited time is not possible when you want to
change fundamental design issues. This is our oppinion, feel free to
proove us wrong.

> > 3. It was an active decision from our team *not* to fork and call it
> >    something else than U-Boot(-v2) when we started. We see that the
> >    U-Boot community is strong, it has long term aims and last but not
> >    least, it has a *great* bootloader. We talked to Wolfgang before
> >    doing so, and Wolfgang's position was in the spirit of "go ahead,
> >    here is a git tree, and let the community decide".
>
> This is actually wrong. When we talked about these  things,  you  had
> already  performed  a  split, and had a up-and-running implementation
> behind your (kind of closed) doors. It was me who asked you  to  make
> this existing code openly available.

Well, how do you think such things are going to happen? By starting with
a big vapourware discussion? Come on. Someone has to show some code, and
that's what we did. It is all GPL, so it is as much open or closed doors
as anything else.

> What I missed, and what I  still  consider  a  big  chance  that  was
> missed, is any public discussion about such a new design - before the
> actual  work  was  started,  or  at  least  before  such  irrevocable
> decisions were made as not to consider any form of an upgrade path.

Until now all we hear is whining about the design, while almost nobody
has ever looked into the code. Could you elaborate? What would you like
to see? What is there that you don't like? Please feel free to send
patches if you have other ideas for v2.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Sascha Hauer]

On Tue, Apr 21, 2009 at 04:40:04PM +0200, Wolfgang Denk wrote:
> Dear Robert,
> 
> just to put a few points right:
> 
> In message <20090421070431.GX5367@pengutronix.de> you wrote:
> >
> > So our intention was and is:
> > 
> > 1. Wolfgang has a focus on stability and gradual changes. We respect this
> >    political position because it is a *good* one.
> 
> This is not quite correct. What  I  consider  important  is  an  evo-
> lutionary path - this may include bigger changes and reorganizations,
> but  I  consider  it a bad idea to not provide a reasonable migration
> path for larger parts of the existing community.

Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries
two incompatible network driver APIs for at least the last seven years and
still 19 drivers have not switched to the new API.

It was exactly this kind of stagnation that made me fork U-Boot. I was
really tired of this ongoing "no, please don't break existing code". And
honestly, I was so blinded by ifdefs that I couldn't even see what the
existing code was. So I started hacking on U-Boot in my spare time, not
knowing where this would lead, but I must admit that it was really fun
to remove everything which I didn't know for what it was good for. You'd
be surprised to see how much dead code hides in U-Boot. Additionally
I wanted to see what's possible. Is it possible to integrate a driver
model without adding much binary space? Is it possible to create a
filesystem layer in this limited space? You see I was in a hacking mood
and not in a discuss-on-mailing-lists mood. What would have happened if
I posted a "I want a driver model" mail on the list? Probably one of the
first answers would have been "U-Boot is about size and simplicity".
Some mails later I probably would have gone back to business as usual.
Even if I tried to integrate a driver model into current U-Boot, how
long would it take till all drivers make use of it given the fact that
a simple thing like CONFIG_NET_MULTI stays for seven years?

I started this for fun, but I think integrating a driver model into
U-Boot without breaking existing stuff is no fun at all and I'm pretty
sure none of our customers would have payed us for working on this
topic.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Sascha,

In message <20090421182102.GZ21747@pengutronix.de> you wrote:
>
> > This is not quite correct. What  I  consider  important  is  an  evo-
> > lutionary path - this may include bigger changes and reorganizations,
> > but  I  consider  it a bad idea to not provide a reasonable migration
> > path for larger parts of the existing community.
> 
> Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries
> two incompatible network driver APIs for at least the last seven years and
> still 19 drivers have not switched to the new API.

What exactly do you complain about? Have there been any such patches
posted that I 9or anybody else) rejected?

> It was exactly this kind of stagnation that made me fork U-Boot. I was

You did not even attempt to fix this, or did you, and I repressed the
memory of this?


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
If you think the problem is bad now, just wait until we've solved it.
                                                        Epstein's Law

[U-Boot] [ANNOUNCE] Kconfig support

[Sascha Hauer]

On Tue, Apr 21, 2009 at 10:08:38PM +0200, Wolfgang Denk wrote:
> Dear Sascha,
> 
> In message <20090421182102.GZ21747@pengutronix.de> you wrote:
> >
> > > This is not quite correct. What  I  consider  important  is  an  evo-
> > > lutionary path - this may include bigger changes and reorganizations,
> > > but  I  consider  it a bad idea to not provide a reasonable migration
> > > path for larger parts of the existing community.
> > 
> > Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries
> > two incompatible network driver APIs for at least the last seven years and
> > still 19 drivers have not switched to the new API.
> 
> What exactly do you complain about? Have there been any such patches
> posted that I 9or anybody else) rejected?
> 
> > It was exactly this kind of stagnation that made me fork U-Boot. I was
> 
> You did not even attempt to fix this, or did you, and I repressed the
> memory of this?

No, neither I tried to fix it nor did anybody else. Probably because
noone wants to dig through numerous drivers for which he most likely does
not even have the hardware. The solution is to mark them as broken and
you'll get the relevant patches within a week. The drivers which are
still not fixed after some months can be removed as nobody seems to have
interest in them. I know this is a strong weapon which should be handled
with care, but I think sometimes it's necessary to use it.

sha at octopus:~/octopus/u-boot/u-boot find board -name "flash.c" | wc -l
201
sha at octopus:~/octopus/u-boot/u-boot find board -name "config.mk"| wc -l
411

So nearly half of the boards in U-Boot seem to be unmaintained since the
advent of the generic flash driver five years ago.
How can you possibly ever change the API for the flash driver with 201
different flash drivers in the tree without marking something as broken?
One of these boards is the Auerswald Innokom, a board Robert once
ported. We probably still have it somewhere @Pengutronix, but nobody in
the world has any interest in running a top of tree U-Boot on it. Still
it is in the tree and by policy it has to be supported for all eternity.
Mark the boards as broken, remove them and give the others some air to
breeze to actually change something without drowning in legacy code.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Sascha,

In message <20090421223025.GA21747@pengutronix.de> you wrote:
>
> sha at octopus:~/octopus/u-boot/u-boot find board -name "flash.c" | wc -l
> 201
> sha at octopus:~/octopus/u-boot/u-boot find board -name "config.mk"| wc -l
> 411
> 
> So nearly half of the boards in U-Boot seem to be unmaintained since the
> advent of the generic flash driver five years ago.

I disagree with your interpretation. Why should aboard maintainer
change running code without need? We never asked to change the flash
driver of existing boards because there was no need for doing this.
So why should anybody spend efforts to change these?

> How can you possibly ever change the API for the flash driver with 201
> different flash drivers in the tree without marking something as broken?

Well, *if* we wanted to change the API, that would be a reason to get
rid of the old legacy flash drivers. But so far no  such  API  change
has  been  necessary.  And  here  and  there the old drivers are even
necessary due to restrictions of the CFI driver that are not too easy
to fix.

So what exactly is it you are critizising? That we don't abondon
working code just because it is old? Hm...

> One of these boards is the Auerswald Innokom, a board Robert once
> ported. We probably still have it somewhere @Pengutronix, but nobody in
> the world has any interest in running a top of tree U-Boot on it. Still
> it is in the tree and by policy it has to be supported for all eternity.

Feel free to submit patches to remove it from the tree if you care.

On the other hand - how much effort was  actually  spent  on  keeping
this  board  alive?  Obviously  not  much, because so far nobody com-
plained about it. Actually that's the whole idea about having a board
in mainline. If you look at the changes  that  were  applied  to  the
related  files,  it's  all stuff that was done 99% automatically with
some scripts - and I don't really care if these  are  applied  to  20
boards or to 200.


I fail to understand what you are trying to tell us.


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 can call spirits from the vasty deep."
"Why so can I, or so can any man; but will they come when you do call
for them?"          - Shakespeare, 1 King Henry IV, Act III, Scene I.

[U-Boot] [ANNOUNCE] Kconfig support

[Ladislav Michl]

On Tue, Apr 21, 2009 at 10:08:38PM +0200, Wolfgang Denk wrote:
> Dear Sascha,
> 
> In message <20090421182102.GZ21747@pengutronix.de> you wrote:
> >
> > > This is not quite correct. What  I  consider  important  is  an  evo-
> > > lutionary path - this may include bigger changes and reorganizations,
> > > but  I  consider  it a bad idea to not provide a reasonable migration
> > > path for larger parts of the existing community.
> > 
> > Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries
> > two incompatible network driver APIs for at least the last seven years and
> > still 19 drivers have not switched to the new API.
> 
> What exactly do you complain about? Have there been any such patches
> posted that I 9or anybody else) rejected?

I wouldn't read this as a complain, it is just a statement of fact that
design flaws in v2 got fixed several orders of magnitude faster than in v1.

> > It was exactly this kind of stagnation that made me fork U-Boot. I was
> 
> You did not even attempt to fix this, or did you, and I repressed the
> memory of this?

The point probably is that is was easier to design it right from scratch
and then add support for needed cpus and devices. And looking at v2 I have to
admit that investing the same time I spent fixing v1 for nestar board into v2
I'd be already done (minus i2c stuff) and could enjoy tons of spare time
otherwise consumed by evolutionary fixing v1 (yes, evolution works quite
well, but neither easy nor the best way things could be done).

Just my two cents...

Best regards,
	ladis

[U-Boot] [ANNOUNCE] Kconfig support

[Robert Schwebel]

On Wed, Apr 22, 2009 at 01:12:07AM +0200, Wolfgang Denk wrote:
> > How can you possibly ever change the API for the flash driver with 201
> > different flash drivers in the tree without marking something as broken?
>
> Well, *if* we wanted to change the API, that would be a reason to get
> rid of the old legacy flash drivers. But so far no  such  API  change
> has  been  necessary.  And  here  and  there the old drivers are even
> necessary due to restrictions of the CFI driver that are not too easy
> to fix.
>
> So what exactly is it you are critizising? That we don't abondon
> working code just because it is old? Hm...

If you consider the current code duplication and ifdef hackery to be an
API, then yes, you are right and there is no need to change anything.

> > One of these boards is the Auerswald Innokom, a board Robert once
> > ported. We probably still have it somewhere @Pengutronix, but nobody in
> > the world has any interest in running a top of tree U-Boot on it. Still
> > it is in the tree and by policy it has to be supported for all eternity.
>
> Feel free to submit patches to remove it from the tree if you care.

Why should I?

> On the other hand - how much effort was  actually  spent  on  keeping
> this  board  alive?  Obviously  not  much, because so far nobody com-
> plained about it. Actually that's the whole idea about having a board
> in mainline. If you look at the changes  that  were  applied  to  the
> related  files,  it's  all stuff that was done 99% automatically with
> some scripts - and I don't really care if these  are  applied  to  20
> boards or to 200.

It is not the effort to keep it alive. These old boards, while being
there, add the requirement not to be broken by any change in the tree.
This makes it impossible to make any fundamental design changes in
U-Boot, like what Sascha did in v2.

> I fail to understand what you are trying to tell us.

Re-read the mails, it is all in there.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [ANNOUNCE] Kconfig support

[Heiko Schocher]

Hello Ladislav

Ladislav Michl wrote:
> On Wed, Apr 22, 2009 at 01:12:07AM +0200, Wolfgang Denk wrote:
>>> One of these boards is the Auerswald Innokom, a board Robert once
>>> ported. We probably still have it somewhere @Pengutronix, but nobody in
>>> the world has any interest in running a top of tree U-Boot on it. Still
>>> it is in the tree and by policy it has to be supported for all eternity.
>> Feel free to submit patches to remove it from the tree if you care.
>>
>> On the other hand - how much effort was  actually  spent  on  keeping
>> this  board  alive?  Obviously  not  much, because so far nobody com-
>> plained about it. Actually that's the whole idea about having a board
>> in mainline. If you look at the changes  that  were  applied  to  the
>> related  files,  it's  all stuff that was done 99% automatically with
>> some scripts - and I don't really care if these  are  applied  to  20
>> boards or to 200.
>>
>> I fail to understand what you are trying to tell us.
> 
> May I? Last time I looked at mainline U-Boot about year ago, sending few
> patches and it was working for me. Since then some changes (only minor ones
> from design pespective) were applied (some of them automatically with some
> scripts) and since then my board support was broken. It cannot boot neither
> from network - network code uses get_timer and I bet _no_ OMAP based will get
> IP address from my DHCP server sitting behind ancient hub - (still true and so
> far no comments except from Dirk) nor from NAND (already fixed). And once
> AT91RM9200 landed on my table I needed to patch other AT91RM9200 based boards
> just because they suffered the same problems I meet. Obviously noone noticed
> for years. Thats from my perspective too much breakage such a "cosmetic"
> changes. And what if we try to do any fundamental one?
> 
> Based on this experience I wouldn't expect much of those 200 boards to work
> properly. Or was it only my bad luck? To sum this up: wide majority of boards
> is just sitting in tree, without any interest. It compiles so it must be good,
> right? Switching v1 into maintenance mode only makes sense as well, it is just

What else should a maintainer do? He have not all boards to try the
new code! You can just look at Coding Style, clean compile and maybe
he see, that this Code couldn;t work ...

To look, that a board works with actual code is at least the job
from the boardmaintainers, and if they notice that some code no
longer works, they have to post patches which fixes that... whats
wrong with that?

> matter of decision. And you obviously decide to incrementaly fix v1. So there
> really is nothing to discuss.
> 
> Now given the fact that most board support consist of config file
> and few lines of board specific glue code, the idea of doing major
> architectural changes in v2 and migrating board support there doesn't
> look completely wrong, does it? Of course, if v1 "just works" for simple
> designs there is no need to throw it away, but I perfectly understand
> Sergey Kubushyn despair trying to support more devices of the same kind.

I can speak here only for the i2c subsystem. Sergey posted patches which
where from the design "nearly" perfect, but this doesn;t gone in main-
line because missing CodingStyle fixes, Patches in not a "good Style"
and so on ... and there were 2-3 minimal points we couldn;t arrange :-(
And someday he went away, because his time was over (no more money
for it) ... :-( This way open source did not work! We cannot plonk
some patches (which change design) to the mailinglist and ignore
all comments, and if they not go in mainline blackguard actual code!

And so we stand here ... (I try to forward this design in my freetime,
but this is a rare resource ...)

So I opened 2 branches in u-boot-i2c.git to compare the 2 "suggestions"
for the multibus approach in the i2c subsystem, so we have a real base
for discussion.

But no one seems to have interest in this :-(

And I have hope, that this multibus design can be adapted for other
subsystems too ... but somebody have to do this work, and if this
is in v1, he has to do this for all boards!

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [ANNOUNCE] Kconfig support

[Ladislav Michl]

On Wed, Apr 22, 2009 at 01:12:07AM +0200, Wolfgang Denk wrote:
> > One of these boards is the Auerswald Innokom, a board Robert once
> > ported. We probably still have it somewhere @Pengutronix, but nobody in
> > the world has any interest in running a top of tree U-Boot on it. Still
> > it is in the tree and by policy it has to be supported for all eternity.
> 
> Feel free to submit patches to remove it from the tree if you care.
> 
> On the other hand - how much effort was  actually  spent  on  keeping
> this  board  alive?  Obviously  not  much, because so far nobody com-
> plained about it. Actually that's the whole idea about having a board
> in mainline. If you look at the changes  that  were  applied  to  the
> related  files,  it's  all stuff that was done 99% automatically with
> some scripts - and I don't really care if these  are  applied  to  20
> boards or to 200.
> 
> I fail to understand what you are trying to tell us.

May I? Last time I looked at mainline U-Boot about year ago, sending few
patches and it was working for me. Since then some changes (only minor ones
from design pespective) were applied (some of them automatically with some
scripts) and since then my board support was broken. It cannot boot neither
from network - network code uses get_timer and I bet _no_ OMAP based will get
IP address from my DHCP server sitting behind ancient hub - (still true and so
far no comments except from Dirk) nor from NAND (already fixed). And once
AT91RM9200 landed on my table I needed to patch other AT91RM9200 based boards
just because they suffered the same problems I meet. Obviously noone noticed
for years. Thats from my perspective too much breakage such a "cosmetic"
changes. And what if we try to do any fundamental one?

Based on this experience I wouldn't expect much of those 200 boards to work
properly. Or was it only my bad luck? To sum this up: wide majority of boards
is just sitting in tree, without any interest. It compiles so it must be good,
right? Switching v1 into maintenance mode only makes sense as well, it is just
matter of decision. And you obviously decide to incrementaly fix v1. So there
really is nothing to discuss.

Now given the fact that most board support consist of config file
and few lines of board specific glue code, the idea of doing major
architectural changes in v2 and migrating board support there doesn't
look completely wrong, does it? Of course, if v1 "just works" for simple
designs there is no need to throw it away, but I perfectly understand
Sergey Kubushyn despair trying to support more devices of the same kind.
In other words, incrementaly changing v1 to be at least close to v2
(from design perspective) would take order of magnitude more man power
than doing it from scratch (and hey, pengutronix guys already did it for
us!), but for those who love slow and painfull paths, there is nothing
really wrong with this approach.

Anyway, this discussion is probably pointless without knowing what are
long term goals of U-Boot (hint: Do we ever consider supporting anything
like Sergey described in thread "Multiple device support - none at all?"?
Yes, I know there were some hints how to hack it "somehow", but I doubt
neither authors of such hint consider them nice solution)

Best regards,
	ladis

[U-Boot] [ANNOUNCE] Kconfig support

[Ladislav Michl]

Hello Heiko!

On Wed, Apr 22, 2009 at 10:53:46AM +0200, Heiko Schocher wrote:
> Hello Ladislav
> 
> Ladislav Michl wrote:
> > May I? Last time I looked at mainline U-Boot about year ago, sending few
> > patches and it was working for me. Since then some changes (only minor ones
> > from design pespective) were applied (some of them automatically with some
> > scripts) and since then my board support was broken. It cannot boot neither
> > from network - network code uses get_timer and I bet _no_ OMAP based will get
> > IP address from my DHCP server sitting behind ancient hub - (still true and so
> > far no comments except from Dirk) nor from NAND (already fixed). And once
> > AT91RM9200 landed on my table I needed to patch other AT91RM9200 based boards
> > just because they suffered the same problems I meet. Obviously noone noticed
> > for years. Thats from my perspective too much breakage such a "cosmetic"
> > changes. And what if we try to do any fundamental one?
> > 
> > Based on this experience I wouldn't expect much of those 200 boards to work
> > properly. Or was it only my bad luck? To sum this up: wide majority of boards
> > is just sitting in tree, without any interest. It compiles so it must be good,
> > right? Switching v1 into maintenance mode only makes sense as well, it is just
> 
> What else should a maintainer do? He have not all boards to try the
> new code! You can just look at Coding Style, clean compile and maybe
> he see, that this Code couldn;t work ...

That's perfectly understandable. I'm just trying to point out, that
"design flaws can be fixed incrementaly, without breaking anything"
attitude does not reflect reality. We break stuff and noone can test
for all boards, so the real question is acceptable level of breakage
we have to suffer from before deciding to try another approach. Just
imagine amount of changes needed, amount of changes done over last year,
amount of boards maintainers care about their board support since they
pushed them into mainline and ask yourself a question how many boards
can survive each such a change still functional. All the long time this
slow evolution will happening, we will pretending ourselves that
we did not break anything and everyone is happy.

> To look, that a board works with actual code is at least the job
> from the boardmaintainers, and if they notice that some code no
> longer works, they have to post patches which fixes that... whats
> wrong with that?

Nothing, were did I express the opposite? I'm not whining anyone for
breaking anything, just trying to honestly describe situation I had to
face.

> > matter of decision. And you obviously decide to incrementaly fix v1. So there
> > really is nothing to discuss.
> > 
> > Now given the fact that most board support consist of config file
> > and few lines of board specific glue code, the idea of doing major
> > architectural changes in v2 and migrating board support there doesn't
> > look completely wrong, does it? Of course, if v1 "just works" for simple
> > designs there is no need to throw it away, but I perfectly understand
> > Sergey Kubushyn despair trying to support more devices of the same kind.
> 
> I can speak here only for the i2c subsystem. Sergey posted patches which
> where from the design "nearly" perfect, but this doesn;t gone in main-
> line because missing CodingStyle fixes, Patches in not a "good Style"
> and so on ... and there were 2-3 minimal points we couldn;t arrange :-(
> And someday he went away, because his time was over (no more money
> for it) ... :-( This way open source did not work! We cannot plonk
> some patches (which change design) to the mailinglist and ignore
> all comments, and if they not go in mainline blackguard actual code!
> 
> And so we stand here ... (I try to forward this design in my freetime,
> but this is a rare resource ...)

Yup, and I hereby point to amount of work Pengutronix already did for us.

> So I opened 2 branches in u-boot-i2c.git to compare the 2 "suggestions"
> for the multibus approach in the i2c subsystem, so we have a real base
> for discussion.

And we have v2 as a real base for discusion as well and I have bad feeling
that not many people actually looked at v2 code. Its whole design reflects
"multibus approach" and adding i2c here is quite an easy (but time consuming,
of course) task.

> But no one seems to have interest in this :-(

Understandable, clean design does not show up on itself. Most embedded people
hack until it works and then it's done. They are (myself including) payed to
work exactly this way. How would I explain my boss that I spent significant
amount of time designing anything we could live happily without for at least
one year? (doable, but... ) Although situation improved a lot over last few
years. Again, see what is already done in v2. Let's see how many effort will
cost migration to Kconfig and remember how many effort did cost OBJ-y makefile
approach. And all this is fun comparing to driver model conversion.

> And I have hope, that this multibus design can be adapted for other
> subsystems too ... but somebody have to do this work, and if this
> is in v1, he has to do this for all boards!

Sure, therefore I suggested to put v1 to maintenence only mode and add new
board support into v2. Actually there is much more to do before for example
mips board can be added or before you can boot from MMC card, but the real
question is whenever changing all boards in v1 to use "multibus design" is
worth dealing with. After all, existing boards ships with u-boot, so it must
do its job well. And with respect to this fact even if we put v1 info feature
freeze mode, time spent with it till now would not be wasted at all. Just look
now many boards it served well! And still serves, because most board ships with
U-Boot version initially ported for them till the end of production. But if
decision is to support v1 till the end of ages in hope its design flaws will be
fixed over time I'm perfectly fine with that. I just do not believe this is
anywhere close to happen in finite time. After all the only possible solution
is to let individual developers to decide which approach is closer to their
hearts. And I'm already decided.

Best regards,
	ladis

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Robert,

In message <20090422071711.GH5367@pengutronix.de> you wrote:
> 
> > > One of these boards is the Auerswald Innokom, a board Robert once
> > > ported. We probably still have it somewhere @Pengutronix, but nobody in
> > > the world has any interest in running a top of tree U-Boot on it. Still
> > > it is in the tree and by policy it has to be supported for all eternity.
> >
> > Feel free to submit patches to remove it from the tree if you care.
> 
> Why should I?

Ummm... because you are listed as the board  maintainer?  Either  you
accept  your  responsibility  for  your  code and maintain it, or you
decide the board is not needed any more and should be  removed,  then
it is your responsibility to submit a patch to remove it.

Your fire-and-forget attitude (first I get this into mainline as long
as it makes sense for me; when I lose interest I  just  go  away  and
leave the dirty work to others) is not exactly in line with community
spirit.


I think you are on thin ice here - first neglecting your  responsibi-
lities  as a board maintainer, and then complaining that the board is
not in the state you  think  it  should  be,  expresses  a  *lot*  of
ignorance.


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
Computers are not intelligent.  They only think they are.

[U-Boot] [ANNOUNCE] Kconfig support

[Wolfgang Denk]

Dear Ladislav,

In message <20090422132536.GA2408@localhost.localdomain> you wrote:
> 
> > What else should a maintainer do? He have not all boards to try the
> > new code! You can just look at Coding Style, clean compile and maybe
> > he see, that this Code couldn;t work ...
> 
> That's perfectly understandable. I'm just trying to point out, that
> "design flaws can be fixed incrementaly, without breaking anything"
> attitude does not reflect reality. We break stuff and noone can test

Please be fair. Re-read the whole discussion,  and  maybe  the  whole
mailing  list  archive.  Who  was  it  who claimed that this was some
(unwritten?) rule of U-Boot development?  It  is  very  difficult  to
defent  against malicious roumors like this, so I tend to just ignore
such accusations. Fact ist, they are just wrong.

> for all boards, so the real question is acceptable level of breakage
> we have to suffer from before deciding to try another approach. Just
> imagine amount of changes needed, amount of changes done over last year,
> amount of boards maintainers care about their board support since they
> pushed them into mainline and ask yourself a question how many boards
> can survive each such a change still functional. All the long time this
> slow evolution will happening, we will pretending ourselves that
> we did not break anything and everyone is happy.

Of course, board maintainers  are  supposed  to  regularly  test  new
versions,  and  ideally  provide  fixes  or  at  least complain about
breakage. Actually quite a lot of boards that cover a wide  bandwidth
of  different features and requirements *are* actually tested more or
less regularly.

There are broken boards around, too -  of  course.  There  are  those
board  maintainers  who  simply dump their stuff on us and then never
show up again with any contributions any more.

I don't know how we could prevent that. It's probably happening  with
any similar software project. For exampole, do you think all exisitng
board  configurations  in  the Linux kernel are working, or even com-
pile-clean?


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
In English, every word can be verbed.  Would that it were  so  in our
programming languages.

[U-Boot] [ANNOUNCE] Kconfig support

[Jerry Van Baren]

Wolfgang Denk wrote:

[snip]

> There are broken boards around, too -  of  course.  There  are  those
> board  maintainers  who  simply dump their stuff on us and then never
> show up again with any contributions any more.
> 
> I don't know how we could prevent that. It's probably happening  with
> any similar software project. For exampole, do you think all exisitng
> board  configurations  in  the Linux kernel are working, or even com-
> pile-clean?

Note that this happens even worse in the commercial world: how many 
printers were thrown in dumpsters because users bought a new computer 
running Vista and the printer manufacturer couldn't be bothered to write 
a new Vista-clean driver for the printers they had already sold?  They 
just said "Sorry, buy a new printer."  That is a very obvious example, 
there are tons of other examples.

> Best regards,
> Wolfgang Denk

Ditto,
gvb

[U-Boot] [ANNOUNCE] Kconfig support

[Ladislav Michl]

On Wed, Apr 22, 2009 at 10:26:12AM -0400, Jerry Van Baren wrote:
> Wolfgang Denk wrote:

Dear Wolfgang,

>> Ladislav Michl wrote:
>>> That's perfectly understandable. I'm just trying to point out, that
>>> "design flaws can be fixed incrementaly, without breaking anything"
>>> attitude does not reflect reality. We break stuff and noone can test
> 
>> Please be fair. Re-read the whole discussion,  and  maybe  the  whole
>> mailing  list  archive.  Who  was  it  who claimed that this was some
>> (unwritten?) rule of U-Boot development?  It  is  very  difficult  to
>> defent  against malicious roumors like this, so I tend to just ignore
>> such accusations. Fact ist, they are just wrong.

"design flaws can be fixed incrementaly, without breaking anything" comes from
"...we should be doing ... poaching good ideas until we get to the point where
v2 can simply die" to which you replied "Full ACK". I know it was not expressed
exactly this way, I know you know there is and will be some breakage and I put
it into this light to get a clue *why* we should.
To quote Heiko:
| And I have hope, that this multibus design can be adapted for other
| subsystems too ... but somebody have to do this work, and if this
| is in v1, he has to do this for all boards!
My question was "why we shoudn't break it the way everyone knows it is
broken"? Ie. during v1->v2 transition, whichever way it happens. Just like
even/odd release numbering before linux-2.6 era. You may also read this as
an opinion of someone who is unrelated to Pengutronix and understands the
reasons behind the fork.

On 2009-04-21 14:40:04 GMT, Wolfgang Denk:
| What I missed, and what I  still  consider  a  big  chance  that  was
| missed, is any public discussion about such a new design - before the
| actual  work  was  started,  or  at  least  before  such  irrevocable
| decisions were made as not to consider any form of an upgrade path.

Whole this discussion proves that not discussing new design before showing
code was right decission... And now there is a new code we can look at
and we still should "poaching good ideas until we get to the point where
v2 can simply die" and yet noone pointed which of them are good ones and
if it is worth to go upgrade path. I consider that a big chance possibly
missed ;-)

And right, this leads to nowhere and I actually make mistake when writing my
first post to this thread.

>> Of course, board maintainers  are  supposed  to  regularly  test  new
>> versions,  and  ideally  provide  fixes  or  at  least complain about
>> breakage. Actually quite a lot of boards that cover a wide  bandwidth
>> of  different features and requirements *are* actually tested more or
>> less regularly.
>>
>> There are broken boards around, too -  of  course.  There  are  those
>> board  maintainers  who  simply dump their stuff on us and then never
>> show up again with any contributions any more.

Wolfgang, now please try to be fair to me - and I'm going to make it
personal - and show where I reacted slowly, overreacted or did anything
what prevented board I'm maintaining to be fixed in mainline. That code
was written in 2005 and now, four years later it is still broken. Perhaps
it is my fault that I do not stand pushing for more than a month at once,
but all this is simply far over my patience (I sent arm925t timer fix,
there was no reaction, but a document what I should measure. Gah... I sent
board fixes for .03, there were scheduled for -next (why the hell, it
touched board specific files only) and current code is broken again, so
sent another bunch of patches...). I did not simply dump anything on you
and I'm testing my code, showing in regular intervals and still cannot
push it into mainline. And to do it I have to ping relevant custodian
several times, whine on IRC and that all simply takes too much effort.
Pushing anything into kernel is much easier. And to be fair to you, I
know you can hardly do anything with that, but I couldn't resist and
took your last sentence personal.

>> I don't know how we could prevent that. It's probably happening  with
>> any similar software project. For exampole, do you think all exisitng
>> board  configurations  in  the Linux kernel are working, or even com-
>> pile-clean?

No, I didn't claimed that at all. It seems we are still missing each others
point, so I'm inclined to end that as you suggested above. Thank you.

> Note that this happens even worse in the commercial world: how many  
> printers were thrown in dumpsters because users bought a new computer  
> running Vista and the printer manufacturer couldn't be bothered to write  
> a new Vista-clean driver for the printers they had already sold?  They  
> just said "Sorry, buy a new printer."  That is a very obvious example,  
> there are tons of other examples.

Heh, fortunately we have source and fortunately there are printers supporting
postscript :)

Best regards,
	ladis

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Monday 20 April 2009 14:42:24 Scott Wood wrote:
> Mike Frysinger wrote:
> > no one said otherwise.  please read the thread context before chiming in.
> >  if you had, you'd know that i was taking issue with the position of
> > "let's not do XXX in v1 because it exists in v2",
>
> I don't recall anyone advocating that position, other than your original
> inquiry ("i thought this was one of the points of u-boot-2?").
>
> You seem to be arguing with yourself. :-)

most recently, it's come up with (previous) kconfig/kbuild and the clock 
changes.  people (myself included) were hesitant to undertake big tasks by 
virtue of v2 already solving it.  so yes, i am in effect invalidating my 
previous stances and in the process, attempting to elicit/vet other people's 
opinions.  seems we're all up to speed now though.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090420/7411f41a/attachment.pgp 

[U-Boot] [ANNOUNCE] Kconfig support

[Scott Wood]

Mike Frysinger wrote:
> no one said otherwise.  please read the thread context before chiming in.  if 
> you had, you'd know that i was taking issue with the position of "let's not do 
> XXX in v1 because it exists in v2",

I don't recall anyone advocating that position, other than your original 
inquiry ("i thought this was one of the points of u-boot-2?").

You seem to be arguing with yourself. :-)

-Scott

[U-Boot] [ANNOUNCE] Kconfig support

[Mike Frysinger]

On Monday 20 April 2009 11:39:52 Grant Likely wrote:
> On Mon, Apr 20, 2009 at 9:34 AM, Sascha Hauer wrote:
> > On Mon, Apr 20, 2009 at 11:20:50AM -0400, Mike Frysinger wrote:
> >> On Monday 20 April 2009 10:53:39 Robert Schwebel wrote:
> >> > On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
> >> > > > U-Boot-v2 is used here to do real work in our projects. If it
> >> > > > isn't what you need, it is perfectly fine if you ignore it.
> >> > >
> >> > > my concern isnt really narrow to the Blackfin port. i was using it
> >> > > as a practical example. we've talked about v2 in the past as the
> >> > > answer to many of our problems and so we dont bother doing it in v1.
> >> > > but that approach looks to be wrong as v2 is of little practical
> >> > > importance. instead we should be doing what Jean-Christophe is
> >> > > doing: poaching good ideas until we get to the point where v2 can
> >> > > simply die.
> >> >
> >> > If you mean "you" while saying "we", then yes, it may be correct that
> >> > this is your plan. "We" don't have any plans to let v2 die.
> >> >
> >> > Should we be mindful of the future? But not at the expense of the
> >> > moment. Be mindful of the living Force, my young Padawan.
> >>
> >> i never said "kill it now"; quite the opposite really.  in fact, it
> >> looks like you really arent taking your own saying to heart.  my point
> >> is to look to the future and stop wasting resources.  if v1 incorporates
> >> all the features of v2, then v2 has no purpose at all except to split
> >> development and waste peoples time.
> >
> > Well as you said at the moment there is not much community around
> > u-boot-v2, so it's basically *our* time which we waste, and we are free
> > to do so. At the moment it seems you're wasting *your* time by warming
> > up this stupid discussion which Jerry already led to a nice ending.
>
> Indeed.  Let this thread die.  There is nothing wrong with v2 going
> off and trying something new.

no one said otherwise.  please read the thread context before chiming in.  if 
you had, you'd know that i was taking issue with the position of "let's not do 
XXX in v1 because it exists in v2", not "wtf does v2 exist".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090420/09d9636c/attachment.pgp 

[U-Boot] [ANNOUNCE] Kconfig support

[Grant Likely]

On Mon, Apr 20, 2009 at 9:34 AM, Sascha Hauer <sha@pengutronix.de> wrote:
> On Mon, Apr 20, 2009 at 11:20:50AM -0400, Mike Frysinger wrote:
>> On Monday 20 April 2009 10:53:39 Robert Schwebel wrote:
>> > On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
>> > > > U-Boot-v2 is used here to do real work in our projects. If it isn't
>> > > > what you need, it is perfectly fine if you ignore it.
>> > >
>> > > my concern isnt really narrow to the Blackfin port. i was using it as
>> > > a practical example. we've talked about v2 in the past as the answer
>> > > to many of our problems and so we dont bother doing it in v1. but that
>> > > approach looks to be wrong as v2 is of little practical importance.
>> > > instead we should be doing what Jean-Christophe is doing: poaching
>> > > good ideas until we get to the point where v2 can simply die.
>> >
>> > If you mean "you" while saying "we", then yes, it may be correct that
>> > this is your plan. "We" don't have any plans to let v2 die.
>> >
>> > Should we be mindful of the future? But not at the expense of the
>> > moment. Be mindful of the living Force, my young Padawan.
>>
>> i never said "kill it now"; quite the opposite really. ?in fact, it looks like
>> you really arent taking your own saying to heart. ?my point is to look to the
>> future and stop wasting resources. ?if v1 incorporates all the features of v2,
>> then v2 has no purpose at all except to split development and waste peoples
>> time.
>
> Well as you said at the moment there is not much community around
> u-boot-v2, so it's basically *our* time which we waste, and we are free
> to do so. At the moment it seems you're wasting *your* time by warming
> up this stupid discussion which Jerry already led to a nice ending.

Indeed.  Let this thread die.  There is nothing wrong with v2 going
off and trying something new.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.