Jump to content

NanoPI NEO / AIR

Per-Mattias Nordkvist
 Share

Recommended Posts

arox

arox

Posted
Posted

No.  The only modules loaded by default are: bcmdhd, cfg80211, and compat, and the only network interfaces are lo and (unconfigured) wlan0.

Thanks.

 

I ordered a neo and an air. I hope I will at least be able to use the armbian setup of the neo to get access to the air threw micro-usb without first playing with the iron ?

Link to comment
Share on other sites
webbbn

webbbn

Posted
Posted

Thanks.

 

I ordered a neo and an air. I hope I will at least be able to use the armbian setup of the neo to get access to the air threw micro-usb without first playing with the iron ?

 

At the very least, if you have a Linux system, you should be able to mount the root FS and edit files that way.

 

BTW, I was talking about the default installation, not Armbian.  Armbian doesn't appear to load g_ether by default either.

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

Armbian doesn't appear to load g_ether by default either.

 

As soon as we have the Air in our hands we'll try two things:

  • support flashing directly to eMMC (should work since yesterday since Zador added UUID support to boot script and fstab for all sunxi devices)
  • enable g_serial as we currently already do on the other non-Ethernet board: Orange Pi Lite

And since the eMMC is already populated with a bootable OS image and there seems to be no FEL boot button users would need a super small special SD card image to enter FEL mode which makes the whole 'flash to eMMC directly' approach somewhat useless :(

 

Neither FEL button nor FEL jumper settings (as done on the CHIP for example) really sucks.

 

At the very least, if you have a Linux system, you should be able to mount the root FS and edit files that way.

 

 

You would need to bring the device in FEL mode before. If you're able to do so the rest is simply https://github.com/zador-blood-stained/fel-mass-storage

Link to comment
Share on other sites
arox

arox

Posted
Posted

enable g_serial as we currently already do on the other non-Ethernet board: Orange Pi Lite

 

Seems reasonable : an armbian user who purchase this card would want to first try/save fa system by configuring network access and then install armbian if he is not satisfied or want to unify his configs. And I do not want to solder ports on a board before being sure I need them for a project : it is awfully difficult to unsolder ...

 

I do not understand FA : flashing the eMMC has a cost for them, but what is the interest if you cannot log in ?

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

I do not understand FA : flashing the eMMC has a cost for them, but what is the interest if you cannot log in ?

 

Well, they chose to let only the elite users make use of the Air. You should have a second Linux host available to enter Wi-Fi credentials on a SD card that will then replace the eMMC's contents (no, please don't ask why that complicated).

 

So currently Air seems to come with a pre-populated OS image in eMMC you can't access in any reasonable way (solder iron needed). Due to missing FEL button this also prevents flashing an OS image to eMMC without the intermediate step to burn fel-sdboot.img to a small SD card and boot from there to expose the eMMC to a connected host. There's also no need to backup the eMMC contents since the OS there is unaccessible anyway.

 

In other words: They pretty much prevented any reasonable access to the Air so far ;)

Link to comment
Share on other sites
arox

arox

Posted
Posted

Well, they chose to let only the elite users make use of the Air.

 

Well, the elite users may have achieve a level of study that allows them to calculate that $18 for a nanopi air is twice as much as $9 for a CHIP. The only advantage is that the "air" can be embedded more easily - and that is perhaps why they considered playing with the iron before even be able to test the board was not a problem. But for two lines of code missing in boot scripts, it is a bit ridiculous ...

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

But for two lines of code missing in boot scripts, it is a bit ridiculous ...

 

Well, this commit enabled g_serial for Orange Pi Lite (and I believe we will do the same for NanoPi Air as well). Maybe FA simply missed the existence of g_serial module (or maybe even worse they tried to implement g_ether just to realize that in their kernel fork a patch might be missing?).

 

Edit: unfortunately currently NanoPi Air comes with a pre-populated eMMC (with a more or less unaccessible OS image for whatever reasons) so it's necessary to flash the fel-sdboot.img OS image that's part of fel-mass-storage, burn it to an SD card and boot the Air from this mini image to enter FEL mode correctly (everything else will fail, always use Etcher since the verify process will show you this)

 

Anyway: If the NanoPi Air would come with an unpopulated eMMC then it would be just this to get it up and running (from OS X in this case):

  • Download and install Etcher
  • Download Armbian image for NanoPi Air
  • Double click sunxi-armbian-flasher-osx.app
  • Use a Micro USB cable to connect the Air to your Mac
  • 20 seconds later the Air is in FEL mode and Etcher will be started asking you to burn the OS image to it
  • If Etcher is finished, unplug the USB cable, wait 3 seconds, re-plug it
  • Wait until /dev/cu.usb* appears and then do 'screen /dev/cu.usb* 115200 –L' to setup Armbian
  • Follow these instructions to setup Wi-Fi (zero feedback so far -- not so great)

No need for an SD card at all, no need to solder or connect anything else than the Micro USB cable (BTW: you should do this on an USB3 port that has to provide 900mA since USB2's 500 mA might not be enough)

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

I do not understand FA : flashing the eMMC has a cost for them, but what is the interest if you cannot log in ?

I don't think it would cost much for mass production. And it is possible that decision to ship with unsoldered headers (including Ethernet port) was made after the decision to pre-populate eMMC with OS image.

 

In other words: They pretty much prevented any reasonable access to the Air so far ;)

From my perspective for boards with eMMC an ideal user experience would be a special button or jumper which would force booting from onboard SPI flash pre-populated with something close to "fel-mass-storage" payload, so you would get eMMC exposed via g_mass_storage on OTG port.

1
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

Got a couple of NanoPi NEO Airs today.  Anyone tried Armbian on them yet?  I imagine the standard NEO image will work, but how hard will it be to install it onto the internal flash?

 

The NanoPi Air commits from today might get everything to work: https://github.com/igorpecovnik/lib/commits/master (at least they should activate eMMC and enable serial console on the Micro USB port using g_serial module -- the foundation to flash to eMMC directly is Zador's work and has been finished before)

 

I tested it not with an Air (since none around) but with a NEO 'simulating' eMMC. Connected the board using the Micro USB connector to an USB port of my MacBook, then burned the image to the 'USB Mass storage device' (in my case SD card, in your case eMMC), then disconnected cable and reconnected and a minute later /dev/cu.usbmodem1421 appeared and I connected with screen to finish installation.

 

Please keep in mind that you need an SD card with a minimal SPL on it that forces the Air into FEL mode (see here how/why) and that currently if you're using our build system to create a fresh image for the Air the nand-sata-install script doesn't work (needs some time to adjust it to get also UUID support if I understood correctly).

 

Feedback welcomed. In case things work not as expected please understand that we've to wait for physical dev samples to arrive to make any real progress. All work currently done is only by looking in FriendlyARM's github account and wiki and listening to you users (who are great BTW!)

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

If you think you have an image to test, I'm willing to test it.  I don't have a Mac, but I do have Windows and Linux if Linux is required or easier to test on.

 

Please test Armbian_5.21.161016_Nanopiair_Ubuntu_xenial_3.4.112.7z. And of course both Windows and Linux are fine. Simply follow the descriptions here:

Link to comment
Share on other sites
webbbn

webbbn

Posted
Posted

 

Please test Armbian_5.21.161016_Nanopiair_Ubuntu_xenial_3.4.112.7z. And of course both Windows and Linux are fine. Simply follow the descriptions here:

 

 

I'm not sure I fully understand what I have to with this image.  I booted it, and it came up just fine, then rebooted after a few minutes (not sure what that was about).  Now it's booted, and it added a COM device that I'm able to log into, which is nice.  I'm not sure what I do with the sunxi-fel, though.

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

I'm not sure I fully understand what I have to with this image.  I booted it, and it came up just fine, then rebooted after a few minutes (not sure what that was about).  Now it's booted, and it added a COM device that I'm able to log into, which is nice.  I'm not sure what I do with the sunxi-fel, though.

 

If it works, that's good ... our Air boards should be here this week. There is also an option to burn image directly to internal eMMC. Officially is under testing but it should work.

 

General note:

 

Link to beta image(s) is(are) changed since date is a part of filename. Since we can't have a full archive, old images are automatically removed. Only the last one remains.

 

