Hi,
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?
-derek
PS: I realize I could look at the Neo+ or M1+ which are supported, but those all appear to be a bare board and I can't (quickly) find those in a nice container like the R1 comes with.
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.
-derek
PS: I realize I could look at the Neo+ or M1+ which are supported, but those all appear to be a bare board and I can't (quickly) find those in a nice container like the R1 comes with.
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Thanks Peter,
On Tue, November 30, 2021 8:32 am, Peter Robinson wrote:
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.
Well, I do have a "working" u-boot for the platform... But yeah, it would certainly be "better" to have it upstream. *sigh*
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.
Let me turn this around; what board (with case) would *YOU* recommend for some small, low-power arm-based server platforms?
-derek
On Tue, November 30, 2021 8:32 am, Peter Robinson wrote:
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.
Well, I do have a "working" u-boot for the platform... But yeah, it would certainly be "better" to have it upstream. *sigh*
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.
-derek
On Tue, November 30, 2021 9:19 am, Derek Atkins wrote:
[snip]
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.
Actually, looking at Mongo's site, they only started supporting AArch64 for mongodb 4.4, and it's unclear if Unifi Controller supports that! I built 4.0 and have been running with that, so even going to an aarch64 platform might not suffice. So it might not even matter. :-(
-derek
On Tue, Nov 30, 2021 at 2:19 PM Derek Atkins derek@ihtfp.com wrote:
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:
- DHCP/DNS/Unifi Controller
- Asterisk
- 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.
There will never be mongodb for 32 bit, it's architecture doesn't allow it.
Personally 32 bit is basically coming to an end, we're proposing retiring it from Fedora 37, which means Fedora 36, supported until June 2023 will be the last release that's supported.
I would probably suggest a Raspberry Pi 4, you can get with up to 8GB of RAM and they work well now for non graphical applications.
-
Derek Atkins -
Peter Robinson