Any good alternative to Raspberry for Arm64?

Sat Mar 27 21:49:16 UTC 2021

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. 
> 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=/usr/local/share/u-boot/u-boot-rock64/idbloader.img of=/path/to/sdcarddevice seek=64 bs=512 conv=sync
dd if=/usr/local/share/u-boot/u-boot-rock64/u-boot.itb of=/path/to/sdcarddevice seek=16384 bs=512 conv=sync

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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)