Many tech companys try to switch Arm.
I know ARM based PC like Apple m1 is good and silent for everything. But, since Windows for ARM is not widely available and reliable. I don’t think it is good option for now. Except, if we want to use Linux
5 Likes
Probably not in near time, since the software for the ARM itself is not good enough. However that will be a possibility in the future when most developers support ARM
Citation needed. I don’t know if there are driver issues, but otherwise Linux can run the exact same software on ARM (or RISC-V, or PPC, or …) as on x86. (There are some exceptions for stuff that has hand-tuned assembler, but that’s fairly uncommon and unlikely to affect your basic productivity stuff.)
2 Likes
the biggest issue I’d forsee is thunderbolt support, since the expansion cards are thunderbolt on the back end. That being said Apple did ARM with thunderbolt so its possible. Just may take some time.
1 Like
As far as i know, there are TB4 Controllers from intel on the horizon. Those should be usable on arm boards
One limitation with Arm is Apple are really the only ones to have produced processors that can out perform an x86_64 alternative.
Also, most developers don’t provide binary builds that target Arm, so installing software can be a problem.
2 Likes
Perhaps this is a noob question, but let’s say I buy the framework laptop with intel CPU now - would I be able to replace the CPU/motherboard with an ARM version in a few years (assuming framework sells ARM-based laptops at that time), or would there be compatibility issues with the other components and chassis in the current laptop?
2 Likes
Depends on what platform you’re using. Windows? yeah not a ton of arm support there, but on the Linux side most of the things you want to run do run on arm just fine.
2 Likes
Yeah, Windows support is really rubbish. I’m on Linux, and yes you can get most software, but ARM64 isn’t supported by some distros, and you may have to compile from source more than x86_64.
Hopefully when more powerful ARM64 laptops and PCs appear we will get a Linux version of Apple’s Rosetta 2!
Not True! Amazon has EC2 ARM instances which are competitive with x86-64. The “same size” ARM instances are slightly slower than the x86-64s, but for the same money you can have more ARM instances. MediaTek and a few others make ARM processors with truly massive core-counts for enterprise-grade network appliances (routers, firewalls, intrusion detectors, load-balancers, etc) which handle far more traffic than one could using a top of the line x86-64 processor. Not to mention, plenty of laptop manufacturers have been producing ChromeBooks with ARM processors (although not exactly competitive with x86-64 on performance, but certainly in portability, poweruse, and cost).
Keep in mind that not everyone has the same metrics in mind when they say “performance”. One person’s performance might be compute intensive like CADD, video editing, or code-compiling. Someone else’s performance might be “shuffle pdfs and word docs for 8-10h.”
1 Like
Which Linux distros do not support ARM64 (aarch64)? As far as I know, Debian, Ubuntu, Fedora Linux, Red Hat Enterprise Linux, CentOS support ARM64.
The real issue there is just that ARM makes a different tradeoff, which is lower energy usage vs. computing power. This makes sense when you consider that the biggest market to date for ARM has been almost exclusively in the mobile and/or embedded space where you’re often operating on battery power and total runtime often trumps raw computing power. If we start to see more interest in ARM in desktop or larger battery powered devices (like say a laptop with a chunky battery instead of a phone) we might start to see ARM CPUs entering the market that favor more cores and higher clock speeds at the expense of higher TDPs.
Some of that can already be seen with Amazon investing in data center targeted ARM processors with upwards of 128 cores and a very hefty 250W TDP, a very different beast from your typical ARM mobile CPU that more often max out at 4 cores and have TDPs under 15W. Even Apples M1 CPU tops out at 8 cores, and although there’s no TDP I can find documented for the more powerful version used in the MacBook Pro and Mac Mini, the passively cooled one used in the MacBook Air has a TDP of only 10W (A reasonable guess for the active cooled TDP might be 25W). An 8 core ARM CPU with a TDP of say 60W should easily be able to go toe to toe with most of the x86 chips out there currently. A more reasonable TDP of 30W would put it in line with the more common mobile x86 CPUs like the 11th gen Intel chips currently used in Framework laptops, and would no doubt also leave plenty of room for performance matching or potentially exceeding its x86 counterparts. In contrast most desktop x86 CPUs have TDPs of anywhere between 45W and 250W with the average being something closer to 125W.
1 Like
Good thoughts here^^. I’ll only add that many times low energy usage is a good tradeoff, even with datacenter loads. Amazon started adding ARM instances because they have low power usage and can service IO-intensive workloads for cheaper.
1 Like
Looks like there are quite a lot of misconceptions about ARM/Risc-V CPUs out there. Those things are typically highly optimized for a given environment. The tradeoff is not energy consumption for compute but energy consumption for complexity. In other words, you give up general applicability and standartization in favor of energy consumption. This is non-trivial for a startup like framework, because it either directly goes against core values like modularity, repairability, upgradability and long term software support, or the budget available. It is a grave mistake to think of ARM SOCs with the same mental model as you would with x86 CPUs. It is easy to call for ARM SOCs but the implications are outside the realm of possibility for many reasons and I dare say, the discussion is hurting more than it helps for now. It is worth revisiting this topic in the future, I guess, but the ARM ecosystem is not at a point where it is reasonable, to have this discussion.
1 Like
You’re talking about RISC vs. CISC which is really orthogonal to all this. Its been shown that RISC and CISC are roughly equivalent, and honestly the architecture of modern CPUs blurs the lines between the two considerably. x86 microcode ends up looking an awful lot like RISC, while over on the ARM side it has picked up a whole raft of extensions that make it start to look an awful lot like CISC. Ultimately most of those differences come out in the wash, so looking at energy consumption makes for a convenient mechanism to compare chips as they both end up able to do approximately the same amount of actual work with the energy consumption (x86 via few cycles but more complex circuitry, and ARM via more cycles but simpler circuitry).
@Kyle_Murphy As you pointed out correctly, ISAs (Instruction set architectures) were based on different philosophies, which gave them certain benefits. But that ist precisely not, what I am talking about. actually, the ISA is the only standardized piece, that all SOCs have in common and that is supported by pretty much all mainstream compilers. What I am talking about, is the rest of the SOC. Graphics, Interconnects, Initialization, Memory Controllers, ASICs for AI, De- and Encoding, RTC, Crypto modules, that sort of stuff. RISC-V goes even further and lets you extend the core ISA. Actually, the goal is for you to identify exactly what your workload looks like and then build a custom RISC-V core that fits exactly that workload and application space in order to be able to leave out everything else. That is, what makes RISC-V so efficient. And that is, what I was talking about, because ARM SOCs are designed similarly (RPI4 missing Crypto extensions, many SOCs missing the RealTimeClock, …) Both ARM and RISC-V SOCs tend to be highly specialized to the application domain, with RISC-V being even more heavily optimized and ARM suffering from it’s diverse ecosystem, in which every vendor adds their own flavour of everything, typically buying the core IP from ARM (A75, A76, A53, …) and maybe some other parts like the Mali GPU cores, which leaves them with the responsibility of supplying drivers, which they did do for 2 years in the past with backported security patches to an old linux kernel, and often implemented as a blob and in user space and being based on Android’s bionic libc, making mainline support an absolute mess. UEFI? HAHA… yeah … sure! That is the reason why I stated, that it goes against Framework’s core values like sustainability. You end up with a device that probably doesn’t get updates after 3 years. If you have questions, just ask. I am happy to explain things like that to people that are truely interested 
Edit: i just want to point out, that leaving out certain ASICs and circuits that are not needed leads to a simpler design and less transistors, which results in a higher energy efficiency. unused parts of the SOC still use energy and controll structures are larger and more complex for generalized CPUs, which influences the energy budget as well.
1 Like
Ah, OK, interesting take. Yes I’m aware of that aspect of RISC-V, although I tend not to think of ARM in the same way as typically you’re just dealing with some particular variant of Cortex-A (or in my case more often Cortex-M). The thing is though, that it doesn’t actually need to be a SOC. There’s no reason for instance that you need anything but the core ISA and basic x86 equivalent functionality like FPU and memory controller. See for instance here where Jeff Geerling is attempting (and admittedly failing, but he gets pretty close) to get a Raspberry Pi 4 Compute module working with a GTX 1080. As long as the processor includes some PCIx lanes for adding extra devices in that functionality could be left off the SOC. Generally the piece that results in needing blobs is the GPU as that’s typically the most closely guarded part of the SOC. Manufacturers to date have also typically had some kind of proprietary boot process for ARM as well, although I see no reason why something like UEFI couldn’t be used, it would just require an ARM license holder to have the will to actually do so. Considering how much of a threat RISC-V might be to those markets in the future we might actually see some competition drive the adoption of more open and standards compliant ARM chips in the face of a rising RISC-V market share (and aside from the GPU and initial boot process, ARM is already pretty open and standards compliant).
While unused components of the chip, even (relatively) unpowered do drain at least a little power it’s a very minor amount. The real reason that ARM tends to run more efficiently than x86 is really just that x86 is an ancient and baroque ISA that’s forced to jump through tons of hoops in the name of backwards compatibility. The arrival of UEFI and AMDs creation of the x86-64 ISA both went a long way to eliminate literal decades of cruft, but even then since nobody creates a x86-64 CPU that can’t also execute x86 or one that can’t boot via BIOS, chip manufacturers are still saddled with the extra silicon necessary to support those old and crufty features.
Both x86 and ARM CPUs are designed to operate within certain power envelopes, and their clock speeds and transistor budgets are picked with respect to that. ARM has the advantage in that its ISA is smaller and more moduler allowing manufacturers to more easily pick and choose where they cut transistors or reduce clock speeds in order to meet those requirements, but as things like Intels Atom line demonstrate it’s also possible to do so in x86 even if it’s coarser work.
Honestly while I think at least in the short term ARM is a more interesting alternative to x86 given its decades of development and mainstream usage, I think in the long term RISC-V has more potential as a disruptor. Its commitment to a truly open standard is likely to be an easier sell to chip manufacturers than trying to convince companies like Broadcom to give up their clutching to proprietary pieces like their Mali GPU. All it would really take is someone to put a open GPU out there into the RISC-V ecosystem to allow for a complete RISC-V SOC that could rapidly unseat ARM as the choice for most hardware manufacturers.
There is funding for development of an open source GPU IP going on, based on OpenPOWER ISA (IBM POWER PC, which is open source as well by now with a lot of stuff associated with it like interconnects and whatnot being open sourced as well) afaik and being publicly funded by NLnet. For further information, check out https://libre-soc.org. I think i remember that there are RISC-V based efforts, too.
Mali GPUs are ARM IP and licensable.
About UEFI, of course, if you throw money and devs at it, there is a solution. AMD’s ARM based A1100 Opteron server cpus worked pretty much like x86 cpus apart from the instruction set and Ampere and Solid-Run probide UEFIs as well. That was the reason for my budget argument originally. Alternatively you throw open source devs at reverse engineering the living spit out of Qualcomm SOCs by airdropping large numbers of devices into the dev community or hope for Samsung (Exynos 1000 with AMD RDNA2 Graphics IP) to chose a more generic approach AND making them available for other companies. Things move into an acceptable direction at least. Things could be worse but for now the ecosystem just can’t provide what we need for all the previous reasons, sadly. Generic ARM (company) IP is well supported in terms of open source drivers btw, so you could maybe get a generic SOC up and running, if you license the full package and order it from TSMC yourself xD
1 Like
Interesting, I didn’t realize that Mali was ARM IP, I’ve only ever seen Mali in relation to Broadcom so I assumed it was theirs. Having an open source Vulkan capable GPU would be amazing, so hopefully Libre-SOC eventually bears fruit there.
While I agree there are currently no perfect ARM SOC offerings out there, I’m not entirely sure how much of a problem something like a proprietary firmware blob would actually be for Framework. While they have stated they want to open source their motherboard it seems like it may be covered by Intel NDAs preventing them from doing so. In a similar vein having a GPU blob covered by an NDA might not be a deal breaker for them. It’s far from ideal of course, but it’s not like they’d be the only company making that tradeoff. The success of Raspberry Pi shows that people are willing to compromise even on a nominally open platform. As for the long term viability of such a decision that I’m less clear on. In theory if Framework was provided the source of the GPU driver they could at least make sure it was kept up to date themselves, although that might be a commitment they would rather not take on, and is predicated that they would receive the source code and not simply be provided a binary themselves.
At any rate, I think the answer to an ARM based Framework laptop is “not right now” for a variety of reasons several of which have nothing to do with ARM itself, and they’ll revisit that in the future. I think the same answer also applies to RISC-V for better or worse. In the short term I think the more interesting question is how long before we see an AMD based framework laptop, particularly considering how badly AMD has been beating Intel across the board.
1 Like