From nobody Sun Aug 04 03:51:49 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Wc5H672rGz5S1Vr for ; Sun, 04 Aug 2024 03:52:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wc5H65Httz4v2g for ; Sun, 4 Aug 2024 03:52:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2cf93dc11c6so5978978a91.1 for ; Sat, 03 Aug 2024 20:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1722743520; x=1723348320; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qU+kEVY7bL1PoFfsGmrstQOyzsbMLitAVO/bL33F5EY=; b=zkesjzrxlzZkdw0P7keFsHxaryCIXFVQFi0sModq0mBsuBb7zerQEKBpetnYN8tv+L P7vuk59WEzGMJMlIJ3UU9puWo2StDrLVQMUc9l9gA2ArCGH2LffRBnn52P2H1E4Vv5it yXiGcb0ee5Jjobekf+2m+AX0svHdOrbIBRdXAajl/7e+BBELJq7WEd/wdb9Ut0i1F/Rc pLejvuaYq8OFL3P+K7zZjbZBUtCv3lE3gUJnSBYglxTMCHi1ABBHtgw2+rq3vokSwwor MuF6kLWIjrp97iea84GsSYo59eugfy2gfI3PK6eEFTDCmkXfxEZSxSTIU8b2gVsMFUkG pZgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722743520; x=1723348320; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qU+kEVY7bL1PoFfsGmrstQOyzsbMLitAVO/bL33F5EY=; b=CTUvHw1hjiT1q6ym8WewPpAWeW20hhRhttSRWU36Awf9Oob+wopdk6T2mtXOXgIa3E wSkg1r4Xr+JdU6oOHA6xJvjtRP81Qz8qShbpo3RfsuB5yF++XP5dZXCiaq5ZVtLQD50c 7Yp8oRg91s3JR4SZRT3XNVRHbCX3sWqJuX7Sunilv1ferTW5IwBtYEcR/BxXpQjJoH6w kYmxNKWfftOMXE5hwviAQK95j0rZOTjz8fLuT7Y1OtANdR0TzMoGnHyaxKHIBFUJ7BV3 sk1679/F5rkAnugcfjH7S47s05F7vBOwnSHvLCWFQePPEtACZbhMMmS3pX31Yb2tyECz /2yw== X-Forwarded-Encrypted: i=1; AJvYcCUzM1XWhbr++d1Hyq5p0In1LpDmOoVipTzlHU+hIrR8fAwtqP+ZSXQ4WzNUkNM+RGozrq05c/oERwdVZdflzgaJwTsTKKlB6g== X-Gm-Message-State: AOJu0YzOzu4dNiZiVFm4x/b9UmwS4AxK+FZFLUmjSg6uDjJj5rQiJBBy pxINlV9BYomr2tODIM0RdkQHr3thk/Pkwe/ksvnL0TR/Zg/5u5Oaksjv5kWqYMCkTuhgz5uYQr9 x1nAMwpscZvO8YjZOvGUjpFGYQTM8bpl6R3ocTA== X-Google-Smtp-Source: AGHT+IEiD2UaNfpgJtL7SMh1zg3Qd3rUqi998ccTDEkMTxV6MEEtEdM9XHXVBR+n9HufYdbTzbiWcEZYDnC/M9DT4UE= X-Received: by 2002:a17:90b:4a46:b0:2ca:a625:f9e9 with SMTP id 98e67ed59e1d1-2cff955f207mr9058920a91.42.1722743520597; Sat, 03 Aug 2024 20:52:00 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 3 Aug 2024 21:51:49 -0600 Message-ID: Subject: Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE. To: bob prohaska Cc: Mark Millard , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000095c2a8061ed37b54" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wc5H65Httz4v2g --00000000000095c2a8061ed37b54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 3, 2024 at 1:00=E2=80=AFPM bob prohaska wr= ote: > On Sat, Aug 03, 2024 at 08:47:54AM -0600, Warner Losh wrote: > > On Sat, Aug 3, 2024, 8:28=E2=80=AFAM bob prohaska = wrote: > > > Is there some reason installworld (or some other make target) doesn't > > > do this by default? The msdos filesystem is mounted and writeable any > > > time the host is running. > > > > > > > > > I have the doodle of a design to have a make installboot that would do = it > > based on parameters set for their system. But i got bogged down when > uboot > > and powerpc ofw got into the mix. > > Could the problem be made less intractable by limiting the scope per > board or board family? I've not played with any but Raspberry Pi in > the past 9 years so have little idea what's in use today. > Well, not really... But writing one for just UEFI isn't terrible for the typical case. We set loader variables in EFI variable space to say what the loader was. So we can look at them to see. We can translate the path to the actual ESP that was updated, and we can know the full path to the last booted thing. But... there's a fair amount of variation even in that. Some safeguards are needed. We know the path of what booted, but we don't necessarily know what the .efi file in FreeBSD is that needs to be copied over. And that's before we have the 'old bootloader' from FreeBSD 11 or earlier that doesn't have a big enough ESP to do the upgrade. Most of these failure cases though we just need to fail-safe: Sorry, you can't upgrade automatically. Really old loaders don't set the variables, So we'd have to fall back to looking at efibootmgr -v to work it out. armv7 and some systems that don't have efi will both have problems, since we can't get the efi variables we want. So do you puzzle out these, or ??? And finally, even if we know exactly what to upgrade and where, there's several people that have mirrored setups, exiter explicitly or implicitly. So should a uefi-update handle some or all of these cases? With or without explicit fallbacks? Should unmounted ESPs be mounted for a minute to do the update? Maybe I'm overthinking this, eh? Warner p.s. the uboot stuff was even more of a convoluted mess. --00000000000095c2a8061ed37b54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Aug 3, 2024 at 1:00=E2=80=AFP= M bob prohaska <fbsd@www.zefox.net= > wrote:
= On Sat, Aug 03, 2024 at 08:47:54AM -0600, Warner Losh wrote:
> On Sat, Aug 3, 2024, 8:28=E2=80=AFAM bob prohaska <fbsd@www.zefox.net> wrote: > > Is there some reason installworld (or some other make target) doe= sn't
> > do this by default? The msdos filesystem is mounted and writeable= any
> > time the host is running.
> >
>
>
> I have the doodle of a design to have a make installboot that would do= it
> based on parameters set for their system. But i got bogged down when u= boot
> and powerpc ofw got into the mix.

Could the problem be made less intractable by limiting the scope per
board or board family? I've not played with any but Raspberry Pi in
the past 9 years so have little idea what's in use today.

Well, not really...

But wr= iting one for just UEFI isn't terrible for the typical case. We set
loader variables in EFI variable space to say what the loader was. S= o
we can look at them to see. We can translate the path to the ac= tual ESP
that was updated, and we can know the full path to the l= ast booted thing.

But... there's a fair amount= of variation even in that. Some safeguards
are needed. We know t= he path of what booted, but we don't necessarily
know what th= e .efi file in FreeBSD is that needs to be copied over. And
that&= #39;s before we have the 'old bootloader' from FreeBSD 11 or earlie= r
that doesn't have a big enough ESP to do the upgrade. Most = of these failure
cases though we just need to fail-safe: Sorry, y= ou can't upgrade automatically.

Really old loa= ders don't set the variables, So we'd have to fall back to looking<= /div>
at efibootmgr -v to work it out.

arm= v7 and some systems that don't have efi will both have problems,
<= div>since we can't get the efi variables we want. So do you puzzle out<= /div>
these, or ???

And finally, even if we kn= ow exactly what to upgrade and where, there's
several people = that have mirrored setups, exiter explicitly or implicitly.

<= /div>
So should a uefi-update handle some or all of these cases? With o= r without
explicit fallbacks? Should unmounted ESPs be mounted fo= r a minute to do
the update?

Maybe I'= ;m overthinking this, eh?

Warner

p.s. the uboot stuff was even more of a convoluted mess.
<= /div>
--00000000000095c2a8061ed37b54--