chwe Posted April 14, 2019 Posted April 14, 2019 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.. I think they sell those also in their own shop. 0 Quote
SriLK Posted April 14, 2019 Posted April 14, 2019 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.. 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! 0 Quote
chwe Posted April 14, 2019 Posted April 14, 2019 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.. 0 Quote
SriLK Posted April 14, 2019 Posted April 14, 2019 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 :-) 0 Quote
chwe Posted April 14, 2019 Posted April 14, 2019 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).. 0 Quote
SriLK Posted April 14, 2019 Posted April 14, 2019 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? :-) 0 Quote
pfry Posted April 14, 2019 Posted April 14, 2019 (edited) 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 April 14, 2019 by pfry Added question/statement at end. 0 Quote
SriLK Posted April 15, 2019 Posted April 15, 2019 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 :-) 0 Quote
SriLK Posted April 16, 2019 Posted April 16, 2019 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) 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 :-) 0 Quote
pfry Posted April 16, 2019 Posted April 16, 2019 Nice work. You're even crazier than I am. And your soldering skills are obviously superior to mine. 0 Quote
SriLK Posted April 16, 2019 Posted April 16, 2019 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! 0 Quote
SriLK Posted April 23, 2019 Posted April 23, 2019 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! 0 Quote
pkfox Posted April 26, 2019 Posted April 26, 2019 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. 0 Quote
SriLK Posted April 26, 2019 Posted April 26, 2019 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! 0 Quote
pkfox Posted April 26, 2019 Posted April 26, 2019 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! 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. 0 Quote
leofuscaldi Posted May 4, 2019 Posted May 4, 2019 Hi all, I've bought a M4 4GB, installed Armbian Bionic and enabled video and 3D acceleration. Then, when I run glmark2 it says that my graphic card is a vmware, not the T860. What have I done wrong? 0 Quote
dogshome Posted May 5, 2019 Posted May 5, 2019 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. 0 Quote
pavelectric Posted June 7, 2019 Posted June 7, 2019 The long-awaited fee on the M4, in the form of a plate.NVME SSD Adapter for M4 No price yet, write to WiKi 1 Quote
dagix5 Posted August 10, 2019 Posted August 10, 2019 (edited) 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 August 15, 2019 by dagix5 added bug link 0 Quote
pavelectric Posted August 11, 2019 Posted August 11, 2019 To maintain interest in the board, I will post some of my photos and videos. 0 Quote
frauhottelmann Posted August 12, 2019 Posted August 12, 2019 On 6/7/2019 at 3:50 PM, pavelectric said: The long-awaited fee on the M4, in the form of a plate.NVME SSD Adapter for M4 No price yet, write to WiKi It's already available: https://www.friendlyarm.com/index.php?route=product/product&path=70&product_id=262 5$ is pretty nice! 0 Quote
NicoD Posted August 12, 2019 Posted August 12, 2019 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. 0 Quote
pavelectric Posted August 12, 2019 Posted August 12, 2019 1 hour ago, NicoD said: 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. This is a new hat - PCIe to USB 3.0 x4 HAT LINK 1 Quote
pavelectric Posted August 25, 2019 Posted August 25, 2019 Meanwhile, we had a big review of a single-board PC, the M4 is in the review. And its characteristics are not even bad, compared to competitors. 1 Quote
dragonlost Posted September 7, 2019 Posted September 7, 2019 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 0 Quote
pavelectric Posted September 8, 2019 Posted September 8, 2019 Hello. Suddenly, the manufacturer introduced a new case for the M4 for purchase ... It seems good and not expensive, given the rich set. Product Link - https://www.friendlyarm.com/index.php?route=product/product&product_id=267 0 Quote
tomsolo Posted September 12, 2019 Posted September 12, 2019 (edited) Hello guys, somebody would do a simple test for me? (before buying ) This SBC can play fullscreen this youtube video without tearing? Thanks Edited September 12, 2019 by tomsolo 0 Quote
markon Posted September 12, 2019 Posted September 12, 2019 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 0 Quote
dogshome Posted September 12, 2019 Posted September 12, 2019 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! 0 Quote
pavelectric Posted September 13, 2019 Posted September 13, 2019 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 ... 0 Quote
Recommended Posts
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.