Unpopular opinion. ARM is a cancer of modern hardware.
Posted by ptoki@reddit | linux | View on Reddit | 83 comments
TLDR: The fragmentation and lack of general standards makes arm devices prone to be abandoned if the vendor drops support or not be able to get any linux support if vendor dont care.
Sorry for controversial/click bait title :)
Longer story:
As probably everyone knows, modern phones which could run linux cant because vendors dont care to provide even simple drivers or docs of how to interact with otherwise already supported hardware.
As a result a ton of perfectly fine devices end in a landfill.
The issue is much more wide even for sort of popular devices like many SBC. Not to mention devices like sharp netwalker or tablets from google, lenovo, dell which run on ARM.
Yes, ARM is not the one to blame but it is the common denominator for all these cases. It is pretty rare to have x86 device which cant run linux at all.
I had devices like oqo 01+, laptops like lifebook, panasonics cf series, up board computers and probably few more which I dont remember. They are all standard. I could load them with almost any linux (well, not the ones which arent 32bits now) but when they were supported in general they worked. Sure a touchscreen was not working here or there or a gpu was not recognized or the graphics card was running only in svga mode but the moment the driver was created for the device it just started to work after kernel update with maybe a config file edit.
With ARM devices it is not so. If vendor supports it and makes it standard (im not even sure if such standards exists) then you get a distro for it. Sharp published just one kernel source (AFAIK) for netwalker. The source was there, still it turns out it was no point of getting it mainlined in the kernel.
There are humble exceptions to that (raspberry pi, banana pi, dlink devices (at least in the past) - few others) but majority of arm devices cant be flashed with even simple debian like base distro.
I would love to hear about initiatives which address this. I would love to be able to turn my old phone into weather app display or ip monitor running linux and not just stitched and crafted third party app running on top of old android.
jean_dudey@reddit
This is not a problem of ARM per se, there are universal UEFI images for ARM with proper ACPI support, but board manufacturers are too lazy to implement that.
This would greatly reduce the use of custom images for each board but the board manufacturers simply don’t care about porting EDK2 to their boards.
jabjoe@reddit
To be honest, it's not that UEFI is great either. It's kind of overkill for a lot of ARM devices. ARM could mandate a simple EEPROM on a known address with enough Device Tree to start a boot would do. Maybe mandate Device Tree EEPROMs for any chunk of hardware without builtin discoverability in the buses.
techzilla@reddit
UEFI is great though, and ACPI is great also, and vendors should be forced to provide that standardized firmware to get certified by any OS vendor. Doesn't even matter which vendor, DTs are a hack, they work but they don't provide the universal solution users need.
jabjoe@reddit
UEFI could be simpler.
DT is ok, and what you end up with when the buses are undiscoverable. Things on ARM Linux were terrible before it.
ARM Linux devices with UEFI and ACPI still have DT.
It would have been useful to me a few times if x86 also had DT for I2C and SPI buses. All the I2C+SPI drivers are DT. I could have done dev on the laptop if there was DT on it. DT for x86 exists, but most kernels are built without CONFIG_OF, so it's bring your kernel.
BUT I would take autodiscoverable over DT if it was an option.
techzilla@reddit
You really wouldn't need to use both DT and ACPI, but sometimes DT can useful when debugging or if you don't have the ability or care to correct ACPI.
jabjoe@reddit
UEFI can be debated but an imperfect standard is normally better than none.
DT exists because of the problem of non-discoverable hardware. And ultimately that is because of cost. ARM is still in the world of cheap and disposable hardware. Pi and Beagle have EEPROM systems for hats/capes to lookup the overlay. If that was standardized, you could have autodiscover. Which I absolutely agree would be better. DT is the least bad option until then. We both agree the pre-DT way was mad.
ARM is not cheap and disposable anymore and it's not ideal to have DT instead of autodiscover. I'm not saying I prefer DT to autodiscover!
https://www.reddit.com/r/linux/comments/1i60nbp/comment/m8bslr3/
Think how much easier it would be to do phone OSs. Phones are not cheap rubbish today.
There is a Right To Repair issue to. DT makes it hard, but not as hard as before it. (SecureBoot could be used to make Right To Repair next to impossible. Screw that!)
techzilla@reddit
You miss the entire point
With EEPROMs/DT: The burden of support is on the OS developer (Linux/Microsoft). They have to write a driver for every ID they find in an EEPROM.
With ACPI: The burden is on the Hardware Vendor. They provide the ACPI tables. If the hardware is weird, the vendor writes the "weirdness" into the ACPI methods.
jabjoe@reddit
How do you think drivers for USB, PCI, etc work? Each device has an ID that is used to look up the right driver. Non discoverable bus have no device IDs. That's what makes them non discoverable. Ask your LLM about discoverable vs non-discoverable buses.
techzilla@reddit
I already understood that, you seem to think that all hardware can be discoverable, but that is not reality. We need to deal with reality as it is.
jabjoe@reddit
DT don't really provide IDs. It is mostly full of things like, at this bus, at this address, load a instance of a device driver with these parameters. If you could get ID for things on the bus, you wouldn't need DT. As I said, this is basically what PCI and USB and other autodiscoverable buses do.
You know that for most ARM things now, you have the same kernel with a different DT? In fact, it's not just the Linux kernel that uses DT to have the same executable on different ARM platforms : https://docs.u-boot.org/en/latest/develop/devicetree/control.html
This is kind of the point of DT. Be far better if the hardware could describe itself, but it's not been designed like that. I'd argue that is mainly down to cost and a throw away attitude. DT copes with this as best as you can without proper discoverable hardware.
techzilla@reddit
You can work around some parts with drivers, and UEFI+DT, without that every board has a custom way of passing or specifying the DT at boot. I'm glad we've agreed that UEFI is non-negotiable.
"you have the same kernel with a different DT?"
You cannot have a standardized bootable image, that is the problem, that has been the problem. Did you forget to mention that DTs are often kernel version specific?
jabjoe@reddit
I didn't say you could have standardized bootable image. That would require some kind of auto-discover. Which the hardware doesn't have. Even if the base had auto-discover, the rest doesn't. Every time bring up hits a non-discoverable bus, it needs something to tell it what is on that bus to continue this traversal. We need to add discoverablity, by say a standard EEPROM...... Or all future devices on the bus implement a standard discover register for at least an ID.
PC moved to discoverablity in the 1990s. Maybe ARM will in the 2030s. The fractions of a penny saved on hardware, is expensive in software support.
techzilla@reddit
We have standardized bootable images for ARM servers today (SystemReady SR). They don't have "new" auto-discovery hardware; they just enforced ACPI. ACPI fulfills that role, x86 doesn't have a 'discovery EEPROM.' It has a firmware contract.
jabjoe@reddit
ACPI is auto-discover. x86 has had auto-discover since the 90s. It's not a specific technology, but a concept that hardware can to the OS about itself so no human has to. "Plug and Play" is another term.
https://en.wikipedia.org/w/index.php?title=Legacy_Plug_and_Play#Hardware_identification
DGolden@reddit
Modern UEFI does have provision for firmware providing a DeviceTree I think.
https://uefi.org/specs/UEFI/2.11/04_EFI_System_Table.html#devicetree-tables
An ARM device could thus have a UEFI boot system but with a simple firmware-provided DeviceTree rather than an ACPI labyrinth
jabjoe@reddit
To be honest, any auto discover system is better than where we are now. At least we have device tree instead of per SoC kernel tree blocks.
keysym@reddit
Do you recommend any brand boards?
jean_dudey@reddit
Not particularly, I haven't seen one with proper UEFI support, have used Raspberry Pi 4B EDK2 though and it worked great for Windows for Arm (impressive), and also Ubuntu and Debian UEFI images.
Most of the Arm boards with a EDK2 port are provided by the community.
fellipec@reddit
I already wrote several rants about how I hate Google and the Android consortion for the state of this platform.
In one of those rants, some ex-employee from a phone manufacturer said back in the day they inteded to have a standard to things are compatible between brands. But the top hats blocked that.
Let's be real: The x86 "standard" was result of an IBM mistake. They made the original PC with off-the-shelf parts and was just matter of someone reverse engineering their BIOS. Microsoft was there with an OS ready for the clones.
No manufacturer made that mistake again as far as I know. If we want some open hardware standard for the future, IMHO it will need to be born open on purpose, or be forced open by regulations, as we'll never see a company create a platform and leave it free of its shackles.
So, to finish, I don't blame ARM itself. But every brand that uses it and keep things locked. Corporate greed is a cancer.
KnowZeroX@reddit
Were things any better in the Window Mobile days? (not WP, the better one before it)
In theory, ARM could have required manufacturers to do so, they simply didn't care. Of course google could have as well, but yeah, no vendor is going to do it voluntarily unfortunately.
techzilla@reddit
Yes Microsoft did have an open phone platform, the problem was simply that they were late to market.
KnowZeroX@reddit
I am not sure what you mean. Windows Mobile was a huge player in the mobile market before Android or iOS, they then killed it off because WP7 boss had jealousy issues(not to mention MS culture at the time encouraged self sabotage) and tried to push a locked down Windows Phone which ended up failing.
techzilla@reddit
You asked, "Were things any better in the Window Mobile days"
I answered, Yes.
KnowZeroX@reddit
I was responding to your statement about them being late to the party which I found weird.
And it wasn't Windows Mobile that was more open, back then many mobile phones were running on x86 intel processors which retained their open nature. When it got switched to ARM, things went downhill. I still remember the horror of HTC not licensing gpu drivers.
techzilla@reddit
In the case of the iterations I'm referencing, they were in fact ARM boards.
fellipec@reddit
Exactly, no one wants this. It just happend with PCs because a happy sequence of mistakes and opportunities that are unlikely to be repeated
20dogs@reddit
You would think that it would leave a gap in the market though
HaikuHeron@reddit
I'm not as versed in CPU architecture stuff, but isn't "born open on purpose" the mission statement of RISC-V?
ptoki@reddit (OP)
I think it was a mistake but it is a mistake they all are happy to repeat.
Remember x64? Intel bowed and paid amd for it. Still pays. And I think they are wealthier doing this. Why? Itanium.
I think you are right, it is egos of few assholes up on top which makes them earn less money because they think they will earn less if they open the market.
shroddy@reddit
Afaik, Intel does not pay AMD, but they both allow each other to use their patents.
ptoki@reddit (OP)
true, that is possible. Thank you.
johncate73@reddit
AMD can't make x86 processors of any kind without Intel's blessing, but Intel cannot make x86-64 processors without AMD's, since AMD developed the 64-bit extensions.
They have a cross-licensing agreement and each company is allowed to make x86 CPUs of any kind. I think the patent on 32-bit x86 has expired now, but the ones held by Intel for stuff like MMX, the various versions of SSE, and AVX are still very much in force.
Character-Dot-4078@reddit
OS's will move to immutable blockchains in the future when corporations can no longer protect people.
Asleep-Land-3914@reddit
We need it to shift to RISC in the future, otherwise folks won't get out of x86 unfortunately
Martin_Ehrental@reddit
Why would RISC-V SBC be more open than the ARM ones?
Asleep-Land-3914@reddit
Because there are a lot of ARM ones already which lack normal support from OSes etc. How to compete with saturated market if the only thing you're better at is openness?
techzilla@reddit
Openness is not the issue at hand, its lack of standardized platform.
Martin_Ehrental@reddit
A phone or SBC manufacturer can already do that with ARM. Amper I believe does it already.
I am sure Raspberry would upstream all the drivers if they could. I doubt they would be more successful on that front if they were using a RISK-V processor.
nightblackdragon@reddit
I guess you mean RISC-V but the RISC-V has exactly the same issue. It's just an ISA, it doesn't specify anything about implementation or firmware.
DGolden@reddit
UEFI does have RISC-V in the spec now at least if nothing else. What proportion of RISC-V devices will actually use UEFI I have no idea of course.
https://uefi.org/specs/UEFI/2.11/02_Overview.html#uefi-images
And LoongArch apparently, and of course IA64 is Itanium.
EBC is EFI Byte Code Virtual Machine.
...I do kinda miss Open Firmware though.
nightblackdragon@reddit
Sure you can use UEFI for your RISC-V board but you can do the same for ARM and yet most of ARM boards are not using UEFI. This is the main issue - unlike x86 or even IA64 UEFI is optional and ignored by many manufacturers.
sheeproomer@reddit
X86 has been RISC already for a long time now.
Any x86 CPU since the Pentium II nowadays translates the public available instruction set internally easier to digest instructions.
MatchingTurret@reddit
RISC-V boards can be as closed as ARM boards. It's not the fault of the instruction set if manufacturers ignore standards.
Asleep-Land-3914@reddit
I hope ARM will teach society a good lesson on this one.
MatchingTurret@reddit
You think people will only buy RISC-V devices with a certified UEFI firmware? Not going to happen...
ipsirc@reddit
"ARM (stylised in lowercase as arm, formerly an acronym for Advanced RISC Machines and originally Acorn RISC Machine) is a family of RISC instruction set architectures (ISAs) for computer processors. " - https://en.wikipedia.org/wiki/ARM_architecture_family
Asleep-Land-3914@reddit
Sorry, I meant the next RISC thing whatever it'll be RISC-V or anything else. While x86 uses RISC at the core level, it is not RISC based system on its own.
While translating CISC to RISC works well, now it's being shown by ARM that more optimal instructions set, based on RISC principles has more gains and potential.
fearless-fossa@reddit
They likely meant RISC-V, not RISC in general.
THEHYPERBOLOID@reddit
I think we can safely assume they meant the RISC-V ISA.
ptoki@reddit (OP)
Yeah, I am looking at riscv with some hope. But I worry it may be similar to netwalker case. Theoretically the code is there and driver can be updated, but it is not.
Similarly with riscv, maybe the os will run but will be locked to few simple devices because the rest stopped working with newer kernels...
DRAK0FR0ST@reddit
ARM fragmentation is indeed a problem.
I never understood Linux' users obsession with ARM, when hardware support is a nightmare. Even popular devices like the Raspberry Pi require specific distros, you can't install any distros you want, like you can with X86.
I'm sticking with my custom built X86 desktop, thank you very much.
Scandiberian@reddit
If I were to guess, its because of battery life. Until like a week ago I had an HP and battery on that thing lasted 2 hours on light-ish use if I was lucky.
Granted, the laptop was 9 years old, so the battery was somewhat degraded, but still.
Now I bought a second hand Thinkpad and it lasts way longer so the ARM stress is lowered. I still think it would be cool to get an ARM-chip on Linux though, so that MacBooks can stop being so special. But unfortunately Qualcomm dropped the ball on that.
MartinsRedditAccount@reddit
At most it just needs a specific kernel configuration and modules. Most distros have repos with builds for ARM-based CPUs.
ptoki@reddit (OP)
Same here. I had brief rendezvous with raspberry pi but realized how problematical the arm is (I realized for example that rrd files arent incompatible between x86 and arm, they arent compatible between arm devices - that is not arm fault but still something what never happened on x86). Since then I sticked to x86 and that saved me a ton of headaches.
And very important aspect of this also is: Modern x86 is negligibly less power efficient but is usually very noticeably faster than arm.
These two factors made a world of difference for me.
Still, easier to get a handheld device which is arm based than x86...
daddyd@reddit
100% agree, ARM on anything else besides an open platform is a pain and are locked down hardware.
aperson1054@reddit
Phones are explicitly designed to run Android and since they are not meant to run anything else manufacturers don't waste their resources to support other operating systems
BranchLatter4294@reddit
Get a Raspberry Pi.
ptoki@reddit (OP)
no way, I have been there and will never go back if I dont have to.
Not for general computing. Maybe for some robotics and such.
I could explain why but that is a different topic. Im happy with x86/x64. Way happier than with arm sbc's
But I use pi zeros W2 with pi cameras, that is a good platform for it.
Vasant1234@reddit
Most modern phones run a Linux distribution called Android. Also the AOSP project is open source and you can download or build Lineage OS for many phones and tablets. But I can understand where you are coming from since Android is very different from any x86 distributions. Unlike x86 which has basically 2 CPU vendors and 3 GPU vendors, the ARM is ecosystem is much more diverse with many more CPU/GPU combinations. Based on comments in this forum Linux distribution for x86 has had difficulty working with NVIDIA. So its is unlikely that Linux distributions in its current form will be able to deal with the diversity of ARM SOC's.
ptoki@reddit (OP)
It is actually not really about cpu/gpu. Its about all the peripherials anot not only about them actually but also about their layout and ways to interact with them on low level which is very diverse and undocumented (not to mention not standard)
KilnHeroics@reddit
Pathetic reasons...
Mister_Magister@reddit
it is, it truly is. ARM is just glorified phones and qualcomm's bootup process is so fucked up its beyond any imagination
shroddy@reddit
Is it worse than switching from real mode to protected mode, enable A20 gate, enable paging, enable long mode?
intulor@reddit
Is this really the place for this?
MrAlagos@reddit
Yes, just as much as constant praise about Linux development on Apple-made ARM hardware.
intulor@reddit
Bitching about arm being the end of pc civilization is more for the tin foil hat people with weak minds. Linux already enough fragmentation without people looking to use arm as a scapegoat.
ipsirc@reddit
It is pretty rare to have an ARM device which cant run Linux at all.
MrAlagos@reddit
But it's not rare to have an ARM device that can't run an updated Linux a couple of years after its release, which is the issue.
Dwagner6@reddit
Most things you are complaining about (old phones or mobile devices) use ARM processors because the alternative in the embedded space is way worse, stuck behind tons of NDAs for even basic documentation and proprietary build tools.
It is so hard to “just install Debian” because these are embedded devices— they, by design, have a very limited set of features defined by their use case in order to save cost and power.
You like getting a full day of use out of your phone, right (that also easily fits in your pocket)? All of this is much harder on a general purpose processor.
So, special build environments are needed to create just the right set of software. You can learn how to do it yourself, if you’d like (yocto project, build root, etc).
Embedded Linux is growing and growing in popularity. It just means there’s no one-size fits all solution for “just installing” something else. You have to design and build it yourself.
CyclopsRock@reddit
If your goal is to reduce electronic devices ending up in landfill, making phones use x86 processors would probably achieve this by making everyone not want to buy a phone in the first place.
Personally, though, I'm glad phone makers concentrate on making their phones work well as phones, rather than work well as something totally different that their customers have no real interest in.
ptoki@reddit (OP)
I have a news for you. "phones" act like such for fraction of time. They are used for many other things than just calling/messaging.
CyclopsRock@reddit
Yeah, exactly.
fellipec@reddit
Like I said in my other comment, the problem isn't ARM by itself.
I've a Dell Venue tablet with an Intel Atom CPU. It works fine, have Android 4. In theory I could install Linux on it, Atom CPU, right?
No, I can't.
If by "working well as phones" means something that gets obsolete in a couple of years by no reason, them yes.
My old Android phone is slow as molasses. Have 4GB of RAM and an octa core CPU. It was blazing fast when I bought it. I've an 2007 laptop with a Core2 Duo and 3GB RAM, opens webpages faster than this phone opens now. Android ecosystem is designed to bring good devices to landfills.
jimicus@reddit
X86 is actually the unusual one.
Historically, different manufacturers computers have had subtle incompatibilities even when based on the same architecture.
Routers are even worse than phones. They commonly support PPPOE (which absolutely requires a kernel driver); manufacturers have gone to immense lengths to engineer their products so it isn’t necessary to have a kernel driver which would require GPL licensing.
ptoki@reddit (OP)
True, but the x86 created an ocean of wealth to x86 vendors.
It is sad that they try to limit the options which is actually hurting them.
sneekeruk@reddit
You do realise that ARM devices have been around since the 80s? its just that x86 hasn't been the most power efficient in recent years so Arm has grown in popularity especially when power consumption is a key metric.
Your problem doesn't seem to be with arm, its with Linux development not developing for it. The pi's etc are open so you can read the specs, phones are a closed source hardware, so whilst porting Linux to a phone is possible, there's no hardware documentation out there every phone so it wouldn't be a very simple task.
ptoki@reddit (OP)
Usually negligible difference. been there.
Yes, the arm advantage is in power efficiency but not directly.
My beef is the lack of standards. You cant get raspbian and launch it on google pixel/samsung galaxy OR EVEN pinephone.
Yes, its not arm fault. But arm is the common denominator here. The fact they dont enforce/require standards is the source of this.
LowEquivalent6491@reddit
I don't think this is an ARM problem. It's just that device manufacturers using ARM processors want their devices to become obsolete as quickly as possible.
ptoki@reddit (OP)
True.
topcat5@reddit
Sounds as if your real beef is with the mobile phone manufacturers who don't open up their hardware.
ptoki@reddit (OP)
There is a number of other vendors which also do that.
Network routers, camera devices (the surveillance ones), tablets (not exactly phones but I understand if you seep those into phones pile), some SBC. Probably few more types of devices you could find which run linux but you cant repurpose them.
Some of the IOT devices? media players?
Funny thing is that those fancier game consoles - the chinese ones which emulate a ton of consoles - including ps1 and ps2 actually do support linux to a degree where you can get independent firmware for them.
I_Arman@reddit
Your argument is flawed. "Almost everyone who worked with radioactive material and got cancer wore shoes, therefore, shoes cause cancer."
It's not the processor's fault. It's the mobile device manufacturers fault. More than that, it's in part the fault of everyone who wants a cheap disposable device.
Yes, it's possible to add all the hardware and firmware to support any OS, but there's no market pressure. Very few people would pay extra for the option to install a new operating system, and that simply isn't worth it to design a whole universal boot. The companies would lose a significant amount of money doing that, for no real gain, because mobile devices are built to be disposable.
Saltyigloo@reddit
This guy sudos