Red Hat Introduces Arm Server Support for Red Hat Enterprise Linux
redhat.com
redhat.com
I wonder how successful this was. Previously, all x86 CPUs (including x86_64) would bootstrap into the same mode from 1970s CPUs and preserve all the functionality from the original ISA (we still talk to the RTC via inb/outb, e.g.). I suppose this changed a little bit after EFI/UEFI was offered?
ARM CPUs were not bound to this backwards compatibility so AFAIK every vendor could implement their own bootstrapping functionality, and therefore having a single bootloader was challenging/impossible? uboot is a popular basis solution but IIRC everyone provides their own tweak to suit their SoC. Does TrustZone normalize the bootstrapping process for ARM devices such that we can write a single bootloader binary and expect it to work the same way across ARM server SoCs?
UEFI OTOH, is a bad combination of BIOS and openfirmware, but has standardized an execution environment that allows device vendors to build standalone "driver" packages that enable booting off plug-in network boards/RAID controllers/graphical display/etc.. Those drivers can then either be installed in the firmware or provided on option roms. There is a higher level API so that grub/whatever can say read a config file written by the OS without having to know the underlying technology.
Basically uboot is great for devices that could do without firmware and just boot a kernel, uefi is useful if you want to have a standard environment usable by a generic kernel/OS across a wide range of devices because combined with ACPI AML/etc it abstracts away much of the underlying platform management.
Coreboot is also very x86 centric last I checked.
Developing a runtime on UEFI is easy to setup and get going, you don't have that feature in coreboot.
Actually RISC-V is fully supported:
https://riscv.org/wp-content/uploads/2016/01/Tues1345-riscvc...
Real hardware coming soon...
We're now in the 3rd generation of Arm servers, all built to the same set of specifications with multiple vendor SoCs by tens of different OEM/ODMs - SBSA (Server Base System Architecture) and SBBR (Server Base Boot Requirements).
The goal of these specs was to make these servers as "boring" as possible, i.e. as similar to an x86 server so that neither OEM/ODMs nor IT guys have to be able to distinguish between supporting an Arm or an x86 servers.
This means that you will be able to boot the same binary OS distribution on every machine. There are no more BSPs like in the old 32-bit Arm world. This means that the OS does not need to know anything about clock domains, pin muxes, GPIOs or DVFS beyond the standard facilities exposed via ACPI. Like x86, machine error handling is firmware-first. PCIe works the same way as on x86. AP core boot up and power off is abstracted through the PSCI (Power State Control Interface). TrustZone is not available for OS use and is purely used to implement resident portions of firmware (RAS error handling, PSCI, SDEI).
For people asking why UEFI and why ACPI, the answer is very simple: because that's what 99% of all deployed servers use. Using something else is just a friction point for the OEMs, ODMs, IHVs and firmware vendors. It would also be a friction for anyone consuming these systems. Sometimes, you have to be the adult in the room and say that you don't need an "ideal" solution, but the existing solution will work. Plus, the UEFI+ACPI world only really works when you are able to make all systems look more or less the same, hiding all the nitty-gritty shitty bus accesses (I2C for power buttons, SPI for flash, GPIO etc) completely in the firmware, not for the OS to care about. The OpenPower ecosystem didn't see this at all, and they have an elegant firmware solution (hostboot + skiboot + petitboot), but... why bother? It's yet another way to boot, and it just makes their systems foreign to 99% of everyone making and using servers. The OpenPower booting was basically built for Google, but the reality of Google is very different from the realities of the world.
softiron.com for the OverDrive 1000.
System76 has a server using this chipset: https://system76.com/servers/starling
and Gigabyte has a whole line of them: http://b2b.gigabyte.com/ARM-Server/Cavium-ThunderX
https://www.solid-run.com/marvell-armada-family/armada-8040-... - $369
https://www.phoenicselectronics.com will sell you a Gigabyte MT30-GS2 (Cavium ThunderX 32-core) 1U system for around $2k. If you want to provide your own ATX case - much less.
ThunderX2 and Qualcomm Centriq (3rd gen arm server) systems have been recently announced (as in GA), but those will set you back quite a bit because they're not toys. But if you look at the 1st and 2nd gen systems, those are quite approachable.
That said, outside of the 10G Ethernet, its pretty much bested by just about every m-itx x86 board in that price range. Plus, if you happen to need the 10G, its still probably less expensive to pick up a G4400+motherboard+10GbaseT board (new dual port on ebay for about $100) and best that machine in most cases.
Yep, ACPI support is evolving, but it’s a matter of time. Folks have figured finally that if it isn’t compliant with SBBR and SBSA, then there will be plenty of competitors who will be, absolving you of the headache of dead-end BSPs.
The base processor is rated at 10W for 4 cores, add ~8W for the 10GbaseT board (plus a bit) and its a competitive solution, particularly if your workload needs more RAM/etc. Feeling like you want a little more beef the Denverton's are hitting the market and many of them have the 10G integrated.
https://www.supermicro.com/products/motherboard/atom/A2SDi-H...
That one also has a BMC, which given my past experience tends to add a few watts too. Without testing them side by side its hard to know which draws more power in a given workload, particularly since the intel machines have become very dynamic over the last couple generations, its actually pretty hard to hit their TDP numbers in most cases (particularly without heavy FP workloads).
Now its become more about what the motherboard manufacture has integrated. Its all fine that the core/etc draws 8 watts. The problem happens when the motherboard manufacture decides to glue an aspeed BMC and an old marvell SATA controller on the board. Between them at idle they draw 2x more power than the SOC does running at peak. Its pretty easy to move the numbers one way or the other with unrelated changes.
EDIT: Discovered after posting that the PCIe on the asrock, is only x1 which keeps it from taking one of the x540T boards, but they have a couple variations including one for less money in m-atx which has a potentially better slot layout, and full size DIMM's.
With RHEL 7 supporting AArch64 after this announcement, I'd assume CentOS will follow suit.
CentOS 5/6/7: https://wiki.centos.org/FAQ/General#head-059f2f807ebb83e93f2...
RHEL 7.4: https://access.redhat.com/documentation/en-us/red_hat_enterp...