From nobody Sun Jul 10 21:44:44 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 244011CFFBE4 for ; Sun, 10 Jul 2022 21:44:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh0sr036Zz45XR for ; Sun, 10 Jul 2022 21:44:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657489486; bh=bi8tObtt6dkTKGeFyO+Q9DTpvWwCfhrVh3ZKf4X/1NQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gqHEFdH46tKNEQafzbfBCW3h0lxhNj3ATLb2VnTMaO42fyaJwD/RA/HhKYvpNAO1J7RhVRfp9DBMcJ4wgZLRS3eAhygjnKo7YSUeCsbmv5TIBjR0bXFS+oSAJyTErGp5nlYxLHcEpLp+XQuyg49TbC2dcqjnLE3EAgYWRTLkbSv1iIE/e2kLlvXaWPjWCVPAJOcT32V80IsmZTGqsbs2pUpSn60ucmS8TtmS3u1z4+K2JgitfI64oSpDtlEzWAcbAxlFPiPlVWlrmhzaDBJu0tpxr3m7DOZzAoK1eal6AWcxzoyUkrRrXgQck2gUSNQDaqhj73XfYYD9MnGOhgap6w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657489486; bh=w27ck5nmY41gxuDyGO8NOyzjXryMfxAUd0/QixfTa7V=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nPl6MViet/iytVpP9q4BCK6ENH2FtHowNrf4jqg+ecgXv+ENfieyULJidaCNXTe5c24zMGyXfTzZHsrCGqlu4X0wdCCgUwXqGYAn9+Yv0N3F/rCHZTcZJvhEoEDmJVmdWDaTaL4sWiFCXhcR3qn/0VmG3TYS5J42DYHHXa8VhlKq75vhAKE7BLHr03sPdOuC3GoPBUgkoXt+bmXIrc4bd0Atg1GRfxqUEomI4pZhwKAVjVt1cpUrDIY0GQbuy96EifQGGdbpLfmbmp3qlyDMk6672eCxSJw/DtrMdePy+IZKexkR3nOonzgH7QHs8BLAxwFOaKEv5yVBnvorFVEH4w== X-YMail-OSG: Zwor45YVM1mGTGfdWOBB0PnowQ33Mvxzg4P3aICzj909TbpLPB3QD1pWCWLaZLa rR1v_jveyOMMrbVUINq2EqskgEicbfoaOGV5YUeh57zE9_bVU5nWqb_khsxzXEXs7AmPvYVDeUmc RBDRWEvvr0Gucph_UNGtFUKxdBdqZdsDusHwUlFhgVvQNwy6mIg69F1gMcOZwIRi6LrhoD8mvntD gPcG8bM72SRxvhJd82ZP5B0gCaMT2WKZquYIEKlND23LOR4DA1bRkH_lCTbUQ5mDRKla8j_JZj3A pw.dR.nBWJ_Vzawsg0Lek_sZPBXwlKdRDA6eVvjbif2151lRv47lFROKQMM.osThUBoN2_x4hEGe fE23pXGz977OAFyR8wDVsPhawMGkR0uQ6GFdFWmzAesWUdG1T06Y3WX0oU3H13jLyyacsxdXezTA bwVf0tE.sph1GYf45UVzQqrPewK9HUGxEJalLHfMF70.8NRENO3sMNLKTk.qZZOxhd5Lo.Vt4.VT QAouMGbFp3OtdyquyBJF7GPwr5GNmYsA398oYWLVGBJenHcKQtEEifouFA7KWbMlpU_cxGm2OWVV dynpV3qRSuqPTVkyBFPUFCsAmoLz4BsftwrOp0Ffhgy08ItR.iurnW38n3tyfqs4ins5pfBdZ0lJ XrIDlDY6Dj2Y7rt_kawlK.PDqOxjsZ_5s8DJr8f1SJqkB_EZeMDOwwKydRTkwS5CkvkPOqASUWBb h8amdZXtPNf90JQvcRgeq.MM1POKmGNHBQH7W8dKApEP9UjE2FzA9uVZiSvsAA_Hh4oIwwffDCJw FBhqFlKvwiCboUlki3IncRl4lwfFw5T8q5yDhZiIE4LZXWhuKBiR_t8n_Um_WN_jseU4AE7qaZL3 miQ.5H4h6DkU78cC989mI8EC5ShxpxsEvGCur0S33Bcu5MEXSBDDsZ7vr_NC3_d2LtlB0mi.lghh HYVpJDr4dMC9JzQGZriuzBurbt96jTlTgThUjAGWRvza9t3ltkpE6fBEHPAIie.sAuN16XbgyCye AzSPAr0FH6Hg11oPGulwpfw8j2lqeUa0G5h_IixLV47GwDbjIldiw0FZgsKysI6iREAeKX9.tNv4 Vk0bhbtJX72g2Jg9X0RGEJA2lHzoLYk4g6_EL.KOCiij9lj8Z_48Tprbxa7o7Dtt4cKdFB5BZeSm ouffsLqAWh8vNwiH3Oq0W5IfwhUcqxQr2uz3WuMCRwanU.y793MsHXNe35v6DRdCvA_igZWDU.p. QJ_hDqvzHFqCuMbWDmWcUhHACPK_yEcnc2JPFqxhem2Kgk_TQasO.9w7AeAyd4q7NYkB47mXSxqn VIB2IG6LtabaTFM9.yEkpmL.05UlKYAuM.w..m04TIoXGv6WtduKsFrGmZUgfhfLh0qt4Ox_VnPh 5Din5hIqLUHyrCoLY3B4RXAStMcxhWQiv8UHqG5Uvz5ED8ysCqnke6eRrZeJBiPJhIWWB15nVSCN Nsh7xnN3HyYVg73E9P5ndT0Z_NmWKXIkfG1mSAKehi.hYN2UcsF98NlVuHscocNMMOpn4CYXtEK. SWPuVFt3aAR1cKGl9wTBNjnXvTrN2yz76TmWNWjbF.aRlEgr8Z2Vmej98WcK7U0iCk9YyovfeyrX 6fgT8eVTlgR64LRIs27hpiEiTU1DIh2bxMhJ4_tnw5adD4tXpSbXDAZZjjloXgEAPAwo0uH.yo43 JQFl12RqeylZUo7FNSl229Qmw5r0CPH8mnDF0NmcS.Csk2ACrKdxVQNiC6sKMuwkZVNYr0XKykxk HomwH9FVT2JL9MgP0Zm7KxUr4KFbNVyAuRVdaPzFB5Zt2ZF1nwr6hRDEBiQ7XOodLc61zxLHA3Vi cLX3PnlpA2e1UKNK.7J7H.QeWcYslYXdfX8zy9mzSJOly0JI8sFs8EyBltu7XIrU2Ca.VoX537Qt s1Yp63JcSNH.OeoGIWEizQ3Tx.BxVxdJS.N6nlwINUGmQu59xtkpK_BkYUEWTVpCYB.nz6UDOUOU Il3OLLAROksxm6NXoX_OOf9dTxHjVtA8cJl4Pr54J.wqbfVaFgyQVp0kO.dnb1ZzMlbRGgHa3rRj pkbjGSeUxsZMWqSRtJEPfIP98S9WOjtxBc.wRBG8CfYRq7bxf.PRYe9d8ZmxxvHoiMAArQGnx51X ozf_3VmNPrXcTkBeDDYeN1s0KGynLSLkF2G9y3cf_UMqvX8tCmAqAG4JRN6D5ylA3fg3sZUGghOt 8sS4BzdcC5Nm5ikOx33Ag1pKNfOG52Y.QuL1BpLRkjgRRO1aYPkKQqBu6lRPuAHtF_zvbBOKZlrE cCeQI X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 21:44:46 +0000 Received: by hermes--production-gq1-56bb98dbc7-r7f9c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cfe02e1ac54bec5d55cd18ee1e1ad1a6; Sun, 10 Jul 2022 21:44:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 14.0 \(3654.120.0.1.13\)) Subject: Re: Partition layout of ARM SD card images From: Mark Millard In-Reply-To: <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com> Date: Sun, 10 Jul 2022 14:44:44 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338@yahoo.com> References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com> To: "Dr. Rolf Jansen" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Lh0sr036Zz45XR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gqHEFdH4; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.21 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.97)[-0.973]; NEURAL_HAM_SHORT(-0.74)[-0.742]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-10, at 14:02, Dr. Rolf Jansen = wrote: > Well, I thought the arm64-RPi one is a general purpose layout becase = the armv7 one is identical: So far as I'm aware, the RPi*'s are unique in having all the content in a file system instead of having some content outside any file system. This tends to make them generally unusual in various respects as far a Small Board Computers go. It is also why I can normally add a RPi* dual-boot configuration adjustment to a configuration for another Small Board Computer (such as the Rock64): no conflict is generated by the 2 U-Boots or other such. > mdconfig -a -u 0 -t vnode -f = diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.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 > Must be something historical. Just for reference for 32-bit (hard float) raspios: = https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_a= rmhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz # mdconfig -a -u 2 -t vnode -f = 2022-04-04-raspios-bullseye-armhf-lite.img=20 # gpart show md2 =3D> 63 3940289 md2 MBR (1.9G) 63 8129 - free - (4.0M) 8192 524288 1 fat32lba (256M) 532480 3407872 2 linux-data (1.6G) So the same use of 8192 and 256M these days for 32-bit raspios. The 256M may in part be from what some linux updaters do: rename the original files with added .bak suffixes and put down the new files with the original file names. So: 2 instances of the files that do not have brand-new names (some .bak/no-.bak pairs possibly being of 2 distinct vintages). I'll note that a lot of the more modern RPi*'s can boot directly from media that uses GPT instead of MBR. Some older ones can do that only via a microsd card that has a sufficiently modern bootcode.bin that loads first and provides the updated context. There may be some that just can not boot via GPT partitioned media at all. (Unsure.) To avoid microsd card and bootcode.bin requirements ending up involved sometimes, FreeBSD will likely stick with MBR. [I use GPT where I can if I'm setting up media for myself.] >> 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: The sizes below were extracted from "ls -Tld" output, so "byte count" for units for each. >> 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