NanoPI NEO / AIR

[Per-Mattias Nordkvist]

This is a rather interesting board isn't it? H3, GPIO, 0.5GB memory. 

 

http://www.cnx-software.com/2016/07/07/smaller-than-raspberry-pi-zero-meet-nanopi-neo-arm-linux-development-board/

 

Would it be possible to run this on Armbian?

[wildcat_paris]

@Per-Mattias Nordkvist

 

I guess the hardware has some similarities with NanoPi M1. Armbian has a working image for my M1. so maybe if you are lucky

 

the board is very small that's very nice but the huge issue is the crap power design to feed the H3 SoC (the same as M1)

 

Either you need a very big heatsink OR you downclock the CPU as much as possible to limit overheating.

 

You get for what you pay

 

edit: currently my M1 with a copper heatsink, idling @ 240MHz has a temperature of 57°C

[zador.blood.stained]

the board is very small that's very nice but the huge issue is the crap power design to feed the H3 SoC (the same as M1)

 

Either you need a very big heatsink OR you downclock the CPU as much as possible to limit overheating.

Schematic is available already, and CPU power design is the same as OPi One/Lite (and NanoPi M1) - 2 voltages controlled via GPIO, so it's not that bad (at least it's not a fixed voltage  ). However board size is relatively small and DRAM type is DDR3 (1.5V), so thermal performance probably will be worse than OPi One/Lite, but better than fixed voltage BPi M2+.

 

On the bright side - finally somebody decided to wire USB ports and audio inputs/outputs to 0.1" pitch header, so you can actually solder something without using magnifying glass, needle sized soldering iron and hair thin wires.

[Per-Mattias Nordkvist]

Ok. Good to know. 

 

Anyone here using the new OrangePi Power PC Plus? I bought a batch of 20 units to try out but I seem to have heat problems with that board as well. The CPU runs super hot. Can it take a while for power management to adjust or is there an issue? 

[Igor]

Anyone here using the new OrangePi Power PC Plus? I bought a batch of 20 units to try out but I seem to have heat problems with that board as well. The CPU runs super hot. Can it take a while for power management to adjust or is there an issue? 

 

Are you using latest Armbian for this board?

[Per-Mattias Nordkvist]

I used 5.14 but upgraded to 5.15. I have not had problems with Power PC or other notn Lite/One boards so I was surprised. Maybe I have to do it all over. 

 

Is it better to run 5.14 or should I wait for a 5.15 image? 

[Igor]

5.14 or newer should be fine.

 

Try using some diagnostic and paste resoults here:

 

armbianmonitor -m

 

Those are mine: OPi PC+ without heat sink or enclosure.
Idle:

20:38:50: 1008MHz  0.65  15%   3%  11%   0%   0%   0%   36°C
20:38:55:  480MHz  0.77  15%   3%  11%   0%   0%   0%   35°C
20:39:00:  480MHz  0.71  14%   3%  10%   0%   0%   0%   35°C
20:39:05:  480MHz  0.65  14%   3%  10%   0%   0%   0%   35°C
20:39:10:  480MHz  0.60  13%   3%   9%   0%   0%   0%   35°C
20:39:16:  480MHz  0.55  13%   3%   9%   0%   0%   0%   35°C
20:39:21:  480MHz  0.51  12%   3%   9%   0%   0%   0%   34°C

Moderate load:

20:40:24: 1296MHz  1.13  16%   3%  12%   0%   0%   0%   47°C
20:40:29: 1008MHz  1.20  16%   3%  12%   0%   0%   0%   42°C
20:40:34: 1152MHz  1.19  16%   3%  12%   0%   0%   0%   44°C
20:40:39: 1008MHz  1.17  17%   3%  12%   0%   0%   0%   44°C
20:40:44:  576MHz  1.16  17%   4%  12%   0%   0%   0%   44°C
20:40:49: 1008MHz  1.31  17%   4%  12%   0%   0%   0%   44°C
20:40:54: 1008MHz  1.52  18%   5%  12%   0%   0%   0%   44°

