Igor Posted February 17, 2017 Posted February 17, 2017 - Allwinner H5 - Gigabit Ethernet - 512MB (test subject) - made few tests with our testing H5 (4.10) kernel - nightly builds 2
tkaiser Posted February 17, 2017 Posted February 17, 2017 FriendlyARM themselves revealed existence and technical details (H5 at least) a week ago: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2/zh 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?
tkaiser Posted March 14, 2017 Posted March 14, 2017 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/
hojnikb Posted March 14, 2017 Posted March 14, 2017 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.
tkaiser Posted March 14, 2017 Posted March 14, 2017 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
hojnikb Posted March 14, 2017 Posted March 14, 2017 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. 1
wtarreau Posted March 14, 2017 Posted March 14, 2017 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. 1
hojnikb Posted March 14, 2017 Posted March 14, 2017 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.
tkaiser Posted March 14, 2017 Posted March 14, 2017 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)
hojnikb Posted March 14, 2017 Posted March 14, 2017 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.
Igor Posted March 15, 2017 Author Posted March 15, 2017 Added:https://www.armbian.com/nanopi-neo-2/ Fixed DTB: Blue led is not blinking. What am I missing? https://github.com/igorpecovnik/lib/commit/85f6cccbd59065c192692e9c921c3c2ed2c77ff2 1
tkaiser Posted March 15, 2017 Posted March 15, 2017 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
Igor Posted March 15, 2017 Author Posted March 15, 2017 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.
tkaiser Posted March 15, 2017 Posted March 15, 2017 26 minutes ago, Igor said: while blue is not lit and reacting to anything Thank you. Maybe trying out PA15 instead?
pezi Posted March 21, 2017 Posted March 21, 2017 There is an article from the c't magazine about this boad. Also mentioned the Armbian OS as an alternative OS to FA the ubuntu core. https://www.heise.de/newsticker/meldung/NanoPi-NEO2-Upgrade-fuer-den-Kleinstrechner-3657847.html (German language) 1
tkaiser Posted March 22, 2017 Posted March 22, 2017 And the next mutation is just around the corner: NEO Plus 2: 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.
eli Posted March 22, 2017 Posted March 22, 2017 Is just me or the friendlyELEC and orange pies sbcs looking like they came out from the same factory?
tkaiser Posted March 23, 2017 Posted March 23, 2017 Anyone wanting to express his personal opinions only or discuss off-topic stuff, please feel free to do this in this splitted thread now and let's focus here on information and development towards NEO2 and NEO Plus 2. Thanks.
eli Posted March 27, 2017 Posted March 27, 2017 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?
tkaiser Posted March 27, 2017 Posted March 27, 2017 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... 1
zador.blood.stained Posted March 27, 2017 Posted March 27, 2017 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.
eli Posted March 27, 2017 Posted March 27, 2017 57 minutes ago, zador.blood.stained said: Ugh, this is not the best option now for H5 based boards. I tend to agree Because maybe this way we gonna get an improved BSP kernel until the mainline kernel is ready
tkaiser Posted March 27, 2017 Posted March 27, 2017 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
zador.blood.stained Posted March 27, 2017 Posted March 27, 2017 24 minutes ago, tkaiser said: (FEL booting another plus) ... that is not implemented in our build system for H5 boards yet...
rodolfo Posted April 2, 2017 Posted April 2, 2017 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 !
tristan Posted April 13, 2017 Posted April 13, 2017 Does anyone know why the current nanopi neo 2 image does not include the ath9k_htc driver? The nanopi neo image included it.
Igor Posted April 13, 2017 Author Posted April 13, 2017 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
tristan Posted April 15, 2017 Posted April 15, 2017 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?
Igor Posted April 15, 2017 Author Posted April 15, 2017 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
tristan Posted April 15, 2017 Posted April 15, 2017 Command not found... A few minutes googling isn't making it clear to me how to install this if it's not already present, either.
Recommended Posts