The target market for the Raspberry Pi foundation is education. They get cheap boards into the hands of people everywhere and provide plenty of documentation to get them started.

Raspberry Pi has the biggest community, and therefore it’s the best choice for anyone looking to get started.

If you’re the type of person who needs very specific features like AES acceleration, then you don’t want to invest in a board aimed at education markets anyway.

The Raspberry Pi 4 is actually very performant due to the Cortex-A72 cores, which are not common on other SBCs at low price points. It’s actually an incredible performance value in the space, even if it doesn’t fit everyone’s exact situational requirements.

> The target market for the Raspberry Pi foundation is education.

I'd bet 80% of the sales are to hobbyists/companies.

It's a weird setup. Have a look at this page: https://www.raspberrypi.org/about/meet-the-team/

There are two groups of people:

* Raspberry Pi Foundation (100+)

* Raspberry Pi Trading (27)

My understanding: The people in "Raspberry Pi Trading" do the hardware/software/documentation/product management/sales work, plus publish the monthly MagPi magazine. That's remarkably few people for this, btw. The profit of this operation goes to support the foundation, per the wikipedia page. There sure seems to be a lot of fluff there.

I think it would be wise to change that balance (100+ vs 27 full times) a little bit more in advantage of Raspberry Pi Trading part.

> I'd bet 80% of the sales are to hobbyists/companies.

Hobbyists are part of the educational target. Raspberry Pi has introduced more people to embedded Linux than any other project.

We didn’t always live in an era of cheap SBCs. Before Raspberry Pi, the barriers to entry were much higher and much more expensive.

As much as people like to criticize the Pi for not having every possible feature or not being completely open source at every level, it doesn’t actually matter for 99% of projects. It gets the job done cheaply, quickly, and with a huge support community behind it.

The Raspberry Pi CM4 is now available for anyone who needs more granular access to IO or extra features like eMMC.

It seems like you didn't reply to I wrote, but rather to what you imagined I could have written. Or you're just pontificating in general.

I guess that's why they put the Raspberry Pi Foundation people first, then.

In my opinion, Raspberry Pi's main problem has to do with using SD cards, which are prone to errors and corruption. It's a kind of media storage that works best if it operates more statically--for instance, you read some photos on your camera, remove a few, take some new ones... and that's it for the day. They are not intended to undergo a large number of read/write cycles on a regular basis, and that's what the Raspberry Pi makes them do, using them to run its OS.

You can use log2ram [0] to reduce the number of writes to the SD card. That's what I'm doing at the moment and haven't had any problems with my SD card, though it has been in use for less than 6 months so far. I agree though that a SD card is not the best storage option for the OS and would like to move mine over to an nvme drive.

[0] https://github.com/azlux/log2ram

I read this same comment in every single HN post even tangentially related to the Pi. As others have pointed out, the Pi can run just fine off of USB and the newer ones support it out of the box. I ran my version 1 256MB Raspberry Pi for off an external USB drive. I only had to _boot_ from the SD card.

There have also been, for a long time now, SD cards with much better durability than the cheapest ones you can buy on Amazon. I personally look for ones labeled "high-endurance" or for use with dashcams because those are much closer to a proper SSD in terms of wear cycles.

I wish the RPi foundation would make it clearer in their documentation and blog posts you're going to have a bad time if you use a generic SD card as if it was a general-purpose hard drive.

>As others have pointed out, the Pi can run just fine off of USB and the newer ones support it out of the box.

I'm fully aware of that. In fact, and ironically enough, I'm one of those people you are referring to: https://news.ycombinator.com/item?id=26157437

>I wish the RPi foundation would make it clearer in their documentation and blog posts you're going to have a bad time if you use a generic SD card as if it was a general-purpose hard drive.

Conversely, I wish they would tell all their approved sellers not to include those "generic" SD cards (Raspbian/RPi OS preinstalled and all) with Pi's.

