NanoPi M4 V2 - M4 Image not working


NicoD

Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

nand-sata-install as root

 

Unsupported u-boot processing configuration!


 

root@Iobroker:~# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk1     179:0    0   30G  0 disk  
└─mmcblk1p1 179:1    0 29.4G  0 part /
zram0       253:0    0   50M  0 disk /var/log
zram1       253:1    0    1G  0 disk [SWAP]

were i should found the Nvme SSD

Link to post
Share on other sites

I recently received NanoPi M4V2 and all of the current armbian NanoPi M4V2 images I tested did not boot fully- I got a blinking green LED, Ethernet link was up, but no IP address requested.

Serial console output stopped with "Starting kernel...".

 

Tested the FriendlyCore images- those did boot correctly.

Link to post
Share on other sites
9 minutes ago, martinayotte said:

To get more verbose log details, you need to edit /boot/armbianEnv.txt and change "verbosity=7" as well as "console=serial" ...

Now that is very strange... I re-flashed the same armbian image to SD card, changed the settings you suggested and see the serial console as expected, system even gets the IP address.

 

Do the default armbian settings disable serial console?

Maybe I messed up the DHCP configuration in NetworkManager on the host PC when I tried running it for the first time...

 

 

Link to post
Share on other sites
4 hours ago, reinisv said:

Do the default armbian settings disable serial console?


Serial console is enabled, but boot log goes to the HDMI by default on boards that have HDMI. You have to tell to where this output goes. In both cases you can login via console, but you have to wait until boot finishes. First one takes longer since it expends SD card/boot media. This can take a while if your media is old, big or old and big.

Link to post
Share on other sites

Hello guys,

 

V2 buster image, kernel 5.4 from an NVMe drive. It works mostly fine but I've been having a consistent issue with copying directories with large files from a USB 3 drive to the internal NVMe.  After `cp -r` the green LED of the board stops flashing and it reboots by itself.  Unfortunately I can't get logs after the reboot so I don't know how to post more info about this.

 

I never had this issue with the original board with the same USB3 ASM1051E SATA 6Gb/s bridge.

Link to post
Share on other sites
10 hours ago, TCB13 said:

Hello guys,

 

V2 buster image, kernel 5.4 from an NVMe drive. It works mostly fine but I've been having a consistent issue with copying directories with large files from a USB 3 drive to the internal NVMe.  After `cp -r` the green LED of the board stops flashing and it reboots by itself.  Unfortunately I can't get logs after the reboot so I don't know how to post more info about this.

 

I never had this issue with the original board with the same hard drives.

 

@Igor I just noticed that you had some info about this problem before here:

 

Is there any fix for this? I never had with this issue with a original board, using the same USB3 ASM1051E SATA 6Gb/s bridge :(

 

What about you @NicoD , since you're always running nice tests, have you experienced such issues?

 

Link to post
Share on other sites
46 minutes ago, TCB13 said:

To make the network work properly under load and some protocols like HTTPS and NFS I have to run:


ethtool -K eth0 rx off tx off

after the network is up. This issue seems to affect both the original M4 and the v2 with all kernels.

Did you build the kernel yourself?

I have committed a fix (https://github.com/armbian/build/commit/8c93385a84e2c8847ad5cf03684bee9c58596bf7) to the build system a few days ago. It should fix issues with the most common MTU of 1500.

It will be build into some future kernel / image build.

Link to post
Share on other sites

I've also notice some random reboots / maybe crashes without logs:

 

Quote

Jan 16 01:38:11 localhost kernel: [ 95.592186] Bluetooth: L2CAP socket layer initialized
Jan 16 01:38:11 localhost kernel: [ 95.592200] Bluetooth: SCO socket layer initialized
Jan 16 01:38:11 localhost kernel: [ 95.593656] Bluetooth: HCI UART driver ver 2.3
Jan 16 01:38:22 localhost kernel: [ 106.182318] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: errors=remount-ro,data=ordered
Jan 16 14:17:03 localhost kernel: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Jan 16 14:17:03 localhost kernel: [ 0.000000] Linux version 5.4.7-rockchip64 (root@builder) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-201
9.03 (arm-rel-8.36))) #19.11.5 SMP PREEMPT Wed Jan 1 09:39:17 CET 2020
Jan 16 14:17:03 localhost kernel: [ 0.000000] Machine model: FriendlyElec NanoPi M4 Ver2.0

As you can see it was running fine without any messages at 1:38 am and them it later rebooted by itself at 2:17 pm without logging anything.

 

Link to post
Share on other sites
6 hours ago, TCB13 said:

What about you @NicoD , since you're always running nice tests, have you experienced such issues?

 

I do not use ethernet since I do not have a connection in my work area. So I was not aware of this. Good to see there's already a fix for it.


Please provide the output of :

armbianmonitor -u

for more info.
 

 

17 hours ago, TCB13 said:

I've been having a consistent issue with copying directories with large files from a USB 3 drive to the internal NVMe. 

Could you be a bit more precise please. What file size is large? Is this with every USB3 device the same? How are both drives formatted? Is the USB3 drive powered by the M4?

Link to post
Share on other sites
2 hours ago, NicoD said:

I do not use ethernet since I do not have a connection in my work area. So I was not aware of this. Good to see there's already a fix for it.


Please provide the output of :


armbianmonitor -u

for more info.
 

 