Install RPI monitor with:

 

armbianmonitor -r

 

And check temperatures, cooling state, ...

[Ford Prefect]

Cooling seems easier than with the CPU on component side.

Someone has an idea of the power saved by not using HDMI at all ?

[wildcat_paris]

@zador.blood.stained

Schematic is available already, and CPU power design is the same as OPi One/Lite (and NanoPi M1) - 2 voltages controlled via GPIO, so it's not that bad (at least it's not a fixed voltage  ). However board size is relatively small and DRAM type is DDR3 (1.5V), so thermal performance probably will be worse than OPi One/Lite, but better than fixed voltage BPi M2+.

 

On the bright side - finally somebody decided to wire USB ports and audio inputs/outputs to 0.1" pitch header, so you can actually solder something without using magnifying glass, needle sized soldering iron and hair thin wires.

 

yes I read quickly the schematic yesterday looking at the voltage controller, so I can call (bend?) this board like TK (a movie named "Bend it like TK!" or "trash me that crappy board before it gets fire")

 

ok, DDR3 1.5V is better. thanks.

 

ok you mean 2.54 millimeters. Awesome I even could solder it.

[tkaiser]

Either you need a very big heatsink OR you downclock the CPU as much as possible to limit overheating.

 

Please stop spreading such nonsense. The correct answer is "Use Armbian defaults and you're done". We spent days of work developing sane dvfs and throttling settings. There's no need to fiddle around with settings since throttling prevents from overheating!

 

If you use a heatsink, throttling jumps in later, if you use a large heatsink even later and if you combine it with a fan maybe never. It's that simple. Statically downclocking is bullshit since why not allowing the CPU to run single threaded stuff at maximum clockspeeds?

 

H3 on this board can run at 1200 MHz (or even higher clockspeeds when reliability has been tested individually), heat dissipation might not be that great as we already know from NanoPi M1 but since the kernel throttles all the user has to do to is to think about the workloads he wants to run and then choose an appropriate heatsink.

 

BTW: Since H3 is on the lower PCB side this small board is perfect for actively cooled clusters. Simply design a tube with 120 mm diameter, put one large 120mm fan on the bottom and one on the top and use 8 NanoPi NEO per row. The PCB side with H3 and huge heatsink mounted towards the inner side of the tube will make heat dissipation as effective as possible while still allowing easy access to SD card, USB and Ethernet on the outside.

 

This way you can use 8 NanoPi NEO (40x40mm) per row and at a height of 200 mm you get already 40 boards or 160 CPU cores. What makes such a 'cluster design' somewhat moronic is the needed amount of network switches and room for Ethernet/power cabling, also amount of DRAM and type (only one module so 16 bit access and DDR3 instead of DDR3L) so maybe we should think about an IoT device instead of cluster node.

 

