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

131–140 of 155 posts

Re: Debian riscv64

#131

Post by giantrobot »

AnthonyMouse wrote: post #123
giantrobot wrote: post #106

Earlier quoted context omitted.

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…

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

This is just a silly statement. Go to an apartment complex sometime and browse the available WiFi networks. You'll see a huge number of them because everyone has the output power on their router set to the max value. There's plenty of places the 2.4GHz band is simply unusable because the noise floor is so high from a hundred base stations blasting out at full power.

If WifiBoost.exe could in tease that output power enough people would do it that WiFi or Bluetooth in some places would be completely unusable.

Modern radio basebands are largely software defined. The modulation/keying, power output, and transmitted bands are all defined in software. In order to sell that silicon as a Part 15 compliant device to end users the firmware needs to be locked. It's the digital equivalent of a fixed function radio. A manufacturer of a fixed function radio couldn't get a Part 15 license if it had a potentiometer on the back allowing you to dial up the output power, even if that potentiometer was locked under the case most people wouldn't open.

With an SDR the hardware plus software is considered the "device" for licensing purposes. If it supported unlocked or modifiable firmware it couldn't be easily/at all sold as a Part 15 device. It would be a different class of device and would require the end user to have a license to operate it.

Re: Debian riscv64

#132

Post by camel-cdr »

snvzz wrote: post #125
camel-cdr wrote: post #57

Earlier quoted context omitted.

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.

Do you know if Ventana Veyron and Tenstorrent Ascalon will be available to regular consumers? I mentally lumped them in with andes from which I haven't seen any vector cores available anywhere, even though they "released" them a long time ago.

Re: Debian riscv64

#133

Post by ilyt »

giantrobot wrote: post #86
ilyt wrote: post #62

Earlier quoted context omitted.

