• Announcements

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

NanoPI NEO / AIR
16 16

491 posts in this topic

Recommended Posts

@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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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? 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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, ...

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

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 ;) )

lanefu and David like this

Share this post


Link to post
Share on other sites

@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 by wildcat_paris
with heatsink or without

Share this post


Link to post
Share on other sites

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 likes this

Share this post


Link to post
Share on other sites

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 by wildcat_paris
edit

Share this post


Link to post
Share on other sites

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.

David likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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)

David likes this

Share this post


Link to post
Share on other sites

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-RPLD, 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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

wildcat_paris likes this

Share this post


Link to post
Share on other sites

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...

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

16 16

  • 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.