Date: Mon, 11 Jul 2022 13:03:42 -0700 From: Mark Millard <marklmi@yahoo.com> To: 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> Subject: Re: Partition layout of ARM SD card images Message-ID: <491AC0F5-2A0F-402D-A503-6A9E34F20E1D@yahoo.com> In-Reply-To: <2B2004D4-268C-446B-86B8-15AD12C152C9@yahoo.com> References: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com> <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net> <CANCZdfp-UUSuLwY=mVZX6HgRTnk4V1v5d8NP6tsguMpaZ4U3Hw@mail.gmail.com> <2B2004D4-268C-446B-86B8-15AD12C152C9@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes =
<freebsd-rwg@gndrsh.dnsmgr.net> wrote:
>>>>=20
>>>> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> =
wrote:
>>>>=20
>>>>>> Am 10.07.2022 um 17:48 schrieb Mark Millard <marklmi@yahoo.com>:
>>>>>>=20
>>>>>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen =
<freebsd-rj@cyclaero.com> wrote:
>>>>>>=20
>>>>>>> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>>>>>>>=20
>>>>>>> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>>>>>>> # gpart show md0 md0s2
>>>>>>>=20
>>>>>>> =3D> 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)
>>>>>>>=20
>>>>>>> =3D> 0 6187041 md0s2 BSD (3.0G)
>>>>>>> 0 57 - free - (29K)
>>>>>>> 57 6186880 1 freebsd-ufs (2.9G)
>>>>>>> 6186937 104 - free - (52K)
>>>>>>>=20
>>>>>>> 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 =3D 104448, which as a matter of =
fact is 4k aligned (104448*512/4096 =3D 13056) and 1M aligned as well =
(104448*512/1024/1024 =3D 51), however all this keeps looking strange.
>>>>>>>=20
>>>>>>> Are there reasons for this partition layout besides making it =
look more interesting? If yes, some insights would be good.
>>>>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> # mdconfig -a -u 0 -t vnode -f =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
>>>>>> # gpart show md0
>>>>>> =3D> 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)
>>>>>=20
>>>>> This is a GPT table, while the others are still MBR. Images which =
come with u-boot must have a different layout.
>>>>=20
>>>> 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.
>>>>=20
>>>> No SBC that has a U-Boot/whatever needing more space
>>>> than is provided below is going to use the same
>>>> 2079 figure:
>>>>=20
>>>> =3D> 63 ??? md0 ??? (?)
>>>> 63 2016 - free - (1.0M)
>>>=20
>>> 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?
>>>=20
>>>> 2079 ?????? 1 fat32lba [active] (?)
>>>=20
>>> 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)=3D1985
>>=20
>> 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.
>>=20
>>> 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?
>>>=20
>> 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).
>>=20
>> I don't think the kernel has changed in this area in a very long =
time.
>> At worse, we're seeing a mkimage bug.
>>=20
>> Warner
>>=20
>>>=20
>>> MBR vs. GPT is not the fundamental issue for that.
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Rod Grimes =
rgrimes@freebsd.org
>>>=20
>>=20
>=20
> For reference:
>=20
> # grep -r MD_ARGS /usr/main-src/release/ | more
> /usr/main-src/release/arm/GENERICSD.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm/RPI-B.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/PINE64-LTS.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/PINE64.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/PINEBOOK.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/ROCK64.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/ROCKPRO64.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/RPI.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/riscv/GENERICSD.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/release.sh: mdconfig -f =
${IMGBASE##${CHROOTDIR}} ${MD_ARGS})
>=20
> where:
>=20
> -x sectors/track
> See the description of the -y option below.
>=20
> -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
=3D> 63 6291393 md0 MBR (3.0G)
63 6291393 - free - (3.0G)
# gpart add -t'!12' -a512k -s50m -b1m md0
md0s1 added
# gpart show md0
=3D> 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
=3D> 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
=3D> 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?)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?491AC0F5-2A0F-402D-A503-6A9E34F20E1D>