NanoPI NEO / AIR
15 15

487 posts in this topic

fortunately, I got it works! 

martinayotte

many many thanks!!!

 

 

Is there any plans for armbian mainline image for orange pi one?

Share this post


Link to post
Share on other sites

Is there any plans for armbian mainline image for orange pi one?

No, apart from nightly (unsupported) images. It's too early to provide official mainline based releases yet.

Share this post


Link to post
Share on other sites

Hi, today I tried to install Armbian on my NEO Air board but without any lack. I follow this instruction: https://forum.armbian.com/index.php/topic/1580-nanopi-neo-air/page-9#entry17707

 

I burn image into microSD card and run sunxi-flasher. It found device but after that I get this message: 

 

neoair.png

 

When I click on Ignore or Eject button Etcher can't find my device to flash.

I am using macOS Sierra

 

I tried to run file "start.sh" in fel-mass-storege folder but then i have this error:

start.png

 

Ok I managed that. 

Firstly I copied sunxi-fel and libusb library to fel-mass-storage folder and next run start.sh script. 

Now I have working copy of Armbian on emmc 

Edited by krystian

Share this post


Link to post
Share on other sites

Hello,

great work on armbian, thanks guys.

 

I've got nanopi neo and wanted to use it as an ambilight device using hyperion (even rpi zero can handle that ;-) but getting a hold on one is hard). For this i need:

* v4l/usbtv kernel modules for the usb grabber

* i2c/spi (for the serial led strips - not yet sure if any of 'rpi' methods using these pins would work) pins or a serial (when using a arduino nano for a bridge - using fastled)

 

and was checking distros/kernels:

* legacy - i2c/spi and all 3 uarts are visible in the system but the dongle wasnt recognized (nothing in dmesg/ and no /dev/video)

root@nanopi:~# cat /proc/tty/driver/uart
serinfo:1.0 driver revision:
0: uart:SUNXI mmio:0x01C28000 irq:32 tx:209 rx:22 RTS|DTR
1: uart:SUNXI mmio:0x01C28400 irq:33 tx:0 rx:0 CTS
2: uart:SUNXI mmio:0x01C28800 irq:34 tx:0 rx:0 CTS
3: uart:SUNXI mmio:0x01C28C00 irq:35 tx:0 rx:0 CTS

* mainline 4.9 - the usbtv grabber works great but there are not i2c/spi drivers and only one uart is visible - uart0

 

I'm a noob with kernels so if anyone could point me to the right directions on getting all the uarts working on mainline - it would be great.

I've seen that i need device tree overlays for the i2c/spi from here - investigating how to use them now ;-)

 

------

 

And now like a noob i see that user 'smile' a page back did enable the uarts. ill try too when ill be back home.

Edited by kabturek

Share this post


Link to post
Share on other sites

If you use newest build images, we now provide some overlays in the /boot/dtb/overlay folder, and your can activate them in /boot/armbianEnv.txt with :

overlays=uart1-enable uart2-enable i2c0 spi0-spidev
kabturek and gnasch like this

Share this post


Link to post
Share on other sites

 

If you use newest build images, we now provide some overlays in the /boot/dtb/overlay folder, and your can activate them in /boot/armbianEnv.txt with :

overlays=uart1-enable uart2-enable i2c0 spi0-spidev

thats great stuff! thanks!

Maybe/should they be loaded by default for nano pi neo ? or is the convention that by default all pins are GPIO and user selects what he wants by overlays?

I've seen that Igor added ethernet today to the neo - that will help a lot :)

Share this post


Link to post
Share on other sites

Yes, that is the convention that kernel guys are promoting : leaving them disabled, so GPIOs by default, overlays loaded when needed.

Share this post


Link to post
Share on other sites

I updated my Neo today - it was running mainline kernel and xenial ... after the update the thing would boot but the ethernet connection is not working - both LEDs are lit. I downloaded a fresh mainline image (the new xenial "5.25" one) and have the same issue.

 

Any ideas before I take the thing to bits and solder a header on it ... ?

 

(BTW, this system has been running very, very nicely for about 6 weeks before I stupidly did the update ...)

Share this post


Link to post
Share on other sites
I updated my Neo today - it was running mainline kernel and xenial ... after the update the thing would boot but the ethernet connection is not working - both LEDs are lit. I downloaded a fresh mainline image (the new xenial "5.25" one) and have the same issue.

 

Update from old (testing) images might broke, while images works. I just download, burn and boot this image:

 

https://dl.armbian.com/nanopineo/Ubuntu_xenial_dev.7z

 

