piter75

Not that I know of. I did use the same procedure with mine some time ago. It led to downgrading available mmc modes but after that it worked well for me. I will try to do it again with latest master and report back.

Thanks for verifying @Matthias! I also verified that 0x18 still works well with my unit and then settled with 0x16. I created a PR covering the change: https://github.com/armbian/build/pull/1698

AFAIK there is currently no driver for Rockchip's PCIE controller in u-boot and that's why booting from SPI/NVMe does not work. There is some work by Radxa in their own fork of Rockchip's u-boot but the support for booting from NVMe is still limited at the moment: https://wiki.radxa.com/Rockpi4/FAQs#What_M.2_SSD_are_supported.3F

@Matthias thanks for verifying that. Could you try to fiddle a bit with `rx_delay` setting on your M4V2 with current kernel? The easiest and fastest way IMHO would be to add the following line to "/boot/boot.cmd" after "fdt resize 65536" line: fdt set /ethernet@fe300000 rx_delay <0x0E> rebuilding the boot script with: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and rebooting. You could try "0x0E", "0x14" and then maybe "0x0C" and "0x16" and see if it helps to move your receiving rates into expected levels.

I hopefully managed to fix networking in legacy kernel. At least it works well on my unit now ;-) It is merged into master and downloadable images are also recreated. I am wondering whether it may have something to do with Panfrost gpu driver being not really stable yet. Maybe VNC is also using gpu to accelerate desktop drawing...

@Nobby42 @Matthias I hopefully fixed ethernet issues on legacy kernel in Armbian master. It works well on my unit. The issue with USB drives borking ethernet are also gone. Downloadable images were recreated. I also verified current (5.4.6) kernel and it does not exhibit the problems with network bandwidth in either direction - it's a strong 930-940mbps in both directions.

Did you by any chance upgade all the packages (apt upgrade) on the one that does not boot anymore? I cannot verify it now but one thing that comes to my mind is that the kernel upgrade overwritten device tree files and m4v2's u-boot points to a file that is not available in the official 19.11.3 kernel package. If that's the case you could use armbian-config to freeze the kernel and still be able to upgrade the rest of the packages.

Thanks for verifying and sharing this valuable insights. I never noticed / verified that for mainline kernels the issue exists but is opposite in direction.

@pkfox try modifying NetworkManager.conf file according to my example in earlier post. It should make the wifi work - without the need to change firmware files.

Is it still the issue that as soon as you connect UART it stops working? The other thing that does not work in 4.4.x right now is networking I was able to fix wireless with the following addition to the NetworkManager's config file. /etc/NetworkManager/NetworkManager.conf [device] wifi.scan-rand-mac-address=no Wired connection is another beast. As soon as it connects and receives IP address it becomes totally slow, unreliable and starts dropping packets. I tried to make the Frankenstein image your way (M4 image + rockpi's u-boot) and it behaves the same. OTOH FriendlyARM's image has stable wired connection and I cannot find the reason why, yet

Well... exactly. It also freezes some more packages. I am not much of a "UI" guy ;-)

@mad If you want to upgrade system and keep the wifi working through apt upgrades you can set the following packages to hold: apt-mark hold armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64 This will keep the 5.4.2 version of kernel installed. You have to remember to unhold it when the next Armbian version is released : apt-mark unhold armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64

Well... the troubles are not with the power units per se but with the combination of issues in mainline kernel for this board: lack of support for MP8859 buck-boost converter which means it always provides 5V instead of switching to 12V possible misconfiguration of FUSB302B PD chip driver used in roc-rk3399-pc If I understand the patch correctly, Markus made some modifications to the power curve of fusb302 PD chip to switch usb-c voltage to 15V when more power is needed. This should workaround power issues when powering from usb-c with pd compliant power units.

I verified and can confirm there are issues with networking on 4.4.192. LAN is not working well and WLAN cannot connect to AP. I will look into fixing that but no ETA guaranteed ;-)

That's true but you can also run the following commands. This will "upgrade" to the latest "current" kernel from Armbian release 19.11.3, which is 5.3.11. That's why I said you can downgrade via upgrading... ;-) sudo apt dist-upgrade sudo reboot

The headers package is not bundled in Armbian image and when you install it you are actually installing the last "stable" version of them in "current" target - which right now is 5.3.11 NanoPi M4V2 image was never built with 5.3.11 kernel and that's why the installed header do not match the kernel. One thing you could try as a "creative workaround" would be to upgrade kernel which will actually downgrade it to 5.3.11 and then the kernel and headers packages should match. I just did it on a freshly downloaded image for NanoPi M4V2 with kernel 5.4.2 from Armbian downloads and it worked fine, however YMMV ;-) You better test it first on a spare SD card if you already did a lot of tuning to the current install. EDIT: I assumed you downloaded my image linked a few posts back. If you did build your own image you can transfer a headers package from "output/debs" folder to you machine and install it there without the need for downgrading kernel.

Nice to see we are on the same page here 😉. My plan was to move out all rk3399 to their own family and then trying to merge back.

Rock Pi 4 works well with u-boot v2019.10 even with mainline ATF I fixed the nand-sata-install issue in master. There are still a few things I have to learn about Armbian ;-) OTOH this bug should not affect Rock Pi 4, unless you moved it to rk3399 family while testing.

@martinayotte nand-sata-install bug may be actually my fault introduced during u-boot migration. I will look into that. That is what I want to pursue next - starting with Rock Pi 4 first.

@Hover did you change the sound-dai to point to i2s0 in the following line? https://github.com/armbian/build/blob/80b757ac27f58085f8c36302a4cd45ab3caa7ae4/patch/kernel/rockchip64-current/board-nanopi-m4v2-dts-add-sound-card.patch#L22 T4's codec is connected to a different i2s bus than M4* You will have to enable i2s0 similar to what I did for i2s1 here: https://github.com/armbian/build/blob/80b757ac27f58085f8c36302a4cd45ab3caa7ae4/patch/kernel/rockchip64-current/board-nanopi-m4v2-dts-add-sound-card.patch#L64 I think you could probably replace i2s1 -> i2s0 in this node.

Sure, I was thinking about it. Feeling motivated by your message I will do that tonight

Yes. Are they needed?

@Hover I did not test bluetooth much as I find it non essential for the first rollout ;-) As for the sound you can test this patch: https://github.com/armbian/build/blob/80b757ac27f58085f8c36302a4cd45ab3caa7ae4/patch/kernel/rockchip64-current/board-nanopi-m4v2-dts-add-sound-card.patch accompanied by: CONFIG_SND_SOC_ROCKCHIP_RT5651=y CONFIG_SND_SOC_RT5651=y in the kernel config file.

A lot of credit goes also to you Once again thanks for testing the images since the beginning. As for the slow boot it plaques now all rk3399 boards. I am tempted to bring the following hack to Armbian: https://gitlab.collabora.com/rockpi/linux/commit/ea2fb5589b4cd92728a6139ee5043945d3e10173 I am using it for weeks now in my builds and don't regret it ;-)

I rebased my branch onto latest master changes. Took me some time to make the sound working in kernel 5.4. Branch is now named nanopi-m4v2-bring-up and supports "legacy", "current" and "dev" targets. Did not test "legacy" much yet but "current" 5.4 works quite well. In dev wi-fi is broken, but anyway "current" is much more compelling as it is 5.4 vs. 5.4-rc1 in dev. Command line for "current": ./compile.sh BOARD=nanopim4v2 BRANCH=current RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no