http://image.armbian.com/betaimages & browse for correct one ... or I can make some linking magic if direct linking is more desirable.

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

I'm not sure what I do with the sunxi-fel, though.

That was meant to burn the OS image directly to eMMC (feedback needed) and then setting up Wi-Fi would be interesting (feedback needed). Please keep in mind that it's already confirmed that the Air image can boot from SD card and works as long as Wi-Fi/BT aren't considered (since tested with NEO).

Link to comment
Share on other sites
webbbn

webbbn

Posted
Posted

Please keep in mind that you need an SD card with a minimal SPL on it that forces the Air into FEL mode (see here how/why) and that currently if you're using our build system to create a fresh image for the Air the nand-sata-install script doesn't work (needs some time to adjust it to get also UUID support if I understood correctly).

 

That was meant to burn the OS image directly to eMMC (feedback needed) and then setting up Wi-Fi would be interesting (feedback needed). Please keep in mind that it's already confirmed that the Air image can boot from SD card and works as long as Wi-Fi/BT aren't considered (since tested with NEO).

I think the part that I was missing is how to bring the NEO Air into FEL mode. Now I see that there is a fel-sdboot.img that is in that repo, which must be the missing piece. I didn't see the last sentence that mentions booting that image. Maybe that should be moved to the top of the README, since I believe it has to happen before the other parts of the README will work, right?

 

Once I boot that image and connect via USB, will it show another drive that I then write the provided image to?

 

In any case, I'll try again tonight add see what happends.

Link to comment
Share on other sites
webbbn

webbbn

Posted
Posted

Clearly I'm missing some crucial information.  I wrote the fel-sdboot.img to an sdcard and booted it, connected to USB.  A device came up that has the same IDs as described in the fel-mass-storage instructions, but what do I do to write the image?  The page you keep referring me to stops at detecting the device.  I don't see any instructions on how to then write an image file to the device.  The closest I can see is "sunxi-fel write address file", but I don't know what the address should be.

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

Perhaps "run start" should be in the readme. It looks like this:

1.start.bat

2.hold FEL button and connect power

"Connect device in FEL mode and press <Enter>"
Press any key to continue . . .
100% [================================================]  4575 kB,  813.5 kB/s
100% [================================================]    21 kB,  730.7 kB/s
100% [================================================]  2230 kB,  813.4 kB/s
100% [================================================]     0 kB,   49.2 kB/s
Press any key to continue . . .

3. Check serial console:

U-Boot 2016.09-armbian-fel-mass-storage-dirty (Sep 28 2016 - 12:21:11 +0300) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi One
DRAM:  1 GiB
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
(FEL boot)
## Executing script at 43100000
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    2229486 Bytes = 2.1 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
Using machid 0x1029 from environment

Starting kernel ...

[sun8i_fixup]: From boot, get meminfo:
        Start:  0x40000000
        Size:   1024MB
