NanoPI NEO / AIR

[Carlos]

Hi

I am trying to use a pair of fibre media converters to connect to my NEO. The converters say they support IEEE802.3U/1000Base-Tx protocol, as well as 10/100/1000M auto-negotiation full and half duplex. I get no lan connection.

I have tested the converters by plugging them into my mac mini and they work fine.

Any thoughts?

 

Regards

Carl

[pzw]

Try sudo ethtool -s eth0 speed 100 duplex full autoneg off

[Carlos]

Try sudo ethtool -s eth0 speed 100 duplex full autoneg off

Hi pzw I have just tried that but got the reply ethtool unknown command

I then tried set eth0 speed 100 duplex full autoneg off

which appeared to be accepted but made no difference. Still no connection via fibre media converters

[pzw]

Try "sudo apt-get install ethtool", and then again "sudo ethtool -s eth0 speed 100 duplex full autoneg off"

[Carlos]

Try "sudo apt-get install ethtool", and then again "sudo ethtool -s eth0 speed 100 duplex full autoneg off"

Thanks for your help pzw

I have installed ethtool and run the command (ethtool -s eth0 speed 100 duplex full autoneg off) The Neo accepted this command.

No luck still no lan connection using the fibre media converters. 

Running ethtool -i eth0  I get the following

driver: sunxi_geth

version: SUNXI Gbgit driver V1.1

firmware-version: 

expansion-rom-version: 

bus-info: 

supports-statistics: no

supports-test: no

supports-eeprom-access: no

supports-register-dump: no

supports-priv-flags: no

 

I see that NanoPi have a NanoPi 2 fire that has a gigabit ethernet port. Do you think I would have more luck if I got one of those?

 

Thanks 

Carl

[pzw]

Are you sure your media converter doesn't have dip switches / jumpers you have to setup? If they do, make sure they are set to 100Mbit full duplex, and then try again... It sounds like there is an auto negotiation issue, so you cannot rely on it to work properly. Therefore forcing every device in the chain to 100Mbit (if possible) might solve the issue.

[Carlos]

Are you sure your media converter doesn't have dip switches / jumpers you have to setup? If they do, make sure they are set to 100Mbit full duplex, and then try again... It sounds like there is an auto negotiation issue, so you cannot rely on it to work properly. Therefore forcing every device in the chain to 100Mbit (if possible) might solve the issue.

Unfortunately no dip switches/jumpers visible. I am sure you are correct that it is an auto negotiation issue as the fibre set up works perfectly with my mac mini.

The fibre converter is not getting the information from the Neo that it requires to set speed etc.

I am reluctant to purchase a NanoPi 2 fire with gigabit ethernet port as the same issue may still persist.

Your help and advice is greatly appreciated. I have no expertise in networking or unix.

 

Regards

Carl

[Igor]

I am reluctant to purchase a NanoPi 2 fire with gigabit ethernet port as the same issue may still persist.

Chip on those boards are not supported by Armbian. You relay on outdated kernel and closed source boot loaders. In case of problems, there won't be much people who could help you. Rather check H3 boards with gigabit LAN and get one. It's safer way.

 

In general this is strange but possible issue. I got one such cheap fiber converter but it's in production use, so can't check if it makes troubles with those boards.

[Carlos]

Chip on those boards are not supported by Armbian. You relay on outdated kernel and closed source boot loaders. In case of problems, there won't be much people who could help you. Rather check H3 boards with gigabit LAN and get one. It's safer way.

 

In general this is strange but possible issue. I got one such cheap fiber converter but it's in production use, so can't check if it makes troubles with those boards.

Do you think the Orange Pi+ 2E would be suitable? It has gigabit ethernet and a couple of other features that would be nice , like power button and dc power socket.

Or would the Odroid C2 be a better choice? Very similar prices when delivered.

The Neo does the job I want it to do but I want to run it through fibre ethernet.

 

Regards

Carl

[rjbrown99]

