← Back to context

Comment by nrclark

20 hours ago

If anybody in Qualcomm leadership is reading this thread: this is a good start, and I applaud you for it. There is also a lot more to do if you're serious about growing your market penetration beyond phones.

The drivers might be up on LKML, but they're not mainlined yet. And this is just gen5. It would be great if you could fix your gen4 and 4.5 drivers, so that people building products with your chips weren't stuck on an orphaned vendor kernel that doesn't even upstream to your public fork.

Also your boot-chain is still closed and proprietary, and completely different than the one used by all other ARM vendors. Being the special snowflake is not helping your business or your customers.

And don't even get me started on Gunyah and GearVM, or on the proprietary, locked nature of your BSP, or how far behind TI and NXP you are on software quality and ease of use. Maybe also consider releasing some actual documentation on your chips.

I know multiple developers who have sworn off Qualcomm and will never design with your chips again at any price point. Your closed-off support model is 100% the culprit, and it hurts your core business. Any software support revenue that you managage to extract comes at the cost of goodwill and future chip sales.

Your chips are good - best in the industry. If you can up your software game to match, you'll really meet your potential.

24 comments

nrclark

Reply
flto  18 hours ago

> Also your boot-chain is still closed and proprietary

Nowadays the entire thing until you land in EL1 needs to be signed by Qualcomm as well. This is without "Secure Boot" enabled. OEMs only get to run code under the hypervisor. And you might want to use a part of the hardware but someone decided the VM your code runs in shouldn't have access to that, too bad.

zozbot234  20 hours ago

> ... Also your boot-chain is still closed and proprietary, and completely different than the one used by all other ARM vendors. Being the special snowflake is not helping your business or your customers. ...

Why does the boot-chain matter? Can't we just have a custom U-Boot implementation that interacts with the bespoke boot chain while providing standard UEFI support to the rest of the system? Isn't that how Asahi works?

  • nrclark  20 hours ago

    It matters when you're doing custom hardware, or when you're designing a product where boot speed matters, or when you need to implement something special.

    A full-featured U-Boot implementation would be fine IMO. But for the generations that I've used, that's not on the table. What we get is a proprietary flow through a proprietary hypervisor into a fork of Android's bootloader (even if vanilla Linux is the target OS). There's no way to control startup boot options, and no way to use KVM, Xen or any hypervisor except the proprietary one that's also part of the boot chain.

    This doesn't lend itself to flexible products, or to products that are easy for a company to design or support. That is why things like this happen: https://news.ycombinator.com/item?id=46008156

  • eqvinox  12 hours ago

    Aside from the sibling comments, it also matters that you need to be able to review it if you need to build a truly "secure" product. History is littered with broken, unfixable secure boot implementations.

  • ryukoposting  13 hours ago

    Because a computer isn't just a processor. It has to interact with an EC, IO controllers, and whatnot, and if you don't have control over the boot chain, all of that stuff becomes an even bigger PITA than it already is.

my123  13 hours ago

> And don't even get me started on Gunyah and

Gunyah is disappearing from new chips, slowly but surely.

X2 doesn't have it anymore, the IoT range has it as optional now. And it's going to be deployed less from there

  • nrclark  13 hours ago

    Awesome, that's great to hear. Now if Qualcomm would only relax the walls between their business units, their other customers could benefit as well.

    Who benefits from having separate BUs maintain fully separate software stacks? It's duplicated, wasted effort on Qualcomm's part. Maybe it lets them double-charge their customers for this duplicate effort, but that feels short-sighted. It leaves a bad taste in their customers' mouths. And there's certainly no benefit in delivered software quality.

    Qualcomm should be making it easy for everybody to buy and use their chips, not artificially segmenting every single customer. They could sweep the market so hard if they were just a little less greedy.

ryukoposting  13 hours ago

Thanks for the constructive framing. My gut reaction was "great job, you're doing the minimum"

  • mumber_typhoon  12 hours ago

    If I was to guess, id say someone did this as a side project at QC because maybe they like FOSS and want to give something back. Given the partnership between QC and MSFT for laptops and Google for android, I won't be surprised if we never see interest from QC for any real linux hardware.

modeless  17 hours ago

Second best, after Apple.