Date: Sun, 28 Mar 2021 16:12:19 -0700 From: Mark Millard <marklmi@yahoo.com> To: Denis Ovsienko <denis@ovsienko.info> Cc: freebsd-arm@freebsd.org Subject: Re: Any good alternative to Raspberry for Arm64? Message-ID: <74820291-0E4B-4047-B6D4-7A25C1E2E340@yahoo.com> In-Reply-To: <20210328222330.26dd034c@basepc> References: <7b284f7718556f1cf0a7a205c98db6b1@pyret.net> <8F8F3491-3E1F-45C8-BF61-09F7557F48A5@googlemail.com> <4F30ABFD-66D2-4515-A3BB-F13F767F8FB9@kronometrix.org> <20210328212009.1b6b3ad98f26256a3490b063@bidouilliste.com> <D11EA82A-8739-4BE6-8910-8D0952180661@kronometrix.org> <20210328222330.26dd034c@basepc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-28, at 14:23, Denis Ovsienko <denis at ovsienko.info> wrote: >> I meant, does NetBSD has a better support for BLE, Wifi on ARM64 SBC >> than FreeBSD? More ready images available for different SBCs? > > Ironically, the latest NetBSD release does not support RPI4B (RPI3 is > acceptable). NetBSD-current does support the RPi4B but you need to to use the EDK2 UEFI/ACPI firmware, such as adding it to the Generic 64-bit image's installed materials. (I've used RPi4B's via NetBSD on and off for a fairly long time, but mostly as a cross check on behavior.) NetBSD-current got GENET support (EtherNet) in the EDK2 UEFI/ACPI context back on 2020-Feb-21 (date announced, asking for testing). NetBSD 9.0 was announced 2020-Feb-14, while initial support of the RPi4B was still being worked on (before GENET was available, for example). The RPi4B has not been subject to an MFC-like operation to my knowledge. > Also ironically, the latest OpenBSD release supports RPI4B, > so long as you are happy to supply a separate UEFI bootloader, to run > the installer through the TTL console and to keep the root filesystem on > USB storage instead of the SD card. > > I had looked into the other BSDs' ARM mailing lists not long ago, and my > impression was that RPI4B progress there is going through a similar > churn (this revision of this DT file plus this revision of this > bootloader fix this thing on this Pi model, but break that thing on > another model, and the other way around the next week). > > Fortunately, my use case is a headless setup and requires only the wired > Ethernet connection, so I managed to get Linux, NetBSD, FreeBSD and > OpenBSD on AArch64 using a set of RPIs. If your use case depends on > other hardware (USB, GPIO, GPU, wireless etc.), flipping between > operating systems will likely trade one surprises for others, but will > not take RPI4B away from the bleeding edge immediately and completely. I've always booted NetBSD on the RPi4B's using USB3 SSD media for the root file system. Any issues seemed to be tied to RPi firmware vintage problems and I controlled what vintage I used to be that known to be working well for the EDK2 implementation. (The issue is not NetBSD specific.) I also updated to not needing to use microsd card media at all for booting when the RPi4B updates to support such were made. (I currently do not have a NetBSD RPi4B configuration set up.) > RPI3 seems to be old enough to be supported everywhere, but it is > notably slower. Other SBCs may be better supported, but I don't have > this information. > > One thing I find useful about FreeBSD on RPI4B is that it seems to work > 2-3 times faster than Linux and OpenBSD given the same workload, which > is C compilation with ccache on tmpfs. The difference is mainly due to a > very fast Autoconf stage on FreeBSD, the main C compiler performance is > actually a tiny bit lower. If one has the heatsinks, fan (cooling), and appropriate power then a from scratch buildworld buildkernel with "Not bootstrapping a cross-compiler" and "Not bootstrapping a cross-linker" status that only targets code generation for aarch64 and 32-bit arm can complete in somewhat under 7 hrs. To get this I use: over_voltage=6 arm_freq=2000 sdram_freq_min=3200 force_turbo=1 in config.txt . It appears that not using force_turbo=1 but using powerd eventually ends up with force_turbo set anyway and the times work out nearly the same. I'll note that an RPi engineer/forum-moderator published on on a RPi forum that the RPi4B's are not subject the the warrantee bit being set for for force_turbo use with over_voltage use. See: https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=283911&p=1719405 My context has USB3 SSD media and 8 GiByte of RAM for these results. I expect 4 GiByte to not be much different. The context is main [14] built without debugging facilities, running a build that was also configured that way. (Letting support for all the default instruction sets build added about 0.5 hr to the build.) With neither force_turbo=1 nor powerd set up, my build times were somewhat under 15 hr 45 min. So there is more than a factor of 2 difference in the times. For those not wanting to overclock, just adding the force_turbo=1 or use of powerd should get such a build down to more like, say, 9 hrs, presuming the media used do not slow thing significantly. This ends up being based on an implicit/default arm_freq=1500 . (The time estimate is based on other's reported build times, not on my testing the combination.) === 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?74820291-0E4B-4047-B6D4-7A25C1E2E340>