From nobody Mon Jul 11 14:38:33 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 55DEB1D0FC75 for ; Mon, 11 Jul 2022 14:38:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LhRMn73mYz422B for ; Mon, 11 Jul 2022 14:38:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x931.google.com with SMTP id s7so439277uao.4 for ; Mon, 11 Jul 2022 07:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LH+/W2POoOaJ/ofqV5a+uAMocJthirOl6TDLNxpBzn0=; b=rI2m5QdeLzxY0iZYeBRaqUhbUH1Z6qBNY0qJuyQhZYpncskYnakM8aMHizoVn5d0P3 iLTryZ/e5xhmYrkEiYyD6+Kl9A7SF0QvDPXQBiJ9rbldIznmFHQ93kfIOXUjdOpZnjAU 2PUaXxM3NdXmb7n0dReTEXv6Z36fWKGbsZxf1tEr1MiO4OazvzuJ550HnShAo7j9iY/0 FOFwBzhBBx+UxGDTca1qobec3enr9zGw2WPztjbQrjDvRWtUjdcGz029ArMe4bqHHz3E 34cOeoiKWzof9wSy4AgkdwJ9gJei4m2PUPMZDIMAJpk20EC/gGiu/pu0kenDuX34kMPo Indw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LH+/W2POoOaJ/ofqV5a+uAMocJthirOl6TDLNxpBzn0=; b=7ETki/IPkwASM3Sfv8R+qdrEFI4ojcoJyOsuK0hlChLZKW6iUHpf6ZcwB1vBm3bmCn TYSSPE4WcdRZuE0f0CASYafJ8at4nvsGALvTpNVYeK4UO2+r+wDB1dFNOgBLqpI/Cbde niaqt2dwJ+bmveim/9Je9zJmjVbRPucKusQfnLT49X1fK7mWMu9dG/zH4CW/raFoW6hN GtaeKKUEZHlkmC3ywCIA0w2vYEr9Zy6dUYzeyX0+jm7B93u1bODD/EV4EbgLBg+f/RkI 2QZD4mCLotePST37APT376Oz5eoMIZjvs/xmdAL2iFo911kFbQPlLjQJ8onarBwqSXiC HT4w== X-Gm-Message-State: AJIora8lhIj9LMclAgZ7w0OLWTkRFgGfPTWW5zsI7GsyGI0OX3lzjvSt okVbUfkJgjFcZm9K26qLO+SmAOiCnAGKi21df+fYiQCxYbY= X-Google-Smtp-Source: AGRyM1tZIy1oqAuDLsV7RXONAybT5meX8zWpjZhAxi1NXnEYr9dOpqiLojZg77T2FEFeSAX9YPSfzu/cYBdk8emS6o4= X-Received: by 2002:ab0:2a06:0:b0:379:96c7:bf4f with SMTP id o6-20020ab02a06000000b0037996c7bf4fmr5731773uar.8.1657550324576; Mon, 11 Jul 2022 07:38:44 -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: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com> <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net> In-Reply-To: <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 11 Jul 2022 08:38:33 -0600 Message-ID: Subject: Re: Partition layout of ARM SD card images To: "Rodney W. Grimes" Cc: Mark Millard , "Dr. Rolf Jansen" , freebsd-arm Content-Type: multipart/alternative; boundary="0000000000004b4a7c05e388827f" X-Rspamd-Queue-Id: 4LhRMn73mYz422B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=rI2m5Qde; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::931) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from]; MLMMJ_DEST(0.00)[freebsd-arm]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_CC(0.00)[yahoo.com,cyclaero.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --0000000000004b4a7c05e388827f Content-Type: text/plain; charset="UTF-8" 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 > 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 > > --0000000000004b4a7c05e388827f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 11, 2022 at 8:31 AM Rodne= y W. Grimes <freebsd-rw= g@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&g= t; 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-RELEA= SE-arm64-aarch64-RPI.img
> >>> # gpart show md0 md0s2
> >>>
> >>> =3D>=C2=A0 =C2=A0 =C2=A063=C2=A0 6291393=C2=A0 md0=C2= =A0 MBR=C2=A0 (3.0G)
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 63=C2=A0 =C2=A0 =C2=A02016=C2= =A0 =C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (1.0M)
> >>>=C2=A0 =C2=A0 =C2=A0 2079=C2=A0 =C2=A0102312=C2=A0 =C2=A0 = 1=C2=A0 fat32lba=C2=A0 [active]=C2=A0 (50M)
> >>>=C2=A0 =C2=A0 104391=C2=A0 6187041=C2=A0 =C2=A0 2=C2=A0 fr= eebsd=C2=A0 (3.0G)
> >>>=C2=A0 =C2=A06291432=C2=A0 =C2=A0 =C2=A0 =C2=A024=C2=A0 = =C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (12K)
> >>>
> >>> =3D>=C2=A0 =C2=A0 =C2=A0 0=C2=A0 6187041=C2=A0 md0s2= =C2=A0 BSD=C2=A0 (3.0G)
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 = =C2=A057=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (29K)
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 57=C2=A0 6186880=C2=A0 =C2=A0 = =C2=A0 1=C2=A0 freebsd-ufs=C2=A0 (2.9G)
> >>>=C2=A0 =C2=A06186937=C2=A0 =C2=A0 =C2=A0 104=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (52K)
> >>>
> >>> The start of the fat32 boot slice s1 (containing the u-bo= ot) 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 paddin= g of 57 blocks within s2 lets the UFS partition start on a globally even ba= se, namely 104391+57 =3D 104448, which as a matter of fact is 4k aligned (1= 04448*512/4096 =3D 13056) and 1M aligned as well (104448*512/1024/1024 =3D = 51), however all this keeps looking strange.
> >>>
> >>> Are there reasons for this partition layout besides makin= g it look more interesting? If yes, some insights would be good.
> >>
> >> The layout details are more specific to the aarch64 RPi* cont= ext
> >> than to general aarch64 SD card images. For example, the Rock= 64
> >> image is different:
> >>
> >> # mdconfig -a -u 0 -t vnode -f=C2=A0 FreeBSD-14.0-CURRENT-arm= 64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
> >> # gpart show md0
> >> =3D>=C2=A0 =C2=A0 =C2=A040=C2=A0 6291376=C2=A0 md0=C2=A0 G= PT=C2=A0 (3.0G)
> >>=C2=A0 =C2=A0 =C2=A0 40=C2=A0 =C2=A0 32728=C2=A0 =C2=A0 =C2=A0= =C2=A0- free -=C2=A0 (16M)
> >>=C2=A0 =C2=A032768=C2=A0 =C2=A0102400=C2=A0 =C2=A0 1=C2=A0 efi= =C2=A0 (50M)
> >>=C2=A0 135168=C2=A0 6156160=C2=A0 =C2=A0 2=C2=A0 freebsd-ufs= =C2=A0 (2.9G)
> >> 6291328=C2=A0 =C2=A0 =C2=A0 =C2=A088=C2=A0 =C2=A0 =C2=A0 =C2= =A0- free -=C2=A0 (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:
>
> =3D>=C2=A0 =C2=A0 =C2=A063=C2=A0 ???=C2=A0 md0=C2=A0 ???=C2=A0 (?)<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 63=C2=A0 =C2=A0 =C2=A02016=C2=A0 =C2=A0 =C2= =A0 =C2=A0- free -=C2=A0 (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?

>=C2=A0 =C2=A0 =C2=A0 2079=C2=A0 =C2=A0??????=C2=A0 =C2=A0 1=C2=A0 fat32= lba=C2=A0 [active]=C2=A0 (?)

The OP is correct, this is a horrid state of alignment
and the cause should be tracked down and fixed!=C2=A0 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

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.
=C2=A0
=
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 fr= om the underlying device that it reported. And that
would lead to= mismatches because it was different than the lies
that md told b= y default. But that only mattered for really old
BIOSes that coul= dn't handle LBA/packet mode in booting (which
is the primary = reason the old fdisk program could set the ending CHS
of partitio= ns since the FreeBSD code used that to guess the CHS
of the drive= itself in the absence of other information).

I do= n't think the kernel has changed in this area in a very long time.
At worse, we're seeing a mkimage bug.

Wa= rner
=C2=A0
yahoo.com
>
>
>
>

--
Rod Grimes=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=A0rgrimes@freebsd.org

--0000000000004b4a7c05e388827f--