11 ms·

I don’t think they have a plan B. Architectures take half a decade of work. Porting from risc-v to arm is not a matter of a backup plan, it’s that of a very cos

I don’t think they have a plan B. Architectures take half a decade of work. Porting from risc-v to arm is not a matter of a backup plan, it’s that of a very costly pivot.

betaby 2y ago
I suppose Google ( + Samsung ) can bear that cost in the context of Android Arm -> Android RISC-V.
gjsman-1000 2y ago
No kidding; and while RISC-V is a massive improvement, I hate to be the wet blanket, but RISC-V will not change signed boot, bootloader restrictions, messy or closed source drivers, carrier requirements, DRM implementation, or other painful day to day paper cuts. Open source architecture != Open source software and certainly != Open source hardware; no matter what the YouTubers think.
- deleted 2y ago
  [deleted]
- Atotalnoob 2y ago
  Until arm or risc-v fix standardize the bootloader, it’s always going to be a big deal for each arm/risc device added anywhere…
  - snvzz 2y ago
    Relevant RISC-V specs were released years ago and implementations follow them. I know of no boards that have application processors and yet not implement SBI. Furthermore, everybody seems to be using the opensbi implementation. ARM and RISC-V are not the same.
snvzz 2y ago
Qualcomm's been involved with RISC-V for several years now. If anything, ARM is the plan B that they'll likely end up abandoning.
- dagmx 2y ago
  It’s a bit much to say their primary product that they’ve done for decades is a plan B. By definition it cannot be a plan B if it’s executed first and is successful. I think a lot of RISC-V advocates are perhaps a little too over eager in their perception of the landscape.
  - snvzz 2y ago
    Typo. Meant to write "ARM is the plan A that they'll likely end up abandoning".
mkl 2y ago
Qualcomm has been working on RISC-V for a while, at outwardly-small scale. It's probably intended as a long-term alternative rather than a ready-to-go plan B. From a year ago: "The most exciting part for us at Qualcomm Technologies is the ability to start with an open instruction set. We have the internal capabilities to create our own cores — we have a best-in-class custom central processing unit (CPU) team, and with RISC-V, we can develop, customize and scale easily." -- https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and-why-were-unlocking-its-potential https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and..., more: https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web
- hajile 2y ago
  Qualcomm pitched a Znew extension for RISC-V that basically removes compressed (16-bit) instructions and adds more ARM64-like stuff. It felt very much like trying to make an easier plan B for if/when they need/want to transition from ARM to RISC-V. https://lists.riscv.org/g/tech-profiles/attachment/332/0/code_size_extension_rvi_20231006.pdf https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...
brucehoult 2y ago
Qualcomm have a Plan B. This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. The proposed extension was actually not bad, and could very reasonably be adopted. Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. RISC-V will eventually need a deprecation policy and procedure -- and the "C" extension could potentially be replaced by something else -- but you wouldn't find anyone who thinks the deprecated-but-supported period should be less than 10 years. So they'd have to support both "C" and its replacement anyway. Qualcomm tried to make a case that decoding two instruction widths is too hard to do in a very wide (e.g. 8) instruction decoder. Everyone else working on designs in that space ... SiFive, Rivos, Ventana, Tenstorrent ... said "nah, it didn't cause us any problems". Qualcomm jumped on a "we're listening, tell us more" from Rivos as being support for dropping "C" .. and were very firmly corrected on that.
- wmf 2y ago
  Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. Android was never really Linux though.
  - refulgentis 2y ago
    This is officially too much quibbling, even if we settled philosophical questions like "Is Android Linux?" Then "If not, would dropping C make RISC nonviable", there isn't actually an Android version that'll do RISC anywhere near on the horizon. Support _reversed_ for it, got pulled 5 months ago
    - snvzz 2y ago
      >Support _reversed_ for it, got pulled 5 months ago Cursory research will yield that this was a technicality with no weight in Google's strong commitment to RISC-V Android support.
