From nobody Fri Oct 20 07:39:11 2023 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 4SBc0y4fwfz4xS88 for ; Fri, 20 Oct 2023 07:39:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4SBc0w1ZDzz3dyL for ; Fri, 20 Oct 2023 07:39:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pKMR1Ae2; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697787565; bh=1FJpMi+Lvjva4FFQHA+/MblJsjabgsKJqQwb4JwtgxM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pKMR1Ae2NTEx6Tlgwms2dbOj5bY86XBV/KIj0ONWXIFx5VNQS7gWh2pziMwpzNSTbVi+MvwdUT1auecO5smMhmXWQql7VDsLhVRmNr3JGWVu0uj2uhCOxWEtN5Fyv8jOqPJMoPq5jEf9V1R0dhl99aAT9acwmnIVBUUqJSfg27sha0lDBfDvjilAKB5Cr9S31ItO1h7S0OqZs9ZHscZ3zbSZbl0+SvIs88w6YcCUUDm3YBCKYhMO2C9/mzyGUK41FCYsJCHtXxlXC0aqubGBW2GYRrA/UHOFarC/sZ36DaYfUPzsaldy/qObbCq02FWdV6WG4BtrJfvQfpJdhlSJWQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697787565; bh=d2XOKSbd0VyiE87Xa7Y1T17ZOlIrJ0SC8y7tvD+fwuK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G9CygFJlh6JWOgEYwlvf8r6QWJSU5Ns1BrXqXNvw6eu4/VkK2HZy6I/cJZCBrYLiHCGy52hl8aYX8wnZrcw3GXe26+8AYxUBRPtnKCCKugnFjjYou8ZEFYkfFiCabBU0XJsWLs/s2xZqkqUzuSIAHYVVpxRbT8TqXJ1iGhDEUVoJg/oKpmtqitTgsurDXzH2kC/bCUZYhAUwfV/4z/UzVn+f1JUeeDuG29O4zHqIxfD2KinWs57Wi4bfL0ue094oZRd3swEF3z5LhB5HQwo0Bk9Vot8xVlWz0snudrvgMrC7W4zqruaEtiWjLrCaDpm5Q0kDqNoTwHMS3pHJRkRzBw== X-YMail-OSG: 0eAG5BUVM1nqS1NaXK_BCwEnljjQ8Nzh4po1jnzJK4lGtHwpiTkh4D_K26xiYNa FejDh6QBjmgxxfuHSGRA9aUFkjK_6Cy3mq9ax_f2rSGWfUvTPlT.4HTshWIwjBz1DiVuus.fAh2x rkt4cxUY.iwUC3HSv98Ko2cukEkMu4fDi8_eUPxtPygPw3AEL6NzhBHjj14Ts3Ic75nyo0cSp3Ok 9c11WOu0c_r5RRztZsWPj7R11gItsli4ZMWgZnMzd5z2xFhFNxqGNyeWAme7c4PiBKADu7x7Fo0G 61UTHHZADRIcbtuub_HVrkNVD72bu8w38BivVHq4cimgidalI7jU89t2joLxdxk1YuACcTCKD6fN MOiKy.sFgtAYqbwjZEDUY7dpLVTvAHWaTiZXGBrqdYdISw4tdfDzvykC4xAkLMWcmXLgdz_p37zo .xbPt3kKke0jnNg2xTkAc06nPxFUk5_M9gXQQMARw6E13HixAD0Lqn2bnnzYpPqjjb6AEn2n7jfc DX.dJZXeod0a7CVdZ06Cdcd4gmzNCemID3zTjoxB.tACnakz5RiLAjqRvBFrXMGsHQv2hxcBYLmP JYZs471vfLKIbUZFfgsq5ERtJjGORAWeBNnzh_O_g6QZVi1nnqpABHi1je9cnyz3BXb4fUTbmQdu 2QqDBdnyj8SMSpOwLGpSVADjplBZN_g34qjUgeueLKqcyc7HBG2WGU.Le2Yydqymi24jxLttm6i1 _Q4c6Ll0ot3FY.CNxxij6_aIMOHPbSUWopmb8T7lDXrMm8AzSkhRu40HtO2BdGxP7Gt3Kl_qEgv0 NGQfxguQhToFvc23CwP5Vuu7oZmBBMFGpaDGNWlfuOOy6DeAdZ4ChwgV9dWJPcDhthpot0rpJ6jV 4KhvA8l1VXwjkrEe62zC2FLPzZrHVXKQ8esAmY1rh1BoDbvz7jbiUmitG.2gQSUdppqDJ6UAVlOb kzRClgzNy.i1JbBlim3MtUSjs_m3xfu0ST1wwQjxdmEVOZuA5wuic4rady9YA5uvCV4E4wA4bYZ9 VEqXBFhnKJT6a3yJ3sjQxpizhrtv_1_qq2UH6jJ6vEbWX66NRhlvqqsBEPIWi0nJ2FRDii11xzTG 2ARfV1sob6O1O3x9XxuHSpWviLK0NMUlEQBsJiWA8Ub5SdTDmxx3WFRBe6SF2knrlixE0dSNPBFz 18kMnJMgSVmILGu_8g475LBG004TKuzTRGpevEVXCThsXT2I9Qq6CvB8KpBCCMENg1NrJTonDusR vWSzrB0vm1JT.wChrcY96w9INuHTRHRRJGS774SScBeKL1UaB7sFhK3r1FPh9CPCEWSXf.1CT5de 0ovqDz2g0hrjKaM7X.Y4AUwc6lAo1P200vIIFeA23lFFJ_4JhJJXc97rUwoG_brgezuoBqN9MVsx DA5emvXEkBIdxdZOXLmvvDZlTm5ucIH8HCfhW57VZFXl.9a8eKwVMxzhKwD2YoKysxmZt4SruqIz 7bVyAozhdrDup7G.mKpwoOqgDNXRct2gupdLuKOOVqJR4q_N6WOXXIAFzTKqlin.OwfPpXOPJ3jW tF6._G3dhXwLOsOe0NzzpqPrQ5ydMJmKL8nW2F6wg5CM5ejTF.NUUZ7QjTuMd1_.z7TIU4SXylMj gXzALu4W71AHMm3ikGo9ZQgdZHVFf6v602nBtf8ELSApjXWanTtmR6chQ4xBnTHLCzIDn3cplR79 KLHNxAU5FrDx2.yyILQvyJSTiJ3bDO.gYa.cW4fPX3VxICBS2_7DZRvn2.PoBusjT5smurP_F_Bp 80X5mGD_lvpEKUmafJM1KiNwlaZmqw1R6xEIuHh.2HRlKPCciGEsO2KjVSA9PptUW6GGYhhudGzL RF0VEwt__iOEkIRVR4EiETNNKE3nle5SG4GF7ztU0WwE1L7624jhLBdYQpTNZ9U5kW5EWCfRi4z0 5M3Ddm4c2Q7WL8v.2zGVSBrlJLTeWdCDhA71RHcoGfkoM.3J0uILY5vHHLWso4AmRsCxGzEYE3HZ _0gpD7PaMRXxZ_HY5KhWRiXP0x2FyADqvxmC62YnuoiRr2VhAmQ_Kx3YIzTCsBlCG0F0EwoCNR7M 2ti2gKFdhkDE31uzMBg2zJsvPNMkl54W_q9no09In1Dv4i.tksetcX.0NlsaAnjfL7n2jc8GtT1M uByTWYGlHpG1pg8itFoEIA1xcHCWowgCaLuGk4.KfPlqz_ocA8U4z3dHHgzMDmxPjdH9x_JCBWcG 9lusmFFkw76XBFuRfkH5FI2fTvEmNhOoSqv8OXbhIvc36Mq0.vd9k4rzgTpaG.5.8j1wEUGz29dk - X-Sonic-MF: X-Sonic-ID: 65bea39b-297f-441f-98cc-837fb4815948 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 20 Oct 2023 07:39:25 +0000 Received: by hermes--production-ne1-68668bc7f7-lchlz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 80add92cfda1623989644f8d7409a2d2; Fri, 20 Oct 2023 07:39:23 +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 16.0 \(3774.100.2.1.4\)) Subject: Re: State of the freebsd/crochet project? From: Mark Millard In-Reply-To: <19481390-118F-4527-BEDC-9935C695A27D@yahoo.com> Date: Fri, 20 Oct 2023 00:39:11 -0700 Cc: Warner Losh , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6770937E-CBA2-4B50-AD7E-71707E36BFF1@yahoo.com> References: <87ttqrqnal.fsf@protonmail.com> <87wmvjjkae.fsf@protonmail.com> <33693188-5C53-4C9E-8F67-647655E957BD@yahoo.com> <8734y5amia.fsf@protonmail.com> <19481390-118F-4527-BEDC-9935C695A27D@yahoo.com> To: Rahul Rameshbabu X-Mailer: Apple Mail (2.3774.100.2.1.4) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.37 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.874]; 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]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; BLOCKLISTDE_FAIL(0.00)[98.137.68.204:server fail]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_TO(0.00)[protonmail.com]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SBc0w1ZDzz3dyL On Oct 20, 2023, at 00:31, Mark Millard wrote: > On Oct 19, 2023, at 22:30, Rahul Rameshbabu = wrote: >=20 >> On Thu, 19 Oct, 2023 00:45:25 -0700 "Mark Millard" = wrote: >>> On Oct 18, 2023, at 21:41, Rahul Rameshbabu = wrote: >>>=20 >>>> On Tue, 17 Oct, 2023 09:01:33 -0600 "Warner Losh" = wrote: >>>>> On Tue, Oct 17, 2023, 7:44 AM void wrote: >>>>>=20 >>>>> On Tue, Oct 17, 2023 at 07:13:28AM -0600, Warner Losh wrote: >>>>>=20 >>>>>> Crochet has no active maintainers. Most people have moved on to = poudriere. >>>>>=20 >>>>> Does poudriere handle the msdos uboot *and* efi part when >>>>> creating the image? >>>>>=20 >>>>> Yes. I worked with manu years ago to put all the needed metadata = for the different boards into the ports... >>>>=20 >>>> It does but it seems to have an unfortunate caveat. It assumes that >>>> FAT16 is supported by all embedded targets. The Raspberry Pi 4 and = I >>>> assume the Pi 5 as well drop support for FAT16 >>>=20 >>> The snapshot images booted the RPI4B's that I have access to just = fine >>> last I tried such. But release/arm64/RPI.conf and = release/tools/arm.subr >>> which are used to build such uses (selective axtractions across = files): >>>=20 >>> FAT_SIZE=3D"50m -b 1m" >>> FAT_TYPE=3D"16" >>> . . . >>> gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev} >>> newfs_msdos -L efi -F ${FAT_TYPE} /dev/${mddev}s1 >>>=20 >>> FreeBSD release images are also build with such: efi partition >>> type and a FAT16 file system. >>>=20 >>> Looking at a (my abbreviation) RaspiOS64 boot media used to boot >>> the RPi4B's (official RPi* media content, not FreeBSD materials): >>>=20 >>> # newfs_msdos -N /dev/da0s1 >>> /dev/da0s1: 523984 sectors in 32749 FAT16 clusters (8192 = bytes/cluster) >>> BytesPerSec=3D512 SecPerClust=3D16 ResSectors=3D1 FATs=3D2 = RootDirEnts=3D512 Media=3D0xf0 FATsecs=3D128 SecPerTrack=3D63 Heads=3D255 = HiddenSecs=3D0 HugeSectors=3D524288 >>>=20 >>> But it does have a partition type of fat32lba: >>>=20 >>> # gpart show -p /dev/da0 >>> =3D> 63 468862065 da0 MBR (224G) >>> 63 8129 - free - (4.0M) >>> 8192 524288 da0s1 fat32lba (256M) >>> 532480 468329648 da0s2 linux-data (223G) >>>=20 >>> Do you know some specific RPi4B EEPROM content for which a FAT16 >>> file syatem is not supported? (The EEPROM has the RPi4B boot >>> loader.) Or are you saying some U-Boot vintage is restricted to >>> FAT32 file systems for loading FreeBSD's EFI/BOOT/bootaa64.efi ? >>=20 >> Yes, I believe that newer EEPROMs in 2020 and above (don't have the >> exact release version but I can bisect if we need to know) no longer >> support FAT16 unfortunately. >=20 > I just booted a RPi4B Rev 1.5 "C0T" part that has: >=20 > RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: = 17:40:52 > BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D1673458852 = serial c740af3c boardrev d03115 stc 421180 > Halt: wake: 1 power_off: 0 >=20 > off the (what I call) RaspiOS64 media that I referenced earlier. >=20 > That means FAT16 with a partition indicating fat32lba. >=20 > There have been bug fixes, such as the 2022=3D01-31 EEPROM release = that > reported: "FAT/GPT fixes and file-system performance improvements." >=20 >> Here is a relevant link on Raspberry Pi >> forums but I can experiment with pinning an exact EEPROM version from >> the Raspberry PI repository if need be. When I got my Raspberry Pi 4 >> board recently, I did an upgrade to the latest EEPROM version and >> noticed this issue. >>=20 >> * https://forums.raspberrypi.com/viewtopic.php?t=3D278295#p1685235 >=20 > At that point (2020-06) there were only 2 tagged EEPROM content > releases: >=20 > v2020.04.16-137ad > v2019.09.10-137ad >=20 > There are 11 from after 2020-06. >=20 >> * https://github.com/raspberrypi/rpi-eeprom/releases >>=20 >> I am using the BOOT_UART feature of the Raspberry Pi 4 for this >> debugging. I was debugging why the image I created at the had failed = and >> noticed the bootloader was failing to actually access/read any = content >> from the boot partition of the SD card. Switching to FAT32 resolved = the >> issue for me immediately, making me trust the assumption about the = state >> of later EEPROM releases from the repository. >=20 > As I've indicated, the official releases of official RPi* > images have FAT16 files systems for the RPi* firmware --and > they boot just fine when dd'd to the USB3 media that I use. >=20 > Similarly, the modern official FreeBSD images boot just fine > and also have FAT16 for the msdosfs for the RPi* > firmware+U-Boot+FreeBSED-UEFI-loader. >=20 > FreeBSD has had problems with a U-Boot vintage that was messed > up for 8 GiByte RPi4B's. But that is now in the past. >=20 >> I noticed in that first link I added here, there seems to be mixed >> opinions on whether the FAT16 file system is supported or not on = latest >> EEPROM releases for the Pi 4. Let me go back and test once again with = a >> FAT16 file system for my boot partition. I am currently running Jan = 11, >> 2023 release (I see they have a new release for Oct 18, 2023). >=20 > I've not tested the 2023-10-18 release. >=20 >> On a side note for myself, might be nice to throw the rpi-eeprom = tools >> into a port for others to easily grab. >>=20 >>>=20 >>> Or may be you are referencing the partition type (expressed here >>> in gpart terms), instead of the actual file system type that is >>> contained? : >>>=20 >>> efi The system partition for computers that = use the >>> Extensible Firmware Interface (EFI). The = scheme- >>> specific types are "!239" for MBR, and >>> "!c12a7328-f81f-11d2-ba4b-00a0c93ec93b" = for GPT. >>> . . . >>> fat16 A partition that contains a FAT16 = filesystem. The >>> scheme-specific type is "!6" for MBR. >>>=20 >>> fat32 A partition that contains a FAT32 = filesystem. The >>> scheme-specific type is "!11" for MBR. >>>=20 >>> fat32lba A partition that contains a FAT32 (LBA) >>> filesystem. The scheme-specific type is = "!12" for >>> MBR. >>>=20 >>> (It has been some time since last I tried it, but last I tried >>> partition type fat16, the RPi4B's boot from it just fine if I >>> remember right. But GPT is supported, not just MBR.) >>>=20 >>=20 >> I am not referring to the partition type rather than the real = filesystem >> type, but thanks for checking. In my boot flow with the image I >> generate, I am using the efi partition type. >>=20 >>>> , so the boot partition >>>> needs to be FAT32. >>>>=20 >>>=20 >>> Not for the actual file system for any fairly modern vintage of >>> RPi4B EEPROM content or U-Boot that I'm aware of. I've less >>> certainty about the range of partition types, not having tested >>> such in recent times. >>>=20 >>> Is there a chance you are using so large of an msdos file >>> system that a FAT32/FAT32LBA file system is a requirement? >>=20 >> Great question but I believe that is not the case since for the same >> msdos file system (though with different components from = rpi-firmware), >> I am able to boot the Raspberry Pi 3 up correctly. Let me verify once >> more FAT16 (the filesystem) was indeed problematic for me since I was >> debugging other issues like not realizing the Pi 4 needed different >> components from the rpi-firmware project compared to previous boards. >>=20 >=20 One more point: the 1st Capture.JPG image shows: c-count 0 c-size 0 r-dir 0 r-sec 0 As I understand it, that is showing that the information was corrupt as read: valid FAT16 would not have that combination. =3D=3D=3D Mark Millard marklmi at yahoo.com