From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LkxZH-0003E2-HU for qemu-devel@nongnu.org; Sat, 21 Mar 2009 05:32:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LkxZC-0003Dq-Qw for qemu-devel@nongnu.org; Sat, 21 Mar 2009 05:32:38 -0400 Received: from [199.232.76.173] (port=37577 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LkxZC-0003Dn-JJ for qemu-devel@nongnu.org; Sat, 21 Mar 2009 05:32:34 -0400 Received: from mail-bw0-f172.google.com ([209.85.218.172]:57992) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LkxZB-0006ZF-RP for qemu-devel@nongnu.org; Sat, 21 Mar 2009 05:32:34 -0400 Received: by bwz20 with SMTP id 20so1027515bwz.34 for ; Sat, 21 Mar 2009 02:32:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <200903171857.42875.rob@landley.net> <200903181328.30900.rob@landley.net> <200903182216.39345.rob@landley.net> Date: Sat, 21 Mar 2009 11:32:30 +0200 Message-ID: Subject: Re: [Qemu-devel] svn 6658 broke powerpc. From: Blue Swirl Content-Type: multipart/mixed; boundary=001636c5b6da5c05ad04659db643 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: The OpenBIOS Mailinglist , qemu-devel@nongnu.org --001636c5b6da5c05ad04659db643 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/19/09, Blue Swirl wrote: > On 3/19/09, Rob Landley wrote: > > On Wednesday 18 March 2009 14:11:19 Blue Swirl wrote: > > > On 3/18/09, Rob Landley 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? > > > > > > No idea, but it worked with the previous openbios, and without --nographic. > > This is a 2.6.28.8 kernel built with the attached .config. > > > > By the way, while binary searching the openbios repository to figure out > > exactly what commit between 450 and 463 actually caused it to stop working, > > and I hit a fun little OpenBios hiccup in the top level Makefile of current > > OpenBios svn: > > > > build: > > @printf "Building..." > > @for dir in $(ODIRS); do \ > > $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \ > > ( echo "error:"; tail -15 $$$dir/build.log; exit 1 ) \ > > done > > > > You have one too many $ before dir/build.log in the error message, so the > > error message you get is > > > > Building...error: > > tail: cannot open `/build.log' for reading: No such file or directory > > make: *** [build] Error 1 > > > I must always have used build-verbose. Should be fixed soon. > > > > Which took about 15 minutes of head scratching for a newbie like me to track > > down. (The actual problem was that your config/examples/cross-ppc_rules.xml > > hardwires TARGET=powerpc-linux-gnu- and my cross compiler just uses powerpc- > > as the prefix, and overriding TARGET on the make command line doesn't work > > because you use recursive make, and you aren't doing the ?= conditional > > assignments that won't overwrite existing environment variable values. I more > > or less expected it and was running the thing the first time so it would tell > > me what cross compiler name it expected when it died unable to find it. Easy > > enough to fix by just editing the darn file, but a mention of it in the README > > wouldn't go amiss...) > > > But my tools also use different prefix, powerpc-elf- > (powerpc-unknown-elf). I compile using: > > make build-verbose TARGET=powerpc-elf- > > without problems. > > About the OpenBIOS problem, I've done further debugging. The crash can > be reproduced with (-nographic -prom-env auto-boot?=false): > 0 > cd /chosen ok > 0 > .properties > name "chosen" > stdin 86904 > stdout 86a08 > memory 86da0 > mmu 867e8 > display 86660 > nvram 86750 > rtc 86d3c > ok > 0 > 86904 get-instance-path type invalid/unsupported opcode: 00 - 00 > - 00 (00000000) fff18f04 1 > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1 > invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230 > > But other nodes crash too: > 0 > 86da0 get-instance-path type /memory@0 ok > 0 > 86660 get-instance-path type /pci@80000000/QEMU,VGA@1 ok > 0 > 86750 get-instance-path type invalid/unsupported opcode: 00 - 00 > - 00 (00000000) fff18f04 1 > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1 > invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230 > > 0 > 86d3c get-instance-path type invalid/unsupported opcode: 00 - 00 > - 00 (00000000) fff18f04 1 > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1 > invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230 > > Sparc32 doesn't crash: > 0 > cd /chosen ok > 0 > .properties > name "chosen" > stdin ffda1824 > stdout ffda18c0 > memory ffda1a88 > mmu 0 > screen ffda1a28 > ok > 0 > ffda1824 get-instance-path type /obio/zs@0,100000:a ok > 0 > ffda18c0 get-instance-path type /obio/zs@0,100000:a ok > 0 > ffda1a28 get-instance-path type > /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 ok > 0 > ffda1a88 get-instance-path type /memory@0,0 ok 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? --001636c5b6da5c05ad04659db643 Content-Type: plain/text; name="fix_ppc_nographic.diff" Content-Disposition: attachment; filename="fix_ppc_nographic.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fsk3e0uh SW5kZXg6IG9wZW5iaW9zLXF1aWx0L2RyaXZlcnMvZXNjYy5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG9wZW5i aW9zLXF1aWx0Lm9yaWcvZHJpdmVycy9lc2NjLmMJMjAwOS0wMy0yMSAwNzoxNzowNy4wMDAwMDAw MDAgKzAwMDAKKysrIG9wZW5iaW9zLXF1aWx0L2RyaXZlcnMvZXNjYy5jCTIwMDktMDMtMjEgMDk6 MTE6MjYuMDAwMDAwMDAwICswMDAwCkBAIC00NDYsNyArNDQ2LDkgQEAKICAgICBzZXRfaW50X3By b3BlcnR5KGRub2RlLCAiI2FkZHJlc3MtY2VsbHMiLCAxKTsKICAgICBwcm9wc1swXSA9IF9fY3B1 X3RvX2JlMzIoSU9fRVNDQ19PRkZTRVQpOwogICAgIHByb3BzWzFdID0gX19jcHVfdG9fYmUzMihJ T19FU0NDX1NJWkUpOworI2lmIDAgLy8gWFhYCiAgICAgc2V0X3Byb3BlcnR5KGRub2RlLCAicmVn IiwgKGNoYXIgKikmcHJvcHMsIHNpemVvZihwcm9wcykpOworI2VuZGlmCiAgICAgc2V0X3Byb3Bl cnR5KGRub2RlLCAiZGV2aWNlX3R5cGUiLCAiZXNjYyIsCiAgICAgICAgICAgICAgICAgIHN0cmxl bigiZXNjYyIpICsgMSk7CiAgICAgc2V0X3Byb3BlcnR5KGRub2RlLCAiY29tcGF0aWJsZSIsICJl c2NjXDBDSFJQLGVzMCIsIDE0KTsK --001636c5b6da5c05ad04659db643--