The problem is that getting a good sd card or flash drive is still a roll of the dice - you can't tell if a given device will suit by looking at its specs.

eMMCs are made pesirically for this purpose and its a shame there is bo pi model using them

Pi 4s can boot from USB now, as of the Sept 2020 bootloader update. No need for microSD.

No, not only Raspberry Pi 4's. I've had this on my bookmarks for a while, which explains how to boot any Pi (some models differ with regards to the procedure, or the need of an SD card, such as the Raspberry Pi Zero, which still needs one): https://www.raspberrypi.org/documentation/hardware/raspberry...

The problem of reliance on an SD card is somewhat less nowadays with the Raspberry Pi 4. Its faster USB3 support allows you to just use the SD card for the /boot partition to boot the system, while you can maintain everything else (root, userspace) on an attached USB drive that can handle heavy reading and writing.

You can boot entirely from USB on the Pi 4s now. Don’t even need the microSD for the boot partition.

Booting from USB was possible for the RPI3 as well.

Lost 2 SD cards that way. It's a relic that should be phased out in favor of NVME or SATA.

What SD cards did you use?

I have seen high endurance ones available.

These have never failed me:

https://www.digikey.com/en/product-highlight/a/atp/advancedm...

I even set up a testing rig to do randomized power shut down thousands of times; they didn't fail:

https://forums.balena.io/t/raspberry-pi-atp-amlc-microsd-car...

Found these via this 2018 HN comment:

https://news.ycombinator.com/item?id=16777238

Cortex-M4s have an optional AES core and hardware RNG. Pretty sad for a higher grade chip to be missing that. It doesn't consume much die space.

If you like poorly documented/supported hardware, try taking a stroll outside of the Raspberry PI ecosystem.

I bought myself a rk3399 based compute module a while ago, the support was... sparse.

* The small amount of documentation that does exist is vague and incomplete. Many of the links were actually broken, so I had to fall back to using the docs for older models.

* The key expired on their apt repo and they never bothered to renew it.

* The selection of prebuilt Linux distributions is small and several generations behind.

* The community is small, so you can’t rely on things like stackoverflow as much as you might in PI land.

Overall, I had a good time with it, but getting started on a PI would have been so much easier.

The issue has never been that the Raspberry PI hardware is amazing or fully utilized. The issue is that is that what is supported is supported well in software. You can put Raspian on it and expect consistent behavior in software, drivers, video, audio, etc. It will all just work in typical ways.

While this board has a nice selection of features, its likely the pi4 is faster in any number of workloads due to the use of the A72s. A55's are still in the small/energy efficient category (the article notes they are slower than the existing rk3399). Which is fine if your doing traditional micro-controller functions. But the problem with these boards is they end up being application specific rather than general purpose boards. For example they have hardware video decoders/etc but as soon as the user tries to decode something that doesn't have hardware support it falls back to the CPU, and turns into a slideshow.

Now if this were the rx3588 with the A76s it would be a different story.

A quad-A55 is a surprisingly performant board - not a desktop replacement, but certainly more than a fancy microcontroller. Keep in mind this SoC is also clocked 20% faster than the RPi4. Not enough to make it faster overall, but enough to substantially close the gap.

There is a newer SoC revision on the newer rpi's. For example the rpi400 comes at 1.8Ghz base.

Even so, it seems the 1.5Ghz is more about running the system without a heatsink. Give one a heatsink and they run at over 2Ghz. The perf bump from 1.5 to 2.2Ghz is not insignificant.

https://www.jeffgeerling.com/blog/2020/raspberry-pi-400-can-...

https://hothardware.com/reviews/hot-clocked-pi-raspberry-pi-...

Also: Arm itself says the A55 is ~18% faster than the a53. So, its still quite slow.

I'm unaware of ARM SBCs that have as much support from their vendors as the Raspberry Pi models do, though.

Pine64 is a probably a pretty close second. For example, many of their boards are supported by upstream Debian [0], which isnt true for the RasPi devices.

[0] https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-c...

What boards would you consider "better" and for what reasons (gpu and crypto extensions, or are there other factors)? I run a few raspberry pis and always looking for new/better toys.

The Raspberry Pi optimises more for lower cost. For not that much more you can get something like the Odroid N2+ which has 6 cores total, 4 Cortex A73 cores @ 2.4 GHz for performance and 2 A55 cores @ 2 GHz for efficiency.

https://www.hardkernel.com/shop/odroid-n2-with-4gbyte-ram-2/

I like rk3399 boards, unless you need deep suspend or video out through the USB type c port.

The only thing really atrocious on the RK3399 is the internal bus matrix. It's a legacy 32-bit crossconnect, i.e. physical address space is only 4GB.

Among other things, this means the PCIe aperture is squeezed down to a very measly 2×16MB — which is not even remotely enough for a lot of PCIe cards.

Also, if you install 4GB RAM, you only get to use something like 3.5G.

Oh and if I remember correctly, PCI MSI are broken, which again limits the PCIe card selection even more...

Where can I find more information related to these issues?

cat /proc/iomem on an installed Linux; note how everything is crammed into 32-bit addresses. Also,

http://opensource.rock-chips.com/images/e/ee/Rockchip_RK3399...

Page 13 ("1.1 Address Mapping") - same thing, everything crammed into 32bit.

PCIe Aperture is documented in TRM Part 2:

https://www.t-firefly.com/download/Firefly-RK3399/docs/TRM/R...

Page 711 - and I misremembered, it's 64MB total in 1×32MB + 32×1MB blocks. For comparison, my 6 year old server has 64GB PCI aperture space on each of its 2 sockets, my Laptop has 16GB. (Obviously both >32bit address spaces... which the RK3399 really should be too, but isn't.)

MSI is blacklisted in the Linux kernel somewhere if I remember correctly; it just randomly loses interrupts.

P.S.: Address space doesn't need to make a 32->64bit jump, my laptop CPU has 39bit, my server has 46bit; even 36bit (like old Intel 32bit PAE) would've been sufficient on the RK3399. But 32bit isn't.

P.P.S.: the PCI aperture size is the most obviously a problem when you try to plug in a GPU. E.g.:

  0c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] [1002:67ff] (rev cf) (prog-if 00 [VGA controller])
  ...
          Region 0: Memory at 900000000 (64-bit, prefetchable) [size=4G]
          Region 2: Memory at 880000000 (64-bit, prefetchable) [size=2M]
          Region 4: I/O ports at f000 [size=256]
          Region 5: Memory at f7e00000 (32-bit, non-prefetchable) [size=256K]
  ...
          Capabilities: [200 v1] Physical Resizable BAR
                  BAR 0: current size: 4GB, supported: 256MB 512MB 1GB 2GB 4GB

This GPU actually allows you to reduce the size it needs, but the absolute minimum you can set it to is 256MB...

The real problem is that PCI address space is not normally a scarce resource, and some RAID controllers & network cards (particularly high-performance/server ones) use a random bunch of it (>= 128MB) , and that's not even starting on SR-IOV. And these requirements aren't well documented because PCI memory space is not normally a problem. If you're lucky you can google "<card name> lspci", if not you only notice after you bought the card...

RK3399s make great bang-for-the-buck boards, but the idle power consumption is pretty high. I’ve been kicking around one of the Khadas VIM3s which has a newer Amlogic SoC on it and like what I’ve seen so far. It’s a significantly more expensive board, though

There are plenty of things that an RK3399 (or the new Rockchip being used in the OP) can handle just fine.

I was definitely interested to see that this new chip supports up to 8GB of RAM. I think there are a lot of interesting applications for RAM-rich, Gig-E bearing nodes that can run off a battery. (Examples: Redis at the edge, “Field” PostgreSQL replicated to the cloud when possible, nested VMs protecting trusted “firmware” from remotely-loaded containers and machine images, etc.)

What is your favorite alternative?