I'd be interested to know if anyone has successfully booted a Nano Pi Neo Air with the 4.9/dev kernel. I have tried a few times now, including building my own image from source. I don't have the debug pins soldered so I'm limited to interacting with just the USB OTG serial console which does not show up at all. Makes it challenging to troubleshoot with no debug messages to know why it's failing to boot.

 

After trying to boot a few times I re-attached in FEL mode and mounted the root partition on my Mac using Paragon. I checked /var/log and saw no messages whatsoever, so this is telling me the kernel probably isn't getting past uboot or is hanging somewhere before mounting the filesystem. 

[tkaiser]

I'd be interested to know if anyone has successfully booted a Nano Pi Neo Air with the 4.9/dev kernel.

 

Sure, all H3 devices can boot mainline kernel. We had some troubles with megi's branch (the one that includes the thermal stuff and allows for throttling and also comes with USB OTG support) so switched to montjoie's branch without throttling/OTG working a few weeks back (better mount a heatsink). The specific problem with the Air might just be related to getting no way to interact with the board once booted since serial console over USB requires USB OTG support.

 

Theoretically when building an own image it should work to re-use Wi-Fi 'connection settings' made on the same device with legacy kernel before: Simply copy the stuff below /etc/NetworkManager/system-connections/ to your 4.9 image prior to booting. And don't forget to apply restrictive access right since logon credentials are stored there:

chown root:root /mnt/etc/NetworkManager/system-connections/*
chmod 600 /mnt/etc/NetworkManager/system-connections/*

Anyway: Currently without a real serial console dev kernel is of not much use anyway.

 

Update: Just tried it out with latest 4.9 beta image: http://sprunge.us/YdGf-- booting works, resize of partition works, connecting via wlan0 doesn't work for whatever reasons ( brcmfmac errors show up in the log). Anyway as said above: without serial console it's more or less useless to play around with dev kernel / beta images

[rjbrown99]

Thanks @tkaiser, that's helpful feedback. Are there plans for OTG support in the near future in the 4.9 branch? Between that and thermal, I see OTG as the more important of the two to make it usable. 

 

Anything I can help with? If it's merging some code and creating a pull request I might be able to assist as I have a local compile environment in place already. I just need some pointers to the correct source repos and related area of the OTG code.

[tkaiser]

Are there plans for OTG support in the near future in the 4.9 branch?

 

There are not that much plans at all. We try to catch a repo somewhere that contains most of the patches flying around that also works. With megi's repo this was the case up to 4.7, with later branches problems occured. So we switched to montjoie's so that at least Ethernet and a few other stuff that hasn't landed in official mainline kernel yet works.

 

We have reports by users that megi's repo works, we have reports that partially applying patches to montjoie's works but it's all WiP and more or less a huge waste of time. In case you want to also waste some time you'll need at least to solder serial console -- without it's useless.

 

BTW: to resolve those problems with mainline branches for H3 it's not necessary to use the Air -- every H3 board will do.

[tkaiser]

Seems like FriendlyARM will soon announce an I2S DAC based on TI's PCM5102A for both NanoPI NEO and Air: https://github.com/friendlyarm/h3_lichee/commits/master

 

And FriendlyARM also designed some sort of a 'HAT' for NEO (and most probably Air also): https://github.com/friendlyarm/BakeBit/tree/master/Hardware

 

 

More information (currently in chinese only) here and there.

[rjbrown99]

Is there anything special about soldering on the 4 pin connector for serial console? I soldered on the 4 pin connector, plugged in my serial cable ground (black), 5v (red), TX (green), RX (white) according to the FriendlyArm web page, and see no signal at all. Tested with both Linux and MacOS hosts using screen. I can see the running agetty process tied to tty1 but can't interact with it. 

 

I did not solder on any of the other connections, just the 4 pin debug UART.

 

Currently trying with the 3.4 kernel to make sure I can see console before testing out any of the 4.x/mainline stuff. The USB OTG/gadget console is still working so I can get in and see what's going on. 

 

My cable is this one.

[StuxNet]

@rjbrown99 I just received my NanoPi Neo Air from the post office today and was exhibiting the same exact issues you've described.

tl;dr: My culprit was the Micro SD card. I thought it was good, it fit the bill/specs but as soon as i tried a 'newer' card it booted right up. So to answer one of your previous questions, Yes. I have successfully booted the Neo Air, however I booted from Armbian v5.24 not the 4.9 v you mentioned.

Detail into the issues I was having earlier:

I installed the Armbian image, attached USBtoUART, I got nothing. I tried several other images, baud rates (besides Armbian's default 115200) still nothing. My Electrical Engineer buddy suggested what others also did in this thread. Solder the UART connections. Not doing so, might not be good enough. So I made good solid solder connections, still nothing. As a last ditch effort I tried a newer Micro SD Card and it booted completely without a hitch. I was kinda irritated because I was pretty sure the card was good since I was just using it in a different SBC project yesterday. Anyways, the main thing to watch out for is the LED for diagnosis. Is it dim? Then fore sure, it's hanging or not booting and could technically be anything. But in my experience, it's usually been user error on my part. The SDCard in this case, a crappy MicroUSB cable in the past not supplying enough amperage, etc...

My Question: Anyone have suggestions on getting the wifi working on my NanoPiNeoAir?

I've been trying to connect my Nano Pi Neo Air to my wifi connection, so I can ditch the USB to UART and interface over Putty/SSH (not to mention install some other stuff) but haven't had any luck. I've tried adding my wifi/pswd credentials to the /etc/wpa_supplicant/wpa_supplicant.conf file. Nothing. I've tried creating/editing SSID's using nmtui but it always "fails to connect." when I don't get this error

 

I also tried FriendlyArm's kernel, followed their instructions on connecting to a WiFi by booting Ubuntu, mounting the MicroSD card (because they don't have nano, vim, etc.. installed) and manually supplying the SSID/Pswd credentials. Any suggestions?

[tkaiser]

I can see the running agetty process tied to tty1 but can't interact with it.

 

Well, then something might be wrong on the physical side of things. Connecting the 5V might be not a good idea too.

 

My Question: Anyone have suggestions on getting the wifi working on my NanoPiNeoAir?

 

With legacy kernel sure otherwise we would've never released an OS image since it would be absolutely useless. Simply connect an antenna (there is no internal antenna and FA ships without the most important piece of hardware for reasons unknown to me) and then simply stop editing config files and use 'sudo nmtui'. It just works.

[arox]

About serial console, are you sure about TX and RX ? Did you check with another board if your adapter work and you know how to use it ?

 

About wifi, do you know it is unusable without aerial ?

[martinayotte]

Be careful, some of those USL-TTL Serial are 5V not 3.3V, in such case, TX must have a additional voltage divider to avoid problem with 3.3V target if the input is not 5V tolerant.

[arox]

His link indicates an adafruit product that clearly says :

 

"The power pin provides the 5V @ 500mA direct from the USB port and the RX/TX pins are 3.3V level for interfacing with the most common 3.3V logic level chipsets."

 

Nevertheless, the boards makers never make it clear if they use 3.3V or 5V logic and should one be confident about docs when they call 3.3V logic "TTL" ? And about TX and RX, it is always a "point of view" in a cross cable DTE to DTE.

 

Anyway, be also carefull that pin order is opposite between "neo" and "neo air".

[StuxNet]

Simply connect an antenna (there is no internal antenna and FA ships without the most important piece of hardware for reasons unknown to me) and then simply stop editing config files and use 'sudo nmtui'. It just works.

 

Again, user error on my part. I connected a spare U.FL IPX pigtail and voila. I feel really dumb. I assumed (I really should stop doing that with SBC's) that it had some small internal antennae and that 5-10 ft away from the router was close enough to pickup something. I assumed wrong. Also, you're right about nmtui. Until this latest SBC I hadn't known about it, but it will be my go-to going forward. As awesome as nand-sata-install. Thanks!

 

P.s. Again I agree in regards to the hardware. I would much rather prefer a tiny pigtail antennae from FriendlyArm than 1 extra piece of every nut/bolt for the case. Especially if the WiFi is useless without it and OrangePi/Other makers include it by default.

[tkaiser]

I would much rather prefer a tiny pigtail antennae from FriendlyArm than 1 extra piece of every nut/bolt for the case.

 

Just leave them some feedback. Those folks are really friendly and quick fixing stuff (see NaniPi NEO overheating problems that were fixed with PCB rev. 1.1)

[StuxNet]

I've got another question now that I've got my wifi working. Do we know if the NanoPiNeoAir supports AP Mode? ie: Can I turn it into a WiFi hotspot?

 

I've tried setting up an 'Access Point' in nmtui but the access point I create isn't detected by any of four WiFi enabled devices (phone/laptops/desktop/etc...) This is after restarting the services, rebooting the device, setting up in both 2.4/5Ghz frequencies and following these two tutorials. I noticed on FriendlyArm's website that other NanoPi models specifically mention AP Mode support. However, it doesn't mention it specifically for the NeoAir. Their main site, the specs on the link to buy it from and their Wiki page only say that it's WiFi 802.11b/g/n. One of the many ideas I had for the NeoAir was a $70 cheaper replacement to this.

 

For now, I'll just setup a Samba and have it search for my phones HotSpot credentials if Home/Work SSID's aren't present.

[tkaiser]

Please da google powered forum search for 'op_mode 2'. Regarding state of Wi-Fi in Armbian please see https://github.com/igorpecovnik/lib/issues/558. (Nothing will ever improve)

[cloudedmund]

in win10

after doing the instruction from fel-mass-storage-master

the emmc might be detected in other category

i have to choose update driver and change it to mass storage device

 

and i have to enable unsafe mode in etcher to be able to burn to the emmc

to be safe, open disk manager in administrative tool to confirm which disk you're writing to.

 

finally i got my neo pi air emmc flashed and running 

[cloudedmund]

nm seems won't autoconnect.

i used  nmcli c show home to check,

 connection.autoconnect : yes

 

seems like autoconnect is yes, but it doesn't connect after reboot.

still trying to figure this out

[tkaiser]

In case you did try it without sudo first, please delete settings with your normal user account and then use 'sudo nmtui' to setup everything. Tested many times with latest beta, always worked like a charm.

[cloudedmund]

i tried with another wifi.

it seems working.

 

i think the issue is that nm won't auto connect to wifi which have hidden ssid

 

ps i don't think u can add/activate connection without sudo

i can't even get ifconfig/iwconfig to run without sudo

[cloudedmund]

tried running sysbench. seems like the performance is close to RPi 2

even though the clock speed is similar to RPi3

 

 

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
total time: 201.2278s
total number of events: 10000
total time taken by event execution: 804.7881
per-request statistics:
min: 80.38ms
avg: 80.48ms
max: 120.57ms
approx. 95 percentile: 80.54ms

Threads fairness:
events (avg/stddev): 2500.0000/0.71
execution time (avg/stddev): 201.1970/0.03

 

monitoring the temperature and cpu load

at the same time running sysbench

seems like CPU max at 912MHz instead of 1200MHz

without a heat sink, temperature reaching 55°C

 

Time CPU load %cpu %sys %usr %nice %io %irq CPU
15:50:06: 912MHz 0.12 2% 0% 2% 0% 0% 0% 39°C
15:50:11: 240MHz 0.11 2% 0% 2% 0% 0% 0% 39°C
15:50:17: 240MHz 0.10 2% 0% 2% 0% 0% 0% 39°C
15:50:22: 240MHz 0.10 2% 0% 2% 0% 0% 0% 39°C
15:50:27: 912MHz 0.09 2% 0% 2% 0% 0% 0% 44°C
15:50:32: 912MHz 0.32 2% 0% 2% 0% 0% 0% 47°C
15:50:37: 912MHz 0.62 2% 0% 2% 0% 0% 0% 48°C
15:50:43: 912MHz 0.89 3% 0% 2% 0% 0% 0% 48°C
15:50:48: 912MHz 1.14 3% 0% 2% 0% 0% 0% 49°C
15:50:53: 912MHz 1.37 3% 0% 2% 0% 0% 0% 49°C
15:50:58: 912MHz 1.58 3% 0% 3% 0% 0% 0% 50°C
15:51:03: 912MHz 1.77 3% 0% 3% 0% 0% 0% 50°C
15:51:08: 912MHz 1.95 3% 0% 3% 0% 0% 0% 51°C
15:51:13: 912MHz 2.11 3% 0% 3% 0% 0% 0% 51°C
15:51:18: 912MHz 2.26 3% 0% 3% 0% 0% 0% 51°C
15:51:24: 912MHz 2.40 3% 0% 3% 0% 0% 0% 52°C
15:51:29: 912MHz 2.53 3% 0% 3% 0% 0% 0% 52°C
15:51:34: 912MHz 2.65 3% 0% 3% 0% 0% 0% 52°C
15:51:39: 912MHz 2.93 3% 0% 3% 0% 0% 0% 53°C
15:51:44: 912MHz 3.02 3% 0% 3% 0% 0% 0% 53°C
15:51:49: 912MHz 3.09 3% 0% 3% 0% 0% 0% 53°C
15:51:54: 912MHz 3.17 3% 0% 3% 0% 0% 0% 53°C
15:52:00: 912MHz 3.23 3% 0% 3% 0% 0% 0% 54°C
15:52:05: 912MHz 3.30 3% 0% 3% 0% 0% 0% 54°C
15:52:10: 912MHz 3.35 3% 0% 3% 0% 0% 0% 51°C
15:52:15: 912MHz 3.40 3% 0% 3% 0% 0% 0% 52°C
15:52:20: 912MHz 3.45 3% 0% 3% 0% 0% 0% 53°C
15:52:25: 912MHz 3.50 3% 0% 3% 0% 0% 0% 53°C
15:52:30: 912MHz 3.54 3% 0% 3% 0% 0% 0% 53°C
15:52:36: 912MHz 3.57 3% 0% 3% 0% 0% 0% 53°C
15:52:41: 912MHz 3.61 3% 0% 3% 0% 0% 0% 53°C
15:52:46: 912MHz 3.64 3% 0% 3% 0% 0% 0% 53°C
15:52:51: 912MHz 3.67 3% 0% 3% 0% 0% 0% 53°C
15:52:56: 912MHz 3.69 3% 0% 3% 0% 0% 0% 54°C
15:53:01: 912MHz 3.72 3% 0% 3% 0% 0% 0% 54°C
15:53:07: 912MHz 3.74 3% 0% 3% 0% 0% 0% 54°C
15:53:12: 912MHz 3.76 3% 0% 3% 0% 0% 0% 54°C
15:53:17: 912MHz 3.78 3% 0% 3% 0% 0% 0% 55°C
15:53:22: 912MHz 3.80 4% 0% 3% 0% 0% 0% 55°C
15:53:27: 912MHz 3.81 4% 0% 3% 0% 0% 0% 55°C
15:53:32: 912MHz 3.83 4% 0% 3% 0% 0% 0% 55°C
15:53:38: 912MHz 3.84 4% 0% 4% 0% 0% 0% 55°C
15:53:43: 912MHz 3.86 4% 0% 4% 0% 0% 0% 55°C
15:53:48: 240MHz 3.87 4% 0% 4% 0% 0% 0% 50°C
15:53:53: 240MHz 3.64 4% 0% 4% 0% 0% 0% 48°C
15:53:58: 240MHz 3.35 4% 0% 4% 0% 0% 0% 47°C
15:54:04: 240MHz 3.08 4% 0% 4% 0% 0% 0% 46°C
15:54:09: 240MHz 2.83 4% 0% 4% 0% 0% 0% 45°C

 

Doesn't seems like performance increase much after changing cpufreq to 1200MHz

 

Running the test with following options:

Number of threads: 4

 

Doing CPU performance benchmark

 

Threads started!

Done.

 

Maximum prime number checked in CPU test: 20000

 

 

Test execution summary:

    total time:                          190.6442s

    total number of events:              10000

    total time taken by event execution: 762.4292

    per-request statistics:

         min:                                 61.07ms

         avg:                                 76.24ms

         max:                                199.86ms

         approx.  95 percentile:              90.00ms

 

Threads fairness:

    events (avg/stddev):           2500.0000/9.57

    execution time (avg/stddev):   190.6073/0.03

 

 

seems unstable. its due to throttling? 

Stop monitoring using [ctrl]-[c]

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU

16:34:20: 1200MHz  1.40  28%   2%  26%   0%   0%   0%   64°C

16:34:25: 1008MHz  1.60  31%   2%  28%   0%   0%   0%   65°C

16:34:30: 1008MHz  1.80  33%   2%  30%   0%   0%   0%   65°C

16:34:35: 1008MHz  1.97  35%   2%  32%   0%   0%   0%   66°C

16:34:40: 1008MHz  2.22  37%   2%  34%   0%   0%   0%   67°C

16:34:45: 1008MHz  2.49  39%   2%  36%   0%   0%   0%   68°C

16:34:51: 1008MHz  2.61  40%   1%  38%   0%   0%   0%   69°C

16:34:56: 1008MHz  2.72  42%   1%  40%   0%   0%   0%   67°C

16:35:01: 1008MHz  2.82  43%   1%  41%   0%   0%   0%   69°C

16:35:06: 1008MHz  2.92  45%   1%  43%   0%   0%   0%   69°C

16:35:11: 1008MHz  3.01  46%   1%  44%   0%   0%   0%   68°C

16:35:16: 1008MHz  3.08  48%   1%  45%   0%   0%   0%   68°C

16:35:21: 1008MHz  3.16  49%   1%  47%   0%   0%   0%   65°C

16:35:26: 1008MHz  3.23  50%   1%  48%   0%   0%   0%   65°C

16:35:32: 1008MHz  3.29  51%   1%  49%   0%   0%   0%   65°C

16:35:37: 1008MHz  3.34  52%   1%  50%   0%   0%   0%   68°C

16:35:42: 1008MHz  3.40  53%   1%  51%   0%   0%   0%   70°C

16:35:47: 1008MHz  3.45  54%   1%  52%   0%   0%   0%   70°C

16:35:52:  816MHz  3.49  55%   1%  53%   0%   0%   0%   70°C

16:35:57:  816MHz  3.53  56%   1%  54%   0%   0%   0%   70°C

16:36:03:  816MHz  3.57  57%   1%  55%   0%   0%   0%   70°C

16:36:08:  816MHz  3.60  58%   1%  56%   0%   0%   0%   71°C

16:36:13:  816MHz  3.63  59%   1%  57%   0%   0%   0%   67°C

16:36:18:  816MHz  3.66  59%   1%  58%   0%   0%   0%   67°C

16:36:23: 1008MHz  3.69  60%   1%  59%   0%   0%   0%   68°C

16:36:28: 1008MHz  3.72  61%   1%  59%   0%   0%   0%   67°C

16:36:34: 1008MHz  3.74  62%   1%  60%   0%   0%   0%   67°C

16:36:39: 1008MHz  3.76  62%   1%  61%   0%   0%   0%   69°C

16:36:44: 1008MHz  3.78  63%   1%  61%   0%   0%   0%   69°C

16:36:49:  816MHz  3.80  63%   1%  62%   0%   0%   0%   68°C

16:36:54: 1008MHz  3.81  64%   1%  63%   0%   0%   0%   66°C

16:36:59:  816MHz  3.83  65%   1%  63%   0%   0%   0%   71°C

16:37:04: 1008MHz  3.84  65%   1%  64%   0%   0%   0%   67°C

16:37:10: 1008MHz  3.85  66%   1%  64%   0%   0%   0%   70°C

16:37:15:  240MHz  3.87  66%   1%  65%   0%   0%   0%   62°C

16:37:20:  240MHz  3.56  65%   1%  64%   0%   0%   0%   57°C

16:37:25:  240MHz  3.27  64%   1%  63%   0%   0%   0%   55°C

16:37:31:  240MHz  3.01  63%   1%  62%   0%   0%   0%   54°C

 

 

 

 

still trying to figure out whether there's a way for nm to connect to hidden ssid automatically

[tkaiser]

Another nice NEO dock to be released soon by FA: