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)

 

 

 

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?

 

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.

8 hours ago, sfx2000 said:

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

here you go: http://linux-sunxi.org/AR100

 

Still think the AR100 could be somehow interesting. 

 

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.

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

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

 

Edited September 30, 20188 yr by sfx2000
updating info

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

 

 

 

Ok... so some work here.... minor change was moving default cpu-gov from performance to ondemand - pulls down temps a bit, but perf is still within ranges....

 

http://ix.io/1nY2

 

 

Fun stuff.... bits in the crucible...

 

 

Try this 

This talks to AR100