I was thinking about ARM at one point, but you’ve got a couple of major drawbacks.
Most ARM devices are SoC, and where they get some of their cost and power savings. That’s kinda the opposite of modular.
ARM running ARM binaries can be more-power-efficient than x86 running x86 binaries. An ARM platform can run x86 binaries via x86 emulation, but then your power benefits go away (probably get worse power efficiency). For Windows, I assume that there’s some form of OS-level emulation, but you’ve got a lot of binary software out there. For Linux, if you’re using all open-source software that can be rebuilt for ARM, and assuming that you have ARM driver support, then you could maybe run only ARM binaries. But if you want to, for example, use Steam, then you are going to be using binary-only x86 software. Now, okay, that depends a lot on your use case, but that may be a real drawback if you play games on the thing.
That also sounds kind of like compatibility is still limited – they’re saying that some ARM platforms can’t do 32-bit x86 binaries, at least two years ago. Dunno if that’s still an issue.
I mean, what is the difference between the current SoC and the soldered CPU? Sure you can save on upgrading RAM, but then what else? Especially if the SoC has PCIe. They can make a daughter board for the SoC to make it simpler to upgrade if they want, alà pi compute module.
its not that simple. high performamce parts are high performamce because the devices that need the fastest speeds have the shortest traces from CPU to said device. its for instance, why the ram slots, and the fastest m.2/slot as well as pci-e lanes are nearest to the cpu, else youd have to resort to adding a south bridge.
the pi compute module works that way because the ram is already on board making it not a problem, and latency to whatever it gets mounted on isnt of highest priority for performance.
its why sodimm for instance has hit a peak speed limit, while lpdde hasnt, and why dell pitched the camm form factor for ram. distance of components to the cpu and its stability is cruicial for performance.
What I am saying is that the current soldered CPU approach on laptop space is not that different from switching an ARM SoC on a daughter board. The only difference is that you cannot change RAM. Maybe that too will change as you said with CAMM standard. Next is that some SBC already supported PCIe for external M.2 storage, so you can theoretically hook up a removable GPU there.
Now, what to do with the old SoC daughter board? The same as with the old framework motherboard. You can repurpose it as another computer.
The point is, framework repairability comes not only from part swapping, but also the promise of providing schematic for board level repair. They can totally make ARM based laptops with SoC repairable if they wanted to. But I suspect they will not (at least in the near future) since there is a lot to do for them.
m.2 to gpu isn’t completely foreign nor new, but less practical than more recent standards like Occulink. the problem, specifically with the lower end model in particular, is using 4/8 pci-e lanes for a port that not everyone is going to use is a waste of the already limited amount of pci-e lanes available to the user because of the CPU choice. hence, it makes sense to keep 1 users with the side option to using usb4/thunderbolt gpu docks
I don’t see what’s non-modular about ARM. Most of the stuff that’s user-serviceable on a Framework laptop would be serviceable with ARM:
ports are all USB-C
drives are NVMe, SATA, or PCIe - Pine64 has boards with each (IIRC)
GPU is PCIe - again, Pine64 has that on their RockPro64
The only difference is RAM, and theoretically they could design a socketable SOC to reuse existing boards (not sure what happened to Project Skybridge). The only difference is RAM, at least for the user, and I really don’t think that’ll be a deal-breaker. Modern x86 chips are already essentially SOCs anyway…
I was thinking about ARM at one point, but you’ve got a couple of major drawbacks.
Most ARM devices are SoC, and where they get some of their cost and power savings. That’s kinda the opposite of modular.
ARM running ARM binaries can be more-power-efficient than x86 running x86 binaries. An ARM platform can run x86 binaries via x86 emulation, but then your power benefits go away (probably get worse power efficiency). For Windows, I assume that there’s some form of OS-level emulation, but you’ve got a lot of binary software out there. For Linux, if you’re using all open-source software that can be rebuilt for ARM, and assuming that you have ARM driver support, then you could maybe run only ARM binaries. But if you want to, for example, use Steam, then you are going to be using binary-only x86 software. Now, okay, that depends a lot on your use case, but that may be a real drawback if you play games on the thing.
googles
https://old.reddit.com/r/linux_gaming/comments/tqem55/you_can_now_run_steam_games_with_proton_on_an_arm/
That also sounds kind of like compatibility is still limited – they’re saying that some ARM platforms can’t do 32-bit x86 binaries, at least two years ago. Dunno if that’s still an issue.
I mean, what is the difference between the current SoC and the soldered CPU? Sure you can save on upgrading RAM, but then what else? Especially if the SoC has PCIe. They can make a daughter board for the SoC to make it simpler to upgrade if they want, alà pi compute module.
its not that simple. high performamce parts are high performamce because the devices that need the fastest speeds have the shortest traces from CPU to said device. its for instance, why the ram slots, and the fastest m.2/slot as well as pci-e lanes are nearest to the cpu, else youd have to resort to adding a south bridge.
the pi compute module works that way because the ram is already on board making it not a problem, and latency to whatever it gets mounted on isnt of highest priority for performance.
its why sodimm for instance has hit a peak speed limit, while lpdde hasnt, and why dell pitched the camm form factor for ram. distance of components to the cpu and its stability is cruicial for performance.
What I am saying is that the current soldered CPU approach on laptop space is not that different from switching an ARM SoC on a daughter board. The only difference is that you cannot change RAM. Maybe that too will change as you said with CAMM standard. Next is that some SBC already supported PCIe for external M.2 storage, so you can theoretically hook up a removable GPU there.
Now, what to do with the old SoC daughter board? The same as with the old framework motherboard. You can repurpose it as another computer.
The point is, framework repairability comes not only from part swapping, but also the promise of providing schematic for board level repair. They can totally make ARM based laptops with SoC repairable if they wanted to. But I suspect they will not (at least in the near future) since there is a lot to do for them.
m.2 to gpu isn’t completely foreign nor new, but less practical than more recent standards like Occulink. the problem, specifically with the lower end model in particular, is using 4/8 pci-e lanes for a port that not everyone is going to use is a waste of the already limited amount of pci-e lanes available to the user because of the CPU choice. hence, it makes sense to keep 1 users with the side option to using usb4/thunderbolt gpu docks
I don’t see what’s non-modular about ARM. Most of the stuff that’s user-serviceable on a Framework laptop would be serviceable with ARM:
The only difference is RAM, and theoretically they could design a socketable SOC to reuse existing boards (not sure what happened to Project Skybridge). The only difference is RAM, at least for the user, and I really don’t think that’ll be a deal-breaker. Modern x86 chips are already essentially SOCs anyway…