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

91–100 of 155 posts

Re: Debian riscv64

#91

Post by smallpipe »

bregma wrote: post #75
totetsu wrote: post #51

Earlier quoted context omitted.

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

Othar than word size (eg. i386 vs. x86_64), endianness (eg. PPC vs. x86), alignment (eg. ARM vs. x86) there's plenty of other low-level issues like parameter passing conventions, call frame handling, exception handling, presence or absence of optional instructions or registers, and a number of other subtle gotchas that could affect a port. Instruction probing is one of the ones we run into where everything builds fin…

You're missing the biggest one, concurrency model.

Re: Debian riscv64

#92

Post by leonheld »

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.

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!

Re: Debian riscv64

#93

Post by Pet_Ant »

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!

I think it is because the firmware guarantees that the radio behaves according to specifications. Much like the governor on a car.

Re: Debian riscv64

#94

Post by megous »

Pet_Ant wrote: post #93
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!

I think it is because the firmware guarantees that the radio behaves according to specifications. Much like the governor on a car.

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

Re: Debian riscv64

#96

Post by 15155 »

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.

Where does the FCC specify the delivery format of firmware? Or what "firmware" is as a concept in general?

Non-modifiable - by whom and to what degree? One-time-programmable memory? Accepting only signed updates from the vendor? Where are these things specified in enumerated FCC regulations?

Re: Debian riscv64

#97

Post by 15155 »

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 don't think so, in practice since atomics (on single-core systems especially) and floats can easily be emulated. If larger, more-incompatible extensions become commonplace, possibly.

Re: Debian riscv64

#98

Post by 15155 »

pjmlp wrote: post #34
tw1984 wrote: post #32

a true milestone! hope it is also the beginning of the end - ISA shouldn't be some tightly controlled assets managed by some lawyers and CXOs, companies shouldn't be sued for just trying to invest into certain ecosystems.

RISC V is not extension free, and a CPU is meaningless without a, most likely, proprietary board.

The R&D (and probably all) expenses and difficulty involved in SOC board manufacture and design are orders of magnitude lower than the R&D expenses, difficulty, and gatekeeping required to design and manufacture that very same CPU.

Re: Debian riscv64

#99

Post by giantrobot »

megous wrote: post #94
Pet_Ant wrote: post #93

Earlier quoted context omitted.

I think it is because the firmware guarantees that the radio behaves according to specifications. Much like the governor on a car.

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.

Re: Debian riscv64

#100

Post by cmrdporcupine »

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 graphics and vector. e.g. bringing compute back in from the GPU, by chip producers bundling extensions into their custom RISC-V implementations and then providing the requisite add-ons for llvm, SDKs, etc.

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^H^H^HIntel (or Motorola/IBM before that). I am hopeful we'll see similar excellence around RISC-V. (EDIT: I had typo'd "ARM" here but meant to write Intel)

Though this will all come at the cost of some amount of fragmentation, at least the base instruction set is standardized, and a standard method for extension put in place.

Post reply on HN