From owner-svn-src-head@freebsd.org Mon Oct 16 17:46:59 2017 Return-Path: Delivered-To: svn-src-head@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 11CD6E404D7; Mon, 16 Oct 2017 17:46:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF7C364AE5; Mon, 16 Oct 2017 17:46:58 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0OXX00F00DXT3T00@st13p35im-asmtp001.me.com>; Mon, 16 Oct 2017 17:08:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1508173704; bh=qT99Ni+pjsSO/HzaVIvG/OxG35Isjf29RZJx7r9Uuls=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=8EfiDrPJDAoW+/tzY4Dk/FKAwxEtlkBgi35OSsWsBId87aTAPqeZAaXhqFuwP2pK4 CAQ/PjnmiDJEfW8HY5Z74Y0EeO33uIj1GiaJrkMN+Xgw7nWaC/wM5JlTZffavTnlwx sQr6xhBbjj81WEYFlpeOYVuThNn+ZRoa4mrepNZ//uKTG5f8/+c1gfVkBKLMcxaRNb D8GFmxJZwAv3R3XUkmalGTdKD/r5YUbVmqfyTRckvorKD9JehemysVc4yr4DGG33ut mtiGxUGc0qy4djPAy9knO33QoO2IYDh0r5AovXYc/Prqi1WqiFOthvbbYuQWkCeFHh jckC0eNxqBoJQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0OXX0056NE9W8J50@st13p35im-asmtp001.me.com>; Mon, 16 Oct 2017 17:08:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-16_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710160239 From: Toomas Soome Message-id: MIME-version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: svn commit: r324646 - in head/sys/boot/efi: boot1 libefi loader Date: Mon, 16 Oct 2017 20:08:19 +0300 In-reply-to: <3BED6A0F-689C-4B89-A2AA-6990FB473539@fubar.geek.nz> Cc: Warner Losh , eric@meatspace.com, src-committers , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Warner Losh To: Andrew Turner References: <201710160359.v9G3xCCi087576@repo.freebsd.org> <3BED6A0F-689C-4B89-A2AA-6990FB473539@fubar.geek.nz> X-Mailer: Apple Mail (2.3445.1.7) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 17:46:59 -0000 The arm (uboot) has a bit different approach on block device(s), see = efipart_hdinfo_add_filepath() in efipart.c; the code needs to check for = MEDIA_FILEPATH_DP, I think. rgds, toomas > On 16 Oct 2017, at 19:07, Andrew Turner wrote: >=20 > Correct, it is aarch64. It runs a similar qemu command, however I also = see it under the ARM Foundation model so it seems to not be simulator = specific. >=20 > Andrew >=20 >> On 16 Oct 2017, at 16:56, Warner Losh > wrote: >>=20 >> So this is on aarch64? Is this running a standardish qemu setup as = documented on https://wiki.freebsd.org/arm64/QEMU = ? Or are there tricks that we need = to cope with... >>=20 >> If we can't get good resoltuion on this today, I plan on backing out = the entire change. >>=20 >> Warner >>=20 >> On Mon, Oct 16, 2017 at 9:38 AM, Andrew Turner > wrote: >> I have a local Jenkins setup that builds images & tries to run under = various simulators. The final image is built with mkimg. I=E2=80=99m = running it under qemu. >>=20 >> Andrew >>=20 >>> On 16 Oct 2017, at 13:19, Warner Losh > wrote: >>>=20 >>> I'll take a look, but I've also ccd Eric so he can figure out what = went wrong with is code in your environment. What env is That? >>>=20 >>> Warnee >>>=20 >>> On Oct 16, 2017 3:26 AM, "Andrew Turner" > wrote: >>>=20 >>> > On 16 Oct 2017, at 04:59, Warner Losh > wrote: >>> > >>> > Author: imp >>> > Date: Mon Oct 16 03:59:11 2017 >>> > New Revision: 324646 >>> > URL: https://svnweb.freebsd.org/changeset/base/324646 = >>> > >>> > Log: >>> > Unify boot1 with loader >>> > >>> > Refactor boot1 to use the same I/O code as /boot/loader uses. = Refactor >>> > to use the common efi_main.c. >>> > >>> > Submitted by: Eric McCorkle >>> > Differential Revision: https://reviews.freebsd.org/D10447 = >>> > >>> > Added: >>> > head/sys/boot/efi/libefi/efi_main.c (contents, props changed) >>> > - copied, changed from r324645, = head/sys/boot/efi/loader/efi_main.c >>> > Deleted: >>> > head/sys/boot/efi/boot1/boot_module.h >>> > head/sys/boot/efi/boot1/ufs_module.c >>> > head/sys/boot/efi/boot1/zfs_module.c >>> > head/sys/boot/efi/loader/efi_main.c >>> > Modified: >>> > head/sys/boot/efi/boot1/Makefile >>> > head/sys/boot/efi/boot1/boot1.c >>> > head/sys/boot/efi/libefi/Makefile >>> > head/sys/boot/efi/loader/Makefile >>>=20 >>> Hello Warner, >>>=20 >>> After this change I=E2=80=99m getting the following panic on various = test VMs. >>>=20 >>> Andrew >>>=20 >>> >> FreeBSD EFI boot block >>>=20 >>> Loader path: /boot/loader.efi >>>=20 >>> Load Path: \EFI\BOOT\BOOTAA64.EFI >>> Load Device: = VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003C000A00000000)/HD(1,GPT,DD40= E9C6-B247-11E7-AA0A-15EFE1BBB7CF,0x3,0x640) >>> panic: Couldn't trim device path >>> --> Press a key on the console to reboot <-- >>>=20 >>=20 >>=20 >=20