Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian riscv64

blog.aurel32.net

Post reply on HN
Print view View original

101–110 of 155 posts

Re: Debian riscv64

#101

Post by cmrdporcupine »

Tepix wrote: post #58
KingLancelot wrote: post #35

Earlier quoted context omitted.

Microsoft, Intel, AMD, NVIDIA. Only one I didn’t see was Apple, hell even Raspberry Pi is there.

Apple is also interested, they were hiring a RISC-V engineer back in 2021 already.

I can't a realistic scenario see Apple moves off Aarch64 at this point for their MPU. They're having boatloads of success with what they've done there.

But I can imagine there's interest on their part in using something like RISC-V in supporting chipsets; modems, power mgmt, disk controllers, etc.

That and having something in their backpocket "just in case."

Re: Debian riscv64

#102

Post by klelatti »

cmrdporcupine wrote: post #100
superdug wrote: post #52

I wanted to check first, and I wasn't saddened when I found netbsd was also available for riscv64. That being said, having a full debian suite to nicely land on is what will gain it adoption. It's a chicken and egg problem where one side is vigorously designing and publishing a hardware spec in search of an operating system and at the same time an entire eco-system of open source development is in search of open hard…

"Fully open systems are an entirely ideological win at this point with a now sub-$50 entry point setups available today." It's not entirely ideological. The advantage an open, license-free, RISC-V brings to the table is ISA flexibility and freedom, the ability for people to bring innovation in terms of extensions, create their own flavours. And where we'll hopefully see this innovation is in realms like AI and graphi…

> We've already seen the excellent things Apple was able to do with ARM because they had the chip under their own control and were no longer beholden to ARM (or Motorola/IBM before that).

Sorry? Apple remains an Arm licensee and everything they have done will be consistent with the terms of their license.

Re: Debian riscv64

#104

Post by cmrdporcupine »

klelatti wrote: post #102
cmrdporcupine wrote: post #100

Earlier quoted context omitted.

"Fully open systems are an entirely ideological win at this point with a now sub-$50 entry point setups available today." It's not entirely ideological. The advantage an open, license-free, RISC-V brings to the table is ISA flexibility and freedom, the ability for people to bring innovation in terms of extensions, create their own flavours. And where we'll hopefully see this innovation is in realms like AI and graphi…

> We've already seen the excellent things Apple was able to do with ARM because they had the chip under their own control and were no longer beholden to ARM (or Motorola/IBM before that). Sorry? Apple remains an Arm licensee and everything they have done will be consistent with the terms of their license.

Oh, just noticed I'd written "with ARM" when I meant to write Intel when talking about Apple being beholden. Fixed.

My understanding is Apple has an architectural license, broader than what some other licensees have, and it permits them to make architectural changes that people without that license cannot. And while I don't know the current business terms of this, I would speculate that by them being part of the original joint venture that created ARM in the first place they have at least some remaining better pricing on that than others would?

In any case, correct me if I'm wrong on that... but there's also the fact that by controlling the whole software stack Apple is also able to initiate changes that would be difficult for any other hardware vendor.

Re: Debian riscv64

#105

Post by bee_rider »

ur-whale wrote: post #73
LatticeAnimal wrote: post #3

I don't fully understand riscv, but shouldn't this be something like `RV64GC`? Are they building for the base riscv with no isa extensions? This might be addressed somewhere in the debian docs but I didn't see it.

If there is a downfall of RISCV, it's going to be the myriad of sub-architectures and their weird naming schemes, with an added layer of marketing drones muddying up the waters even further. This is going to confuse the hell out of the potential customer base and it would be a crying shame, wasting a golden opportunity to get out of the oxygen-choking clutches of proprietary ISA vendors (who at this point are purely…

I mean, in the very least the proprietary ISA vendors provide the service of selecting what extensions are added. If you think too many extensions will take down RISC-V, that seems to have value.

Re: Debian riscv64

#106

Post by giantrobot »

leonheld wrote: post #92
giantrobot wrote: post #86

Earlier quoted context omitted.

> it was always the binary blobs required to run IP blocks put on the die with the cores that stopped people from using them That's not going to change with RISC-V. If you've got silicon that has to conform with FCC regulations it's going to have non-modifiable firmware. No matter how open the rest of the system is, your WiFi and Bluetooth (and any other radios) will have closed firmware.

I'm not from the US so not really familiar with FCC regulations. > If you've got silicon that has to conform with FCC regulations it's going to have non-modifiable firmware. Can you explain 'why?' or maybe throw me a link or two? Thanks!

The why is simple: Power/frequency limits allow everybody to be able to use personal consumer devices without licensing and without preventing other people from using their devices. If you modified your WiFi to blast out a 10W signal across multiple channels at your house, you completely ruin my ability to use Wifi at my house next door. Radio spectrum is shared by everybody.

As for reading there's CFR title 47 [0]. Parts 15 and 18 are germane for unlicensed radios and electronic devices. Parts 22 and 24 cover cellular devices.

The regulations don't explicitly say anything about firmware but to build devices that follow the regulations end user modifiable firmware is an implicit restriction. Even user serviceable antennas are restricted because radio device licenses cover not just the electrical output but total gain of the shipped antenna.

[0] https://www.ecfr.gov/current/title-47

Re: Debian riscv64

#107

Post by klelatti »

cmrdporcupine wrote: post #104
klelatti wrote: post #102

Earlier quoted context omitted.

> We've already seen the excellent things Apple was able to do with ARM because they had the chip under their own control and were no longer beholden to ARM (or Motorola/IBM before that). Sorry? Apple remains an Arm licensee and everything they have done will be consistent with the terms of their license.

Oh, just noticed I'd written "with ARM" when I meant to write Intel when talking about Apple being beholden. Fixed. My understanding is Apple has an architectural license, broader than what some other licensees have, and it permits them to make architectural changes that people without that license cannot. And while I don't know the current business terms of this, I would speculate that by them being part of the orig…

Ah Ok. Agree with the amended version!

FWIW I think it’s unlikely that being a founder has any impact on current terms - we’re now thirty years on and several new licenses on now. Being a huge high profile customer will have an impact so Apple can probably get better terms than if you or me tried to buy an architecture license!

Re: Debian riscv64

#108

Post by pabs3 »

Tepix wrote: post #53
djha-skin wrote: post #11

Any promising riscv64 computers on the market I should know about? Raspberry pi level or otherwise? What computers could I use this distro on?

I'm wondering about this as well. In particular, are there any with RAM slots instead of soldered RAM?

https://milkv.io/pioneer

Re: Debian riscv64

#109

Post by pabs3 »

cmeacham98 wrote: post #15
viraptor wrote: post #13

Earlier quoted context omitted.

Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).

Debian distributes compiled binaries. Thus, they have to either turn processor features on in all their binaries, or off (or distribute two sets of binaries).

There are options for runtime instruction selection:

https://wiki.debian.org/InstructionSelection

Re: Debian riscv64

#110

Post by pabs3 »

sanxiyn wrote: post #68
totetsu wrote: post #51

Earlier quoted context omitted.

What kind of assumptions would badly-written applications make to make themselves impractical to cross-build?

All Debian packages are built natively. There is no cross build going on here.

During the initial port bootstrap process, the initial package set is cross-built using rebootstrap:

https://wiki.debian.org/PortsDocs/New#Bootstrap

Perhaps in the future Debian will be able to have cross-build-only architectures, that have hardware too slow to build software.

Post reply on HN