From nobody Sat Aug 03 14:47:54 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 4Wbltc4thGz5SYT6 for ; Sat, 03 Aug 2024 14:48:08 +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 4Wbltc2CWQz4K34 for ; Sat, 3 Aug 2024 14:48:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2cd5e3c27c5so6364799a91.3 for ; Sat, 03 Aug 2024 07:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1722696487; x=1723301287; 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=kUcYwJCzWbiaCXcPWF1b+ADCSobDSzkOky1OOIDlH6E=; b=IT1Napmw1QB36OvjgokYp7eN9gOq82G/pzRJGANj1vOJYGr5PitPYJPnZorkBBOIM3 64wkpqKA4qlZwGlTjQXT9s/bsDMAioRLBzUXDFNhhsia4TqNWbXzYhmqr4bK1FlQXGQj yyyBJvKL2frEPuRbr8Yi0tTrHO3nvPYpVmumAsbncL6lkqfM3lp0wWWWPCgd37vAs3k+ dQXRH8lKGljwgvySlMlryfDXFJMv/cu+eKH+wH3DGB+wyxD55TBRTXxcwoCPOz3ZjLxQ 7K+frQdKiN7wv20ZB5eWDight40ze+PYHkV5AuLgnfp+sxL3jxHX+WaEZbBnyZK97MhT 1kqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722696487; x=1723301287; 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=kUcYwJCzWbiaCXcPWF1b+ADCSobDSzkOky1OOIDlH6E=; b=eaWAYi7hWsu6nRDcfwlYLHDXfnkh2TK5wauZml0ma2bLQqT2wDKh3g28ekQAU00tHM hnySK+mppAb9f3dDAHA3zxCPXebGnNV3EvkyH2Zb6QRDmOfuFkImZf0/RQI116s38bOK ssZi9aaRBYpaQElCJSr+4qfPme7Ndi4VGcFt7d2zhKMrzVKNl8pSU490qSear4g5UK9R 6AG9B+uVi6EYaftQIwIMLJD6AmsJwbOUH9PEBLIqi/oAN9OitiSn0cTySyHemWH9D9sU FNfFh34EtNFkXQ+wTH3wp/lrqYht5VQuREP8AFW6gg/+861Zi3CV6mHszV0l18N1A/AR gQcg== X-Forwarded-Encrypted: i=1; AJvYcCUBrETkSov0Dh3VFavS/0DN3psnKmwi/YiiLQvGbz6VN69rBXs1+D0biECjF+HBOs0Fs7QbqHXr1NrJ7NC4pkIvPXBEjfW49A== X-Gm-Message-State: AOJu0YxSIi/uwNc8/bWGEZidsSWU3nt5FoLit+QB/36PwGcM+sGTCd7s eZlUOseB9+uAQEUNrkD5stnSiAdxYjQEp03rxvwgK1o21lpzhycGgaZVqMrW2xbbb7RSbZL+0v7 poWvkZBscj0nk/0unXKVc8q5F84FucJVD9ysCM18vDmguG1cH X-Google-Smtp-Source: AGHT+IGNE1GzB9VNxxVZjSnOmfGmqzWULykpyoui/HF5zC54cnHtHyeOqz/fKk/HFs7WyaFgmES2NRWur3NxcIb7d0g= X-Received: by 2002:a17:90a:6d66:b0:2c9:9b16:e004 with SMTP id 98e67ed59e1d1-2cff9566a90mr6828871a91.43.1722696486705; Sat, 03 Aug 2024 07:48:06 -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 08:47:54 -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="000000000000257371061ec88841" 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: 4Wbltc2CWQz4K34 --000000000000257371061ec88841 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 3, 2024, 8:28=E2=80=AFAM bob prohaska wrot= e: > On Fri, Aug 02, 2024 at 11:08:36PM -0700, Mark Millard wrote: > > > > > > On Aug 2, 2024, at 21:59, bob prohaska wrote: > > > > > On Fri, Aug 02, 2024 at 09:02:46PM -0700, Mark Millard wrote: > > >> On Aug 2, 2024, at 19:19, bob prohaska wrote: > > >> > > >>> After a build/install of -current on a Raspberry Pi 2 (so, armv7) > the > > >>> console output reported: > > >>> > > >>> > ********************************************************************** > > >>> > ********************************************************************** > > >>> ***** > ***** > > >>> ***** BOOT LOADER IS TOO OLD. PLEASE UPGRADE. > ***** > > >>> ***** > ***** > > >>> > ********************************************************************** > > >>> > ********************************************************************** > > >>> > > >>> The statement is likely true, but it's a bit hard to guess exactly > > >>> what needs upgrading. The boot process succeeded. Is it wiser to > > >>> heed the command, or leave well enough alone? AFAIK there's no > > >>> firmware to upgrade on the Pi2. > > >> > > >> The message is about the likes of: > > >> > > >> RPi2 v1.1 (armv7)? /boot/efi/EFI/BOOT/bootarm.efi > > >> RPi2 v1.2 (aarch64)? /boot/efi/EFI/BOOT/bootaa64.efi > > >> > > >> Those are not RPi* firmware, nor armstub* , nor are they U-Boot. > > >> > > >> They are code from FreeBSD: FreeBSD UEFI loader code. So, yes, > > >> there is new code to update to. > > >> > > > Where can I find the newer version? Following buildworld/kernel > > > find / -name bootarm.efi > > > locates only > > > /boot/msdos/EFI/BOOT/bootarm.efi > > > which I imagine is the obsolete version. > > > > > > Apologies if this is naive, something suggests it might be.... > > > > Presuming a self-hosted build was done and was installed to > > update that system, the updates could be done via: > > > > > > On armv7 (RPi2 v1.1 --or RPi2 v1.2 used with an armv7 kernel/world): > > > > # cp /boot/loader.efi /boot/efi/EFI/BOOT/bootarm.efi > > In this case the path turns out to be > /boot/msdos/EFI/BOOT/bootarm.efi but the fix was otherwise trivial. > It was surprising to find the old file dated Jul 2 2020, I didn't > realize the machine has been up that long. > > > > > In other words, they are copies of the FreeBSD boot loader > > but under other path and naming conventions on the msdosfs > > that is involved. > > > > 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. > Except it's not. When FreeBSD first did UEFI support we did it in the half assiest way possible. We had a file that was a FAT that would get dd'd onto the ESP. So, this was never mounted. That is mistake #1. The boot loader could never grow. Nor change, really. Or get any new functionality. Oh, and it was a copy of the loader.efi, but without the scripting. It was a total mess that barely worked for UFS. So, there never was a standard place to mount it early on. Plus some people think having the ESP mointed was bad. So for years we argued about even whether or not to mount it. Plus, there are two places yhat loader.efi can go. One is in /efi/boot/bootXxx.efi. this is the place the BIOS looks for it on removable media. But is terrible for multiboot. So we implemented the efiboitmgr protocol and put it in /efi/freebsd/loader.efi. efibootmgr lets it be anywhere. Also, there are still systems that use boot1.efi which are impossible to change. So what do we update in installworld? How do we deal with all the cases needing some level dwim, but guessing about the boot loader is high stakes. It doesn't take too many wrong guesses to really frustrate and drive away a lot of users. 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. Warner Thank you very much! > > bob prohaska > > > --000000000000257371061ec88841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Aug 3, 2024, 8:28=E2=80=AFAM bob prohaska <= fbsd@www.zefox.net> wrote:
=
On Fri, Aug 02, 2024 at 11:08:36PM -07= 00, Mark Millard wrote:
>
>
> On Aug 2, 2024, at 21:59, bob prohaska <fbsd@www.zefox.net> = wrote:
>
> > On Fri, Aug 02, 2024 at 09:02:46PM -0700, Mark Millard wrote:
> >> On Aug 2, 2024, at 19:19, bob prohaska <fbsd@www.zefox.net= > wrote:
> >>
> >>> After a build/install of -current on a Raspberry Pi 2 (so= , armv7) the
> >>> console output reported:
> >>>
> >>> *********************************************************= *************
> >>> *********************************************************= *************
> >>> *****=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *****
> >>> *****=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BOOT LOADER= IS TOO OLD. PLEASE UPGRADE.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *****
> >>> *****=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *****
> >>> *********************************************************= *************
> >>> *********************************************************= *************
> >>>
> >>> The statement is likely true, but it's a bit hard to = guess exactly
> >>> what needs upgrading. The boot process succeeded. Is it w= iser to
> >>> heed the command, or leave well enough alone? AFAIK there= 's no
> >>> firmware to upgrade on the Pi2.
> >>
> >> The message is about the likes of:
> >>
> >> RPi2 v1.1 (armv7)?=C2=A0 =C2=A0/boot/efi/EFI/BOOT/bootarm.efi=
> >> RPi2 v1.2 (aarch64)? /boot/efi/EFI/BOOT/bootaa64.efi
> >>
> >> Those are not RPi* firmware, nor armstub* , nor are they U-Bo= ot.
> >>
> >> They are code from FreeBSD: FreeBSD UEFI loader code. So, yes= ,
> >> there is new code to update to.
> >>
> > Where can I find the newer version?=C2=A0 Following buildworld/ke= rnel
> > find / -name bootarm.efi
> > locates only
> > /boot/msdos/EFI/BOOT/bootarm.efi
> > which I imagine is the obsolete version.
> >
> > Apologies if this is naive, something suggests it might be.... >
> Presuming a self-hosted build was done and was installed to
> update that system, the updates could be done via:
>
>
> On armv7 (RPi2 v1.1 --or RPi2 v1.2 used with an armv7 kernel/world): >
> # cp /boot/loader.efi /boot/efi/EFI/BOOT/bootarm.efi

In this case the path turns out to be
/boot/msdos/EFI/BOOT/bootarm.efi but the fix was otherwise trivial.
It was surprising to find the old file dated Jul 2 2020, I didn't
realize the machine has been up that long.

>
> In other words, they are copies of the FreeBSD boot loader
> but under other path and naming conventions on the msdosfs
> that is involved.
>

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.
Except it's not.

When FreeBSD first did UEFI support we did it in the = half assiest way possible. We had a file that was a FAT that would get dd&#= 39;d onto the ESP. So, this was never mounted. That is mistake #1. The boot= loader could never grow. Nor change, really. Or get any new functionality.= Oh, and it was a copy of the loader.efi, but without the scripting. It was= a total mess that barely worked for UFS.

=
So, there never was a standard place to mount it early on= . Plus some people think having the ESP mointed was bad. So for years we ar= gued about even whether or not to mount it.

Plus, there are two places yhat loader.efi can go. One = is in /efi/boot/bootXxx.efi. this is the place the BIOS looks for it on rem= ovable media. But is terrible for multiboot. So we implemented the efiboitm= gr protocol and put it in /efi/freebsd/loader.efi. efibootmgr lets it be an= ywhere.

Also, there are = still systems that use boot1.efi which are impossible to change.

So what do we update in installwor= ld? How do we deal with all the cases needing some level dwim, but guessing= about the boot loader is high stakes. It doesn't take too many wrong g= uesses to really frustrate and drive away a lot of users.

I have the doodle of a design to have a m= ake 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.

Warner
Thank you very much!

bob prohaska


--000000000000257371061ec88841--