From nobody Fri Oct 20 07:31:50 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 4SBbrS33wGz4xSJ1 for ; Fri, 20 Oct 2023 07:32:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (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 4SBbrS0WmHz3dYN for ; Fri, 20 Oct 2023 07:32:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697787125; bh=YpzSkHdl7Yr0k0vlXekB4Woqgabsg/R2u4eBeTgbTmw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iDHB3Bg03KtAxezSr2NvxJWIp+deILMFwbDq3fJRO3PG3rNITrIXgPVEg181FkoxRVruF3ilwfkS4IWQfvNrkaZBhfy4tBiij99xduQDVTA420ChUaI/edu750gaV9MgxfkGUZr4FvEDqZj24oo9tn41I5QMf4LXqLeBvW3k68QJcv7wjmRujZ7P2dXYjvxJ6BH/F9pfnPzMrVpfBqY68zx/fX+PW8lZZ16p8JAWv1eGy7418zdAlS6CI6YZQzCmtktlllzjlaKL3b8jtGlF1N4thfayZkyfRnK82OLPIqW3UsvXTMNNk+gDq/uFRCLqF4FyeNzb/thPVFJ8nX7nRA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697787125; bh=ezvnZhn+G3nIp3DuqxOsCKMV6TmURvowOxW9NH0Iu/J=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=m1STUwNcGGuxqu4G9Y/r+gAeOuRV9psks2F8nYtrL7nzhWnzwru/mybgFjVWEay05t2to1QzuKHGnT2np0xrrM5OLn6WscDwMqk+T4nQ7EMm/6bODDnLByZfrNpLm0BC5U3ES7WJ9CUQw7Ha+UwD6FyY/55bNnJYD78Kl8XxHtJm0BrHAxj7IT7R+sH8cfHdG7sbtwuQMXHtL6CqSqibGzelLXPoFh51K5++AKu89fezSloG+/of0cN+9YY5nw4Py6/Ye7oI9xnBNAi77H2tZjqr6pmZLo74cC/8pDkoGcwiSVTS/NgSrdsADpBwQG60bVVlTgNeWlPp0CMNlpLdvA== X-YMail-OSG: Rr0SFsIVM1kM8E4VtmlMzT_n0nL7Z8ee4IG6cYzZ0eBdn.F.e1hkfMB28aV0aUa sZg83bxYiklHtKWP2yNcH6j_M_xyT00i_zoTfmypMoFsWg2Oy33a9xJAPDB9anwXQLkkAuyUSZKt EnGDRoSggiZN.bdWoQEI.02JqY8CHjmWtdDFF1.MgT7HcdKH8WVLWMAenW8GRwqgis.iPpsC4heo 3wDqQaTlekYSBAbsMf7eDMC6wTAMqX7szI637iu3KfCHvCvrxX8PnuGkaAayTHo00I0vjauF1VxW 8K2OKArVJ2YGhEk3cZRVkHhRhxwrly8.X08uSImyHt7Q5Zyu.H19GCRLoZDveMZWbgeNPPhvMSjG A0VmgsIUSkDVCFnGwPlhafqc.KqY.mq_MQmudSYgDrJ6NLwN0gS4GyMcv.Q3Fwzu8w9OWUpO9VDD xrc0hT5Pn49biAc12JpStW3rUjfWxNgmi41hW2p70lTlReEyxyMHfCDrSSgK3iZkI20p2pQ2zghT xZwnlO84E43KP94UcJ4GAkSWw9NYI_9WpJv9vmuF6WqKcgvOj5y1GAPYZxk_Opllyo6.tG_dYSFz cQG8EhBJivvepgm1w8N.nZikrnZBaC4GgF._3yxvbokKpulf8mKtci7C2X9xa75HalPvUGaV1AVo TBVE7VMU7utlvUIUqRCengOhqWpIxYOB9UunRnQPlr5FTJs8ojE.7ZwKKwCePeB58tRfbnjGeN1p b5a0YPy3CnL5497wefKyYNSkMTcIa78_oiG9GCSp1v954NutsLhfiUyGnyhN1vzptm9zllo6Ng1T UYsZwKmae4XGHlQ7qEz63NgEYTFW9tf5Eg0hno.fyWoASconF_6Dg6Ij405FLv7Glzg1pYOZwdLN idmBRkT7.BY.NPyRafYX3yzcjRtHEcISnIROBThOFFX4uNXY0AKOg7FvBrl4EVNDfyxcoSA1KBxg uDKCtGvPZPRnyZFX5__.dZIvIDS3XuuA_h8UMfqSR.dAF6NQlfkZ8ba_0oFXRS9aLQZfBt21iyYR 0wQEvSIzTVV73emV7Ac_4PmQ4WnOvJseUqXdLdmtX8pTRe1yvW4L.4XD0x6UFFJtsUwYw6dQS__q xq8J2rOTayls3x2HH6NB62Fg7uFBeDSmpwEw4gJOrysXUgiCQwJOBD3qt5Tv_9XTt_YqJwOAu7Rf .cnss984yxWS_5yZ2sYlnFqlxReI52M45iXdcrrrrfkYPHhECkzrjHPUw67o9Xy.xfhf0LGXY1qC ZH_4gEFaauGhILaqsfpc9em3HlbpGugbsznpr2gi3yRArpn7ggqvjES.QhhfvS_udG0J3efENrc8 ZCvKvcrkSqlaFTTePme3tl8Q55U4Crsdu4BjmTWqhm33vXtM_KTGy_A1ni9TLNBYCdJaqtS2wh2o KTIctVEQA6SYHEUpWGqwr4w96uhI.NqW360gHQfhlVFxNoesHluEstnrwWUeZxDglHAi8S3syYEw rXV12awmNtQ98EgABIhDjkvE2JEOfJWSVGrVuxpHIwzgAnzhD5Vi8VhMZGzYXVXjAMSqMOQbr0yp YW4AfQBSg35xR08P.4G771Z8Q984kk7Kink6vc1HMoonR_MCcmdDt9cyMbO1hkDHkrv9_abTUVf6 pdIbcsZs6OIq_z0XzD1sI3Vi1jNgWwmgtNa15E.9jwYrntx2SYAivM_suvM9oBAkVj3Mruw5qfek PKGTT3DZZWR0ek1H5KfcQwzQLgQ2fHKh082SHohpNquivmestb6XV.aqWBNht8DcpuWOGNYPD6TT 1dCXDVcDKby.Ja7z1tlVIYj0F2.l_3aS5wVr9_UFsSe9cgNJ2.6Is_ISKZHTXsTvSYAvz9PE.cpl 77Vm9JEkuN.J.aZ9CH2cfiETlIK8VKSaPD98WhyCXUT0vAVuOvjaCQgLtUA8N1l6ngcEItAlAohf Xah065Ax5JUl7L5q0qP1aHDJ6FgIaaScWhl2k91_L_kvg5.cTu7leDTTvLU9GqVLDDBO_B.QNMpt bgX5QGZU8VApk5cfrzOx17LUklm8XHxD0c7aadj6Lt5g5jrMV3KcXMSv0KgCQqWs2A5MVgeDDcHj HYYQkN9H99V.3JdqVr2zTr5jPgpOy.e3trInv8M4Nrybuq6GDR07w2vnwcYRpMGKm3WeHjgLLtux YaMgBqImXtt8PS5WadVzCXPux8ZCQ27O2ImcjWGDF9hpDfnZYA48KBESyAarrl8a5et_KUrpFOpo Ci5FFGXG76pp9lHy_7HM5Ecge.BmsKhsAAU0xCJnXNDJ_qir3RuAqii__KfjoBO5hkOKLosSuFei N X-Sonic-MF: X-Sonic-ID: 330ab860-eb13-49c9-9f53-458e5f119868 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 20 Oct 2023 07:32:05 +0000 Received: by hermes--production-ne1-68668bc7f7-mqln8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e63c50564613fdae7980310b998095b6; Fri, 20 Oct 2023 07:32:03 +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: <8734y5amia.fsf@protonmail.com> Date: Fri, 20 Oct 2023 00:31:50 -0700 Cc: Warner Losh , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <19481390-118F-4527-BEDC-9935C695A27D@yahoo.com> References: <87ttqrqnal.fsf@protonmail.com> <87wmvjjkae.fsf@protonmail.com> <33693188-5C53-4C9E-8F67-647655E957BD@yahoo.com> <8734y5amia.fsf@protonmail.com> To: Rahul Rameshbabu X-Mailer: Apple Mail (2.3774.100.2.1.4) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4SBbrS0WmHz3dYN On Oct 19, 2023, at 22:30, Rahul Rameshbabu = wrote: > 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. I just booted a RPi4B Rev 1.5 "C0T" part that has: 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 off the (what I call) RaspiOS64 media that I referenced earlier. That means FAT16 with a partition indicating fat32lba. There have been bug fixes, such as the 2022=3D01-31 EEPROM release that reported: "FAT/GPT fixes and file-system performance improvements." > 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 At that point (2020-06) there were only 2 tagged EEPROM content releases: v2020.04.16-137ad v2019.09.10-137ad There are 11 from after 2020-06. > * 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. 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. 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. 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. > 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). I've not tested the 2023-10-18 release. > 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 =3D=3D=3D Mark Millard marklmi at yahoo.com