snvzz 2y ago
It would be naive to think that Qualcomm is only starting its RISC-V effort today and from scratch.

I don’t think they have a plan B. Architectures take half a decade of work. Porting from risc-v to arm is not a matter of a backup plan, it’s that of a very costly pivot.

betaby 2y ago

I suppose Google ( + Samsung ) can bear that cost in the context of Android Arm -> Android RISC-V.

gjsman-1000 2y ago

No kidding; and while RISC-V is a massive improvement, I hate to be the wet blanket, but RISC-V will not change signed boot, bootloader restrictions, messy or closed source drivers, carrier requirements, DRM implementation, or other painful day to day paper cuts. Open source architecture != Open source software and certainly != Open source hardware; no matter what the YouTubers think.

deleted 2y ago
[deleted]
Atotalnoob 2y ago
Until arm or risc-v fix standardize the bootloader, it’s always going to be a big deal for each arm/risc device added anywhere…
- snvzz 2y ago
  Relevant RISC-V specs were released years ago and implementations follow them. I know of no boards that have application processors and yet not implement SBI. Furthermore, everybody seems to be using the opensbi implementation. ARM and RISC-V are not the same.

snvzz 2y ago

Qualcomm's been involved with RISC-V for several years now. If anything, ARM is the plan B that they'll likely end up abandoning.

dagmx 2y ago
It’s a bit much to say their primary product that they’ve done for decades is a plan B. By definition it cannot be a plan B if it’s executed first and is successful. I think a lot of RISC-V advocates are perhaps a little too over eager in their perception of the landscape.
- snvzz 2y ago
  Typo. Meant to write "ARM is the plan A that they'll likely end up abandoning".

mkl 2y ago

Qualcomm has been working on RISC-V for a while, at outwardly-small scale. It's probably intended as a long-term alternative rather than a ready-to-go plan B. From a year ago: "The most exciting part for us at Qualcomm Technologies is the ability to start with an open instruction set. We have the internal capabilities to create our own cores — we have a best-in-class custom central processing unit (CPU) team, and with RISC-V, we can develop, customize and scale easily." -- https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and-why-were-unlocking-its-potential https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and..., more: https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web

hajile 2y ago
Qualcomm pitched a Znew extension for RISC-V that basically removes compressed (16-bit) instructions and adds more ARM64-like stuff. It felt very much like trying to make an easier plan B for if/when they need/want to transition from ARM to RISC-V. https://lists.riscv.org/g/tech-profiles/attachment/332/0/code_size_extension_rvi_20231006.pdf https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...

brucehoult 2y ago

Qualcomm have a Plan B. This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. The proposed extension was actually not bad, and could very reasonably be adopted. Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. RISC-V will eventually need a deprecation policy and procedure -- and the "C" extension could potentially be replaced by something else -- but you wouldn't find anyone who thinks the deprecated-but-supported period should be less than 10 years. So they'd have to support both "C" and its replacement anyway. Qualcomm tried to make a case that decoding two instruction widths is too hard to do in a very wide (e.g. 8) instruction decoder. Everyone else working on designs in that space ... SiFive, Rivos, Ventana, Tenstorrent ... said "nah, it didn't cause us any problems". Qualcomm jumped on a "we're listening, tell us more" from Rivos as being support for dropping "C" .. and were very firmly corrected on that.

wmf 2y ago
Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. Android was never really Linux though.
- refulgentis 2y ago
  This is officially too much quibbling, even if we settled philosophical questions like "Is Android Linux?" Then "If not, would dropping C make RISC nonviable", there isn't actually an Android version that'll do RISC anywhere near on the horizon. Support _reversed_ for it, got pulled 5 months ago
  - snvzz 2y ago
    >Support _reversed_ for it, got pulled 5 months ago Cursory research will yield that this was a technicality with no weight in Google's strong commitment to RISC-V Android support.

snvzz 2y ago

It would be naive to think that Qualcomm is only starting its RISC-V effort today and from scratch.