Nanopi NEO2 CPU frequency issue

[ulorentz]

Hi!
I've recently bought a nanopi NEO2 which features an Allwinner H5. On FriendlyArm website (and on Allwinner's too) it is stated that the H5 is clocked 1.5Ghz. I need to perform some heavy job and and noticed that the cpu frequency hits, at full power, only 1Ghz. I checked using cpufreq-info and I got:

driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 244 us.
hardware limits: 120 MHz - 1.01 GHz
available frequency steps: 120 MHz, 240 MHz, 312 MHz, 480 MHz, 624 MHz, 816 MHz, 1.01 GHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
current policy: frequency should be within 120 MHz and 1.01 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.01 GHz (asserted by call to hardware).
cpufreq stats: 120 MHz:58.40%, 240 MHz:0.75%, 312 MHz:0.82%, 480 MHz:0.47%, 624 MHz:0.65%, 816 MHz:0.64%, 1.01 GHz:38.28% (66)

which clearly says that the cpu is limited to 1.01 Ghz by hardware. I am sure the allwinner H5 could reach 1.5, so the options are two: or friendly elec has limited by hardware their nanopi (in that case it would absolutely not fair to state on the website 1.5ghz) or it is limited by the kernel.

Hoping the case is the second one (I bought two of them!), can you help me? Is there a way to compile the kernel allowing the true maximum frequency?

Thank you very much

[tkaiser]

36 minutes ago, ulorentz said:

which clearly says that the cpu is limited to 1.01 Ghz by hardware

 

Nope. Software doesn't know that much about hardware in this case. NEO2 has no voltage regulation and H5 is fed with 1.1V which limits maximum cpufreq on this board to 812 MHz (maybe 864 MHz). FriendlyELEC learned from a conversation with open source community that with mainline kernel they could make use of DVFS (dynamic voltage frequency scaling), something that still seems not possible with Allwinner's BSP. As a consequenze they dropped Allwinner's software offerings, rely on mainline u-boot/kernel now, have DVFS working and even re-designed a few H5 boards to implement better voltage regulation (eg NanoPi M1 Plus 2, NEO Plus2 or the new NEO Core2 which are both equipped with an I2C accessible voltage regulator).

 

What limits cpufreq is DVFS (the higher the clockspeeds the higher VDD_CPUX voltage provided). With NEO2 you're out of luck since this board remains at 1.1V all the time. All fixes in software (adjusting cpufreq OPP or thermal trip points) will only result in instabilities, freezes, crashes but not in higher performance. It's slightly larger sibling NEO Plus2 can switch up to 1.3V (~1200 MHz) and M1 Plus 2 as well as NEO Core2 can theoretically be fed with +1.4V which would allow for slightly higher clockspeeds (increasing temperature and consumption a lot).

 

On small boards like these NEOs this is of course absolutely useless unless since heat dissipation is a huge problem. Without huge heatsink(s) plus additional fan(s) don't think about running any load at 1 GHz clockspeed or above over longer periods of time (read as: few minutes).

[ulorentz]

Thanks for the very accurate answer.
I wrote (few days ago) to the tech support of friendlyelec about that issue and they answered me in a very misguiding way:

"Hi,

    The board now change the frequency dynamicly. More info you can see this link:https://forum.armbian.com/index.php?/topic/4263-nanopi-neo2-cpu-frequency/ 

https://forum.armbian.com/index.php?/topic/4734-nanopi-neo-plus2/ Maybe the link can help you.

thank you! "

 

What really upsets me is that they write on their site that the frequency is 1.5ghz. I have no problem with 1ghz (considering the very low price, it's still good for a 64 bit quad core ), just I don't like to claim things not true.
For the rest, the board seems to work quite well: with the huge heat sink and a fan it doesn't get too hot using it at full load.

Just a pity for the frequency things. I was looking for a performant board with low price, and this seemed the best one. Do you know any other comparable product? Not banana things, I had very bad experiencies with banana pi boards...

[zador.blood.stained]

36 minutes ago, ulorentz said:

I was looking for a performant board with low price, and this seemed the best one. Do you know any other comparable product?

Please define the "low price" as a number (max), and maybe define other hardware requirements that you need - it will be much easier to answer such questions with more initial info.

[tkaiser]

31 minutes ago, ulorentz said:

https://forum.armbian.com/index.php?/topic/4734-nanopi-neo-plus2/ Maybe the link can help you

 

Well, this one is about NEO Plus 2 and not NEO 2 (and there's also explained what happened and why they re-designed NEO Plus 2), so maybe this is all a misunderstanding? I won't check their site for the 1.5GHz claim since pretty useless, especially simce we know that with proper voltage regulation you can overvolt H3/H5 devices and then 1.5 GHz are most probably possible (though I never understood why people buy the slowest devices on earth if they're looking for performance  )

 

'Comparable' might be an Orange Pi PC2 -- also H5 but with an I2C capable voltage regulator so you're free to fry H5 with the voltage you want and can then allow the CPU cores to clock higher, also higher DRAM bandwidth which might be important for certain types of workloads. But IIRC with Armbian currently dvfs/cpufreq scaling isn't working on H5 boards anyway so you'll have fun tweaking an FriendlyELEC image (they use a 4.11.2 kernel with all necessary patches applied) to run on an Orange Pi

 

As Zador suggested: please describe the 'problem' and your limits...

[ulorentz]

The requirements are simple: a quad-core with good frequency. What I need is run an intensive CPU program (it uses only cpu, not ram, nor sd). To the question why people buy slow device looking for performance, my answer (that fits just my case) is because I don't need a time efficient computer, but more an energy efficient (and, as you know better than me, ARM devices are more energy efficient than amd64); still I need not to be too slow, but a good ARM with performance and energy efficiency.

Thanks again for answers!

Ps: a good thing about NEO2 is that I have launched about 26hours ago a job that takes all four cores a 100% and temp is still at 55°C, running very smoothly and without problems (it has an heat sink and a small fan)

[Pat]

Hi, sorry in advance if my question is about a point already explained. I just bought the NanoPI Neo2 and I've red as far as I know all discussion about the CPU frequency issue. The status seems sticked on the fact that V CPU can not exceed 1.1V and for this reason the max frequency we can reach with stability is 816MHz.

However, when I read the schematic plan (Schematic_NanoPi_NEO2-V1.1-1711.pdf), there's seem to be a voltage regulation for vCPU with the ability to control the level between 1.1-1.3V through GPIO.

See POWER 01 / VCC-CPUX 1.1V/3A

GPIOL6/CPUX-VSET = 0, VDD-CPUX=1.1V

GPIOL6/CPUX-VSET = 1, VDD-CPUX=1.3V

 

Is it something related to a new design, not available at the time of this thread (2017, August) ?

Can someone help to understand what is the meaning of these GPIOL6 settings ?

 

Thanks in advance.

[raschid]

Correct. These discussions refer to rev 1.0 - the schematic details the new rev 1.1. The new version allows to power the SoC with 1.1V or 1.3V (for higher CPU frequencies) by changing the state of GPIO L6. AFAIK armbian currently does not support the new revision.

[guidol]

1 hour ago, raschid said:

the new rev 1.1. The new version allows to power the SoC with 1.1V or 1.3V (for higher CPU frequencies) by changing the state of GPIO L6.

AFAIK armbian currently does not support the new revision.

the "new" V1.1 is alo called the LTS-Version
see the differences: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2#Datasheet_.26_Schematics

[reverend_t]

Is there any news on Armbian support for the v1.1 revision of the NanoPi Neo2 with dvfs? Because of the sensible placement of the cpu, it may be the only small board capable of consistently high speeds (with enough thermal care).

 

If not, could someone point me to how I might go about compiling a working kernel for testing, (I can manually monitor temperatures if thermal monitoring isn't fixed yet on the H5) or even beginning to add more formal support for the board? Not expecting any hand holding

[5kft]

On 7/3/2018 at 3:36 AM, reverend_t said:

Is there any news on Armbian support for the v1.1 revision of the NanoPi Neo2 with dvfs? Because of the sensible placement of the cpu, it may be the only small board capable of consistently high speeds (with enough thermal care).

 

If not, could someone point me to how I might go about compiling a working kernel for testing, (I can manually monitor temperatures if thermal monitoring isn't fixed yet on the H5) or even beginning to add more formal support for the board? Not expecting any hand holding

 

The challenge with the Neo2 is that there are two hardware versions, so by default Armbian can't enable the regulator that is present only in the new 1.1 version of the board.  However I made a patch that I use for my Neo2 v1.1 board that adds support for the MP2143DJ regulator to the DT - see https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/sunxi-next-h5-nanopi-neo2-fix-leds-add-regulator.patch (this also corrects the LED names for the board).

 

In order to enable the higher clock rate, you'll also have to update the "sun50i-h5.dtsi" DT include.  I updated both this and the associated cooling-map in this patch:  https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/update-H5-board-config-support.patch (search for "sun50i-h5.dtsi" in this file).  You can extract just the patch for this file and ignore the other file patches I made.

 

Note that if you make these changes in your DT, then you'll also need to edit "/etc/default/cpufrequtils" on your Armbian board and change MAX_SPEED value to 1296000.  This way the board will run at a maximum of 1.3GHz via cpufrequtils.  With these changes thermal cooling works very well for me - the board auto-clocks down when it gets too hot, etc.

 

Unfortunately my Neo2's H5 is unstable at anything faster than 1.3GHz as the v1.1 regulator is restricted to 1.3v output maximum, so you can't overvolt.

 

I've been running my Neo2 using this for months using this configuration and it's been working great.  It's really a neat little board!

 

In any case, I hope this info might be useful - good luck!

[reverend_t]

Thanks very much for this, I will give it a go

[tkaiser]

On 7/4/2018 at 4:43 PM, 5kft said:

The challenge with the Neo2 is that there are two hardware versions, so by default Armbian can't enable the regulator that is present only in the new 1.1 version of the board.

 

Can you imagine sending a PR defining a new sun50i-h5-orangepi-zero-plus2-v1.1.dts so that we can add to the board's documentation that users of the v1.1 rev should simply add

fdtfile=sun50i-h5-orangepi-zero-plus2-v1.1.dtb

to /boot/armbianEnv.txt, adjust /etc/default/cpufrequtils, reboot and are done?

[5kft]

On 7/6/2018 at 5:02 AM, tkaiser said:

 

Can you imagine sending a PR defining a new sun50i-h5-orangepi-zero-plus2-v1.1.dts so that we can add to the board's documentation that users of the v1.1 rev should simply add

fdtfile=sun50i-h5-orangepi-zero-plus2-v1.1.dtb

to /boot/armbianEnv.txt, adjust /etc/default/cpufrequtils, reboot and are done?

 

Given the number of boards that can support higher CPU clocks (e.g., Nano Pi Neo 2, Plus2, Core2, OPi Zero Plus, OPi Zero Plus2 w/H/W MOSFET fix, etc.) it'd be great to be able to do this with overlays, rather than introduce a combinatorial explosion of board DTBs (i.e., per-board 1.1GHz max, 1.3GHz max, 1.4GHz max).

 

I have made some test override overlays to add the regulator and extend the CPU operating table (e.g., adding additional CPU core clock frequencies).  This works fine - one can just add the desired overlays in armbianEnv.txt and the new clock speeds appear and work:

	...
overlay_prefix=sun50i-h5
overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz
param_spidev_spi_bus=1
	...

However the problem is that one can't reliably run these boards at the higher clock rates without adjusting the thermal-zone cooling-map for the higher speeds.  Unfortunately device tree overlays don't appear to support thermal zones (at least I can't get them to compile with these present ).

 

I'm interested if anyone might have any ideas to to manage this.  Just brainstorming here, but perhaps we could make the default cooling-map for the H5 a bit more conservative, and then it could cover the introduction of the higher possible clock rates?  Or perhaps we could remove some slower entries from the H5 default clock operating table to allow for the addition of the optional higher clock rates (to better correspond to the default H5 cooling-map)?

 

Again, the nice thing about the overlay route is that we wouldn't have to change the 1.1GHz Armbian H5 default, so operation will be reliable.  But if users want to try speeding up their boards (whatever brand, VDD regulator, etc.), then they can just add an overlay or two and voila the higher speeds will be enabled.

 

[5kft]

@tkaiser, @Igor - I now have a working solution for this, and I'm interested in your thoughts regarding it.  If this makes sense, I'd like to add it to the Armbian mainline.

 

To explain the problem:  Many H5 boards have different hardware revisions where some have a 1.1v/1.3v regulator present (e.g., SY8113B, MP2143DJ), and others may not (or it may not be accessible because of a missing Q5 MOSFET ).  It would be nice for users to be able to enable this regulator if they can, and enable a higher maximum CPU clock rate when they enable the regulator.  This solution addresses this problem.

 

The problem with using optional DT overlays to add the higher clock rates is that it isn't currently possible to modify the corresponding thermal-zone entries in an overlay.  So instead in the optional overlay I override the last three clock entries from the default H5 CPU operating table to be higher.  This way the cooling-maps will still match the table.  Basically the "1.3GHz" overlay replaces the "1.05GHz" entry with the 1.1GHz clock definition, and the "1.1GHz" entry with the 1.2GHz clock definition, and the "1.152GHz" entry with the 1.296GHz clock definition.  Kind of "strange" I know, but it works 

 

I've tested all of this on an Orange Pi Zero Plus2 H5 (with Q5 MOSFET) using cpuburn-a53, and it properly clocks down from 1.3GHz as expected.

 

I've added a patch on my "h5-overclock-changes" branch that introduces these changes - see https://github.com/5kft/build/blob/h5-overclock-changes/patch/kernel/sunxi-next/sunxi-h5-add-gpio-regulator-overclock.patch.  This patch causes two new overlays to be created in the build: "sun50i-h5-gpio-regulator-1.3v.dtbo" and "sun50i-h5-cpu-clock-1.3GHz.dtbo".

 

The regulator overlay adds a "standard" GPIO-controlled 1.1v/1.3v regulator DT entry, controlled by GPIO PL6.  All the H5 boards I have (both NanoPi and Orange Pi) have this same sort of regulator on the same GPIO, however I'm not sure if this is the case for all H5 boards (?).

 

So, if a user would like to run their board at 1.3GHz, and they have a board with a regulator on GPIO PL6 that supports 1.3v (e.g., Nano Pi Neo2 v1.1, Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, Nano Pi Neo Plus2, etc.), then all they would have to do is this:

 

1.  Edit /boot/armbianEnv.txt, and add these lines:

overlay_prefix=sun50i-h5
overlays=cpu-clock-1.3GHz gpio-regulator-1.3v

 

2.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000:

# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
MIN_SPEED=408000
MAX_SPEED=1300000
GOVERNOR=ondemand

 

3.  Reboot the board

 

Following reboot, the board will then run in the cpufreq range of 408MHz to 1.296GHz.

 

Again, I would love to hear your thoughts regarding this solution.  Many thanks!

 

 

 

[tkaiser]

3 hours ago, 5kft said:

All the H5 boards I have (both NanoPi and Orange Pi) have this same sort of regulator on the same GPIO, however I'm not sure if this is the case for all H5 boards (?).

 

Historically the first H3 boards from Xunlong had an I2C accessible voltage regulator. Orange Pi One was the first with this primitive voltage regulation only switching between 1.1V and 1.3V. Allwinner's old H3 BSP contained code for I2C voltage regulators and the primitive mechanism with 1 pin (2 voltages) and 2 pins (4 voltages).

 

The first H5 board (Orange Pi PC2) also used the advanced I2C accessible SY8106A chip but voltage regulation support in Allwinner's H5 BSP was broken and a little later they also removed it from later H3 BSP variants. That's the reason why

• Orange Pi PC2 with Allwinner's BSP kernel (3.10.65) never was able to reach high clockspeeds
• NanoPi NEO2 did not implement voltage regulation at all in the beginning
• The Libre Computer Tritium boards do the same

FriendlyELEC could be convinced to give up on crappy Allwinner BSPs so they added voltage regulation to a later NEO2 revision, at the same time they redesigned other boards like NEO Plus2 (some Armbian devs have early revs without voltage regulation) or NanoPi M1 Plus2 (here they even use a SY8106A).

 

Back to your overlays: great work! Thanks.

 

If we find out that all affected boards use the same pin PL06 wouldn't it be nice to combine both overlays into one?

 

Which boards are affected? You listed 'Nano Pi Neo2 v1.1, Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, Nano Pi Neo Plus2' but AFAIK the latter shouldn't be on the list since the regulator stuff for this board can be part of the normal DT and doesn't need an overlay.

 

Then I've to admit that I'm not familiar with the way mainline implements throttling at all. Is the number of cooling-maps entries limited? When we started with our optimizations on A64 and H3 boards more than 2 years ago we added as much cpufreq/dvfs OPP and 'cooling-maps' nodes as possible since allowing cpufreq to avoid large jumps was key to success. When I first tested with the mainline implementation performance was significantly lower once throttling kicked in.

 

We found that providing 48 MHz steps especially in that thermal region where throttling will happen afterwards will provide overall higher performance compared to a setup where cpufreq always switches between a very low and a very high value instead of choosing the optimum in between. But I guess we're limited here, right?

 

Wrt the pin used. There's BPI M2+ H5 that uses PL01 with board revision 1.2 but fortunately we don't need to care about this board. And even if we had we could simply use a single DT for all board variants since this overheating fail used 1.3V on revision 1.1 (same hardware as BPi M2+ with H3 SoC)

[tkaiser]

AFAIK at least FriendlyELEC changed something on the boards to be able to distinguish between those board revisions with working voltage regulation and the older ones. They use a patched u-boot version where they implemented hardware detection and set DRAM clockspeeds based on this (at another location than standard u-boot).

 

So if the above changes work maybe in the future we could extend support also by automatically detecting hardware revision in u-boot and then load the specific DT overlay in question (disclaimer: both DT and u-boot noob speaking here  )

[Igor]

5 hours ago, 5kft said:

If this makes sense, I'd like to add it to the Armbian mainline.

 

Absolutely. Only let's start with this feature and testing at sunxi-4.18 branch. Already at this point.

[5kft]

Quote

The first H5 board (Orange Pi PC2) also used the advanced I2C accessible SY8106A chip but voltage regulation support in Allwinner's H5 BSP was broken and a little later they also removed it from later H3 BSP variants. That's the reason why

• Orange Pi PC2 with Allwinner's BSP kernel (3.10.65) never was able to reach high clockspeeds
• NanoPi NEO2 did not implement voltage regulation at all in the beginning
• The Libre Computer Tritium boards do the same

FriendlyELEC could be convinced to give up on crappy Allwinner BSPs so they added voltage regulation to a later NEO2 revision, at the same time they redesigned other boards like NEO Plus2 (some Armbian devs have early revs without voltage regulation) or NanoPi M1 Plus2 (here they even use a SY8106A).

 

This is the really frustrating thing - these are fundamentally very nice and capable boards, but the voltage regulation support is all inconsistent and/or messed up, and changes within a board family.  To your point I wish they all just standardized on the SY8106A from the start.  It does seem to be coming back with FriendlyELEC (e.g., the Neo Core2 uses this part as well). 

 

Quote

Back to your overlays: great work! Thanks.

 

Thank you very much!  

 

Quote

If we find out that all affected boards use the same pin PL06 wouldn't it be nice to combine both overlays into one?

 

I thought about this, but there are a few reasons that I split these, at least to start with:

 

It gives maximum flexibility to the user.  For example by default without the 1.3v regulator entry, then the Armbian default maximum clock will be 816MHz (limited to 1.1v).  By adding the 1.3v regulator overlay alone, then that will increase to run with the default Armbian opp table at 1.152GHz maximum, and will not "overclock" to a higher frequency.  This way it ensures maximum stability.

 

The, if a user wants to overclock to 1.3GHz, then they can just load the "enbale 1.3GHz" overlay.

 

Some boards already have a 1.3v regulator in the default DT, so there's no need to add another regulator entry via the overlay for this case.  E.g., for the Neo Plus2 (at least the current board revisions), as you note below, it has a MP2143DJ present, so this should be part of the default DT for the board - I actually have a change pending that I want to submit to add this.  (Now this may not really matter because if both regulator entries are present, the CPU assignment will only use one of them.)

 

The downside of this?  It's kind of confusing.  Will users understand this?  At this point I'm erring on the side of how Armbian users need to be a bit more technical, given the nature of the use of Armbian with all of these different types boards.  The nice thing about these overlays is that they are completely optional, and perhaps documentation can help prevent this from being too confusing?

 

Quote

Which boards are affected? You listed 'Nano Pi Neo2 v1.1, Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, Nano Pi Neo Plus2' but AFAIK the latter shouldn't be on the list since the regulator stuff for this board can be part of the normal DT and doesn't need an overlay.

Agreed (see note above).

 

Quote

Then I've to admit that I'm not familiar with the way mainline implements throttling at all. Is the number of cooling-maps entries limited?

 

This is a good question.  I'm not an expert in this area by any means (yet), but it seems rather limited (or "single-definition").  But I have to admit that I haven't dug in here very deeply.  The real problem is that at present "dtc" doesn't support thermal-zones at all in terms of DT overlays.
 

Quote

We found that providing 48 MHz steps especially in that thermal region where throttling will happen afterwards will provide overall higher performance compared to a setup where cpufreq always switches between a very low and a very high value instead of choosing the optimum in between. But I guess we're limited here, right?

 

I agree with your findings.  I've found that (relatively) small changes the upper region do help with cooling and maintain performance.  Dropping significantly really impacts performance.

 

Quote

Wrt the pin used. There's BPI M2+ H5 that uses PL01 with board revision 1.2 but fortunately we don't need to care about this board. And even if we had we could simply use a single DT for all board variants since this overheating fail used 1.3V on revision 1.1 (same hardware as BPi M2+ with H3 SoC)

 

OK, sounds good.  I was going to pull schematics and just double-check this to do an assessment; so far I've only looked at this in terms of the boards I have (several variants of NanoPi and Orange Pi).

 

Thanks for all of your feedback - it is very interesting and helpful!

 

[5kft]

8 hours ago, tkaiser said:

AFAIK at least FriendlyELEC changed something on the boards to be able to distinguish between those board revisions with working voltage regulation and the older ones. They use a patched u-boot version where they implemented hardware detection and set DRAM clockspeeds based on this (at another location than standard u-boot).

 

So if the above changes work maybe in the future we could extend support also by automatically detecting hardware revision in u-boot and then load the specific DT overlay in question (disclaimer: both DT and u-boot noob speaking here  )

 

Ah, this is very interesting!  Do you know which boards support this?  I'll have to add this to my "todo" list to research.  I agree that if we can detect this then we could very much automatically load the correct DT overlay for the board.  This would be great!

[5kft]

6 hours ago, Igor said:

Absolutely. Only let's start with this feature and testing at sunxi-4.18 branch. Already at this point.

 

OK, will do!  I actually have a number of other H5-related changes I'm going to be submitting, should I make all of these against the sunxi-4.18 branch?

 

(I'll cancel pull request #1046 and resubmit against the new branch as well after I test it.)

[tkaiser]

30 minutes ago, 5kft said:

I'll have to add this to my "todo" list to research.

 

Just had a quick look: https://github.com/friendlyarm/u-boot/commits/5532d5e641a990595156e83952049dd34cf838c0/common/board_r.c ?

[Igor]

46 minutes ago, 5kft said:

I actually have a number of other H5-related changes I'm going to be submitting, should I make all of these against the sunxi-4.18 branch?

Yes. sunxi-4.18 Allwinner (NEXT & DEV) part will replace the one in the master branch. ASAP. I already cleaned and ported all patches from 4.14.y. The only major known regression is no HDMI at A64 boards.

[5kft]

On 7/16/2018 at 7:54 AM, tkaiser said:

Just had a quick look: https://github.com/friendlyarm/u-boot/commits/5532d5e641a990595156e83952049dd34cf838c0/common/board_r.c ?

 

Ah - thank you for this pointer!  This is great, exactly what I need!  

[5kft]

@tkaiser, unfortunately I don't have a v1.0 NanoPi NEO2 to test against; I only have a v1.1 board.  Would you (or anyone else) happen to have a v1.0 version?  If so, could you do me a small favor and run these commands, and let me know the value printed by the "cat" command:

sudo su -
cd /sys/class/gpio
echo 355 >export
cd gpio355
echo in >direction
cat value

The value printed should be "1" for the v1.0 NanoPi NEO2.  (The value for my v1.1 NEO2 is "0", which is correct according to the schematics.)

 

Thanks!

[tkaiser]

4 hours ago, 5kft said:

I don't have a v1.0 NanoPi NEO2

Me neither. Maybe @guidol can help?

[Pat]

Hi, I own a NanoPI Neo2 v1.0. Let me know which OS image I have to install, and I'll run out these commands :)

May be only in further days, but I'd be happy to help.

Pat

[guidol]

6 hours ago, 5kft said:

@tkaiser, unfortunately I don't have a v1.0 NanoPi NEO2 to test against; I only have a v1.1 board.  Would you (or anyone else) happen to have a v1.0 version?  If so, could you do me a small favor and run these commands, and let me know the value printed by the "cat" command:

The value printed should be "1" for the v1.0 NanoPi NEO2.  (The value for my v1.1 NEO2 is "0", which is correct according to the schematics.)

Here the output from (one of) my v1.0:
 

root@nanopi-neo22(192.168.6.22):~# sudo su -
root@nanopi-neo22(192.168.6.22):~# cd /sys/class/gpio
root@nanopi-neo22(192.168.6.22):/sys/class/gpio# echo 355 >export
root@nanopi-neo22(192.168.6.22):/sys/class/gpio# cd gpio355
root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# echo in >direction
root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# cat value
1

Kernel:
Linux nanopi-neo22 4.17.7-sunxi64 #129 SMP Tue Jul 17 20:35:09 UTC 2018 aarch64 GNU/Linux

 

[5kft]

6 hours ago, guidol said:

Here the output from (one of) my v1.0:
 

root@nanopi-neo22(192.168.6.22):~# sudo su -
root@nanopi-neo22(192.168.6.22):~# cd /sys/class/gpio
root@nanopi-neo22(192.168.6.22):/sys/class/gpio# echo 355 >export
root@nanopi-neo22(192.168.6.22):/sys/class/gpio# cd gpio355
root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# echo in >direction
root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# cat value
1

Kernel:
Linux nanopi-neo22 4.17.7-sunxi64 #129 SMP Tue Jul 17 20:35:09 UTC 2018 aarch64 GNU/Linux

 

 

Many thanks @guidol, this very helpful!   Perhaps you (and @Pat?) could help me test my changes on your v1.0 board if/when I have the bootloader DT loader modifications working?  At this point I am thinking that this solution should be straightforward (e.g., similar to the bootloader changes I did for the NanoPi Fire3).  Thanks again!

[5kft]

6 hours ago, Pat said:

Hi, I own a NanoPI Neo2 v1.0. Let me know which OS image I have to install, and I'll run out these commands :)

May be only in further days, but I'd be happy to help.

Pat

 

Thanks @Pat!  I think I'm set at this point as @guidol was able to do the test.  But perhaps you could help test my bootloader changes after I implement them?  This will be off of the latest sunxi-next from the Armbian master branch.