Jump to content

Recommended Posts

Posted

Edit: Price seems to be $17.99

 

Just FYI: FriendlyARM is preparing another H3 board: NanoPi Air somehow related to NanoPI NEO (same low default DRAM clockspeed let me believe this). What we already know (by looking at Github commits):

  • onboard eMMC (no idea about the size)
  • no HDMI
  • no Ethernet
  • AP6212 based WiFi+BT (connected through SDIO and UART)

Personal assumptions:

  • most probably also just a single bank DRAM configuration
  • most probably also a SD card slot
  • maybe eMMC only an option and a basic version without eMMC available
  • same 40 x 40 mm dimensions as NEO, eMMC on the lower PCB side next to H3, AP6212 on the upper (where the Ethernet Jack is located on the NEO -- assumption based on heatsink design for NEO)

Therefore adding Armbian support for this board is pretty easy as soon as we're done with NanoPi NEO since it's then just combining settings for NanoPi NEO with Banana Pi M2+ (WiFi/BT).

 

No official announcement available yet and no traces in FA's wiki. But since the FriendlyARM folks follow the 'release often, release early' principle most information can be gathered from Github sources :)

<
Posted

Correct me if I'm wrong but the H3 can boot direct from eMMC without an SD card. If this board is less than $15 it'll be a home run.

Posted
  On 8/1/2016 at 11:52 AM, trewq said:

Correct me if I'm wrong but the H3 can boot direct from eMMC without an SD card. If this board is less than $15 it'll be a home run.

Yes it can - H3 (same for A10, A20 and other Allwinner SoC) has 4 SD/MMC controllers, 2 of them can be used as boot devices. And for small home automation use cases even SPI flash may be enough (once it is fully implemented in u-boot)

Posted
  On 8/1/2016 at 11:52 AM, trewq said:

Correct me if I'm wrong but the H3 can boot direct from eMMC without an SD card. If this board is less than $15 it'll be a home run.

 

Well, eMMC is just like another -- soldered -- SD card and booting from eMMC is supported by every Allwinner SoC currently known. The only question is: How to burn an OS to eMMC if no SD card slot would be present on the board (then only FEL boot would help which is already used by PhoenixSuit/LiveSuit to burn Android OS images to eMMC, maybe it's quite easy to use FEL booting to burn Linux images too)

 

Since Zador already mentioned SPI: http://linux-sunxi.org/Bootable_SPI_flash

 

The H3 based IoT device I would dream of comes with 1 MiB (8 Mbit) SPI flash to boot from, Fast Ethernet and prepared for passive PoE (using the 2 unused Ethernet cable pairs and providing a step-down converter to be able to use a higher voltage on the Ethernet cable to prevent voltage drops over large distances) for less than $10.

 

Based on our recent research to minimize consumption by adjusting settings and disabling everything that's not needed I'm pretty confident we can provide an Armbian image limiting also peak consumption of such a board to below 2.5W (and idling way below).

Posted
  On 8/1/2016 at 12:18 PM, tkaiser said:

The only question is: How to burn an OS to eMMC if no SD card slot would be present on the board (then only FEL boot would help which is already used by PhoenixSuit/LiveSuit to burn Android OS images to eMMC, maybe it's quite easy to use FEL booting to burn Linux images too)

Since there is no Ethernet FEL booting will require some manual configuration to use wireless or g_ether network. In case fastboot works in u-boot for H3, it may be easier to use it instead.

 

  On 8/1/2016 at 12:18 PM, tkaiser said:

Since Zador already mentioned SPI: http://linux-sunxi.org/Bootable_SPI_flash

 

The H3 based IoT device I would dream of comes with 1 MiB (8 Mbit) SPI flash to boot from, Fast Ethernet and prepared for passive PoE (using the 2 unused Ethernet cable pairs and providing a step-down converter to be able to use a higher voltage on the Ethernet cable to prevent voltage drops over large distances) for less than $10.

I tested SPI boot recently. Currently it's quite useles for H3 (USB and MMC are the only interfaces available after loading u-boot), but in the future it should be possible to load kernel from SPI flash too or use PXE/TFTP, and then you can make small expansion boards for existing SBCs like this (I still have to solder wires to connect 2x4 header pins to expansion board pins and Write Protect jumper; CR2032 battery for size comparison)

 

  Reveal hidden contents

 

Posted
  On 8/1/2016 at 12:52 PM, zador.blood.stained said:

Since there is no Ethernet FEL booting will require some manual configuration to use wireless or g_ether network.

 

Ha! I thought about this also in the meantime. Relying on the work done (by you and others) a few months ago it would be pretty easy to set up a PC being able to FEL boot a couple of connected H3 boards without Ethernet, do a quick hardware check and then load/burn an image to onboard eMMC. All that's needed is an Ubuntu 16.04 host (to ease setup since then your fel-boot script can be used without modification regarding prerequisits) with a bunch of USB ports (or powered UBS hubs in between) and a mechanism that checks lsusb output for new devices periodically.

 

The NanoPis just need a single USB connection between their Micro USB port and the host for both power and g_ether networking and then it's pretty easy:

  • as soon as a connected NanoPi is detected on the PC it can be FEL booted (since the fel tool now supports the --dev switch)
  • a modified small Armbian install will be loaded through USB and uses then g_ether / Micro USB to finish booting through NFS
  • optionally a few tests can run (QA checking)
  • then the real OS image will be fetched through g_ether/NFS and written to eMMC and the board will be halted

We have a throughput of ~120 Mbits/sec with g_ether on H3 boards so without any testing burning a headless image (+200MB) should be done within a minute and count of NanoPis to be handled in parallel only depends on the host's count of USB ports.

Posted

I wish this board was 36x36 dimensions with M3 screws 2.75 distance from each edge (so 30.2 betweens screws center) :)

Also connector for RPi camera if it would fit, would be nice. I am glad ethernet is gone, as anything as big as that kills the point of designing such a small board. That's why I ordered without ethernet connector.

 

36x36 is standard for many flight controllers, many multirotor frames come with holes for 36x36 board, it would be neat if you guys had NanoPi at this size :)