on my FA Neo. Network works out of the box. If you made a download yesterday, you could accidentally download broken image. I was correcting those images manually during the evening since I figured out, that network was disabled.

Share this post


Link to post
Share on other sites

yep just want to confirm that todays image works (thanks!) and wasnt in some images before (network). checking the serial ports now.

Share this post


Link to post
Share on other sites

using mainline im having trouble with those serial ports - i've added

overlays=uart1-enable uart2-enable i2c0 spi0-spidev

and i can see the serial ports:

root@nanopineo:~# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:U6_16550A mmio:0x01C28000 irq:33 tx:1230648 rx:3 fe:1 brk:1 RTS|DTR
1: uart:U6_16550A mmio:0x01C28400 irq:34 tx:105838838 rx:0 RTS|CTS|DTR
2: uart:U6_16550A mmio:0x01C28800 irq:35 tx:269575 rx:0 RTS|CTS|DTR
3: uart:U6_16550A mmio:0x01C28C00 irq:36 tx:44 rx:0 CTS
4: uart:unknown port:00000000 irq:0
5: uart:unknown port:00000000 irq:0
6: uart:unknown port:00000000 irq:0
7: uart:unknown port:00000000 irq:0

root@nanopineo:~# cat /proc/device-tree/soc/serial@01c28400/status
okay
root@nanopineo:~# cat /proc/device-tree/soc/serial@01c28800/status
okay
root@nanopineo:~# cat /proc/device-tree/soc/serial@01c28c00/status
okay

root@nanopineo:~# dmesg | grep tty
[    0.000000] Kernel command line: root=UUID=f3b76779-12e8-4b21-a8ce-f2920a5d65a1 rootwait rootfstype=ext4 console=tty1 console=ttyS0,115200 cgroup_enable=memory swapaccount=1 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1 ubootpart=d9a7670c-01 ubootsource=mmc   sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16
[    0.000947] console [tty1] enabled
[    4.100401] console [ttyS0] disabled
[    4.120629] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 33, base_baud = 1500000) is a U6_16550A
[    4.120698] console [ttyS0] enabled
[    4.142206] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 34, base_baud = 1500000) is a U6_16550A
[    4.163692] 1c28800.serial: ttyS2 at MMIO 0x1c28800 (irq = 35, base_baud = 1500000) is a U6_16550A
[    4.188288] 1c28c00.serial: ttyS3 at MMIO 0x1c28c00 (irq = 36, base_baud = 1500000) is a U6_16550A

(added newlines for clarity)

 

ive tested with looback and with a 3v3 serial converter attached to the UART1 RX/TX: http://wiki.friendlyarm.com/wiki/index.php/File:NEO_pinout-02.jpg

 

When testing with the image provided by FriendlyArm  i can use UART1 without problems with looback and the serial converter (hardware connection is the same - just switching the sd card, tried different baud rates).

 

friendly_arm:

root@nanopi:~# cat /proc/tty/driver/uart
serinfo:1.0 driver revision:
0: uart:SUNXI mmio:0x01C28000 irq:32 tx:46 rx:0 RTS|DTR
1: uart:SUNXI mmio:0x01C28400 irq:33 tx:0 rx:0 CTS
2: uart:SUNXI mmio:0x01C28800 irq:34 tx:0 rx:0 CTS
3: uart:SUNXI mmio:0x01C28C00 irq:35 tx:0 rx:0 CTS

root@nanopi:~# dmesg | grep tty
[    0.000000] Kernel command line: console=ttyS0,115200 console=tty0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait init=/sbin/init storage_type=1 fb_base=0x40000000
[    0.000000] console [tty0] enabled
[    0.309642] uart0: ttyS0 at MMIO 0x1c28000 (irq = 32) is a SUNXI
[    0.417861] console [ttyS0] enabled
[    1.181073] uart1: ttyS1 at MMIO 0x1c28400 (irq = 33) is a SUNXI
[    1.353686] uart2: ttyS2 at MMIO 0x1c28800 (irq = 34) is a SUNXI
[    1.490380] uart3: ttyS3 at MMIO 0x1c28c00 (irq = 35) is a SUNXI
[    5.930512] systemd[1]: Created slice system-serial\x2dgetty.slice.
[    5.952509] systemd[1]: Created slice system-getty.slice.

Share this post


Link to post
Share on other sites

Ok i still can't believe it but after looking at orangepione dts files comparing it to nanopi-neo.dts i managed to make some changes that made the serial ports work:

root@nanopineo:/boot/dtb# diff  sun8i-h3-nanopi-neo.dts.orig sun8i-h3-nanopi-neo.dts -u
--- sun8i-h3-nanopi-neo.dts.orig    2017-02-04 09:18:09.295914003 +0000
+++ sun8i-h3-nanopi-neo.dts    2017-02-04 09:13:25.065085930 +0000
@@ -759,7 +759,9 @@
             resets = <0x2 0x32>;
             dmas = <0x16 0x7 0x16 0x7>;
             dma-names = "rx", "tx";
-            status = "disabled";
+            pinctrl-names = "default";
+            pinctrl-0 = <0x43 0x44>;
+            status = "okay";
             linux,phandle = <0x49>;
             phandle = <0x49>;
         };
@@ -774,7 +776,9 @@
             resets = <0x2 0x33>;
             dmas = <0x16 0x8 0x16 0x8>;
             dma-names = "rx", "tx";
-            status = "disabled";
+            pinctrl-names = "default";
+            pinctrl-0 = <0x45>;
+            status = "okay";
             linux,phandle = <0x4a>;
             phandle = <0x4a>;
         };
@@ -1495,12 +1499,14 @@
                 clocks = <0x0>;
                 resets = <0x0>;
                 dmas = <0x0 0x8>;
+                pinctrl-0 = <0x0>;
             };

             serial@01c28800 {
                 clocks = <0x0>;
                 resets = <0x0>;
                 dmas = <0x0 0x8>;
+                pinctrl-0 = <0x0>;
             };

             serial@01c28c00 {
root@nanopineo:/boot/dtb# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:U6_16550A mmio:0x01C28000 irq:33 tx:8350 rx:0 RTS|DTR
1: uart:U6_16550A mmio:0x01C28400 irq:34 tx:13239 rx:24 brk:1 RTS|CTS|DTR
2: uart:U6_16550A mmio:0x01C28800 irq:35 tx:26 rx:0 RTS|CTS|DTR
3: uart:U6_16550A mmio:0x01C28C00 irq:36 tx:0 rx:0 CTS
4: uart:unknown port:00000000 irq:0
5: uart:unknown port:00000000 irq:0
6: uart:unknown port:00000000 irq:0
7: uart:unknown port:00000000 irq:0

shouldn't uart2 have uart2_rts_cts section too ?

 

Other issue - every reboot the ethernet adapter has different mac address

I solved it by adding :

mac-address = [72 28 b7 40 79 f2];

to sun8i-h3-nanopi-neo.dts under ethernet@1c30000

I'm on fire today.

Edited by kabturek
Igor likes this

Share this post


Link to post
Share on other sites

Update from old (testing) images might broke, while images works. I just download, burn and boot this image:

 

https://dl.armbian.com/nanopineo/Ubuntu_xenial_dev.7z

 

on my FA Neo. Network works out of the box. If you made a download yesterday, you could accidentally download broken image. I was correcting those images manually during the evening since I figured out, that network was disabled.

 

 

@Igor - thanks that now works with your fixed image!

 

What manual fix did you need to do? It may be quicker than moving all my stuff across to a new image!

Share this post


Link to post
Share on other sites

Got my nano pi neo booted as well.  Eth0 is stuck at half duplex, anyone else seen this?  

Share this post


Link to post
Share on other sites

Got my nano pi neo booted as well.  Eth0 is stuck at half duplex, anyone else seen this?  

seen that too but as i dont use it for anything that needs speed i left it as is.

 

@igor apart from the

status = "okay";

that should use the overlay - should i submit the rest as a PR ?

Share this post


Link to post
Share on other sites

@kabturek are you fixing the half duplex issue?  If not, could i get some general directions, I think i can of help as well.

Share this post


Link to post
Share on other sites

I have this half duplex issue, too.

with autoneg off i can set it for some seconds to full, but then it falls back to 10(!) half duplex.

Share this post


Link to post
Share on other sites

Did anyone tried the NanoPi Neo Air already?

 

I wrote a DTS and am able to boot. (chttps://github.com/erazor83/linux/commit/d09e783c8b28b0eb465cb3d6efe001c8a19b1ffc )

 

EMMC seems to work but I got no wireless interface.

 

dmesg gives me:

[    1.784171] Key type encrypted registered
[    1.787030] sunxi-mmc 1c11000.mmc: smc 2 err, cmd 8, RTO !!
[    1.791131] sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !!
[    1.791959] sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !!
[    1.792783] sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !!
[    1.793615] sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !!
[    1.893988] mmc1: new high speed SDIO card at address 0001
[    2.043016] mmc2: new DDR MMC card at address 0001
[    2.048893] mmcblk2: mmc2:0001 8WPD3R 7.28 GiB 
[    2.053984] mmcblk2boot0: mmc2:0001 8WPD3R partition 1 4.00 MiB
[    2.060469] mmcblk2boot1: mmc2:0001 8WPD3R partition 2 4.00 MiB
[   18.315477] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[   19.330087] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[   20.338826] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50

sunxi-mmc 1c11000.mmc is for mmc2, which is the emmc - so it hasn't to do anything with the wifi.

 

I'm wondering about the htclk messages. Does anyone have some ideas about this?

Share this post


Link to post
Share on other sites

Thanks. It's been the firmware.

 

Funny since I tried the one from NanoPI's image "DietPi_NanoPiNEO-armv7-(Jessie)"

Share this post


Link to post
Share on other sites

Hey all,

I'm loving the Neo Air! Couple of issues that I've seen so far, and hoping to see if you guys have suggestions.

 

I started with the 5.24 image with the 3.X kernel and everything is working great. Mindlessly did an upgrade to 5.25 and it killed access to the bluetooth device. Not showing up at all. I've rolled back to the previous image for now.

 

Secondly, (I posted another topic about this) I'm trying to get higher baud rates on the UARTs, specifically 460800. Any suggestions?

 

Keep up the good work!

 

Leif

Share this post


Link to post
Share on other sites

Hi all!

I am trying to use windows remote destop to connect with my NanoPi Neo with Armbian_5.20_Nanopiair_Debian_jessie_3.4.112.

I install xrdp, lxde and xorg.

When I type "startx" error "Fatal server error: no screens found" appears.
I think that video driver (/dev/fbo) is missing.
With "nanopi-neo-core-qte-sd4g-20161213.img" was all ok.

 

How I can install it?

Thx

Share this post


Link to post
Share on other sites

In case anyone cares, I've got proof of concept of the SSD1306 working on NanoPi Neo Air over i2c.

Full write up, examples, sources, etc... I've provided here, under 'i2c': https://github.com/BiTinerary/PocketServerPi#i2c-screen-ssd1306

The write up is technically for FriendlyArm distro however I was also able to recreate it running Armbian kernel 3.4.113.

 

Big kudos to this guys awesome work and contribution: https://github.com/rm-hull/luma.oled which is easily extensible and compatible across multiple systems.

His example code works verbatim for the ssd1306 on NanoPi Neo Air with a small change of port 1 to port 0.

Example code here: https://luma-oled.readthedocs.io/en/latest/python-usage.html

Share this post


Link to post
Share on other sites

The write up is technically for FriendlyArm distro however I was also able to recreate it running Armbian kernel 3.4.113.

 

 

So it has to work with Armbian obviously :)

 

Unfortunately both your following claims are completely wrong (please see post #403 of this thread or just search the forum for op_mode=2):

 

Armbian forums mentioned multiple times that their kernel/drivers don't support an Access Point and "Nothing will ever improve."

 

In post #284 of this thread you can read through the contents of the 'turn-wifi-into-apmode' shell script (it's not a binary and there is zero magic involved!). The whole magic is still just telling the kernel module to switch between client and AP mode (op_mode).

 

So in other words: since you're already using Armbian kernel, you're obviously using Armbian's Wi-Fi kernel module and the switch between client and AP mode can be done by a script. Same with setting up an AP, there's really no need to fiddle around with old/anachronistic hostap/wpa_something config files, just let network-manager do the job: http://forum.odroid.com/viewtopic.php?f=52&t=25472&sid=84d2b8f1e7ad477e9907591eb7fb030d

 

BTW: I still believe that change of op_mode can be done from userspace/sysfs and it might not even be necessary to unload/load the module like FriendlyARM's script is doing it currently.

StuxNet likes this

Share this post


Link to post
Share on other sites

 

 

Unfortunately both your following claims are completely wrong (please see post #403 of this thread or just search the forum for op_mode=2):

Yup, you're right. My bad, I do need to change that. I made that false claim after misunderstanding a post/reply you made. Furthermore I have one distro on eMMC, another on SD that I swap interchangeably to test new things, like the screen. I just haven't gotten around to re-testing the switch AP Mode thingy on Armbian and as result haven't made the appropriate changes to the write up. Again, my bad. I will get around to changing the comment and testing the feature. Nice catch, thanks for the reminder.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
15 15

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.