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=…http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=…
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...
How much diagnostics support is already in OpenBIOS and what would it
take to add something like sun's OBDiag.
Has anyone ever tried running a sparc32 OpenBIOS image on real hardware?
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
>
> Added:
> trunk/openbios-devel/
> Removed:
> openbios-devel/
> Log:
> 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 .
Stefan
--
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