JeremyA

I've just got a shiny new NanoPC-T6 and can get it to sort of work using a Debian image provided by the Vendor. One issue is the HDMI output which seems to be quite unusual. I can only get one of my monitors to display an image (a 4K philips) . The usual 1920x1080 screens such as Acer 22" don't work. It also seems the Debian version can only run an overlay driver rather than native I already run a NanoPi M4V2 and a NanoPi R2S under Armbian and am very happy with them and armbian I'm happy to be a guinea pig for anyone wanting to get an armbian version running on the T6. I have some respectable machines that can do cross-compiles quite fast. I want to get the device to run fully native drivers and specifically have full control over the NPU cores for hard-core image applications.

I found this post to be very helpful https://forum.armbian.com/topic/7511-nanopi-m4/?do=findComment&comment=92709 The code works well. However, edit the low temperature to something under room temperature so you can check the fan starts. To check this Run the program in the compile directory before you install it as a service. Then put it the temperature back to some reasonable figure and install it as a service and enable the service. The new fancontrol is installed in /usr/bin/fancontrol I found another file /usr/sbin/fancontrol. That seems to be a shell script. It may be helpful to rename it to avoid interfering with the new fancontrol

I am searching for the cause of my m4v2 fan not running (and from the lack of dust it's possible it's never been running). I have the metal case and NVME adpator board. The fan is controlled by channel PWM1 in the NVME adaptor. I checked my fan connector and found 0V which I assume means it's running at 0% PWM or the mosfet has failed. I have attempted to use the code from https://cgomesu.com/blog/Nanopi-m4-mini-nas/#pwm-fan-controller and got That's as far as I have got. I imagine there is some process already in place to control that PWM pin? But I don't know how to identify it. There is of course the option to hard wire the fan into the 5V supply on the main I/O connector. This will run 24/7 at reduced speed, which by reports is very quiet but effective.

armbianmonitor -u http://ix.io/4eJI

lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye hwinfo --disk 20: PCI 00.0: 10600 Disk [Created at block.245] Unique ID: wLCS.EJHvc9MwvZ7 Parent ID: VCu0.AxGd7hiuG+6 SysFS ID: /class/block/nvme0n1 SysFS BusID: nvme0 SysFS Device Link: /devices/platform/f8000000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/nvme/nvme0 Hardware Class: disk Model: "Samsung Electronics NVMe SSD Controller SM981/PM981/PM983" Vendor: pci 0x144d "Samsung Electronics Co Ltd" Device: pci 0xa808 "NVMe SSD Controller SM981/PM981/PM983" SubVendor: pci 0x144d "Samsung Electronics Co Ltd" SubDevice: pci 0xa801 Driver: "nvme" Driver Modules: "nvme" Device File: /dev/nvme0n1 Device Files: /dev/nvme0n1, /dev/disk/by-id/nvme-eui.002538540142ff22, /dev/disk/by-path/platform-f8000000.pcie-pci-0000:01:00.0-nvme-1, /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_Plus_250GB_S4EUNJ0N451054H Device Number: block 259:0 Geometry (Logical): CHS 238475/64/32 Size: 488397168 sectors a 512 bytes Capacity: 232 GB (250059350016 bytes) Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #1 (Non-Volatile memory controller) 21: None 00.0: 10600 Disk [Created at block.245] Unique ID: kLao.Fxp0d3BezAE Parent ID: OBK3._NN+DZ1HDn4 SysFS ID: /class/block/mmcblk1 SysFS BusID: mmc1:aaaa SysFS Device Link: /devices/platform/fe320000.mmc/mmc_host/mmc1/mmc1:aaaa Hardware Class: disk Model: "Disk" Driver: "dwmmc_rockchip", "mmcblk" Device File: /dev/mmcblk1 Device Files: /dev/mmcblk1, /dev/disk/by-path/platform-fe320000.mmc, /dev/disk/by-id/mmc-SC16G_0xe2e82a63 Device Number: block 179:0-179:31 Geometry (Logical): CHS 486192/4/16 Size: 31116288 sectors a 512 bytes Capacity: 14 GB (15931539456 bytes) Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #15 (MMC Controller) lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk1 179:0 0 14.8G 0 disk └─mmcblk1p1 179:1 0 14.7G 0 part /media/mmcboot nvme0n1 259:0 0 232.9G 0 disk └─nvme0n1p1 259:1 0 232.9G 0 part / hdparm -t --direct /dev/nvme0n1p1 /dev/nvme0n1p1: Timing O_DIRECT disk reads: 1088 MB in 3.00 seconds = 362.25 MB/sec In comparison I have seen reports of other Rockchip systems with speeds around 1500 MB/sec. The drive is a Samsumg 970 EvoPlus

I have been using Armbian on the R2S with an uptime of weeks without any LAN issues at all. Look back earlier in this thread where I documented the steps required to get a stable router using Armbian

As an update, the target NanoPi R2S system has been up for 22 days now without issue. I'm using the black metal case and my ambient temperature is 29C (local summer with no aircon). The CPU temperature is 58C running a 50Mbps uplink. I realise the CPU temperature isn't strictly relevant to armbian, but it's indicative of the performance of the R2S under Armbian in the router role. From my point of view the R2S under slightly modified armbian is a very usable approach to firewall and routing.

I have a Nanopi R2s but this is generic to most boards without an inbuilt battery backed RTC. I have added a battery backed 1307 module on the I2C bus and gone through the process of getting it recogised and used. As far as it goes that's fine. The problem is the RTC is only read late in the boot process so the first part of the syslog record has incorrect date and time. Is there any way to force systemd to process the 1307 at the very start? I tried hacking the non-battery backed RTC script but it didn't take. Another option is to get the pre-systemd processes to read from the 1307 and set the inbuilt RTC before systemd starts using it? Suggestions appreciated.

One side effect I have noticed from the upgrade to 21.02.0 trunk is logging to /var/log/messages has ceased. Is this expected? Or how do I re-enable the logging?

I did the install of the latest armbian build and the device is now rock solid, no reboots after 18 hours - compared to between one and four hours to failure before the upgrade. For the benefit of others who wish to repeat the process here are my install steps. I used a fairly powerful debian buster desktop to do the build but it still took some time, maybe half an hour including download time? I chose to only build the kernel elements by answering the prompts from the build script compile.sh cd /usr/src/ git clone --depth 1 https://github.com/armbian/build mv build build-armbian cd build-armbian/ ./compile.sh docker cd /usr/src/build-armbian/output/debs scp *.deb root@192.168.0.1:~ ssh root@192.168.0.1 dpkg -i armbian-firmware-full_21.02.0-trunk_all.deb linux-dtb-current-rockchip64_21.02.0-trunk_arm64.deb linux-image-current-rockchip64_21.02.0-trunk_arm64.deb linux-u-boot-current-nanopi-r2s_21.02.0-trunk_arm64.deb systemctl reboot

How can I revert the driver on my system?

This workaround is effective to detect the failure of the r8152 interface (lan0) and cleanly restart the system. Create a file /root/checklan.sh and make it executable. #!/bin/bash log=/root/restarts.txt ip a | grep -q lan0 if [[ $? != 0 ]]; then date >> $log systemctl reboot fi Run this with a crontab -e entry of * * * * * /root/checklan.sh This will check the lan0 interface every minute. NB it will also log into syslog each minute. To prevent clutter edit /etc/rsyslog.conf to have the following two lines (insert cron into the auth line and add the cron.* line) *.*;cron,auth,authpriv.none -/var/log/syslog cron.* /var/log/cron.log This means all cron logging goes into /var/log/cron.log and none into /var/log/syslog Activate the logging changes with systemctl restart rsyslog Logrotate already comes configured to rotate /var/log/cron.log so no changes required The file /root/restarts.txt gives an accurate record of when and how often the interface fails. My system has a failure after a few hours but the distribution is random from minutes to many hours.

I tried the nightly path. It all loaded O.K. but the network fault appeared within a few minutes, so not as stable as 'stable'. Reversion seems to have worked and my present plan is to write a script to reboot when lan0 ceases to exist. In the past few days that's every few hours. I did see that before I set the device up as a router it stayed up indefinitely

I'm a bit uncertain about the process. I assume you mean install the latest kernel? I've been to the Armbian R2S page https://www.armbian.com/nanopi-r2s/ but it appears I can only download a complete system image, while what I think I want to do is install a new kernel. Where should I look for a nightly release kernel package to download?

