From nobody Fri Oct 20 08:52:30 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 4SBddW6SlZz4xWtd for ; Fri, 20 Oct 2023 08:52:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.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 4SBddV6FMWz4HvZ for ; Fri, 20 Oct 2023 08:52:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PzjdI3Z5; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1697791965; bh=uiYnUy++UlCfnbOCPJPhIaRdsAIG/TODVXj+iVqdnKM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PzjdI3Z5ZsnSCW24uCS2x4hti+IjTqzHWi0bcTgu5uX8HktduYdynaF9JYq22kWl1QkiyOHxv/eaZrdiA7lPMb6FSdMRPjnMA21E2JrzPd+drodlVqMr5+MlgkpbzYgleZkk2UkfW4MgeLdadj1eM7Feaep3hWiR490uNTaa2jgUGlNr5FrU5jgNtM1TwUr6tx3z5slIVBcv69XTh4sMywU96fz5fzK9K+5HPph55yRQMIupZCDzS7J7fKe/dOU4H+idGGSlNAaQA1KkzUu48YNGkTPL94MADZUytt5bm1ZmpLa10hzvpFs7QfRHpeDcMn90BUjP4REVt6jmUQAdXg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697791965; bh=VdZwjg6N2a1vSY6I9x69RDMvv9BuHfJQA6KZOAGPUm4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lXfowuGM7rNu46CqkG+NVERLmVMTWv/SmrpbHSpz1ZwrgJXGD52C28ozLg8vMGpCy6mNvYyw+H9rTm04AxckC0S1RpX/cAvXfJaAwgqGCfbr0I+W3538Rg5mkSkvChphWklZParFQvgegYlEUncSsJX2UanzM5dwVLXT8N8FgA0oN6Qp8z6OSkZSzbDI5hIP6d54oSDu6qcNPR4D6XQD+Aln9GrgI9dDwfnIqLQ4/uTxrAfd/fveRMXbi3wxBflsguQeJHcdnecDPwQS2p2L6ioTyVqhpuNdHebG/liIcysYMcVDdeWNUBPqX4wRq3msIIMKtvk54a7jg61yXEGD8A== X-YMail-OSG: z1rOEXkVM1kvxJbd0T7dlJVJmlQQ6l_nDU6ppSDRRWcSgjJIc8N9fwchdQm_HbH 7CGVa_VHVKnVDR6aHTaC9r92RZbntDihG8huDvKTiwPL4Mgr_8JWwEyaeTQkXBUKmDlgdQEG17aK _4EeyhlIu4uZ00Z5etxzWqdZYhwMAK9EceSJoGe7wNzz6O8znKoUna9a6Wbuz69q8_YZiLmzdmH3 yJ5k7l3kZLXkkZC3dIO1J7RMiT1H0pzHNPeMGHleXdxR5KmU2hlnsl2pmBwl0mbXv2A.gdStpjp9 9iY_8i92dZyUfwK2Rnw75iR_u0XEVqO9OghaAy55NDjKgQieAiGzLH3fLXsCCASZQ.f9bEg1KEbh Ch6hY_l1qezzDUvQJH.lYcqbWX7rBvBBcBXB4PZPKR8sKBHK0_h_qakCtFgzB5aZRo8TKBSOFv9x 5kjsisw52vS6AsDG2UeeJL.EfaMvdxKd_qMsH8VdRLeu7QsPpTeXcnCb9D_YM0g_OFE6BRMiQt9k Ttb.v8jn1Bitc7tzimZHhHWGkR1EZo8xIhUhdWV5GamaIs1J0Uo5iU9QSGmqOJ.D6yHJI0nEN46U DmZMAu5_mOTr_T0RXqhLG8WsaQdPRUJppWjFrWOHsKfE26j0yKO426szxp38BQn3sqyb0XzNv5NG YQjkr.OSsWuwPOh3dZmJMqOdyAEgfFpvzX7lef.Mhs9S.5JZGW7HDj5UBQJDuOYJEfQcDhwd7jF7 YpFOmGkSeel_ZGpJStM_eLFXO40MuLIsYWm8n3zIQ3cA0rzzvVkvYFcaHR_CaIwHLRAkAny63SPd we4qQHMw8bNESsHi4QUn5vTjSp7vZcPXjgqY8PUDecU2kAiWtY8tKqCADIaKaO9cGPj.QrwYjYHE Iz2zOEFnhHUXdPUjmoxdXFN_5267O2SmDaM1sNNHUbbsDXHmuotmmTCs3FEwfq28X5Q9DglCzg86 NTvEQEv8en6egkPGE.RY5aImwpg.VzKPwN9d7NYcSR8o3_IuauIeQkig4dvP1EGqw4QDVVCcbnT8 Laq3EcFHSwfq0C4KUsQP1ewfLYQg1C2ixf2Kn7V5FAaPhlJpqzgVAbbbQlLXd3adDSntInvz0xBk SDLKqxwOKeBI.nKqsQXau8iAwEGC6GOEO5JZ0wFry3XSD3FrXyg2glrP2f0wHTJmX4diU4G1AEga uPn1dC7cVZ9Px.F04_9uNGOk.OqP8p86AnvC2EBK0VPBZN5.P214WOEZb.3uQQeIPkiePea1Ya2X 7l1JhZwa2fRZ47rirmACcQGc1o4ErRnJU60icOS8Y8tC7B43oHafQujdOjFVoXDumxd9jrOK9ugG APDCBN_rJuVBMkhKDpc8yGz1GjL3dle1QKd03f4VnK52l5.7pbAi93n7e5I.qnFK4WukmHMtsKJ8 noekm0RySnzZXBy6kNZbRVzK5.SCz0zckYQrFB4p5WCermvlyhfLb741arBpn7fh7oHxZiuLabgR 7mhfHIqQ2UUY1pmszKWrGW2_l5IJXLTwcIunshrwWAg2yCRL1sg8ujQCwIgoknwZHyl1Y9RGskHD 1vRGX5g6c_iDQiO516Ggym1s2oiWs7DZN4Ig25EXSl_.M3ueM8fnNHAhu8GIhYwNFHcNJtxmCw19 n.iUfqxjoV_SpKZkX_ONvyHxTeAFpbkuoPy2LJDY7czK44TkNsPSe_NFV8oYUsYg9MihfRUehBOU VZ55gB9t1uj.ckMHgqpDPnWec8nziKkGr2S3IXI5PrdOQ33SrZIAHvQWDB7XGLg_UpAQvZJDWXTb 8YAgAemk.8wqAsfKdI2HXf49xj9u2VU0tVzBhfL7_u9EPG_DIZvlZZan0wuhw7aUK_rPwuCoWlta DnzjEAdgHyT8CjLzhlzGTXCvmHJh.O0DSoR5OQf45YPic_9t1Y8jDmP0jR5LmDsZsCAuDmbu_pii MEoTuoBXaLlhyJeWXQXoaUOgzTVdbc95LPkeRkk4vgpV8rdeGQRbtWeOlwSXdGBKaEbmww9Urk9G NYWEfmwIC5LUgwJ4EW5byGmfZPAP089QJzpR4O3wvKhQ3HucEEpLjjKwxDpjZpUq6.F8d9RklHau yhY9GGfgv6PRsaG5ytTokXEkd6po8GoIYSXamIVnxf.jnTyP0i3kXw3X1KDXZuRmQnkQojsh.E2x bwjJyHf7rF9PliuoblIy4yHti7pihTkcn23uFmK8q_7p9F8K7AZ0lSFaYF9ohtHlZ.cduz4hcJ6W hUWlUuMjAV10VpSJeTViLCwEC8Y4S8gDv2lHwArbnwv8ZprKkRG_a2zvrxsf4mD9Y9eWasFAhqA- - X-Sonic-MF: X-Sonic-ID: fd9eb5f9-c0d2-40c3-9616-b2a951d19f08 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 20 Oct 2023 08:52:45 +0000 Received: by hermes--production-ne1-68668bc7f7-lchlz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6620741789eaae001a41917b163ad4be; Fri, 20 Oct 2023 08:52:42 +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: Date: Fri, 20 Oct 2023 01:52:30 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3D73D35C-ECD8-4280-85C7-5B9ACEF0331C@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> <6770937E-CBA2-4B50-AD7E-71707E36BFF1@yahoo.com> To: Rahul Rameshbabu X-Mailer: Apple Mail (2.3774.100.2.1.4) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; BLOCKLISTDE_FAIL(0.00)[98.137.65.204:server fail]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_TO(0.00)[protonmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SBddV6FMWz4HvZ [I've dropped Warner from my CC.] On Oct 20, 2023, at 01:44, Mark Millard wrote: > On Oct 20, 2023, at 00:39, Mark Millard wrote: >=20 >> On Oct 20, 2023, at 00:31, Mark Millard wrote: >>=20 >>> 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 > Hmm. Linux reports: >=20 > # file -s /dev/sda1 > /dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", = sectors/cluster 4, Media descriptor 0xf8, sectors/track 32, heads 64, = sectors 524288 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1020, = reserved 0x1, serial number 0xf92becc, label: "boot " >=20 > I must have misinterpreted what "newfs_msdos -N /dev/da0s1" reports > when /dev/da0s1 has an already exiting file system. >=20 > Sorry for that and the resultant bad example. >=20 > For completeness, FreeBSD reports for that media: >=20 > # file -s /dev/da0s1 > /dev/da0s1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID = "mkfs.fat", sectors/cluster 4, Media descriptor 0xf8, sectors/track 32, = heads 64, sectors 524288 (volumes > 32 MB), FAT (32 bit), sectors/FAT = 1020, serial number 0xf92becc, label: "boot " >=20 > Generating a valid example using, instead: >=20 > = FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20231019-fb7140b1f928-266042.img.xz= >=20 > expanded and dd'd to media: >=20 > # file -s /dev/da0s1 > /dev/da0s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 = ", sectors/cluster 8, root entries 512, sectors/FAT 50, sectors/track = 63, heads 255, sectors 102400 (volumes > 32 MB), serial number = 0xc90a0d0f, label: "EFI ", FAT (16 bit) >=20 > I just used that to boot 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 > . . . The console log for this shows that the RPi* firmware reported: MBR: 0x00000800, 102400 type: 0x0c MBR: 0x00019800,468757680 type: 0xa5 MBR: 0x00000000, 0 type: 0x00 MBR: 0x00000000, 0 type: 0x00 Trying partition: 0 type: 16 lba: 2048 oem: 'BSD4.4 ' volume: ' ^ ' rsc 1 fat-sectors 50 c-count 12783 c-size 8 root dir cluster 1 sectors 32 entries 512 FAT16 clusters 12783 >=20 > Thu Oct 19 05:57:02 UTC 2023 >=20 > FreeBSD/arm64 (generic) (ttyu0) >=20 > login: root > Password: > Oct 19 05:59:46 generic login[1474]: ROOT LOGIN (root) ON ttyu0 > FreeBSD 15.0-CURRENT (GENERIC) #0 main-n266042-fb7140b1f928: Thu Oct = 19 04:52:33 UTC 2023 >=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 > I accidentally had used what was actually a FAT32 context: > bad example. >=20 > The rest of the types of notes should be okay, including the > corrected example. >=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 >>=20 >> One more point: the 1st Capture.JPG image shows: >>=20 >> c-count 0 c-size 0 r-dir 0 r-sec 0 >>=20 >> As I understand it, that is showing that the information was corrupt >> as read: valid FAT16 would not have that combination. >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com