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

121–130 of 155 posts

Re: Debian riscv64

#121

Post by ComputerGuru »

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.

Apple is the only company with a special licensing deal with ARM that lets them do whatever they want and develop their own ARM cores without relying on ARM IP or premade designs like everyone else. They've also sorted it out financially where they're probably not incurring incremental costs, though I think the details are secret.

Re: Debian riscv64

#122

Post by Pet_Ant »

giantrobot wrote: post #119
jchw wrote: post #111

Earlier quoted context omitted.

Wait, though. Doesn't that seem to make this point moot? If they're not responsible for what users do hacking around, then there's not really any need to keep firmware closed source or locked down. To be fair, I think at least at one point, that is in fact how it worked. I recall having a wrt54g and being able to run it out-of-spec using DD-WRT.

> Doesn't that seem to make this point moot? If they're not responsible for what users do hacking around, then there's not really any need to keep firmware closed source or locked down. To sell the device the manufacturer has to make sure the device follows regulations and normal usage will follow end user regulations. The easier they make it for regulation-violating user modifications the more likely the product is…

Okay, but you could release the source code for the firmware, and only accept a signed binary blob. This would still be open source (GPL v2 compliant, but not v3 AFAIK) and auditable, but it still be conforming and certifiable.

Re: Debian riscv64

#123

Post by AnthonyMouse »

giantrobot wrote: post #106
leonheld wrote: post #92

Earlier quoted context omitted.

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

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

That explains why there are power/frequency limits, not why the device manufacturer should be deputized into responsibility for a sophisticated user's non-compliant device modifications.

Anyone can make an arc gap transmitter for morse code out of $3 in bits from any hardware store that will interfere with anybody else's radio devices in the vicinity. Anyone can buy ham radio equipment or built it from parts and do all kinds of non-compliant things with it. Then the FCC comes after you, not the hardware store or the device OEM.

Or more likely in the case of a WiFi device, comes after the person distributing custom firmware that purposely exposes a simple knob to allow unsophisticated users to exceed regulatory limits.

And if DD-WRT did that, they should expect a visit from The Government. But what should that have anything to do with Linksys or Netgear?

There aren't enough end users who know how to modify the firmware code themselves to matter, even if you make that "easy."

Re: Debian riscv64

#124

Post by snvzz »

ComputerGuru wrote: post #121
Tepix wrote: post #58

Earlier quoted context omitted.

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

Apple is the only company with a special licensing deal with ARM that lets them do whatever they want and develop their own ARM cores without relying on ARM IP or premade designs like everyone else. They've also sorted it out financially where they're probably not incurring incremental costs, though I think the details are secret.

I have seen this statement several times before, but nobody's ever been able to source it.

Re: Debian riscv64

#125

Post by snvzz »

camel-cdr wrote: post #57
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?

https://milkv.io/pioneer seems to be the most powerful rn, but I'd only recommend it for developers who are working on getting things like gpu drivers ported. For most development smaller SBCs are enough, and I'd recommend waiting for RVA22/23 profile supporting hardware before spending a lot of money, because most current chips use the non standard vector isa and don't support all profile extensions, because they wh…

Current chips largely implement what we retroactively call RVA20: RV64GC. This was ratified in 2019 and unmodified since 2017.

The next batch we are aware of (Ventana Veyron, Tenstorrent Ascalon, SiFive P470/P670/U84, XuanTie C908) implement RVA22+V. The extensions included were largely ratified in December 2021.

Re: Debian riscv64

#126

Post by panick21_ »

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.

Apple had to pay a lot for that license and even if you are willing to pay its not that easy to get. And if you do pay, you are not actually allowed resell the licenses for that chip.

RISC-V gives all people a level of power that is even higher then what Apple had with ARM.

As somebody from Esperanto said when making their Esperanto said it. If we had asked ARM it would have been 'pay of a couple million and then you can't do X,Y and Z'.

Re: Debian riscv64

#127

Post by snvzz »

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…

Not since RISC-V Profiles[0].

0. https://github.com/riscv/riscv-profiles/releases

Re: Debian riscv64

#128

Post by snvzz »

panick21_ wrote: post #71
pjmlp wrote: post #39

Earlier quoted context omitted.

A path already trailed by OpenSPARC and PowerPC.

No it isn't. PowerPC was never free. I think you mean OpenPOWER. Again that was just marketing, it wasn't free in anyway. Only the pressure of RISC-V lead to POWER and MIPS becoming more free over time. And even if OpenSPARC had a open spec, but was only for 32bit. The 64 bit version would never become a standard. You need more then air dropping a spec. You need people to continue to push it forward and evolve it. Yo…

>OpenSPARC had some success, being used for space by ESA for example.

ESA's OpenSPARC-based LEON. But note ESA has already decided to replace it with the RISC-V based NOEL.

Re: Debian riscv64

#129

Post by giantrobot »

megous wrote: post #118
giantrobot wrote: post #99

Earlier quoted context omitted.

It only has power level control up to the limits for ISM devices on its operating frequencies. Its license is only valid for antennas with specific gain. You technically can overwrite its firmware to turn the radio into some general purpose software defined radio transmitter but that's not how the device is licensed and sold.

You can use channels not allowed in your country. The firmware doesn't prevent that.

A device SKU only meant to be sold in ITU region 2 or North America specifically will often have the available bands/channels locked in the firmware despite the capability of the underlying hardware. Same for a SKU meant for other ITU regions or countries. It's far less common to have user selectable region settings for things like WiFi channels. It used to be more common but regional SKUs are just easier for everyone involved.

Even if a device enables you to specify channels not allowed in your country/region doesn't mean you're legally in the clear. "But there's a switch" isn't a defense against an FCC fine. It's unlikely you'll get caught and fined for using channels 12-14 on a Wifi device in the US but if you interfere with something important you're breaking several laws and if caught can potentially face jail time.

Re: Debian riscv64

#130

Post by megous »

giantrobot wrote: post #129
megous wrote: post #118

Earlier quoted context omitted.

You can use channels not allowed in your country. The firmware doesn't prevent that.

A device SKU only meant to be sold in ITU region 2 or North America specifically will often have the available bands/channels locked in the firmware despite the capability of the underlying hardware. Same for a SKU meant for other ITU regions or countries. It's far less common to have user selectable region settings for things like WiFi channels. It used to be more common but regional SKUs are just easier for everyon…

Allright, so firmware lock is not a requirement then?
Post reply on HN