I'm grateful to everyone putting in the work to make RISC-V happen, open hardware is the only way out of the increasingly grim world of 'secure boots' and the like, which seems hell-bent on making general purpose computing on a trusted platform a thing of the past.

The problem is that the current crop of "secure boot" implementations focuses squarely on the average consumer that wants to delegate trust to the manufacturer, and, at best, only pays lip service to users who want to control their own hardware (see: Pixel devices and the like with closed bootloaders/TrustZone but an escape hatch for the OS) or nothing at worst.

Almost every "secure boot" CPU in modern smartphones and such is already user-control-friendly, it's just that they aren't being shipped that way. They get locked down at the factory. The CPU architecture has little to do with any of this.

If you want an example of what an unlocked secure boot device is, look at the Nvidia Tegra devkits. Those come without the public key fuses blown. You can burn in your own public key and then they will only ever run firmware you signed, forever.

ARM devices without secure boot, or with user-control-assertable secure boot exist. And RISC-V devices locked down at the factory will exist.

But foundries will burn whatever chip you have the money to pay for. Having a robust open standard ISA lowers the barriers enough that I'm confident we'll see free-as-in-freedom CPUs and GPUs come out of the project.

There is already pretty cool stuff. Look at this developer board, you get a RISC-V Dual Core 64bit + an ESP32 (a full MCU for wifi + Bluetooth) on the same board and a camera for $24. That Risc-V chip is optimized for processing neural networks.

https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-...

(warning site very slow)

Don't expect a smooth out-of-the-box experience (things like the pin numbers don't match in different versions) but the hardware works and the software works enough to be able to use it.

Cost aside, I think using the PC ecosystem has a lot of advantages over the pi ecosystem.

Particularly what makes this RISC-V board a PC, what an RPi does not have? Form factor, ATX power or PCI-Express?

I was just wondering how you define PC. Form factor or "standard connectors" (whatever that is - which RPi connector is not "standard"?) are none of my criteria.

Again, to me this are entirely arbitrary criteria. They are not "PC-Standards", they are some of many standardized connectors, form factors, etc. and in fact a matter of habit, not defining criteria.

Let me put it differently:

- So is a DTX-Board with an ARM-SoC a PC?

- Is an ATX-Board with a PowerPC but without PCIe a PC? What if we add PCIe?

- Is a SBC with an AMD APU powered by an USB power supply a PC? What if we add an M.2 port?

See where I am going? These are terrible criteria.

Define PC for me.

As someone who is relatively a lay-person (as in - I know computers but I'm not a hardware person) I understand the difference as "can I buy some standard components off of amazon/ebay and lego-build a computer with fairly powerful components like geforce/radeon type GPUs and m.2 storage" or is something that's basically a sealed box/board (aside from more advanced stuff I won't do, like soldering chips to a PCB) and/or doesn't have access to desktop class components (as far as I'm aware you can't reasonably stick a desktop GPU on an rpi).

Normally this would also imply an Intel isa, which dictated a multi-component chipset. (North bridge/South bridge) this in turn implies an multi-voltage power supply with a standard plug or plugs derived from the one in the PC AT.

The PC ecosystem also features a set of peripherals, such as floppy drives, hard drives, and CD-ROM drives. These peripherals have their own busses, starting with MFM, and now IDE and SATA. In some cases SCSI entered into the mix, but most consumer-oriented PCs did not use it. These drives were also were powered by the same power supply as the rest of the PC, with an evolving set of connectors and electrical standards.

The Mac took a parallel course, but featured it's own set of proprietary connectors and buses, as well as SCSI, for years before converging with the PC ecosystem in part in later years.

Many of these de-facto and cloned standards were adopted by standards organizations, such as EIA/TIA and IEEE. They were joined by PCI buses, which were used in a diverse set of architectures, including Sun. Later serial variants were developed for the PC and Mac ecosystems, driven by demand for faster graphics accelerators, with a side jaunt to AGP.

At the same time, emdedded devices evolved around a simpler usually single-chip chipset, and often single voltage board designs, with the exception of the cpu core voltage in some cases. These largely used memory-mapped IO with periphrial chips coupled to the memory bus, as well as slower buses such as I2C and SPI. These devices were usually power constrained, having quickly moved into the mobile realm with early PDAs such as the Newton. They mostly developed around the ARM chip which so low power in the early versions that it could run without voltage on it's primary bus.

As the PC ecosystem has evolved, it is now largely built around the PCI bus. PCI is cpu agnostic, so the CPU can be replaced with a different isa while keeping the rest of the system intact.

The PC is also historically modular, so substitutions such as those you suggested can generally be made while keeung the PC nature of the system. M.2 is a modern bus that has veen adopted into the ecosystem primarily for laptops, though also featured in some desktops.

Modern emedded devices are begininning to feature PCI interfaces, though these are only recently appearing in consumer electronics. They have been used in storage-centric chipsets for much longer.

The PC also implies a modular memory bus, with chips or modules complying with a logical and electrical standard, and identifying chip that can be probed by the chipset. In some cases the modularity is reduced and the chips are soldered to the mainboard.

PCs have also begun to adopt single-chip chipsets and System-on-Chip designs, starting with some emdedded intel designs used in mobile tablets and the UMPC. These brought the classic north bridge and south bridge as well as graphics (in this case PowerVR coming from the emdedded world). AMD64 chips also began to include the memory controller on die, leading up to the mentioned APUs that can be powered with the help of a standard embedded power IC from a single low voltage source.

Which also implies that the mentioned "criteria" are not good, since it is not a clear cut case. It is not binary, I cannot definitely say when something "starts or stops being PC" or where "non-PC" begins, there is a huge grey area nowadays.

It is as such a very meaningless classification.

And ACPI doesn't really have a standard root bus, it's a soup of descriptor tables and virtual machine blobs you have to run and trust, along with veritable mountains of patches for those vm bytecodes to fix firmware issues.

IMO Device Tree is the right way to go for nearly all platforms.

For normal PC hardware, you have a SATA controller, the device company commits a driver for it to the Linux kernel tree, and thereafter every subsequent version of Linux can use the SATA controller in any device with that kind of SATA controller. If the device company doesn't provide a driver but the hardware is popular, somebody else reverse engineers the chip and eventually the same result obtains. Likewise for the network controller, the GPU and so on.

Typical ARM devices like cellphones are beleaguered by some kind of shameful omnishambles whereby that doesn't work. The device maker provides a hideous binary blob with the device, it only works with that specific kernel version and everything is terrible. The exact source of the tragedy is the part I'm not quite clear on.

But making whatever that is not apply to RISC-V boards would be highly satisfactory.

The difficulty with 'dev boards' like the RPi is that for economic reasons they're made with SoCs from the high-volume markets of the embedded world but sold to people who want to use them like the standardized hw of the server world. This mismatch tends to be annoying and inconvenient.

Anyway, my take is that for RISC-V the dynamics will be exactly the same -- in the embedded world there will be a profusion of different hardware and a lot of binary blobs and non-upstreamed drivers; in the server world things will be nicer; and dev boards will be more like the embedded world than you would like.

(Also, x86 is really unusual in having such a uniform every-machine-looks-the-same ecosystem; this has happened by historical accident as much as anything else. Of course most people only have experience with x86, but it might help to try to not think of absolute-x86-monoculture as 'normal' and wider-variety as 'weird', when it's the other way around :-))

Additionally, PCs do in fact of tons of glue and support systems that match how ARM style SoCs work. They paper over it with ACPI which is based around a VM that has to be run in the kernel that's basically a giant binary blob, in contrast to device tree's description of the components and how they're connected.

If what you're saying is that on ARM there are 15,000 different kinds of USB controller that all need their own driver, that's one thing. But if all you're saying is that there are 25 different USB controllers and 25 different drive controllers and 25 different network controllers and that means you get 15,000 different possible combinations, the fact that every combination needs its own separate drivers is the bug. Even if various controllers are combined into one SoC.

> They paper over it with ACPI which is based around a VM that has to be run in the kernel that's basically a giant binary blob, in contrast to device tree's description of the components and how they're connected.

It seems to be doing a useful thing in abstracting away the various binary blobs into a stable interface that allows them to continue operating with newer kernel versions.

Getting rid of the binary blobs entirely is a separate fight, presumably related to getting open source firmware (rather than drivers).

On many non-PC platforms, you’re given a thousand “pins” to which you’re free to connect whatever circuit that you conceived for your product, be it green and red buttons, or backlight control circuits, or temperature sensing inputs, or SATA controllers, or 4 bit 74 series counter repurposed to switch pin 567 between SATA controller configuration interface output and battery temperature gauge input and laser ranging sensor power modulation output and self destruction device detonation cord output.

There’s no way or even motivation to describe those board specific miscellanies in such way that Linux Kernel drivers can dynamically consume and adapt to, or decide how to behave.

This is not an issue for x86 PC platform, because every x86/x64 PC is either a 100% clone of IBM 5170 “PC/AT” to run IBM DOS 5.0 or Microsoft MS-DOS 5.0 binary without ever catching fire, or a Microsoft Windows Logo Program certified product that boots into Windows of the same era from binary installer disc/USB key.

It doesn't seem like an intractable problem to standardize and document this sort of thing. Once you know that pin 45 is connected to a model ABC123 backlight controller, you know to communicate with it on pin 45 using the ABC123 backlight controller driver. If the same pin is used for multiple outputs, no problem, standardize the method for switching between outputs and describe which pins are switched to which devices using which control pins in a machine-readable table.

Apparently they haven't done this, so how do we get them to start?

It's not a combinatorial problem, but just pure number of different devices.

I have many pis that I love, but you have to admit, there are a few compromises made for a lower bom cost. That is not a requirement for a $600+ board.

You can put a Pi in a case. In fact, it's hard to find one on Amazon without a case.

Of course you can develop on it. That's the whole point.

Pi 4 has pci-express, no?

I struggled with the pi SD card - extremely slow and always the possibility of corruption.

I struggled with pi graphics - none of my projects every had accelerated graphics, not even blits.

I struggled with pi USB - at first it was power and speed, now it might be in better shape but not all the way there. The pi is still limited to ~ 15w.

When you get to the pc ecosystem, and it's really just a bit more expensive, you get a step up in capabilities. You get all the voltages. You can get a 300w or a 1500w power supply.

You can add a graphics card.

You can put it in a case that has room for more than just the board. Say, I/O?

I wish the pi had a nice metal case that had a 2x the width allowing for an enclosed breadboard or the like. Or a case with all the connectors on one side.

> Pi 4 has pci-express, no?

really? where is the slot? (I said not compute) ;)

btw, I'm not anti-pi, the opposite in fact.

Maybe I could say it in another way -- what if you could have an itx form-factor pi? I think that would be very exciting.

Not the pi, but the vaguely-similar (better, IMHO) https://www.pine64.org/rockpro64/ has a 4x pcie. Works great for a sata/raid controller, but still has plenty of "embedded" limitations - you can't just plug a graphics card into it.

[0] ayufan https://docs.google.com/spreadsheets/d/1pCqJg0VSzvihUOoxCOq3...

[1] https://www.reddit.com/r/arm/comments/9v8qpm/do_amd_or_nvidi...

https://device.harmonyos.com/en/docs/start/introduce/oem_wif...

That was the case for the very first version, but didn't the subsequent models use SoCs made specifically for them?

https://www.reddit.com/r/raspberry_pi/comments/egwo6z/was_th...

Development boards are typically more expensive, since they are produced in lower numbers, and have features a consumer is not interested in (debugging, etc.).

Unless the manufacturer pushes development boards hard to e.g. pull developers in to the new eco-system quickly, then they might get sold at a bargain. But those are then usually not usable in place of the "real thing" (would cut into sales).

Although I would expect better debugging interfaces, less hacky hardware setup, a reasonable boot-loader, etc. Some things improved over the generations, true.

That's not what I've experienced: Arduino's are cheaper, Teensys are cheaper, Adafruit boards are cheaper, many others too.

And that's just regular retail prices at e.g. Mouser, or even the official websites — without even getting into the super-cheap Chinese stuff on AliExpress/etc.

— Why the downvotes? IDK, maybe you meant more powerful boards than those?

Whereas from a classic development board it's typically expected that it provides access to as many capabilities of the chip as possible, and more complex chips have a staggering amount of those. E.g. taking the chip on the teensy, since it's the one that's the most high-end one from your examples: It has Ethernet support - add an Ethernet port. It has CAN support - add external CAN circuitry. It has USB - add USB ports. It supports low-level debugging through JTAG and SWD - add that, either a basic debugger or at least a space to connect an external one. It has a display interface - add a dedicated header for that, or maybe even just add a display. I think it supports eMMC flash - add space for that. That makes these boards a lot bigger and expensive, but it means a developer can start with whatever combination of things they want to try, and if the alternative is them spending a day on figuring out and hooking up all the external bits they need on a simpler board the higher price doesn't matter anymore. (Especially coming from the days were there wasn't as big an ecosystem of breakout boards for lots of things available).

The end result then looks more like something like this: https://www.embeddedartists.com/products/imx-rt1062-develope..., and appropriately costs a bunch more than the teensy Teensy.

This is like me handing you a RISC-V iPhone (same price) and 30% of the apps work. Would you ever, ever, ever switch? No.

Sorry, Arm architecture skyrocketed to popularity because of an ultra long term strategy and a few rocket ship design wins like Android and the iPhone. I am afraid the door is shut.

Tizen might have been a good idea, but without a rocket ship to subsidize the improvements of the OS, it died. RISC-V boards are not different.

I am looking for a rocket ship, which is a new high volume use case which is not properly covered by the current set of solutions. Self driving cars? AI cameras? Robots? Nothing looks like it needs RISC-V in particular, none of it seems likely to produce iPhone scale novel designs that will eat the rest of the market out from Under arm.

ARM popularity is going to significantly reduce the porting challenge. The gap between supporting 1 and 2 platforms is an order of magnitude harder to cross than 2 and 3.

The door is never fully shut. Arm itself is proof of that.

[1] https://fedoraproject.org/wiki/Architectures/RISC-V/Installi...

That's the same as the Unleashed but clocked slower. Like the new HiFive Unmatched it also has PICe.

https://www.hackster.io/news/microchip-s-risc-v-powered-pola...

[0]: https://linux-sunxi.org/Linux_mainlining_effort

There are probably lots more, but lots are not documented.

Even exact same chip isn't used for other than RPI, its design should be shared to other SoCs, so it can be cheap.

https://www.reddit.com/r/raspberry_pi/comments/egwo6z/was_th...

> > Hi all – I'm curious about the origin of the chip used in the Pi 4, the Broadcom BCM2711. Was it designed specifically for the Pi? I can't find any reference to it on the Broadcom website, which is strange, nor any record of its use in any other device, e.g. a smartphone.

> Sort of. The BCM2835 (Pi 1) was originally designed as a set top box SoC and was used in devices like the 1st gen Roku boxes. The BCM2836 (Pi 2), BCM2837 (Pi 3) and BCM2837B0 (Pi 3+) were designed for and only used by Pi boards. The BCM2711 was designed for and only used by the Pi 4 but it is closely related to a new BCM7211 which is for set top box usage.

[0] https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications

[1] https://en.wikipedia.org/wiki/ARM11#Overview

[2] https://en.wikipedia.org/wiki/ARM11

[3] https://en.m.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores

This is cooler than Raspberry Pi because it has PCIe x8 (which I couldn't find on the picture but the specs say its there) and M.2 slots.

If you've got a complaint, say it like a grownup, IMO.

I've built things around all kinds of ARM SoCS big and small... And AVR... and 8051 and 6502... I find things about Pi and Raspbian annoying, and sure wish there was more I/O and better graphics support...

But, how awesome is it that there's a ~$50 lego brick out there, with a ton of computation and long term support that a huge ecosystem of projects have sprouted from? And even better, we have all the boards around with less traction (Beagle*, oDroid, etc) to pick from. I don't see the draw in being elitist.

There's all kinds of projects I'd have had to spin a challenging-to-lay-out and expensive-to-manufacture board for before.. and now I can make a little silly Pi hat and get prototypes done in hours. This is exciting!