NanoPC T4

[Merblud]

Probably in Armbian core is already patched (used SCLK_I2SOUT_SRC in rk3399-cru.h).

[balbes150]

23 hours ago, Werner said:

Push to Armbian repo?

Script for automatically enabling audio on all known ARM models (in my images, it runs automatically when the system is first started and includes all known audio devices for the model being used).

 

By the way, today, T4 has almost full support for all hardware (WiFi BT NVMe sound etc) and copes well with any tasks. It remains only to solve the issue with 4K resolution.

sound.sh

[starman345]

On 4/25/2020 at 7:13 AM, balbes150 said:

Script for automatically enabling audio on all known ARM models (in my images, it runs automatically when the system is first started and includes all known audio devices for the model being used).

 

By the way, today, T4 has almost full support for all hardware (WiFi BT NVMe sound etc) and copes well with any tasks. It remains only to solve the issue with 4K resolution.

sound.sh 3.86 kB · 6 downloads

Latest image works great. Is there any chance to have boot/rootfs  on SD card installed to emmc/nvme via Armbian-config?

[balbes150]

12 hours ago, starman345 said:

Latest image works great. Is there any chance to have boot/rootfs  on SD card installed to emmc/nvme via Armbian-config?

Sorry, I didn't understand the question, what version of images are we talking about ?

[RussianNeuroMancer]

On 4/25/2020 at 6:13 PM, balbes150 said:

By the way, today, T4 has almost full support for all hardware (WiFi BT NVMe sound etc) and copes well with any tasks. It remains only to solve the issue with 4K resolution.

 

Did you get Type-C port working on 5.4 too?

[balbes150]

20 minutes ago, RussianNeuroMancer said:

Did you get Type-C port working on 5.4 too?

I didn't check this port.

[Merblud]

Strange and obscure problem. With the latest patches, I have audio output working through the codec rt5651. But only with a 5.2.8 core.
I used these fixes in core 5.4.35. But no sound device rt5651 is created. At the same time, everything is normal in the log. The codec driver is connecting successfully.

 

 

Good news. There was an error in dts file patch. You must use the name "realtek" instead of "rockchip" in the node rt5651: rt5651@1a. In this case, the codec driver module will be used successfully. Otherwise, the module will not load automatically.

 

 &i2c1 {
	clock-frequency = <200000>;
 	i2c-scl-rising-time-ns = <150>;
 	i2c-scl-falling-time-ns = <30>;
 	status = "okay";
 
 	rt5651: rt5651@1a {
		#sound-dai-cells = <0>;
 		compatible = "realtek,rt5651";
 		reg = <0x1a>;
 		clocks = <&cru SCLK_I2S_8CH_OUT>;
 		clock-names = "mclk";
		pinctrl-names = "default";
		pinctrl-0 = <&i2s_8ch_mclk>;
 	};
 };

 

[Oleksii]

On 4/28/2020 at 1:27 PM, RussianNeuroMancer said:

 

Did you get Type-C port working on 5.4 too?

 

I managed to make Type-C port working on 5.* kernels by forcing its mode to "host":

&usbdrd_dwc3_0 {
 dr_mode = "host";
 status = "okay";
};
 

[RussianNeuroMancer]

I briefly tested 5.6.10 kernel  and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again.

 

On 5/4/2020 at 10:48 PM, Oleksii said:

I managed to make Type-C port working on 5.* kernels by forcing its mode to "host"

Manually compiled dtb will be overwritten during linux-dtb-current-rockchip64 package updates, I guess?

[Oleksii]

2 hours ago, RussianNeuroMancer said:

I briefly tested 5.6.10 kernel  and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again.

 

Manually compiled dtb will be overwritten during linux-dtb-current-rockchip64 package updates, I guess?

Yep, most probably file names will collide  I use custom 5.* kernels all the time with optimized configuration + some DT tweaks, so I don't usually care about linux-dtb-current-rockchip64 updates.

And if you want to overcome this, you may simply give your customized *.dtb a new name (make sure it is also correctly specified in the armbianEnv.txt). As another option, TD overlay might be handy too.

However, I would admit with every mainline kernel version increment I keep less and less of my custom patches  For the moment, I have only one important that fixes Type-C on NanoPC T4 (and still, no 100% confidence it is right way to fix) and one small patch to enable ES400 mode on emmc for NanoPi M4.

[balbes150]

5 hours ago, RussianNeuroMancer said:

I briefly tested 5.6.10 kernel  and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again.

Hm. I have a Nanopc T4 with evo 970 and kernel 5.7 performs LE build (compilation with full load within 5-7 hours), I did not find any problems with stability.

[DerDave]

36 minutes ago, balbes150 said:

Hm. I have a Nanopc T4 with evo 970 and kernel 5.7 performs LE build (compilation with full load within 5-7 hours), I did not find any problems with stability.

Great to hear!
So you compiled this from mainline and didn't need to apply any further patches to fix e.g. wifi? 

[balbes150]

49 minutes ago, DerDave said:

Great to hear!
So you compiled this from mainline and didn't need to apply any further patches to fix e.g. wifi? 

No, I'm using a different kernel (from LE) with additional patches.

[RussianNeuroMancer]

22 hours ago, Oleksii said:

And if you want to overcome this, you may simply give your customized *.dtb a new name (make sure it is also correctly specified in the armbianEnv.txt).

I could, but this solution does not scale (specifically "things that don’t scale ... fix a problem for myself" and "things that scale ... fix the problem in way that will just work for most people, most of the time"). I there reason why you can't submit patch for type-c port to Armbian? You have better understanding of Armbian internals than I do, for sure.

[Oleksii]

2 hours ago, RussianNeuroMancer said:

I could, but this solution does not scale (specifically "things that don’t scale ... fix a problem for myself" and "things that scale ... fix the problem in way that will just work for most people, most of the time"). I there reason why you can't submit patch for type-c port to Armbian? You have better understanding of Armbian internals than I do, for sure.

 

1. I still have quite shallow understanding of Armbian's internals

2. I use most up-to-date kernel revisions all the time in experimental mode and those are always several month ahead of Armbian's I suppose

3. I'm not sure that forcing controller to host mode purposely is a right fix - I miss experience and knowledge for such decisions. I did it for my personal sake and my own risk and clearly admitted this in the message above

4. Submitting the code to community project - is about 100% confidence and responsibility for me

5. Just have a look on the DT overlays capabilities - this was designed to provide some decent scalability potential and could be good compromise for you

[DerDave]

On 5/6/2020 at 12:31 PM, balbes150 said:

No, I'm using a different kernel (from LE) with additional patches.

Ah, I got that wrong. Didn't know you were talking about Libre Elec. Just had a look at all your great work in the LE forums. Seems like you have a good understanding of our device. Any chance your work on the kernel in LE can be committed to Armbian, so we can all profit from it?

[balbes150]

29 minutes ago, DerDave said:

Any chance your work in LE can be committed to Armbian, so we can all profit from it?

I wrote about Armbian. It all works (WiFi BT HDMI analog sound) and uses a common kernel with LE.

Including installation on eMMC and installation on NVMe, and run system in USB

[DerDave]

Ah great! Thank you all, so much for all the hard work! Seems like it's time to try out the latest kernels again!

EDIT: @balbes150 I tried both Buster and Bionic with the latest available Kernels (5.6.10-rockchip64) but the wifi adapter still doesn't show up in my interfaces...
Is there anything I can do? I could really use the newer kernels, because I have a lot of problems on the legacy kernels, but I wifi is crucial for my setup. I don't care about HDMI or the 3.5mm Jack. Just a modern kernel and wifi.
Bluetooth also works by the way

EDIT2: I got it working with the hint, Martin gave in this post: 

Is there a way to implement this, so all devices can have wifi with a normal install?

[RussianNeuroMancer]

15 hours ago, Oleksii said:

I'm not sure that forcing controller to host mode purposely is a right fix

Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.

[balbes150]

19 hours ago, DerDave said:

Is there a way to implement this, so all devices can have wifi with a normal install?

This is already done for the ArmbianTV version. Everything works in it at once, without manual operations and with the kernel 5.7

 

 

[Oleksii]

10 hours ago, RussianNeuroMancer said:

Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.

 

It is not so obvious  I only consider the state in the mainline kernel as a reference (because I decided for myself to track changes since 5.* only). And I see that USB Type-C controller changes its state from "host" to "gadget" and almost immediately powers off during the boot. It should be correctly handled automatically by the driver on this board according to my understanding. And forcing to host mode is imho just a workaround for some issue in the current driver (or some other problems in device tree).

[DerDave]

On 5/8/2020 at 9:33 AM, balbes150 said:

This is already done for the ArmbianTV version. Everything works in it at once, without manual operations and with the kernel 5.7

 

 

Great! Looking forward to see this trickle down to standard Armbian in the future!

[mmendeza]

On 4/25/2020 at 12:13 PM, balbes150 said:

Script for automatically enabling audio on all known ARM models (in my images, it runs automatically when the system is first started and includes all known audio devices for the model being used).

 

By the way, today, T4 has almost full support for all hardware (WiFi BT NVMe sound etc) and copes well with any tasks. It remains only to solve the issue with 4K resolution.

sound.shUnavailable

 

I was able to fix 4k resolution issue editing dtb to make hdmi use vopb as in rk3399 4k dtb fix

 

Hope it helps.

[balbes150]

8 hours ago, mmendeza said:

I was able to fix 4k resolution issue editing dtb to make hdmi use vopb as in rk3399 4k dtb fix

 

Hope it helps.

Unfortunately, this is for the old core 4. as far as I understand, these parameters are already used on the new core.

 

https://github.com/150balbes/Amlogic_s905-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L1601

https://github.com/150balbes/Amlogic_s905-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L1765

https://github.com/150balbes/Amlogic_s905-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi#L889

 

 

By the way, the latest version of Libreelec (20200512) has support for 4K decoding. I checked it on T4 - it works.

[Oleksii]

On 5/8/2020 at 2:08 AM, RussianNeuroMancer said:

Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.

 

If you are still interested in Type-C for mainline kernels. My patches at least explain what is missing in the present drivers and why this magic dr_mode = "host" is specified everywhere in the mainline dtbs

[RussianNeuroMancer]

I briefly tested 5.7.6 kernel and found that Samsung 970 EVO still doesn't work with same PCIe link training gen1 timeout error.

 

Rollback to 5.4.49, and it works again.

[Oleksii]

2 hours ago, RussianNeuroMancer said:

I briefly tested 5.7.6 kernel and found that Samsung 970 EVO still doesn't work with same PCIe link training gen1 timeout error.

 

Rollback to 5.4.49, and it works again.

 

My Transcend 110S SSD stoped working due to some driver changes in v5.4. But started to work again since next 5.5

[RussianNeuroMancer]

On 3/4/2020 at 12:55 AM, RussianNeuroMancer said:

While WD SSD, such as WDS200T3X0C, works just fine on both of Linux 4.4 and 5.3, SSD from Samsung, such as 970 EVO, works only with 4.4, but not with 5.3. Pci driver just fail to detect it, while on 4.4 same SSD works for half year without issues.

Issue with Samsung 970 EVO is no longer reproducible for me on uboot 2020.10 and Linux 5.10.

[DerDave]

Am 27.2.2021 um 10:28 schrieb RussianNeuroMancer:

Issue with Samsung 970 EVO is no longer reproducible for me on uboot 2020.10 and Linux 5.10.

Ah that's amazing! Thanks for trying this out! I can finally upgrade then!

[RussianNeuroMancer]

2 hours ago, DerDave said:

I can finally upgrade then!

Keep in mind that after package upgrade you also should install new uboot release via armbian-config.