Guest post by ServeTheHome attended Arm Vision Day 2021 and posted a quick overview.
At the event, the company introduced Armv9 which will bring about key advancements for machine learning, digital signal processing, and security.
One of the key drivers of Arm expecting to see massive shipment growth is the need for specialized compute. Or another way to look at this is that a number of traditional analog devices will convert to some level of “smart” and connected over the next few years. An example was given of a mechanical pump (like a water pump) that could be monitored for failure signs and efficiency versus just pumping water. For each of those applications, there will be different needs in terms of sensor connectivity and processing, general-purpose and accelerated compute (CPU and AI as examples), memory, and communications infrastructure. Arm sees the lower power cost of new chips enabling a wider array of chips and therefore more chips being sold.
[…]Another key push will be for Arm SystemReady. This is building on Arm ServerReady which helped Arm servers go from being a science experiment to boot each server to our experience with the Ampere Altra Wiwynn Mt. Jade Server where it worked (mostly) out-of-the-box using a standard image.
Arm SystemReady is probably the biggest thing for OS enthusiasts. One of the weaknesses of the Arm hardware ecosystem, compared to the x86 ecosystem, is the lack of a standardized boot environment. x86 has a BIOS or UEFI, and Arm has UEFI (server) and something (probably devicetrees and a fork of Das U-Boot). Going forward Arm SystemReady systems will be able to boot via UEFI to allow for a standard OS image like x86.
They could have picked something else (coreboot, Barebox, Das U-Boot), but UEFI is at least better then what it was.
So, it is time to *defragment* ARM ecosystems.
To be fair, the fragmentation enabled competition, which enabled introducing newer ideas, like tensor cores, or hi-lo power pairings. However it also led to massive issues wrt. long term support of consumer hardware.
I am all for occasional ebb and weave in technological progress where we do random things for a while (like the early days of PC/Amiga/Z80s, or 3D accelerators with different APIs), and then use the best findings to improve upon them.
(Actually this is a well known technique in machine learning itself, called “Simulated annealing”)
sukru,
I agree with this in principal, as a consumer it would be extremely useful to have standardized CPU extensions, peripherals and boot environment. But achieving it is another thing entirely. A dominant party could achieve a defacto standard. Google, apple, and microsoft are the only parties with market relevancy here. Microsoft doesn’t have the ARM numbers on it’s own. Apple doesn’t seem particularly interested in vendor interoperability. Google hasn’t done much to standardize ARM. I’d like to see it happen regardless of where it originates. What would it take to really get everyone on board?
Mandating it in the license for ARM would certainly do it
Drumhellar,
Sure they can try to force it.
But then again, why spend their clout on this, especially risking possible lawsuits for anti-competitive behavior?
I am hoping it will happen organically though; as more servers, desktops, raspberry pi style SBCs start using ARM.
Interestingly, Microsoft could actually be the major player achieving this. After all, their MS-DOS was instrumental in standardizing the IBM PC, and the current server/desktop/laptop markets still heavily rely on their OS.
That leaves mobile phones and tablets, though.
I find your comment about the Raspberry Pi particularly ironic here, given that it’s actually a well documented example of exactly what ARM SystemReady is trying to get away from. A lot of other ARM-based SBCs are much friendlier to work with, in the early stages of the boot process even if they are not quite as standardized as ARM SystemReady is aiming for.
sukru,
Microsoft is pushing an ARM UEFI standard, which is good. I haven’t checked if it’s still the case, but they were contractually mandating windows vendors to deny owner’s control over the bootloader on ARM devices, which is very bad.
It’s not clear to me that any hardware vendors are both willing and able to change the frustrating path that ARM is on. The biggest difference between ARM today and x86 back in the day is bundling. Prior to this you could buy the hardware and software separately and the PC standards, as quaint as they were, made interoperability very easy. So much so that many people like myself could write portable bootloader utilities without much effort and x86 has largely retained this feature. However on ARM the hardware and OS are so tightly coupled that often times users can’t even upgrade the kernel on their own systems. This inability to run mainline linux has marred my experience with ARM SBC’s.
I hope that once the dust settles, ARM will be more PC-like in terms of vendor interoperability, but it might never happen because hardware/software bundling may be the standard business practice going forward for mainstream devices 🙁
Yes, my plan is not foolproof, and requires a lot of *luck*.
However in a random environment, luck comes eventually. Maybe not in a year, or two. But it should come soon.
Last time it happened because Compaq decided to reverse engineer IBM BIOS and release cloned computers:
https://www.allaboutcircuits.com/news/how-compaqs-clone-computers-skirted-ibms-patents-and-gave-rise-to-eisa/
This time it could happen so that Supermicro releases affordable ARM workstations, who knows?
Because it’s a major problem, and it’s an impediment to adoption. If Arm isn’t being adopted, Arm isn’t making money.
Arm servers have already standardized on UEFI via Arm’s ServerReady initiative, and standardizing on UEFI allows a generic OS image to be booted instead of a bespoke image which only works for this one proc.
What’s anti-competitive about this? UEFI is an open standard with multiple implementations; Tianocore EDK II and Mu for instance. I don’t agree with some of the decisions (fat32), but it’s not like it’s a proprietary format which requires a separate license.
We’ve seen the results of “happening organically”, and it was a pipe dream. Vendor lock in and selling professional services is too attractive to the Arm vendors.
MS can stay out of this. They’ve done enough damage.
I’m still salty about having to create a Fat32 partitions to boot via UEFI instead of a more robust FS. After countless years of corrupted filesystems, I get a little anxious and twitchy when I think about it.
The PC was already standardized. The only thing custom about the IBM PC was the BIOS, and the rest of the hardware was off the shelf stuff. That’s the beauty, and ugliness, of the PC.
MS gets way too much credit for the early days of the PC. They are a result, not a cause. If IBM hadn’t pick MS because Bill’s Mom was on a non-profit board with one of the IBM decision makers, it would have been some other OS, and we might live in a better world.
The server market is not driven by Windows. MS wouldn’t have ported their server tech (.NET, SQL Server, Powershell) if Windows was anywhere close to being a player in the server market. They got dog walked, and it’s not even close.
Which leads into, Windows doesn’t have a presence in the IoT market, and everyone is tired of Arm vendors holding their hardware hostage with weird bootstrapping methods, which brings us full circle.
Even if it is optional, this lets everyone know what to expect. A board is Arm SystemReady compliant or it is not.