-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of svn@coreboot.org Sent: Wednesday, April 22, 2009 4:43 PM To: coreboot@coreboot.org Subject: [coreboot] [v2] r4188 - trunk/coreboot-v2/targets/hp/dl145_g3
Author: stepan Date: 2009-04-23 00:43:02 +0200 (Thu, 23 Apr 2009) New Revision: 4188
Added: trunk/coreboot-v2/targets/hp/dl145_g3/Config-abuild.lb Log: fix compilation of hp dl145
Signed-off-by: Stefan Reinauer stepan@coresystems.de Acked-by: Stefan Reinauer stepan@coresystems.de
Thanks for fixing it. I didn't think I'd need to add Config-abuild.lb for this board. Tyan s2892 doesn't have one.
Is there a rule?
Thanks, Myles
On 23.04.2009 0:47 Uhr, Myles Watson wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of svn@coreboot.org Sent: Wednesday, April 22, 2009 4:43 PM To: coreboot@coreboot.org Subject: [coreboot] [v2] r4188 - trunk/coreboot-v2/targets/hp/dl145_g3
Author: stepan Date: 2009-04-23 00:43:02 +0200 (Thu, 23 Apr 2009) New Revision: 4188
Added: trunk/coreboot-v2/targets/hp/dl145_g3/Config-abuild.lb Log: fix compilation of hp dl145
Signed-off-by: Stefan Reinauer stepan@coresystems.de Acked-by: Stefan Reinauer stepan@coresystems.de
Thanks for fixing it. I didn't think I'd need to add Config-abuild.lb for this board. Tyan s2892 doesn't have one.
Is there a rule?
If there is none, abuild will create one with a ROM_IMAGE_SIZE of 0x17000 (92kb).. Unfortunately abuild can not figure out how much space is needed to fit the image before the linker fails. This is one thing where further CBFS integration in v2 can bring us a big gain... we could drop 90% of the Config-abuild.lb files (plus the ugly image calculation that Carl-Daniel factored out so nicely)
Stefan
On Wed, Apr 22, 2009 at 5:32 PM, Stefan Reinauer stepan@coresystems.de wrote:
On 23.04.2009 0:47 Uhr, Myles Watson wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of svn@coreboot.org Sent: Wednesday, April 22, 2009 4:43 PM To: coreboot@coreboot.org Subject: [coreboot] [v2] r4188 - trunk/coreboot-v2/targets/hp/dl145_g3
Author: stepan Date: 2009-04-23 00:43:02 +0200 (Thu, 23 Apr 2009) New Revision: 4188
Added: trunk/coreboot-v2/targets/hp/dl145_g3/Config-abuild.lb Log: fix compilation of hp dl145
Signed-off-by: Stefan Reinauer stepan@coresystems.de Acked-by: Stefan Reinauer stepan@coresystems.de
Thanks for fixing it. I didn't think I'd need to add Config-abuild.lb for this board. Tyan s2892 doesn't have one.
Is there a rule?
If there is none, abuild will create one with a ROM_IMAGE_SIZE of 0x17000 (92kb).. Unfortunately abuild can not figure out how much space is needed to fit the image before the linker fails.
OK. It looks like we could remove all but s2892_fam10 by increasing that size to 0x20000 (128K.)
For some reason s2892_fam10 needs 0x34000 (208K.)
Signed-off-by: Myles Watson mylesgw@gmail.com
This patch would be followed by lots of svn rm targets/*/Config-abuild.lb.
The only downside I see is that Patrick uses Config-abuild.lb files instead of the Config.lb files:
On Mon, Apr 27, 2009 at 12:35 PM, Patrick Georgi patrick@georgi-clan.de wrote:
Am Montag 27 April 2009 20:12:45 schrieb Myles Watson:
I don't understand why this board needs a Config-abuild.lb. It seems like if we want one it should build normal and fallback images like Config.lb does.
I can't tell you why it is already there. But, as I use abuild for my local work, I rely on those files and edit those when necessary.
I don't like having both files if we can get away from it. Maybe abuild just use the Config.lb unless there's a Config-abuild.lb.
This is one thing where further CBFS integration in v2 can bring us a big gain... we could drop 90% of the Config-abuild.lb files (plus the ugly image calculation that Carl-Daniel factored out so nicely)
That'll be great.
Thanks, Myles
On 27.04.2009 22:50 Uhr, Myles Watson wrote:
OK. It looks like we could remove all but s2892_fam10 by increasing that size to 0x20000 (128K.)
Which will break those images that only have a 256K flash chip. Whatever we do, it needs to happen careful here.
This patch would be followed by lots of svn rm targets/*/Config-abuild.lb.
The only downside I see is that Patrick uses Config-abuild.lb files instead of the Config.lb files
So do I. abuild is very convenient for building production images quickly. We have another set of scripts which builds images for our supported targets and remotely flashes them to the targets to improve development cycles.
Stefan
On 27.04.2009 22:50 Uhr, Myles Watson wrote:
I don't like having both files if we can get away from it. Maybe abuild just use the Config.lb unless there's a Config-abuild.lb.
Abuild creates a default Config-abuild.lb file unless there is a Config-abuild.lb file already.
The Config.lb files are mostly crap and unusable for work in different development scenarios and have no real features that abuild wouldn't provide without them
So I suggest, we drop all Config.lb files instead, and only keep config-abuild instead.
Stefan
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Monday, April 27, 2009 3:14 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] [v2] r4188 - trunk/coreboot-v2/targets/hp/dl145_g3
On 27.04.2009 22:50 Uhr, Myles Watson wrote:
I don't like having both files if we can get away from it. Maybe abuild just use the Config.lb unless there's a Config-abuild.lb.
Abuild creates a default Config-abuild.lb file unless there is a Config-abuild.lb file already.
The Config.lb files are mostly crap and unusable for work in different development scenarios and have no real features that abuild wouldn't provide without them
So I suggest, we drop all Config.lb files instead, and only keep config-abuild instead.
That'd be fine with me! I think having the redundancy makes it too confusing for beginners. I think it's much easier to tell them to replace __COMPRESSION__ and __LOGLEVEL__ appropriately. Then buildrom (the payload builder) could do that too and we wouldn't have to have Config-lab.lb anymore either.
Once we drop all the others, though, why not just call it Config.lb?
Thanks, Myles
Myles Watson wrote:
Once we drop all the others, though, why not just call it Config.lb?
Yes. That is important. Stick with simple names. Config.cb please.
//Peter
On Mon, Apr 27, 2009 at 2:40 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
Once we drop all the others, though, why not just call it Config.lb?
Yes. That is important. Stick with simple names. Config.cb pleas
OK.
So what we'll have is Config.lb (let's not change one until we change them ALL) that is configured for abuild.
What are you going to tell users again? I'm trying to get this.
ron
On Mon, Apr 27, 2009 at 3:49 PM, ron minnich rminnich@gmail.com wrote:
On Mon, Apr 27, 2009 at 2:40 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
Once we drop all the others, though, why not just call it Config.lb?
Yes. That is important. Stick with simple names. Config.cb pleas
OK.
So what we'll have is Config.lb (let's not change one until we change them ALL) that is configured for abuild.
What are you going to tell users again? I'm trying to get this.
Tell them to use abuild.
If they need something special, tell them how to insert options for __COMPRESSION__ etc.
Right now Config.lb files are mostly commented out lines referring to someone else's test payloads. I think we should hide most of the options in src/mainboard/*/Config.lb, and only have the ones users should need to care about in target/*/Config.lb.
Thanks, Myles
On Mon, Apr 27, 2009 at 2:54 PM, Myles Watson mylesgw@gmail.com wrote:
Right now Config.lb files are mostly commented out lines referring to someone else's test payloads. I think we should hide most of the options in src/mainboard/*/Config.lb, and only have the ones users should need to care about in target/*/Config.lb.
well, of course. That's how it is intended to work. The issue is the usage, but the basic design is what you say.
But I don't see the point of only having one Config.lb in targets.
I want to make sure you are not proposing that they make a habit of changing the Config.lb in targets. That way lies madness.
ron
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Monday, April 27, 2009 3:57 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] [v2] r4188 - trunk/coreboot-v2/targets/hp/dl145_g3
On Mon, Apr 27, 2009 at 2:54 PM, Myles Watson mylesgw@gmail.com wrote:
Right now Config.lb files are mostly commented out lines referring to someone else's test payloads. I think we should hide most of the options in src/mainboard/*/Config.lb, and only have the ones users should need to care about in target/*/Config.lb.
well, of course. That's how it is intended to work. The issue is the usage, but the basic design is what you say.
Understood. I'd like to get the usage in line.
But I don't see the point of only having one Config.lb in targets.
Why should there be multiple?
I want to make sure you are not proposing that they make a habit of changing the Config.lb in targets. That way lies madness.
Who do you mean? I think it should be a habit for users to customize one Config.lb. Having many files makes it hard to keep them updated. An example of that is the Kontron abuild that only builds fallback. The Config.lb builds normal and fallback, so now abuild doesn't check the "default" config file's build.
Thanks, Myles
On Mon, Apr 27, 2009 at 3:03 PM, Myles Watson mylesgw@gmail.com wrote:
Why should there be multiple?
I guess because we intended there to be :-)
Sometimes people want fallback, sometimes not, on the same board. Other things change. The layout for linux as bootloader is sometimes wildly different than other types of bootloaders. By setting up multiple Config.lb files we were trying to show the users that there was flexibility. If you only have one there, they might think there can only be one.
Who do you mean? I think it should be a habit for users to customize one Config.lb. Having many files makes it hard to keep them updated. An example of that is the Kontron abuild that only builds fallback. The Config.lb builds normal and fallback, so now abuild doesn't check the "default" config file's build.
If the user customizes the Config.lb in the targets tree, their customizations get wiped on the next svn up. Our intent was to make it easy to copy and modify it. That's why bulidtarget takes either the directory name (and assumes Config.lb) or a file name.
That said, one could argue that our plans for the use of Config.lb have not worked out; I'm not going to object too much to what you all come up with.
Thanks!
ron
On Mon, Apr 27, 2009 at 6:01 PM, ron minnich rminnich@gmail.com wrote:
On Mon, Apr 27, 2009 at 3:03 PM, Myles Watson mylesgw@gmail.com wrote:
Why should there be multiple?
I guess because we intended there to be :-)
If there's not a problem, I won't push it.
Sometimes people want fallback, sometimes not, on the same board. Other things change. The layout for linux as bootloader is sometimes wildly different than other types of bootloaders. By setting up multiple Config.lb files we were trying to show the users that there was flexibility. If you only have one there, they might think there can only be one.
True.
Who do you mean? I think it should be a habit for users to customize one Config.lb. Having many files makes it hard to keep them updated. An example of that is the Kontron abuild that only builds fallback. The Config.lb builds normal and fallback, so now abuild doesn't check the "default" config file's build.
If the user customizes the Config.lb in the targets tree, their customizations get wiped on the next svn up. Our intent was to make it easy to copy and modify it. That's why bulidtarget takes either the directory name (and assumes Config.lb) or a file name.
That said, one could argue that our plans for the use of Config.lb have not worked out; I'm not going to object too much to what you all come up with.
It's not the top priority. I was just surprised to hear that Config-abuild.lb was the preferred config for anybody. I thought they were only there to work around brokenness.
Thanks, Myles
On Mon, Apr 27, 2009 at 7:22 PM, Myles Watson mylesgw@gmail.com wrote:
It's not the top priority. I was just surprised to hear that Config-abuild.lb was the preferred config for anybody. I thought they were only there to work around brokenness.
yeah, it surprised me too.
ron
-
Myles Watson -
Peter Stuge -
ron minnich -
Stefan Reinauer