From owner-freebsd-hackers@freebsd.org Mon Mar 25 10:33:51 2019 Return-Path: Delivered-To: freebsd-hackers@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 8AE84155AC6C; Mon, 25 Mar 2019 10:33:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2617D8B44F; Mon, 25 Mar 2019 10:33:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.0.12] (cpc91194-cmbg18-2-0-cust919.5-4.cable.virginm.net [80.6.183.152]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 9A2F04E6E6; Mon, 25 Mar 2019 10:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1553510021; bh=Z8MAmmC/K8A9vCio/5nSFTsKReU1TEGDIP9cGfn8Wts=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=diWjpZWxC203lQ0fMViGvt+ArAmDZbEyj2MxU22WGidLAfXTcvG+J1mLNfglQvLl9 Jli3UZuNxbh12VoLGCeq3XLK/TlqvjsciK1+o7l5ma31zLjkgdWreMtfvMvwnPsRs6 BC6v6r4y7AfutZAW8oCjZLyzkEROlTU8WvzTH87uEwuGDNsUd7CoiwdnFacPUs2xja 29Y2YDZ3mrSPCa8xHQLNMFXFwNb/LDIPQKYDpfhMVN8skRrEFcSl8I3EuqN7rdEm18 c4f081xWBmLrTWA9I4EZZky6oOu8N7vE0Reel/ZRVXf0SAtmyR0BHfxF5wEk5m61bF 9SBaxyr1EZ32fsNnPC8///TF4tv8UEqDWTDSXEK7pKrzo43Pn9iTNnkmT4rMQSLg8C /o/BmY9+DUxPJkR1qoHrTsuvASNLJBtWy+PhpMLtoidK4/vk1xYIkTQhc6oi1JLdcd eMCDz+Vs4b7VKDO6mkQbmZJJsCLnPL+beHh3yGTUta2uiGStGeAJtEspTyERG0Iszj zc1BkcHTHUrwWL04Pm5hc64M0yzo+Na7AzgDXmaV/jzvYiacArTki3ls7EcOtQAyV6 ScakReWiO4llhYOv9BsI+Kr2Y9BHVuFqpzNCZXRX+oaLJAF+RgxGWcdYvJm7L/fbr6 IrPnGVi+v/vPSk0RBCVxdwOE= From: Andrew Turner Message-Id: <2E6E33E9-FF5E-4198-AC48-37C0873CAF95@fubar.geek.nz> Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Date: Mon, 25 Mar 2019 10:33:40 +0000 In-Reply-To: Cc: Rebecca Cran , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" To: Warner Losh References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 2617D8B44F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 10:33:51 -0000 > On 25 Mar 2019, at 00:49, Warner Losh wrote: >=20 > On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran > wrote: >=20 >> On 3/24/19 5:57 PM, Warner Losh wrote: >>=20 >>=20 >> He's asking for stopping doing a make install in src/stand. I'm = thinking >> that's a good thing. We should update the ESP's = \efi\freebsd\loader.efi, >> but leave the\efi\boot\bootXXXX.efi alone as part of this new = installloader >> phase. Again, only if the ESP is mounted, and we have a default spot = for >> it. For this script, I don't think hunting for the ESP is the right = way to >> go... which means we need to define a standard place for the ESP to = be >> mounted, which we should do before we turn on any of these features. >>=20 >> We have the start of a generic script to update things in >> src/tools/boot/install-boot.sh which was supposed to install boot = blocks on >> everything known to run FreeBSD. >>=20 >>=20 >> Only updating \efi\freebsd\loader.efi is the wrong thing to do in my >> opinion: there are situations like on ARM where EFI variables aren't >> persistent, and we need \efi\boot\bootxxxx.efi for booting. What we = could >> do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which = case we >> know any changes to BootXXXX variables won't survive a reboot, and we = need >> BOOTxxxx.efi. >>=20 > Systems that don't support variables are a super duper weird special = case. > Let's not let them drive the design. I want to get to (a) a = standardized > mount point and (b) drive people towards having the boot loader be in > /efi/freebsd/loader.efi. our tooling should reflect that first and > foremost. The weirdo, special cases that likely won't be updating from > source are secondary. Let's get a good design flow down first for the = most > common case, one that encourages the most people to adopt the standard = boot > flow as possible. Systems that don=E2=80=99t support reading variables are weird, however = systems that don=E2=80=99t support writing valuables are common for arm = and arm64. The EBBR spec [1] that Arm and others are working on allows = both reading and writing variables via the runtime services as optional = [2]. This is because these variables may be stored on the same media as = the OS. It would be nice if we could support this case, even if it=E2=80=99s not = the default on systems that support setting variables. Andrew [1] https://github.com/ARM-software/ebbr [2] = https://github.com/ARM-software/ebbr/blob/v1.0-rc1/source/chapter2-uefi.rs= t