Would be interesting whether SPI pins are routed to the connectors (didn't checked schematics already) since Allwinner SoCs could boot from cheap SPI NOR flash (if board vendors would get the idea) and then implement PXE: http://linux-sunxi.org/Bootable_SPI_flash

 

(really looking forward to Xunlong's Orange Pi Zero -- maybe this comes with SPI flash, allows passive PoE and netbooting and so on -- ok, just dreaming )

[wildcat_paris]

@TK

Please stop spreading such nonsense. The correct answer is "Use Armbian defaults and you're done". We spent days of work developing sane dvfs and throttling settings. There's no need to fiddle around with settings since throttling prevents from overheating!

 

If you use a heatsink, throttling jumps in later, if you use a large heatsink even later and if you combine it with a fan maybe never. It's that simple. Statically downclocking is bullshit since why not allowing the CPU to run single threaded stuff at maximum clockspeeds?

 

So tell me why even with 5.16 kernel, my NanoPi M1 with "stress -c 5" and "sudo armbianmonitor -r"

 

cpufreq-info changes on its own

 current policy: frequency should be within 240 MHz and 1.01 GHz.

 current policy: frequency should be within 240 MHz and 816 MHz.

I am in trouble to understand the following output

 

 

gr@nanopim1:~$ sudo armbianmonitor -m
[sudo] password for gr:
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
08:47:40: 1008MHz  0.84  31%   0%  30%   0%   0%   0%   68°C
08:47:45: 1008MHz  1.17  31%   0%  30%   0%   0%   0%   68°C
08:47:51: 1008MHz  1.48  31%   0%  30%   0%   0%   0%   69°C
08:47:56: 1008MHz  1.76  31%   0%  30%   0%   0%   0%   69°C
08:48:01: 1008MHz  2.33  31%   0%  30%   0%   0%   0%   68°C
08:48:06:  816MHz  2.54  31%   0%  30%   0%   0%   0%   70°C
08:48:12: 1008MHz  2.74  31%   0%  30%   0%   0%   0%   69°C
08:48:17: 1008MHz  2.92  31%   0%  30%   0%   0%   0%   68°C
08:48:22: 1008MHz  3.09  31%   0%  30%   0%   0%   0%   70°C
08:48:28: 1008MHz  3.24  31%   0%  30%   0%   0%   0%   66°C
08:48:33:  816MHz  3.38  31%   0%  30%   0%   0%   0%   65°C
08:48:38:  816MHz  3.51  31%   0%  30%   0%   0%   0%   70°C
08:48:43: 1008MHz  3.63  31%   0%  30%   0%   0%   0%   67°C
08:48:49: 1008MHz  3.74  31%   0%  30%   0%   0%   0%   67°C
08:48:54: 1008MHz  3.84  31%   0%  30%   0%   0%   0%   66°C
08:48:59:  816MHz  3.93  31%   0%  30%   0%   0%   0%   66°C
08:49:05:  816MHz  4.02  31%   0%  30%   0%   0%   0%   70°C
08:49:10:  816MHz  4.10  31%   0%  30%   0%   0%   0%   71°C
08:49:15: 1008MHz  4.17  31%   0%  30%   0%   0%   0%   67°C
08:49:20:  816MHz  4.24  31%   0%  30%   0%   0%   0%   71°C
08:49:26: 1008MHz  4.38  31%   0%  30%   0%   0%   0%   69°C
08:49:31:  816MHz  4.43  31%   0%  30%   0%   0%   0%   70°C
08:49:36: 1008MHz  4.63  31%   0%  30%   0%   0%   0%   71°C
08:49:42: 1008MHz  4.69  31%   0%  30%   0%   0%   0%   67°C
08:49:47:  816MHz  4.72  31%   0%  30%   0%   0%   0%   70°C
08:49:52: 1008MHz  4.74  31%   0%  30%   0%   0%   0%   71°C
08:49:57: 1008MHz  4.76  31%   0%  30%   0%   0%   0%   67°C
08:50:03:  816MHz  4.78  31%   0%  30%   0%   0%   0%   71°C
08:50:08: 1008MHz  4.80  31%   0%  31%   0%   0%   0%   69°C
08:50:13:  816MHz  4.81  31%   0%  31%   0%   0%   0%   68°C
08:50:19:  816MHz  4.91  31%   0%  31%   0%   0%   0%   72°C
08:50:24: 1008MHz  4.91  31%   0%  31%   0%   0%   0%   69°C
08:50:29:  816MHz  4.92  31%   0%  31%   0%   0%   0%   72°C
08:50:34:  816MHz  4.93  31%   0%  31%   0%   0%   0%   72°C
08:50:40: 1008MHz  5.01  31%   0%  31%   0%   0%   0%   69°C
08:50:45:  816MHz  5.01  31%   0%  31%   0%   0%   0%   72°C
08:50:50: 1008MHz  5.01  31%   0%  31%   0%   0%   0%   72°C
08:50:56: 1008MHz  5.01  31%   0%  31%   0%   0%   0%   69°C
08:51:01:  816MHz  5.17  31%   0%  31%   0%   0%   0%   69°C
08:51:06: 1008MHz  5.16  31%   0%  31%   0%   0%   0%   68°C
08:51:11: 1008MHz  5.14  31%   0%  31%   0%   0%   0%   69°C
08:51:17:  816MHz  5.19  31%   0%  31%   0%   0%   0%   72°C
08:51:22:  816MHz  5.18  32%   0%  31%   0%   0%   0%   71°C
08:51:27:  816MHz  5.16  32%   0%  31%   0%   0%   0%   72°C
08:51:33:  816MHz  5.15  32%   0%  31%   0%   0%   0%   73°C
08:51:38:  816MHz  5.14  32%   0%  31%   0%   0%   0%   69°C
08:51:43:  816MHz  5.13  32%   0%  31%   0%   0%   0%   72°C
08:51:48: 1008MHz  5.12  32%   0%  31%   0%   0%   0%   69°C
08:51:54: 1008MHz  5.11  32%   0%  31%   0%   0%   0%   70°C
08:51:59: 1008MHz  5.10  32%   0%  31%   0%   0%   0%   69°C
08:52:04: 1008MHz  5.09  32%   0%  31%   0%   0%   0%   69°C
08:52:10:  816MHz  5.08  32%   0%  31%   0%   0%   0%   71°C
08:52:15:  816MHz  5.08  32%   0%  31%   0%   0%   0%   70°C
08:52:20: 1008MHz  5.07  32%   0%  31%   0%   0%   0%   69°C
08:52:26:  816MHz  5.07  32%   0%  31%   0%   0%   0%   71°C
08:52:31:  816MHz  5.06  32%   0%  31%   0%   0%   0%   70°C
08:52:36:  816MHz  5.06  32%   0%  31%   0%   0%   0%   69°C
08:52:41:  816MHz  5.05  32%   0%  31%   0%   0%   0%   73°C
08:52:47: 1008MHz  5.12  32%   0%  31%   0%   0%   0%   70°C
08:52:52: 1008MHz  5.11  32%   0%  31%   0%   0%   0%   69°C
08:52:57:  816MHz  5.10  32%   0%  31%   0%   0%   0%   69°C
08:53:03:  816MHz  5.09  32%   0%  31%   0%   0%   0%   70°C
08:53:08:  816MHz  5.08  32%   0%  31%   0%   0%   0%   72°C
08:53:13:  816MHz  5.08  32%   0%  31%   0%   0%   0%   71°C
08:53:19: 1008MHz  5.07  32%   0%  31%   0%   0%   0%   69°C
08:53:24:  816MHz  5.06  32%   0%  31%   0%   0%   0%   72°C
08:53:29:  816MHz  5.06  32%   0%  31%   0%   0%   0%   71°C
08:53:34:  816MHz  5.05  32%   0%  31%   0%   0%   0%   69°C
08:53:40:  816MHz  5.05  32%   0%  31%   0%   0%   0%   72°C
08:53:45:  816MHz  5.05  32%   0%  31%   0%   0%   0%   70°C

 

 

 

edit: with or without copper heatsink, it is the same

Edited July 8, 2016 by wildcat_paris
with heatsink or without

[tkaiser]

So tell me why even with 5.16 kernel, my NanoPi M1 with "stress -c 5" and "sudo armbianmonitor -r"

 

cpufreq-info changes on its own

 current policy: frequency should be within 240 MHz and 1.01 GHz.

 current policy: frequency should be within 240 MHz and 816 MHz.

 

That's throttling! What else?!

 

H3 reports higher temperature and our settings limit cpufreq automatically in this situation. So you already see that the kernel reduces clockspeeds when starting to heat up so you know that throttling is working. Why do you advice others to fiddle around with settings then? That's what throttling is made for: reducing clockspeeds when necessary (compare stress or running benchmarks with normal use cases: most of the times we deal with single threaded workloads and therefore reducing maximum clockspeed by default is simply dumb as hell -- allow the max and let throttling do the job!)

[wildcat_paris]

That's throttling! What else?!

 

so NanoPi M1 is crap and probably NanoPI Neo as well. ("you get for what you paid")

 

Using a H3 SoC and using it at 50% because of low cost voltage management is madness, isn't it?

 

edit : it is the very first time I notice such a behavior among all my ARM boards, as Tido implied I shouldn't have bought it.

Edited July 8, 2016 by wildcat_paris
edit

[tkaiser]

so NanoPi M1 is crap and probably NanoPI Neo as well. ("you get for what you paid")

 

Using a H3 SoC and using it at 50% because of low cost voltage management is madness, isn't it?

 

Sorry, but we already know that it's not the voltage regulator that makes the real difference regarding overheating (OPi One/Lite use exactly the same as NanoPi M1/NEO). Xunlong  seems to use copper layers inside the PCB on Orange Pis to improve heat dissipation away from the SoC. I read some people complain about this since other PCB components get hot too (SD card for example). So based on perspective less heat dissipation through PCB design on the NanoPis can be considered both bug and feature.

 

Not all use cases require 100% CPU load on all cores, in fact when trying to use a H3 device as an IoT node you might want to limit max cpufreq to something like 600 MHz (when I did some tests with OPi PC then this setting ensured consumption never exceeding 2.5W while still being faster than most dual-core ARM SoCs when workloads are multithreaded)

 

If FriendlyARM provides huge shipping discounts then NanoPi NEO might be interesting for bulk orders. The connector pinout is interesting since you could provide an add-on with SPI flash that makes netbooting possible (could also include a passive PoE splitter to power the board through Ethernet), the 2 available USB ports could be combined with an add-on that uses two directly wired USB-to-SATA bridge chips and so on... I see a lot of use cases for a device like this. And I hope others will come up with similar designs (especially hoping for Xunlong here!)

 

Regarding thermal issues: They still provide the primitive voltage regulator to be able to switch between 1.1V and 1.3V and this really helps getting throttling more efficient (as can be seen with Banana Pi M2+ where the 'engineers' used the same voltage regulator but 'forgot' to add adjusting VDD_CPUX through GPIO access so Banana Pi M2+ always runs with 1.3V and is the slowest H3 device around). If you measure identical throttling behaviour with and without heatsink on your NanoPi M1 then simply your heatsink sucks or it is not mounted properly. But for an IoT node no heatsink is necessary since H3 is pretty performant even when throttling reduces CPU clockspeeds to 50% or below.

[wildcat_paris]

@TK

 

thank you for the detailed explanation. All is pretty clear now.

[tkaiser]

We should also not forget that NanoPi NEO is the first H3 device with SoC on the other PCB side. Therefore heat dissipation can be improved easily without a classical heatsink but instead using a thermal pad between SoC and a large metal plate/enclosure. With such a conductive silicone pad like this you can make thermal pads for 49 H3 (14x14mm). Then use 3 mm spacers and a metal enclosure or a thick metal plate, put thermal pad between metal and H3 and you're done (tested with Beelink X2 where cooling is done exactly like this -- you get different thermal characteristics especially cooling down takes way longer but the whole approach is still pretty effective)

 

By using such a large heatsink like this (important: the space between the fins is large enough to work without forced airflow) as enclosure top, mounting the NanoPi NEO upside down inside connecting H3 and heatsink with a thermal pad and adding a 3D printed case bottom to it I doubt overheating is possible.

[zador.blood.stained]

Would be interesting whether SPI pins are routed to the connectors (didn't checked schematics already) since Allwinner SoCs could boot from cheap SPI NOR flash (if board vendors would get the idea) and then implement PXE: http://linux-sunxi.org/Bootable_SPI_flash

Yes, PC0-PC3 are wired to 13x2 header as SPI0 pins, so this should work.

[tkaiser]

Yes, PC0-PC3 are wired to 13x2 header as SPI0 pins, so this should work.

 

Thx for the confirmation. By looking through FriendlyARM's wiki page I already had the same assumption. And I asked FriendlyARM whether they think about populating the connectors with GPIO headers and maybe provide some sort of a netboot HAT (containing 1MiB SPI flash, a passive PoE splitter and a step-down converter): http://www.cnx-software.com/2016/07/07/smaller-than-raspberry-pi-zero-meet-nanopi-neo-arm-linux-development-board/#comment-528621

 

And while thinking about other use cases I found that combining a 43x46 mm 3D printed enclosure with a 40x41mm heatsink as 'top cover' (connecting to H3 through a thermal pad) would make for a nice small enclosure solving any potential overheating problems (distance between mounting holes is 35.4mm -- would fit perfectly)

[roel]

tkaiser,

 

thanks for the link to the thermal pads, I was thinking to make a copper spacer the size of the H3 and connect it to a metal base board with thermal paste.  But the silicone pad will make it easier.

 

I was planning to add 2 usb to sata bridges on the expansion holes, but will the provided current of the board be enough to drive to 2.5" drives?  Or should I provide external power?

[tkaiser]

I was planning to add 2 usb to sata bridges on the expansion holes, but will the provided current of the board be enough to drive to 2.5" drives?

 

Depends on the drives in question. When modern 2.5" drives are already spinning consumption isn't that high and you can run a H3 board with 2 disks connected even when powered only through Micro USB (1.8A max by specs!).

 

Peak consumption when drives spin-up is way more important (each drive might need up to 1A in this situation). So it depends whether you can control spin-up or not (I played around with this stuff when thinking about combining A20 with a port multiplier, a small PSU and several 3.5" disks that should be used only concurrently and never in parallel -- depending on the disk and firmware revision some can be configured to stay spun off when power is provided and wait for ATA commands to spin-up later. But using a MOSFET or something like this and provide power through GPIO is more reliable and this way you can ensure a delayed spin up of more than one disk)

 

Please keep in mind that these silicone pads do not transport heat that good as a direct metal connection with a thin thermal paste film between. But it works pretty well (at least in Beelink X2 where such a thermal pad is used together with a large/thick metal plate above H3)

[zador.blood.stained]

And I asked FriendlyARM whether they think about populating the connectors with GPIO headers and maybe provide some sort of a netboot HAT (containing 1MiB SPI flash, a passive PoE splitter and a step-down converter): http://www.cnx-software.com/2016/07/07/smaller-than-raspberry-pi-zero-meet-nanopi-neo-arm-linux-development-board/#comment-528621

Please, why? Buying and soldering the connector that you want (straight or angled jack (PBS, PBS-R, PBD, PBD-R) or straight or angled plug (PLS, PLS-R, PLD, PLD-R) is much easier than desoldering something that was soldered in the first place), so IMO for a cost-down minimal board leaving connectors unsoldered is the best option.

[tkaiser]

for a cost-down minimal board leaving connectors unsoldered is the best.

 

Totally agree. But in case they start thinking about adopting RPi's HAT concept and come up with such a Netboot/PoE and a RFID HAT to use this stuff in a business environment prepopulated headers make more sense (BTW: Using SPI0 for both booting and accessing RFID readers won't work I would assume?).

 

If I want to deploy an authenticated print/scan server solution simply sticking together NanoPI NEO with RFID HAT and maybe netboot/PoE HAT is something different compared to start soldering first. So in case they provide HATs they IMO should think about selling the board with headers for $1 or $2 more.

[zador.blood.stained]

Totally agree. But in case they start thinking about adopting RPi's HAT concept and come up with such a Netboot/PoE and a RFID HAT to use this stuff in a business environment prepopulated headers make more sense.

Yes, but it makes sense to me to provide both boards for HATs and business environments with soldered connectors AND boards for hardware hackers with unsoldered connectors. It may be either separate boards like M1 and Neo, or the same board but in 2 variants (Neo with soldered connectors and Neo with unsoldered connectors).

 

BTW: Using SPI0 for both booting and accessing RFID readers won't work I would assume?

If they wire SPI1 instead of SPI0 to GPIO headers, you will have an available SPI interface (but -1 UART interface), from the link you posted earlier: https://linux-sunxi.org/Bootable_SPI_flash

[tkaiser]

I was thinking to make a copper spacer the size of the H3 and connect it to a metal base board with thermal paste.

 

Should work with these copper shims also but I would fear vibrations (maybe using a laser cut cardboard to prevent the copper shim sliding around). I already thought about combining this approach with metal enclosures (also containing an open frame PSU) like this or this (or even this cutting out the space for Ethernet and USB jack). But to be honest: Given shipping costs, heat dissipation, amount of DRAM and count of readily available connectors Orange Pi PC is still the way better choice for most use cases I would need H3 boards for

 

@Zador: Also agree on providing the populated GPIO header version as an alterantive and not a replacement for the Neo without headers soldered.

[roel]

tkaiser,

 

I work in a workshop, so I can make a custom enclosure with trash.  I can also mill away the space around the position of the SOC so I only need thermal paste ones and how more sharp edges on the base plate, how better the heat dissipation.

Regarding the shippingcost, it's not urgent so shipping cost may go down when the OPI zero arrives.  In fact I still hope allwinner will release the new A20 soc soon (if they ever do) and there will be similar boards as the NEO with the A20 SOC. If...

 

I wonder how they will react on your questions about the HAT's.

[martinayotte]

@tkaiser,

 

Could you provide links for your best choices of USB-SATA ?

 

I've purchased one 1 year ago, but never use it yet.

 

Maybe you should test it with my OPi-Plus-2E ...

[tkaiser]

Could you provide links for your best choices of USB-SATA ?

 

http://linux-sunxi.org/USB/UAS#UASP_capable_chipsets_in_disk_enclosures

 

Since some vendors fail to differentiate correctly between the different ASMedia chipsets and since ASMedia has a long history of re-using USB product IDs for totally different chips I try to get JMS567/JMS568 but ASM1153 is ok too (adapters with or without enclosure are available for 10€ here including VAT). Performance/features identical (all SAT capable and therefore SMART available and hdparm can be used)

[tkaiser]

BTW: Just looked through FriendlyARM's github repo. They lowered DRAM clockspeed for NanoPi M1 (from the 624 MHz we used all the time since we do not trust in the 672 MHz -- Allwinner's defaults) and on the NEO it's even worse. This new board has only a single bank memory implementation (so no 32-bit memory accesses) and they clock it with just 432 MHz.

 

It seems in case we want to support this board OS images for Nano Pi M1 won't suffice due to different DRAM. I adopted FriendlyARM's fex file to our 'standards' (THS/throttling and LED handling) and added it to the repo: https://github.com/igorpecovnik/lib/blob/master/config/fex/nanopineo.fex

[tkaiser]

Hmm... all that's missing to support the NEO is a board config as below and the necessary u-boot defconfigs for default/dev using 432 MHz DRAM clock or am I'm missing something?

# H3 quad core 256/512MB SoC
BOARD_NAME="NanoPi NEO"
LINUXFAMILY=sun8i
BOOTCONFIG=FriendlyARM_NanoPi_NEO_defconfig
MODULES="#gpio_sunxi #w1-sunxi #w1-gpio #w1-therm #sunxi-cir"
MODULES_NEXT=""
CPUMIN=240000
CPUMAX=1200000
CLI_TARGET="jessie:default"
DESKTOP_TARGET=""
KERNEL_TARGET="default,dev"

BTW: For whatever reasons we specify NanoPi M1 as Wi-Fi capable. But I can't spot any chip or antenna on the board...

[wildcat_paris]

BTW: For whatever reasons we specify NanoPi M1 as Wi-Fi capable. But I can't spot any chip or antenna on the board...

 

NanoPi M1 has no Wifi on board as you can guess