Live data from Hacker News

PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

cnx-software.com

81–90 of 159 posts

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#81
post #27
post #11

I honestly didn't realise the Raspberry Pi isn't open source. Why isn't it? The Foundation's charitable objective is education, so sure, it's not necessary , but there really seems to be no reason for it to be closed - I suppose it's just 'closed by default'?

Not only is the SoC and board RPi uses open hardware, it has hardware DRM in place to prevent people using custom camera modules: https://mobile.twitter.com/marcan42/status/10884725497159188...

Wow. Links to twitter so often serve as a reminder that twitter is horrible and people are weird and noxious.

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#82
post #73

Earlier quoted context omitted.

FWIW, every chip I've seen with a PowerVR GPU uses a video scan out engine that's pretty much completely disconnected from the GPU. That's one of the neat things about how programmable their cores are; you can resolve in the tile to just about any surface format since it's all done in software anyway, so it's really easy to integrate with other scan IP blocks. TL;DR: You'll probably get a simple un-accelerated frameb…

>with a PowerVR off to the side that you can just ignore if you want. The problem is that I can't, and most people who care about freedom and thus could be interested in a slower, more expensive board... can't either.

Of course you can, just ignore it, and pretend it isn't there. Don't even load its drivers. Because of dark silicon, you won't be able to fully light up the chip anyway. Use the GPU being off to clock other parts faster if you want. You still get an unaccelerated framebuffer if it has the same arch as every other chip I've seen with a PowerVR for the past twenty years (Dreamcast, BeagleBoard, iPhones, PSP Vita, the MIPS board they came out with that I'm forgetting the name of).

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#83
post #77

Earlier quoted context omitted.

Do we know the foundry? I like your idea because I could see the Chinese government doing this to help prop up SMIC too. The RPi4 isn't any smaller than 16nm, and SMIC needs 14nm customers. Shoot for the 500MHz target listed, which is achievable with Victorian era style over engineering. Next sell those more or less at cost after the government footed the bill for initial capital (probably paying back .gov.cn first).…

Image in the article says TSMC 28nm. https://www.cnx-software.com/wp-content/uploads/2020/09/Pico...

Lol, oh well, it was a good idea.

Thanks for the citation!

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#84

Earlier quoted context omitted.

One concrete advantage RISCV has is its variable-length SIMD instruction set. The assembly instructions used for SIMD in RISCV can all operate on data sizes that are various powers of 2. All using the same instructions. You could even call it “SIMD with dynamically-sized data”. Right now, x86 needs one set of instructions for each SIMD data size. That’s why we have SSE, AVX, AVX512, etc. This introduces complexity fo…

Right now, x86 needs one set of instructions for each SIMD data size. If you look at the encodings, many of them are actually the same opcodes as the original MMX, but with prefixes. In the proposed RISCV design, you wouldn’t have to. It would just work on all sizes. That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ? Unless they added some…

> That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ?

You ask the hardware. The current vector width is a register that can be set and queried.

https://gms.tf/riscv-vector.html

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#85
post #61
post #51

Earlier quoted context omitted.

Broadcom SoC is probably protected by a bunch of patents and/or trade secrets, which makes it impractical to open source. For example the whole boot process is a black box, which is why you have to use Raspbian and not regular Debian.

That's not really true anymore. Device Tree and other things help with this, although you do still require certain BLOB's to access the GPU and other features.

As far as I know the efforts in this direction only worked for Raspberry Pi 1, not the subsequent ones - or are there some news for later devices too?

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#86
post #17

Why is RISC-V even so hyped up/successful? Other open ISAs precede it, and AFAIK the code density that RISC-V allows is disappointing considering the designers had an opportunity to start from scratch.

>Other open ISAs precede it

Do you have any in mind? From what I can tell even POWER is not as open as RISC-V. They only show schematics to their partners, not the public at large.

https://en.wikipedia.org/wiki/OpenPOWER_Foundation#Openness

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#87
post #46

Earlier quoted context omitted.

Oof indeed. I'd rather unaccelerated graphics. Hell, take any display solution from opencores. But don't give me proprietary garbage and especially not PowerVR. I'm OK with no graphics as an alternative. Hell, I could always use some USB display solution.

> I'm OK with no graphics as an alternative Then you'll be fine with the first version of this, since it's exactly that.

Yeah, I noticed. And hopefully by the time the 2nd version comes, they'll have understood who they're selling these to... or there'll be alternatives.

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#88
What's the latest on a cheap, small board where you can run linux, with BLE & WiFi 2.4/5GHz?

Rpi Zero W and the corresponding Banana Pi M2 Zero meet all criteria except the 5GHz. Beside these, I have a really hard time finding any cheap alternative.

There's plenty of embedded devices for iot, from arduino to all others. But 100% of the iot I have in my apartment are actually powered and don't need a batter/extremely low consumption. I much rather enjoy the flexibility of running linux (or android) vs flashing a firmware.

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#89

One of the key selling points for me is the RasPi OS and software ecosystem. Raspbian a great distro, very well aligned with the hardware. Getting a generic distro to boot on a system isn't the same as ensuring a smooth experience with things like system config, video playback, networking and peripherals.

In some ways I see this as a downside. Despite how many years the RPi has been a thing, the drivers for it still aren't fully upstreamed to the Linux kernel, and the device tree in mainline is very different from that in the RPi Foundation's kernel fork.

The RPi-specific userspace bits are just (in the past year or so) starting to become more standard (like moving the stuff in /opt/vc to standard system locations, having a normal kernel headers package).

I don't want a specially-built OS just for one piece of hardware. I want to run stock Debian, with a stock kernel. And yes, I can do that, but as you hit at, the experience is sometimes lacking (for a while I couldn't get sound to work with stock Debian).

I've been looking at some of the RPi workalike boards that run Armbian... I haven't dug into it yet to evaluate the quality of Armbian, but I at least like the overall approach of having one OS that can support different chipsets and boards.

Re: PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board

#90
post #85
post #61

Earlier quoted context omitted.

That's not really true anymore. Device Tree and other things help with this, although you do still require certain BLOB's to access the GPU and other features.

As far as I know the efforts in this direction only worked for Raspberry Pi 1, not the subsequent ones - or are there some news for later devices too?

I’ve played with this recently in setting up a shared netboot server with Debian for my pile of ARM SBCs (I really should write up that blog post...). The upstream kernel’s device trees are different from the ones supplied by the Raspberry Pi Foundation, with some slightly different names for devices, and basically no easy way to use overlays. Other than that minor obstacle, it’s perfectly doable to build up your own image with debootstrap and chroot with 100% Debian repositories (or go the easy way and download one of the prebuilt images [0]). You do still need the closed-source blobs (bootcode.bin, start.elf, fixup.dat) for boot though, which are made available in the non-free repo.

The 4’s hardware support is still being merged upstream last I heard though, so the easy way for that is still to use the Foundation’s kernel (which is what Ubuntu does, probably to also make overlays work as expected).

0: https://raspi.debian.net/

Post reply on HN