Hacker News Reader

> 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.

not all true. And Qualcomm taking over EL2 is optional now

What is not true?

EL2 is still locked down for the chip this post is about, AFAIK. And everything else is is staying locked.

AFAIK Google runs their own EL3 on the Snapdragon Chromebooks. (And KVM at EL2)

Lots of this is customer dependent but what you say is true for the typical android phone config that most use

The Snapdragon Chromebooks use older chips that didn't have the locked down boot-chain yet. Even if you didn't have the official EL3 unlock that Google got, you could still get into EL3 trivially if you wanted to.

It will be interesting to see what Google got from Qualcomm for the new Chromebooks (EL3 isn't even the highest level anymore, that's TME now).

> It will be interesting to see what Google got from Qualcomm for the new Chromebooks (EL3 isn't even the highest level anymore, that's TME now).

The new AL BSP target for Hamoa, which is what's going to ship on the new Android laptops, runs KVM at EL2 instead of Gunyah. But it has (at least partially) Qualcomm-owned EL3.

> ... 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?

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

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.

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.

> 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

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.

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

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.

They hired Linaro (Linux Consultancy) for it so not just a side project

Second best, after Apple.

https://en.wikipedia.org/wiki/Qualcomm#2015–2024:_NXP,_Broad...

Apple, whose FOSS support is reliant on volunteers reverse engineering their shit?

This is much better than that. Not great yet, but much better than that in comparison.

Comparing the chips, not the software, Apple's chips are better than Qualcomm's.

I agree Qualcomm's support of open source is better, while still leaving a lot to be desired.

I guess you were specifically replying to the last paragraph; that wasn't clear to me at all. A quote would've helped :)

That said, though, Apple can't be best for embedded applications, they're plainly not competing in that space - or can you make e.g. a custom ticket vending machine with an Apple chip?

Yeah that page smells like a pr stunt.

Go all in or go home, qualcomm.

You'd rather have nothing it seems.

It doesn't matter much anyway, at least at this point.

Kinda yes?

Nowadays the standards for Linux support are much higher. This isn't the 1990s anymore. Releasing a half-assed support that will be obsolete in six months is pretty much useless.

Also, the fact that the drivers have not been upstreamed tells me they're most likely sub-par in terms of code quality and possibly stability.

What's the point of buying hardware whose softwares support is already deteriorating ?