Only benefit is companies not having to pay ARM. The architecture NEVER WAS A PROBLEM for open, it was always the binary blobs required to run IP blocks put on the die with the cores that stopped people from using them. ISA is the easy part. Even if you need to RE it, you only need to do it once. Now hopefully with RISC V companies will be even more inclined to just upstream their drivers from the start (and not do t…

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

Completely moot point. They are not selling a device. They are selling chip. It's on the device manufacturer to prevent it and it doesn't need to be in baseband chip.

Re: Debian riscv64

#134

Post by snvzz »

camel-cdr wrote: post #132
snvzz wrote: post #125

Earlier quoted context omitted.

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.

Do you know if Ventana Veyron and Tenstorrent Ascalon will be available to regular consumers? I mentally lumped them in with andes from which I haven't seen any vector cores available anywhere, even though they "released" them a long time ago.

Ventana announced last year they'd have server boards late current year.

Tenstorrent Ascalon's TBA 2024, but it is a chiplet. We do not know in which form it'll be available in. I am hopeful there'll be development boards.

Re: Debian riscv64

#135

Post by snvzz »

FullyFunctional wrote: post #43
snvzz wrote: post #12

Earlier quoted context omitted.

I would look at JH7110, released earlier this year, used in VisionFive 2, Star64, as well as PineTab-V, and with an excellent official effort towards upstreaming software support[0]. I own a VisionFive 2 and can recommend it. There's also the TH1520, a newer chip that's a bit faster and has pre-spec V extension. This is available in the Sipeed Lichee Pi4A, but the support for this chip is very green still. CPU-wise,…

TH1520 is definitely not faster than a RPi4, not for normal programs compiled with normal compilers or binaries that will come from your distribution. And no, Bruce, vendor benchmarkering doesn't count. ADD: TH1520 is about twice as fast as JH7110, but as best I can tell, StarFive (JH7110) is more proactive about upstreaming support.

A quick search in Linux git head for "th1520" returned some results. It must mean there is ongoing work.

I hope they set up a webpage to track what's going on with upstreaming efforts, similar to JH7110 has.

Notably, boards with TH1520 are just starting to ship, whereas boards with JH7110 were shipping in volume in February.

Re: Debian riscv64

#136

Post by giantrobot »

Pet_Ant wrote: post #122
giantrobot wrote: post #119

Earlier quoted context omitted.

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

And some manufacturers do just that. Many do not because they're sub-licensing components/code from other companies. Others don't because they want to license their hardware to others and firmware source is a special sauce when the functions of the radio are all in software.

Re: Debian riscv64

#137

Post by giantrobot »

ilyt wrote: post #133
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.

Completely moot point. They are not selling a device. They are selling chip. It's on the device manufacturer to prevent it and it doesn't need to be in baseband chip.

For Part 15 devices the licensed portion of the device is the software and hardware that does the RF emission. Firmware defining operation is seen by the FCC (and other regulatory bodies in other countries) as the same thing as a circuit design of a fixed radio transmitter. To the point of firmware updates can require recertification just like a change in the BOM or circuit design would.

A RISC-V radio baseband will end up no more open than a Cortex-M one. The CPU core portion might be documented/open but not the full firmware. It'll still be effectively a black box no matter how open the specs on the processor.

Re: Debian riscv64

#138

Post by AnthonyMouse »

giantrobot wrote: post #131
AnthonyMouse wrote: post #123

Earlier quoted context omitted.

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

> There aren't enough end users who know how to modify the firmware code themselves to matter, even if you make that "easy." This is just a silly statement. Go to an apartment complex sometime and browse the available WiFi networks. You'll see a huge number of them because everyone has the output power on their router set to the max value. There's plenty of places the 2.4GHz band is simply unusable because the noise…

> You'll see a huge number of them because everyone has the output power on their router set to the max value.

None of these people are firmware developers. They used the setting that existed from the factory in their router or in something they downloaded from the internet, and in the vast majority of cases it wasn't even the second one.

> If WifiBoost.exe could in tease that output power enough people would do it that WiFi or Bluetooth in some places would be completely unusable.

Then WifiBoost.exe would be illegal and the developers would be subject to penalties.

It would also be ineffective, because you can't remove interference by increasing power. The "highest allowable power" setting is often the default because it gives the best range, and the purpose of allowing it to be set at all is so that the user can reduce interference at the expense of range by lowering the power level so fewer devices are overlapping.

It's hard to get people to avoid doing illegal things when breaking the law benefits them. It's not that hard when breaking the law is pointless and maladaptive regardless of whether or not they get caught.

It's notable that there have existed routers with completely open firmware and there is no epidemic of ordinary users installing shady firmware on them to violate regulatory limits. There is likewise full software defined radio hardware on the market, for which a license is required to transmit but not to buy it. Applying a different standard to consumer hardware which is available to exactly the same set of people makes no sense.

> With an SDR the hardware plus software is considered the "device" for licensing purposes. If it supported unlocked or modifiable firmware it couldn't be easily/at all sold as a Part 15 device. It would be a different class of device and would require the end user to have a license to operate it.

I'm not arguing about what the law currently is but rather about what it ought to be.

But I also think your analogy is flawed. If the manufacturer sells a device with a potentiometer whose maximum setting was within the regulatory range, or with a fixed power output, and then the user modifies the device to install one that can increase the power output, that should be on the user. So why is it different if the user modifies the device to install firmware that increases the power output?

You're essentially arguing not that the device can't include a potentiometer, but that the case has to be sealed so the user can't install one.

Which in turn prevents the user or any other third party from repairing the device or supporting it past when the vendor stops caring about it, inducing widespread security vulnerabilities as users commonly continue to use operational devices even after the hardware vendor stops issuing updates.

Re: Debian riscv64

#139

Post by pabs3 »

Pet_Ant wrote: post #122
giantrobot wrote: post #119

Earlier quoted context omitted.

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

This is what the Intel Sound "open" Firmware does, and it is incredibly annoying.

https://github.com/thesofproject/sof/issues/5814

I don't think that would be GPLv2 compliant either:

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t...

Re: Debian riscv64

#140

Post by giantrobot »

AnthonyMouse wrote: post #138
giantrobot wrote: post #131

Earlier quoted context omitted.

> There aren't enough end users who know how to modify the firmware code themselves to matter, even if you make that "easy." This is just a silly statement. Go to an apartment complex sometime and browse the available WiFi networks. You'll see a huge number of them because everyone has the output power on their router set to the max value. There's plenty of places the 2.4GHz band is simply unusable because the noise…

> You'll see a huge number of them because everyone has the output power on their router set to the max value. None of these people are firmware developers. They used the setting that existed from the factory in their router or in something they downloaded from the internet, and in the vast majority of cases it wasn't even the second one. > If WifiBoost.exe could in tease that output power enough people would do it t…

> You're essentially arguing not that the device can't include a potentiometer, but that the case has to be sealed so the user can't install one.

No I'm literally saying a company can't literally include a potentiometer that boosts power above the licensed levels. It doesn't matter if the case is sealed or screwed shut. The design will not get a Part 15 license and can't be sold. User modifiable firmware is the same thing as the power boosting potentiometer. If the user can boost the power the device is no longer a Part 15 device and needs a different license for sale and the user will require a license of their own to operate it.

It doesn't matter what you think the law should be that's what the law is. The FCC as a regulatory body doesn't care about FOSS, they care about keeping an easy to over exploit shared resource continue to have significant and extremely profitable use. If licensing keeps the system working but makes FOSS inconvenient they're going to err on the side of a working system. The FCC is far from perfect and title 47 regulations are far from perfect. But they don't exist for no reason and didn't just appear overnight to inconvenience FOSS enthusiasts.

Post reply on HN