I expect r4110 to break things because the util was renamed. This should lead to working builds again.
src/arch/i386/Config.lb | 4 src/boot/Config.lb | 2 src/boot/hardwaremain.c | 8 src/boot/selfboot.c | 24 +- src/config/Options.lb | 4 src/devices/pci_rom.c | 6 src/include/cbfs.h | 54 ++--- src/lib/Config.lb | 4 src/lib/cbfs.c | 104 +++++----- src/mainboard/a-trend/atc-6220/Options.lb | 6 src/mainboard/a-trend/atc-6240/Options.lb | 6 src/mainboard/abit/be6-ii_v2_0/Options.lb | 6 src/mainboard/advantech/pcm-5820/Options.lb | 6 src/mainboard/amd/db800/Options.lb | 6 src/mainboard/amd/dbm690t/Options.lb | 6 src/mainboard/amd/norwich/Options.lb | 6 src/mainboard/amd/pistachio/Options.lb | 6 src/mainboard/amd/rumba/Options.lb | 6 src/mainboard/amd/serengeti_cheetah/Options.lb | 6 src/mainboard/amd/serengeti_cheetah_fam10/Options.lb | 6 src/mainboard/arima/hdama/Options.lb | 6 src/mainboard/artecgroup/dbe61/Options.lb | 6 src/mainboard/asi/mb_5blgp/Options.lb | 6 src/mainboard/asi/mb_5blmp/Options.lb | 6 src/mainboard/asus/a8n_e/Options.lb | 6 src/mainboard/asus/a8v-e_se/Options.lb | 6 src/mainboard/asus/m2v-mx_se/Options.lb | 6 src/mainboard/asus/mew-am/Options.lb | 6 src/mainboard/asus/mew-vm/Options.lb | 6 src/mainboard/asus/p2b-ds/Options.lb | 6 src/mainboard/asus/p2b-f/Options.lb | 6 src/mainboard/asus/p2b/Options.lb | 6 src/mainboard/asus/p3b-f/Options.lb | 6 src/mainboard/axus/tc320/Options.lb | 6 src/mainboard/azza/pt-6ibd/Options.lb | 6 src/mainboard/bcom/winnet100/Options.lb | 6 src/mainboard/bcom/winnetp680/Options.lb | 6 src/mainboard/biostar/m6tba/Options.lb | 6 src/mainboard/broadcom/blast/Options.lb | 6 src/mainboard/compaq/deskpro_en_sff_p600/Options.lb | 6 src/mainboard/dell/s1850/Options.lb | 6 src/mainboard/digitallogic/adl855pc/Options.lb | 6 src/mainboard/digitallogic/msm586seg/Options.lb | 6 src/mainboard/digitallogic/msm800sev/Options.lb | 6 src/mainboard/eaglelion/5bcm/Options.lb | 6 src/mainboard/embeddedplanet/ep405pc/Options.lb | 6 src/mainboard/emulation/qemu-x86/Options.lb | 4 src/mainboard/gigabyte/ga-6bxc/Options.lb | 6 src/mainboard/gigabyte/ga_2761gxdk/Options.lb | 6 src/mainboard/gigabyte/m57sli/Options.lb | 6 src/mainboard/ibm/e325/Options.lb | 6 src/mainboard/ibm/e326/Options.lb | 6 src/mainboard/iei/juki-511p/Options.lb | 6 src/mainboard/iei/nova4899r/Options.lb | 6 src/mainboard/iei/pcisa-lx-800-r10/Options.lb | 6 src/mainboard/intel/jarrell/Options.lb | 6 src/mainboard/intel/mtarvon/Options.lb | 6 src/mainboard/intel/truxton/Options.lb | 6 src/mainboard/intel/xe7501devkit/Options.lb | 6 src/mainboard/iwill/dk8_htx/Options.lb | 6 src/mainboard/iwill/dk8s2/Options.lb | 6 src/mainboard/iwill/dk8x/Options.lb | 6 src/mainboard/jetway/j7f24/Options.lb | 6 src/mainboard/kontron/986lcd-m/Options.lb | 6 src/mainboard/lippert/frontrunner/Options.lb | 6 src/mainboard/lippert/roadrunner-lx/Options.lb | 6 src/mainboard/lippert/spacerunner-lx/Options.lb | 6 src/mainboard/motorola/sandpoint/Options.lb | 6 src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb | 6 src/mainboard/msi/ms6119/Options.lb | 6 src/mainboard/msi/ms6147/Options.lb | 6 src/mainboard/msi/ms6178/Options.lb | 6 src/mainboard/msi/ms7135/Options.lb | 6 src/mainboard/msi/ms7260/Options.lb | 6 src/mainboard/msi/ms9185/Options.lb | 6 src/mainboard/msi/ms9282/Options.lb | 6 src/mainboard/nec/powermate2000/Options.lb | 6 src/mainboard/newisys/khepri/Options.lb | 6 src/mainboard/nvidia/l1_2pvv/Options.lb | 6 src/mainboard/olpc/btest/Options.lb | 6 src/mainboard/olpc/rev_a/Options.lb | 6 src/mainboard/pcengines/alix1c/Options.lb | 6 src/mainboard/rca/rm4100/Options.lb | 6 src/mainboard/sunw/ultra40/Options.lb | 6 src/mainboard/supermicro/h8dme/Options.lb | 6 src/mainboard/supermicro/h8dmr/Options.lb | 6 src/mainboard/supermicro/x6dai_g/Options.lb | 6 src/mainboard/supermicro/x6dhe_g/Options.lb | 6 src/mainboard/supermicro/x6dhe_g2/Options.lb | 6 src/mainboard/supermicro/x6dhr_ig/Options.lb | 6 src/mainboard/supermicro/x6dhr_ig2/Options.lb | 6 src/mainboard/technexion/tim8690/Options.lb | 2 src/mainboard/technologic/ts5300/Options.lb | 6 src/mainboard/televideo/tc7020/Options.lb | 6 src/mainboard/thomson/ip1000/Options.lb | 6 src/mainboard/totalimpact/briq/Options.lb | 6 src/mainboard/tyan/s1846/Options.lb | 6 src/mainboard/tyan/s2735/Options.lb | 6 src/mainboard/tyan/s2850/Options.lb | 6 src/mainboard/tyan/s2875/Options.lb | 6 src/mainboard/tyan/s2880/Options.lb | 6 src/mainboard/tyan/s2881/Options.lb | 6 src/mainboard/tyan/s2882/Options.lb | 6 src/mainboard/tyan/s2885/Options.lb | 6 src/mainboard/tyan/s2891/Options.lb | 6 src/mainboard/tyan/s2892/Options.lb | 6 src/mainboard/tyan/s2895/Options.lb | 6 src/mainboard/tyan/s2912/Options.lb | 6 src/mainboard/tyan/s2912_fam10/Options.lb | 6 src/mainboard/tyan/s4880/Options.lb | 6 src/mainboard/tyan/s4882/Options.lb | 6 src/mainboard/via/epia-cn/Options.lb | 8 src/mainboard/via/epia-m/Options.lb | 6 src/mainboard/via/epia/Options.lb | 6 src/mainboard/via/pc2500e/Options.lb | 6 util/newconfig/config.g | 20 - 116 files changed, 431 insertions(+), 431 deletions(-)
//Peter
did you test with abuild :-)
ron
ron minnich wrote:
did you test with abuild :-)
No sir. I have neither procedure nor CPU power for abuild. :\
By the time I would have managed to run abuild once, the server would probably have run abuild thrice, including the two potential rounds of fixes.
There is little doubt about the patch, so any errors will get fixed quickly in case of mistakes. By me if I can.
Because I have little knowledge of the cbfs usage, and zero experience, I suggested someone else might be better suited to create these patches. Noone did, and sed is easy enough.
//Peter
Peter Stuge wrote:
ron minnich wrote:
did you test with abuild :-)
No sir. I have neither procedure nor CPU power for abuild. :\
By the time I would have managed to run abuild once, the server would probably have run abuild thrice, including the two potential rounds of fixes.
Something I've always wondered about is why is abuild only in response to a svn commit? I think it would be quite handy if you had something like abuild-v[23]@coreboot.org and any patch you send as an attachment to it pulls a copy of the tree applies the patch and then runs abuild on the tree and then emails back the results.
Richard Smith wrote:
abuild-v[23]@coreboot.org
Fantastic idea! Just make it abuild@coreboot.org, right now abuild only knows v2 and if that changes I think the wrapper could determine which tree to patch.
//Peter
On 14.04.2009 03:29, Richard Smith wrote:
Peter Stuge wrote:
ron minnich wrote:
did you test with abuild :-)
No sir. I have neither procedure nor CPU power for abuild. :\
By the time I would have managed to run abuild once, the server would probably have run abuild thrice, including the two potential rounds of fixes.
Something I've always wondered about is why is abuild only in response to a svn commit? I think it would be quite handy if you had something like abuild-v[23]@coreboot.org and any patch you send as an attachment to it pulls a copy of the tree applies the patch and then runs abuild on the tree and then emails back the results.
Security reasons? What's stopping anyone from mailing a patch which starts a shell on the abuild server which listens on port 12345 or similar fun?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Security reasons? What's stopping anyone from mailing a patch which starts a shell on the abuild server which listens on port 12345 or similar fun?
Maybe use a PGP signature?
That presents new problems, but the basic idea is still fantastic - making testing even easier.
//Peter
On Tue, Apr 14, 2009 at 4:03 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 14.04.2009 03:29, Richard Smith wrote:
Peter Stuge wrote:
ron minnich wrote:
did you test with abuild :-)
No sir. I have neither procedure nor CPU power for abuild. :\
By the time I would have managed to run abuild once, the server would probably have run abuild thrice, including the two potential rounds of fixes.
Something I've always wondered about is why is abuild only in response to a svn commit? I think it would be quite handy if you had something like abuild-v[23]@coreboot.org and any patch you send as an attachment to it pulls a copy of the tree applies the patch and then runs abuild on the tree and then emails back the results.
Security reasons? What's stopping anyone from mailing a patch which starts a shell on the abuild server which listens on port 12345 or similar fun?
I'm not understanding how that could happen, unless they sent a patch against abuild itself, and that could be easily rectified by running patch as another user, and having abuild owned by e.g. root and marked as rx for others. That would kill the ability to have patches against abuild tested by abuild, but those are so rare I don't think it'd be a big issue. I'm considering setting up something like this, my Q6600 with 6GB of ram runs idle most of the day, I'm just dreading setting up a mail system on it to send out the results.
-Corey
On 14.04.2009 3:06 Uhr, Peter Stuge wrote:
ron minnich wrote:
did you test with abuild :-)
No sir. I have neither procedure nor CPU power for abuild. :\
Please make yourself familiar with the coreboot procedure, then: http://www.coreboot.org/Development_Guidelines
It often helps to run abuild on a few targets only.
(And, as you saw from my recent patches, abuild not always catches all breakage the build system detects. It is, nonetheless, useful)
By the time I would have managed to run abuild once, the server would probably have run abuild thrice, including the two potential rounds of fixes.
There is little doubt about the patch, so any errors will get fixed quickly in case of mistakes. By me if I can.
All went fine.
Because I have little knowledge of the cbfs usage, and zero experience, I suggested someone else might be better suited to create these patches. Noone did, and sed is easy enough.
Probably noone else cared or wanted the rename.
Stefan
Stefan Reinauer wrote:
did you test with abuild :-)
No sir. I have neither procedure nor CPU power for abuild. :\
Please make yourself familiar with the coreboot procedure, then: http://www.coreboot.org/Development_Guidelines
It says "please run before commit" but not much more. An example would be nice - how do you guys run abuild? I can add it.
It often helps to run abuild on a few targets only.
But then it is testing less, that's not as good as a full run right? (Agree still better than no testing!)
(Btw I did build a target, but I was not sure what would be the best candidate. As I understood Ron no board actually uses cbfs right now.)
(And, as you saw from my recent patches, abuild not always catches all breakage the build system detects. It is, nonetheless, useful)
I agree! I would however like the build system to be so consistent that the result is always the same in and out of central abuild. I have no idea what is causing the few problems we've seen so far though. :\
There is little doubt about the patch, so any errors will get fixed quickly in case of mistakes. By me if I can.
All went fine.
Yep!
Because I have little knowledge of the cbfs usage, and zero experience, I suggested someone else might be better suited to create these patches. Noone did, and sed is easy enough.
Probably noone else cared or wanted the rename.
The point is to avoid confusion. Next time someone is describing benefits of coreboot we have a name of our own for a technology which is our own. All ways we can make coreboot easier to grok are good, and I think unique terms for unique things really helps (it does for me) when climbing the learning curve.
//Peter
OK I took the patch and am trying out abuild now.
ron
Acked-by: Ronald G. Minnich rminnich@gmail.com
abuild tested. There are one or two fails but none related to this patch.
ron minnich wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
abuild tested. There are one or two fails but none related to this patch.
Wow - thanks! r4113
-
Carl-Daniel Hailfinger -
Corey Osgood -
Peter Stuge -
Richard Smith -
ron minnich -
Stefan Reinauer