From nobody Fri Oct 20 05:30:59 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 4SBY8w6pvPz4xKpj for ; Fri, 20 Oct 2023 05:31:12 +0000 (UTC) (envelope-from sergeantsagara@protonmail.com) Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SBY8w4nfWz3VPf for ; Fri, 20 Oct 2023 05:31:12 +0000 (UTC) (envelope-from sergeantsagara@protonmail.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1697779869; x=1698039069; bh=PpkHHDZGET6g0zcKfyqJmJIGlblSCDJtXFaPZirzC70=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XqYxH6CtB9z5hXz4TQqnkYU4Ccx5/b8QoFw8M+MslB0sfT1b6JHcTOxifNP+j9UDL Mh+wI6Ig7xN9evwmVOLnk8Nihdm5kcLc8HhustGp6CWMjK3zU+hDM2bgWBkvTGqeNB fEM6L7y78lZ+WQRQk0enZ/qpiQycuNSknuX47B0dwnleqlLWXX8BHEK+A5PVe5qOIr MVWdwtczFK4gb2PRh5SRqsDmyCFdE10fZhN5tUUModnqtI9jCuozHnWhslXLHePdTX VDtyxUgPRzCJghaxuIJDpdGMBTcipAvdpEpGRc3Bd7AMadcafUXoHCwnVcPiOE7nHh +i6/OQEYHHRyg== Date: Fri, 20 Oct 2023 05:30:59 +0000 To: Mark Millard From: Rahul Rameshbabu Cc: Warner Losh , freebsd-arm@freebsd.org Subject: Re: State of the freebsd/crochet project? Message-ID: <8734y5amia.fsf@protonmail.com> In-Reply-To: <33693188-5C53-4C9E-8F67-647655E957BD@yahoo.com> References: <87ttqrqnal.fsf@protonmail.com> <87wmvjjkae.fsf@protonmail.com> <33693188-5C53-4C9E-8F67-647655E957BD@yahoo.com> Feedback-ID: 26003777:user:proton 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Queue-Id: 4SBY8w4nfWz3VPf On Thu, 19 Oct, 2023 00:45:25 -0700 "Mark Millard" wrot= e: > On Oct 18, 2023, at 21:41, Rahul Rameshbabu wrote: > >> On Tue, 17 Oct, 2023 09:01:33 -0600 "Warner Losh" wrote= : >>> On Tue, Oct 17, 2023, 7:44 AM void wrote: >>> >>> On Tue, Oct 17, 2023 at 07:13:28AM -0600, Warner Losh wrote: >>> >>>> Crochet has no active maintainers. Most people have moved on to poudri= ere. >>> >>> Does poudriere handle the msdos uboot *and* efi part when >>> creating the image? >>> >>> Yes. I worked with manu years ago to put all the needed metadata for th= e different boards into the ports... >> >> 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 > > 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): > > 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 > > FreeBSD release images are also build with such: efi partition > type and a FAT16 file system. > > Looking at a (my abbreviation) RaspiOS64 boot media used to boot > the RPi4B's (official RPi* media content, not FreeBSD materials): > > # 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=3D= 512 Media=3D0xf0 FATsecs=3D128 SecPerTrack=3D63 Heads=3D255 HiddenSecs=3D0 = HugeSectors=3D524288 > > But it does have a partition type of fat32lba: > > # 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) > > 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 ? 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. 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. * https://forums.raspberrypi.com/viewtopic.php?t=3D278295#p1685235 * https://github.com/raspberrypi/rpi-eeprom/releases 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. 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). On a side note for myself, might be nice to throw the rpi-eeprom tools into a port for others to easily grab. > > Or may be you are referencing the partition type (expressed here > in gpart terms), instead of the actual file system type that is > contained? : > > efi The system partition for computers that use t= he > Extensible Firmware Interface (EFI). The sch= eme- > specific types are "!239" for MBR, and > "!c12a7328-f81f-11d2-ba4b-00a0c93ec93b" for G= PT. > . . . > fat16 A partition that contains a FAT16 filesystem.= The > scheme-specific type is "!6" for MBR. > > fat32 A partition that contains a FAT32 filesystem.= The > scheme-specific type is "!11" for MBR. > > fat32lba A partition that contains a FAT32 (LBA) > filesystem. The scheme-specific type is "!12= " for > MBR. > > (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.) > 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. >> , so the boot partition >> needs to be FAT32. >> > > 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. > > Is there a chance you are using so large of an msdos file > system that a FAT32/FAT32LBA file system is a requirement? 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. -- Thanks, Rahul Rameshbabu