Igor Posted August 12, 2018 Posted August 12, 2018 (edited) 8 minutes ago, martinayotte said: Did you tried also to build a Mainline ? ... Yes, a kernel only, briefly. It works but booting took very long time for unknown reasons, some strange errors in the logs, ... Haven't got time for debugging yet. Edited August 12, 2018 by Igor typo
TonyMac32 Posted August 12, 2018 Posted August 12, 2018 8 hours ago, martinayotte said: Did you tried also to build a Mainline ? I was planning on trying that tonight, I'll share notes if you will. ;-)
TonyMac32 Posted August 12, 2018 Posted August 12, 2018 8 hours ago, Igor said: Yes, a kernel only, briefly. It works but booting took very long time for unknown reasons, some strange errors in the log Tinker is suffering the same. :-/
TonyMac32 Posted August 13, 2018 Posted August 13, 2018 My attempt to build dev image resulted in an image missing the kernel version. [edit] found it, the packaging script is for "next", not "dev" - Fixed. Slow boot confirmed. :-)
hjc Posted August 16, 2018 Author Posted August 16, 2018 On 8/12/2018 at 5:17 AM, Igor said: @martinayotte @hjc Successfully merged. https://github.com/armbian/build/commit/6d82a8974872ee261006d2cdf6726b7d13df5032 Thanks for merging these boards into Armbian. I'm excited to see the first RK3399 board on Armbian download page. I've migrated my NanoPC T4 to the pre-built image downloaded from Armbian website just now. Also built an image for Firefly RK3399 from armbian/build repository. They all worked smoothly. I'll keep testing these boards and provide feedback or pull requests. BTW the dragonboard 820c & qcomlt kernel/u-boot should be removed, since those are just my personal interests, and they're not completed yet. I'm almost sure that few people would be interested in those Qualcomm boards & SoCs here.
hjc Posted August 16, 2018 Author Posted August 16, 2018 Firefly RK3399 (with official active cooling fan) sbc-bench test results: http://ix.io/1kk9 It shows impressive CPU performance numbers when overclocked to 2.2/1.8 GHz, but that definitely requires a fan.
thomasgrzybowski Posted August 21, 2018 Posted August 21, 2018 Hi, I'm thinking of purchasing one of these boards. The CPU specs look very promising: CPU: big.LITTLE，Dual-Core Cortex-A72(up to 2.0GHz) + Quad-Core Cortex-A53(up to 1.5GHz). BUT, from what I read, only the Dual-Core Cortex-A72 is available to use from existing builds. What can the Quad-Core Cortex-A53 be used-for? Can I access these cores in any way? Thanks, TG
TonyMac32 Posted August 22, 2018 Posted August 22, 2018 2 hours ago, thomasgrzybowski said: BUT, from what I read, only the Dual-Core Cortex-A72 is available to use from existing builds The build I am running on my NanoPC-T4 is showing all 6 cores.
tkaiser Posted August 22, 2018 Posted August 22, 2018 5 hours ago, thomasgrzybowski said: BUT, from what I read, only the Dual-Core Cortex-A72 is available to use from existing builds Very weird statement especially directly below @hjc's post where he shows how performant all 6 cores are with adjusted cpufreq clockspeeds. All RK3399 devices have 6 cores and all of them are usable of course. It's just a matter how fast they and the memory is clocked: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
Igor Posted August 22, 2018 Posted August 22, 2018 43 minutes ago, tkaiser said: Very weird statement If you build an image with build tools now, DVFS is partially broken on two cores since sources were switched to Ayufan's repo and they need further adjustments (WIP). Perhaps this is the problem?
Sergius Triticum Aestivum Posted August 22, 2018 Posted August 22, 2018 Hi all. Did anybody try to connect any others PCIe devices to this board? Not an SSD. I say about external graphics card connected to m.2 via the adapter for example.
tkaiser Posted August 22, 2018 Posted August 22, 2018 1 hour ago, Sergius Triticum Aestivum said: External graphics card connected to m.2 via the adapter for example IIRC RK3399 suffers from not large enough PCI BAR for frame buffer access similar to this problem: https://bugs.freedesktop.org/show_bug.cgi?id=102497 So other PCIe cards using a smaller window work but not GPUs. SATA, network und USB adapters are known to work (Pine folks are currently testing a lot of stuff for RockPro64)
Sergius Triticum Aestivum Posted August 22, 2018 Posted August 22, 2018 23 minutes ago, tkaiser said: IIRC RK3399 suffers from not large enough PCI BAR for frame buffer access similar to this problem: https://bugs.freedesktop.org/show_bug.cgi?id=102497 So other PCIe cards using a smaller window work but not GPUs. SATA, network und USB adapters are known to work (Pine folks are currently testing a lot of stuff for RockPro64) in fact I want to connect a card for video capture.
tkaiser Posted August 22, 2018 Posted August 22, 2018 3 minutes ago, Sergius Triticum Aestivum said: in fact I want to connect a card for video capture. No idea. But this is clearly something I would try to avoid since all those ARM SoCs are equipped with a VPU able to do HW accelerated video decoding but also encoding. Unfortuantely this requires Android but not Linux (almost) everywhere to my knowledge.
Sergius Triticum Aestivum Posted August 22, 2018 Posted August 22, 2018 8 minutes ago, tkaiser said: No idea. But this is clearly something I would try to avoid since all those ARM SoCs are equipped with a VPU able to do HW accelerated video decoding but also encoding. Unfortuantely this requires Android but not Linux (almost) everywhere to my knowledge. Why not? , I quite successfully did made a lot of captures from an external USB3 (connected to USB2) on an orange one and from the CSI device on a raspberry 1. And I encoded it with HW encoder. I could do it to 1280x720p30 quite successfully. now I want to try to do video capture in 1080
tkaiser Posted August 22, 2018 Posted August 22, 2018 17 minutes ago, Sergius Triticum Aestivum said: Why not? I was talking about letting the SoC do the job and not a PCIe card. The RK3399 equipped Orange Pi has HDMI input, most probably for a reason (yet unknown to me -- communication with Xunlong has always been a mess)
Sergius Triticum Aestivum Posted August 22, 2018 Posted August 22, 2018 31 minutes ago, tkaiser said: I was talking about letting the SoC do the job and not a PCIe card. The RK3399 equipped Orange Pi has HDMI input, most probably for a reason (yet unknown to me -- communication with Xunlong has always been a mess) there're rumors that oranges buried their project on 3399. In order to start working HDMI entry on the orange, the kernel should have a support driver TC358749XBG (this is a Toshiba HDMI to MIPI CSI-2 bridge)
thomasgrzybowski Posted August 22, 2018 Posted August 22, 2018 Igor: "The build I am running on my NanoPC-T4 is showing all 6 cores." Igor: "If you build an image with build tools now, DVFS is partially broken on two cores since sources were switched to Ayufan's repo and they need further adjustments (WIP). Perhaps this is the problem?" Great! I'm gonna get me one of these, and will use the Download build instead of building one myself, for now. Thanks much! Tom
tkaiser Posted August 25, 2018 Posted August 25, 2018 On 8/22/2018 at 8:31 AM, Igor said: If you build an image with build tools now, DVFS is partially broken on two cores since sources were switched to Ayufan's repo and they need further adjustments (WIP). Perhaps this is the problem? He mentioned it would be the other way around (little cores missing and only big cores present). I looked into it right now: [ 1.562675] rk_tsadcv2_temp_to_code: Invalid conversion table: code=1023, temperature=2147483647 [ 1.562900] rockchip-thermal ff260000.tsadc: tsadc is probed successfully! [ 1.564982] cpu cpu0: Failed to get leakage [ 1.565017] cpu cpu0: Looking up cpu-supply from device tree [ 1.565099] cpu cpu0: Failed to get pvtm [ 1.565480] cpu cpu4: Failed to get leakage [ 1.565508] cpu cpu4: Looking up cpu-supply from device tree [ 1.565571] cpu cpu4: Failed to get pvtm [ 1.565872] cpu cpu0: Looking up cpu-supply from device tree [ 1.566208] cpu cpu0: Looking up cpu-supply from device tree [ 1.569178] cpu cpu4: Looking up cpu-supply from device tree [ 1.569716] cpu cpu4: _opp_add: duplicate OPPs detected. Existing: freq: 1800000000, volt: 1200000, enabled: 1. New: freq: 1800000000, volt: 1350000, enabled: 1 [ 1.569760] cpu cpu4: _of_add_opp_table_v2: Failed to add OPP, -17 [ 1.570410] cpu cpu4: couldn't find opp table for cpu:4, -17 [ 1.570638] cpu cpu5: Looking up cpu-supply from device tree [ 1.571138] cpu cpu5: _opp_add: duplicate OPPs detected. Existing: freq: 1800000000, volt: 1200000, enabled: 1. New: freq: 1800000000, volt: 1350000, enabled: 1 [ 1.571172] cpu cpu5: _of_add_opp_table_v2: Failed to add OPP, -17 [ 1.571798] cpu cpu5: couldn't find opp table for cpu:5, -17 Hmm... that's bad. Due to different ways @ayufan deals with DT includes and 'the others' (RK kernel consumers) do I wonder how to proceed.
mmarks Posted August 25, 2018 Posted August 25, 2018 I installed armbian stretch on my T4 and also got it installed in the eMMC with the nand install script. Good progress! It runs OK except for one thing. I installed a 512GB NVME SSD for bulk storage and it doesnt seem to be recognized at all. The FriendlyElec Wiki says to check /proc/partitions - and I see nothing for the nvme there. And also lspci shows nothing at all. Looking at dmesg I see some indications that pcie might be started but it has problems, maybe the device tree is not quite right?: ... [ 0.833210] phy phy-pcie-phy.5: Looking up phy-supply from device tree [ 0.833218] phy phy-pcie-phy.5: Looking up phy-supply property in node /pcie-phy failed [ 0.835200] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep [ 0.835211] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup [ 0.835237] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0) [ 0.835458] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree [ 0.835540] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree [ 0.835551] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed [ 0.835563] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found [ 0.835570] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree [ 0.835578] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed [ 0.835586] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found [ 0.855987] rockchip-pcie f8000000.pcie: invalid power supply [ 1.356010] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 1.356204] rockchip-pcie: probe of f8000000.pcie failed with error -110 ... Any ideas what might be wrong? I noticed that there are some performance numbers for NVME speed - what kernel/device tree is being used for that data?
Igor Posted August 25, 2018 Posted August 25, 2018 root@nanopct4:~# lspci 00:00.0 PCI bridge: Rockchip Inc. RK3399 PCI Express Root Port Device 0100 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 root@nanopct4:~# cat /proc/partitions major minor #blocks name 1 0 4096 ram0 259 0 500107608 nvme0n1 259 1 1024 nvme0n1p1 259 2 500104192 nvme0n1p2 179 0 7761920 mmcblk0 179 1 7590288 mmcblk0p1 179 32 15267840 mmcblk1 179 128 4096 mmcblk1rpmb 179 96 4096 mmcblk1boot1 179 64 4096 mmcblk1boot0 252 0 51200 zram0 252 1 262144 zram1 252 2 262144 zram2 252 3 262144 zram3 252 4 262144 zram4 Huh. Nothing suspicious here. http://ix.io/1ldb
mmarks Posted August 25, 2018 Posted August 25, 2018 I see you are running kernel 4.4.150 while the debian stretch version for download is 4.4.148. Do I need to do an offline full build to pick up the latest changes?
Igor Posted August 25, 2018 Posted August 25, 2018 6 hours ago, tkaiser said: and 'the others' (RK kernel consumers) do I wonder how to proceed. It is a total mess which means a lot of work. I was trying a few hours now to come up with some working combination, but problems are just piling up: random gmac, hanging on boot, ... I used radical solutions as such: Spoiler diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-ayufan.dtsi similarity index 100% rename from arch/arm64/boot/dts/rockchip/rk3399.dtsi rename to arch/arm64/boot/dts/rockchip/rk3399-ayufan.dtsi diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-opp-ayufan.dtsi similarity index 100% rename from arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi rename to arch/arm64/boot/dts/rockchip/rk3399-opp-ayufan.dtsi diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts index 78ad3ac4..d79a35af 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts @@ -43,8 +43,8 @@ /dts-v1/; #include <dt-bindings/pwm/pwm.h> #include <dt-bindings/input/input.h> -#include "rk3399.dtsi" -#include "rk3399-opp.dtsi" +#include "rk3399-ayufan.dtsi" +#include "rk3399-opp-ayufan.dtsi" / { model = "Pine64 RockPro64"; @@ -283,7 +283,7 @@ cooling-max-state = <3>; #cooling-cells = <2>; cooling-levels = <0 102 170 230>; - }; + }; rk_key: rockchip-key { compatible = "rockchip,key"; ... and using stock .dtsi for the rest. Additional families? Or someone else takes a look if he can come up with something. rk3399-pine64 rk3399-fa joined once into rk3399?
hjc Posted August 25, 2018 Author Posted August 25, 2018 17 minutes ago, Igor said: Additional families? rk3399-pine64 rk3399-fa joined once into rk3399? Is it possible to share a board family between Rock64 and RockPro64? If they could use exactly the same kernel source and u-boot source from ayufan... 3 hours ago, mmarks said: I see you are running kernel 4.4.150 while the debian stretch version for download is 4.4.148. Do I need to do an offline full build to pick up the latest changes? Use armbian-config and switch to nightly build, and you'll get the latest kernel.
Igor Posted August 25, 2018 Posted August 25, 2018 11 minutes ago, hjc said: Is it possible to share a board family between Rock64 and RockPro64? If they could use exactly the same kernel source and u-boot source from ayufan... That should be possible, yes. We use the same kernel source, but one kernel is packed into rk3328 and another into rk3399. The plan is also to merge Rk3288 in ... but we already had many troubles.
TonyMac32 Posted August 25, 2018 Posted August 25, 2018 16 minutes ago, hjc said: Is it possible to share a board family between Rock64 and RockPro64? If they could use exactly the same kernel source and u-boot source from ayufan... To echo Igor it should be possible. If the rk3288 is too much trouble (for example kernel configs) I'd recommend we move over to something more "conventional" with "RK32" and "RK33". Once @ayufan rebases on today's Rockchip kernel we can use his source on Tinker, I just think we'll have to have separate configs.
Igor Posted August 25, 2018 Posted August 25, 2018 2 minutes ago, TonyMac32 said: I just think we'll have to have separate configs. That is not a problem. How about this way: RK3288 -> rockchip with whatever source, ayugan if there will be not much hassle RK3399 (RockPRO) and RK3328 (Rock64) -> rockchip64 (ayufan source) RK3399 (FriednlyARM) remains RK3399 (fa source) ... we postponed this merge for the future 1
botfap Posted August 25, 2018 Posted August 25, 2018 Apologies for slightly off topic but what is the most generic Armbian RK3399 build to use as a starting point to bring up an unsupported RK3399 board?
TonyMac32 Posted August 25, 2018 Posted August 25, 2018 4 hours ago, Igor said: How about this way: Seems ok. I would like to switch to Ayufan as soon as it is even with current Rockchip.
![m][sko](https://forum.armbian.com/uploads/n2a/n2a-180904eb9612afa23a4c3358385bd86f384613e3.avatars_letters_gd.png){kind=avatar}
Recommended Posts