Jump to content

NanoPI M4


mindee

Recommended Posts

your questions are probably better in their forum/supportplace.. this is about armbian and not friendlyarm crafted images.

 

59 minutes ago, SriLK said:

This would help a lot, since I could backup directly the rootfs partitions with rkflashkit, mount it in my linux box, modify it and flash it back to the emmc again with rkflashkit. Very straight forward! 

https://www.innet24.de/Makerspace/Single-Board-Computer/FriendlyELEC/FriendlyELEC-MicroSD-to-eMMC-adapter::148975.html

 

even more straight forward.. :P  I think they sell those also in their own shop.

Link to comment
Share on other sites

14 minutes ago, chwe said:

your questions are probably better in their forum/supportplace.. this is about armbian and not friendlyarm crafted images.

 

https://www.innet24.de/Makerspace/Single-Board-Computer/FriendlyELEC/FriendlyELEC-MicroSD-to-eMMC-adapter::148975.html

 

even more straight forward.. :P  I think they sell those also in their own shop.

 

Exactly with that converter (connecting the emmc to my PC) I have taken the backup with dd at my linux box... But, as said in the previous posts, the problem is that I can not mount the image produced while backing the emmc.

 

Also, this is not about friendlyarm crafted images, but about MASKROM mode on the M4 and/or extract partitions from emmc image backups  generated by final users (friendlyarm image is just anecdotical fact). Explanation/solutions will work for all users whatever OS.

 

Thanks!

Link to comment
Share on other sites

3 minutes ago, chwe said:

armbian has a simple partition scheme.. were https://unix.stackexchange.com/questions/316401/how-to-mount-a-disk-image-from-the-command-line always works (we use one or max 2 partitions, so things are easy)... whereas those images crafted with rockchips partition scheme thingie are always a pain..

I get your point. So, I can not mount the emmc image from backup because of the partition scheme. With armbian I could mount the partitions without any issue directly from the emmc image backup if I understand you correctly. That's good to know! Indeed this weird friendlyarm partition scheme is pain in the ass. (Solutions still welcome, tho)

 

Anyway: MASKROM question is what I am much more interested :-)

Link to comment
Share on other sites

1 minute ago, SriLK said:

I get your point. So, I can not mount the emmc image from backup because of the partition scheme.

no my point is that probably not that many people here are experienced with the 'android partitionscheme' that's were this stuff came from originally.. if you get the right one with a proper offset I don't see a reason why it should not work (doesn't mean that there is none as said, not that experienced in those, I only did it when I had to dump a fdt file long time ago)..

 

 

Link to comment
Share on other sites

2 hours ago, chwe said:

no my point is that probably not that many people here are experienced with the 'android partitionscheme' that's were this stuff came from originally.. if you get the right one with a proper offset I don't see a reason why it should not work (doesn't mean that there is none as said, not that experienced in those, I only did it when I had to dump a fdt file long time ago)..

 

 

Thank you for your comment, chwe. You know how to motivate :-)

 

I just installed latest stable Armbian (debian stretch) to my M4 and work very nicely. Easy installation, no need sdcard since it flashes directly to emmc. And much easier everything. Emmc can be mounted exactly as it is (read or read/write) in any Linux box supporting ext4 at any time with no complications/investigations. Indeed this is the way to go. I really don't understand why friendlyarm needed to complicate things so badly with the ubuntu-core emmc partition scheme.

 

I will continue with Armbian for now on. Still, I have important files at my previous installation since it was a home server which I would like to migrate. And so, I'm still very interested in solution for this post: 

 

Mostly about entering MASKROM mode or RECOVERY mode, short-ing the correct points. My plan now is to extract old friendlyarm ubuntu core rootfs partition with rkflashkit, mount it, get the important/needed files and feed them to the M4 running Armbian Debian Stretch.

 

 Can anyone with this? :-)

Link to comment
Share on other sites

6 hours ago, SriLK said:

Mostly about entering MASKROM mode or RECOVERY mode, short-ing the correct points. My plan now is to extract old friendlyarm ubuntu core rootfs partition with rkflashkit, mount it, get the important/needed files and feed them to the M4 running Armbian Debian Stretch.

 

 Can anyone with this? :-)

