[U-Boot] [ANNOUNCE] Kconfig support
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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! ;-).
Dear Robert,
just to put a few points right:
In message 20090421070431.GX5367@pengutronix.de you wrote:
So our intention was and is:
- 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.
- 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
On Tue, Apr 21, 2009 at 04:40:04PM +0200, Wolfgang Denk wrote:
- 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.
- 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
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:
- 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
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
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@octopus:~/octopus/u-boot/u-boot find board -name "flash.c" | wc -l 201 sha@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
Dear Sascha,
In message 20090421223025.GA21747@pengutronix.de you wrote:
sha@octopus:~/octopus/u-boot/u-boot find board -name "flash.c" | wc -l 201 sha@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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
When I try to do a make menuconfig I get:
[galak@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
On Apr 20, 2009, at 10:26 AM, Kumar Gala wrote:
When I try to do a make menuconfig I get:
[galak@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
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
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
participants (10)
-
Daniel Stenberg -
Heiko Schocher -
Jean-Christophe PLAGNIOL-VILLARD -
Jerry Van Baren -
Kumar Gala -
Ladislav Michl -
Mike Frysinger -
Robert Schwebel -
Sascha Hauer -
Wolfgang Denk