From nobody Mon Jul 11 14:31: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 CEE301D0ED85 for ; Mon, 11 Jul 2022 14:31:48 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LhRCl66P2z41bj for ; Mon, 11 Jul 2022 14:31:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 26BEVXXR037802; Mon, 11 Jul 2022 07:31:33 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 26BEVXCf037801; Mon, 11 Jul 2022 07:31:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net> Subject: Re: Partition layout of ARM SD card images In-Reply-To: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com> To: Mark Millard Date: Mon, 11 Jul 2022 07:31:33 -0700 (PDT) CC: "Dr. Rolf Jansen" , freebsd-arm X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4LhRCl66P2z41bj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[dnsmgr.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > > 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 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? > > MBR vs. GPT is not the fundamental issue for that. > > === > Mark Millard > marklmi at yahoo.com > > > > -- Rod Grimes rgrimes@freebsd.org