I don't think we should have two copies of the device tree. I removed the second copy in Tyan s289x boards. I also removed rom_address statements that were pre-CBFS. Abuild tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
Am Dienstag, den 06.10.2009, 13:52 -0600 schrieb Myles Watson:
I don't think we should have two copies of the device tree. I removed the second copy in Tyan s289x boards. I also removed rom_address statements that were pre-CBFS. Abuild tested.
I think the original idea why this wasn't done is to allow sconfig to develop from there. But I hope we'll get this switch done quick enough that sconfig changes can wait until newconfig is gone...
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
On Tue, Oct 6, 2009 at 2:31 PM, Patrick Georgi patrick@georgi-clan.de wrote:
Am Dienstag, den 06.10.2009, 13:52 -0600 schrieb Myles Watson:
I don't think we should have two copies of the device tree. I removed the second copy in Tyan s289x boards. I also removed rom_address statements that were pre-CBFS. Abuild tested.
I think the original idea why this wasn't done is to allow sconfig to develop from there.
I'm letting my ignorance show again. I don't know anything about sconfig.
But I hope we'll get this switch done quick enough that sconfig changes can wait until newconfig is gone...
That would be nice.
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
Rev 4727. Thanks, Myles
Am Dienstag, den 06.10.2009, 14:37 -0600 schrieb Myles Watson:
I'm letting my ignorance show again. I don't know anything about sconfig.
sconfig is newconfig minus the Makefile generation code. what remains is the part of newconfig that parses the device tree and creates the C representation of it, etc.
Eventually, I'll rewrite it in C, to remove the python dependency, but for now, it's quite similar to newconfig - just with lots of stuff removed. (Thank you, Ron!)
Patrick
I don't recommend doing this but it's done.
But until we kill newconfig, with this change, we've locked sconfig into supporting the newconfig tree grammar. If we fix or improve things for devicetree.cb we stand a change of breaking builds based on newconfig.
So, in future, if we change the new tree grammar for some reason, we stand a chance of breaking abuild.
If we're going to do something like this change I'd prefer just removing Config.lb and Options.lb.
ron
Am Dienstag, den 06.10.2009, 13:46 -0700 schrieb ron minnich:
So, in future, if we change the new tree grammar for some reason, we stand a chance of breaking abuild.
Future? We got >50% of all boards in kconfig (but not verified to work, that will have to happen over time). I intend to do the rest soon, and improve the chances of things working out of the box (by comparing configuration variables).
What's to stop us from dropping newconfig at that time (talking days and weeks, not months)? I think we should be able to restrain us from improving the device tree syntax for a while longer ;)
Patrick
On Tue, Oct 6, 2009 at 1:53 PM, Patrick Georgi patrick@georgi-clan.de wrote:
What's to stop us from dropping newconfig at that time (talking days and weeks, not months)? I think we should be able to restrain us from improving the device tree syntax for a while longer ;)
built is one thing, tested another.
I'm still all for dropping Config.lb when a target is known to work. And killing newconfig is fine with me any time.
ron
ron minnich wrote:
I'm still all for dropping Config.lb when a target is known to work.
I think that will hold up progress for quite some time. By progress here I mean "having a single build system to minimize confusion".
Of course it would be great to have builds tested more now that there are big changes going on - but I think it would be OK to break now and fix later - or?
And killing newconfig is fine with me any time.
Hm, isn't it needed for building from {Config,Options}.lb?
//Peter
I don't recommend doing this but it's done.
It's easily reverted.
But until we kill newconfig, with this change, we've locked sconfig into supporting the newconfig tree grammar. If we fix or improve things for devicetree.cb we stand a change of breaking builds based on newconfig.
My opinion is that we have too many things up in the air. When Patrick is trying to figure out differences between Kconfig and newconfig, the last thing he needs is a devicetree.cb that has been modified from the Config.lb breaking things.
So, in future, if we change the new tree grammar for some reason, we stand a chance of breaking abuild.
I thought the idea was to switch over to kbuildall before we made other major changes. Otherwise we have too many things to test. For example the s2881 that used to work.
If we're going to do something like this change I'd prefer just removing Config.lb and Options.lb.
That seems one step more drastic than what I did.
Thanks, Myles
On 06.10.2009 22:56, Myles Watson wrote:
I don't recommend doing this but it's done.
It's easily reverted.
I'm happy with the change.
But until we kill newconfig, with this change, we've locked sconfig into supporting the newconfig tree grammar. If we fix or improve things for devicetree.cb we stand a change of breaking builds based on newconfig.
My opinion is that we have too many things up in the air. When Patrick is trying to figure out differences between Kconfig and newconfig, the last thing he needs is a devicetree.cb that has been modified from the Config.lb breaking things.
In German there is a proverb about having too many construction sites at once. I'm happy that the CBFS conversion seems to be done, and the ongoing Kconfig work is also awesome. Taking into account that new boards are ported every few weeks, it becomes clear that a new devicetree.cb syntax is not something to develop right now.
Besides that, the v3 dts stuff was (and still is) awesome, and considering that qemu people have been working on dts as well for their device model stuff, we should seriously consider not reinventing devicetree structure and syntax again.
So, in future, if we change the new tree grammar for some reason, we stand a chance of breaking abuild.
I thought the idea was to switch over to kbuildall before we made other major changes. Otherwise we have too many things to test. For example the s2881 that used to work.
Yes, can we please at least try to keep those boards working (or restore them to working state) which we can test? Moving infrastructure too fast and breaking boards contributed to the waning interest in v3.
If we're going to do something like this change I'd prefer just removing Config.lb and Options.lb.
That seems one step more drastic than what I did.
Once Kconfig works for all boards and kbuildall works for all boards, why not? But before that... I am very afraid of repeating procedures which may have had bad impact on v3.
Regards, Carl-Daniel
On 06.10.2009 22:40, Patrick Georgi wrote:
sconfig is newconfig minus the Makefile generation code. what remains is the part of newconfig that parses the device tree and creates the C representation of it, etc.
Eventually, I'll rewrite it in C, to remove the python dependency, but for now, it's quite similar to newconfig - just with lots of stuff removed.
Do we really want to throw away the design that went into dts by rewriting the v2 sconfig?
If I misunderstood your intentions, please accept my apologies.
Regards, Carl-Daniel
let's do one thing first. Let's not worry about what we might do in future. You have all made the good point that we are juggling too many chainsaws and flaming arrows and tigers. Let's land a few of those before we worry about python removal/dts/whatever :-)
ron
Carl-Daniel Hailfinger wrote:
On 06.10.2009 22:40, Patrick Georgi wrote:
sconfig is newconfig minus the Makefile generation code. what remains is the part of newconfig that parses the device tree and creates the C representation of it, etc.
Eventually, I'll rewrite it in C, to remove the python dependency, but for now, it's quite similar to newconfig - just with lots of stuff removed.
Do we really want to throw away the design that went into dts by rewriting the v2 sconfig?
DTS has no considerable advantages over the current sconfig, but it was much more complicated. I think we should stick to that format until we have something worthwhile.
I agree an sconfig version in C would make sense because right now on my build host almost 50% of the build time goes into the configuration step.
When we're out of Kconfig + CBFS + Normal/Fallback firefighting mode, we should reconsider our options here. Until then, every minute of work is best spent on bringing over the remaining 50% of the mainboards to Kconfig.
Stefan
-
Carl-Daniel Hailfinger -
Myles Watson -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer