Jump to content

Firefly RK3399 support efforts (potential csc board?)


hjc

Recommended Posts

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 by Igor
typo
Link to comment
Share on other sites

On 8/12/2018 at 5:17 AM, Igor said:

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines