From nobody Mon Jul 11 16:50:11 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 9AF691CFC74C for ; Mon, 11 Jul 2022 16:50:21 +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 4LhVHc2FHjz3Mn9 for ; Mon, 11 Jul 2022 16:50:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657558218; bh=P78lZ0GDuTfgIwYkJTmKJ49B/g38IVGpgPU4ExVX5M8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AmYE46C1xgZe7s4a7oeLGSL6pI6L3x3jlfbVpUD1LZhJQNx/8JEIsYTcbG81lrHCL+W/Lpae6Becz9D1vAt+CuVcB/8OmFzziYRWenvkiyyDyj2B+dmX1cjZNXZu03ALl4SFHW9nlb3MAm7MROX+ULec2mXd2KvEJpj9eAPgZ4zMd7fYixxFLS+6yvHfSC+kLpKb2cb6TWQvvF2EsgRvOAUXiAFrNejNV3ab9ocqoiwdZRLwlxOXoYfDPPfqAa26Sb8zchf/3cvx8YEsSOivXLHhdJjMYuGCz6UxAssazpV/Aj4MAH8tbdwWFEQ4opfJ54J8DNJHIV7QdFFNeEt+qg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657558218; bh=rdLGS8nipx/pGNPsOV+iVqVy5pdRA+0VwwAq9wsb/Qh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OCTkAniWbc/0oP72vWMub4SdJBBeGkznbY5K1iQznV0KvfDIKVrQeCyHpTlT3/VvBKU7Fx3sY4TnAiS/3pH21G65KUS+WiCo6nt5s/5uWYYkY7kGGnU7SjvqWA5moTFjLR8CO9SNX1KxivJnqP/MnrBgzuOMB+V9wpGwUJ4krHtfeVdCn3FY2w1U60wxj3DSkPXSbALoz8e5fAAnvqF3sRgqrm+9KtjBYYmsWNlG7GK6TrWYj9e7phRQOqR3rAKrGZ27iCzH2TsaTqX0+jRI3QbvBMvSKqptzes/eGLyemw32lV6r+h1NYUOTpsnCMHyVZe3cz1XslXh6MpK49V1VQ== X-YMail-OSG: ZuiBPYYVM1m.DRIZifpZWlOvgaVwPNXNFQjUax9EJTxSmW49njisslM_tjMxKHn hXADrCebFEa56AjJpp9SBpbpqScj0ghJ7TmeFlU6o5aUvdvMeavfz5PfysWe2kYuGZE1R4Hcmapm iQL0FmH0Gssc1KOGEQY9b6c5qdYoUy7AjfSd8v6fzK2bt0HD6gIhb8ylfxB3r1.CZFKHUY2TY5qn KkqNKKwC3t306GHAZBeRio3UtBRFYgodm3HxgFDmPnA7DzarG3Uyvuh2cZDNo_4poBjBO0vza3Uh e73vnzfQ9CAEpSncjVriWr5d5o74t5jWoC9k29mNQ7kTAkMOy_ZuQEcN13g4ePpESyeFT6lcChik AjExI2XJEDjs3_7DZiJuROhAw3KjpXViaIPRtgTeGCgjmgssxP4EMxriGTC49MfasAMo1MFlOMN1 XFRBFaB.4q4d1TKfFip11NAaQ.D30lGAFvfTyCy1Fs3r2JMqgk3guBFUXZ4R3aDz3VxIemv5IfBS 2qSuTFUZ2OR9nc4cgM9a4OEHCgVj6HvRW.6tUo5bMLEub0m5UwRff3reDfJJxigO.JdLp9go6ZMT _BU2sg3KsyhKLOH4bvvUlD_YFJRoo1uA8Qyns0pXbfTWRl0P9oTU2EdrahMrbbSUT.aOP5.iHQpi kLRZCW3kXuhHzmjBUCJMgzcOJxEOg_kuvvFjCX8vUnxmAXJExJPSRExvVRqNxKPY5YwCvDLXPnrx OPi1vzaRdfAu.ASS1ZebLf_INRuRZETUVBMAxUiGZWjkTrFbwMZS4c5ev4_0m3dGqwsRza16xf0l 6DSIZbw9KRGZ4st6rxO2GOeH6vi.WKA18lVfLkXMp9wko7uljPkhCJ40tAir17.XFCkriJBg0SJK kzNjIQrjAYs9kh7dfGSZ6zG_ckWQ88rfYYjmSZs9M5vzMakarraQd7DwMUM0sFFrge3BGLj38UTX .qzl.vXPy93u.uI9MsgWIbqkC6siM8M44cLPhOXfv.KwPzSpTUPEd9RF3yz9qJAQpuv9Yi2UmoXG 7xEOFZY3M0nR8HLjJZm2RsN6nKWwk891VLElQzAkGwfAxPMMeWBeeMGbDJXjV6jLiFITOtVRud1z QVPa54ZvILz8x7r69KA56LuQ47.dof8BrflAMYUHnPTuvuspKweFq0ApJEovBuznUT9yUHHtJ2hG HsF4Wgv4JioURSKRdrMZiuZiR6vt8ujJnhsWpy5tZuxxsQC8R40QyA..dEGJ0MJSv740harewwzC 8R6hzyfpB36t6.Ow7JmK10V1s4ATO0Sc5XNZQFISP3JSwUPGlkA_UUdhMxT1AI8m1LGvMtSEGCIk ClCJY4TxKDfwuDbJOpobswpzvtICpFreOp0xY8_mQ60_eWXwggVgiC2kyx_Vz1JF4MQVK8BEAJRv zrAKMde_TrsJ2zEG0E7CFx.ZvmK4m8.8DPtRxM3cPs2O5EcrwbGOg9b.KGPXuFPuvQDbKrfU0Ibr zwKn.jNMQJTNzlrqkczzcdpBkoV27Hnx93F1JykFaD8aHH.LOcJPhcUjnq4CA765kvfRUzeiH8gH SDRiq9eFn4QNZ_cLtVgaFRXPTRj0BTK2EIheiKOaGeoKIoE9YVQF0Yhhj_sTPBVUApXznMpKNOGY qCvI1fiE847xQ5J7sq98bOpdsxVoJFmyp7ypkUvzKi0luq0E6WGT12VdV0YHSbjBImuxhJwAhcya ocffOt1ISpelX_Xzx5b9RF3ebjbmFnrz8PyqGc9z6MMJ2z_O_KdfGLeNWAOBMoOUGEMKy1oOUj5D 0gLA6sm2M4q6ymFhyVk_Zi4JGxmnC3.V64Rl4f281IFDWfAL7fpJs5HcxHUTaNOk7LQT670Io3ST 8IV3iv0Hj00NeHUcedpyihAO24pwhfukbObOAcQk2wSfFexmoJogiUxbbm7hgHG92cP4jXf4GhZx _2MQ5jHeqjs7D58vFEeovpOSzrZYzo8XUrl3jY8QvFiQmDsc96gBtlfujvEG9oSIs9lexwMqvNHW LUOLSGhvT6VyK3npXuTgeArvcygo7X_IR4RctMeLa0.pM_2HFOhQ8tlWg88UIx80KO_tWpk7QTox g_hfxBy_6CfxrJHyXsdivLf3RJFJ9n0.rkiqwp7ZTZzPbvHEHQIOj70JH2490xhKL7sP4LHdHsr9 pi6mN13.7uaZ6Km8lTalZvwA6hVE.muHO9tpHMySzPcY5XaNQiF57RE5RCPiXNqSCLrkw4F1lm8B rCkzSCYXN84RoYpvh.o3a.FFu.TwZdbmsU1h5ds5o.kKRNdCtDgqg7QFn9B6TLpnOPE0pSRu9ZHV sEdN2GtU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 11 Jul 2022 16:50:18 +0000 Received: by hermes--production-gq1-56bb98dbc7-mpzkq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8eb7b21379b76d947eaf393a5f757367; Mon, 11 Jul 2022 16:50:12 +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: Date: Mon, 11 Jul 2022 09:50:11 -0700 Cc: "Rodney W. Grimes" , "Dr. Rolf Jansen" , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2B2004D4-268C-446B-86B8-15AD12C152C9@yahoo.com> References: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com> <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net> To: Warner Losh X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LhVHc2FHjz3Mn9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AmYE46C1; 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 [-1.64 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.86)[0.862]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; 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]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-11, at 07:38, Warner Losh wrote: > On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes = wrote: >> >=20 >> > On 2022-Jul-10, at 14:34, Dr. Rolf Jansen = wrote: >> >=20 >> > >> 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 >> > > 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