ion_carveout reserve: 160m@0 256m@0 130m@1 200m@1
ion_reserve_select: ion chipid  [0x2004620!
ion_reserve_common: ion reserve: [0x50000000, 0x60000000]!
Loading, please wait...
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... 
Starting g_mass_storage script
https://github.com/zador-blood-stained/fel-mass-storage
Exporting MMC 0 (SD) (/dev/mmcblk0)
Done
Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

Clearly I'm missing some crucial information.  I wrote the fel-sdboot.img to an sdcard and booted it, connected to USB.  A device came up that has the same IDs as described in the fel-mass-storage instructions, but what do I do to write the image?  The page you keep referring me to stops at detecting the device.  I don't see any instructions on how to then write an image file to the device.  The closest I can see is "sunxi-fel write address file", but I don't know what the address should be.

I'll extend this page in the future.

On Windows you need to install WinUSB driver for the device with Zadig and then run "start.bat". On Linux/OS X you need to compile and install sunxi-tools and then run "start.sh"

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

http://image.armbian.com/betaimages/Armbian_5.21.161019_Nanopiair_Ubuntu_xenial_3.4.112.7z (available in a few hours) should contain everything that's needed to get up and running with NanoPi Air: nmtui/nmcli installed by default and Wi-Fi ready to be configured through network-manager. I just hope we did everything right regarding driver/firmware -- if I understood correctly Igor&Co still can't test since no dev samples around.

Link to comment
Share on other sites
Wazou

Wazou

Posted
Posted

Thanks guys for being on top of the things with the NanoPi Neo > NanoPi Air ARMbian release !

 

I'm currently firing up my NanoPi AIR cluster with the FA ubuntu but I'm now planning to switch to Armbian. But one of my major issue at the moment is to get the I2S up & running and so far it has not been a successful ride with the FA Ubuntu image. Is that something that will be implemented within the armbian release for the AIR ? 

 

Cheers;

Link to comment
Share on other sites
webbbn

webbbn

Posted
Posted

To complete the steps, after running start.sh a new drive was detected (/dev/sdd). I then dd'ed the Armbian image to /dev/sdd and power cycled the board, and it appears to have worked.

 

A new tty device was created, which brings up a console login.  There is a wlan0 network interface, but I wasn't able to configure it because nmcli is missing.  The latest version of the firmware was not available yet, so I'm using yesterday's version, which apparently doesn't have it yet.

 

After going though that, wouldn't it be easier to just have a small boot disk image that contains the full image and automatically dd's the image to the eMMC partition on boot?

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

one of my major issue at the moment is to get the I2S up & running and so far it has not been a successful ride with the FA Ubuntu image. Is that something that will be implemented within the armbian release for the AIR ?

 

This is supposed to work after adjusting fex settings so the correct pin mappings are defined. Please have a look at FA wiki which pins are exposed on the header and look through this here: http://forum.armbian.com/index.php/topic/759-tutorial-i2s-on-orange-pi-h3/

 

It's important that multiplexed pins are only defined once as active (so better set gpio_used = 0 for example).

 

None of us has a NEO PCB rev 1.1 or Air currently, we also lack the equipment to test I2S and SPDIF properly so we have to wait for users adopting these changes and submitting a correct fex file to Armbian.

 

After going though that, wouldn't it be easier to just have a small boot disk image that contains the full image and automatically dd's the image to the eMMC partition on boot?

 

 

This is normal behaviour (but requires a few fixes to nand_sata_install script now). Zador changed boot device selection so that this is now more flexible so that stuff like directly burning to eMMC is possible. After nand_sata_install script has been fixed it's simply up to the user to do it the usual way (flashing to SD card and then transferring to eMMC) or to flash directly.

 

Please keep in mind that we support over 40 devices and that we do not focus only on the smallest and most limited devices around. If FA would have designed the Air properly (providing a FEL button) then a lot of the hassles necessary now could've been saved.

Link to comment
Share on other sites
Wazou

Wazou

Posted
Posted

This is supposed to work after adjusting fex settings so the correct pin mappings are defined. Please have a look at FA wiki which pins are exposed on the header and look through this here: http://forum.armbian.com/index.php/topic/759-tutorial-i2s-on-orange-pi-h3/

 

Thank you very much; confirming I2S working on the latest pre-release of the NanoAIR using MAX98357A (PCM Input Class D Audio Power Amplifiers)

Cheers !

1
Link to comment
Share on other sites
Slawek

Slawek

Posted
Posted

Hi,

 

finally I have tested my NanoPi NEO with X11 Forwarding. It was simpler than I was expecting.

 

My steps to have X11 forwarding on "headless" NanoPi NEO to my desktop Win10 machine

 

  • Install and configure Xming X Window System on PC
  • Setup SSH Terminal access with X11 forwarding in my case PuTTY
  • Check sshd_config file according to this guide http://www.straightrunning.com/XmingNotes/trouble.php

    /etc/ssh/sshd_config

    X11Forwarding yes
    X11DisplayOffset 10
    X11UseLocalhost yes
    XAuthLocation /usr/bin/X11/xauth

    AddressFamily inet
     
  • Install Xorg: apt-get install xorg
  • reboot

You just can test the X11 forwarding running for example xclock or gterm from terminal window.

 

It works with all images "stock one" and armbian's Debian and Ubuntu.

 

Now I have Freepascal/Lazarus installed on my NanoPi NEO. It works on 512MB and 256MB version !!! Wow.

 

Now it's time to start programming ....

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept