The long awaited RPi 4 is almost finally here! Except we’re not talking about Raspberry Pi 4, but Rock Pi 4 designed by Radxa team, back after three years following the launch of Radxa Rock 2 Square, with the new SBC just unveiled by Tom Cubie, Radxa founder.
Rock Pi 4 single board computer is powered by a Rockchip RK3399 hexa-core processor coupled with 1 to 4GB RAM, and following Raspberry Pi 3 and ASUS Tinker board form factor.
There will be two variants with Rock Pi 4 Model A and Model B sharing most of the same specifications:
- SoC – Rockchip RK3399 big.LITTLE hexa-core processor with 2x Arm Cortex-A72 @ up to 1.8 GHz, 4x Cortex-A53 @ up to 1.4 GHz, a Mali-T864 GPU with support OpenGL ES1.1/2.0/3.0/3.1, OpenVG1.1, OpenCL, DX11, and AFBC, and a VPU with 4K VP9 and 4K 10-bit H265/H264 decoding
- System Memory – 1, 2 or 4GB LPDDR4 @ 3200 Mbps
- Storage – eMMC module socket, micro SD card slot up to 128GB, M.2 NVME SSD socket
- Video Output / Display Interface
- HDMI 2.0a up to 4K @ 60 Hz
- 2-lane MIPI DSI via FPC connector
- Dual independent display support
- Audio – Via HDMI and 3.5mm audio jack; HD codec supporting up to 24-bit/96Khz audio
- Camera – MIPI-CSI2 connector for camera up to 8MP
- Connectivity
- Rock Pi 4A – Gigabit Ethernet
- Rock Pi 4B – Gigabit Ethernet with PoE support (additional HAT required), 802.11ac WiFi 5, Bluetooth 5.0 with on-board antenna
- USB – 1x USB 3.0 host port, 1x USB 3.0 OTG port, 2x USB 2.0 host ports
- Expansion – 40-pin expansion header with 1x UART, 2x SPI bus, 2x I2C bus, 1x PCM/I2S, 1x SPDIF, 1x PWM, 1x ADC, 6x GPIO, and power signals (5V, 3.3V and GND)
- Misc – RTC
- Power Supply – Via USB-C port supporting USB PD 2.0 (9V/2A, 12V/2A, 15V/2A, or 20V/2A) and Qualcomm Quick Charge 3.0/.0 (9V/2A, 12V/1.5A). It’s also possible to power the board via a 5V/3.4A power adapter, but it is not recommended
- Dimensions – 85 x 54 mm
So the only real difference between model A and model B is the latter includes a wireless module, and optional support for PoE.
The main advantage of relying on Raspberry Pi form factor is that you can use/re-use Rasperry Pi add-ons, including official ones, and for example, the official Raspberry Pi 7″ display and the Raspberry Pi Camera V2 IMX219 have all been tested successfully on Rock Pi boards. Just to be clear compatible here means hardware compatible, but not software compatible, as Raspberry Pi 3 images won’t magically work on Rock Pi 4. Initial / WiP documentation is available on Radxa wiki, as well as a dedicated website.
Tom Cubie did not inform me about pricing, and there’s no such info on the website that I could find, but LinuxGizmos reports the Rock Pi Model A will sell for $39 (1GB), $49 (2GB) and $65 (4GB), while the Model B will go for $49 (1GB), $59 (2GB) or $75 (4GB).
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Hard to believe the pricing reported by LinuxGizmos and my only remaining question is still: how does Radxa want to solve heat dissipation? RK3399 without at least a great performing heatsink will have to throttle at higher loads.
Maybe the trick will be a slightly higher shipping fee?
The only solution I’m seeing is to sacrify the M2 connector and the compatibility with standard RPi enclosures, to place a heavy heatsink under the board like FriendlyElec does with NanoPI Neo4/M4. Otherwise they’ll end up with total RPi compatibility including the throttling behaviour 😉
With this said, at this price (if confirmed) the board is very interesting for such a CPU and I/Os.
Tom Cubie confirmed pricing:
The retail price should be the following:
Model A Model B
1GB : 39usd 1GB : 49usd
2GB : 49usd 2GB : 59usd
4GB : 65usd 4GB : 75usd
The launch was actually planned for 11.11, but a “leak” changed that.
where can i buy rock pi model a $39
https://s.taobao.com/search?q=rock+pi&imgfile=&js=1&stats_click=search_radio_all%3A1&initiative_id=staobaoz_20181205&ie=utf8
…and how does the M.2 work, exactly? Do you barbeque the SSD, or…?
“…and how does the M.2 work, exactly? Do you barbeque the SSD, or…?”
Edit: Saw tkaiser post below with picture of how the m.2 slot actually works.
the m2 ssd has a serepret borad giveing a inch gap from the sbc borad opasite of below not above heat sink heat rise so it quit safe i own 2 of them i know
I have a Rock Pi 4 with heatsink. CPU temp after 24 hours is 113 F.
“micro SD card slot up to 128MB”
I assume GB?
Is there any benefit to this compared to a NanoPi M4? It’s $5 cheaper, but lacks a good way to mount a heatsink and might have some hardware quirks.
Which hardware quirks? The only two notable things are:
* M.2 is oriented outwards so you either use the adapter or you DIY an enclosure that takes care of an attached M.2 card (not just NVMe SSDs, other M.2 cards like SATA or additional Ethernet will work as well but this will make the whole installation much larger of course due to the orientation of the M.2 slot)
* Heat dissipation. I wonder whether Radxa will provide an enclosure with a metal base plate to allow for appropriate heat transfer.
Picture of the M.2 Extender at the bottom of https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Review_of_Rock_Pi_4B.md
Thanks for clarifying M.2
@tkaiser, I was curious how they envisioned using the M.2. Thanks.
I have a few board design issues, like the placement of the Ethernet controller. It’s too far away from the Ethernet port and this is likely to cause signal degradation, especially as the routing is going to have to in a really quirky way around other noise components.
No option for an external Wi-Fi antenna is also a bummer, as those tiny chip antennas have very poor range in general.
The 4-pin RPi style PoE connector is vile imho.
Once again, an expansion header with only low-speed interfaces, why?
Forsee RAM, really? I guess that’s one way to keep the cost down, but it’s hardly a company know for quality or performance products.
Apparently the board could’ve had an SPI flash, but they chose not to add it so they could save 50 cents.
Some of the component placement is likely to cause signal interference, but that’s just my opinion. I do highly doubt that this board would pass certification as it is though.
Rock Pi 4 vs NanoPi M4 – https://ibb.co/mg0O0A
Three remarks to this comparison:
* DRAM: while testing weeks ago I found your LPDDR4 performing as good/bad as the other RK3399 thingies around: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md (see especially the notes there explaining in detail why memory performance seems to differ — it’s all about the software stacks running)
* I wonder whether your claim that the two USB3 ports do not have to share bandwidth is backed by tests. At least my tests (not with RockPi 4 so far) showed that both USB3 ports have a combined 5 Gbps bandwidth limit. See ‘Let’s try both USB3 ports at the same time’ at https://forum.armbian.com/topic/6496-odroid-n1-not-a-review-yet/
* Funnily I don’t get the RockPi 4 to boot with your supplied QC PSU. Currently using the FriendlyELEC’s ‘dumb’ M4 PSU for my testing. But I was too lazy to look into it in detail right now.
That eMMC connector looks odd. Doesn’t look like the normal ODROID type. Does anyone know more about it?
It’s compatible with Odroid with additional mounting connector.
The information is there, just not visible (Jean-Luc still thinks readers would be able to spot links in the first sentence/paragraph of his posts).
ODROID and Pine modules should be compatible. I’m about to test this right now, just looking for the .dtb file on vendor’s OS image (they use the horrible Rockchip partition layout for whatever reasons) to continue testing with Armbian since the ‘official’ image is armhf (again: ‘for whatever reasons’).
I’ve only used H3/s905 boards. Does a board like this consume that much more power to require a 9.V/2A supply, or is this only necessary because it can host USB 3 devices?
The RK3399 is a much more power hungry SoC. Also, power input doesn’t really have anything directly to do with power draw of the SoC. However, if you don’t have sufficient input power, the board isn’t going to work. It is always preferable to have too much input power, than not enough. Personally I favour good old 12V barrel jacks, especially for development boards, as you don’t know what people want to hook up to it. In this case, you also have an M.2 slot which is a PCIe x4 interfaces, which means you can connect some rather power hungry devices. In theory at least, if you connected a x4 PCIe card to this board, that card would want up to 35W through the connector and 25W of that is at 12V, not 9V. Even the most basic PCIe x1 devices will draw as much as 10W, but only at 3.3V.
Regardless, a poorly designed power input is not something you want, yet something way too many of these so called developer boards suffer from.
Isn’t it a bit early to declare this board as poorly-designed power-wise, though? I guess things can get botched sw-wise in usb-c PD land, but let’s wait and see how this will develop post-launch. At least the potential for proper power delivery is there.
I did no such thing, I was just comparing in general. I think the power design is one of the things I’m not overly concerned with, unlike the issues I mentioned above.
What hobbyist coolers did you want to see in 2019? CO2 immersion with impingement jet plates would help cover the free shipping.
Thanks. If I was just going to use this board as a simple kiosk computer, using the SD card as the only storage medium (no PCIe nor USB 3 drives or devices), how much power would it likely draw?
I wouldn’t use microSD cards for anything except testing. Get the eMMC module, as microSD cards have a very finit life span, since there’s no wear leveling or garbage collection.
> microSD cards have a very finit life span, since there’s no wear leveling or garbage collection
Huh? This is not ‘raw’ NAND here. Of course SD cards implement both, and we run a bunch of servers off them (with btrfs of course to do regular scrubs checking for — not existing yet — data integrity issues).
But of course only SD cards made for the use case should be used. And that’s currently A1 rated ones (since A2 suffers from driver support currently): https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md
I guess you’ve been lucky so far then, as I’ve been involved in projects where the microSD cards have burnt out in less than three months. I really wouldn’t use microSD cards for any kind of production environment where the OS runs on the microSD card. It’s fine for storage, but nothing much else imho. The fact still stands that there is no wear leveling or garbage collection on microSD cards, which eMMC has. Btrfs doesn’t make up for that.
Interesting information about the A2 cards though, I thought I was doing something wrong testing my SanDisk A2 card as well, or using the wrong benchmark somehow, but if it is as you say, then I guess there’s really no performance benefit to be had as yet.
Use SD cards only with a read only OS.
BS. If you care about longevity then buy such cards, e.g. SanDisk Industrial. And always test each and every flash memory product you buy directly after purchase. The tools exist and are easy to use: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card
The reality is, apart from that “industrial grade” Tkaiser mention, you should not trust SD cards. For example In 2 similar cards running Android kodi on Opi PC non-stop for the past 4 years, heavy use (recently with the great H3DROID), one of them only had last for 3 years, the other one is still in operation. So, it’s like a casino.
> you should not trust SD cards
And the same is true for eMMC and every other type of storage. That’s why we do backup and that’s why businesses and smart home users also care about data integrity. Since storage is prone to failure.
This is not the only report of ‘eMMC has died’: https://forum.armbian.com/topic/2071-emmc-broken-on-orangepi-pc/
1x back ups on site 1x back up in building safe 1x back up off site diffent locathion makes for a profeccional and very high sucuess for 98.99 % of all cases
> The fact still stands that there is no wear leveling or garbage collection on microSD cards, which eMMC has
Seriously? We’re still not talking about ‘raw NAND’ (where the host controller has to take care of all of this) but SD cards where the FTL (flash translation layer). SD cards are that similar to eMMC that adapters exist making eMMC modules usable as the former.
This is rather old knowledge: https://web.archive.org/web/20130728131543/https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey?action=show&redirect=WorkingGroups%2FKernel%2FProjects%2FFlashCardSurvey and https://msreekan.com/2014/01/15/sdcard/
I believe there are 2 main differences between SD cards and eMMC and both are not technical:
1) eMMC is usually bought by companies not individuals. No fancy marketing BS needed but storage that lasts
2) due to this we don’t have the fake/counterfeit problem with eMMC as we have with SD cards
And 2) is IMO reason number one why people don’t trust in SD cards. Since counterfeit cards faking a higher capacity will die at least thousand times earlier than correctly specced SD cards.
Imagine 3 products each advertised as 32 GB in size: A counterfeit card which is in reality just 8 GB in size, a crappy 32 GB SD card which can withstand only 500 P/E cycles per cell and a great 32 GB eMMC module with superior controller and flash than is good for 1500 P/E cycles.
Oversimplified as hell: the counterfeit card will fail after just 8 GB have been written to it. The crappy 32 GB SD card with an inferior controller can take approx. 13 TB (32*400) while the good eMMC with its better flash and superior controller will fail only after 48 TB (32*1500).
Counterfeit SD card will die 6000 times earlier than the eMMC module. And users still blame the card and not themselves for not testing each and every flash product directly after purchase. I guess since it’s a lot easier for them…
Sorry, but I don’t think you understand the underlying differences in technology for microSD cards and eMMC. Yes, microSD cards aren’t raw NAND, but at the same time, they are far from eMMC. I don’t even know why you’re bringing in counter fit cards into this discussion, maybe you had a bit too much beer for breakfast? But please, go ahead and be right as always, since it’s not possible to have a reasonable discussion with you about any topic you feel strongly about.
Tbh it looks like wear levelling is optional for both SD cards and eMMC. I think we’re dancing around the truth here that industrial SD cards and industrial eMMC exist both of which likely include wear levelling. If they include it, they advertise it.
The problem is that if you pick at random an eMMC board and an SD card you are far more likely to get an industrial-grade unit with the eMMC than the SD card. So many of those are used by consumers that there’s just a lot of junk floating around.
> Tbh it looks like wear levelling is optional for both SD cards and eMMC
As it’s ‘optional’ with SSDs. Show me any standard or specification requiring an SSD to do internal housekeeping like wear leveling and garbage collection. Of course they all do since they do not expose their flash cells directly but there’s always an abstraction layer in between. With SSDs, (e)MMC and SD cards it’s all called FTL (flash translation layer) as already mentioned. Without wear leveling any SD card used in a camera would be dead within no time since the FAT (file allocation table) always resides at the same location and these cells would’ve been worn out almost immediately. Why doesn’t this happen?
Of course every SD card needs to implement wear leveling and garbage collection just as (e)MMC storage does for the simple reason called FTL. This is different with other approaches like ‘raw NAND’ or for example xD-Picture Card which do not rely on FTL but need a flash aware filesystem to last long(er). I posted the two links above for a reason: to read and learn. Here’s another guy (Linux kernel developer Arnd Bergmann) explaining what’s happening inside SD cards and similar (e)MMC: https://lwn.net/Articles/428584/
There’s no technical distinction between SD cards and eMMC since you can buy high quality SD cards as well as crappy eMMC. It’s a problem of markets and user expectations. And now with another cheap SBC allowing for socketed eMMC and even being compatible to Hardkernel’s and Pine’s modules selling counterfeit eMMC modules gets interesting for fraudsters… poor users being tricked into believing eMMC would always be the better choice…
Always test flash storage directly after purchase for faked capacity and promised performance.
“Current SanDisk products do not preempt wear leveling events during normal operation of the
card. Applications typically don’t require such management beyond the natural wear leveling that
occurs during normal host operations. As a result, the effectiveness of wear leveling in current
SanDisk products is dependent upon host usage. ” https://web.archive.org/web/20150326122100/http://ugweb.cs.ualberta.ca/~c274/resources/hardware/SDcards/WPaperWearLevelv1.0.pdf
This is very different to how eMMC works, where you have both static and dynamic wear levelling, plus garbage collection. This also means that the OS can trigger wear levelling, which you can’t do on microSD cards. https://www.micron.com/~/media/documents/products/technical-note/nand-flash/tn2961_wear_leveling_in_nand.pdf
But please, be right, as always, since no-one else happen to have any knowledge.
> Current SanDisk products
Quoted from a well known document that is 15 years old now (October 2003). So first this is about historical and not current SanDisk products. Second: of course in the same document also the other prerequisite for implementing FTL is mentioned: ‘requiring the system to perform a “garbage collection” operation to free up new blocks for subsequent write operations’.
If a flash storage technology involves FTL (flash translation layer) to abstract physical from virtual addresses both wear leveling and garbage collection have to be done by the card’s controller. That’s still true for every single member of the FTL category be it SD card or (e)MMC or AHCI/NVMe SSDs and is explained in detail in the Micron document (look at Figure 1).
TL;DR: If there’s FTL involved this means ‘Wear Leveling’ and ‘Garbage Collection’ by definition since otherwise this wouldn’t work at all.
To the best of my knowledge neither SD nor eMMC standars require wear leveling — whatever individual products do is entirely up to their respective manufacturers. It just happens so that eMMCs, by means of being used as irreplaceable media in phones, tend to implement more robust wear leveling techniques. That doesn’t mean that you cannot get an SD card that outperforms an eMMC at wear leveling. It just means it’s less likely.
> To the best of my knowledge neither SD nor eMMC standars require wear leveling
Wear leveling and garbage collection is internal housekeeping no standard/spec is needed for. But any FTL storage product not doing wear leveling will be dead within no time when used with the standard’s default filesystems called FAT/ExFAT since the piece that gave these filesystems their name — the FAT (file allocation table) — will always be at the same (virtual) address.
That’s the whole point of implementing an FTL: virtual vs. physical addresses, an abstraction layer in between needing both wear leveling and garbage collection since otherwise the storage product would be almost immediately unusable due to the default filesystem’s behavior of storing the FAT at always the same location. If it does not at least primitive wear leveling it will die shortly since storing the FAT will destroy the product. It’s really that easy and the historical documents TLS linked to really help understanding the basics.
You can argue about the quality of a specific wear leveling implementation but not about it’s existence (with FTL implementing flash storage products). And BTW: technology involves. Back in 2003 the controllers in these cards were performing rather poorly and also the amount of volatile cache they had was low which had an direct impact on the WL implementation. But things have changed.
Talking about historical documents… this is also a refreshing read (especially at the bottom where Bunnie explains what the micro controllers on these cards are also doing): https://www.bunniestudios.com/blog/?page_id=1022
Dual-channel LPDDR4 — about time! Now they need proper sw support (read: an aarch64 user-space official image) and this board will be the default entry-level choice.
> Now they need proper sw support (read: an aarch64 user-space official image)
I just had a quick look wrt efforts to get this thing supported by Armbian (same with Khadas Edge/Captain also lying on my desk for some time now):
https://github.com/radxa/kernel/tree/rockpi-release-4.4 (‘This branch is 13 commits ahead, 1855 commits behind rockchip-linux:release-4.4.’ — great!). On the vendor provided image I neither find rockpi-4b-linux.dtb nor anything where I could adjust boot arguments, e.g. to add ‘coherent_pool=2M’ to get USB3/UAS working stably. It seems boot arguments are hardcoded in u-boot… OMG)
Situation with Khadas is even more weird. They only provide obscure OS images to be flashed to eMMC with some proprietary Rockchip tools needing an USB-C connection to some other PC running Windows or Linux (if a Windows PC is needed to get Linux on a device then something went ‘slightly’ wrong I would say)
What a mess with most vendor provided software offerings for RK3399 boards. Most of them are busy reinventing the wheel fiddling around with SoC vendor BSPs of different age partially implementing ‘Android methods’ to flash/boot Linux images, then combine this with some userland lurking around somewhere on the Internet (Linaro in this case) an awful lot of people have already fiddled around here and there. Pretty annoying…
That’s really the main (only?) issue I’m having with Rockchip in fact. I love the 3288. I find the 3399 reasonably good (but only once the little cores are overclocked since it has too few big ones). But each time it’s a real PITA to try to experiment with different kernel/DTB/cmdline settings. Most even ship with u-boot configured with boot_wait=0! So in practice once it boots you think “OK let’s get calm now and not touch anything anymore”. I’d like to see u-boot configured properly, with support for scripts and extlinux.conf so that I can simply play with symlinks on the flash to try various entries. Like I can do on the NanoPI-Fire3 in fact.
> it’s a real PITA to try to experiment with different kernel/DTB/cmdline settings
Good news. Found a new Debian image for the RockPi. Still Linaro/armhf userland but now with an extlinux.conf, a kernel image and a rockpi-4b-linux.dtb directly accessible 🙂
Immediately did the usual slight ‘overclock’ (1.8GHz –> 2.0GHz on the A72 and 1.4GHz –> 1.5 GHz on the A53) and at least my board seems to be stable with these settings. As expected performance is the same as any other RK3399 with dual channel memory configuration but this might change in the future once Rockchip + board vendor provide newer boot BLOBs (DRAM initialization) allowing for higher memory performance.
> Found a new Debian image for the RockPi. Still Linaro/armhf userland but now with an extlinux.conf
Great! I’m interested in trying it on my H96Max. Do you have a URL ?
http://wiki.radxa.com/Rockpi4/downloads — The extlinux stuff is on an own partition but it seems the image relies on an own BL31 version that will prevent booting on other RK3399 devices.
Thank you, I’ll see if I can manage to replace the BL31 with the one present in my boot loader, but given that they tend to sign everything it will not be trivial.
@tkaiser, have you updated the rpi4 memtest results in the perf table?
https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
They look low but that’s only due to running an armhf userland and kernel with CONFIG_HZ_1000 (Rockchip’s BSP default, once you switch to CONFIG_HZ_250 memory performance improves a lot)
The kernel is reasonably up to date for this branch (4.4.154, dated 2018-09-05), this is pretty cool. Let’s hope they’ll continue to merge stable updates over time.
Well, 4.4 is good but it isn’t mainline. People who care about support still prefer the Raspberries.
RK3399 mainline support is excellent as long as it’s not about ‘Media Center’, it’s just the board vendors doing their first steps with the SoC vendor’s BSP which is 4.4 LTS with Rockchip right now (EOL in Feb, 2022): http://opensource.rock-chips.com/wiki_Status_Matrix
Unlike the Raspberry Pi where the whole primary operating system is closed source (an RTOS called ThreadX running on the VC4 has total control over the hardware unlike the secondary OS like Linux running on the guest processors) with Rockchip currently it’s just one boot BLOB required for DRAM initialization (maybe this has changed and RK open sourced their DRAM/SPL code in the meantime so we could run a fully open software stack on the RK boards, something that will never happen on the Raspberries since BroadCom / Express Logic don’t allow ThreadX to be open)
> People who care about support still prefer the Raspberries.
Good one, you made my day 🙂
Interesting SBC, but if they continue to print “EC” instead of “CE” on it, they can’t sell it in the EU tough ? Embarrassing mistake.
The FCC logo is incorrect as well. I highly doubt that this board is certified, as pointed out in my first post here.
https://shop.allnet.de/detail/index/sArticle/297717 — on these pictures the CE logo looks right. And it seems they’ve ALLNET as European distributor which is most probably good news wrt retail pricing and should also mean certifications have already been done?
Allnet is a ripoff outfit. Charging almost twice the Chinese price for European customers
Well: https://www.innet24.de/Makerspace/Single-Board-Computer/Rock-Pi:::2953_2779_3444.html (prices there include VAT and all the other distributor hassles).
Only able to compare the following ROCK PI 4B prices (guessing normal status of the inexpensive 4A variants will be ‘sold out’ anyway all the time):
* 4GB: 95,18€ (80€ w/o VAT) vs. $74.95
* 2GB ‘Basic Performance Set’: 87,01€ (73€ w/o VAT) vs. $73.85
So pretty normal I guess. And when adding in customs I would clearly order from a local reseller.
Can’t find a link at Alibaba/Taobao.com, I guess this product is for overseas.
I guess they’ll sell it in China too, but it’s just not available because launch is planned for November 11th.
Where will it be available? On Seeed Studio? Thanks!
So where can I buy one in Canada/US ? There is no clickable buy link on rockpi.org…
As mentioned a few times in the comments above, it will launch on November 11 (tomorrow)
i had to buy from china i got trumps terriff plus customs 207.04 finial cost with nvme exp borad and 32 gb samu evo msd
What about software support? For 3288 all links to Android SDK are dead.
Hi all. I’ve made a review video about the Rock Pi 4B. It’s a great board, very well designed. And the software support is getting realy good. Recalbox is comming(I’ve already tested it, it’s great), LibreElec will be added soon, Armbian is already available. And also Android, Android TV, Debian desktop armhf and Ubuntu Server.
Here is my video. Greetings, NicoD
https://www.youtube.com/watch?v=5eV-uPOyVlg
very nice review, thanks for sharing.
OK great! “Will not Work magically” means that it works with some os issues? Ubuntu?
So for that Price i will buy Modell B 4GB. Ich will sell old pi 1, 2 or 3
Armdevices.net have a video of Collabora running open source mail panfrost drivers on Rock Pi 4 , video posted April 2 2019