Date: Fri, 14 Feb 2025 19:48:33 -0800 From: Mark Millard <marklmi@yahoo.com> To: Kim Shrier <kim@westryn.net> Cc: Russell Haley <russ.haley@gmail.com>, freebsd-arm@freebsd.org Subject: Re: i.MX8 Support? Message-ID: <4CB221D0-BBDD-4D7D-A30F-0FC9897E76B6@yahoo.com> In-Reply-To: <6E9A8133-6621-4C60-836B-160119C882A7@westryn.net> References: <CABx9NuQxFsvgjx9_hfdgRq3hGBH_JiFL763pXtEjXm=H%2BSmS2g@mail.gmail.com> <B6AED154-00E4-41AA-9D38-58CFFDE4FBBD@westryn.net> <EEF91DC7-27E6-4D5B-9B8A-F0A8084100DF@yahoo.com> <6E9A8133-6621-4C60-836B-160119C882A7@westryn.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 14, 2025, at 18:25, Kim Shrier <kim@westryn.net> wrote: >=20 >=20 >> On Feb 14, 2025, at 6:44=E2=80=AFPM, Mark Millard <marklmi@yahoo.com> = wrote: >>=20 >> Russell may want to know: >>=20 >> Which U-Boot? --and which Linux mainline *.dtb ? >> Or is it working via UEFI/ACPI via, say, EDK2? >>=20 >=20 > It is working using UEFI. The system is a Traverse Ten64. Used as UEFI/ACPI (via EDK2? . . .)? Used as UEFI/DeviceTree? (Via U-Boot? Via EDK2? . . .) Some EDK2 implementations provide a user choice between ACPI and Device Tree. But Device Tree might only be a testing subset compared to a mainline Linux *.dtb file. It is unlikely that the board Russell referenced has a EDK2 UEFI implementation, either ACPI or Device Tree style. More likely U-Boot based UEFI/DeviceTree, with a then-involved *.dtb file (Device Tree Blob). Mainline vs. vendor specfic, including for the *.dtb involved is less clear. If the UEFI(/ACPI) is not built in, and the device is not a RPi*, FreeBSD support is normally based on U-Boot and mainline Linux *.dtb files of some vintage. Such may not exist yet in a FreeBSD compatible form for the board Russell identified. It is common for small board computers to have, say, a microsd card with a U-boot outside any file system (via dd use) and a msdosfs file system as well for the *.dtb to be used. (It and the FreeBSD kernel need to match.) microsd card use is not the only possibility. > I just used a memstick image like >=20 > = https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/15.0/FreeB= SD-15.0-CURRENT-arm64-aarch64-20250206-9ef38a01aea8-275290-memstick.img.xz= >=20 > but the actual one I used is from over a year ago. The details for the board Russell identified may well require different handling. Classically the FreeBSD memstick.img file style of installation does not deal with getting U-Boot in place: it expects the system to already have UEFI built in, like on servers. Such is not true for the systems used with the likes of: o 15.0-CURRENT armv7 GENERICSD o 15.0-CURRENT aarch64 RPI o 15.0-CURRENT aarch64 PINE64 o 15.0-CURRENT aarch64 PINE64-LTS o 15.0-CURRENT aarch64 PINEBOOK o 15.0-CURRENT aarch64 ROCK64 o 15.0-CURRENT aarch64 ROCKPRO64 and the images for those do have the U-Boot required and the *.dtb(s) required. The RPi* contexts are the only ones with U-Boot in the msdosfs, if I understand right for the current status. The others have it placed via dd outside the file systems in the image: FreeBSD-*-NAME_FROM_ABOVE-*.img.xz ( such as the pattern: FreeBSD-*-ROCK64-*.img.xz ) but the *.dtb used is in the msdosfs in the image. Note: The RPi*'s are unusual in this area and various of my notes here do not deal with the RPi*'s details explicitly. > After uncompressing the file, I dd=E2=80=99ed it to a usb stick. >=20 > After getting the serial console connected, I booted off > the usb stick and then did a =E2=80=9Cnormal=E2=80=9D install to the > internal nvme drive using GPT partitioning. >=20 > root@ten64-2# gpart show > =3D> 40 500118112 nda0 GPT (238G) > 40 532480 1 efi (260M) > 532520 490201088 2 freebsd-ufs (234G) > 490733608 8388608 3 freebsd-swap (4.0G) > 499122216 995936 - free - (486M) That does not leave room for the U-Boot at the beginning as far as I can tell. Most of the FreeBSD-*-NAME_FROM_ABOVE-*.img.xz have space at the "front" to hold the U-Boot. (RPI is an exception since the U-Boot goes in the msdosfs for that context.) FreeBSD-*-ROCK64-*.img.xz happens to have one of the larger spaces, making it likely big enough for being replaced by an alternate U-Boot without overlapping the partitions (or slices) used for the file systems/swap-space. (I've used that to advantage before.) By contrast, copying the ROCK64 U-Boot and related materials to other example FreeBSD-*-NAME_FROM_ABOVE-*.img.xz tends to overlap with file system information and partially destroy the file system involed. > I don=E2=80=99t recall having to do anything with a .dtb file. UEFI/ACPI need not involve a *.dtb file. UEFI/DeviceTree may or may not involve such a file? For U-Boot, instead of EDK2, a *.dtb is normally involved. U-Boot based configurations for FreeBSD is historically Device Tree *.dtb based. FreeBSD tends to speak of ACPI vs. FDT (a flattened form of Device Tree representation). If both ACPI and FDT are present, ACPI is the default for what is used --but can be disabled. > I have U-boot configured to boot from the efi > partition. Hmm. A system with UEFI/ACPI or UEFI/DeviceTree from EDK2 being built-in would not normally have U-Boot involved. For FreeBSD U-Boot with UEFI/ACPI has not been involved as far as I know, just U-Boot with UEFI/DeviceTree. U-Boot may have progressed to having UEFI/ACPI as a possibility for all I know. Overall, I can not tell the EDK2 vs. U-Boot vs. other context for you. But that probably does not matter. The notes still serve as background information to be investigated. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CB221D0-BBDD-4D7D-A30F-0FC9897E76B6>