Date: Mon, 25 Mar 2019 10:33:40 +0000 From: Andrew Turner <andrew@fubar.geek.nz> To: Warner Losh <imp@bsdimp.com> Cc: Rebecca Cran <rebecca@bluestop.org>, Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <2E6E33E9-FF5E-4198-AC48-37C0873CAF95@fubar.geek.nz> In-Reply-To: <CANCZdfodhpRcUJoGZs1F3zcXGLAZKh=dVJ_oRGkF=eCV6zUW9Q@mail.gmail.com> References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <e6695237-6a22-3ff0-b113-9efeee05a51a@bluestop.org> <CANCZdfq1vb2-R-R4AZyoqi_940GCooMuhXyjCgSkHSusic5p_w@mail.gmail.com> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> <CANCZdfodhpRcUJoGZs1F3zcXGLAZKh=dVJ_oRGkF=eCV6zUW9Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 25 Mar 2019, at 00:49, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran <rebecca@bluestop.org = <mailto:rebecca@bluestop.org>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E6E33E9-FF5E-4198-AC48-37C0873CAF95>