Pine64 Unveils Quartz64 SBC(cnx-software.com)
cnx-software.com
Pine64 Unveils Quartz64 SBC
https://www.cnx-software.com/2021/02/16/pine64-unveils-quartz64-sbc-powered-by-rockchip-rk3566-soc/
76 comments
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.
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.
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.
[deleted]
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.
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.
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...
[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/
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...
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.:
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...
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
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.)
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?
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.
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.
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.
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.
worik(1)
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
[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.
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.
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
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.
[deleted]
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.
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.
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
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.
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.
A killer feature that can be replaced by a 6€ external module? https://www.ebay.com/itm/402641596500
(you can get crappier ones for 2€... this one has a charge controller [MCP73833] from a recognizable brand [Microchip] with datasheets available)
(you can get crappier ones for 2€... this one has a charge controller [MCP73833] from a recognizable brand [Microchip] with datasheets available)
I dont see how a battery attached to the board would do much good for powering your drives in a NAS situation - they'd still need their own UPS.
Yeah, but you'll have to power your modem too.
These work really well for that task. Can power a cable modem and a small edgerouter-x using a y-cable.
https://www.ebay.com/itm/Belkin-Residential-Gateway-Battery-...
https://www.ebay.com/itm/Belkin-Residential-Gateway-Battery-...
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]:
[1] https://wiki.pine64.org/wiki/Quartz64
[2] https://rockchip.fr/RK817%20datasheet%20V1.01.pdf
[3] https://patchwork.kernel.org/project/linux-arm-kernel/patch/...
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)
[1] https://wiki.pine64.org/wiki/Quartz64
[2] https://rockchip.fr/RK817%20datasheet%20V1.01.pdf
[3] https://patchwork.kernel.org/project/linux-arm-kernel/patch/...
This feature caught my attention too; can’t wait till I can get my hands on a unit for testing.
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.
I worry more about the price of a 10 inch e-ink panel.
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...)
(Source: our company tried to buy e-ink displays to integrate into a product. All I can say is, it is difficult...)
> when the e-ink patent overlords
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.
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. 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.
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.
What's the motivation for the vendors to vet use cases/limit sales?
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.
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.
Probably linked to failure rates due to significantly higher page updates than an ebook or sign.
Kobo's Clara HD is 99$, runs post market OS, has a small 1GHz core and 512 MB of RAM.
Great low end option IMO.
Great low end option IMO.
Pity, they're $200+ in Australia.
Do you mean that they come stock running postmarketOS, or just that you can install it?
You can run pmOS. Not stock.
I am confused. Seems like this unit does not boot yet according to the postmarketos Web site.
I must have confused the wiki page for "is able to run on the device".
Nevertheless there are kernels and X.org patches available that supposedly work.
Nevertheless there are kernels and X.org patches available that supposedly work.
Cost of Pine64 SBC: $64
Cost of e-Ink panel: $50
Money paid to patent owner: $300
Cost of e-Ink panel: $50
Money paid to patent owner: $300
I was referring to the sum of both--to the price of that particular machine (SBC + e-ink panel) I just described.
Yeah, those can easily be in the $200 range.
What's the concern?
This is the real star of CES (just kidding). Where can I put my preorder?
With 8 GB it becomes a viable small desktop box.
With all of the connectors and interfaces, this is more of a dev board.
The article notes that CPU performance is similar to the Raspberry Pi 4, which is already available with 8GB of RAM and has better mainstream support.
The article notes that CPU performance is similar to the Raspberry Pi 4, which is already available with 8GB of RAM and has better mainstream support.
Lacks the PCI. If you get the compute boards, you can get it, and then use a carrier board to do things e.g. quad-Sata disk stuff.
I'm using the Pi4 with the 4 port SATA card through USB, and its just-about ok. I'm happy, but I'd love to try direct PCI access
I'm using the Pi4 with the 4 port SATA card through USB, and its just-about ok. I'm happy, but I'd love to try direct PCI access
I tried the rk3328 on my 1080p monitor. Was fairly slow, and video playback was problematic.
Otherwise good enough for light usage.
Hopefully the Rockchip VPU patches are still making progress.
Otherwise good enough for light usage.
Hopefully the Rockchip VPU patches are still making progress.
I've been meaning to buy something from pine64. This might finally be it; especially with that e-ink screen.
I just joined the mailing list. Hopefully I can snag one of those.
I just joined the mailing list. Hopefully I can snag one of those.
One word: Pinecil