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

111–120 of 155 posts

Re: Debian riscv64

#111

Post by jchw »

giantrobot wrote: post #99
megous wrote: post #94

Earlier quoted context omitted.

Can you explain wifi chips like rtl8852 that have power levels and channels specified in the linux drivers and are fcc certified, then?

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.

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.

Re: Debian riscv64

#112

Post by pabs3 »

jffry wrote: post #19
sohrob wrote: post #16

When Debian is ported to a new architecture does that mean something special needs to happen to all of the packages in the repository for them to work on that new architecture?

Sounds like they need to cross-compile enough stuff to get a bootable system in the new architecture: https://wiki.debian.org/DebianBootstrap#Cross-building

Related link:

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

Re: Debian riscv64

#113

Post by drmpeg »

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.

Probably a better example than WiFi would be the on-chip SDRAM controller. It's always somebody else's IP and there's a blob in the boot firmware that's just binary register settings. Like so:

https://github.com/u-boot/u-boot/blob/master/arch/riscv/dts/...

Re: Debian riscv64

#114

Post by superdug »

alexeldeib wrote: post #85
xyproto wrote: post #81

Earlier quoted context omitted.

Usually when people feel like this, it is because the text has been generated by a LLM.

What makes you think it’s an LLM? It made fine sense to me, it’s just an odd style

Simply someone getting a break to philosophize about a crowning achievement in my eyes as the entire idea of free and open had yet to even be fully defined let alone on the precipice of realization four decades ago when I signed on to this free information roller coaster that changed the world.

Re: Debian riscv64

#115

Post by superdug »

TheSpiceIsLife wrote: post #65
ur-whale wrote: post #54

Earlier quoted context omitted.

No snarkiness intended, but I just read your post for the 3rd time and although I understand each sentence individually, I'm still not sure what point you're trying to make.

Surely that was generated by an LLM? Artificial indeed.

No, but I’ll take any moniker of intelligence at this point in my life, so thank you! If you’d like I can prove my Turing completeness if you’d like.

Re: Debian riscv64

#116

Post by [deleted] »

Uehreka wrote: post #27
AndyKelley wrote: post #7

Great work Debian! We already have riscv64-linux builds of Zig enabled with every CI run[1]. Happy to see that they might finally be utilized by more users soon. [1]: https://ziglang.org/download/

I may not work with Zig (yet) but it’s cool to see y’all representing yourselves like this, keep up the good work!

[deleted]

Re: Debian riscv64

#117

Post by capitol_ »

totetsu wrote: post #51
lmm wrote: post #21

Earlier quoted context omitted.

Well-written applications will just work. Badly-written applications may require patches or be impractical to build at all, and some system software may not make sense on the architecture at all. There's a whole lot of build infrastructure for Debian; by default the package maintainer doesn't need to do anything specific, building for all architectures will happen by default.

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

In my packaging work I encounter hard coded assumptions about pointer width, endianness and presence of atomic operations.

Re: Debian riscv64

#118

Post by megous »

giantrobot wrote: post #99
megous wrote: post #94

Earlier quoted context omitted.

Can you explain wifi chips like rtl8852 that have power levels and channels specified in the linux drivers and are fcc certified, then?

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.

Re: Debian riscv64

#119

Post by giantrobot »

jchw wrote: post #111
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.

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 to not get a license for sale of the device.

In something where the radio baseband is a physical circuit layout conformance is easy. Without modifying surface mount parts that circuit will always conform to its license.

For complicated basebands (WiFi etc) with software control having a fixed/closed firmware is the easiest way to get a license and not get it pulled after the fact.

The WRT54G is a fluke because it ended up using Linux/GPL code in the firmware. It was then obliged to release the source because of that. You can buy devices that allow firmware development and modification but not at retail and you can't offer them for sale without an FCC license covering them.

Re: Debian riscv64

#120

Post by hampereddustbin »

lmm wrote: post #21
sohrob wrote: post #16

When Debian is ported to a new architecture does that mean something special needs to happen to all of the packages in the repository for them to work on that new architecture?

Well-written applications will just work. Badly-written applications may require patches or be impractical to build at all, and some system software may not make sense on the architecture at all. There's a whole lot of build infrastructure for Debian; by default the package maintainer doesn't need to do anything specific, building for all architectures will happen by default.

I wouldn't go as far as telling something is badly written just because it's written to work on one platform. It can be an exceptional application even when it only works using a single platforms' intrinsics. Similarly a badly written application may work on many platforms
Post reply on HN