The Orange Pi 5 has finally arrived! I received my pre-order and the board is great. So should you go out and buy it? Probably, but there are some things you should know first that you may not be expecting.
The biggest thing to know is that there is no WiFi/Bluetooth included. If you were planning on using Ethernet anyway this doesn’t have much of an impact. If you do need wireless capabilities we’ll cover what options are available.
In this review we’ll cover what you need to know about the Orange Pi 5 including it’s onboard capabilities, the available RAM options as well as benchmark the board. Let’s get started!
Hardware Used
Orange Pi 5
The Orange Pi 5 the latest release from Orange Pi and is the most powerful model yet. It has a 6 core CPU and options from 4GB of RAM all the way up to 32GB of RAM!
The Geekworm copper heatsink set is designed to fit many different single board computers. It uses thermal conductive adhesive which many “cheap” heatsink kits for SBCs don’t have. Eliminates hotspots and reduces throttling. Can be further enhanced by powered cooling over the heatsinks.
The Kioxia (Toshiba) 128GB M.2 2230 PCIe NVMe drive is much shorter than most NVMe drives (full size is 2280). It fits great with single board computers / tablets / other smaller form factors.
The Orange Pi monitor is meant to be a portable monitor you can take anywhere. It has a resolution of 1080P and features a hinge in the back that folds out to support the monitor.
The Orange Pi 5 official wireless module is designed to fit into a M-keyed M.2 slot (the only one the Orange Pi 5 has). This WiFi adapter will work with both Linux and Android.
HDMI2.1, up to 8K @60Hz DP1.4 (DisplayPort) DP 1.4 and USB 3.1 ports are multiplexed and the port is shared with Type-C 2 * MIPI D-PHY TX 4Lane Configurable up to 4K @60Hz
Camera
MIPI CSI 4Lane 2 * MIPI D-PHY RX 4Lane
Audio
CODEC: ES8388 3.5mm headphone jack audio input/output Input: Onboard MIC HDMI 2.1 eARC
Ethernet
10/100/1000Mbps Ethernet
Expansion Port
For extending UART, PWM, I2C, SPI, CAN and GPIO interfaces.
That is an outstanding score. We are getting NVMe performance. This score actually even beats my ODROID M1 benchmark.
The Orange Pi 5 is without a doubt a very powerful board and is performing exactly where it should be.
Keep in mind that this is PCIe 2.0 performance. This board does not have PCIe 3.0 (only the RK3588 proper has that, not the RK3588S).
UPDATE 1/2/2023: If you update the Orange Pi 5 firmware by using sudo orangepi-config and choosing “System->Firmware” and then choose to update the firmware I was able to get *low* PCIe 2.0 performance (about 280MB/s). I highly recommend updating the firmware with sudo orangepi-config. You may see some marginal improvements!
Due to this you should not use a powerful NVMe drive with the Orange Pi 5. You are limited in speeds to around 500MB/s at best (according to Orange Pi themselves via the user manual) and more like 250MB/s write according to the benchmarking.
I’ve now installed my heat sinks which looks like this:
Orange Pi 5 with Heat Sinks
That means it’s time for a head-to-head benchmarking match against the Pi 4 to see how the Orange Pi 5 compares. For the benchmark I used the “hardinfo” benchmark which can be installed on most Linux flavors with:
sudo apt install hardinfo
Here are the results:
Test
Orange Pi 5
Pi 4
CPU Blowfish (lower is better)
2.65s
5.24s
CPU CryptoHash (higher is better)
574.49 MiB/s
466.37 MiB/s
CPU Fibonacci (lower is better)
0.5s
1.73s
CPU N-Queens (lower is better)
4.24s
8.74s
CPU Zlib (higher is better)
0.80
0.31
FPU FFT (lower is better)
1.23s
5.52s
FPU Raytracing (lower is better)
2.86s
2.18s
GPU Drawing (higher is better)
2064.13 HiMarks
1708.15 HiMarks
That is almost a clean sweep for the Orange Pi 5! The only category it didn’t win was FPU raytracing interestingly enough. On GPU drawing performance however the Orange Pi 5 scored significantly higher and also won all other categories.
Pros / Cons
Pros
4 GB and 8 GB RAM variants cost under $100
M.2 slot supports high speed NVMe storage
RAM options from 4 GB all the way up to 32 GB available
Cons
No WiFi or Bluetooth included (requires either adapter for the M.2 slot or a USB adapter to get WiFi/Bluetooth capabilities)
No eMMC option
PCIe speeds are limited to 500MB/s (PCIe 2.0, benchmarks show closer to 250MB/s write or PCIe 1.0 performance) — this is slower than SATA3
Conclusion
The Orange Pi 5 feels almost perfect except for the lack of built in WiFi / Bluetooth. This seems like a surprising choice on what seems like is portrayed as their “flagship” model. Fortunately it is easy to add WiFi/Bluetooth on the board via either the custom M.2 wireless PCB or by using one of your USB ports and just using a USB-based WiFi/BT chip.
The board performs extremely well. The GPU is powerful on the board and feels very snappy while using the desktop OS and applications. This board would be a good choice for almost any use case. It would make a great Minecraft server as well.
I’d recommend this one for just about anyone. The price is right. There are widely varying amounts of RAM available depending on what you need. There are good Linux and Android images available even at launch. At under $100 for the 4 GB – 8 GB the Orange Pi 5 is priced well in this market especially for the power and flexibility it offers!
Thanks for sharing this update as I saw one quick video today with it running from sd card and it looks really polished.
The ARMBIAN team have done an outstanding job in such a short time and having gpu acceleration drivers ready to install is fantastic as I was expecting it to take months unless you’re savvy enough to work it out yourself!
Jesús Vega
1 year ago
Hello everyone. I keep looking for solutions at pcie speed. I have found a bash script to change the speed of a pcie port. Let’s see if it works…
Welcome back! So I don’t have good news about this:
root@orangepi5:~# ./test.sh 0004:40:00.0
Link capabilities: 00726812
Max link speed: 2
Link status: f012
Current link speed: 2
Configuring 0004:40:00.0...
Original link control 2: 00000002
Original link target speed: 2
New target link speed: 2
New link control 2: 00000002
Triggering link retraining...
Original link control: f0120042
New link control: f0120062
Link status: 7012
Current link speed: 2
root@orangepi5:~# ./test.sh 0004:41:00.0
Link capabilities: 00726812
Max link speed: 2
Link status: 7012
Current link speed: 2
Configuring 0004:40:00.0...
Original link control 2: 00000002
Original link target speed: 2
New target link speed: 2
New link control 2: 00000002
Triggering link retraining...
Original link control: 70120042
New link control: 70120062
Link status: 7012
Current link speed: 2
That doesn’t look like it did much for me. It’s saying this PCIe interface is already set to PCIe 2.0.
This might not be fixable. It might just be a really poorly performing PCIe interface unfortunately. That’s very unfortunate! I cannot recommend the Rock 5B any higher if you need really fast NVMe as that board is actually hitting PCIe 2.0 speeds (and no one can with this one).
I think the issue is we got the RK3588S and this is probably all it can do. The Radxa Rock 5B has the real RK3588 and it shows. The Radxa Rock Pi 4C+ has the RK3399T which also has a faster PCIe interface than the RK3588S.
I don’t think we’ve really tested the RK3588S PCIe interface speed before (at least I don’t have this CPU on another board). This board is down thousands of points from the Rock Pi 4B, Rock Pi 4C, Radxa Rock 5B, and even the Compute Module 4.
I hate to say it but you are better off with just about any other PCIe interface than what we got on this device. You’d be better off with a Pi CM4 or just about any modern Radxa board it looks like if you want PCIe 2.0 speeds (or potentially higher for the Rock 5B). How much better? You’ll get 26,000-30,000 instead of 21,000 so it’s underperforming by roughly 25% from other boards that have PCIe 2.0.
This board does not qualify as PCIe 2.0 speeds but it looks like it’s not going to be an easy answer like an overlay. This might be all it can do. I consider this a pretty disastrous result and my hope that this will be fixed/changed has dropped 90%. I wish I had another board with the RK3588S in it so we could test if this is just the best the RK3588S can do or if Orange Pi still has something wrong in their kernel/code/configuration.
I’ve never tested a slower one. The Pi CM4 is faster and all the Radxa boards are faster. Boards that came out years ago (and are *definitively actually PCIe 2.0*) beat it. It’s pretty poor PCIe performance to put it mildly.
It looks like the answer was the more cynical one I was debating with someone earlier here in the comments. It might be a PCIe 2.0 interface but it might as well be a PCIe 1.0 interface because that is how it’s performing. The Radxa Rock 4B+ is curb stomping it with 26k+ scores and that model came out in spring of 2021! 6 core CPUs like the RK3399T are curb stomping it. This should not be happening on a board so much more obviously powerful than those old ones. What in the hell did they do to get the PCIe interface so *bad*?
The whole point of the RK3588S existing was to cut the PCIe 3.0 interface from the RK3588. That is almost the entire difference between the two other than a couple of mild I/O port count changes and it makes almost a $30-$40 price difference (best we can tell from the differences in prices between the boards that have the real RK3588 and the ones that don’t). And boy did they cut it well. Too well.
That’s why my hopes are fading for this at least. We have a version of the RK3588 that has fast PCIe. This is the version that doesn’t and it’s the only reason the board is <$100. It turns out though that if NVMe is what you wanted to do then you would have been much better off paying the 30-40% more. You want the RK3588 for that!
It does make me frustrated though that after more than 2 years we can't beat the Raspberry Pi CM4 with any of these boards. I was covering the CM4 back in like 2020. The CM4's PCIe 2.0 interface is in a whole different league from the one on this device. So is the one on the Radxa boards and the real RK3588. Even the real RK3588 isn't beating the CM4 so far in the PCIe benchmarks let alone this one! The CM4 continues to absolutely wipe the floor with the supposedly PCIe 2.0 interfaces on these devices and I have been waiting for YEARS for someone to knock them off the top.
Maybe this is the missing piece for people about why this is such a disappointing result to me. I was doing better than this years ago on the CM4. I have other Radxa boards that do better than this that are 1-2 years old. It's absolutely indefensible. I want someone to make a board that can outperform the CM4's PCIe 2.0 interface which should be *easy*. The CM4 was originally supposed to cost like $15-$20 and they can't outperform this with $100+ SoCs? 2 years later?
I really thought this board was going to be the one that would finally dethrone the CM4. It sure looks like it should on paper. I would have guaranteed from the spec sheets that this device should beat the CM4's I/O scores. It's not even close though. We're like 25% off. It will be the Orange Pi 7 that will beat the CM4's IO scores at this rate. 25% seems 1-2 generations behind to me. Radxa will probably catch up next generation it looks like but Radxa is at least putting out PCIe 2.0 scores even though they're not beating the CM4 still.
I suppose that's the story of this article so far. The spec sheets for this device will lead you to very dubious conclusions about performance here. If the spec sheets are to be believed this device should *smoke* the CM4 on I/O performance. Everything is there. The PCIe 2.0 interface. The faster CPU/GPU/SoC. More memory. It *looks* great! According to the spec sheet it's better than the CM4 in every way. In reality it gets curb stomped. They're not in the same league. It's multiple generations away from challenging it and they're even a generation behind their *other* competition!
That's why I think it was such a bad choice to cut to the RK3588S. I would have raised the price instead because then we're at least getting in the neighborhood of CM4 PCIe performance. They would have only been one generation behind (which is a position it looks like Radxa will enjoy this generation) instead of 2. Raspberry Pi doesn't have anything to ship so this would have been the time to try to put the real deal CPUs in your boards and not these cost-cutting variants. Saving the extra money probably isn't helping them very much right now because nobody can get their main competitor's boards anyway. They had a shot here to put up some serious firepower and they still went for the cheap cost-cutting variant.
Who is smarter, Radxa or Orange Pi? Radxa went for the expensive one this generation and Orange Pi went with the cheap version (but that is kind of their thing). I don't know the answer but I would give the edge to Radxa. I think this was the time to ship the real deal this generation with Raspberry Pi being in the state it is. Orange Pi is still operating like they're trying to compete against a $60 Raspberry Pi 4. That's not a thing that people have really been able to buy at that price for a long time. I really don't think Orange Pi needs to be so aggressive on pricing in this market but they're operating the same way they always have (and they may be right, they've made it this far). Time will tell!
If the Orange Pi 5 wasn't meant to be a value-based board I would absolutely destroy it. If it is meant to be a high performance PCIe 2.0 board it's among the worst (actually it is the worst for PCIe performance). If it's meant to be a value board though it's honestly the best value board I see out there right now. It's in the unique position of being among the worst I/O performers but the best value / bang for the buck!
The Radxa Rock 5B might have a better PCIe interface but it starts at like $140 which is roughly 50% more expensive than the Orange Pi 5 (at least what I paid on Amazon). If you don't need NVMe it's a no brainer to pick the Orange Pi 5 over the Rock 5B since you will get the exact same CPU performance with the Orange Pi 5 but with a slow PCIe interface.
Thank you Jesús Vega for continuing to investigate this. Just to be clear I do not know why it is performing so poorly. Linux says it is running in PCIe 2.0 mode. I just know that it is. I know that it's not performing as well as Radxa boards or as well as the CM4. There's no question about that. What I don't know is if there's any way to fix/improve it so thank you for continuing your investigation!
UPDATE: I did some more digging based on what I found from trying to run the script you shared. The interface definitely *is* PCIe 2.0 like the script said:
2.5GT/s is PCIe 1.0, 5GT/s is PCIe 2.0. The interface says it's running at 5GT/s. That means the question now becomes:
Why is it performing so slowly? Why is it slower than the CM4's PCIe 2.0 interface, or the Rock 4B/4C? Is it because it's only a single PCIe lane? But so are a lot of these other boards that are stomping it according to their spec sheets. It's performing so much worse than the others and it's not clear to me why still!
I guess that leaves some hope that this is some kind of bug / mistake still. It should be performing better than this! It's literally so bad that it took me weeks to even accept it is PCIe 2.0 because something is *wrong* here.
The numbers don't add up. Boards from 1-2 generations ago are beating it by 25%-33%+ that shouldn't be if we're going by the specification sheets and all logical reason. This is an 8 core board getting stomped by the quad-core CM4 and last-gen 6 core Radxa Rock Pi 4/4B/4C boards with supposedly identical PCIe versions. There is nothing equal about the PCIe performance between these devices. It's been a confusing / harrowing process to even determine the version because the speeds are screaming PCIe 1.0 and look nothing like the performance on other similar (and older) models with supposedly identical versions.
In other words it's not that it's failing to live up to my expectations that it's the fastest board for I/O performance ever released that is driving me crazy. That would be a "me" problem. It's how much worse it performs to similar boards with the exact same capabilities. It doesn't make sense for last-gen (and current gen) Radxa budget models (which are also the versions that were cut to not have PCIe 3.0 to drop the price) to be beating the shiny newer RK3588S (and not by a little either).
EUREKA! I tried something new. I went into orangepi-config with:
sudo orangepi-config
I then chose System->Firmware and chose to update the board firmware. I had not done this since I got the board so the firmware had never been updated.
After letting it update and rebooting:
Category Test Result
HDParm Disk Read 380.15 MB/s
HDParm Cached Disk Read 370.00 MB/s
DD Disk Write 263 MB/s
FIO 4k random read 61134 IOPS (244537 KB/s)
FIO 4k random write 37101 IOPS (148405 KB/s)
IOZone 4k read 76599 KB/s
IOZone 4k write 68684 KB/s
IOZone 4k random read 37015 KB/s
IOZone 4k random write 71836 KB/s
Score: 18965
Nice, that’s actually a marginal improvement and I broke 250 (slightly)! I’d say it’s probably worth updating the system firmware on it.
Outstanding work there James as who knows how many others neglected to upgrade the firmware and who knows you might uncover something that’s hidden to get even better speeds.
I see some people mentioning seeing a wifi + bt usb dongle being sold as part of a Orange Pi 5 bundle on aliexpress and I believe the dongle uses one of the hashed out chipsets from wifi bt config (RTL8723BU) so that might be the one that’s included in those amazon bundles and its supposedly plug & play…? I have one on order and will do some testing once it arrives and its available cheaper from aliexpress or ebay AUS but I suspect they’re sourcing it from China themselves LOL.
Yes, I actually saw those as well. It’s the only place I had seen it offered for sale. If anyone has one of these (even if it’s a non-official one) definitely share a picture or something with us, I still can’t find one!
Good news James [applause]. With what we have already found out, we have seen where improvements in speed can come from. We must insist to the firmware developers. For now, we will have to identify the parts of the source code and compare with other developments. I don’t lose hope of reaching 400MB/s hahaha. My shipment is running late and my orangepi5 still hasn’t arrived. Regarding the android image, what is the nvme speed? Greetings.
Thank you, I actually couldn’t believe this made a difference! It did though. Probably something like 5-10% which is huge. It means exactly what you say.
I haven’t tried with Android yet. I wonder how hard it will be to image it for Android using NVMe and if my cloning trick will work. Android likes to be “flashed” with those awful programs like PhoenixFlash a lot of the time and never just lets you write a normal image.
I’ll give this a try today and see if I can get an Android benchmark!
I tried this with Busybox’s built in dd and it doesn’t look like that one gives you a speed result:
/dev/shm # dd if=/dev/zero of=test bs=4096 count=140k conv=fsync
10240+0 records in
10240+0 records out
Can you install fio or iozone? It looks like it’s possible to do iozone but it’s going to be quite a few steps. When I googled “fio for Android” I did see some possible ports of fio for Android. Either one of those ones would be able to benchmark it as well!
I’m not sure what the best Android specific benchmarks you could run would be. It doesn’t seem like anyone has made anything like my Linux pibenchmarks.com script. It looks like there’s a PCMark one maybe. I should probably make a version of my benchmark for Android eventually!
Yes I did see that one in some of my searches looking to see if any obvious ones popped out. I would say it’s worth giving it a try.
You’re definitely right that it’s not an apples to apples comparison but we will keep that in mind. It should still give you a read / write score and I would say to give it a try and we’ll compare it (and if anything is really far off we could investigate further).
I think this would be a great start though! I’d say run it and whatever scores / results it gives let’s just take a look at them together. If it says anything wild like it’s getting 500MB/s write then I could absolutely put Android on mine and do some further testing but I think this is a valid starting point for sure.
:/data/data/com.termux/files/home # dd if=/dev/zero of=test bs=4096 count=140k conv=fsync
conv=1
143360+0 records in
143360+0 records out
587202560 bytes (560 M) copied, 2.197941 s, 255 M/s
/dev/block/nvme0n1:
Timing buffer-cache reads: hdparm: HDIO_DRIVE_CMD: Not a typewriter
4932 MB in 0.50 seconds = 9910902 kB/s
Timing buffered disk reads: 1210 MB in 3.00 seconds = 412848 kB/s
hdparm: HDIO_DRIVE_CMD: Not a typewriter
Excellent, that does help! You are actually right where mine is. My last testing I was at 260MB/s with the latest firmware updates so you’re really close. I imagine if you ran it several more times you’d probably be able to hit numbers like 260 since there’s some minor variation between runs.
I think this does help answer the question some people had about how the disk performs in Android. According to your benchmarking it’s exactly the same. This is a good thing in my opinion as we’re not really seeing a huge difference in disk performance between Android and Linux. That means people should be able to run Linux or Android without worrying that they’re sacrificing any disk performance choosing one or the other.
I love the weird busybox hdparm warning it threw of:
hdparm: HDIO_DRIVE_CMD: Not a typewriter
Hdparm has apparently been able to determine that your disk is in fact not a typewriter. Outstanding! Just some kind of funny old legacy code in there I’m sure but I got a kick out of it. The numbers are looking good though for hdparm as well.
Yes, I ran it several times.
. A few times was around 243MB/s~246MB/s.
. A few times was reached 260MB/s.
. And, many other times was around 255MB/s~257MB/s.
Oh my! I’m guessing this can be explained by differences in the dd version between busybox’s dd command and the one that comes with most modern Linux distributions.
You can tell they are different because the busybox one gives you that weird typewriter warning. I’ve actually never seen that before in my life running dd but it must be a thing in some versions of busybox.
One thing you may want to try is do:
dd --version
I think you’ll find they are probably different versions (maybe substantially). I think that would be the place to start before going any further. Let’s look at the version differences between the two!
I just read an article by nvidea on calculating pcie bandwidth for versions 1.0, 2.0 and 3.0. For versions 1.0 and 2.0 it tells you that 20% of the transmission is header overhead.
Also around 1Gb/s is lost in communication errors. If we take this to obtain the bandwidth of pcie 2.0 it would be: 5 Gb/s * (1-1/5) – 1 Gb/s =
3 Gb/s = 375 MB/s.
For sure this has to be part of the equation. This is true of all devices using PCIe so the tricky thing is still why does the Rock Pi 4C or the Pi CM4 still score something like 15-20%+ higher (even with the firmware updates)?
Those devices have to have the exact same PCIe overhead since that’s just a natural consequence of using the technology and expected. In other words we should see the same slowdown on those devices due to the overhead. There seems to be some kind of additional bottleneck here but the answer likely is in fact in the firmware (or possibly the kernel if it’s hardcoded like older Orange Pi boards such as the i96).
The good news is the gap has closed a lot. After firmware updates it’s starting to get performance more similar to the ODROID M1 which also disappointed me to be honest (because it also can’t compete with the CM4 for as of yet still unexplained reasons/bottlenecks despite being more powerful in paper in literally every way). It’s at least within the ballpark though of underperforming PCIe 2.0 devices instead of straight up PCIe 1.0 speeds!
I’ve actually updated the article today and added a note that I was able to achieve (low but still) PCIe 2.0 performance (about 260MB/s and I got one as high as 280MB/s) by updating the system firmware through sudo orangepi-config and then choosing System->Firmware and then updating the system’s firmware. I highly recommend updating (both the firmware and also the software through sudo apt update && sudo apt full-upgrade -y) when it does arrive as one of the first things you do!
Marcus
1 year ago
I asked Shenzhen XiaoTuDou Technology Store “Could you please explain, where to buy that “Wi-Fi6+BT 5.0 custom module M.2 M-KEY ?” Answer: “We will issue the WIFI+BT module.”
I see! That’s kind of a funny answer. I wish they would have elaborated and said maybe weeks, months, etc. but it’s definitely better than nothing!
I’ve tried searching Amazon for M.2 WiFi adapters and to be honest with you most of them I see are meant for Windows notebooks and tablets. Those types of machines have been using WiFi cards like this for a long time. This is what is making it harder to find one.
There hasn’t really been a lot of reason to use these in Linux so far but surely there are some tablets out there that have been released that use these that have Linux support. We just need to figure out what those are.
If anyone has a tablet or laptop that has one of these M.2 WiFi cards and you know it can run Linux that would be a really good place to start to see if we can plug and play it with the Orange Pi 5 or if we can rebuild the Orange Pi 5 kernel and add support for one. These type of M.2 WiFi cards have been around long enough that some of these have to be in the mainline Linux kernel by now.
It’s just not really obvious which ones those are but if people have access at work to a lot of laptops / tablets like I used to when I was a hardware tech I bet I could have found one of these inside a laptop/tablet model that would be capable of running Linux (and thus has a high chance that the card might be available in the mainline Linux kernel). Dell and HP both have models that support Linux for sure and that’s exactly the kind of place I’d expect to see of one these like Amazon is showing on page 1,2,3, etc.
I think the enterprise ones are probably the most likely ones to be mainlined because although the number of models with Linux support from places like HP and Dell aren’t a huge % of their models the ones that do have it tend to be *very* well supported. This is because HP and Dell have teams (and the money / resources) to actually submit these devices and get them into the mainline Linux kernel. If they’re putting that hardware in their Linux supported models there’s a really good chance it’s either because it’s already mainlined or it’s one that HP/Dell/whoever wanted to put the resources behind getting it mainlined.
Hopefully it won’t be too much longer before the official release/listing of these individually for sale, thanks for sharing!
EDIT: I tried some of these I had around the house and none of them fit. This seems obvious in retrospect but as a hardware technician I had never actually tried putting a M.2 WiFi module into the storage M.2 slot (because that’s not where it goes, I would have put it where the chip I was replacing was). It turns out most of the WiFi adapters in the tablets/notebooks are typically “E” keyed (and sometimes A+E keyed). Perhaps this is what they mean by the “custom PCB” part. These definitely do exist though like here. I’ll keep looking and see if I can find one that will fit into the Orange Pi’s slot.
There’s also special adapters that can let you use a E-key WiFi adapter with a normal M-key slot. Take a look at this one:
This would work theoretically. This specific adapter is $17-$18 which makes it quite a nasty additional cost to also needing a E-key WiFi adapter on top of that. Unless you already have one/some of these like I do it’s probably prohibitively expensive (at least considering that I can’t imagine Orange Pi will charge much more than $17 for their entire working module when it’s released and frankly hopefully it’s less than that). It is theoretically possible to do this though.
I ordered one and it says it’s going to come on the 3rd of January. Even if it doesn’t work for this purpose the adapter should be useful in my toolkit for weird future blog experiments (I love having weird adapters like this around). I’ll definitely update though and let you guys know if this adapter idea lets me actually utilize some of these almost certainly mainlined E-keyed WiFi chips.
Hello, I should have my OP5 in few days. I have that mentioned E-key WiFi adapter already and I plan to test that with Intel 9560NGW WiFi ac+BT card. That chip is supported by linux kernel since 4.14 so maybe there is some hope with Android. Anyway I found some more info from reddit.
RTL8821CU, RTL8723BU, RTL8811CU should be supported now by Orange Pi 5 Android image, following this information I found that “non existing” WIFi Pcie key M modules: RTL8821CE so that is my next plan if Intel + Adapter will fail. Now I’m focused on super fast micro sd card + wifi+bt solution on pcie, but propably more people need nvme drive + usb wifi+bt.
That looks like mini-PCIe to me and not M.2. Here’s a side by side showing the pins:
You can see the difference in width here between M.2 and Mini PCIe.
This will not work for the Orange Pi 5 (it won’t fit). It requires a “custom PCB” because what they are doing is not a normal thing. The Radxa Rock 5B is actually using a E-keyed WiFi adapter but Orange Pi 5 is trying to use the M.2 M-key slot for both.
This type of card is actually what older laptops used before the M.2 standard took over. They’re bigger and wider adapters basically and M.2 E-key shrunk them down. They’re obsolete which is why they’re widely available for <$10 (on Amazon too and not just AliExpress).
The reason these are non-existing adapters is because it's actually *wrong* to make them this way (and by wrong I mean nobody else does this, we have a M.2 port for WiFi and it is the E key or A+E key). Nobody else is trying to combine these ports into one (because it's a terrible choice to have to choose between WiFi and NVMe).
That's why it requires a "custom PCB". You cannot buy a normal one and plug it in because Orange Pi 5 did not include a E-keyed M.2 port like Radxa did on the Rock 5B. On the Rock 5B you can buy a E-keyed adapter to use like this because they include 2 M.2 ports (one for WiFi and one for storage both with the correct keyed port).
I was pleasantly surprised to find out that the Rock 5B has 2 M.2 ports yesterday thanks to Razor Burn. I thought that both Radxa and Orange Pi did this but it wasn't. It's just Orange Pi that only wanted to put one port on the board and have it serve both functions. Sacrificing that E-keyed port is why you have to buy Orange Pi's "custom PCB" (unless my E-key to M-key adapter that is supposed to come today can fix this, it says "Arriving today 3:45 PM - 7:45 PM").
I'm assuming this is probably all explained by the RK3588S vs. the RK3588 on the Radxa Rock 5B. They had plenty of room on the Orange Pi 5 for another M.2 slot. Remember though, as we've talked about the RK3588 has the PCIe 3.0 interface (AND the PCIe 2.0 interface). That's why it can have both ports. It's a direct consequence of cutting to the RK3588S that they couldn't fit more PCIe / M.2 slots on the board.
It's going to be extremely difficult to split a PCIe 2.0 1x lane any further. If you can it would just be the expense of bandwidth for all the other devices as they'd be competing with each other. It's not like the PCIe 3.0 2x-4x interface where you actually do have some options to lane split there (into 1x lanes or 2x lanes etc.). Imagine if they somehow had split the PCIe 2.0 1x lane between two M.2 ports and every time your WiFi connection got really active your disk I/O would drop. Not good.
This can't have been what Orange Pi wanted as I'm sure Radxa is paying a lot less for their adapters than Orange Pi will spend for the "custom PCB" but they are competing on price and this is how they felt they had to do it (and to be fair they succeeded, it is *way* cheaper than the Rock 5B).
Hopefully that helps!
UPDATE: The adapter works. See my WiFi alternatives for the Orange Pi using a E-key to M-key adapter guide here!
Danct12
1 year ago
Nice review! Have you ever got U-Boot HDMI to work? I’ve compiled mine, but nothing shows up on the screen. I also currently don’t have any F-F UART cable, so I can’t debug it yet (just ordered one yesterday).
Hello. I think I have found the cause of the slow pcie port speed. Everything suggests that instead of using version 2.0 x1 of pcie (500 MB/s) version 1.0 x1 (250 MB/s) is being used. In the following link some users of rockpi4 manage to activate the pcie 2.0 mode, which apparently by default the u-boot compilation and the kernel uses version 1.0. My Orange pi hasn’t arrived yet and I can’t test it. Are you interested in doing the tests in case we manage to activate that 2.0 mode? Link: https://forum.manjaro.org/t/enabling-pcie-gen2-on-rockpi4-c/104671
Oh I would be delighted to! What a great find. This is exactly like the Orange Pi i96. On the Orange Pi i96 there was an issue where the one USB port the board has was stuck in “Full Speed” mode instead of “High Speed” mode (more on that at the end).
Unfortunately I don’t see any such overlay yet on the Orange Pi 5:
This seems right to me. I think this is the problem. I’m not sure there is an Orange Pi 5 overlay for this though like there is for Radxa. Interestingly I do see the new overlay to activate M.2 SATA mode (rk3588-ssd-sata.dtbo) that people were talking about yesterday here.
I think you’re absolutely on the right track though. I wonder what we would need to change in the Orange Pi 5 uboot to fix this if there’s no overlay!
I’ve seen things like this before on Orange Pi boards. My Orange Pi i96 image was born to fix an issue like this. On the Orange Pi i96 they shipped the kernel with the USB port locked to “full speed” (11Mbps) instead of high speed (480Mbps). This was a one line error in the kernel source code that I fixed (thanks also to hints and code from others too as credited in the GitHub repo, it’s a community effort) and the Orange Pi i96 image was born. I’d imagine the Orange Pi 5 needs something similar to enable PCIe 2.0 (or potentially an overlay like Radxa has)!
Owl Creek Tech
1 year ago
Here is an update on what WIFI/BT are listed in the Orange Pi Android 12 source:
I purchased a few rtl1723au from AliExpress, but keep in mind these are ONLY 150Mbps. I don’t know if the will be recognized, but for $12 it was worth the gamble. The SDIO variant is interesting since I did see a SDIO/SD to M.2 card adapter.
Everything else has a # in front of it so I think all those above ones are examples. I don’t think this necessarily means that the modules you’re getting won’t work. I’d imagine if the drivers are built into the kernel (even as M) that it should still work.
A lot of these drivers are probably in the mainline Linux kernel as well. If that’s the case we can use the orangepi-build system and actually just build a custom kernel that has the WiFi driver for the module you are getting. If you look for M.2 WiFi modules that have “mainline kernel support” these could be good options as well.
In other words even if Orange Pi didn’t build the WiFi driver into the official kernel we could easily use the orangepi-build tool to generate a custom kernel that has the WiFi drivers (as long as the adapter is in the mainline Linux kernel). A lot of people will probably have to build a custom kernel anyway for support for various other devices that won’t be included by default.
Definitely let us know what you find when the adapter comes!
Yeah I see the RTL8723au is being bundled with the board for sale on Ali and the listing says its plug & play yet comes with a separate cd so only time will tell if it works but no mention of Android support on the documentation?
Jesús Vega
1 year ago
Hello.
I have news about the next version of the OrangePi5 software and that it is now available in the Chinese language version.
The first novelty is that it is already clarified which Wifi/bluetooth adapter we can use. This is the AP6275P Pcie module. This module connects to the M2 interface.
The second novelty is that it will be possible to use SATA disks with an M2 interface. We already had the option of connecting an NVME M2 drive. Now we can also use SATA M2 drives such as 2242 and 2280 although the latter are quite large and will exceed the SBC.
We also have new version of u-boot for the SPI
Flash.
Hopefully the new version of u-boot will solve the boot of usb-A 3.0 and usb-c 3.1.
Excellent, thanks for the translation! That’s actually very interesting that they are adding SATA support for their M.2 interface. Most devices I’ve seen in the past it has been one or the other!
I think you’re right on the money about the u-boot issues. I’ve done some work before and made my own custom Orange Pi i96 image that is pretty popular using this Orange Pi build tool and the source from it.
When I originally encountered the boot problem when we were initially testing the different ports I speculated that it probably needs some sort of uboot modification. It probably needs either a driver for those USB interfaces within uboot (so it can see the files) or perhaps there’s a list of places it checks it needs to be added to. This is definitely something that should be fixed by Orange Pi and I’m certain I could probably figure out how to fix it like I did with a lot of my i96 fixes if I absolutely had to.
I’m leaning toward the uboot probably isn’t being built with the USB-C driver for sure. The white USB port is a bit more of a mystery. That port might actually have a different interface as well (if it’s actually USB 2.0 instead of USB 2.1 like the bottom blue USB port is). I should probably pull the code as well and take a look. I’ve looked through Orange Pi’s uboot systems before (and even fixed/modified issues like this on the i96) so I have some familiarity with it.
Fortunately unlike the Orange Pi i96 the Orange Pi 5 is still within it’s support period! That means we can reasonably expect / ask Orange Pi to fix this issue for sure. I learned a lot about the i96 doing exactly what you are doing by going through the code (and the changelogs). Thanks so much for sharing this!
Hola.
Ya están disponibles versiones de ARMBIAN OS para Orangepi 5.
También tiene opción de instalar drivers gráficos 3D.
A ver si hay diferencia de rendimiento.
Saludos
Thanks for sharing this update as I saw one quick video today with it running from sd card and it looks really polished.
The ARMBIAN team have done an outstanding job in such a short time and having gpu acceleration drivers ready to install is fantastic as I was expecting it to take months unless you’re savvy enough to work it out yourself!
Hello everyone. I keep looking for solutions at pcie speed. I have found a bash script to change the speed of a pcie port. Let’s see if it works…
Hey Jesús Vega,
Welcome back! So I don’t have good news about this:
root@orangepi5:~# ./test.sh 0004:40:00.0Link capabilities: 00726812
Max link speed: 2
Link status: f012
Current link speed: 2
Configuring 0004:40:00.0...
Original link control 2: 00000002
Original link target speed: 2
New target link speed: 2
New link control 2: 00000002
Triggering link retraining...
Original link control: f0120042
New link control: f0120062
Link status: 7012
Current link speed: 2
root@orangepi5:~# ./test.sh 0004:41:00.0
Link capabilities: 00726812
Max link speed: 2
Link status: 7012
Current link speed: 2
Configuring 0004:40:00.0...
Original link control 2: 00000002
Original link target speed: 2
New target link speed: 2
New link control 2: 00000002
Triggering link retraining...
Original link control: 70120042
New link control: 70120062
Link status: 7012
Current link speed: 2
That doesn’t look like it did much for me. It’s saying this PCIe interface is already set to PCIe 2.0.
This might not be fixable. It might just be a really poorly performing PCIe interface unfortunately. That’s very unfortunate! I cannot recommend the Rock 5B any higher if you need really fast NVMe as that board is actually hitting PCIe 2.0 speeds (and no one can with this one).
I think the issue is we got the RK3588S and this is probably all it can do. The Radxa Rock 5B has the real RK3588 and it shows. The Radxa Rock Pi 4C+ has the RK3399T which also has a faster PCIe interface than the RK3588S.
I don’t think we’ve really tested the RK3588S PCIe interface speed before (at least I don’t have this CPU on another board). This board is down thousands of points from the Rock Pi 4B, Rock Pi 4C, Radxa Rock 5B, and even the Compute Module 4.
I hate to say it but you are better off with just about any other PCIe interface than what we got on this device. You’d be better off with a Pi CM4 or just about any modern Radxa board it looks like if you want PCIe 2.0 speeds (or potentially higher for the Rock 5B). How much better? You’ll get 26,000-30,000 instead of 21,000 so it’s underperforming by roughly 25% from other boards that have PCIe 2.0.
This board does not qualify as PCIe 2.0 speeds but it looks like it’s not going to be an easy answer like an overlay. This might be all it can do. I consider this a pretty disastrous result and my hope that this will be fixed/changed has dropped 90%. I wish I had another board with the RK3588S in it so we could test if this is just the best the RK3588S can do or if Orange Pi still has something wrong in their kernel/code/configuration.
I’ve never tested a slower one. The Pi CM4 is faster and all the Radxa boards are faster. Boards that came out years ago (and are *definitively actually PCIe 2.0*) beat it. It’s pretty poor PCIe performance to put it mildly.
It looks like the answer was the more cynical one I was debating with someone earlier here in the comments. It might be a PCIe 2.0 interface but it might as well be a PCIe 1.0 interface because that is how it’s performing. The Radxa Rock 4B+ is curb stomping it with 26k+ scores and that model came out in spring of 2021! 6 core CPUs like the RK3399T are curb stomping it. This should not be happening on a board so much more obviously powerful than those old ones. What in the hell did they do to get the PCIe interface so *bad*?
The whole point of the RK3588S existing was to cut the PCIe 3.0 interface from the RK3588. That is almost the entire difference between the two other than a couple of mild I/O port count changes and it makes almost a $30-$40 price difference (best we can tell from the differences in prices between the boards that have the real RK3588 and the ones that don’t). And boy did they cut it well. Too well.
That’s why my hopes are fading for this at least. We have a version of the RK3588 that has fast PCIe. This is the version that doesn’t and it’s the only reason the board is <$100. It turns out though that if NVMe is what you wanted to do then you would have been much better off paying the 30-40% more. You want the RK3588 for that! It does make me frustrated though that after more than 2 years we can't beat the Raspberry Pi CM4 with any of these boards. I was covering the CM4 back in like 2020. The CM4's PCIe 2.0 interface is in a whole different league from the one on this device. So is the one on the Radxa boards and the real RK3588. Even the real RK3588 isn't beating the CM4 so far in the PCIe benchmarks let alone this one! The CM4 continues to absolutely wipe the floor with the supposedly PCIe 2.0 interfaces on these devices and I have been waiting for YEARS for someone to knock them off the top. Maybe this is the missing piece for people about why this is such a disappointing result to me. I was doing better than this years ago on the CM4. I have other Radxa boards that do better than this that are 1-2 years old. It's absolutely indefensible. I want someone to make a board that can outperform the CM4's PCIe 2.0 interface which should be *easy*. The CM4 was originally supposed to cost like $15-$20 and they can't outperform this with $100+ SoCs? 2 years later? I really thought this board was going to be the one that would finally dethrone the CM4. It sure looks like it should on paper. I would have guaranteed from the spec sheets that this device should beat the CM4's I/O scores. It's not even close though. We're like 25% off. It will be the Orange Pi 7 that will beat the CM4's IO scores at this rate. 25% seems 1-2 generations behind to me. Radxa will probably catch up next generation it looks like but Radxa is at least putting out PCIe 2.0 scores even though they're not beating the CM4 still. I suppose that's the story of this article so far. The spec sheets for this device will lead you to very dubious conclusions about performance here. If the spec sheets are to be believed this device should *smoke* the CM4 on I/O performance. Everything is there. The PCIe 2.0 interface. The faster CPU/GPU/SoC. More memory. It *looks* great! According to the spec sheet it's better than the CM4 in every way. In reality it gets curb stomped. They're not in the same league. It's multiple generations away from challenging it and they're even a generation behind their *other* competition! That's why I think it was such a bad choice to cut to the RK3588S. I would have raised the price instead because then we're at least getting in the neighborhood of CM4 PCIe performance. They would have only been one generation behind (which is a position it looks like Radxa will enjoy this generation) instead of 2. Raspberry Pi doesn't have anything to ship so this would have been the time to try to put the real deal CPUs in your boards and not these cost-cutting variants. Saving the extra money probably isn't helping them very much right now because nobody can get their main competitor's boards anyway. They had a shot here to put up some serious firepower and they still went for the cheap cost-cutting variant. Who is smarter, Radxa or Orange Pi? Radxa went for the expensive one this generation and Orange Pi went with the cheap version (but that is kind of their thing). I don't know the answer but I would give the edge to Radxa. I think this was the time to ship the real deal this generation with Raspberry Pi being in the state it is. Orange Pi is still operating like they're trying to compete against a $60 Raspberry Pi 4. That's not a thing that people have really been able to buy at that price for a long time. I really don't think Orange Pi needs to be so aggressive on pricing in this market but they're operating the same way they always have (and they may be right, they've made it this far). Time will tell! If the Orange Pi 5 wasn't meant to be a value-based board I would absolutely destroy it. If it is meant to be a high performance PCIe 2.0 board it's among the worst (actually it is the worst for PCIe performance). If it's meant to be a value board though it's honestly the best value board I see out there right now. It's in the unique position of being among the worst I/O performers but the best value / bang for the buck! The Radxa Rock 5B might have a better PCIe interface but it starts at like $140 which is roughly 50% more expensive than the Orange Pi 5 (at least what I paid on Amazon). If you don't need NVMe it's a no brainer to pick the Orange Pi 5 over the Rock 5B since you will get the exact same CPU performance with the Orange Pi 5 but with a slow PCIe interface. Thank you Jesús Vega for continuing to investigate this. Just to be clear I do not know why it is performing so poorly. Linux says it is running in PCIe 2.0 mode. I just know that it is. I know that it's not performing as well as Radxa boards or as well as the CM4. There's no question about that. What I don't know is if there's any way to fix/improve it so thank you for continuing your investigation!
UPDATE: I did some more digging based on what I found from trying to run the script you shared. The interface definitely *is* PCIe 2.0 like the script said:
root@orangepi5:/sys/firmware/devicetree/base# lspci -vv | grep -E 'PCI bridge|LnkCap'0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3588 (rev 01) (prog-if 00 [Normal decode])
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1, Exit Latency L1 <16us
LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS-
LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L1 <8us
LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 2Retimers- DRS-
2.5GT/s is PCIe 1.0, 5GT/s is PCIe 2.0. The interface says it's running at 5GT/s. That means the question now becomes:
Why is it performing so slowly? Why is it slower than the CM4's PCIe 2.0 interface, or the Rock 4B/4C? Is it because it's only a single PCIe lane? But so are a lot of these other boards that are stomping it according to their spec sheets. It's performing so much worse than the others and it's not clear to me why still!
I guess that leaves some hope that this is some kind of bug / mistake still. It should be performing better than this! It's literally so bad that it took me weeks to even accept it is PCIe 2.0 because something is *wrong* here.
The numbers don't add up. Boards from 1-2 generations ago are beating it by 25%-33%+ that shouldn't be if we're going by the specification sheets and all logical reason. This is an 8 core board getting stomped by the quad-core CM4 and last-gen 6 core Radxa Rock Pi 4/4B/4C boards with supposedly identical PCIe versions. There is nothing equal about the PCIe performance between these devices. It's been a confusing / harrowing process to even determine the version because the speeds are screaming PCIe 1.0 and look nothing like the performance on other similar (and older) models with supposedly identical versions.
In other words it's not that it's failing to live up to my expectations that it's the fastest board for I/O performance ever released that is driving me crazy. That would be a "me" problem. It's how much worse it performs to similar boards with the exact same capabilities. It doesn't make sense for last-gen (and current gen) Radxa budget models (which are also the versions that were cut to not have PCIe 3.0 to drop the price) to be beating the shiny newer RK3588S (and not by a little either).
EUREKA! I tried something new. I went into orangepi-config with:
sudo orangepi-configI then chose System->Firmware and chose to update the board firmware. I had not done this since I got the board so the firmware had never been updated.
After letting it update and rebooting:
Category Test ResultHDParm Disk Read 380.15 MB/s
HDParm Cached Disk Read 370.00 MB/s
DD Disk Write 263 MB/s
FIO 4k random read 61134 IOPS (244537 KB/s)
FIO 4k random write 37101 IOPS (148405 KB/s)
IOZone 4k read 76599 KB/s
IOZone 4k write 68684 KB/s
IOZone 4k random read 37015 KB/s
IOZone 4k random write 71836 KB/s
Score: 18965
Nice, that’s actually a marginal improvement and I broke 250 (slightly)! I’d say it’s probably worth updating the system firmware on it.
Outstanding work there James as who knows how many others neglected to upgrade the firmware and who knows you might uncover something that’s hidden to get even better speeds.
I see some people mentioning seeing a wifi + bt usb dongle being sold as part of a Orange Pi 5 bundle on aliexpress and I believe the dongle uses one of the hashed out chipsets from wifi bt config (RTL8723BU) so that might be the one that’s included in those amazon bundles and its supposedly plug & play…? I have one on order and will do some testing once it arrives and its available cheaper from aliexpress or ebay AUS but I suspect they’re sourcing it from China themselves LOL.
Keep up the great work!
Hey Razor Burn,
Yes, I actually saw those as well. It’s the only place I had seen it offered for sale. If anyone has one of these (even if it’s a non-official one) definitely share a picture or something with us, I still can’t find one!
Good news James [applause]. With what we have already found out, we have seen where improvements in speed can come from. We must insist to the firmware developers. For now, we will have to identify the parts of the source code and compare with other developments. I don’t lose hope of reaching 400MB/s hahaha. My shipment is running late and my orangepi5 still hasn’t arrived. Regarding the android image, what is the nvme speed? Greetings.
Hey Jesús Vega,
Thank you, I actually couldn’t believe this made a difference! It did though. Probably something like 5-10% which is huge. It means exactly what you say.
I haven’t tried with Android yet. I wonder how hard it will be to image it for Android using NVMe and if my cloning trick will work. Android likes to be “flashed” with those awful programs like PhoenixFlash a lot of the time and never just lets you write a normal image.
I’ll give this a try today and see if I can get an Android benchmark!
Hi guys,
I have nvme running android 12 rooted (using magisk) , and BusyBox installed. I want to help, but I don’t know what commands (programs) to run?
Hey KhanhDTP,
I tried this with Busybox’s built in dd and it doesn’t look like that one gives you a speed result:
/dev/shm # dd if=/dev/zero of=test bs=4096 count=140k conv=fsync10240+0 records in
10240+0 records out
Can you install fio or iozone? It looks like it’s possible to do iozone but it’s going to be quite a few steps. When I googled “fio for Android” I did see some possible ports of fio for Android. Either one of those ones would be able to benchmark it as well!
I’m not sure what the best Android specific benchmarks you could run would be. It doesn’t seem like anyone has made anything like my Linux pibenchmarks.com script. It looks like there’s a PCMark one maybe. I should probably make a version of my benchmark for Android eventually!
Hi James,
> It looks like it’s possible to do iozone but it’s going to be quite a few steps.
Yeah, it looks like out of my capability.
I found this app: CPDT Benchmark – Storage, memory (pretty high ranked)
But, I am not sure if its results should be trusted (“apple to apple” comparative).
Hey KhanhDTP,
Yes I did see that one in some of my searches looking to see if any obvious ones popped out. I would say it’s worth giving it a try.
You’re definitely right that it’s not an apples to apples comparison but we will keep that in mind. It should still give you a read / write score and I would say to give it a try and we’ll compare it (and if anything is really far off we could investigate further).
I think this would be a great start though! I’d say run it and whatever scores / results it gives let’s just take a look at them together. If it says anything wild like it’s getting 500MB/s write then I could absolutely put Android on mine and do some further testing but I think this is a valid starting point for sure.
Hi James!
I have run your command
:/data/data/com.termux/files/home # dd if=/dev/zero of=test bs=4096 count=140k conv=fsyncconv=1
143360+0 records in
143360+0 records out
587202560 bytes (560 M) copied, 2.197941 s, 255 M/s
:/data/data/com.termux/files/home # hdparm -tT /dev/block/nvme0n1/dev/block/nvme0n1:
Timing buffer-cache reads: hdparm: HDIO_DRIVE_CMD: Not a typewriter
4932 MB in 0.50 seconds = 9910902 kB/s
Timing buffered disk reads: 1210 MB in 3.00 seconds = 412848 kB/s
hdparm: HDIO_DRIVE_CMD: Not a typewriter
I hope it will help?
Hey KhanhDTP,
Excellent, that does help! You are actually right where mine is. My last testing I was at 260MB/s with the latest firmware updates so you’re really close. I imagine if you ran it several more times you’d probably be able to hit numbers like 260 since there’s some minor variation between runs.
I think this does help answer the question some people had about how the disk performs in Android. According to your benchmarking it’s exactly the same. This is a good thing in my opinion as we’re not really seeing a huge difference in disk performance between Android and Linux. That means people should be able to run Linux or Android without worrying that they’re sacrificing any disk performance choosing one or the other.
I love the weird busybox hdparm warning it threw of:
hdparm: HDIO_DRIVE_CMD: Not a typewriterHdparm has apparently been able to determine that your disk is in fact not a typewriter. Outstanding! Just some kind of funny old legacy code in there I’m sure but I got a kick out of it. The numbers are looking good though for hdparm as well.
Thank you so much for sharing this!
Yes, I ran it several times.
. A few times was around 243MB/s~246MB/s.
. A few times was reached 260MB/s.
. And, many other times was around 255MB/s~257MB/s.
You know, what is weirder?
I tried this app to run Linux (on android)
and used the same dd command as above.
Many times it reached 280MB/s.
Hey KhanhDTP,
Oh my! I’m guessing this can be explained by differences in the dd version between busybox’s dd command and the one that comes with most modern Linux distributions.
You can tell they are different because the busybox one gives you that weird typewriter warning. I’ve actually never seen that before in my life running dd but it must be a thing in some versions of busybox.
One thing you may want to try is do:
dd --versionI think you’ll find they are probably different versions (maybe substantially). I think that would be the place to start before going any further. Let’s look at the version differences between the two!
Hello.
I just read an article by nvidea on calculating pcie bandwidth for versions 1.0, 2.0 and 3.0. For versions 1.0 and 2.0 it tells you that 20% of the transmission is header overhead.
Also around 1Gb/s is lost in communication errors. If we take this to obtain the bandwidth of pcie 2.0 it would be: 5 Gb/s * (1-1/5) – 1 Gb/s =
3 Gb/s = 375 MB/s.
What do you think about this article?
Hey Jesús Vega,
For sure this has to be part of the equation. This is true of all devices using PCIe so the tricky thing is still why does the Rock Pi 4C or the Pi CM4 still score something like 15-20%+ higher (even with the firmware updates)?
Those devices have to have the exact same PCIe overhead since that’s just a natural consequence of using the technology and expected. In other words we should see the same slowdown on those devices due to the overhead. There seems to be some kind of additional bottleneck here but the answer likely is in fact in the firmware (or possibly the kernel if it’s hardcoded like older Orange Pi boards such as the i96).
The good news is the gap has closed a lot. After firmware updates it’s starting to get performance more similar to the ODROID M1 which also disappointed me to be honest (because it also can’t compete with the CM4 for as of yet still unexplained reasons/bottlenecks despite being more powerful in paper in literally every way). It’s at least within the ballpark though of underperforming PCIe 2.0 devices instead of straight up PCIe 1.0 speeds!
I’ve actually updated the article today and added a note that I was able to achieve (low but still) PCIe 2.0 performance (about 260MB/s and I got one as high as 280MB/s) by updating the system firmware through sudo orangepi-config and then choosing System->Firmware and then updating the system’s firmware. I highly recommend updating (both the firmware and also the software through sudo apt update && sudo apt full-upgrade -y) when it does arrive as one of the first things you do!
I asked Shenzhen XiaoTuDou Technology Store “Could you please explain, where to buy that “Wi-Fi6+BT 5.0 custom module M.2 M-KEY ?” Answer: “We will issue the WIFI+BT module.”
Hey Marcus,
I see! That’s kind of a funny answer. I wish they would have elaborated and said maybe weeks, months, etc. but it’s definitely better than nothing!
I’ve tried searching Amazon for M.2 WiFi adapters and to be honest with you most of them I see are meant for Windows notebooks and tablets. Those types of machines have been using WiFi cards like this for a long time. This is what is making it harder to find one.
There hasn’t really been a lot of reason to use these in Linux so far but surely there are some tablets out there that have been released that use these that have Linux support. We just need to figure out what those are.
If anyone has a tablet or laptop that has one of these M.2 WiFi cards and you know it can run Linux that would be a really good place to start to see if we can plug and play it with the Orange Pi 5 or if we can rebuild the Orange Pi 5 kernel and add support for one. These type of M.2 WiFi cards have been around long enough that some of these have to be in the mainline Linux kernel by now.
It’s just not really obvious which ones those are but if people have access at work to a lot of laptops / tablets like I used to when I was a hardware tech I bet I could have found one of these inside a laptop/tablet model that would be capable of running Linux (and thus has a high chance that the card might be available in the mainline Linux kernel). Dell and HP both have models that support Linux for sure and that’s exactly the kind of place I’d expect to see of one these like Amazon is showing on page 1,2,3, etc.
I think the enterprise ones are probably the most likely ones to be mainlined because although the number of models with Linux support from places like HP and Dell aren’t a huge % of their models the ones that do have it tend to be *very* well supported. This is because HP and Dell have teams (and the money / resources) to actually submit these devices and get them into the mainline Linux kernel. If they’re putting that hardware in their Linux supported models there’s a really good chance it’s either because it’s already mainlined or it’s one that HP/Dell/whoever wanted to put the resources behind getting it mainlined.
Hopefully it won’t be too much longer before the official release/listing of these individually for sale, thanks for sharing!
EDIT: I tried some of these I had around the house and none of them fit. This seems obvious in retrospect but as a hardware technician I had never actually tried putting a M.2 WiFi module into the storage M.2 slot (because that’s not where it goes, I would have put it where the chip I was replacing was). It turns out most of the WiFi adapters in the tablets/notebooks are typically “E” keyed (and sometimes A+E keyed). Perhaps this is what they mean by the “custom PCB” part. These definitely do exist though like here. I’ll keep looking and see if I can find one that will fit into the Orange Pi’s slot.
There’s also special adapters that can let you use a E-key WiFi adapter with a normal M-key slot. Take a look at this one:
This would work theoretically. This specific adapter is $17-$18 which makes it quite a nasty additional cost to also needing a E-key WiFi adapter on top of that. Unless you already have one/some of these like I do it’s probably prohibitively expensive (at least considering that I can’t imagine Orange Pi will charge much more than $17 for their entire working module when it’s released and frankly hopefully it’s less than that). It is theoretically possible to do this though.
I ordered one and it says it’s going to come on the 3rd of January. Even if it doesn’t work for this purpose the adapter should be useful in my toolkit for weird future blog experiments (I love having weird adapters like this around). I’ll definitely update though and let you guys know if this adapter idea lets me actually utilize some of these almost certainly mainlined E-keyed WiFi chips.
I suspect they meant the wifi+bt 4.0 usb dongle that they’re adding to their bundles on aliexpress but hope to be proved wrong!?
Hello, I should have my OP5 in few days. I have that mentioned E-key WiFi adapter already and I plan to test that with Intel 9560NGW WiFi ac+BT card. That chip is supported by linux kernel since 4.14 so maybe there is some hope with Android. Anyway I found some more info from reddit.
RTL8821CU, RTL8723BU, RTL8811CU should be supported now by Orange Pi 5 Android image, following this information I found that “non existing” WIFi Pcie key M modules: RTL8821CE so that is my next plan if Intel + Adapter will fail. Now I’m focused on super fast micro sd card + wifi+bt solution on pcie, but propably more people need nvme drive + usb wifi+bt.
Hey Marcus,
That looks like mini-PCIe to me and not M.2. Here’s a side by side showing the pins:
You can see the difference in width here between M.2 and Mini PCIe.
This will not work for the Orange Pi 5 (it won’t fit). It requires a “custom PCB” because what they are doing is not a normal thing. The Radxa Rock 5B is actually using a E-keyed WiFi adapter but Orange Pi 5 is trying to use the M.2 M-key slot for both.
This type of card is actually what older laptops used before the M.2 standard took over. They’re bigger and wider adapters basically and M.2 E-key shrunk them down. They’re obsolete which is why they’re widely available for <$10 (on Amazon too and not just AliExpress). The reason these are non-existing adapters is because it's actually *wrong* to make them this way (and by wrong I mean nobody else does this, we have a M.2 port for WiFi and it is the E key or A+E key). Nobody else is trying to combine these ports into one (because it's a terrible choice to have to choose between WiFi and NVMe). That's why it requires a "custom PCB". You cannot buy a normal one and plug it in because Orange Pi 5 did not include a E-keyed M.2 port like Radxa did on the Rock 5B. On the Rock 5B you can buy a E-keyed adapter to use like this because they include 2 M.2 ports (one for WiFi and one for storage both with the correct keyed port). I was pleasantly surprised to find out that the Rock 5B has 2 M.2 ports yesterday thanks to Razor Burn. I thought that both Radxa and Orange Pi did this but it wasn't. It's just Orange Pi that only wanted to put one port on the board and have it serve both functions. Sacrificing that E-keyed port is why you have to buy Orange Pi's "custom PCB" (unless my E-key to M-key adapter that is supposed to come today can fix this, it says "Arriving today 3:45 PM - 7:45 PM"). I'm assuming this is probably all explained by the RK3588S vs. the RK3588 on the Radxa Rock 5B. They had plenty of room on the Orange Pi 5 for another M.2 slot. Remember though, as we've talked about the RK3588 has the PCIe 3.0 interface (AND the PCIe 2.0 interface). That's why it can have both ports. It's a direct consequence of cutting to the RK3588S that they couldn't fit more PCIe / M.2 slots on the board. It's going to be extremely difficult to split a PCIe 2.0 1x lane any further. If you can it would just be the expense of bandwidth for all the other devices as they'd be competing with each other. It's not like the PCIe 3.0 2x-4x interface where you actually do have some options to lane split there (into 1x lanes or 2x lanes etc.). Imagine if they somehow had split the PCIe 2.0 1x lane between two M.2 ports and every time your WiFi connection got really active your disk I/O would drop. Not good. This can't have been what Orange Pi wanted as I'm sure Radxa is paying a lot less for their adapters than Orange Pi will spend for the "custom PCB" but they are competing on price and this is how they felt they had to do it (and to be fair they succeeded, it is *way* cheaper than the Rock 5B). Hopefully that helps! UPDATE: The adapter works. See my WiFi alternatives for the Orange Pi using a E-key to M-key adapter guide here!
Nice review! Have you ever got U-Boot HDMI to work? I’ve compiled mine, but nothing shows up on the screen. I also currently don’t have any F-F UART cable, so I can’t debug it yet (just ordered one yesterday).
Hey Danct12,
Have you done a make menuconfig with uboot and enabled the options like this? I haven’t tried this yet but that’s typically how you would turn it on for Allwinner boards.
Hopefully that helps!
Hello. I think I have found the cause of the slow pcie port speed. Everything suggests that instead of using version 2.0 x1 of pcie (500 MB/s) version 1.0 x1 (250 MB/s) is being used. In the following link some users of rockpi4 manage to activate the pcie 2.0 mode, which apparently by default the u-boot compilation and the kernel uses version 1.0. My Orange pi hasn’t arrived yet and I can’t test it. Are you interested in doing the tests in case we manage to activate that 2.0 mode? Link: https://forum.manjaro.org/t/enabling-pcie-gen2-on-rockpi4-c/104671
Hey Jesús Vega,
Oh I would be delighted to! What a great find. This is exactly like the Orange Pi i96. On the Orange Pi i96 there was an issue where the one USB port the board has was stuck in “Full Speed” mode instead of “High Speed” mode (more on that at the end).
Unfortunately I don’t see any such overlay yet on the Orange Pi 5:
root@orangepi5:/boot/dtb/rockchip/overlay# lsREADME.rockchip-overlays rk3588-i2c1-m2.dtbo rk3588-lcd1.dtbo rk3588-ov13850-c3.dtbo rk3588-pwm15-m2.dtbo rk3588-pwm3-m2.dtbo rk3588-uart1-m1.dtbo
rk3588-can1-m1.dtbo rk3588-i2c1-m4.dtbo rk3588-lcd2.dtbo rk3588-pwm0-m1.dtbo rk3588-pwm1-m1.dtbo rk3588-spi4-m0-cs1-spidev.dtbo rk3588-uart3-m0.dtbo
rk3588-can2-m1.dtbo rk3588-i2c3-m0.dtbo rk3588-ov13850-c1.dtbo rk3588-pwm13-m2.dtbo rk3588-pwm1-m2.dtbo rk3588-ssd-sata.dtbo rk3588-uart4-m0.dtbo
rk3588-fixup.scr rk3588-i2c5-m3.dtbo rk3588-ov13850-c2.dtbo rk3588-pwm14-m1.dtbo rk3588-pwm3-m0.dtbo rk3588-uart0-m2.dtbo rk3588-wifi-ap6275p.dtbo
This seems right to me. I think this is the problem. I’m not sure there is an Orange Pi 5 overlay for this though like there is for Radxa. Interestingly I do see the new overlay to activate M.2 SATA mode (rk3588-ssd-sata.dtbo) that people were talking about yesterday here.
I think you’re absolutely on the right track though. I wonder what we would need to change in the Orange Pi 5 uboot to fix this if there’s no overlay!
I’ve seen things like this before on Orange Pi boards. My Orange Pi i96 image was born to fix an issue like this. On the Orange Pi i96 they shipped the kernel with the USB port locked to “full speed” (11Mbps) instead of high speed (480Mbps). This was a one line error in the kernel source code that I fixed (thanks also to hints and code from others too as credited in the GitHub repo, it’s a community effort) and the Orange Pi i96 image was born. I’d imagine the Orange Pi 5 needs something similar to enable PCIe 2.0 (or potentially an overlay like Radxa has)!
Here is an update on what WIFI/BT are listed in the Orange Pi Android 12 source:
## wifi bt config
#
#
# BOARD_CONNECTIVITY_VENDOR:
# for broadcom, realteck wifi, bt
# Broadcom:
# rk90x,
# ap6xxx,
# ap6xxx_gps, #like ap6476
# ap6xxx_nfc, #like ap6441 & ap6493
#
# for mtk wifi, bt
# MediaTek:
# combo_mt66xx,
# mt5931_6622,
#
# for realtek wifi, bt & rda587x bt
# RealTek:
#
# rtl81xx, #only wifi
# rtl8723as, #like rtl8723as sdio
# rtl8723bs, #like rtl8723bs sdio
# rtl8723au, #like rtl8723au usb
# rtl8723bu, #like rtl8723bu usb
# rda587x, #like rtl8188+rda587x
# mt6622, #like rtl8188+mt6622
#
# for Espressif wifi & Beken bt
# Espressif:
# esp8089_bk3515,
# esp8089, #only wifi
# mt6622, #like esp8089+mt6622
# rda587x, #like esp8089+rda587x
#
# MediaTek_mt7601:
# mt7601 #only wifi
# rda587x, #like rtl8188+rda587x
# mt6622, #like rtl8188+mt6622
#
BOARD_CONNECTIVITY_VENDOR := Broadcom
BOARD_CONNECTIVITY_MODULE := ap6xxx
I purchased a few rtl1723au from AliExpress, but keep in mind these are ONLY 150Mbps. I don’t know if the will be recognized, but for $12 it was worth the gamble. The SDIO variant is interesting since I did see a SDIO/SD to M.2 card adapter.
Hey Owl Creek Tech,
Very interesting! So the only concern is that in the code you posted here I only see the following 2 lines uncommented:
BOARD_CONNECTIVITY_VENDOR := BroadcomBOARD_CONNECTIVITY_MODULE := ap6xxx
Everything else has a # in front of it so I think all those above ones are examples. I don’t think this necessarily means that the modules you’re getting won’t work. I’d imagine if the drivers are built into the kernel (even as M) that it should still work.
A lot of these drivers are probably in the mainline Linux kernel as well. If that’s the case we can use the orangepi-build system and actually just build a custom kernel that has the WiFi driver for the module you are getting. If you look for M.2 WiFi modules that have “mainline kernel support” these could be good options as well.
In other words even if Orange Pi didn’t build the WiFi driver into the official kernel we could easily use the orangepi-build tool to generate a custom kernel that has the WiFi drivers (as long as the adapter is in the mainline Linux kernel). A lot of people will probably have to build a custom kernel anyway for support for various other devices that won’t be included by default.
Definitely let us know what you find when the adapter comes!
According to a github posting it appears the same setup as Khadas android_device_rockchip_rk3288/wifi_bt.mk
## wifi bt config
#
#
# BOARD_CONNECTIVITY_VENDOR:
# for broadcom, realteck wifi, bt
# Broadcom:
# rk90x,
# ap6xxx,
# ap6xxx_gps, #like ap6476
# ap6xxx_nfc, #like ap6441 & ap6493
#
# for mtk wifi, bt
# MediaTek:
# combo_mt66xx,
# mt5931_6622,
#
# for realtek wifi, bt & rda587x bt
# RealTek:
#
# rtl81xx, #only wifi
# rtl8723as, #like rtl8723as sdio
# rtl8723bs, #like rtl8723bs sdio
# rtl8723au, #like rtl8723au usb
# rtl8723bu, #like rtl8723bu usb
# rda587x, #like rtl8188+rda587x
# mt6622, #like rtl8188+mt6622
#
# for Espressif wifi & Beken bt
# Espressif:
# esp8089_bk3515,
# esp8089, #only wifi
# mt6622, #like esp8089+mt6622
# rda587x, #like esp8089+rda587x
#
# MediaTek_mt7601:
# mt7601 #only wifi
# rda587x, #like rtl8188+rda587x
# mt6622, #like rtl8188+mt6622
#
BOARD_CONNECTIVITY_VENDOR := Broadcom
BOARD_CONNECTIVITY_MODULE := ap6xxx
GitHub Link
Yeah I see the RTL8723au is being bundled with the board for sale on Ali and the listing says its plug & play yet comes with a separate cd so only time will tell if it works but no mention of Android support on the documentation?
Hello.
I have news about the next version of the OrangePi5 software and that it is now available in the Chinese language version.
The first novelty is that it is already clarified which Wifi/bluetooth adapter we can use. This is the AP6275P Pcie module. This module connects to the M2 interface.
The second novelty is that it will be possible to use SATA disks with an M2 interface. We already had the option of connecting an NVME M2 drive. Now we can also use SATA M2 drives such as 2242 and 2280 although the latter are quite large and will exceed the SBC.
We also have new version of u-boot for the SPI
Flash.
Hopefully the new version of u-boot will solve the boot of usb-A 3.0 and usb-c 3.1.
Greetings.
Hey Jesús Vega,
Excellent, thanks for the translation! That’s actually very interesting that they are adding SATA support for their M.2 interface. Most devices I’ve seen in the past it has been one or the other!
I think you’re right on the money about the u-boot issues. I’ve done some work before and made my own custom Orange Pi i96 image that is pretty popular using this Orange Pi build tool and the source from it.
When I originally encountered the boot problem when we were initially testing the different ports I speculated that it probably needs some sort of uboot modification. It probably needs either a driver for those USB interfaces within uboot (so it can see the files) or perhaps there’s a list of places it checks it needs to be added to. This is definitely something that should be fixed by Orange Pi and I’m certain I could probably figure out how to fix it like I did with a lot of my i96 fixes if I absolutely had to.
I’m leaning toward the uboot probably isn’t being built with the USB-C driver for sure. The white USB port is a bit more of a mystery. That port might actually have a different interface as well (if it’s actually USB 2.0 instead of USB 2.1 like the bottom blue USB port is). I should probably pull the code as well and take a look. I’ve looked through Orange Pi’s uboot systems before (and even fixed/modified issues like this on the i96) so I have some familiarity with it.
Fortunately unlike the Orange Pi i96 the Orange Pi 5 is still within it’s support period! That means we can reasonably expect / ask Orange Pi to fix this issue for sure. I learned a lot about the i96 doing exactly what you are doing by going through the code (and the changelogs). Thanks so much for sharing this!
Sadly, that would make sense since the Android 12 does identify the ‘ap6xxx’ as build default.