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
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":
Nor does your repository viewer view anything before 470 from the little pull-
I guessed how to get the repository viewer to show me the earlier versions:
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
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:
Anything in there look broken to you?
P.S. Please at least put up a link to this on your development page:
Right now earlier versions of your repository are completely inaccessible to
newbies like me...
On 3/18/09, Rob Landley <rob(a)landley.net> wrote:
> On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
> > On 18.03.2009, at 00:57, Rob Landley wrote:
> > > Up through svn 6657, I could boot a powerpc kernel with -kernel.
> > > That commit
> > > changed it so now it says:
> > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
> > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
> > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
> > >
> > > And dies.
> > >
> > > You can grab a test kernel from http://landley.net/zImage-powerpc
> > > and try
> > > booting it (out of the qemu source directory, this is assuming
> > > you've built it
> > > but haven't installed it yet) via:
> > >
> > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
> > > -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
> > >
> > > With svn 6657, it works. (You get kernel boot messages up until it
> > > panics and
> > > dies because it can't find the root filesystem). With 6658 it dies
> > > immediately with the above error message.
> > >
> > > Unfortunately, this means that the 0.10.0 release doesn't work for
> > > powerpc for
> > > me, but svn a couple days _before_ the release did.
> > That specific commit shouldn't have changed anything with respect to
> > ppc32 emulation. The one where your command broken is the openBIOS
> > update.
> The commit I pointed to is the openbios update, yes.
> > Please try again without -nographic.
> It does indeed work without nographic. (It doesn't do anything _useful_ for
> me without nographic, since I'm scripting the emulated kernel's behavior
> through stdin and stdout, but allowing it to pop up an SDL window does make it
> out of openbios and into the kernel.)
The kernel makes the equivalent of the following calls to OF interface:
finddevice("/") = 0x11d5c
finddevice("/chosen") = 0x1197c
finddevice("/openprom") = 0x11b3c
getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
memmove overwrites all memory.
But where does this 0x86ea0 come from?
On 08.03.2009 8:51 Uhr, svn(a)openbios.org wrote:
> Author: blueswirl
> Date: 2009-03-08 08:51:18 +0100 (Sun, 08 Mar 2009)
> New Revision: 470
> Move openbios-devel under /trunk
Thank you, blueswirl, for cleaning up the repository.
A small hint for anyone with existing modified trees: When you want to
bring over your checked-out openbios-devel repository, you can do:
$ cd openbios-devel
$ svn switch svn://openbios.org/openbios/trunk/openbios-devel .
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866