Date: Sat, 27 Mar 2021 14:49:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: Andrew Mitchell <andy_mitchell_fr@icloud.com> Cc: freebsd-arm@freebsd.org Subject: Re: Any good alternative to Raspberry for Arm64? Message-ID: <2C868C60-80CB-4A4A-A12B-9CC0F3A1F531@yahoo.com> In-Reply-To: <21BE83BC-0667-44F7-83E4-1664A2BC6017@icloud.com> References: <21BE83BC-0667-44F7-83E4-1664A2BC6017@icloud.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-27, at 10:26, Andrew Mitchell via freebsd-arm <freebsd-arm = at freebsd.org> wrote: > Hi everyone, > I've seen that there are arm machines for FreeBSD other than = Raspberry. I've been using it with 14.0-CURRENT, and my skills are too = limited for patching it. So, I've decided to find a machine on which a = RELEASE or STABLE version would work. To my knowledge, and after many = tries, it seems that there are no FreeBSD working smoothly on RPI4 B.=20 > So, if you have any suggestions for a working FreeBSD on any machine, = I'd be grateful. > I won't discard 14.0 CURRENT, as I've done quite a few things which = were much fun. It's just for getting other experiences. The only aarch64 images with a pre-supplied u-boot (or whatever all is involved beyond FreeBSD itself) in the modern available images are: aarch64 RPI aarch64 PINE64 aarch64 PINE64-LTS aarch64 PINEBOOK aarch64 ROCK64 aarch64 ROCKPRO64 Beyond those requires establishing an appropriate u-boot(+) on the media. It is not clear if you are comfortable with doing such activity. If not, you may be limited to the above alternatives if you are to use FreeBSD. Unless you start from scratch in order to update, as far as I know you are always responsible for updating u-boot on media once the initial u-boot becomes too old to work well. So, long term I'm not sure that you can avoid dealing with u-boot updates if from-scratch-updates is too extreme to deal with. You have not made clear if you have RAM size or other requirements that could limit the possibilities. Do you want to avoid doing your own buildworld buildkernel installkernel installworld activity going forward vs. using a form of pkg update that also updates the operating system? (This might go with avoiding patch activity.) Probably within the next couple of weeks the 13.0-RELEASE builds of the above should become available. For now there is the 13.0-RC3 . When I tested a microsd card with the image dd'd to it, it booted the 8 GiByte RPi4B just fine. I've not tried a Rock64 image but probably could. (I normally do my own non-debug builds of main [14].) I do not have working hardware for the others in the above list. Since you have one of the above devices, if you get it working temporarily you can use it to help bootstrap a different type of device if you are switching, such as installing pre-built ports that supply u-boot materials that you could dd to media. Otherwise you might be making the media via a different operating system. The list of u-boot ports is long but a lot of them are for older devices. (u-boot-master is material shared by the u-boot's for devices. The ones with *qemu* names are not for hardware. I've not tried to avoid listing armv7/armv6 contexts as well.) /usr/ports/sysutils/u-boot-a13-olinuxino /usr/ports/sysutils/u-boot-a64-olinuxino /usr/ports/sysutils/u-boot-bananapi /usr/ports/sysutils/u-boot-bananapim2 /usr/ports/sysutils/u-boot-beaglebone /usr/ports/sysutils/u-boot-chip /usr/ports/sysutils/u-boot-clearfog /usr/ports/sysutils/u-boot-cubieboard /usr/ports/sysutils/u-boot-cubieboard2 /usr/ports/sysutils/u-boot-cubox-hummingboard /usr/ports/sysutils/u-boot-duovero /usr/ports/sysutils/u-boot-firefly-rk3399 /usr/ports/sysutils/u-boot-imx-serial-loader /usr/ports/sysutils/u-boot-master /usr/ports/sysutils/u-boot-nanopi-a64 /usr/ports/sysutils/u-boot-nanopi-m1plus /usr/ports/sysutils/u-boot-nanopi-neo /usr/ports/sysutils/u-boot-nanopi-neo-air /usr/ports/sysutils/u-boot-nanopi-neo2 /usr/ports/sysutils/u-boot-olimex-a20-som-evb /usr/ports/sysutils/u-boot-olinuxino-lime /usr/ports/sysutils/u-boot-olinuxino-lime2 /usr/ports/sysutils/u-boot-olinuxino-lime2-emmc /usr/ports/sysutils/u-boot-orangepi-one /usr/ports/sysutils/u-boot-orangepi-pc /usr/ports/sysutils/u-boot-orangepi-pc-plus /usr/ports/sysutils/u-boot-orangepi-pc2 /usr/ports/sysutils/u-boot-orangepi-plus-2e /usr/ports/sysutils/u-boot-orangepi-r1 /usr/ports/sysutils/u-boot-orangepi-zero /usr/ports/sysutils/u-boot-orangepi-zero-plus /usr/ports/sysutils/u-boot-pandaboard /usr/ports/sysutils/u-boot-pcduino3 /usr/ports/sysutils/u-boot-pine-h64 /usr/ports/sysutils/u-boot-pine64 /usr/ports/sysutils/u-boot-pine64-lts /usr/ports/sysutils/u-boot-pinebook /usr/ports/sysutils/u-boot-pinebookpro /usr/ports/sysutils/u-boot-qemu-arm /usr/ports/sysutils/u-boot-qemu-arm64 /usr/ports/sysutils/u-boot-qemu-riscv64 /usr/ports/sysutils/u-boot-riotboard /usr/ports/sysutils/u-boot-rock-pi-4 /usr/ports/sysutils/u-boot-rock64 /usr/ports/sysutils/u-boot-rockpro64 /usr/ports/sysutils/u-boot-rpi /usr/ports/sysutils/u-boot-rpi-0-w /usr/ports/sysutils/u-boot-rpi-arm64 /usr/ports/sysutils/u-boot-rpi2 /usr/ports/sysutils/u-boot-rpi3 /usr/ports/sysutils/u-boot-rpi3-32 /usr/ports/sysutils/u-boot-rpi4 /usr/ports/sysutils/u-boot-sifive-fu540 /usr/ports/sysutils/u-boot-sinovoip-bpi-m3 /usr/ports/sysutils/u-boot-sopine /usr/ports/sysutils/u-boot-sopine-spi /usr/ports/sysutils/u-boot-tools /usr/ports/sysutils/u-boot-utilite /usr/ports/sysutils/u-boot-wandboard As I remember, there are some variations in how much room was needed for u-boot (plus possibly more dd'd to a separate places). So partition layout can be part of what has to be figured out. (Unless one has an idea of the worst case and just sets up to allow for it even when it might not actually be in use for a specific device.) The Rock64's instructions (from the README) indicate: To install this bootloader on an sdcard just do: dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img = of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb = of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync Note the seek for the u-boot.itb dd. The size of the 2 files that are dd'd are shown below: # ls -Tld /usr/local/share/u-boot/u-boot-rock64/* -rw-r--r-- 1 root wheel 359 Jan 29 12:14:54 2021 = /usr/local/share/u-boot/u-boot-rock64/README -rw-r--r-- 1 root wheel 103675 Jan 29 12:14:54 2021 = /usr/local/share/u-boot/u-boot-rock64/idbloader.img -rw-r--r-- 1 root wheel 779132 Jan 29 12:14:54 2021 = /usr/local/share/u-boot/u-boot-rock64/u-boot.itb (I've no clue how close this may be to worst-case spread of u-boot + other-materials.) I'll note that the RPi* do not use u-boot or other materials in such an area. I've used this to have one media that boots both an RPi* and another type of device: I installed the alternate's u-boot/whatever as well as RPi* capable materials, both using the same UFS root file system. I used labels and such to avoid machine specific fstab contents and the like. I took care with any environment specific content in FreeBSD, not much for my use that needs to be adjusted for swapping where the media is used. I used a PINE64 (non-LTS) for a lot of years before it finally failed. I have access to a Rock64 and some RPi*'s as far as aarch64 small board computers go. The Rock64 has worked well but my way of mixing a USB3 SSD, removable eMMC (removable while powered off), and microsd card use on it is not a normal configuration. But it means that I have the microsd card slot available for fiddling with microsd cards any time that I want: not normally used in booting or in standard operation. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C868C60-80CB-4A4A-A12B-9CC0F3A1F531>