Date: Mon, 11 Jul 2022 09:50:11 -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: <2B2004D4-268C-446B-86B8-15AD12C152C9@yahoo.com> In-Reply-To: <CANCZdfp-UUSuLwY=mVZX6HgRTnk4V1v5d8NP6tsguMpaZ4U3Hw@mail.gmail.com> References: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com> <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net> <CANCZdfp-UUSuLwY=mVZX6HgRTnk4V1v5d8NP6tsguMpaZ4U3Hw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>> >=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
For reference:
# 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})
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.
=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?2B2004D4-268C-446B-86B8-15AD12C152C9>