Get a NanoPC-T4, which has handy pushbuttons? The NanoPC-T4 schematic sheet 17 has its "boot" button (ground EMMC_D0, essentially); sheet 26 has the "recovery" button (ground ball AH 26/ADC_IN1). EMMC_D0 is pin 1 of the NanoPi M4's eMMC header - a bit tough to reach, given its surface mounting on both the M4 and the eMMC module. The best way would be via a (presumably custom) module inserted between the M4 and the eMMC module, but that's a bit of work, unless you plan to do it a lot(!). Using the solder pad(s) should be possible if you have a finely pointed contact and a steady hand. Good luck, as a bad slip could cost $100. As for recovery mode, finding a particular ball or trace would make dealing with the surface-mounted eMMC header look super easy.

Kinda odd - am I missing them, or does the M4 have no buttons at all?

Edit: Hm. Not sure how suppressing the eMMC on boot helps you. But hey.

Edited by pfry
Added question/statement at end.
Link to comment
Share on other sites

16 hours ago, pfry said:

Get a NanoPC-T4, which has handy pushbuttons? The NanoPC-T4 schematic sheet 17 has its "boot" button (ground EMMC_D0, essentially); sheet 26 has the "recovery" button (ground ball AH 26/ADC_IN1). EMMC_D0 is pin 1 of the NanoPi M4's eMMC header - a bit tough to reach, given its surface mounting on both the M4 and the eMMC module. The best way would be via a (presumably custom) module inserted between the M4 and the eMMC module, but that's a bit of work, unless you plan to do it a lot(!). Using the solder pad(s) should be possible if you have a finely pointed contact and a steady hand. Good luck, as a bad slip could cost $100. As for recovery mode, finding a particular ball or trace would make dealing with the surface-mounted eMMC header look super easy.

Kinda odd - am I missing them, or does the M4 have no buttons at all?

Edit: Hm. Not sure how suppressing the eMMC on boot helps you. But hey.

 

Yesterday I connected two wires, one to GND and another to eMMC header base's pin EMMC_CLKO.  After that, shorting them as I connect USB-C  and releasing in couple of seconds showed the device in the rkflashkit, but curiously eMMC partitions didn't  get populated to the rkflashkit. I tried several shorting times at boot with no difference... So, what you say in the edit might be true. Tested that eMMc and yes, it works with Armbian fresh installation, and it looked good, so no damage done.

 

Anyway, I will try now shorting EMMC_D0 to GND. Found the R35 at board (at top layer ->  top-right  from WIFI-BT chip). Only thing now is to find out which side is connected to ADC_IN1 and which one to VCCA1V8_S3. I see that there are many capacitors connected to VCCA1V8_S3... but looking directly to the PCB I find none. I wonder if I can find a good CAD file for the actual PCB with symbols for the NanoPi M4. I tried this one: http://wiki.friendlyarm.com/wiki/images/e/e4/NanoPi-M4-1807_Drawing(dxf).zip but it looks not very detailed to me (maybe my CAD software is not good enough for opening this format version??), It doesn't seem to contain much more info than the one at http://wiki.friendlyarm.com/wiki/images/4/41/NanoPi_M4_1807_Drawing.png . Does anybody knows if/where I can find the full CAD file for PCB with the symbols for the NanoPi M4?

 

Well, I'll keep informed and post some photos if I achieve any goal here... I mean, maybe the photos with the actual solding of the switches (Boot, Recovery, maskrom). Maskrom switch I have already, in place but... worthless, as said at the start.

 

Thanks for help

 

BTW, when I was buying this M4 I was deciding if to buy M4 or T4... price was mostly the same for the configuration chosen. I decided to go for M4 because of the detachable eMMC and the writer/reader interface to USB. This make things much easier and in theory you would not need recovery, boot or maskrom ever. But... friendly arm had this "surprise" waiting for me: I could not mount easily the partitions contained in my eMMC. My mistake and lesson learned: Armbian does not do those NASTY things and does things as should be done: partitions at eMMC are standard and fdisk -l , so they mount ok and image reports also correct information and can be mounted on loop mode in any system. So, happy that I bought M4... still, I need my old files from Friendly core ubuntu installation :-)

Link to comment
Share on other sites

On 4/15/2019 at 6:54 PM, SriLK said:

Yesterday I connected two wires, one to GND and another to eMMC header base's pin EMMC_CLKO.  After that, shorting them as I connect USB-C  and releasing in couple of seconds showed the device in the rkflashkit, but curiously eMMC partitions didn't  get populated to the rkflashkit. I tried several shorting times at boot with no difference... So, what you say in the edit might be true. Tested that eMMc and yes, it works with Armbian fresh installation, and it looked good, so no damage done.

 

