Coupled with that 10-inch e-ink panel that they mention will be available when it launches, this could make for a great machine for working (reading, writing, coding...). I hope the price is not very steep.
Don't worry about the price - when the e-ink patent overlords learn that they are not being used for blessed purposes (digital signage or ebook readers) but as general purpose display sold to end users (gasp!) they'll probably become mysteriously unavailable.
(Source: our company tried to buy e-ink displays to integrate into a product. All I can say is, it is difficult...)
Any evidence of this? Everytime someone mentions this, I ask, and I get no evidence. If this kind of allegation was true, I'd expect tonnes of publications to jump on this.
> our company tried to buy e-ink displays to integrate into a product. All I can say is, it is difficult
I perceive this as equivalent to my company trying to buy 100 displays straight from Samsung and then alleging that it is hard to do. It is all about volume. Even a 1000 and they won't talk to you. It has to be in the 100k volumes before the actual device vendors talk to you. Otherwise you go through distributors just like everyone else.
Well we regularly buy LCD panels in large and small quantities from big manufacturers, and distributors, in order to integrate them into our industrial PCs. While we are not a household name, we're big in our niche and I'd say we have industry experience.
I was not on the project and I'm not in purchasing, so I don't know the details, but from what I heard it was quite odd. The vendor (not e-ink, but a downstream integrator) was first willing to sell thousands of units, we got a devkit from them and started developing. But suddenly they were like "What is your business plan sir?" and "I'm afraid we cannot sell at the moment". The quantity was not the problem, they sounded like they were not happy with the use case.
The reason you never see hard evidence is that there is no evidence to be found - it's just that the vendors behave "odd" and are picky with whom they sell to.
> I was not on the project and I'm not in purchasing, so I don't know the details, but from what I heard it was quite odd.
Ok.
> The vendor (not e-ink, but a downstream integrator) was first willing to sell thousands of units, we got a devkit from them and started developing. But suddenly they were like "What is your business plan sir?" and "I'm afraid we cannot sell at the moment". The quantity was not the problem, they sounded like they were not happy with the use case.
If my purchasing team gave an explanation like that, I'd be suspicious of the purchasing team. I've seen scenarios where the "distributor" didn't actually have the quantity in the timeframe they promised as they weren't a top tier distributor. So the purchasing guy who had some kind of relationship with that distributor was coming up with lots of crazy reasons to keep delaying until we finally found out. As always, the simplest explanation is not "vendors behaving odd and being picky about who they sell to", I've never seen a vendor being unwilling to sell as long as you are offering market price for that quantity.
My crazy conspiracy theory is that there is some ownership overlap with traditional display manufacturers. If it gets used widely as a general-purpose display this can cannibalize sales of LCDs as the technology gets better and cheaper. [1]
That's one reason you can get good and cheap e-ink if you are building an ebook reader [2], or if you are building these little price displays for the shelves in supermarkets. But if you want a monitor, you have to either pay a lot of money or buy something for tinkerers, there is no inbetween.
----
[1] The rational reason would be that they have only limited production or support capacity, and sell to the easiest, most lucrative customers first.
[2] Of course, for e-book readers you also have the benefit of scale if you are Amazon or Sony. But there are also smaller vendors, and in the case of the digital price tags the companies that make them are mostly smallish businesses.
There's quite a few third party boards that are far better than the Raspberry Pi 4. I found the Rpi4 quite disappointing, especially the half-supported GPU and the lack of AES/crypto extensions in the ARM64 chip. Only ARM64 chip I've ever seen that lacks those.
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.
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.
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.
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.
>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
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.
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.
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.
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.
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.)
How does the onboard battery charging IC work? Can I hook up a 3s li-ion battery and charge it via the 12v power input? Does the battery kick on if the main PSU is interrupted?
I think that this could be an underlooked, but absolutely killer feature for this board. Built-in support for high-capacity li-ion batteries that automatically kick-in for a battery backup would be awesome for homemade NAS set-ups, not to mention a whole host of robotics-y or home automation projects.
I imagine you would need to communicate the battery topology (voltages, currents) to the power management IC (PMIC). Probably via a devicetree, or possibly a devicetree overlay?
Devicetrees are used to list hardware peripherals, and instruct the kernel load the appropriate drivers with the appropriate parameters (I²C addresses, etc), so it would be the reasonable place to put that info, though it's probably configurable at run-time instead. There might also be some defaults, but I'd expect it to be "power PMIC off" if that chip is only used for the battery circuit (which I doubt).
Edit: According to the scematic on the wiki page[1], it's a feature of the main PMIC, RK817-15. I's also indicated "1Cell Li-ion"
Interesting features for that chip[2]:
Input range: 3.8V –5.5V for USB input
2.7V -5.5V for BAT input
Switch mode Li-ion battery charger providing charging current up to 3.5A.
Power path controller with 4A current path with optional extended external mos.
Accurate battery fuel gauge with two separate battery voltage and current ADC
Real time clock (RTC)
Low standby current of 16uA (at 32.768KHz clock frequency)
Devicetree support has already been submitted, probably merged a while back[3].
