it is also my conviction but at that moment i was a little annoyed with the resellers proposed by the company,
these charge the mule with allucinant expenses of delivery, insurances of routing very strongly advised, and followed of delivery in supplement.
The taxes must be paid with the customs what adds a supplement for the expenses of procedure.
Brief one thing goes up to 250Euro, and I take two of them.
for a SOC with RAM, no EMMC, no heat sink, no psu, no software support, just a motherboard with RK3588 and heat sink holes placed oddly to remain polite,
basically they taken me for an american! 
to be honest Iāve picked up a few coupons since last time, at worst if this madness continues Iāll only have lost 10$.
I will be glad to read your test of network card, it was planned on my roadmap but by weakness I think to install a SFF-8643 to connect external adapters if necessary.
ROCK 5B Debug Party Invitation
No, you wonāt lost 10$. You can just refund the 10$.
I mentioned above that I observed the same power cut issue at boot as you, I suspect it happens when a USB driver is loaded though I could be wrong. For me it fails with the ubuntu SD image, but the debian on the eMMC doesnāt have this problem.
But how does this have anything to do with your perception of the boardās readiness from a technical perspective ? I mean, itās in debug phase and weāre trying to spot problems that need to be fixed before the final model starts to ship to customers (software-only problem may be fixed later). If your concern is only about delivery costs, itās not related to this thread at all since thereās nothing any of us testing the hardware can help with. Thatās a bit confusing :-/
First, Radxa explained that this heatsink is temporary, so you donāt need to count on the plastic fixation that would hinder the M.2 module, but instead youād likely have a flat screw posing no problem. Second, Tom said he will probably change this. I personally donāt think it is a problem at all if it ends up as a screw. Itās only a problem with the current large plastic part, so please stop worrying about this. The issue was reported and acknowledged.
Forget what I said before, thanks to your tests, proposals, suggestions and feedback, my opinion has changed on this board, but you canāt blame me for being suspicious of board distributors, your commitment this week will save a lot of pain to those who will acquire it, and Iām very thankful for that.
As TK point out we donāt know yet how the RK3588 will react with CPU+GPU+TPU+NPU in toaster mode and although the TK3588 is oriented towards embedded and automotive applications, I think it was radxaās responsibility to propose a ROCK5 heat sink, and not for me to order a piece of metal from the scrap dealer and machine it in my workshop so that it fits on some oddly placed holes.
I donāt want to dwell on it anymore, Iām very enthusiastic, this board will allow a lot of things, itās a new dimension, clearly to fit so much I/O and offer as many combinations in such a small format is a technical feat.
itās very promising, everybody will find his account here.
the week has been hard and I wish you all a very good weekend.
I tried the Armbian image as well and had no problems (though no display(s) connected). Since your PVTM log entries are rather low could you please do an sbc-bench run on your board to see with which clockspeeds your RK3588 ends up?
Also please provide output from
cat /sys/devices/system/cpu/cpufreq/policy?/scaling_available_frequenciesHere is the output if cat /sys/devices/system/cpu/cpufreq/policy?/scaling_available_frequencies:
408000 600000 816000 1008000 1200000 1416000 1608000 1800000
408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2256000
408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2304000
I will post result of sbc-bench later.
Just curious about theā hdmi in āportļ¼with this powerful cpu,maybe itās possible to make it into a portable video game console capture card?
Ok, in case your board freezes when running the benchmarks just like Jean-Lucās please provide output from
taskset -c 1 /usr/local/src/mhz/mhz 3 100000
taskset -c 5 /usr/local/src/mhz/mhz 3 100000
taskset -c 7 /usr/local/src/mhz/mhz 3 100000
And if this is really reproducible now on 2 boards we need to get in contact with RK for more conservative BLOBs than those currently used.
By comparing memory performance of Radxaās Ubuntu with your Armbian build Iām pretty sure at least rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.07.bin is also used in Radxaās builds.
Has the m2 pcie3x4 slot been tested for pcie bifurcation support? I am only asking because I read somewhere in this forum that there are plans to support m2 multi-chip network cards (such as the odroid h2 net card) and that would require pcie bifurcation.
I know of no-one who has tested this with RK3588 but it should work. RK3588ās little sibling RK3568 sharing same/similar IP blocks also supports bifurcation (see here for feature comparison and there for discussion) and with RK3568 I can personally confirm itās working since having two NanoPi R5S on my desk where each Gen3 lane is connected to an own RTL8125BG NIC.
Youāre right that it should be tested prior to final release but I donāt know who would match the prerequisits (owning the H2 netcard or some special splitter card that turns M.2 into two or four PCIe slots).
Yes, the PCIe 3.0 x4 can be configured as:
- 4x 1-lane
- 2x 2-lanes
- 1x 2-lanes + 2x 1-lanes
- 1x 4-lanes
Note you also need PCIe clock for multiple PCIe devices.
Well, I tried to replace this BLOB, built an u-boot package [1], installed it on Armbian [2] and rebooted:
root@rock-5b:/home/tk# dpkg -i /tmp/linux-u-boot-legacy-rock-5b_22.08.0-trunk_arm64.deb
dpkg: Warnung: Version 20220707f-rpardini des Paketes linux-u-boot-rock-5b-legacy wird durch Ƥltere Version 22.08.0-trunk ersetzt
(Lese Datenbank ... 37287 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../linux-u-boot-legacy-rock-5b_22.08.0-trunk_arm64.deb ...
Entpacken von linux-u-boot-rock-5b-legacy (22.08.0-trunk) Ć¼ber (20220707f-rpardini) ...
linux-u-boot-rock-5b-legacy (22.08.0-trunk) wird eingerichtet ...
But after a reboot at least same PVTM entries in dmesg as before:
cpu cpu0: pvtm=1529
cpu cpu0: pvtm-volt-sel=5
cpu cpu4: pvtm=1784
cpu cpu4: pvtm-volt-sel=7
cpu cpu6: pvtm=1782
cpu cpu6: pvtm-volt-sel=7
cpu cpu0: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=1608000000 h_table=0
cpu cpu4: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=2208000000 h_table=0
cpu cpu6: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=2208000000 h_table=0
Also ending up with exact same provided cpufreq OPP and real clockspeedsā¦
[1] MD5 (linux-u-boot-legacy-rock-5b_22.08.0-trunk_arm64.deb.zip) = 154ec1750fbe1d3e1be1431183b43b42
[2] Donāt try this on the Radxa provided images, only supposed to work on the preliminary Armbian images
Are you hinting at something special or can we expect that Rock 5Bās M.2 implementation supports ābifurcationā including clocks to the point where aforementioned PCIe splitters or this ODROID H2 net card work flawlessly?
Note that I didnāt expect the values to change as theyāre defined in the DTS, e.g.:
rockchip,pvtm-voltage-sel = <0x00 0x63b 0x00 0x63c 0x64f 0x01 0x650 0x668 0x02 0x669 0x68b 0x03 0x68c 0x6ae 0x04 0x6af 0x6cf 0x05 0x6d0 0x6f0 0x06 0x6f1 0x270f 0x07>;
Iām reading this as: 0-63b -> sel 0; 63c->64f -> sel 1 etc. So above for 1782 (0x6f6) it would match 6f1-270f hence 7.
I suspect that the opp-microvolt-L1ā¦L7 values are voltages for various PVTM values for a given frequency, allowing to lower the voltage on some higher quality chips. This owuld mean that the last frequency to support an adjustable voltage is 2208 MHz, and above there are only fixed values. I havenāt yet found how theyāre enabled, though the opp-supported-hw value suspiciously looks like a bit mask of the PVTM values that will expose that frequency. With 0x80 for 2.4 GHz (pvtm-sel=7) youāre seeing your frequency, while Iām only seeing 2304 or 2352, and as there are holes in the mask this avoids some useless ones which almost overlap with the next one.
This would then allow to unlock high frequencies for lower grade chips by using a slight overvolting. Apparently at 2.208 the difference between L6 and L7 is 12.5mV and between L5 and L6 itās 25mV. So it might be reasonable to try to compensate for silicon quality with a bit more heat.
Thank you for the insights!
Different topic: the MAC address of āmyā board is 00:e1:4c:68:00:1c which is an unknown OUI to me. Is yours similar?
Foxconn according to lookup
00:e1:4c:68:00:1f here. I canāt find foxconn associated with it, however when I look that prefix up, each time I find it associated with a realtek chip, wired or wireless (8139, 8153, 8125, 8192cu). So I guess itās a sub-range of realtek. Interestingly, realtek is 00-E0-4C, so thereās just one flip bit there. Maybe they recently ordered a second range.
https://hwaddress.com/oui-iab/00-1E-4C/ was what I used and maybe wrong but presumed the same was found as what does it matter what the OUI is?
If not shame as it would of have had the build quality of an Iphone.