From owner-freebsd-arm@freebsd.org Fri Dec 30 08:14:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7DE3C97499 for ; Fri, 30 Dec 2016 08:14:59 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B74B51C17 for ; Fri, 30 Dec 2016 08:14:59 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from [136.179.10.143] (helo=[10.140.230.85]) by id.bluezbox.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cMsL3-0005fI-Ht; Fri, 30 Dec 2016 00:14:58 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: loading 'VIRT' kernel in qemu From: Oleksandr Tymoshenko In-Reply-To: <58C0D791-3D3C-4DE2-9EAF-93DA40ED620D@bluezbox.com> Date: Fri, 30 Dec 2016 00:14:26 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <272ABF9C-4735-44C4-8EB8-FBCCDE37785A@bluezbox.com> References: <58C0D791-3D3C-4DE2-9EAF-93DA40ED620D@bluezbox.com> To: Jason Harmening X-Mailer: Apple Mail (2.3259) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > On Dec 29, 2016, at 5:25 PM, Oleksandr Tymoshenko wrote: > > >> On Dec 29, 2016, at 5:12 AM, Jason Harmening wrote: >> >> .. skipped .. >> >> Ah, thanks! That should make things a good deal easier. >> Using the nanobsd-generated images and the qemu invocation from qemu-armv7.cfg, I get a bit further but end up with a repeating prefetch abort: >> Prefetch Abort Exception PC at 0xFF176790 CPSR 0x80000113 >> >> This is either in UEFI or very early in kernel bootstrap, since the copyright hasn't printed yet...haven't poked at it to figure out where the pc comes from yet. > > Looks like it's boot1.efi. After upgrading to clang 3.9.0 -fPIC is required to build loader. In addition to this problem there seems to be some error when calculating value for relocation. Looks like it’s going to take a bit of time to track down, I can’t identify it immediately. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bluezbox.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 08:15:00 -0000 > On Dec 29, 2016, at 5:25 PM, Oleksandr Tymoshenko = wrote: >=20 >=20 >> On Dec 29, 2016, at 5:12 AM, Jason Harmening = wrote: >>=20 >>=20 .. skipped .. >>=20 >> Ah, thanks! That should make things a good deal easier. >> Using the nanobsd-generated images and the qemu invocation from = qemu-armv7.cfg, I get a bit further but end up with a repeating prefetch = abort: >> Prefetch Abort Exception PC at 0xFF176790 CPSR 0x80000113 >>=20 >> This is either in UEFI or very early in kernel bootstrap, since the = copyright hasn't printed yet...haven't poked at it to figure out where = the pc comes from yet. >=20 > Looks like it's boot1.efi. After upgrading to clang 3.9.0 -fPIC is = required to build loader. In addition to this problem there seems to be = some error when calculating value for relocation. Looks like it=E2=80=99s = going to take a bit of time to track down, I can=E2=80=99t identify it = immediately. =20 Hi Jason, I think I fixed the PIC problem along with FDT-related one: https://people.freebsd.org/~gonzo/arm/patches/arm-uefi.diff You also need to provide 256M memory to qemu, because loader.efi allocates 64Mb heap and 128Mb is just not enough for UEFI firmware and loader.efi. Message below is an indication of such error: Failed to start image provided by UFS (9) I used following command line to test nanobsd image: qemu-system-arm -M virt -serial stdio -bios QEMU_EFI.fd \ -m 256M -nographic -monitor none \ -drive if=3Dnone,file=3D_.disk.image.qemu-armv7.qcow2,id=3D= hd0 \ -device virtio-blk-device,drive=3Dhd0