Jump to content

Allwinner H3 NanoPiNEO - hi temps on mainline vs. vendor build


sfx2000

Recommended Posts

Checking in...

 

NanoPi-NEO v.1.31 with the OLED hat... need to be a bit specific as there are multiple HW revs of the NEO - v1.2 and later moved from LDO to a DC/DC regulator, so info from 1.0/1.1 might not be accurate these days - still sorting out the regulator in use, as there are a couple of options with Allwinner H3 there. I think it's the SY8113B, but hard to tell...

 

Testing with Armbian 5.61 vs. FriendlyArm's 4.14.52 build for their OLED hat (I'd source a direct link, but they have two source - baidu and google drive) -- The friendlyarm image is pretty good with temps on the 4.14.52 kernel, typically around 31-33c idle, and I've not seen temps above 46c under load.

 

the friendly arm image - the Clocks are pretty conservative - max cpu is 1.0GHz... I'm assuming that mem is at 432 defaults from allwinner bsp

 

tinymembench...

 

          standard memcpy                                      :    448.1 MB/s (2.9%)

          standard memset                                      :   1448.4 MB/s (2.5%)

 

(note - the NEO is well heat-sinked with the provided hs, and it's in a metal closure - it's the cute little item from friendlyarm... so one has the plate HS and the housing)

 

cube.jpg.09364471c70d8e28c9b9bef1185eec35.jpg

 

 

My concern - armbian 5.61 ubuntu idles at 42c in the same scenario... it's the 10 degree difference that's interesting in idle state.

 

subjectively - one can feel the housing warmer with the armbian 5.61 image running - but subjective results are never good...

 

Looking into this, not sure which numbers to trust there - did friendlyarm pull in the dvfs changes? are they levering into the AR100 system manager block?

 

Comment - as soon as one gets into AR100 - it's a blackbox blob - so some concerns there obviously as it's a system manager as such, perhaps better than superuser privs

 

I'm assuming that current Allwinner armbian mainline pulls in the linux upstream here so some of the dvfs items haven't been pushed and accepted there.

 

thoughts?

 

Link to comment
Share on other sites

8 hours ago, sfx2000 said:

Looking into this, not sure which numbers to trust there - did friendlyarm pull in the dvfs changes? are they levering into the AR100 system manager block?

 

Temp diff can be explained with using proper regulator bits ... but since there seem to be many different board revisions, it's a mess. This would be the first case, that some other kernel runs cooler than Armbian :) And it can also be false readings. Did you measure temps?

 

DVFS is n/a in upstream 4.14.y kernel. FA took https://github.com/megous/linux/tree/orange-pi-4.14 as a base ... where DVFS is already implemented. They only added their board's settings and some board recognition to that fork. If boards heat powered down, there is not AR100 involved.

Link to comment
Share on other sites

12 hours ago, Igor said:

DVFS is n/a in upstream 4.14.y kernel. FA took https://github.com/megous/linux/tree/orange-pi-4.14 as a base ... where DVFS is already implemented. They only added their board's settings and some board recognition to that fork. If boards heat powered down, there is not AR100 involved.

 

Confirmed that AR100 is not involved with the FA Ubuntu 16.04 image, so that's solved...

 

The FA image borrows a lot from the community at large - they do include all their add-ons to support the boards and hats - GPIO is incorrect as it tries to ID the board as an M1, not NEO, but there's a guy over in Japan that has a fix to sort that out.

 

It does run better than the old Allwinner BSP, but they know that the GPU/VPU isn't fully baked yet, so if that's important, either the AW BSP or something else might be the right path until the bootlin stuff gets fully mainlined...

 

Going to give another stab at 5.6, will try the Bionic release, rather than stretch which I tried a bit earlier.

Link to comment
Share on other sites

12 hours ago, chwe said:

Still think the AR100 could be somehow interesting. 

 

Kind of reminds me of the Intel System Management Engine - the AR100 block has direct access to memory outside of the ARM's, Mali, and Cedrus - could be a security concern...

 

and the firmware blob from AW is a closed binary (some folks have decompiled it)

 

Anyways - did some spelunking around the webs, and found this...

 

https://github.com/allwinner-zh/linux-3.4-sunxi/tree/master/drivers/arisc

 

I don't think mainline includes this, as there are other ways to do that functionality - some of the Orange PI images do it include it (remember the Orange Pi Zero overheating issue, where ARISC would spam the logs if the right image wasn't used).

Link to comment
Share on other sites

13 hours ago, Igor said:

Temp diff can be explained with using proper regulator bits ... but since there seem to be many different board revisions, it's a mess. This would be the first case, that some other kernel runs cooler than Armbian :) And it can also be false readings. Did you measure temps?

 

So I bumped the clocks to 1.2GHz, and it still runs fairly cool - putting a bit of stress on it (unixbench -c 4 - it's not CPU burn, I know, but it's still a sustained load over a lot of different mixes of instructions)

 

Temps hit a high of 64C, which is pretty good all things considered - credit to FA for including a good heatsink there...

 

I'll give @tkaiser excellent bench script a try in a bit... but I'm thinking nothing exceptional, as he's tested the board extensively...

 

Screen Shot 2018-09-30 at 2.22.04 PM.png

Edited by sfx2000
updating info
Link to comment
Share on other sites

Ok -- bit of work, as my stash of recent SD cards ended up being a rather bad batch (I order them in bulk, and they're branded, and a trusted reseller, and still get a bad batch from time to time...)

 

 

 

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