This was discussed informally on #gentoo-infra Would be great if we can increase the arm(32bit) power. There aren't too much devices around and this is what I've found: https://wiki.odroid.com/odroid-xu4/odroid-xu4 https://www.amazon.com/ODROID-XU4-Single-Board-Computer-Gigabit/dp/B0163GEA64 Thanks
ago: Can you please clarify what the requirements for the device are? Why is running an RPi4 with a 32-bit kernel not ok for example? I think if you're doing builds & tests, you should have some form of fast local storage that you boot off (not just an attached USB key), as well at least 2GB of RAM. I've asked bkero to comment here as well with hardware suggestions for you, because they have done hardware selection stuff w/ ARM before.
I would think a nanopc t4 or a nanopi m4 with the nvme or even sata hat would be a better bang for the buck.
@Robin: I don't have special requirements. I just need hw to do AT for arm32, so whatever is fine. However, unless it costs a disproportionate amount, the faster is better =) The odroid is just something suggested by mattst88, but if there is something better or similar (as suggested by steev), it is fine for me.
I'd suggest using some Raspberry Pi 4 systems for this. They have a low price, large community ensuring good and continued firmware upgrade support, and competitive performance (especially with recent firmware patches: https://www.raspberrypi.org/blog/thermal-testing-raspberry-pi-4/) Standardizing on a popular board like the RPi4 has ecosystem advantages. For clustering, they have a standard board size for better compatibility, especially with cluster mounts that also give you centralized power management for remote reboot possibilities, and centralized console support to be able to have out-of-band access to each board. If you absolutely need NVMe support I'd suggest Rock Pi 4 boards. They're comparably priced to RPi4s, although don't have the large community support. They're RK3399 based, come in a very similar (identical to some accessories) board layout as the RPi4, and like it can come with 1, 2, or 4GB RAM, and have a M.2 slot for NVMe support. They also have a separate eMMC port if you'd like two onboard block devices for management purposes. The ODroid XU-4 boards mentioned are getting a bit older and aren't as good value-for-money anymore. The processor was made on a 28nm process in 2013 and is severely lacking in performance-per-clock compared to the other 2 modern options. It costs a bit more at $55 per unit with AC adapter (more if you include their eMMC packages), and it only has the option for 2GB RAM.
@ago: you'd originally said you wanted arm32. in your description, yet the XU4 you mentioned is specifically a 64-bit system. Can you clarify what your plans are getting 32-bit are with that 64-bit hardware? - running a 32-bit kernel? - running a mixed 64-bit kernel/32-bit userland environment? - as above, 64-bit host userland & 32-bit userland inside chroots? @bkero: do you know if the RockPI4 will run a 32-bit ARM kernel?
@ago: as a potential related idea, AWS EC2 A1 ARM64 instances, using our free AWS credits. If a 64-bit kernel is fine, and there's a ARM64 system image, you could spin them up on demand for building.
(In reply to Robin Johnson from comment #6) > @ago: as a potential related idea, AWS EC2 A1 ARM64 instances, using our > free AWS credits. If a 64-bit kernel is fine, and there's a ARM64 system > image, you could spin them up on demand for building. This seems viable, but we do have the arm64 instance on packet with the arm64 project. Would also not cause us to use credits.
ago simply wants a system (or a few of them if costs allow) to do KEYWORDS="arm" arch testing. Whatever system you guys think is best for doing that is fine. He mentioned the XU4 only because of my (likely under-informed) suggestion to him. There are not any special 32-bit userland/64-bit kernel requirements. Just something to do KEYWORDS="arm" arch testing with.
@ago: Based on the above, can you quickly verify that the Amazon A1 Graviton systems work? You can login here with your SSH key to a short-lived test instance: ssh ubuntu@34.241.48.103 I've created it with spot pricing set to $0.02, max duration 14 days, so it might be terminated on short notice. Data will NOT persist over that. I did try the following tarballs, and could chroot into all of them and run stuff: stage3-armv4tl-20180831.tar.bz2 stage3-armv5tel-20180831.tar.bz2 stage3-armv6j_hardfp-20180831.tar.bz2 stage3-armv7a_hardfp-20180831.tar.bz2 Here's the lscpu output on the Graviton A1.medium system (Ubuntu 19.10, 5.3.0-1008-aws): Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 NUMA node(s): 1 Vendor ID: ARM Model: 3 Model name: Cortex-A72 Stepping: r0p3 BogoMIPS: 166.66 L1d cache: 32 KiB L1i cache: 48 KiB L2 cache: 2 MiB NUMA node0 CPU(s): 0 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Not affected Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Mitigation; Branch predictor hardening Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Here's the lscpu output on the Packet system (arm64-build.arm.dev.gentoo.org, 4.9.0-4-arm64): root@arm64-build:~# lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 96 On-line CPU(s) list: 0-95 Thread(s) per core: 1 Core(s) per socket: 48 Socket(s): 2 Model: 1 BogoMIPS: 200.00 L1d cache: 32K L1i cache: 78K L2 cache: 16384K Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32
Hello Robin, thanks for taking care about. Yes, the amazon machine works for me. Would you mind to setup a definitive machine? Also, since you mentioned arm64-build.arm.dev.gentoo.org's cpu, were you able to do something about arm32 on that machine? Or what's the purpose? Thanks
ago: 34.253.196.255 is online as a medium-term ubuntu host for you now. please see the 20GB LVM VG that's associated with it. Any persistent content MUST be placed on that second drive. Any other content, including home directories may be lost on reboot still. Need to work on improving launch templates/cloud-init scripts to fully automate keys, users, and mounting that space to disk. leio: are the arm64 stage4 tarballs suitable for automated generation of Amazon AMIs?
Meant to say, for login: ssh ubuntu@34.253.196.255 Doesn't have IPv6 connectivity yet either, I need to work on that. It's a1.xlarge, in the EU region for you.
(In reply to Robin Johnson from comment #11) > Need to work on improving launch templates/cloud-init scripts to fully > automate keys, users, and mounting that space to disk. Thanks. If possible I would like to have in cloud-init: - creation of /data directory and mount of /dev/nvme1n1p1 to that directory - execution of /data/ago/init where I do the rest and where I can put everything without depending on who have the permission to modify cloud-init
Obsolete; we have other ARM systems now.