Anyway, I will try now shorting EMMC_D0 to GND. Found the R35 at board (at top layer ->  top-right  from WIFI-BT chip). Only thing now is to find out which side is connected to ADC_IN1 and which one to VCCA1V8_S3. I see that there are many capacitors connected to VCCA1V8_S3... but looking directly to the PCB I find none. I wonder if I can find a good CAD file for the actual PCB with symbols for the NanoPi M4. I tried this one: http://wiki.friendlyarm.com/wiki/images/e/e4/NanoPi-M4-1807_Drawing(dxf).zip but it looks not very detailed to me (maybe my CAD software is not good enough for opening this format version??), It doesn't seem to contain much more info than the one at http://wiki.friendlyarm.com/wiki/images/4/41/NanoPi_M4_1807_Drawing.png . Does anybody knows if/where I can find the full CAD file for PCB with the symbols for the NanoPi M4?

 

Well, I'll keep informed and post some photos if I achieve any goal here... I mean, maybe the photos with the actual solding of the switches (Boot, Recovery, maskrom). Maskrom switch I have already, in place but... worthless, as said at the start.

 

Thanks for help

 

BTW, when I was buying this M4 I was deciding if to buy M4 or T4... price was mostly the same for the configuration chosen. I decided to go for M4 because of the detachable eMMC and the writer/reader interface to USB. This make things much easier and in theory you would not need recovery, boot or maskrom ever. But... friendly arm had this "surprise" waiting for me: I could not mount easily the partitions contained in my eMMC. My mistake and lesson learned: Armbian does not do those NASTY things and does things as should be done: partitions at eMMC are standard and fdisk -l , so they mount ok and image reports also correct information and can be mounted on loop mode in any system. So, happy that I bought M4... still, I need my old files from Friendly core ubuntu installation :-)

 

It worked! Shorting the recovery (ADC_IN1) point to GND entered successfully into recovery. rkflashkit inmediately got the device and partitions got populated to the program. Backup-ed rootfs and then I extracted the files.

 

Here the ADC_IN1 point to short to GND (GND can be found easily in the board at the public FriendlyCore published photos). I identified the correct side in the R35 for ADC_IN1 by measuring the voltage: around 1.72V, while the other side's reading was exactly 1.8V (what is was suppossed to have the VCCA1V8_S3)

image.thumb.png.c241ba0c25e3fa3ff677e514bf75fe07.png

 

BTW, if anyone want to solder that... beware, It is very very small and needs special tools/hands. It took to me 30 minutes just the preparation, before even applying any heat to the union of the wire/resistor ending. anyway... with a needle connected to a wire (which is connected to GND in the other side) would be easier. Touching ADC_IN1 with the end of the needle while powering up seems to be not so difficult (a magnifier lens will help also)

 

I also connected the Header pins 1 (EMMC_D0) for boot and pin 12 (EMMC_CLKO) for maskrom. Maskrom didn't work so well as told yesterday. And since recovery worked, Boot I haven't even tried. if anyone interested in feedback about this point/switch, then just ask!

 

Happy ending! From now my NanoPC M4 will stay in the bright side of life: Armbian

 

Thanks everyone, specially pfry who is the one bringing the recovery (ADC_IN1) info and chwe for clear and straight forward mind :-)

Link to comment
Share on other sites

9 minutes ago, pfry said:

Nice work. You're even crazier than I am. And your soldering skills are obviously superior to mine.

I said I do it, and I do it... no matter what... those files were too much valuable for m, and now they are back under my control:-)

 

And well, I got some tricks for soldering: solder paste  (something like Sn42/Bi57.6/Ag0.4), Hot air SMD solder and big magnifier lens.... with that, solding skills are not so important. Not expensive eigther!

Link to comment
Share on other sites

On 4/14/2019 at 1:47 PM, SriLK said:

...

Ok, 1st thing I backed emmc to an image (dd)

Then I started to try to access the rootfs partition, in order to modify the /etc/fstab ... without success!

The emmc should have this structure:


0x00002000@0x00002000(uboot),
0x00002000@0x00004000(trust),
0x00002000@0x00006000(misc),
0x00006000@0x00008000(resource),
0x00010000@0x0000e000(kernel),
0x00010000@0x0001e000(boot),
-@0x00030000(rootfs) consoleblank=0

So, I tried mounting from backup image:

mount -t ext4 m4-image /media/img/ -o loop,offset=100663296  (offset for rootfs should be 0x30000 * 512)

and fails with "wrong fs type"

then I list the image's structure with: fdisk -l m4-image


Device         Boot   Start      End  Sectors  Size Id Type
m4-image1           3342336 15234373 11892038  5.7G 83 Linux
m4-image2            196608  3342335  3145728  1.5G 83 Linux

So... I try m4-image1 partition instead:

mount -t ext4 m4-image /media/img/ -o loop,offset=1811939328  (offset for rootfs should be 3342336 * 512 + 0x30000 * 512, in case rootfs is inside m4-image1 partition?)

same error as before, "wrong fs type"

....

 

I recovered all the files from my unbootable M4 EMMC and got my server back on with same functionality as before. Once done I wanted to know why I couldn't mount the raw image partitions backed up with friendlyarm's eflasher utility (or directly with dd from my Linux box of the eMMC connected with the USB-EMMC interface supplied by Friendlyarm)... that had been much easier!

 

After some investigation, the secret here WAS that there is a extra 4MB offset to add to the informed offsets. This is the calculations done

 

rkflashkit log:

	uboot        (0x00002000 @ 0x00002000)    4 MiB
	trust        (0x00002000 @ 0x00004000)    4 MiB
	misc         (0x00002000 @ 0x00006000)    4 MiB
	resource     (0x00006000 @ 0x00008000)   12 MiB
	kernel       (0x00010000 @ 0x0000E000)   32 MiB
	boot         (0x00010000 @ 0x0001E000)   32 MiB
	rootfs       (0x01CEF000 @ 0x00030000) 14814 MiB

Offsets once mounted as recovery. Hexs are in 512 Byte blocks, so:

0x00030000 = 196608 = x*1024*1024/512; x= 96Mb = 100663296 B

rootfs actual offset at raw image:

0x6400000 = 104857600 B = 100 MB

So, for rootfs:

sudo mount -o loop,offset=104857600 -t ext4 friendlycore-bionic-4.4.raw.img /media/img/

Diff offset to add to the informed offset by recovery = 4mb 

example for partition boot:
0x0001E000 = 122880 = x*1024*1024/512; x= 60Mb 
raw image real offset for boot = 60 + 4 = 64Mb = 67108864 B

Summarizing: for mounting the rootsfs partition contained in the raw image (containing a Friendlyarm distributed linux OS), what is needed to do is:

 

sudo mount -o loop,offset=104857600 -t ext4 friendlycore-bionic-4.4.raw.img /media/img/

 

I thought that somebody might be in the same situation as the one I was in my 1st post. AND, if that somebody is not able to enter recovery mode by shorting the ADC_IN1 (R35) point to GND while connecting the USB Type-C, them, might prefer to extract the files by mounting the rootfs partition. Or even make changes directly there.

 

Thats all!

 

 

Link to comment
Share on other sites

On 4/23/2019 at 8:55 PM, SriLK said:

 

I recovered all the files from my unbootable M4 EMMC and got my server back on with same functionality as before. Once done I wanted to know why I couldn't mount the raw image partitions backed up with friendlyarm's eflasher utility (or directly with dd from my Linux box of the eMMC connected with the USB-EMMC interface supplied by Friendlyarm)... that had been much easier!

 

After some investigation, the secret here WAS that there is a extra 4MB offset to add to the informed offsets. This is the calculations done

 


rkflashkit log:

	uboot        (0x00002000 @ 0x00002000)    4 MiB
	trust        (0x00002000 @ 0x00004000)    4 MiB
	misc         (0x00002000 @ 0x00006000)    4 MiB
	resource     (0x00006000 @ 0x00008000)   12 MiB
	kernel       (0x00010000 @ 0x0000E000)   32 MiB
	boot         (0x00010000 @ 0x0001E000)   32 MiB
	rootfs       (0x01CEF000 @ 0x00030000) 14814 MiB

Offsets once mounted as recovery. Hexs are in 512 Byte blocks, so:

0x00030000 = 196608 = x*1024*1024/512; x= 96Mb = 100663296 B

rootfs actual offset at raw image:

0x6400000 = 104857600 B = 100 MB

So, for rootfs:

sudo mount -o loop,offset=104857600 -t ext4 friendlycore-bionic-4.4.raw.img /media/img/

Diff offset to add to the informed offset by recovery = 4mb 

example for partition boot:
0x0001E000 = 122880 = x*1024*1024/512; x= 60Mb 
raw image real offset for boot = 60 + 4 = 64Mb = 67108864 B

Summarizing: for mounting the rootsfs partition contained in the raw image (containing a Friendlyarm distributed linux OS), what is needed to do is:

 

sudo mount -o loop,offset=104857600 -t ext4 friendlycore-bionic-4.4.raw.img /media/img/

 

I thought that somebody might be in the same situation as the one I was in my 1st post. AND, if that somebody is not able to enter recovery mode by shorting the ADC_IN1 (R35) point to GND while connecting the USB Type-C, them, might prefer to extract the files by mounting the rootfs partition. Or even make changes directly there.

 

Thats all!

 

 

What would be the offset for an Armbian image ?

Edit I worked it out with googles help

 

if you run fdisk -lu /path/to/your/image.img it will give you start and end numbers , if you multiply the start figure by 512 this gives you the offset. I just tried it with my dd created Armbian EMMC image and it mounted ok - this is a useful piece of knowledge when you want to retrieve some files from your backup.

 

 

Link to comment
Share on other sites

5 hours ago, pkfox said:

What would be the offset for an Armbian image ?

Edit I worked it out with googles help

 

if you run fdisk -lu /path/to/your/image.img it will give you start and end numbers , if you multiply the start figure by 512 this gives you the offset. I just tried it with my dd created Armbian EMMC image and it mounted ok - this is a useful piece of knowledge when you want to retrieve some files from your backup.

 

 

Yes! you can mount Armbian with the real info provided by fdisk -l, as it should be... and if you have automount, the system will mount it automatically and correctly without even the necessity to multiply the start sector * bytes per sector . But not at those non-standard raw images from friendlyarm ubuntu OS the fdisk -l offsets are informed incorrectly (as said)... but well, with the info at previous post the real offsets are now known and the rootfs can be mounted easily. In the other hand Armbian  emmc has no recovery available so you can not use rkflashkit. BUT: we don't need that shit because we already got GOD mode! :P

Link to comment
Share on other sites

1 hour ago, SriLK said:

Yes! you can mount Armbian with the real info provided by fdisk -l, as it should be... and if you have automount, the system will mount it automatically and correctly without even the necessity to multiply the start sector * bytes per sector . But not at those non-standard raw images from friendlyarm ubuntu OS the fdisk -l offsets are informed incorrectly (as said)... but well, with the info at previous post the real offsets are now known and the rootfs can be mounted easily. In the other hand Armbian  emmc has no recovery available so you can not use rkflashkit. BUT: we don't need that shit because we already got GOD mode! :P

I've just dd'd the image to another EMMC card and it booted perfectly - bearing in mind I created the image from a running system which I know is frowned  upon.

 

Link to comment
Share on other sites

I switched away from armbian as it only supported graphics acceleration in certain packages. Friendly OS is tweaked and chromium for example is supported. I never tried open gl though and someone more knowledgeable than me will know for sure exactly what armbian supports today.

Link to comment
Share on other sites

Hello everyone,

I'm doing some testing to check if I can use Armbian on my NanoPi M4. It seems pretty stable except for one problem with the ethernet. Basically after some data transferred, it dies.

 

This is an iperf3 log:

Spoiler

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  92.0 MBytes   770 Mbits/sec  192    557 KBytes       
[  5]   1.00-2.00   sec  97.5 MBytes   819 Mbits/sec    4    393 KBytes       
[  5]   2.00-3.00   sec  95.0 MBytes   795 Mbits/sec    0    653 KBytes       
[  5]   3.00-4.00   sec  97.5 MBytes   819 Mbits/sec    7    503 KBytes       
[  5]   4.00-5.00   sec  97.5 MBytes   819 Mbits/sec    0    731 KBytes       
[  5]   5.00-6.00   sec  98.8 MBytes   829 Mbits/sec    6    609 KBytes       
[  5]   6.00-7.00   sec  97.5 MBytes   817 Mbits/sec    0    771 KBytes       
[  5]   7.00-8.00   sec  97.5 MBytes   819 Mbits/sec   27    628 KBytes       
[  5]   8.00-9.00   sec  98.8 MBytes   828 Mbits/sec    4    437 KBytes       
[  5]   9.00-10.00  sec  98.8 MBytes   829 Mbits/sec    0    683 KBytes       
[  5]  10.00-11.00  sec  98.8 MBytes   828 Mbits/sec    3    508 KBytes       
[  5]  11.00-12.00  sec   100 MBytes   837 Mbits/sec    0    735 KBytes       
[  5]  12.00-13.00  sec  98.8 MBytes   831 Mbits/sec    4    573 KBytes       
[  5]  13.00-14.00  sec  98.8 MBytes   828 Mbits/sec    0    783 KBytes       
[  5]  14.00-15.00  sec  98.8 MBytes   829 Mbits/sec   11    638 KBytes       
[  5]  15.00-16.00  sec   100 MBytes   837 Mbits/sec    1    455 KBytes       
[  5]  16.00-17.00  sec  98.8 MBytes   830 Mbits/sec    0    700 KBytes       
[  5]  17.00-18.00  sec  98.8 MBytes   828 Mbits/sec   14    591 KBytes       
[  5]  18.00-19.00  sec  98.8 MBytes   829 Mbits/sec    0    796 KBytes       
[  5]  19.00-20.00  sec   100 MBytes   836 Mbits/sec    3    652 KBytes       
[  5]  20.00-21.00  sec  98.8 MBytes   829 Mbits/sec    9    455 KBytes       
[  5]  21.00-22.00  sec  98.8 MBytes   831 Mbits/sec    0    701 KBytes       
[  5]  22.00-23.00  sec  98.8 MBytes   828 Mbits/sec    3    550 KBytes       
[  5]  23.00-24.00  sec  98.8 MBytes   829 Mbits/sec    0    765 KBytes       
[  5]  24.00-25.00  sec  32.5 MBytes   273 Mbits/sec   14   1.41 KBytes 
[  5]  25.00-26.00  sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes 
[  5]  26.00-27.00  sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes 
[  5]  27.00-28.00  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes 
[  5]  28.00-29.00  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes 

 

 

Ethtool:

Spoiler

	Supported ports: [ TP AUI BNC MII FIBRE ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: external
	Auto-negotiation: on
	Supports Wake-on: ug
	Wake-on: d
	Current message level: 0x0000003f (63)
			       drv probe link timer ifdown ifup
	Link detected: yes

 

 

Armbian logs: http://ix.io/1RcN

I've tried almost all kernels available for Armbian, Buster and Stretch as well. Same result.

 

With FriendlyCore instead, it seems working:

Spoiler

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  94.5 MBytes   791 Mbits/sec   13    489 KBytes       
[  4]   1.00-2.01   sec  98.8 MBytes   823 Mbits/sec    0    619 KBytes       
[  4]   2.01-3.00   sec  97.5 MBytes   823 Mbits/sec    0    728 KBytes       
[  4]   3.00-4.01   sec  98.8 MBytes   822 Mbits/sec   36    437 KBytes       
[  4]   4.01-5.00   sec  97.5 MBytes   824 Mbits/sec    0    580 KBytes       
[  4]   5.00-6.01   sec  98.8 MBytes   825 Mbits/sec    0    694 KBytes       
[  4]   6.01-7.01   sec  98.8 MBytes   826 Mbits/sec    1    560 KBytes       
[  4]   7.01-8.02   sec  98.8 MBytes   820 Mbits/sec    0    677 KBytes       
[  4]   8.02-9.01   sec  98.8 MBytes   838 Mbits/sec    0    776 KBytes       
[  4]   9.01-10.01  sec  98.8 MBytes   828 Mbits/sec    1    646 KBytes       
[  4]  10.01-11.01  sec  98.8 MBytes   829 Mbits/sec    0    754 KBytes       
[  4]  11.01-12.01  sec  98.8 MBytes   829 Mbits/sec    4    622 KBytes       
[  4]  12.01-13.01  sec  98.8 MBytes   829 Mbits/sec    0    732 KBytes       
[  4]  13.01-14.00  sec  98.8 MBytes   833 Mbits/sec    1    597 KBytes       
[  4]  14.00-15.00  sec  99.5 MBytes   833 Mbits/sec    0    713 KBytes       
[  4]  15.00-16.00  sec  98.8 MBytes   827 Mbits/sec    0    813 KBytes       
[  4]  16.00-17.00  sec  98.8 MBytes   829 Mbits/sec   17    544 KBytes       
[  4]  17.00-18.00  sec  98.8 MBytes   831 Mbits/sec    0    667 KBytes       
[  4]  18.00-19.00  sec  99.5 MBytes   833 Mbits/sec    0    773 KBytes       
[  4]  19.00-20.00  sec  98.8 MBytes   827 Mbits/sec   19    642 KBytes       
[  4]  20.00-21.00  sec  98.8 MBytes   830 Mbits/sec    0    745 KBytes       
[  4]  21.00-22.01  sec   100 MBytes   834 Mbits/sec    1    619 KBytes       
[  4]  22.01-23.01  sec  98.8 MBytes   828 Mbits/sec    0    725 KBytes       
[  4]  23.01-24.01  sec  98.8 MBytes   827 Mbits/sec    7    591 KBytes       
[  4]  24.01-25.00  sec  98.8 MBytes   832 Mbits/sec    0    707 KBytes       
[  4]  25.00-26.00  sec  97.5 MBytes   820 Mbits/sec   13    580 KBytes       
[  4]  26.00-27.00  sec  97.5 MBytes   818 Mbits/sec    0    667 KBytes       
[  4]  27.00-28.00  sec  98.8 MBytes   829 Mbits/sec    0    771 KBytes       
[  4]  28.00-29.00  sec  99.4 MBytes   834 Mbits/sec    6    648 KBytes       
[  4]  29.00-30.00  sec  98.8 MBytes   827 Mbits/sec    0    755 KBytes       

 

 

This is the kernel used by FriendlyCore:

Linux NanoPi-M4 4.4.167 #1 SMP Fri Jul 12 17:32:47 CST 2019 aarch64 aarch64 aarch64 GNU/Linux

Ethtool:

Spoiler

Settings for eth0:
	Supported ports: [ TP AUI BNC MII FIBRE ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: external
	Auto-negotiation: on
	Supports Wake-on: ug
	Wake-on: d
	Current message level: 0x0000003f (63)
			       drv probe link timer ifdown ifup
	Link detected: yes

 

 

Lowering the speed of the ethernet card to 100Mbs, it's "solving" the issue.

Does anyone have the same problem? I searched around the forum, but I didn't find anything.

 

It seems pretty similar to this: https://github.com/rockchip-linux/kernel/issues/27

 

Thanks.

Edited by dagix5
added bug link
Link to comment
Share on other sites

On 8/11/2019 at 2:10 PM, pavelectric said:

To maintain interest in the board, I will post some of my photos and videos.

Very nice setup. What hat is that?
I only knew about the sata hat, and now the NVMe hat.
I'd love to have the nvme hat, I'll see to buy it next month. Thanks for the sbcporn.

Link to comment
Share on other sites

Hello. 

I would like to use wiring pi on my nanopi-m4, but unfortunately I can not change the mode of 3 gpio (11,15 and 16 on wiring-pi number), it remains stuck in "in" mode when I try to change its mode  . 

After restart it returns to "alt" mode. 

 

all other gpio support by wiring-pi this normally features. 

it's quite disabling because the nanopi-m4 card has only 11gpio and I need 10.

 

On datasheet is i2c_3 and spdif pin as well.

No have bug/debug message

Link to comment
Share on other sites

And there is also new revision of M4 itself, it's uses LPDDR4 instead of usual one, and it come 5$ cheaper, also it's seems to have more "cleaner" pcb (less smd component's?).
Did anybody know if it will be compatible with existing version of armbian or it will need new image for new version of ram ?
https://www.friendlyarm.com/index.php?route=product/product&product_id=268

Link to comment
Share on other sites

1 hour ago, tomsolo said:

Hello guys,

 

somebody would do a simple test for me? (before buying :))

 

This SBC can play fullscreen  this youtube video without tearing?

 

Thanks

Not sure exactly what tearing you are asking about? Does it show black and white bars moving across the screen, yes.  Are the bars all vertical without sections moving independently, yes. Is it like a piece of paper in front of you, no. The edges have a couple pixels blur. Is it the same on my i7 laptop and external graphics card, don't know yet :-)

 

Sorry for the subjective answer!

Link to comment
Share on other sites

14 hours ago, tomsolo said:

Hello guys,

 

somebody would do a simple test for me? (before buying :))

 

This SBC can play fullscreen  this youtube video without tearing?

 

Thanks

Good afternoon. I have a version with DDR3 4Gb. OS - FriendlyCore + Mate desktop. YouTube full screen 1080 no problem at all. Armbian doesn't work like that ...

Link to comment
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...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines