Xalius

You might run into problems since either the rk miniloader or u-boot spl on Rock64 images are configured for the Rock64's LPDDR3 DRAM and not the LPDDR4 the Renegade uses, so you will most likely have to build a new boot firmware with the right RK miniloader or submit patches to the u-boot spl with detection for the LPDDR4 stuff...

Mainline linux just got PCIe endpoint support patches for RK3399, in addition to the host mode that is already there, so you could theoretically connect multiple RK3399 via PCIe, it can't do multi-master though afaik, so you would have a single Master plus slaves/devices...

Looking at the state of Linux on the H6 atm, I would recommend going with RK3328 if you need hardware immediately...

Mainline Linux works quite well on my H6 board (PineH64), or other H6 boards for that matter..., as far as it is supported by linux-sunxi (spl, usb2, usb3, GbE) and I think icenowy is currently looking into PCIe, she already submitted a patch for basic H6 support to the ML for Linux upstream... As for the BSP Linux, I did not look into the 3.10.x BSP (http://files.pine64.org/os/sdk/H64-ver1.0/H6-BSP-1.0.tgz) other to confirm it's the same mess as the A64 BSP, the 4.9.x BSP kernel boots and you can probably even make one of those AW Phoenix card images with it for your board (Linux 4.9 BSP and tools https://github.com/Allwinner-Homlet/), but if I am going to use BSP kernel, then integrated with normal upstream u-boot/spl... currently the 4.9 BSP does not contain ATF sources, only a binary blob (bl31.bin), so integrating that with upstream boot firmware is tricky... As for Android, Pine64 should release a new Android image for the PineH64 shortly, which I think will be based on the new 4.9 BSP too...

The dts blob I posted has to go into your kernel source tree, it wont work like that in a decompiled dtb from /boot since the references are wrong. DTS are just text files... You have to put the blob into https://github.com/hardkernel/linux/blob/odroidn1-4.4.y/arch/arm64/boot/dts/rockchip/rk3399-odroidn1-linux.dts and then run make dtbs again to produce the output dtb and put that back in /boot. If you are cross-compiling, you need to ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs

nvm found it... https://github.com/hardkernel/linux/blob/odroidn1-4.4.y/arch/arm64/boot/dts/rockchip/rk3399-odroidn1-linux.dts It doesnt seem to enable the SPDIF node atm... SPDIF node is defined here, https://github.com/hardkernel/linux/blob/odroidn1-4.4.y/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L1658 so it has to be instantiated in the board dts by checking the schematics... You can look at other RK3399 boards for that, but try at your own risk since I dont have the N1 to verify that works for your HW: &spdif { status = "okay"; pinctrl-0 = <&spdif_bus_1>; i2c-scl-rising-time-ns = <450>; i2c-scl-falling-time-ns = <15>; #sound-dai-cells = <0>; }; spdif-sound { status = "okay"; compatible = "simple-audio-card"; simple-audio-card,name = "ROCKCHIP,SPDIF"; simple-audio-card,cpu { sound-dai = <&spdif>; }; simple-audio-card,codec { sound-dai = <&spdif_out>; }; }; spdif_out: spdif-out { status = "okay"; compatible = "linux,spdif-dit"; #sound-dai-cells = <0>; }

Well first you have to see why the SPDIF output driver is not loaded, can you pastebin your devicetree?

What does aplay -l list as devices? Do you have a asound.conf that includes those interfaces?

https://github.com/Icenowy/u-boot/commits/h6-dram

That sounds a bit like just the card died to me, I never managed to break any sdcard from the software/bus side so far... eMMC are a different matter if you write to the boot/firmware partitions... do you have steps to reproduce?

Are you talking about CPU affinity at run-time, at the process level you can use taskset or syscalls to bind a process to a core... or do you mean on the thread level?

You can use multiarch on ARM boards of course, but only for architectures that the hardware supports. For example you can use armhf (32bit) and aarch64 at the same time. But looking at your post, you have added i386 which is a 32bit x86 architecture and can not run on ARM without emulation.

Now that the DRAM config issues (at least for dual-rank LPDDR3) seem to be fixed on mainline Linux for H6, I had time to run some first tests... On my PineH64 (2GB) GbE seems to work ok (I get 930 / 720 Mbit/s in iperf3 without even touching gmac delays) and USB2 can be saturated using a SSD (Samsung 850Pro/JMS578 USB3-SATA bridge). USB3 seems to have some issue with buffer allocation at the moment, but I still got about 380MB/s reading and 75MB/s writing. The writing limitation is odd an needs some further investigation...

I assembled a mainline (thanks @Icenowy and @jernej!) image with some Arch rootfs for my PineH64 and now after the libdram workarounds and other spl fixes seem to work, I got a least USB2, USB3 and GbE working... waiting for some more linux-sunxi upstream patches now to fix an issue with DRAM clocks...

Try it out with ethtool -K eth0 rx off tx off

As far as I can see the PineH64 only uses 3.3V for SD-card, and 1.8V for the SDIO on the WIFI socket and the eMMC. I guess that is because the SD-card mmc bus on Port F has no extra VCC-IO and so the whole SoC would need to be switched to 1.8V and the rest shifted back to 3.3V... and the eMMC bus is shared with the SPI Flash at 3.3V as well as the PCIe control lines and the GMAC. I think Allwinner's rational for that is that set top boxes with H6 will either use USB3 or PCIe for fast storage.... Edit: They actually shifted the rest of the port the eMMC bus is on, misread the schematics... So you have: SD-card 3.3V/4bit, SDIO 1.8V/4bit, eMMC 1.8V/8bit

Can you run tinymembench on your Firefly and post the results? https://github.com/ssvb/tinymembench

This is going to be an interesting year with all those new RK3399 boards, and we will probably learn a lot more about the capabilities and limitations of that SoC than before. Even if the Firefly RK3399 has been around for a while, I have not really seen/heard a lot of reports as to how complete the BSP/mainline drivers and what the issues in general are... that being said, almost no day goes by where there are not RK3399 patches on the mainline patchwork system...

Have you tried disabling rx/tx offloading? iirc there was some issue on RK3328 with that as well...

Does inlining the function change anything?

Most boards I know of just wire sdcard to 3.3V only, supporting 1.8V/3.3V dual mode requires support in the SoC and software since you need to do that dynamically during training and in operation, so I guess a lot of designs just avoid that. You could wire up the sdcard in 1.8V only probably like the eMMC but that breaks backwards compatibility to older cards. On some SoC is is also not easy since when you switch the mmc bus to 1.8V on that port, the whole port is using 1.8V and depending what else is on there this causes more issues...

My Rock64s boot fine so far without pushing any buttons, booting from USB or network via SPI flash works too... if you look for community built images check out ayufan's github ... GbE issues have been fixed by tuning RGMII delays, SD card is limited to 25Mhz since it is wired up at fixed 3.3V (might change in future board revision, needs more evaluation), eMMC runs at 1.8V and supports higher speeds https://github.com/ayufan-rock64 https://github.com/ayufan-rock64/linux-build/releases

Free Electrons (now Bootlin ;/) have launched a Kickstarter to get the work on the Allwinner VPU (Video Processing Unit) off the ground again... https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel

The USB3 controller on RK3328 (Rock64/...) can be more or less saturated with a SSD using UAS. I got about 380MB/s (theoretical maximum for UAS is just over 400MB/s) using iozone, and since RK3399 uses the same DW IP block, I would guess that RK3399 is similar...

Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now... https://forum.pine64.org/showthread.php?tid=5614