I have the same problem with my R2S. I have tried the giox069 suggestion using ethtool but lan0 is still dropping out. I have to reboot the machine to regain lan0 This is the output of armbianmonitor -u http://ix.io/2Gs5 This is the start of the kernel log where the error occurs: Dec 4 15:33:48 firewall kernel: [17897.537194] ------------[ cut here ]------------ Dec 4 15:33:48 firewall kernel: [17897.537249] NETDEV WATCHDOG: lan0 (r8152): transmit queue 0 timed out Dec 4 15:33:48 firewall kernel: [17897.537364] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x39c/0x3a8 Dec 4 15:33:48 firewall kernel: [17897.537370] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth rfkill zstd r8152 hantro_vpu(C) v4l2_h264 videobuf2_dma_contig v4l2_mem2mem videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ip6t_rt cpufreq_dt xt_tcpudp xt_state xt_conntrack nft_counter zram nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink usb_f_acm u_serial g_serial libcomposite ip_tables x_tables autofs4 realtek dwmac_rk stmmac_platform stmmac mdio_xpcs gpio_syscon Dec 4 15:33:48 firewall kernel: [17897.537493] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 5.8.17-rockchip64 #20.08.21 Dec 4 15:33:48 firewall kernel: [17897.537499] Hardware name: FriendlyElec NanoPi R2S (DT) Dec 4 15:33:48 firewall kernel: [17897.537509] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) Dec 4 15:33:48 firewall kernel: [17897.537519] pc : dev_watchdog+0x39c/0x3a8 Dec 4 15:33:48 firewall kernel: [17897.537528] lr : dev_watchdog+0x39c/0x3a8 Dec 4 15:33:48 firewall kernel: [17897.537533] sp : ffff800011abbd10 Dec 4 15:33:48 firewall kernel: [17897.537538] x29: ffff800011abbd10 x28: ffff000022a1fa80 Dec 4 15:33:48 firewall kernel: [17897.537549] x27: 0000000000000004 x26: 0000000000000140 Dec 4 15:33:48 firewall kernel: [17897.537559] x25: 00000000ffffffff x24: 0000000000000000 Dec 4 15:33:48 firewall kernel: [17897.537569] x23: ffff000032d793dc x22: ffff000032d79000 Dec 4 15:33:48 firewall kernel: [17897.537578] x21: ffff000032d79480 x20: ffff800011807000 Dec 4 15:33:48 firewall kernel: [17897.537587] x19: 0000000000000000 x18: 0000000000000000 Dec 4 15:33:48 firewall kernel: [17897.537597] x17: 0000000000000000 x16: 0000000000000000 Dec 4 15:33:48 firewall kernel: [17897.537606] x15: ffff80001182e000 x14: ffff800011a1d23a Dec 4 15:33:48 firewall kernel: [17897.537616] x13: 0000000000000000 x12: ffff800011a1c000 Dec 4 15:33:48 firewall kernel: [17897.537625] x11: ffff80001182e000 x10: ffff800011a1c880 Dec 4 15:33:48 firewall kernel: [17897.537635] x9 : 0000000000000000 x8 : 0000000000000001 Dec 4 15:33:48 firewall kernel: [17897.537644] x7 : 00000000000001b9 x6 : 0000000000000003 Dec 4 15:33:48 firewall kernel: [17897.537653] x5 : 0000000000000000 x4 : 0000000000000000 Dec 4 15:33:48 firewall kernel: [17897.537662] x3 : ffff80001180d020 x2 : 0000000000000103 Dec 4 15:33:48 firewall kernel: [17897.537671] x1 : fdf502529fc7a700 x0 : 0000000000000000 Dec 4 15:33:48 firewall kernel: [17897.537681] Call trace: Dec 4 15:33:48 firewall kernel: [17897.537693] dev_watchdog+0x39c/0x3a8 Dec 4 15:33:48 firewall kernel: [17897.537705] call_timer_fn+0x30/0x1e0 Dec 4 15:33:48 firewall kernel: [17897.537715] run_timer_softirq+0x1e0/0x5b0 Dec 4 15:33:48 firewall kernel: [17897.537725] efi_header_end+0x16c/0x400 Dec 4 15:33:48 firewall kernel: [17897.537734] irq_exit+0xc8/0xe0 Dec 4 15:33:48 firewall kernel: [17897.537744] __handle_domain_irq+0x98/0x108 Dec 4 15:33:48 firewall kernel: [17897.537757] gic_handle_irq+0x54/0xa8 Dec 4 15:33:48 firewall kernel: [17897.537765] el1_irq+0xb8/0x180 Dec 4 15:33:48 firewall kernel: [17897.537776] arch_cpu_idle+0x28/0x218 Dec 4 15:33:48 firewall kernel: [17897.537788] default_idle_call+0x1c/0x44 Dec 4 15:33:48 firewall kernel: [17897.537797] do_idle+0x210/0x288 Dec 4 15:33:48 firewall kernel: [17897.537806] cpu_startup_entry+0x24/0x68 Dec 4 15:33:48 firewall kernel: [17897.537815] rest_init+0xd8/0xe8 Dec 4 15:33:48 firewall kernel: [17897.537825] arch_call_rest_init+0x10/0x1c Dec 4 15:33:48 firewall kernel: [17897.537833] start_kernel+0x7f0/0x82c Dec 4 15:33:48 firewall kernel: [17897.537839] ---[ end trace bb9026d51506ff19 ]---