Jump to content

Nanopi Neo 2


Igor

Recommended Posts

On 17.2.2017 at 6:43 PM, tkaiser said:

I'm still asking myself how voltage regulation works here? Still switching between 1.1V and 1.3V or does NEO2 also make use of I2C accessible SY8106A allowing for more fine grained voltage regulation?

 

Price is known now ($15) and schematic is available too: http://wiki.friendlyarm.com/wiki/images/a/a1/Schematic_NanoPi_NEO2-v1.0_1701.pdf

 

It's 'VCC-CPUX 1.1V/3A' using MP2143DJ step-down converter. So compared to eg. Orange Pi PC2 the NEO2 is somewhat limited regarding performance due to max 1.1V Vcore voltage. According to Allwinner's recommendations this is good for up to 816MHz with some safety headroom in mind. According to Allwinner's recommendations and @ErwinH's work done on DVFS table for OPi PC2 with 1.1V 1008 MHz are the maximum with some safety headroom in mind: https://forum.armbian.com/index.php?/topic/2869-armbian-for-orangepi-pc2-allwinner-h5/&do=findComment&comment=22480

 

So we're talking about 1GHz cpufreq max, maybe even less if stability issues occur. On the other hand that doesn't matter that much since the small PCB will prevent running with higher clockspeeds for longer than a few seconds anyway due to bad heat dissipation (I strongly recommend using FriendlyELEC's NEO heatsink!)

 

Then we're also talking about single bank DRAM configuration so also expect less memory throughput (I would assume it's similar as with H3 boards so results from my testings a few months ago might apply here too: search for 'membench' in this thread for details: https://forum.armbian.com/index.php?/topic/1748-sbc-consumptionperformance-comparisons/

 

 

Link to comment
Share on other sites

3 hours ago, hojnikb said:

It's a good thing this is limited to 1.1V, because A53 cores just get awfully inefficient beyond that anyway. And since this only has mUSB power, it would spell disaster anyway.

C'mon... repeating the same untrue stuff over and over again :(

 

Every NanoPi has a 4 pin header to be powered through, every NanoPi ships with a high quality Micro USB cable with very low resistance and the stuff about A53 and 'beyond 1.1V' is so weird that I don't comment on it.

 

Edit: for whatever reasons FriendlyELEC decided to not ship the NEO2 with one of their Micro USB cables. That's sad :(

Link to comment
Share on other sites

Well, most users will use crappy microusb power adapters, which are shit as you pointed out many times.

 

As for A53 efficiency scaling, you can test it yourself. Beyond 1Ghz, power consumption ramps up quite high. I might do a test for each frequency/voltage to further illustrate that.

Link to comment
Share on other sites

3 hours ago, hojnikb said:

As for A53 efficiency scaling, you can test it yourself. Beyond 1Ghz, power consumption ramps up quite high.

It's an over-simplification. The die technology and etching resolution matters a lot as well. And my NanoPI-M3 with 8xA53 at 1.4 GHz disagrees with you, just like my Odroid-C2 at 1.536 GHz which stays really cool to the touch at full speed. Some A53 run pretty fine at 2 GHz. You'd better say that A53 is mostly used in cheap devices and that cheap devices don't scale well above 1 GHz due to the cheap technologies involved, that would be more accurate.

Link to comment
Share on other sites

2 hours ago, wtarreau said:

It's an over-simplification. The die technology and etching resolution matters a lot as well. And my NanoPI-M3 with 8xA53 at 1.4 GHz disagrees with you, just like my Odroid-C2 at 1.536 GHz which stays really cool to the touch at full speed. Some A53 run pretty fine at 2 GHz. You'd better say that A53 is mostly used in cheap devices and that cheap devices don't scale well above 1 GHz due to the cheap technologies involved, that would be more accurate.

Yes, i should clearly indicated, that this was for 40nm process. Obviously shrinking the process or using a different type of process will yield in different frequency/voltage  table. But in the context of cheap allwinner devices (as this thread is about) ~1Ghz seems to be "sweetspot" frequency.

Link to comment
Share on other sites

1 hour ago, hojnikb said:

this was for 40nm process

 

For the specific 40nm process Allwinner's manufacturing partner uses when doing A64 or H5. Some interesting stuff can be found here: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-264680901

 

Since it seems your own quick measurements with preliminary DVFS settings for OPi PC2 impressed you I just want to point out that running cpuburn-a53 isn't a real use case. It's great to get 'worst case' situations to be able to tweak settings (see this example) but cpuburn consumption numbers have close to no meaning for average workloads. The latter often consist of single threaded stuff only (then you don't even run into any throttling problems even at 1.3GHz/1.4V since one or two cores are active only) and then there's also the "race to idle" concept (finishing stuff in less time allows several subsystems to enter sleep states more quickly) and if CPU cores are sitting on a 'wait for interrupt' (WFI) instruction they enter a low-power state where current clockspeed doesn't matter that much any more (existed with older ARM designs too, since too lazy here the WFI A7 description).

 

So when looking at the bigger picture and not solely relying on load generators or benchmarks the ability to clock higher might even result in less consumption if settings are accordingly (kernel scheduler and stuff like that)

Link to comment
Share on other sites

race to sleep is all fine dandy, but if you clock the cpu too high,you might finish the work faster and let the cpu sleep, but you waste more power (and subsequently heat) for a given workload you did more damage than good, at least in the context of poorly cooled SBCs.

 

so i think high frequencies are good for peak workloads (like scrolling, opening windows etc) but anything that needs the cpu longer, scheduler should resort to the most efficient frequency point (as much work done for a given W of heat dissipated). and keep it there. Obviously determing what this frequency/voltage is would require proper power testing in real world apps + temperature should be taken into account, since that can affect power consumption too.

Link to comment
Share on other sites

49 minutes ago, Igor said:

Blue led is not blinking. What am I missing?

 

Hmm... according to this commit and schematic it's PL10 pwr/green, PA10 status/blue. Is it just 'not blinking' and you're able to access it otherwise through sysfs?

 

Edit: don't understand this line: https://github.com/friendlyarm/h5_lichee/blob/935ac674f8238649ffebc90d1b620a96240d5dad/tools/pack/chips/sun50iw2p1/configs/cheetah-p1/sys_config.fex#L1468

Link to comment
Share on other sites

1 hour ago, tkaiser said:

Hmm... according to this commit and schematic it's PL10 pwr/green, PA10 status/blue. Is it just 'not blinking' and you're able to access it otherwise through sysfs?


Both are accessible via sysfs, green is configurable while blue is not lit and reacting to anything. Will look next time.

Link to comment
Share on other sites

And the next mutation is just around the corner: NEO Plus 2:

 

NEOPlus2-1.jpg

 

NEOPlus2-2.jpg

 

H5, camera connector for OV5640, voltage regulation is back (1.1V and 1.3V as usual but FriendlyELEC admits that it does not work software-wise yet -- obviously this is about Allwinner's BSP kernel since with mainline it should just work), and surprisingly XR819 Wi-Fi as known from OPi Zero.

 

Open question: How does FriendlyELEC deal with the 2nd USB receptacle on the board (since USB data lines might be also available on the 12 pin header). Don't ask about availability please -- we don't know.

Link to comment
Share on other sites

On 3/22/2017 at 7:30 PM, tkaiser said:

surprisingly XR819 Wi-Fi as known from OPi Zero.

Do you believe we gonna get a better driver for this chip or at least a datasheet?

Link to comment
Share on other sites

8 minutes ago, eli said:

Do you believe we gonna get a better driver for this chip or at least a datasheet?

 

@zador.blood.stainedimmediately reminded my to ask for this. Done last week, waiting for an answer (in the meantime explaining to FriendlyELEC kernel dev how to use Armbian's build system since they want to start now to support all their boards with mainline kernel too. My personal goal is to get them to send PRs against Armbian's repo for new hardware and to also send those patches upstream and become board maintainers of their own hardware). Let's wait and see...
 

Link to comment
Share on other sites

Just now, tkaiser said:

@zador.blood.stainedimmediately reminded my to ask for this. Done last week, waiting for an answer (in the meantime explaining to FriendlyELEC kernel dev how to use Armbian's build system since they want to start now to support all their boards with mainline kernel too.

Ugh, this is not the best option now for H5 based boards.

First problem is the u-boot configuration. We are using a quite old u-boot branch but newer stuff wasn't accepted in mainline yet (so we are using something that works instead of trying to catch a constantly moving target).

Second problem is H5 device tree (merged to 4.11 while we are using WIP 4.10 stuff). Again, once we move to a more or less stable 4.11 or 4.12 based branch it would be more productive for the future mainlining efforts.

Link to comment
Share on other sites

57 minutes ago, zador.blood.stained said:

Ugh, this is not the best option now for H5 based boards.

 

I tend to agree :rolleyes:

Because maybe this way we gonna get an improved BSP kernel until the mainline kernel is ready

Link to comment
Share on other sites

1 hour ago, zador.blood.stained said:

Ugh, this is not the best option now for H5 based boards.

 

I forwarded your concerns but still hope FE devs try to get familiar with Armbian's build system since I'm really convinced it will save them huge amounts of time compared to deal again and again with Allwinner's BSP mess (FEL booting another plus)

 

7 minutes ago, eli said:

we gonna get an improved BSP kernel

 

There you go: https://github.com/friendlyarm/h5_lichee

 

Based on questions from a few hours ago it seems FE is also struggling with voltage regulation related to Allwinner's BSP kernel (but maybe I got that wrong, doesn't matter that much since I'm not into H5 development at all). I hope they join linux-sunxi since "Chinese whispers" through my mailbox is rather inefficient and maybe Icenowy won't have the time to answer all questions all the time :)

Link to comment
Share on other sites

Just did a short smoke test with a newly arrived Nanopi Neo2 and the nightly Armbian build. Works like a charm, LAN speeds > 800mbps, wireless stable with Edimax dongle. Using both a USB3 ethernet dongle with speeds of >250 mbps and the inbuilt GLAN the Nanopi Neo2 makes for a great little firewall/router/jumpstation. Cleverly combined with some storage hooked up to USB pins the Nanopi Neo2 is a mighty little NAS contender.

Excellent job, Armbian team ! 

Link to comment
Share on other sites

2 hours ago, tristan said:

Does anyone know why the current nanopi neo 2 image does not include the ath9k_htc driver? The nanopi neo image included it. 


Nanopi Neo 2 uses different chip and architecture (H5, arm64) kernel and configurations are not and can't be always the same. This is config for Neo 2 kernel and it looks like this module is there:

https://github.com/igorpecovnik/lib/blob/master/config/kernel/linux-sun50i-dev.config#L1764

Link to comment
Share on other sites

Hi Igor, 

Thanks for the response. You're right, it looks like it does have the module. However, it isn't working for me. I have a nanopi neo which works easily when I plug in the usb wifi adapter, but the nanopi neo 2 simply doesn't work. Hence, my assuming it didn't include the driver.

given that the driver is present, any suggestions for getting it to work?

Link to comment
Share on other sites

15 minutes ago, tristan said:

Hence, my assuming it didn't include the driver. given that the driver is present, any suggestions for getting it to work?


With logs we could be smarter :) Type: armbianmonitor -u
 

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines