7 ms·

> Nobody is even trying. Qualcomm has a $1.5B wager that they can, with the same engineers from Apple who helped them get where they are now. > . Qualcomm, an

> Nobody is even trying. Qualcomm has a $1.5B wager that they can, with the same engineers from Apple who helped them get where they are now. > . Qualcomm, and then Samsung decided licensing ARM’s cores would be easier than trying to outdo them. ... > ARM has a firm grip on the Android market. Samsung, Qualcomm, and MediaTek may develop their own SoCs, but all use CPU core designs from ARM (the company). But they've now reversed that decision, so we'll see whether they can change it.

mschuster91 3y ago
The problem that Qualcomm and all the other ARM manufacturers have: they're impossible for tinkerers to get ahold of, outside of Raspberry Pi and a truckload of shitty, barely supported clones. And even then, the RPi still doesn't have the basics of PCIe working - in 2023 [1]. What. The. Fuck. Yes, Apple theoretically offers ARM devices, but they are not cheap, not extendable at all beyond USB-C and a ton of stuff doesn't work on Linux. In contrast, say I want to develop something on Intel? No problem, I head to Amazon, buy a CPU, a motherboard and try if that old ATX power supply is still working. I plug in whatever card I need and it Just Works. Steve Ballmer was right on track with "developers, developers, developers" - because if the ecosystem is crap or impossible to use for creative people on a low budget, guess what, they won't and go for the alternative. Linux started out on x86 for a reason, and Android blasted Windows Mobile (and everyone else but Apple) to pieces despite it being a solidly established player. A large part was due to neglected developers: outdated APIs, expensive and half-broken dev tools (developing for WinCE was a real pain in the proverbial arse), and a complete inability to even try to match Apple's innovation. Apple had a monopoly on capacitive touchscreens for years! If the ARM ecosystem players actually want to throw punches towards the unholy duopoly of Intel/AMD, they need to standardize on a common core of UEFI and get modular, working components out on the market. [1] https://www.jeffgeerling.com/blog/2022/external-graphics-cards-work-on-raspberry-pi https://www.jeffgeerling.com/blog/2022/external-graphics-car...
- geerlingguy 3y ago
  To be fair, the PCI Express bus on the current Pi was kind of an afterthought, only meant to work with a very limited set of devices, so I'm pretty sure nobody at Broadcom, and few in the design stages at Raspberry Pi, had ever tested more complex devices with it. It works fine in _most_ cases for simple devices (USB controllers, SATA, NVMe, WiFi, and the like), but really falls apart for more advanced devices (hardware RAID, GPU, TPU, etc.). And all Arm processors have to deal with cache coherence issues (which aren't a problem on X86), meaning some drivers (notably, AMD still) need to program for the different architecture (some patches exist but they're not perfect yet, and not in mainline Linux).
  - mschuster91 3y ago
    > To be fair, the PCI Express bus on the current Pi was kind of an afterthought, only meant to work with a very limited set of devices, so I'm pretty sure nobody at Broadcom, and few in the design stages at Raspberry Pi, had ever tested more complex devices with it. The first Raspberry Pi was sold over a decade ago and I 'member people actually using them as embedded boards for whatever stuff they were working with eight years ago (especially once the GPU performance became powerful enough to run digital signage). Sorry but that a company like Broadcom can't be arsed to develop a standards-compliant PCIe interface is a joke, and with this kind of attitude the ARM world complains that no one buys their chips?! (Edit: Oh, just noticed whom I replied to - the person who wrote the article I referred to. HN is a small world indeed, and I guess we share at least some of our frustrations) > meaning some drivers (notably, AMD still) need to program for the different architecture (some patches exist but they're not perfect yet, and not in mainline Linux). Drivers... oh don't get me started on that front. Everyone in the x86 space seems to have learned over the last two decades that it is a good idea to submit drivers to the Linux kernel early. Intel and AMD both do that for CPUs and also for a lot of their other stuff. In contrast, the entire embedded world still locks away drivers behind years-old kernel forks, ridiculous NDAs, absurdly expensive dev boards, completely whack u-boot forks and even more whack BSPs.
  - csdreamer7 3y ago
    > And all Arm processors have to deal with cache coherence issues (which aren't a problem on X86), meaning some drivers Why are they a problem on Arm and not x86?
- lizknope 3y ago
  > The problem that Qualcomm and all the other ARM manufacturers have: they're impossible for tinkerers to get ahold of This sounds more like a problem tinkerers have rather than a problem that Qualcomm or ARM manufacturers have. Qualcomm doesn't care about the tinkerers so it's not a problem to them. Embedded ARM systems like my router or smart thermostat seem fine. Google controls Android and it also seems fine for 99% of their users. There are thousands of Android developers. There are ARM boot standards like https://developer.arm.com/documentation/den0029/latest/ https://developer.arm.com/documentation/den0029/latest/ https://en.wikipedia.org/wiki/Server_Base_System_Architecture https://en.wikipedia.org/wiki/Server_Base_System_Architectur... But in general embedded device makers don't care about having a common boot system. They want to make their device as cheaply as possible. If the common standard helps them do that then they would adopt it. Otherwise it is unnecessary overhead. So what do you actually want? A cheap desktop level ARM system? I doubt that is going to happen. The number of people who want such a thing is extremely low even though places like Hacker News make it seem like it would be popular.
  - amluto 3y ago
    > Qualcomm doesn't care about the tinkerers so it's not a problem to them. Qualcomm is selling performance. Performance is a combination of the hardware and the tubing that developers do to make their products perform well on the hardware. On x86 or M1/M2, developers develop on those chips. Graviton and Qualcomm trail significantly in this regard.
    - lizknope 3y ago
      Listening to the Qualcomm management they seemed more interested in selling licenses to technology than actual physical products. But Qualcomm is selling more than just performance. Cost, quality, schedule, delivery of products. Qualcomm has shown they can make an SoC good enough satisfy a lot of phone manufacturers and there are thousands of Android developers and applications. Would the Qualcomm / Google / Android ecosystem be better if they opened up more of the hardware specs to tinkerers? Maybe but I don't think they care or they don't see the business case. Apple's ecosystem is even more closed and their performance seems to be better in general. I sat in a lot of all hands meetings when I was there listening to revenue and profit breakdown. The QTL licensing division was far more profitable than the QCT hardware division. These numbers are publicly available.
- saratogacx 3y ago
  Qualcomm doesn't have a storefront, that's true, but they have a partner search that will show you all the partner-made development kits you can buy. They aren't going to be nearly as inexpensive as an rPI but they don't make finding products you can get too difficult and it isn't just nabbing some random board from AliExpress. https://www.qualcomm.com/support/qan/member-directory?activeCategory=Hardware&facetRegions=United+States&facetItemSubType=Development+Board+/+Kit#member-offerings https://www.qualcomm.com/support/qan/member-directory?active...
- schaefer 3y ago
  > ...they need to standardize on a common core of UEFI and get modular, working components out on the market. Except that this DOES already exists. Right now. The standard is called: Arm SystemReady SR [1]. I'll be the first to admit: It's far from ideal. There are only a couple of high-end options on the market and lead times are measured in weeks. But this development is new as of this year. And I think it's terribly exciting movement in the right direction (finally). [1]: https://www.arm.com/architecture/system-architectures/systemready-certification-program/sr https://www.arm.com/architecture/system-architectures/system...
  - mschuster91 3y ago
    I admit it's been two years since I last dabbled in embedded, never heard of that one. I hope this initiative finds some success!
- IOT_Apprentice 3y ago
  I’ve been wondering if ANYONE has done something with the more recent AppleTV4K hardware and ported say ashai or other Linux versions being worked on for Apple Silicon. Or perhaps getting containers running on the hardware.
re-thc 3y ago
> Qualcomm has a $1.5B wager that they can, with the same engineers from Apple who helped them get where they are now. Maybe or maybe not. Qualcomm has a history of price fixing, bullying and shutting off competitors rather than trying to do better. Perhaps they're just shutting down the Nuvia here too. Back then nVidia Tegra tried to compete until Qualcomm went around complaining... The pest is Qualcomm more than anything.

mschuster91 3y ago

The problem that Qualcomm and all the other ARM manufacturers have: they're impossible for tinkerers to get ahold of, outside of Raspberry Pi and a truckload of shitty, barely supported clones. And even then, the RPi still doesn't have the basics of PCIe working - in 2023 [1]. What. The. Fuck. Yes, Apple theoretically offers ARM devices, but they are not cheap, not extendable at all beyond USB-C and a ton of stuff doesn't work on Linux. In contrast, say I want to develop something on Intel? No problem, I head to Amazon, buy a CPU, a motherboard and try if that old ATX power supply is still working. I plug in whatever card I need and it Just Works. Steve Ballmer was right on track with "developers, developers, developers" - because if the ecosystem is crap or impossible to use for creative people on a low budget, guess what, they won't and go for the alternative. Linux started out on x86 for a reason, and Android blasted Windows Mobile (and everyone else but Apple) to pieces despite it being a solidly established player. A large part was due to neglected developers: outdated APIs, expensive and half-broken dev tools (developing for WinCE was a real pain in the proverbial arse), and a complete inability to even try to match Apple's innovation. Apple had a monopoly on capacitive touchscreens for years! If the ARM ecosystem players actually want to throw punches towards the unholy duopoly of Intel/AMD, they need to standardize on a common core of UEFI and get modular, working components out on the market. [1] https://www.jeffgeerling.com/blog/2022/external-graphics-cards-work-on-raspberry-pi https://www.jeffgeerling.com/blog/2022/external-graphics-car...

geerlingguy 3y ago
To be fair, the PCI Express bus on the current Pi was kind of an afterthought, only meant to work with a very limited set of devices, so I'm pretty sure nobody at Broadcom, and few in the design stages at Raspberry Pi, had ever tested more complex devices with it. It works fine in _most_ cases for simple devices (USB controllers, SATA, NVMe, WiFi, and the like), but really falls apart for more advanced devices (hardware RAID, GPU, TPU, etc.). And all Arm processors have to deal with cache coherence issues (which aren't a problem on X86), meaning some drivers (notably, AMD still) need to program for the different architecture (some patches exist but they're not perfect yet, and not in mainline Linux).
- mschuster91 3y ago
  > To be fair, the PCI Express bus on the current Pi was kind of an afterthought, only meant to work with a very limited set of devices, so I'm pretty sure nobody at Broadcom, and few in the design stages at Raspberry Pi, had ever tested more complex devices with it. The first Raspberry Pi was sold over a decade ago and I 'member people actually using them as embedded boards for whatever stuff they were working with eight years ago (especially once the GPU performance became powerful enough to run digital signage). Sorry but that a company like Broadcom can't be arsed to develop a standards-compliant PCIe interface is a joke, and with this kind of attitude the ARM world complains that no one buys their chips?! (Edit: Oh, just noticed whom I replied to - the person who wrote the article I referred to. HN is a small world indeed, and I guess we share at least some of our frustrations) > meaning some drivers (notably, AMD still) need to program for the different architecture (some patches exist but they're not perfect yet, and not in mainline Linux). Drivers... oh don't get me started on that front. Everyone in the x86 space seems to have learned over the last two decades that it is a good idea to submit drivers to the Linux kernel early. Intel and AMD both do that for CPUs and also for a lot of their other stuff. In contrast, the entire embedded world still locks away drivers behind years-old kernel forks, ridiculous NDAs, absurdly expensive dev boards, completely whack u-boot forks and even more whack BSPs.
- csdreamer7 3y ago
  > And all Arm processors have to deal with cache coherence issues (which aren't a problem on X86), meaning some drivers Why are they a problem on Arm and not x86?
lizknope 3y ago
> The problem that Qualcomm and all the other ARM manufacturers have: they're impossible for tinkerers to get ahold of This sounds more like a problem tinkerers have rather than a problem that Qualcomm or ARM manufacturers have. Qualcomm doesn't care about the tinkerers so it's not a problem to them. Embedded ARM systems like my router or smart thermostat seem fine. Google controls Android and it also seems fine for 99% of their users. There are thousands of Android developers. There are ARM boot standards like https://developer.arm.com/documentation/den0029/latest/ https://developer.arm.com/documentation/den0029/latest/ https://en.wikipedia.org/wiki/Server_Base_System_Architecture https://en.wikipedia.org/wiki/Server_Base_System_Architectur... But in general embedded device makers don't care about having a common boot system. They want to make their device as cheaply as possible. If the common standard helps them do that then they would adopt it. Otherwise it is unnecessary overhead. So what do you actually want? A cheap desktop level ARM system? I doubt that is going to happen. The number of people who want such a thing is extremely low even though places like Hacker News make it seem like it would be popular.
- amluto 3y ago
  > Qualcomm doesn't care about the tinkerers so it's not a problem to them. Qualcomm is selling performance. Performance is a combination of the hardware and the tubing that developers do to make their products perform well on the hardware. On x86 or M1/M2, developers develop on those chips. Graviton and Qualcomm trail significantly in this regard.
  - lizknope 3y ago
    Listening to the Qualcomm management they seemed more interested in selling licenses to technology than actual physical products. But Qualcomm is selling more than just performance. Cost, quality, schedule, delivery of products. Qualcomm has shown they can make an SoC good enough satisfy a lot of phone manufacturers and there are thousands of Android developers and applications. Would the Qualcomm / Google / Android ecosystem be better if they opened up more of the hardware specs to tinkerers? Maybe but I don't think they care or they don't see the business case. Apple's ecosystem is even more closed and their performance seems to be better in general. I sat in a lot of all hands meetings when I was there listening to revenue and profit breakdown. The QTL licensing division was far more profitable than the QCT hardware division. These numbers are publicly available.
saratogacx 3y ago
Qualcomm doesn't have a storefront, that's true, but they have a partner search that will show you all the partner-made development kits you can buy. They aren't going to be nearly as inexpensive as an rPI but they don't make finding products you can get too difficult and it isn't just nabbing some random board from AliExpress. https://www.qualcomm.com/support/qan/member-directory?activeCategory=Hardware&facetRegions=United+States&facetItemSubType=Development+Board+/+Kit#member-offerings https://www.qualcomm.com/support/qan/member-directory?active...
schaefer 3y ago
> ...they need to standardize on a common core of UEFI and get modular, working components out on the market. Except that this DOES already exists. Right now. The standard is called: Arm SystemReady SR [1]. I'll be the first to admit: It's far from ideal. There are only a couple of high-end options on the market and lead times are measured in weeks. But this development is new as of this year. And I think it's terribly exciting movement in the right direction (finally). [1]: https://www.arm.com/architecture/system-architectures/systemready-certification-program/sr https://www.arm.com/architecture/system-architectures/system...
- mschuster91 3y ago
  I admit it's been two years since I last dabbled in embedded, never heard of that one. I hope this initiative finds some success!
IOT_Apprentice 3y ago
I’ve been wondering if ANYONE has done something with the more recent AppleTV4K hardware and ported say ashai or other Linux versions being worked on for Apple Silicon. Or perhaps getting containers running on the hardware.

re-thc 3y ago

> Qualcomm has a $1.5B wager that they can, with the same engineers from Apple who helped them get where they are now. Maybe or maybe not. Qualcomm has a history of price fixing, bullying and shutting off competitors rather than trying to do better. Perhaps they're just shutting down the Nuvia here too. Back then nVidia Tegra tried to compete until Qualcomm went around complaining... The pest is Qualcomm more than anything.