Re: Any good alternative to Raspberry for Arm64?

On 2021-Mar-27, at 14:49, Mark Millard <marklmi at yahoo.com> wrote:

> 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.

I should have noted that my small board computer
use is normally serial console and ssh over EtherNet
based: headless, soundless, and so on. My notes
about what "has worked well" has a limited context
of use involved.


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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"