Could you be a bit more precise please. What file size is large? Is this with every USB3 device the same? How are both drives formatted? Is the USB3 drive powered by the M4?

 

Hi,

 

About the Ethernet: as expected I was able to fix it by disabling tcp offload.

 

Now about the hard drive: It's a SATA hard drive connected via a USB 3 ASM1051E SATA bridge. The disk has its own power supply and if I connect it to my old M4 (the original one) I'm able to copy GB of data without issues, however in the M4v2 the board restarts itself. I guess since it works fine on the old M4 it is safe to assume that the issue is on the new board and/or kernel. The only difference here is that the old board is runing a 4.X kernel while the new one is running 5.X.

 

Link to post
Share on other sites
8 minutes ago, TCB13 said:

Now about the hard drive: It's a SATA hard drive connected via a USB 3 ASM1051E SATA bridge. The disk has its own power supply and if I connect it to my old M4 (the original one) I'm able to copy GB of data without issues, however in the M4v2 the board restarts itself. I guess since it works fine on the old M4 it is safe to assume that the issue is on the new board and/or kernel. The only difference here is that the old board is runing a 4.X kernel while the new one is running 5.X.

As @piter75 commented. Try the 4.x image. I'm using the M4V2 with 4.x for a while and haven't had any issues like that. I often copy big files of GB's to my externel USB HD.  
So I do not think the issue is with the M4V2, but might be with 5.x instead. Mainline kernel is still a work in progress.

Link to post
Share on other sites

@piter75 and @NicoD as you guys suggested I decided to try the 4.x image and it works just fine! Look like there are bugs in the 5.x image. Thank you.

 

PS: I tried to downgrade the kernel using armbian-config and my system never booted again :P had to do a fresh install. I've noticed that the CPU in the 5.x image was running up to 2.02Ghz on the big cores, with the 4.x image seems to be a cap at 1.80Ghz.

 

Link to post
Share on other sites
4 hours ago, TCB13 said:

as you guys suggested I decided to try the 4.x image and it works just fine! Look like there are bugs in the 5.x image. Thank you.

Thanks for verifying. Now we have one less variable in this equation.

Would you be able to spare some more time and test the same scenario with 5.x on NanoPi M4?

Link to post
Share on other sites
7 hours ago, TCB13 said:

@piter75 and @NicoD as you guys suggested I decided to try the 4.x image and it works just fine! Look like there are bugs in the 5.x image. Thank you.

Interesting, I also had problems copying files using the 5.4 kernel on my NanoPi M4V2. I compiled it myself and copies files from the sd-card to and external hard drive connected via the SATA-hat. I used file systems on the hard drive that were able to detect corrupted data on the drive (ZFS and BTRFS) and every time I did a scrub after copying the files, failed CRC-checks within the data were reported, some of them even at the same position on two redundant drives (mirror).

 

I'll try again with the legacy kernel (4.x). Would be greate if it works in this configuration. @piter75: Did you apply your fixes for ethernet also to the legacy kernel? Then it would be much easier to get the data onto the device in the first place.

Link to post
Share on other sites
11 minutes ago, Matthias said:

@piter75: Did you apply your fixes for ethernet also to the legacy kernel? Then it would be much easier to get the data onto the device in the first place.

Oh... I somehow fixed my mind on the fact that it was working properly with 4.4 and fixed it only in "current" and "dev".

I will verify it with 4.4 and try to fix if needed.

Link to post
Share on other sites
4 hours ago, piter75 said:

Thanks for verifying. Now we have one less variable in this equation.

Would you be able to spare some more time and test the same scenario with 5.x on NanoPi M4?

 

Yes I will, but only in a few days. I'll report as soon as I have new information.

Link to post
Share on other sites
1 hour ago, piter75 said:

Oh... I somehow fixed my mind on the fact that it was working properly with 4.4 and fixed it only in "current" and "dev".

I will verify it with 4.4 and try to fix if needed.

Don't worry. I remember darkly that when I tested it one month ago the legacy kernel was good at receiving and bad at sending while the current kernel was cood at sending and bad at receiving. See here:

 

Link to post
Share on other sites
On 1/16/2020 at 1:58 AM, TCB13 said:

Hello guys,

 

V2 buster image, kernel 5.4 from an NVMe drive. It works mostly fine but I've been having a consistent issue with copying directories with large files from a USB 3 drive to the internal NVMe.  After `cp -r` the green LED of the board stops flashing and it reboots by itself.  Unfortunately I can't get logs after the reboot so I don't know how to post more info about this.

 

I never had this issue with the original board with the same USB3 ASM1051E SATA 6Gb/s bridge.

Hi,

I have had formative experience with the NanoPI M4v2..
First, you need a real power supply. The Rasbberry 4 power supply for example breaks down when using a NMVe and a SSD, at high load, to below 5V (approx. 4.8V - 4.7V).
2. the CPU frequency. I think the 1.5/2Ghz is too much. I have had several crashes. For example the NanoPi crashes when transferring large amounts of data, sometimes processes (kworker, sshd, ...) just crashed and sometimes the NanoPi just stopped. Since I use the frequency to 1.4/1.8Ghz and a similar power supply, it looks like the NanoPI runs stable with NMVe and USB SSD.  Currently I am using the NanoPi as a file server, MQTT Broker and nextcloud server and haven't had any crashes for 4 days.

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...