Date: Sat, 27 Mar 2021 16:51:58 -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: <E975A3D2-3CA6-4658-8CAF-968BA9D031FA@yahoo.com> In-Reply-To: <2C868C60-80CB-4A4A-A12B-9CC0F3A1F531@yahoo.com> References: <21BE83BC-0667-44F7-83E4-1664A2BC6017@icloud.com> <2C868C60-80CB-4A4A-A12B-9CC0F3A1F531@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> 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. >=20 > The only aarch64 images with a pre-supplied u-boot > (or whatever all is involved beyond FreeBSD itself) > in the modern available images are: >=20 > aarch64 RPI > aarch64 PINE64 > aarch64 PINE64-LTS > aarch64 PINEBOOK > aarch64 ROCK64 > aarch64 ROCKPRO64 >=20 > 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. >=20 > 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. >=20 > You have not made clear if you have RAM size > or other requirements that could limit the > possibilities. >=20 > 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.) >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > /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 >=20 > 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.) >=20 > The Rock64's instructions (from the README) > indicate: >=20 > 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 >=20 > Note the seek for the u-boot.itb dd. The size > of the 2 files that are dd'd are shown below: >=20 > # 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 >=20 > (I've no clue how close this may be to worst-case > spread of u-boot + other-materials.) >=20 > 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. >=20 > 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. =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?E975A3D2-3CA6-4658-8CAF-968BA9D031FA>