> Looking at the --supported list in arm-image-installer I see a bunch of > the NanoPi variations, except for the one I have (from work), the > NanoPi-R1. > > I was able to get Armbian running on it without any issue, and it's > running quite happily. However, I would certainly much prefer to run > Fedora. > > To that end, what would it take to get Fedora onto the device? There's no upstream support in U-Boot for the device, in the upstream Linux kernel there is a device tree, so you may be able to use a 3rd party U-Boot but YMMV.

> I've been using Wandboards, which I've liked, but I discovered that what > I > was using just wasn't powerful enough to do what I wanted to do.. So I > was looking for replacements for my wandboards. I have a handful of > these > R1 devices from work, so I've been able to play with them and verify > that, > yes, it can do what I want and perform much better than the wandboard > quad > did. The R1 is based on a Allwinner H3, it's a quad core Cortex-A7, it's not really any more powerful than the quad core Wandboard TBH.

> Let me turn this around; what board (with case) would *YOU* recommend > for > some small, low-power arm-based server platforms? I always reply to that with the question what are you doing with them? What are your feature requirements? Eth? Dual eth? WiFi, etc.....

On Tue, November 30, 2021 8:53 am, Peter Robinson wrote: >> I've been using Wandboards, which I've liked, but I discovered that what >> I >> was using just wasn't powerful enough to do what I wanted to do.. So I >> was looking for replacements for my wandboards. I have a handful of >> these >> R1 devices from work, so I've been able to play with them and verify >> that, >> yes, it can do what I want and perform much better than the wandboard >> quad >> did. > > The R1 is based on a Allwinner H3, it's a quad core Cortex-A7, it's > not really any more powerful than the quad core Wandboard TBH. Perhaps, but it IS faster/more powerful. Not that you can trust the "bogomips" results, but the R1 definitely reports a "higher" number ;) Specifically, the WB reports 6, and the R1 reports 64. And I was able to get more audio streams through the R1 than the Wandboard running shairport-sync. On the other hand, I do need to go verify that I *WAS* running a quad wandboard for that server; I honestly don't recall now (and the device is now offline) so I can't quickly check. >> Let me turn this around; what board (with case) would *YOU* recommend >> for >> some small, low-power arm-based server platforms? > > I always reply to that with the question what are you doing with them? > What are your feature requirements? Eth? Dual eth? WiFi, etc..... I've got three ARM systems deployed right now: 1) DHCP/DNS/Unifi Controller 2) Asterisk 3) My shairport-sync server (~16 streams) Right now I've got #3 on an R1 with Armbian Buster -- the only non-RPM-based distro I'm running! #2 is fine as a wandboard quad. I'm not having issues there. #1 is running on a Wandboard Quad, which has 2GB RAM. Currently it is reporting: [~]# free total used free shared buff/cache available Mem: 2061172 871612 140692 804 1048868 1162612 Swap: 982420 11008 971412 Granted, it works here, but I'd like to "update" from the old version of Fedora running there onto a newer version, but the main issue is the unifi controller. The issue was with mongodb-server, where I had to rebuild it myself to get it to work on the platform. If I'm going to upgrade to F35 on the WB I might need to do that again (unless it will continue to support mongodb 4.0.3). Unfortunately there is still not an armhfp build of mongo -- although there is one for aarch64, so if I stay with that (instead of aarch64) I'll still have to rebuild mongo again -- so I guess to replace this system I'd want an aarch64 board with sufficient RAM to run mongo and unifi. I don't mind using an SD for storage (certainly for mongo). The system currently uses 6G of storage, which would fill most of the 8G eMMC devices. But I am concerned about the 1G.