From nobody Sun Jul 10 21:02:24 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 57E571CF99B4 for ; Sun, 10 Jul 2022 21:02:33 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.160]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lgzx34Zwsz41D8 for ; Sun, 10 Jul 2022 21:02:31 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657486949; s=strato-dkim-0002; d=cyclaero.com; h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From: Subject:Sender; bh=VrKJH3bGznJ/xpIU57OA3tYkEiTZwP5eBdsWZyIhYr0=; b=ibDA9Z1a/vABbMqhRBCtKQTFCP66i2dpyngaDiGbnWbiIvMOdSH1Haw3neyuKfuBv2 0xitjTEc9ueTkkYoIVrcWFEVxMKKXkm8YxPnD3K0nOcgRPROuzxb5frT1F5DYAvnVKQO FJpH5WBDFz4N/pDHYJkiT+FfO6lUbM8tbbArky9uq/zYGAkxAoTFR7dVn7aM8CzMmxzw jIXuUR6sruWUS18D7DlLtu0YA/ydPyAMExymTB/wn4rSPawhps+21jHk604tA52P/jgK LcS20WS/hdzRjtn59Hhx6QbzrJgOiaJOGJSWMO2WSyfBxUEK7sHEuMmx/4O3HzFw4eTo 5Yqw== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg=" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.46.1 AUTH) with ESMTPSA id kcd9d5y6AL2Td1K (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Sun, 10 Jul 2022 23:02:29 +0200 (CEST) Received: from rolf-mini.obsigna.com (unknown [177.95.254.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id BDF6D63937 for ; Sun, 10 Jul 2022 23:02:28 +0200 (CEST) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: Partition layout of ARM SD card images Date: Sun, 10 Jul 2022 18:02:24 -0300 References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> To: freebsd-arm In-Reply-To: Message-Id: <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com> X-Mailer: Apple Mail (2.3445.104.15) X-Rspamd-Queue-Id: 4Lgzx34Zwsz41D8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=ibDA9Z1a; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.160 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com X-Spamd-Result: default: False [-2.00 / 15.00]; FROM_NAME_HAS_TITLE(1.00)[dr]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25]; R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[81.169.146.160:from]; DMARC_NA(0.00)[cyclaero.com]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cyclaero.com:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RWL_MAILSPIKE_POSSIBLE(0.00)[81.169.146.160:from]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Well, I thought the arm64-RPi one is a general purpose layout becase the = armv7 one is identical: mdconfig -a -u 0 -t vnode -f = diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img gpart show md0 md0s2 =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) =3D> 0 6187041 md0s2 BSD (3.0G) 0 57 - free - (29K) 57 6186880 1 freebsd-ufs (2.9G) 6186937 104 - free - (52K) Must be something historical. > Am 10.07.2022 um 17:48 schrieb Mark Millard : >=20 > On 2022-Jul-10, at 12:26, Dr. Rolf Jansen = 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 > The 32768 is associated with: >=20 > # more /usr/local/share/u-boot/u-boot-rock64/README=20 > U-Boot loader and related files for the Pine64 Rock64. >=20 > To install this bootloader on an sdcard just do: > dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img = of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync > dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb = of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync >=20 > where the sizes are: >=20 > 103411 for idbloader.img > 793560 for u-boot.itb >=20 > In other words: assocaited with having room for > the idbloader and U-Boot as required by the Rock64. > [Most U-Boot's(/whatever's) are not placed inside > a file system and the positions/sizes vary. The > Rock64 is just an example that I happen to have > access to.] >=20 > [If I make my own partitioning, I tend to use the 32768 so > U-Boot/whatever fairly generally have room to be replaced. > But I've not checked if any u-boot/whatever ports require > even more space up front. I tend to set up to also allow > the RPi* to boot as well as the likes of the Rock64 (or > whatever).] >=20 > Looking at what the official raspios arm64 images look > like, for example: >=20 > = https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_a= rm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz >=20 > # mdconfig -a -u 1 -t vnode -f = 2022-04-04-raspios-bullseye-arm64-lite.img=20 > # gpart show md1 > =3D> 33 3907551 md1 MBR (1.9G) > 33 8159 - free - (4.0M) > 8192 524288 1 fat32lba (256M) > 532480 3375104 2 linux-data (1.6G) >=20 > Note the 256M fat32lba instead of only 50M. This dates back > to: >=20 > QUOTE > 2019-06-20: > * Based on Debian Buster > . . . > * Boot partition size set to 256M > * Linux kernel 4.19.50 > * Raspberry Pi firmware 88ca9081f5e51cdedd16d5dbc85ed12a25123201 > END QUOTE >=20 > rpi-update has logic that can produce the following > kind of message: >=20 > QUOTE > Partition size $(( $PARTSIZE >> 20 ))M may not be sufficient for new = Pi4 files > This could result in a system that will not boot. > 256M FAT partition is recommended. Ensure you have a backup if = continuing. > END QUOTE >=20 > It has had that since 2019-Jun-24, 882f5c1 in: >=20 > https://github.com/raspberrypi/rpi-update/commits/master/rpi-update >=20 > I do not know when the 8192 usage started. >=20 > It is possible that the FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img > structure just dates back to matching far earlier Raspberry Pi > images. (I did not look that far back.) >=20 >> For the time being, I created a second SD card from the initial one = for my RPi 4, and it's partition table is as follows: >>=20 >> # gpart show mmcsd0 mmcsd0s2 >> =3D> 63 62410689 mmcsd0 MBR (30G) >> 63 25 - free - (13K) >> 88 102312 1 fat32lba [active] (50M) >> 102400 62308352 2 freebsd (30G) >>=20 >> =3D> 0 62308352 mmcsd0s2 BSD (30G) >> 0 56623104 1 freebsd-ufs (27G) >> 56623104 5685248 2 freebsd-swap (2.7G) >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com