From owner-freebsd-ppc@freebsd.org Sun Oct 14 05:59:46 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45AD210C685F for ; Sun, 14 Oct 2018 05:59:46 +0000 (UTC) (envelope-from cam@neo-zeon.de) Received: from neo-zeon.de (neo-zeon.de [96.90.244.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.neo-zeon.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7BEE7AA69 for ; Sun, 14 Oct 2018 05:59:45 +0000 (UTC) (envelope-from cam@neo-zeon.de) Received: from [192.168.0.2] (amuro.nerv.lan [192.168.0.2]) (authenticated bits=0) by neo-zeon.de (8.15.2/8.15.2) with ESMTPSA id w9E5xhJS010465 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 13 Oct 2018 22:59:44 -0700 (PDT) (envelope-from cam@neo-zeon.de) Subject: Re: FreeBSD 12.0-ALPHA4 fails to boot on POWER9/KVM From: Cameron Berkenpas To: freebsd-ppc@freebsd.org References: <5d84652d-8b54-19f9-1396-e7c9acbe6c03@neo-zeon.de> <5f44c6d6-7eec-6732-6fef-123e7e0d3292@freebsd.org> <2b4455f4-37f6-5645-dcba-2cc41c845ae8@neo-zeon.de> <0a970b75-160a-e40e-b360-1b73a753f701@freebsd.org> <573eb381-35f0-5523-3d6a-77a01174bdc8@blastwave.org> <557519fc-a1f7-4a78-ee77-eae6f96d3a5e@freebsd.org> <341c38b5-d319-226c-946e-ecdbeaae1d0c@neo-zeon.de> Message-ID: <46e403ec-b5db-a706-2002-7783413d8c97@neo-zeon.de> Date: Sat, 13 Oct 2018 22:59:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <341c38b5-d319-226c-946e-ecdbeaae1d0c@neo-zeon.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 05:59:46 -0000 In order to get this working with libvirt/virt-manager, simply do: virsh edit And add the following under your "" line.         Apparently you can turn this further, but this little snippet is enough. I had to use "virsh edit" to force remove the VGA device to get a serial console to see what was going on. I/O seems really slow... I booted into a non-debug kernel, but that didn't seem to make much of a difference. Anyone know how much of this due to not supporting virtio yet vs lack of optimization for PPC/PPC64? Anyway, the last issue for me, and it's not major, is that shutting down doesn't work. Ie, "virsh shutdown " simply doesn't do anything. Shutting down from within the guest itself works fine though, so I guess this isn't a HUGE issue. Anyway, I hope this all eventually helps someone. Thanks! -Cameron On 10/13/2018 04:18 PM, Cameron Berkenpas wrote: > Whoops, that would be: > > make buildworld buildkernel TARGET=powerpc TARGET_ARCH=powerpc64 > make cdrom TARGET=powerpc TARGET_ARCH=powerpc64 > > > Good catch. Turns out that's the bootloader of my install that no > longer boots... > > So you can either manually select to boot from the cd-rom in the > firmware, or here's how to boot from the cd-rom via kvm/qemu: > qemu-system-ppc64 -enable-kvm -m 2048 -nographic -vga none -boot > order=d -cdrom bootonly.iso -drive > file=/var/lib/libvirt/images/freebsd-ppc.qcow2,format=qcow2 > -mem-prealloc -mem-path /dev/hugepages -smp 2 > > Then after installing, of course remove the '-boot' option and its > argument to boot from the disk. > > Interestingly, disc1.iso still won't boot: > Trying to load:  from: /vdevice/v-scsi@71000003/disk@8200000000000000 > ... failed to load CHRP boot loader.failed to load CHRP boot loader. > E3404: Not a bootable device! > > There's probably something wrong with my disc1.iso. > FreeBSD-12.0-ALPHA9-powerpc-powerpc64-20181009-r339271-disc1.iso boots > successfully in spite of the "NOT FOUND" errors. > > My earlier attempts with bootonly.iso failed due to some foolishness > on my part. The above examples will work. > > However, during the install, I'm getting a checksum error with > base.txz. Looking at the MANIFEST, it seems correct. > > I used the ALPHA9 ISO and was able to install successfully. Anyway, > just remember to use the MBR partition scheme or your install won't boot. > > I still can't get FreeBSD to boot through virt-manager/libvirt, but > I'm still trying to see if I get that working too. > > -Cameron > > On 10/13/2018 01:08 PM, Nathan Whitehorn wrote: >> >> On 10/13/18 12:53 PM, Cameron Berkenpas wrote: >>> Hello, >>> >>> Finally had some time to spin up my own ISO from 12-CURRENT. >>> Unfortunately, it still fails. Looks like there's no real change from >>> before. >>> >>> # This is how I built the cdrom image: >>> make cdrom TARGET=powerpc TARGET_ARCH=powerpc64 >>> make cdrom TARGET=powerpc TARGET_ARCH=powerpc64 >>> >>> I tried this with revision r339340. >> [...] >> >>>>> FreeBSD/powerpc Open Firmware boot block >>>     Boot path: /pci@800000020000000/scsi@7/disk@100000100000000 >>>     Boot loader: /boot/loader >>>     Boot volume: /pci@800000020000000/scsi@7/disk@100000100000000:2 >>> Consoles: Open Firmware console >>> >>> FreeBSD/powerpc64 Open Firmware loader, Revision 0.1 >>> (Sun Aug 19 13:30:54 PDT 2018 root@freebsd-ppc) >> >> I think you aren't using the loader you think you are using judging by >> the date above. >> -Nathan >> >>> Memory: 2097152KB >>> Booted from: /pci@800000020000000/scsi@7/disk@100000100000000 >>> >>> >>> block-size NOT FOUND >>> #blocks NOT FOUND| >>> block-size NOT FOUND >>> #blocks NOT FOUND\ >>> block-size NOT FOUND >>> #blocks NOT FOUND >>> >>> ( 700 ) Program Exception [ 0 ] >>> >>> >>>      R0 .. R7           R8 .. R15         R16 .. R23 R24 .. R31 >>> 0000000000000040   000000000345cdc4   ffffffffffffffff 0000000002c50468 >>> 0000000002c548c0   0000000000000000   0000000002c56ba0 0000000002c513a0 >>> 0000000000000000   0000000002c67780   0000000002c56b98 0000000002c51c18 >>> 000000000345d8f0   0000000002c67300   0000000002c62200 000000000345d8f0 >>> 0000000002c67340   0000000020000048   000000000040e78e 0000000000000000 >>> 0000000000000000   0000000000000000   0000000001802118 0000000000000000 >>> 0000000000000040   0000000002c4baec   0000000002c71980 0000000000000000 >>> 0000000000000040   000000007fffffff   0000000002c5bb84 000000000345d8f0 >>> >>>      CR / XER           LR / CTR          SRR0 / SRR1 DAR / DSISR >>>          80000044   0000000002c02938   0000000000000000 >>> 0000000000000000 >>> 0000000020040000   0000000000000000   0000000000083000 00000000 >>> >>> >>> e > >>> >>> Hope this is helpful! >>> >>> On 10/11/2018 12:00 PM, Dennis Clarke wrote: >>>> On 10/11/2018 02:50 PM, Mark Millard wrote: >>>>> On 2018-Oct-11, at 11:19 AM, Dennis Clarke >>>> blastwave.org> wrote: >>>>> >>>>>> On 10/10/2018 11:59 PM, Nathan Whitehorn wrote: >>>>>>> The first part of this (all the errors about "NOT FOUND") I just >>>>>>> fixed >>>>>>> and the fixes will be included in BETA1 and subsequent builds. The >>>>>>> remaining issue is that virtio SCSI is not part of the standard >>>>>>> kernel >>>>>>> on PPC (there are some endian and DMA bugs), so you will need to >>>>>>> use an >>>>>>> alternative storage backend. The default storage backend (VSCSI) is >>>>>>> fine, as are more PC-ish things like AHCI emulation. >>>>>>> This command line will work and is otherwise equivalent to the >>>>>>> below: >>>>>>> qemu-system-ppc64 -enable-kvm -m 2048 -nographic -vga none -cdrom >>>>>>> FreeBSD-12.0-ALPHA9-powerpc-powerpc64-20181009-r339271-disc1.iso >>>>>>> /var/lib/libvirt/images/freebsd-ppc.qcow2 -mem-prealloc -mem-path >>>>>>> /dev/hugepages -smp 2 >>>>>>> -Nathan >>>>>> >>>>>> Has anyone tried this on a PowerMac G5 yet ? >>>>> "this"? I'm unsure if the following is addressing what you are >>>>> referring to or not. But it might be. >>>>> >>>>> Until the problems with -r334498 's adjustment to >>>>> VM_MAX_KERNEL_ADDRESS >>>>> are dealt with, PowerMac G5's have boot problems (and possibly other >>>>> problems), at least those with multiple sockets (for what I can >>>>> test). >>>>> (I've no access to other forms of PowerMac G5's.) >>>>> >>>>> See: >>>>> >>>>> https://lists.freebsd.org/pipermail/freebsd-ppc/2018-October/009669.html >>>>> >>>>> >>>>> >>>>> and later in that thread. (Earlier in the thread is likely a waste >>>>> of time >>>>> to read, given what is now known.) >>>>> >>>>> My G5 contexts are operational by reverting -r334498 . The >>>>> contexts are >>>>> otherwise based on -r339076 currently. >>>>> >>>>> >>>>> Note: >>>>> >>>>> My boot test on a 8 GiByte, dual-socket, one "CPU" per socket, >>>>> PowerMac G5 met the conditions of Andreas Tobler's requested test >>>>> conditions and the machine boot fine (VM_MAX_KERNEL_ADDRESS near >>>>> the RAM size, on the low side). >>>>> >>>>> The G5 so-called "Quad Core"s, 4 cores total in each system but >>>>> split evenly across 2 sockets in each), one with 12 GiByte and >>>>> one with 16 GiByte of RAM, booted fine as well. But >>>>> VM_MAX_KERNEL_ADDRESS was somewhat under 8GiByte and so not near >>>>> those sizes. >>>>> >>>> >>>> OKay ... that is a lot of good information and I'll sum up as "no". >>>> >>>> Was merely curious if I should give it a try. >>>> >>>> Dennis >>>> >>>> >>>> _______________________________________________ >>>> freebsd-ppc@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-ppc@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >> >