From nobody Tue Jul 12 08:05:21 2022 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 9DF1C17FC32D for ; Tue, 12 Jul 2022 08:05:29 +0000 (UTC) (envelope-from SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LhtbX3LLdz3Gnc for ; Tue, 12 Jul 2022 08:05:28 +0000 (UTC) (envelope-from SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl) Date: Tue, 12 Jul 2022 10:05:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1657613121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=IVoL1hcvMHg+nAV8iS5QGaqbe4mvR2oddwSUWbLM34Y=; b=bR/N7cTSq5AK96wkwABUgj5m6AVoPzwBwHabFJj6YA2jaeGrY60TxDzckTBhZ0xamAdgGx 9kiscJxBJ5jSpg7yS4BYWOJpmsYJw6A9sIhffsVmz5AK1O9BanRsf3+/ZOFoHDWUIddxMY pENDqXQCrPsRxljKQ5s0q1mPjHsWRCFsN2SP8M30szIzL2FiFo2affXynpwUE72qhIJXAt S45ALAZ64W5Q5+PvArDUFMKkgcgUg6ookpc6CxYXDqX51nmOG8olwFmrK/EFz5ma7wES/3 HIs7DL3JfqZZQl1NxWJ2UtdMVHclhSsmj3ZLCwo+HuXCs92pHeVXXb0QRT+Yng== From: Ronald Klop To: Mark Millard , Warner Losh , "Rodney W. Grimes" , "Dr. Rolf Jansen" , freebsd-arm Message-ID: <1169617916.2919.1657613121111@localhost> In-Reply-To: <491AC0F5-2A0F-402D-A503-6A9E34F20E1D@yahoo.com> Subject: Re: Partition layout of ARM SD card images 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 Content-Type: multipart/alternative; boundary="----=_Part_2918_2130341816.1657613121106" X-Mailer: Realworks (614.98.9856e01) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4LhtbX3LLdz3Gnc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b="bR/N7cTS"; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com,bsdimp.com,gndrsh.dnsmgr.net,cyclaero.com,freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; FROM_HAS_DN(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_2918_2130341816.1657613121106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Mark Millard Datum: 11 juli 2022 22:04 Aan: Warner Losh CC: "Rodney W. Grimes" , "Dr. Rolf Jansen" , freebsd-arm Onderwerp: Re: Partition layout of ARM SD card images > > > On 2022-Jul-11, at 09:50, Mark Millard wrote: > > > On 2022-Jul-11, at 07:38, Warner Losh wrote: > > > >> On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes wrote: > >>>> > >>>> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen wrote: > >>>> > >>>>>> Am 10.07.2022 um 17:48 schrieb Mark Millard : > >>>>>> > >>>>>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen wrote: > >>>>>> > >>>>>>> For example let's have a llok on the partition layout of, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar): > >>>>>>> > >>>>>>> # mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img > >>>>>>> # gpart show md0 md0s2 > >>>>>>> > >>>>>>> => 63 6291393 md0 MBR (3.0G) > >>>>>>> 63 2016 - free - (1.0M) > >>>>>>> 2079 102312 1 fat32lba [active] (50M) > >>>>>>> 104391 6187041 2 freebsd (3.0G) > >>>>>>> 6291432 24 - free - (12K) > >>>>>>> > >>>>>>> => 0 6187041 md0s2 BSD (3.0G) > >>>>>>> 0 57 - free - (29K) > >>>>>>> 57 6186880 1 freebsd-ufs (2.9G) > >>>>>>> 6186937 104 - free - (52K) > >>>>>>> > >>>>>>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange. > >>>>>>> > >>>>>>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good. > >>>>>> > >>>>>> The layout details are more specific to the aarch64 RPi* context > >>>>>> than to general aarch64 SD card images. For example, the Rock64 > >>>>>> image is different: > >>>>>> > >>>>>> # mdconfig -a -u 0 -t vnode -f FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img > >>>>>> # gpart show md0 > >>>>>> => 40 6291376 md0 GPT (3.0G) > >>>>>> 40 32728 - free - (16M) > >>>>>> 32768 102400 1 efi (50M) > >>>>>> 135168 6156160 2 freebsd-ufs (2.9G) > >>>>>> 6291328 88 - free - (44K) > >>>>> > >>>>> This is a GPT table, while the others are still MBR. Images which come with u-boot must have a different layout. > >>>> > >>>> I know it is a GPT table. That is part of the point about > >>>> the variety of contexts that there are across the Small > >>>> Board Computers. > >>>> > >>>> No SBC that has a U-Boot/whatever needing more space > >>>> than is provided below is going to use the same > >>>> 2079 figure: > >>>> > >>>> => 63 ??? md0 ??? (?) > >>>> 63 2016 - free - (1.0M) > >>> > >>> I read this thread.. and it keeps nagging me in > >>> the back of the head, I know this 2016 number. > >>> It is common when the sectors per track of a > >>> drive is reported as "32", its an attempt to > >>> 1M align such a drive, is somehow the image > >>> creation code picking up 32 to do the align > >>> calculation wrongly on a 63 sector/track > >>> image? > >>> > >>>> 2079 ?????? 1 fat32lba [active] (?) > >>> > >>> The OP is correct, this is a horrid state of alignment > >>> and the cause should be tracked down and fixed! I > >>> can see no valid reason to have an approx > >>> 1MB free hole that causes this missalignment, > >>> that free hole should be (2048-63)=1985 > >> > >> Yes, we should be aligning at a 1M or 2M boundary on the > >> root device, not within the partition. The offsets are supposed > >> to do that, and if there's a problem we should fix it. > >> > >>> AHhhhh thought hits me... did the code get changed > >>> to make the images larger, and somehow the image > >>> creation code went from a 32 sector/track fake C/H/S > >>> to a 63 sector fake C/H/S, and the code has all > >>> along been assuming 32 sector/track drives? > >>> > >> 63 sector for 'fake' C/H/S has been a thing since at least > >> FreeBSD 6 and maybe a little longer. There's no cutover > >> based on image size of the device. The older ATA code, > >> pre-cam but post SOS rewrite, would try very hard to return > >> the values from the underlying device that it reported. And that > >> would lead to mismatches because it was different than the lies > >> that md told by default. But that only mattered for really old > >> BIOSes that couldn't handle LBA/packet mode in booting (which > >> is the primary reason the old fdisk program could set the ending CHS > >> of partitions since the FreeBSD code used that to guess the CHS > >> of the drive itself in the absence of other information). > >> > >> I don't think the kernel has changed in this area in a very long time. > >> At worse, we're seeing a mkimage bug. > >> > >> Warner > >> > >>> > >>> MBR vs. GPT is not the fundamental issue for that. > >>> > >>> === > >>> Mark Millard > >>> marklmi at yahoo.com > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Rod Grimes rgrimes@freebsd.org > >>> > >> > > > > For reference: > > > > # grep -r MD_ARGS /usr/main-src/release/ | more > > /usr/main-src/release/arm/GENERICSD.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/arm/RPI-B.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/arm64/PINE64-LTS.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/arm64/PINE64.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/arm64/PINEBOOK.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/arm64/ROCK64.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/arm64/ROCKPRO64.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/arm64/RPI.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/riscv/GENERICSD.conf:MD_ARGS="-x 63 -y 255" > > /usr/main-src/release/release.sh: mdconfig -f ${IMGBASE##${CHROOTDIR}} ${MD_ARGS}) > > > > where: > > > > -x sectors/track > > See the description of the -y option below. > > > > -y heads/cylinder > > For malloc or vnode backed devices, the -x and -y options can be > > used to specify a synthetic geometry. This is useful for > > constructing bootable images for later download to other devices. > > I'm failing to reproduce the problem when I > try my own commands on: > > # uname -apKU # manual line split > FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40 > stable/13-n251684-815db559eccc-dirty: Sat Jul 9 14:02:23 PDT 2022 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1301505 1301505 > > I tried what it looks to me the /usr/src/release/ > code would do initially for arm64/RPI.conf (but with > my file naming and an explicit -u0 style of use): > > # truncate -s3072m mmjnk.test > # mdconfig -u0 -fmmjnk.test -x63 -y255 > # gpart create -sMBR md0 > md0 created > # gpart show md0 > => 63 6291393 md0 MBR (3.0G) > 63 6291393 - free - (3.0G) > # gpart add -t'!12' -a512k -s50m -b1m md0 > md0s1 added > # gpart show md0 > => 63 6291393 md0 MBR (3.0G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba (50M) > 104448 6187008 - free - (3.0G) > > I tried the same sequence in a chroot into a 13.0-RELEASE-p11 > tree on an aarch64 main [so: 14] machine. I got the same result. > > But such is not what the 13.1-RELEASE build produced, for > example: > > # mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img -x63 -y255 > # gpart show md0 > => 63 6291393 md0 MBR (3.0G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba [active] (50M) > 104391 6187041 2 freebsd (3.0G) > 6291432 24 - free - (12K) > > (There are no 13.1-STABLE snapshots available to download > and look at.) > > Looking at the recent 14.0-CURRENT snapshot: > > # mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img -x63 -y255 > # gpart show md0 > => 63 6291393 md0 MBR (3.0G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba [active] (50M) > 104391 6187041 2 freebsd (3.0G) > 6291432 24 - free - (12K) > > So, also not matching. > > Is there something odd about the environment for official > snapshot/release builds that leads to getting a different > result? Possible lack of use of some of the modern > /usr/src/release/ material to build the images? Some issue > associated with amd64 -> aarch64 (or armv7 / armv6 / . . .) > cross builds? > > > > I've always thought that it was too bad that the build logs > for release and snapshot builds were not publicly available. > Multiple times I've wished I could see what a build failure > or other oddity looked like in the snapshot build logs in > order to see if I could track down part of what was leading > to the failure(s)/oddities. (I may presume that there is more > log output than is actually set up?) > > === > Mark Millard > marklmi at yahoo.com > > > > > > It seems the image builder of aarch64 13-stable is disabled. https://ci.freebsd.org/job/FreeBSD-stable-13-aarch64-images/ Other architectures are enabled. Regards, Ronald ------=_Part_2918_2130341816.1657613121106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Mark Millard <marklmi@yahoo.com>
Datum: 11 juli 2022 22:04
Aan: Warner Losh <imp@bsdimp.com>
CC: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com>, freebsd-arm <freebsd-arm@freebsd.org>
Onderwerp: Re: Partition layout of ARM SD card images

On 2022-Jul-11, at 09:50, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Jul-11, at 07:38, Warner Losh <imp@bsdimp.com> wrote:
>
>> On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
>>>>
>>>> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> wrote:
>>>>
>>>>>> Am 10.07.2022 um 17:48 schrieb Mark Millard <marklmi@yahoo.com>:
>>>>>>
>>>>>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> wrote:
>>>>>>
>>>>>>> For example let's have a llok on the partition layout of, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>>>>>>>
>>>>>>> # mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>>>>>>> # gpart show md0 md0s2
>>>>>>>
>>>>>>> =>     63  6291393  md0  MBR  (3.0G)
>>>>>>>       63     2016       - free -  (1.0M)
>>>>>>>     2079   102312    1  fat32lba  [active]  (50M)
>>>>>>>   104391  6187041    2  freebsd  (3.0G)
>>>>>>>  6291432       24       - free -  (12K)
>>>>>>>
>>>>>>> =>      0  6187041  md0s2  BSD  (3.0G)
>>>>>>>        0       57         - free -  (29K)
>>>>>>>       57  6186880      1  freebsd-ufs  (2.9G)
>>>>>>>  6186937      104         - free -  (52K)
>>>>>>>
>>>>>>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.
>>>>>>>
>>>>>>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.
>>>>>>
>>>>>> The layout details are more specific to the aarch64 RPi* context
>>>>>> than to general aarch64 SD card images. For example, the Rock64
>>>>>> image is different:
>>>>>>
>>>>>> # mdconfig -a -u 0 -t vnode -f  FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
>>>>>> # gpart show md0
>>>>>> =>     40  6291376  md0  GPT  (3.0G)
>>>>>>     40    32728       - free -  (16M)
>>>>>>  32768   102400    1  efi  (50M)
>>>>>> 135168  6156160    2  freebsd-ufs  (2.9G)
>>>>>> 6291328       88       - free -  (44K)
>>>>>
>>>>> This is a GPT table, while the others are still MBR. Images which come with u-boot must have a different layout.
>>>>
>>>> I know it is a GPT table. That is part of the point about
>>>> the variety of contexts that there are across the Small
>>>> Board Computers.
>>>>
>>>> No SBC that has a U-Boot/whatever needing more space
>>>> than is provided below is going to use the same
>>>> 2079 figure:
>>>>
>>>> =>     63  ???  md0  ???  (?)
>>>>       63     2016       - free -  (1.0M)
>>>
>>> I read this thread.. and it keeps nagging me in
>>> the back of the head, I know this 2016 number.
>>> It is common when the sectors per track of a
>>> drive is reported as "32", its an attempt to
>>> 1M align such a drive, is somehow the image
>>> creation code picking up 32 to do the align
>>> calculation wrongly on a 63 sector/track
>>> image?
>>>
>>>>     2079   ??????    1  fat32lba  [active]  (?)
>>>
>>> The OP is correct, this is a horrid state of alignment
>>> and the cause should be tracked down and fixed!  I
>>> can see no valid reason to have an approx
>>> 1MB free hole that causes this missalignment,
>>> that free hole should be (2048-63)=1985
>>
>> Yes, we should be aligning at a 1M or 2M boundary on the
>> root device, not within the partition. The offsets are supposed
>> to do that, and if there's a problem we should fix it.
>>
>>> AHhhhh thought hits me... did the code get changed
>>> to make the images larger, and somehow the image
>>> creation code went from a 32 sector/track fake C/H/S
>>> to a 63 sector fake C/H/S, and the code has all
>>> along been assuming 32 sector/track drives?
>>>
>> 63 sector for 'fake' C/H/S has been a thing since at least
>> FreeBSD 6 and maybe a little longer. There's no cutover
>> based on image size of the device. The older ATA code,
>> pre-cam but post SOS rewrite, would try very hard to return
>> the values from the underlying device that it reported. And that
>> would lead to mismatches because it was different than the lies
>> that md told by default. But that only mattered for really old
>> BIOSes that couldn't handle LBA/packet mode in booting (which
>> is the primary reason the old fdisk program could set the ending CHS
>> of partitions since the FreeBSD code used that to guess the CHS
>> of the drive itself in the absence of other information).
>>
>> I don't think the kernel has changed in this area in a very long time.
>> At worse, we're seeing a mkimage bug.
>>
>> Warner
>>
>>>
>>> MBR vs. GPT is not the fundamental issue for that.
>>>
>>> ===
>>> Mark Millard
>>> marklmi at yahoo.com
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Rod Grimes                                                 rgrimes@freebsd.org
>>>
>>
>
> For reference:
>
> # grep -r MD_ARGS /usr/main-src/release/ | more
> /usr/main-src/release/arm/GENERICSD.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/arm/RPI-B.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/arm64/PINE64-LTS.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/arm64/PINE64.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/arm64/PINEBOOK.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/arm64/ROCK64.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/arm64/ROCKPRO64.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/arm64/RPI.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/riscv/GENERICSD.conf:MD_ARGS="-x 63 -y 255"
> /usr/main-src/release/release.sh:               mdconfig -f ${IMGBASE##${CHROOTDIR}} ${MD_ARGS})
>
> where:
>
>     -x sectors/track
>             See the description of the -y option below.
>
>     -y heads/cylinder
>             For malloc or vnode backed devices, the -x and -y options can be
>             used to specify a synthetic geometry.  This is useful for
>             constructing bootable images for later download to other devices.

I'm failing to reproduce the problem when I
try my own commands on:

# uname -apKU # manual line split
FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40
stable/13-n251684-815db559eccc-dirty: Sat Jul  9 14:02:23 PDT 2022
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1301505 1301505

I tried what it looks to me the /usr/src/release/
code would do initially for arm64/RPI.conf (but with
my file naming and an explicit -u0 style of use):

# truncate -s3072m mmjnk.test
# mdconfig -u0 -fmmjnk.test -x63 -y255
# gpart create -sMBR md0
md0 created
# gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
       63  6291393       - free -  (3.0G)
# gpart add -t'!12' -a512k -s50m -b1m md0
md0s1 added
# gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
       63     1985       - free -  (993K)
     2048   102400    1  fat32lba  (50M)
   104448  6187008       - free -  (3.0G)

I tried the same sequence in a chroot into a 13.0-RELEASE-p11
tree on an aarch64 main [so: 14] machine. I got the same result.

But such is not what the 13.1-RELEASE build produced, for
example:

# mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img -x63 -y255
# gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
       63     2016       - free -  (1.0M)
     2079   102312    1  fat32lba  [active]  (50M)
   104391  6187041    2  freebsd  (3.0G)
  6291432       24       - free -  (12K)

(There are no 13.1-STABLE snapshots available to download
and look at.)

Looking at the recent 14.0-CURRENT snapshot:

# mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img -x63 -y255
# gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
       63     2016       - free -  (1.0M)
     2079   102312    1  fat32lba  [active]  (50M)
   104391  6187041    2  freebsd  (3.0G)
  6291432       24       - free -  (12K)

So, also not matching.

Is there something odd about the environment for official
snapshot/release builds that leads to getting a different
result? Possible lack of use of some of the modern
/usr/src/release/ material to build the images? Some issue
associated with amd64 -> aarch64 (or armv7 / armv6 / . . .)
cross builds?



I've always thought that it was too bad that the build logs
for release and snapshot builds were not publicly available.
Multiple times I've wished I could see what a build failure
or other oddity looked like in the snapshot build logs in
order to see if I could track down part of what was leading
to the failure(s)/oddities. (I may presume that there is more
log output than is actually set up?)

===
Mark Millard
marklmi at yahoo.com




It seems the image builder of aarch64 13-stable is disabled. 
Other architectures are enabled. 

Regards,
Ronald

------=_Part_2918_2130341816.1657613121106--