On Saturday 21 March 2009 04:32:30 Blue Swirl wrote:
I accidentally (by using a wrong variable in a more complex patch) found out a workaround for the bug, now -nographic boot works. But still the other nodes have the same problem as before and the workaround removes the "reg" node which is present on real tree.
Now the escc node doesn't have the address appended: 1bfac /pci@80000000/mac-io@4/nvram@0 (nvram) 1c1c0 /pci@80000000/mac-io@4/escc (escc) 1c2ac /pci@80000000/mac-io@4/escc/ch-a@13020 (serial) 1c52c /pci@80000000/mac-io@4/escc/ch-b@13000 (serial)
Maybe nodes under /pci/mac-io should use custom encode-unit/decode-unit methods instead of PCI ones?
My workaround at this end is to just revert openbios-ppc to the earlier version.
I still think that bisecting to find the specific commit that broke it would be informative, but your repository's move to /trunk at commit 470 essentially wiped all repository history before that. Your development page doesn't say how to download the old versions, just the ones under "trunk":
http://www.openfirmware.info/OpenBIOS
Nor does your repository viewer view anything before 470 from the little pull- down menu: http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=4... http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=4...
I guessed how to get the repository viewer to show me the earlier versions:
http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
But this doesn't work:
$ svn co -r 469 svn://openbios.org/openbios/openbios-devel svn: File not found: revision 480, path '/openbios-devel'
Then again, I can always bisect by downloading tarballs from your repository viewer... Eh, why not.
For easy cut and pasting, my build reproduction sequence is:
chmod +x config/scripts/switch-arch config/scripts/switch-arch cross-ppc PATH=~/firmware/firmware/build/cross-compiler-powerpc/bin:$PATH \ make TARGET=powerpc- sudo cp obj-ppc/openbios-qemu.elf /usr/local/share/qemu/openbios-ppc
469 exhibits the bug, so it's before that. I believe 450 is the "known good" version, so let's try 460... Bug. 455... Bug. 452... Bug. 451... Works.
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
Anything in there look broken to you?
Rob
P.S. Please at least put up a link to this on your development page:
http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
Right now earlier versions of your repository are completely inaccessible to newbies like me...
On 3/21/09, Rob Landley rob@landley.net wrote:
On Saturday 21 March 2009 04:32:30 Blue Swirl wrote:
I accidentally (by using a wrong variable in a more complex patch) found out a workaround for the bug, now -nographic boot works. But still the other nodes have the same problem as before and the workaround removes the "reg" node which is present on real tree.
Now the escc node doesn't have the address appended: 1bfac /pci@80000000/mac-io@4/nvram@0 (nvram) 1c1c0 /pci@80000000/mac-io@4/escc (escc) 1c2ac /pci@80000000/mac-io@4/escc/ch-a@13020 (serial) 1c52c /pci@80000000/mac-io@4/escc/ch-b@13000 (serial)
Maybe nodes under /pci/mac-io should use custom encode-unit/decode-unit methods instead of PCI ones?
My workaround at this end is to just revert openbios-ppc to the earlier version.
I still think that bisecting to find the specific commit that broke it would be informative, but your repository's move to /trunk at commit 470 essentially wiped all repository history before that. Your development page doesn't say how to download the old versions, just the ones under "trunk":
Good point, I'll add some notes.
http://www.openfirmware.info/OpenBIOS
Nor does your repository viewer view anything before 470 from the little pull- down menu: http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=4... http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=4...
I guessed how to get the repository viewer to show me the earlier versions:
http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
But this doesn't work:
$ svn co -r 469 svn://openbios.org/openbios/openbios-devel svn: File not found: revision 480, path '/openbios-devel'
'svn switch' may help: http://www.openfirmware.info/pipermail/openbios/2009-March/003594.html
I'll add something about this too.
Then again, I can always bisect by downloading tarballs from your repository viewer... Eh, why not.
For easy cut and pasting, my build reproduction sequence is:
chmod +x config/scripts/switch-arch config/scripts/switch-arch cross-ppc PATH=~/firmware/firmware/build/cross-compiler-powerpc/bin:$PATH \ make TARGET=powerpc- sudo cp obj-ppc/openbios-qemu.elf /usr/local/share/qemu/openbios-ppc
469 exhibits the bug, so it's before that. I believe 450 is the "known good" version, so let's try 460... Bug. 455... Bug. 452... Bug. 451... Works.
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
Anything in there look broken to you?
No. This basically enabled automatic switch of OpenBIOS input and output to serial console when using the -nographic flag which was already supported the same way by Sparc32 and Sparc64.
The bug is somewhere in the device path processing, probably in the PPC specific higher level device like mac-io, that's why the same ESCC serial console works on Sparc32.
Rob
P.S. Please at least put up a link to this on your development page:
http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
Right now earlier versions of your repository are completely inaccessible to newbies like me...
On 3/21/09, Rob Landley rob@landley.net wrote:
On Saturday 21 March 2009 04:32:30 Blue Swirl wrote:
I accidentally (by using a wrong variable in a more complex patch) found out a workaround for the bug, now -nographic boot works. But still the other nodes have the same problem as before and the workaround removes the "reg" node which is present on real tree.
Now the escc node doesn't have the address appended: 1bfac /pci@80000000/mac-io@4/nvram@0 (nvram) 1c1c0 /pci@80000000/mac-io@4/escc (escc) 1c2ac /pci@80000000/mac-io@4/escc/ch-a@13020 (serial) 1c52c /pci@80000000/mac-io@4/escc/ch-b@13000 (serial)
Maybe nodes under /pci/mac-io should use custom encode-unit/decode-unit methods instead of PCI ones?
My workaround at this end is to just revert openbios-ppc to the earlier version.
I still think that bisecting to find the specific commit that broke it would be informative, but your repository's move to /trunk at commit 470 essentially wiped all repository history before that. Your development page doesn't say how to download the old versions, just the ones under "trunk":
http://www.openfirmware.info/OpenBIOS
Nor does your repository viewer view anything before 470 from the little pull- down menu: http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=4... http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=4...
I guessed how to get the repository viewer to show me the earlier versions:
http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
But this doesn't work:
$ svn co -r 469 svn://openbios.org/openbios/openbios-devel svn: File not found: revision 480, path '/openbios-devel'
Then again, I can always bisect by downloading tarballs from your repository viewer... Eh, why not.
For easy cut and pasting, my build reproduction sequence is:
chmod +x config/scripts/switch-arch config/scripts/switch-arch cross-ppc PATH=~/firmware/firmware/build/cross-compiler-powerpc/bin:$PATH \ make TARGET=powerpc- sudo cp obj-ppc/openbios-qemu.elf /usr/local/share/qemu/openbios-ppc
469 exhibits the bug, so it's before that. I believe 450 is the "known good" version, so let's try 460... Bug. 455... Bug. 452... Bug. 451... Works.
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
Anything in there look broken to you?
Fixed in r481. I removed the PCI encode-unit/decode-unit methods for non-bus devices, now get-instance-path works.
On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
Anything in there look broken to you?
Fixed in r481. I removed the PCI encode-unit/decode-unit methods for non-bus devices, now get-instance-path works.
Cool!
Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
Rob
(By the way: qemu is shipping a gpled bios binary without accompanying source code. I realize that the maintainer of said binary checked it in, but what exactly is the rationale here?)
Rob Landley wrote:
On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
Anything in there look broken to you?
Fixed in r481. I removed the PCI encode-unit/decode-unit methods for non-bus devices, now get-instance-path works.
Cool!
Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
Rob
(By the way: qemu is shipping a gpled bios binary without accompanying source code. I realize that the maintainer of said binary checked it in, but what exactly is the rationale here?)
IANAL, but from the FSF GPL FAQ, you just have to make sure the source code is available. Since Blue Swirl is an Open BIOS maintainer, I think we can say with confidence that the openbios code will always be available. If that situation changed for some reason, we'd have to mirror their code.
Regards,
Anthony Liguori
Anthony Liguori wrote:
IANAL, but from the FSF GPL FAQ, you just have to make sure the source code is available. Since Blue Swirl is an Open BIOS maintainer, I think we can say with confidence that the openbios code will always be available. If that situation changed for some reason, we'd have to mirror their code.
Specifically:
http://www.fsf.org/licensing/licenses/gpl-faq.html#SourceAndBinaryOnDifferen...
Not too long ago, I went through and attempted to make sure the instructions in pc-bios/README were very clear how to obtain the sources for the binaries we ship. Patches are always welcome if people think they need clarification.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
In message: 49C9994F.2040803@codemonkey.ws Anthony Liguori anthony@codemonkey.ws writes: : Rob Landley wrote: : > On Sunday 22 March 2009 11:54:22 Blue Swirl wrote: : > : >>> So the bug was introduced (or at least triggered) by revision 452: : >>> : >>> http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel : >>> : >>> Anything in there look broken to you? : >>> : >> Fixed in r481. I removed the PCI encode-unit/decode-unit methods for : >> non-bus devices, now get-instance-path works. : >> : > : > : > Cool! : > : > Is there a procedure to ask how to queue this up for qemu 0.10.2? :) : > : > Rob : > : > (By the way: qemu is shipping a gpled bios binary without accompanying source : > code. I realize that the maintainer of said binary checked it in, but what : > exactly is the rationale here?) : > : : IANAL, but from the FSF GPL FAQ, you just have to make sure the source : code is available. Since Blue Swirl is an Open BIOS maintainer, I think : we can say with confidence that the openbios code will always be : available. If that situation changed for some reason, we'd have to : mirror their code.
This is covered by 'third party' agreements. Blue Swirl has agreed to provide the source for the qemu project, as signified by his committing the binaries to the qemu repo and since he's a cool guy. If he decides to stop, then Anthony is right.
Warner
On 3/25/09, Rob Landley rob@landley.net wrote:
On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
Anything in there look broken to you?
Fixed in r481. I removed the PCI encode-unit/decode-unit methods for non-bus devices, now get-instance-path works.
Cool!
Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
Technically the best solution would be to introduce a stable tree also to OpenBIOS like Qemu. But OpenBIOS development is not as fast paced as Qemu, so I'm not sure if it's worth the effort.
I can commit the latest version to Qemu SVN and if there are no issues, update the version in stable before release.
Rob
(By the way: qemu is shipping a gpled bios binary without accompanying source code. I realize that the maintainer of said binary checked it in, but what exactly is the rationale here?)
I see it as a service for both OpenBIOS and Qemu development communities, also the casual users don't have to install cross compilers just to try the Sparc/PPC emulators. The binaries are compiled from unmodified sources as indicated in the README.
If someone finds problems with this, it's easy to put the binaries to OpenBIOS site and remove them from Qemu SVN. That would make bisecting a bit harder. Or Qemu could just include the OpenBIOS tree, it's only 12M.
Blue Swirl wrote:
Technically the best solution would be to introduce a stable tree also to OpenBIOS like Qemu. But OpenBIOS development is not as fast paced as Qemu, so I'm not sure if it's worth the effort.
I can commit the latest version to Qemu SVN and if there are no issues, update the version in stable before release.
It's your call.
For bochs, we have a patch queue built in pc-bios. For stable, I'd add individual patches that fix issues if they came up. I generally wouldn't update to a newer bochs SVN though b/c bochs has a bad habit of breaking things upstream.
So two options would be to include a new OpenBIOS version or just apply the patches that you think are important.
Regards,
Anthony Liguori
On Friday 27 March 2009 13:59:36 Blue Swirl wrote:
On 3/25/09, Rob Landley rob@landley.net wrote:
On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-dev el
Anything in there look broken to you?
Fixed in r481. I removed the PCI encode-unit/decode-unit methods for non-bus devices, now get-instance-path works.
Cool!
Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
Technically the best solution would be to introduce a stable tree also to OpenBIOS like Qemu. But OpenBIOS development is not as fast paced as Qemu, so I'm not sure if it's worth the effort.
I can commit the latest version to Qemu SVN and if there are no issues, update the version in stable before release.
Rob
(By the way: qemu is shipping a gpled bios binary without accompanying source code. I realize that the maintainer of said binary checked it in, but what exactly is the rationale here?)
I see it as a service for both OpenBIOS and Qemu development communities, also the casual users don't have to install cross compilers just to try the Sparc/PPC emulators. The binaries are compiled from unmodified sources as indicated in the README.
If someone finds problems with this, it's easy to put the binaries to OpenBIOS site and remove them from Qemu SVN. That would make bisecting a bit harder. Or Qemu could just include the OpenBIOS tree, it's only 12M.
I'm not complaining, I just tend to pay attention to license issues.
If qemu is never going to try to enforce its license, it probably doesn't matter. If it _does_ and the other side can point to you guys not honoring your own license terms, you may have a hard time getting them to.
Most likely you guys fall under GPLv2 section 3c anyway. Commercial redistributors of qemu might have to include the openbios source in addition to the qemu source (and maybe the bochs bios source, who knows?) But the qemu project itself probably doesn't.
Rob
-
Anthony Liguori -
Blue Swirl -
M. Warner Losh -
Rob Landley