For coupon in Jan, it’s the first batch, so don’t worry
ROCK 5B Debug Party Invitation
Don’t get me wrong - I was just curious if You tried to put there 32GB. In fact both firefly and mixtile teams are advertising 32GB version and nobody is selling it - firefly have note that it’s on special request only (probably way to expensive) and mixtile announced that because of chip shortage this one will be ready at the end of year (also at unknown price but they asked recently how much clients are willing to pay).
Do I need 32GB? Probably not for single service or desktop usage, when You are doing one thing at time and have much more expensive workstation/laptop with huge, fast memory. For clusters it’s the matter of resources and services, some just needs more memory and its easy to scale in k8s. Also proxmox is coming to ARM and those are resource hungry too. For me 16GB is optimal and I would probably buy just another and cluster them together to get more CPU and io
More RAM may be needed in AI and newest nvidia orin comes with up to 64GB RAM and 275T (it’s available to buy, but I’m waiting for $900 version with 32GB/200T). Of course it’s different price range and much more power than 6T of RK3588, but probably best TDP and dimensions. I think RK3588 will stay with us for some time so it’s still big jump from RK3399 with max 4GB of RAM
I completely agree - for now it’s just expensive memory chip. I just was curious if there were any attempts on this capacity or if it’s currently just not possible. As Jack said nobody is selling that option now, but this may change when memory chip prices will go down and there will be more memory hungry applications
My memory of my foggy brain has a hazy memory that SODIMMs are a bit awkward to use as you need to read the eeprom conf to initialise which is a whole load of dev work.
Pretty sure I read a suggestion that a hybrid arrangement is much easier where if you have a single fixed ram chip to boot with additional sodimm is much easier to initialise.
Dunno how true that is but that would be so much more flexible, maybe even easier to accommodate on board, but yeah ram as ARM socs get ever more powerful could see need for more ram.
The economies of sale that Micron are selling there ram chips for is obviously much more than Radxa’s purchase power and maybe that could be a future solution?
I guess you have a few problems with fixed chips, initial cost, board space and stock that may not sell.
It would be interesting what the Rcode results gave Radxa as I would guess 8gb would be the most popular for a SoC that is quite a big step up from a Pi4, but maybe the spread was more even from 4gb to 16gb.
Also when it comes to curiosity what is the speed difference of dedicated eMMC to SD adapter mounted eMMC as just wondering if more universal use could help as that also seems to suffer from economies of sale when compared to mass produced NVME.
3月份的优惠卷,大概排多久呢:咧着嘴笑:
I think in August we can ship the first batch of order.
Once the EU distributor surfaces, will it be possible to get our hands on coupons here in Europe as well? And/or will coupons acquired elsewhere accepted by said distributor?
I am sorry that the coupon is only available for current two distributors, Allnet and Ameridroid and the coupon will not be available soon once we start shipping. The already bought coupon is available in one year.
I am sorry that the coupon is only available for current two distributors, Allnet and Ameridroid […]
Thanks for the quick clarification! Let’s hope that there will be coupons for early adopters of future models in the EU as well, then…
This is still good schedule, we should have devices shipped before christmas
We got july now so I hope there will be announcement about this EU shop, hopefully much better than pine64.eu which has only one sbc now and site looks poor. I saw that Allnet restocked some rock pis, so probably there is another batch of them comming to that EU store.
BTW: yestarday annonced pi was sold in about 5 hours at most of distributors.
https://coolcomponents.co.uk/products/raspberry-pi-pico-w you can still get if that is what you mean or did I miss a new product?
I would rather go for some esp32 for such product.
Sure some stores could get more of them - I checked those near and all sold everything on first day
I hope that radxa new eu shop will get reasonable amounts
Is PoE capability planned for this board?
For the fellow reviewers/devs:
Radxa’s most recent OS images are here: https://github.com/radxa/debos-radxa/releases (two months ahead of where we should look at).
The eMMC has a compatible pin-out at least with Hardkernel and Pine64 (the second row of pins is just for better connection w/o any signals/power) so flashing one of these images with an eMMC-to-SD-card adapter was an easy one.
Default user/password: rock/rock
At least the rock-5b-ubuntu-focal-server-arm64-20220701-0826-gpt.img
image has SSH enabled, fetches an IP address via DHCP and is good to go without connecting any display/peripherals except network:
root@rock-5b:/home/rock# sbc-bench.sh -m
Rockchip RK3588 (35880000), Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 408 1800 Cortex-A55 / r2p0
1 0 0 408 1800 Cortex-A55 / r2p0
2 0 0 408 1800 Cortex-A55 / r2p0
3 0 0 408 1800 Cortex-A55 / r2p0
4 1 4 408 2400 Cortex-A76 / r4p0
5 1 4 408 2400 Cortex-A76 / r4p0
6 2 6 408 2400 Cortex-A76 / r4p0
7 2 6 408 2400 Cortex-A76 / r4p0
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)
Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp
17:40:23: 408/1200MHz 0.11 0% 0% 0% 0% 0% 0% 30.5°C
17:40:28: 408/1008MHz 0.10 0% 0% 0% 0% 0% 0% 30.5°C
First sbc-bench run: http://ix.io/41BH
Rock5B (and of course other RK3588 thingies) are so far the fastest SBC around (competition). And when comparing performance/watts most probably also the most power efficient (TBC).
Insights:
- consumption with this set of benchmarks is really low: not exceeding 10W with the most demanding benchmarks (measured at wall with a NetIO ‘PowerCable REST 101F’ and an Apple 94W USB-C charger known for really low losses). Idle consumption with the Ubuntu Focal server image and network at GbE speeds: 3W.
- CPU clockspeeds are controlled by an MCU inside the SoC (with this OS image A76 cores are clocking in at 2350 MHz instead of 2400 and A55 cores being clocked slightly higher). Also cpufreq governor gets ignored with RK’s BSP. Even with
performance
the MCU inside the SoC decides to downclock cores if they’ve nothing to do. Which is stuff for further inspection since it could negatively affect real-world workloads (talking Linux here and not Android). - There’s 3 CPU clusters: 4 x A55, 2 x A76, 2 x A76. The latter seem to behave the same but ofc they could be configured in different ways: cluster 2 way more aggressively jumping to higher DVFS OPP than cluster 1 and 0 to always allow for maximum single-threaded performance peaks. Again: this seems to be a closed sourced MCU thing if there is really a difference in behaviour of cluster 1 and 2 (both 2 x A76)
- the supplied fansink is noisy/annoying but a) it does its job and b) Radxa will come up with something else for regular consumers (at least I hope so). Heatsink mounting holes are there and IIRC they’re designed for old x86 Northbridge coolers so there should be plenty of alternatives to the fansink provided with the 5B dev samples
- memory performance is awesome. When testing the A55 cluster isolated (at 1820 MHz) it gets a 7-ZIP-MIPS score of ~5900 which is 20% ahead of other ARM SoCs featuring four A55 (also at 1.8-2.0 GHz)
I received mine as well and couldn’t resist running a few tests.
Man, this board is fast… amazingly fast! We’re seeing a great product come here.
Mine is configured to top at 2.304 GHz, I don’t know how Thomas got 2.400 in his tests. I noticed that the two A76 clusters don’t run at exactly the same frequency, cores 4 and 5 are reported as running at 2286-2290 MHz while cores 6 and 7 are measured at 2308 MHz. I suspect that something is disturbing cores 4-5 or maybe it’s someting internal, but quite frankly that’s a minor detail.
I could measure inter-core latency for atomic operations. It’s overall uniform across the 8 cores because they all share the same L3 cache, which is great. The values are excellent (27-28ns for R/O accesses, 56ns for A55 to anything, 67ns for A76-A76) and much better than the last Xeons I tested.
I have also run my usual build test. The build times are the shortest I’ve seen to date on this test, x86 included, and they’re twice as fast as the Odroid-N2+ at 2.4 GHz, which was the previous winner ( http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm ).
As Thomas also noticed, the memory performance is excellent, and definitely participates to the very high build speed (since gcc is extremely sensitive to both latency and bandwidth). Having 4 channels very likely maintains low latencies even when all cores are loaded.
I also noticed that an extlinux.conf is used to pass the kernel parameters. Thanks for that! It’s so much easier than having to figure how to fiddle with a boot_param variable in a u-boot environment!
Oh and by the way, the board doesn’t particularly heat up during build sessions, so it seems like great components were chosen.
I noticed two small problems on the hardware layout though, that were already suspected from the photos. The holes for the heat sink not being centered around the SoC make it almost not touch the SoC (I’ll try to upload photos). This can certainly be arranged by placing something as high as the SoC at the opposite side. The second problem is the location of the heat shink hole that goes directly under the M.2 location. The plastic part is particularly high and I think it will cause trouble with some M.2 boards, though with flat screws it shouldn’t be a problem.
From top to bottom:
- the height of the plastic fixation for the fan compared to the M.2 connector.
- how to connect a serial port while keeping the fan (use split wires and connect the ground to the next GND, one with a black color around the pin)
- the heat sink as currently placed on the SoC. I’ll remove it and try other heat sinks and try to measure the most suitable riser needed to keep it perfectly flat.
Wow that must be running cool if the heatsink is like that, but can not see it ever lying flat if its so far off centre?
If it does run so cool would they not be better reverting to the original smaller heatsink that also doesn’t protrude under the m.2?
PS the heat sink looks extremely close to the 1st row of gpio also.
And here comes a photo of the heat sink from my thermal IR camera under the exact same angle as above, with the fan unplugged during build loops (otherwise the temperature doesn’t raise in a relevant way).
We can see roughly 3 degrees difference between the SoC and the aluminum. Note that the measurement lacks accuracy due to using a small sensor, but it gives an idea. Overall it’s not bad at all, but definitely something that could be improved a bit