Posted

The standard for flight controllers are 30.5mm hole centers, at least that's the standard for OpenPilot boards, which pretty much defined the current standard.

 

We already contacted FrendlyArm to see if they might be considering building such a board, and they say they have no plans, but I suspect if they hear enough interest it might spur them on to doing something.

 

I (just yesterday) designed a carrier/breakout board just for such a purpose.  I already found some things that I plan to change in the design, but I think it's going to just barely work.  The intent is to have multiple options for connecting to existing flight controllers (UART, SPI, USB) to experiment with using the NanoPi for the higher-level control algorithms.

Posted
  On 8/24/2016 at 10:11 PM, trewq said:

It also looks like it has eMMC as well though.

 

Well, support for eMMC was obvious since weeks (by looking into FA's github repo) but we didn't know whether SD card slot is still present (when missing like on the C.H.I.P for example that would lead to some trouble flashing a new OS -- now confirmed that slot is present and eMMC has to be populated by a tool/script) and we still don't know whether eMMC is optional or not.

 

At least the name of the OS image they provide (nanopi-air-eflasher-sd8g.img.zip) let me believe that the eMMC will be 8 GB in size.

Posted

I can see that there is something called NanoPi NEO v1.1 on the wiki page: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Layout

 

Schematic dated September 2nd, 2016: http://wiki.friendlyarm.com/wiki/images/c/c4/NanoPi-NEO-V1.1-1607-Schematic.pdf

 

The main difference seems to be different voltage regulators and a change in the USB/Audio/IR pin header. We now have I2S instead of lineout and mic from the SoC codec, and the codec I/Os have been moved to a seperate header (maybe an audio jack?).

Can we expect the NanoPi Air to have this same pinout?

Posted

And they release a new camera module called CAM500B based on OmniVision OV5640 (which is good news IMO also for NanoPi M1)

 

And also breaking news regarding OV5640: great community members did what all the hardware vendors failed to do the last years (I've never seen any good image coming out of a OV5640 when running Linux and never higher resolutions than funny 640x480 pixels): http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/?p=16486

Posted

Thanks! 

I saw FA has a week of vacations so we need to wait at least until 8th + shipping time ...

Posted

Hi,

 

I am using Armbian for NanoPI NEO AIR + CAM500B.  I am unable to see any /dev/video0.

 

I am able to get camera working with FA default image. 

 

Here is my dmeg out put.

 

  Reveal hidden contents

 
I really appreciate any help to get this working. I would like to use OV5640 with https://github.com/avafinger/ov5640drivers to control frame rate.
 
Thanks
Posted
  On 1/6/2017 at 12:03 PM, sri said:

 

Hi,

 

I am using Armbian for NanoPI NEO AIR + CAM500B.  I am unable to see any /dev/video0.

 

I am able to get camera working with FA default image. 

 

Here is my dmeg out put.

 

  Reveal hidden contents

 
I really appreciate any help to get this working. I would like to use OV5640 with https://github.com/avafinger/ov5640drivers to control frame rate.
 
Thanks

 

 

Start a new post, with a good title. Makes it easier for others to find. 

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines