From nobody Wed May 14 02:24:26 2025 X-Original-To: freebsd-embedded@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 4Zxxxh3g8Rz5vtQd for ; Wed, 14 May 2025 02:24:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 4Zxxxh00HHz3MB0 for ; Wed, 14 May 2025 02:24:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-7423fb98cb1so4582999b3a.3 for ; Tue, 13 May 2025 19:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1747189478; x=1747794278; 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=akHdgTQoCG7Ht8dGHvl+od54QwIZeDgu3dmwjdBB2ds=; b=gRvrKZZyLjlZDda/dqORoEiRd3QL0bEMiOIi6z05Ms/0J17FzHfRW+SOIZ3XEv0TNe hUICHk3ABTHxf9Xt+8LXJrlqEHQfjUJHXzmXzwoQxJdb06S40RzzW7jVyIma7B/+jjru Djcu6V1SHLmuHczfEZrzJDuDmuXCjTmp+4bb6tilVFEzB7TALao4GUEZ77M6RKyGpAF0 X/mgO+9jy23zV+sTtSjBuCGsmgxoMPKfuEH3Vkq2yXa5wG8+jrgDQcQIQrb1xBxHFwQ6 6DYa4j7zGKWxteYO54cec+u3AlFiAobsQtNJ+71Wb+0+3oSc9a62hrEzkSMXbNTtAtZD hiqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747189478; x=1747794278; 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=akHdgTQoCG7Ht8dGHvl+od54QwIZeDgu3dmwjdBB2ds=; b=hk25iJgav1uua/TQTMgVpfNtKYzQ3FE3HIl5ZlbQSg/AxBjiFNkZfB2+vr+brFhVNa X8TWbptu8YfGLVfG60Ea+vhdWLkZRHXaDWG5yQkgFOT6Ji5CumHR+b4kthkAQujNhdpw QFP0plOuW21ZzScLeuGjvpnAjyGGWhd8fcjTSz1zXfOcdVIG53HkSe5+yTACyoMD7W04 VE6rLb25htpS3oH+RBHRQUKcIxpnrjqsjld4Ye/tJM4MN+/F8WS41uMf3g9tLGIPRXgx szkHsyarZfZfY0DMKidfNYoT/hy1wl1kRi4sHawV/Uo1023xLf1SfzrO9BL4y+wuoZxG 5qNA== X-Gm-Message-State: AOJu0Ywni8GiFOUVvwtMZRzN7soMPPhqoBfuPkBLXAx/kHxNz5k5WWrc M+QezSL2pnAG9rNzSjJbcOaaiJ5SlZ5zftJpC+AznD6fSjxtt98lZFcW2W3TC6NRTgI6LjotGVD W39pvXgX33tz5UVWhaox0D/IyEGWzp5XAsl5fxoGlrBWVRYlh8+8= X-Gm-Gg: ASbGnct/y2jnoJ86zSHh2/4BLtGl6Aj9/c3K8lGw3aAfoZsIhctaLZK2PDjSUoHjfMS rykdkrELLzKqHlwNfKN8sf30zM2GEZYyp4SXXm+48oRPrYRTCNuqCLIZyoJXoKOsBV178wV+Pzq YN/M2TOWV1IPgxKR0PSMXQ/H/0ZxBkpLjXL/EeINpW8DLBRJyF0JVdnhPZU5qttFo= X-Google-Smtp-Source: AGHT+IFF2wu0+BGE5xRB7kRLnVCBzJUFoucn54xwWujRmy539W+J/EzY99+LxO3z+K00oiOC1ss6Rh8BtFash0qNny0= X-Received: by 2002:a05:6a21:62c2:b0:1fe:6bbf:af22 with SMTP id adf61e73a8af0-215ff0858b4mr2228760637.1.1747189478371; Tue, 13 May 2025 19:24:38 -0700 (PDT) List-Id: Dedicated and Embedded Systems List-Archive: https://lists.freebsd.org/archives/freebsd-embedded List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-embedded@FreeBSD.org MIME-Version: 1.0 References: <5887b3f9-8820-47fb-8d26-94e184cdafeb@denninger.net> In-Reply-To: <5887b3f9-8820-47fb-8d26-94e184cdafeb@denninger.net> From: Warner Losh Date: Tue, 13 May 2025 20:24:26 -0600 X-Gm-Features: AX0GCFvSsB6X05q4SZLfuVhmfeuggPAjpBofpWZBZhVw94HLiT3flzySEIbLTgQ Message-ID: Subject: Re: Where/how to submit proposed patches to Nanobsd provided files? To: Karl Denninger Cc: freebsd-embedded Content-Type: multipart/alternative; boundary="00000000000036cc6906350f40f3" X-Rspamd-Queue-Id: 4Zxxxh00HHz3MB0 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-Spamd-Bar: ---- --00000000000036cc6906350f40f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 13, 2025, 7:40=E2=80=AFAM Karl Denninger w= rote: > I've put some time in on the "Nanobsd" build process files that do a few > things: > > 1. Support efi dual-boot mode (EFI or not) while keeping an MBR partition > layout so older devices can still boot the media and also keep the data > partition. Basically, set up Partition 4 as an extended "BSD" partition > with "a" (cfg) and "d" (data, if non-zero size) so they both work. This > involved essentially a rewrite of the "legacy" file entirely since the > partition creation was done through awk basically emitting a script it th= en > executed; it was much easier to, due to the different types involved, jus= t > do "nah", make a calculation for the code segments, subtract off space fo= r > the EFI partition and cfg area and then use what's left for data. > This has already been rewritten to not use the awk script, I thought. Though maybe just for gpt since very few systems actually require mbr. > 2. Put the EFI partition in slot 3 thus the "dual image, online update" > capacity is unperturbed. Place the loader in > EFI/BOOT/{architecture-specific-name} as defined in the config file. Thi= s > is harmless if the machine is CSM boot but if its EFI it will find it and > boot using it. > This is good. > 3. Update the "updatepx" files distributed to look for an EFI partition o= n > the NanoBSD device and, if found, set loader.env which should then cause > the EFI loader to use the correct load partition since the "active" flag = is > ignored otherwise. > Efibootmgr is the new way. When it works, its the most reliable. There's also a gptboot.efi if you want an on media thing that doesn't ignore the FreeBSD specific hack/partition flag. > Should I put these up somewhere for possible review and inclusion? I use > this to build bootable sticks or SD cards for firewall appliances that ru= n > "read-only" and thus are power-fail safe, and have tested against both a > commodity EFI-boot-only dual-NIC "NUC" style PC and also the older > pcEngines apu2 series. > Yea. I've been busy for a while, but am starting to have time again. I think i replied to submit a github pull request. I notice those. Anything else is a huge crap shoot since bz has a terrible code review interface (and I have too many bugs assigned to me anyway) and phabricator is terrible for non-committers since there's no oversight. We're getting better at bugzilla at least. But I am planning a github run next week online on Discord so if you have it submitted by Saturday it will be in for sure for that and I might be able to do a review before it even. Warner --=20 > Karl Denninger > karl@denninger.net > *The Market Ticker* > *[S/MIME encrypted email preferred]* > --00000000000036cc6906350f40f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 13, 2025, 7:40=E2=80= =AFAM Karl Denninger <karl@denning= er.net> wrote:
=20 =20 =20

I've put some time in on the "Nanobsd" build process f= iles that do a few things:

1. Support efi dual-boot mode (EFI or not) while keeping an MBR partition layout so older devices can still boot the media and also keep the data partition.=C2=A0 Basically, set up Partition 4 as = an extended "BSD" partition with "a" (cfg) and "= ;d" (data, if non-zero size) so they both work.=C2=A0 This involved essentially a rewrite of the "legacy" file entirely since the partition creation was= done through awk basically emitting a script it then executed; it was much easier to, due to the different types involved, just do "nah", make a calculation for the code segments, subtract o= ff space for the EFI partition and cfg area and then use what's left for data.

This ha= s already been rewritten to not use the awk script, I thought. Though maybe= just for gpt since very few systems actually require mbr.

=

2. Put the EFI partition in slot 3 thus the "dual image, online update" capacity is unperturbed.=C2=A0 Place the loader in EFI/BOOT/{architecture-specific-name} as defined in the config file.=C2=A0 This is harmless if the machine is CSM boot but if its EF= I it will find it and boot using it.

=

This is good.

3. Update the "updatepx" files distributed to look for an = EFI partition on the NanoBSD device and, if found, set loader.env which should then cause the EFI loader to use the correct load partition since the "active" flag is ignored otherwise.

=
Efibootmgr is the new way.= When it works, its the most reliable.

There's also a gptboot.efi if you want an on media thing= that doesn't ignore the FreeBSD specific hack/partition flag.

Should I put these up somewhere for possible review and inclusion?=C2=A0 I use this to build bootable sticks or SD cards for firewall appliances that run "read-only" and thus are power= -fail safe, and have tested against both a commodity EFI-boot-only dual-NIC "NUC" style PC and also the older pcEngines apu2 s= eries.

Yea. I'v= e been busy for a while, but am starting to have time again. I think i repl= ied to submit a github pull request. I notice those. Anything else is a hug= e crap shoot since bz has a terrible code review interface (and I have too = many bugs assigned to me anyway) and phabricator is terrible for non-commit= ters since there's no oversight. We're getting better at bugzilla a= t least.

But I am planni= ng a github run next week online on Discord so if you have it submitted by = Saturday it will be in for sure for that and I might be able to do a review= before it even.

Warner<= /div>


--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--00000000000036cc6906350f40f3--