[linux-sunxi] Re: [PATCH] sunxi: lower the DRAM frequency of Nano Pi NEO2 to 504MHz

[Thomas Kaiser]

Am Donnerstag, 2. November 2017 14:59:57 UTC+1 schrieb Maxime Ripard:

> On Thu, Nov 02, 2017 at 11:36:52AM +0800, Icenowy Zheng wrote: 
> > The BSP of Nano Pi NEO2 provided by FriendlyARM uses 504MHz DRAM 
> > frequency, which is much lower than the current 672MHz used in 
> > mainline. 
> > 
> > Switch to use the BSP-provided frequency 504MHz for DRAM. 
> > 
> > Thanks to Thomas Kaiser, who pointed out the frequency problem. 
>
> What issue does this patch fix? BSPs have often been way underclocked 
> in the past. 
>
> Did you encounter any corruption? 
>

We had a couple of reports in Armbian forum about instabilities with NEO2 
that went away after downclocking the DRAM to 408 MHz (that's what Armbian 
uses currently on all Allwinner H thingies with just a single DRAM chip). 
FriendlyELEC started with 432 MHz on their single bank DRAM configurations 
last year and also lowered down to 408 MHz in the meantime.

But not where one would expect the change but somewhere else -- please see 
here: 
https://github.com/armbian/build/commit/b57c9d767ead528a54001d8728d39470e9faf5e4#commitcomment-23003991

I asked FriendlyELEC's Weidong right now to join the discussion providing 
some insights.

Best,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] sunxi: Tune H3 DRAM PLL to improve lock time

[Thomas Kaiser]

Jens Kuske wrote:

> The H3 PLL5 used for DRAM barely manages to lock to the required 
> frequency before DRAM controller starts, sometimes leading to wrong 
> delay-line calibration results. 
> This patch changes the PLL tuning parameters to the same values as 
> boot0 used, which speeds up the locking and fixes the problem.
>

Just FYI: I prepared an archive with u-boot packages (for Debian/Ubuntu 
based distros -- target audience are Armbian users) including your patch 
and covering 624-768 MHz DRAM clockspeed:

http://kaiser-edv.de/tmp/4U4tkD/linux-u-boot-sun8i-624-768.tar.bz2

Will now ask in Armbian forum for volunteers willing to test. 

Thx,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Forcing device mode on USB OTG, Pine64

[Thomas Kaiser]

Jon Smirl wrote:
>
> Is there some way to manually poke the kernel and force the port to 
> switch modes?
>

In case /sys/bus/platform/devices/sunxi_usb_udc/otg_role exists, setting it 
to 2 should switch to OTG role (assumption based on similarities in 
Allwinner's BSP legacy kernel for H3, A83T and A64)

Best regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Thomas Kaiser]

Hi,

Ondřej Jirman wrote:
>
> We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned 
> voltage regulation and every such board will need it's own set of 
> operating points. 
>

Yes, and Allwinner's current BSP kernel code might encourage board makers 
to implement a forth variant: switching between 4 different voltages 
through GPIOs.

Currently we have 4 boards that rely on the simple '2 voltage regulation' 
all using 1.1V/1.3V: Orange Pi One and Lite and NanoPi M1 and NEO. Then 
there are 2 devices with (legacy) Linux support existing that use no 
voltage regulation at all: Banana Pi M2+ (according to schematic using 1.2V 
but in reality it's 1.3V VDD_CPUX) and Beelink X2. And according to Tsvetan 
if/when Olimex will release their 2 H3 boards we have two more with fixed 
but yet unknown VDD_CPUX voltage (since olimex fears overheating maybe they 
use 1.1V or 1.2V limiting max cpufreq to 816 or 1008 MHz). And all the 
bigger H3 based Orange Pi use the SY8106A voltage regulator being able to 
adjust VDD_CPUX in steps of 20mV allowing VDD_CPUX to exceed 1200 MHz (a 
reasonable value seems to be 1296 MHz since above throttling will be an 
issue without active cooling)

Things get even worse since Xunlong uses copper layers inside the PCB to 
spread the heat away from H3 so Orange Pi One/Lite do not overheat that 
much like eg. NanoPi M1 (and maybe NEO -- can tell next week when I get dev 
samples to play with). So while eg. Orange Pi One and NanoPi M1 switch 
between the same voltages in the same way we (Armbian) found that we have 
to allow M1 to downclock to even 240 MHz since when testing with legacy 
kernel really heavy workloads led to throttling that low (even CPU cores 
were killed at this low clockspeed -- same applies to BPi M2+ and Beelink 
X2)

So i would second Ondřej's suggestions since when we're talking about H3 
devices we're not talking about tablet SoCs with accompanied PMU but 3 
classes of devices behaving totally different in regard to cpufreq limits 
and dvfs OPPs (and maybe someone is already developing a new H3 device 
adding a forth variant switching between 4 different VDD_CPUX voltages)

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: All Allwinner kernels rootable with an echo

[Thomas Kaiser]

Benjamin Henrion wrote:

> All Allwinner kernels rootable with an echo: 
>
>
> https://olimex.wordpress.com/2016/05/10/how-to-root-any-allwinner-device-running-android-and-most-of-the-chinese-pi-clones-which-bet-on-allwinner-android-linux-kernel/
>  
>
> Insane!
>

Wrong instead since it affects not *all* but only the new BSP kernel tree 
for sun8i (H3/A83T) released by Allwinner last year (and also the newer 
sun8i BSP variant released by FriendlyARM some weeks ago). Please read also 
ssvb's comment in Olimex' blog.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Pine64 unreview

[Thomas Kaiser]

Siarhei Siamashka wrote:
>
> Having too much poorly structured information and too many SD card 
> images to try actually does more harm than good.


Well, the unreviewer pointed out that he did what everyone would do: Go to 
the download section on wiki.pine64.org and choose the OS images _featured_ 
there. Longsleep's weren't mentioned until yesterday so only outdated and 
questionable images were present lacking even the minimum amount of 
documentation (eg. "This is WiP, HDMI is limited to 1080p60 at the moment")

Everything as expected given the current behaviour of the Pine64 folks that 
still do not *want* to provide appropriate documentation (listing all the 
known design flaws of their board) and raise surreal expectations. But 
maybe that's just how KS works and hardware guys can't do it better?

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] SinoVoip BPi M2+

[Thomas Kaiser]

Just a try to save others some time. SinoVoip sent me a developer/review 
sample yesterday and I did some testing.

Wiki stub: http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B

Since BPi M2+ is more or less a 99% clone of Orange Pi Plus/PC it was 
pretty easy to combine OPi PC/Plus stuff to a working .dts (everything 
tested except the stuff I'm not interested in: WiFi/BT). Fex, defconfig and 
a .dts available at the link above. Since they do not sent their camera 
module with the board I couldn't test this.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Allwinner dev board code names

[Thomas Kaiser]

Jon Smirl wrote:

> Pine 64 has an android/lichee Allwinner code drop from 1/13/16. 
> http://wiki.pine64.org/index.php/Pine_A64_Software_Release 
>
> Is these anything interesting in it? 
>

I don't think the Android image the Pine64 folks provide is based on this. 
They might get support from Allwinner but I don't know.

Looks likes there is only H3 support in their 3.4 kernel, not the 3.10 one. 
>

True. And this is the state of 'getting Android sources for 
H3': https://github.com/orangepi-xunlong/orangepi_android ;)

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Allwinner dev board code names

[Thomas Kaiser]

Jon Smirl wrote:
>
> I was looking for H3. 
>

What about dolphin then?

https://github.com/friendlyarm/h3_lichee/tree/master/tools/pack/chips/sun8iw7p1/configs

Thomas 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Is a somewhat maintained 3.4 kernel branch needed for Allwinner H3?

[Thomas Kaiser]

Siarhei Siamashka wrote:

So does anyone have any good ideas about how to move forward? 
> Or is anyone willing to step up as the 3.4 kernel maintainer for Allwinner 
> H3? 
>

Neither/nor. Just to save others some time. On top of your branch here and 
there a lot of additional patches were collected. 

The pretty active OpenELEC fork: 


https://github.com/jernejsk/OpenELEC-OPi2/tree/master/projects/H3/patches/linux

And Armbian relied on Yann Dirson's [1] commits so we've nearly the same 
patches in our repo but had to use a 'reverse' patch to get Ethernet 
working 
accross all H3 Orange Pis differently since Yann already applied a loboris 
patch:


https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default

BTW: The patches to bring Allwinner's 3.4.39 up to 3.4.110 should be able
to be applied to 3.4 kernels for A83T/H8 too (Cubietruck Plus, Banana Pi M3,
pcDuino8 Uno)

Regards,

Thomas

[1] https://github.com/O-Computers/linux-sunxi/commits/h3-wip

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: esata multiplier

[Thomas Kaiser]

Hi,

on the website http://linux-sunxi.org/SATA#Caveats there is stated "Cheap 
> port multipliers like JMB321/JMB393", Im just wondering what are the 
> good esata multiplier, could you please suggest some?
>

Nope, since using PMs with A20 is no good idea at all (low performance, 
risk that people try to replace backup with RAID, reliability problems when 
setting up 'el cheapo' RAID this way). You might find some informations in 
the thread referenced form the link above about other PMs that are known to 
work (and consume many times more than a typical A20 board)

Best,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: orangepi mirror

[Thomas Kaiser]

Benjamin Henrion wrote:

> The naming convention (OrangePi 2, Plus, Minus, etc...) is just a
> nightmare, especially to understand which image is compatible with
> which, considering that the SOC is the same for all.

And it won't get better with the new H3 based Orange Pi One/Lite ;)

But loboris' images do not differentiate between the different boards
at all. It's necessary to run update_kernel.sh that exchanges kernel
and script.bin (and for the latter you can decide from a few fixed
resolutions and whether you use a HDMI-DVI converter or not ‹ all this
stuff is defined in script.bin)

> I went through different states yesterday:
> 
> 1. Broken USB
> 2. Broken ethernet
> 3. Broken wifi support

Ethernet/USB should work after running update_kernel.sh and choosing
the correct board (if you're using a really old image from him there
might be a few manual steps necessary). Regarding Wi-Fi check whether
the necessary module is loaded and then execute:

sudo nmcli -a d wifi connect

See

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread=342

BTW: To use any display resolution (currently no EDID detection in the
H3 3.4 kernel) I relied on fbset in the past: Install the package,
define/choose a resolution in /etc/fb.modes and set this with fbset at
boot.

Regards,

Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: orangepi mirror

[Thomas Kaiser]

Benjamin Henrion wrote:

The few images I tested were full of bugs and needed a kernel update 
> to get latest Loboris.eu version.
>

Maybe it's a good idea to point out that while loboris' images/settings fix 
many things they're also responsible for worsening the overheating problems 
the H3 is blamed for. Please have a look at:

http://www.cnx-software.com/2015/09/01/getting-started-with-orange-pi-pc-pi-2-and-pi-plus-development-boards/#comment-521235

Maybe you can add this as a readme.txt?

Any idea if we might get a recent 4.4 kernel for the H3?


Work in progress. We also have a wiki: 
http://linux-sunxi.org/Orange_Pi_PC#Mainline_kernel

One Orange Pi PC is used here as NAS serving music since weeks with kernel 
4.4-rc-something.

Regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC

[Thomas Kaiser]

Siarhei Siamashka wrote:

> It's likely that the credit for "unlocking" the 1.5 GHz clock speed
> actually belongs to third-party modders.

Thanks for clarifying this (and all the additional informations). I'll
try to correct this where I spread wrong "informations"/assumptions
asapissimo.

> As there were no real objections, I have just pushed the Orange Pi PC
> fex file to the sunxi-boards repository. This makes it the first FEX
> file for the H3 SoC :-)

Great. Only one single question (I've overlooked before). Why

boot_clock = 1200

(especially since you wrote about SY8106A's default 1.2V voltage being
safe for operation at 1008 MHz)

Thx,

Thomas




-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Jpeg Encoding

[Thomas Kaiser]

Martin wrote:
>
> I know this is a quite old thread, but I would like to implement jpeg 
> thumbnail encoding in XMBC (since jpeg HW decoding is working now), but 
> gitorious has closed down and therefore the link 
> https://gitorious.org/recedro/jepoc 
> is no longer working. 
> Is this proof of concept for JPEG encoding on Allwinner A10/A20 anywhere 
> else available?
>

http://web.archive.org/web/20150101165922/https://gitorious.org/recedro/jepoc/source/78eb98d731467cef2804ba250c9fa5462240fed2

Regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Thomas Kaiser]

Siarhei Siamashka wrote:

> Unless we get more test results in a few days which radically change
> the statistics, probably using 624 MHz for DRAM on Orange Pi PC would
> be reasonable.

I second that while also asking the overclocker community for help:

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread=847
 

(but doubt that we get any useful feedback from there)

Regards,

Thomas




-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC

[Thomas Kaiser]

Siarhei Siamashka:

> Extracted from the Lubuntu_1404_For_OrangePiPC_v0_8_0_.img.xz image: 
>
> http://www.orangepi.org/downloadresources/orangepipc/oragepipc_4a0e8d960f7f0a52606dfaba58.html
>  
>
> Not necessarily the best one
>

This is the worst one since it's the origin of all thermal problems with 
Orange Pis and the result of product marketing: Advertising the H3 to be 
able to run at "up to 1.6Ghz". All Steven did was to increase clockspeeds 
and to adjust the Vcore voltage of the two available operting points in the 
dvs table he took from Draco by 200mV (to be able to reach the 
extremity_freq as scaling_max_freq).

And the result is that everyone using OS images for H3 based Orange Pi 
models has to suffer from heat/stability problems. When you replace this 
moronic dvfs table with something sane (a few more operating points and not 
only 2 already exceeding the recommended maximum values), you won't even 
need a heatsink:

http://linux-sunxi.org/User_talk:Tkaiser#Lessons_to_learn_from_Xunlong

With Xunlong's dvfs settings switching between 1.2 Ghz and 1.56 GHz *while 
being idle* the SoC's temperature increases by 12°C.

I don't know what I'm doing wrong but I can fire up cpuburn-a7 running on 
all 4 CPU cores at 1.2Ghz on my Orange Pi PC without thermal throttling, 
without CPU cores being dropped and also without heatsink/fan attached. Can 
please anyone explain to me what's wrong with my Orange Pi?

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Default cpufreq governor: performance vs. interactive/ondemand

[Thomas Kaiser]

Thomas Kaiser wrote:
>
> I have no multimeter that would be precise enough so I rely on the thermal 
> sensors in the 2 SoCs I used to show the difference the clockspeed makes 
> depending on dvfs settings. 


I bought a powermeter in the meantime and get a difference of ~250mW idle 
consumption on a Banana Pi M3 (A83T) when switching between interactive and 
performance (between 2.9/3W with interactive and 3.2W with performance) 
with the following settings:

scaling_max_freq: 180 (@1080 mV defined in dvfs table)
scaling_min_freq: 48 (@840 mV defined in dvfs table)

Then I defined dvfs settings where all cpufreq operating points share the 
same 1080mV and tested again. I couldn't measure a difference in 
consumption realiably but the SoC's internal sensor showed at least some 
differences. On the left Vcore set statically to 1080mV and on the right 
the very same test with dynamic voltage frequency scaling and voltage being 
adjusted between 840mV and 1080mV when walking through 
_scaling_available_frequencies_:

http://linux-sunxi.org/File:A83T_Vcore_static_vs_dvfs.png

I still believe that my consumption measurements are too unrealiable to 
draw any conclusions from. But in the meantime I believe there's some 
evidence that the whole discussion about power savings or waste of energy 
due to different cpufreq governors is totally useless if the dvfs settings 
aren't considered as well. Since based on my tests with A20, H3 and A83T 
the clockspeed alone wasn't that important regarding consumption and 
internal SoC temperatures. But the voltage was.

Therefore I find it a bit hard to draw _any_ conclusions from these two 
sets of practical tests that are referenced here since the used dvfs 
settings aren't mentioned (or I missed it):

http://linux-sunxi.org/Cpufreq#The_.22performance.22_governor

"The practical tests 
<https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00347.html> 
show 
<https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00678.html> that 
there is not much power consumption difference between idling at 60MHz and 
idling at 1008MHz (a ~1.5x difference on Cortex-A8, almost no difference on 
Cortex-A7)"

In my tests it made a huge or nearly no difference to switch between both 
governors -- based on the dvfs settings defined: the higher the voltage 
difference therein the more difference in consumption. While I still 
understand that a switch to performance seemed like a good idea two years 
ago when OS images with 60MHz _scaling_min_freq_ and fantasy or ondemand 
governor were used, I doubt it's the right approach when taking dvfs 
settings into account.

IMO a better approach is to choose interactive and adjust scaling_min_freq 
to the cpufreq with the lowest voltage defined in the dvfs table (or maybe 
one above). At least my tests made with the H3 recently showed nearly no 
difference whether the H3 idled at 240 or 720 MHz (both defined with the 
lowest voltage in the dvfs table) therefore I chose 720 as 
_scaling_min_freq_ and the system behaves as snappy as with performance:

http://linux-sunxi.org/File:H3_testing_cpufreq_limits.png

I can't test that with an A10 board since I don't own one. But might the 
test results from back then ("a ~1.5x difference on Cortex-A8, almost no 
difference on Cortex-A7") not be related more to dvfs settings than A8 vs. 
A7?

Thx,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Default cpufreq governor: performance vs. interactive/ondemand

[Thomas Kaiser]

Hello,

to justify the switch from interactive/ondemand to performance as default
cpufreq governor the following 2 year old sources are cited again and
again:

https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00492.html

https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00678.html
http://www.cubieforums.com/index.php/topic,1413.msg8745.html#msg8745


Unfortunately they miss the dvfs settings used ‹ it seems all cpufreq
operating points shared the same voltage.

Using recent Allwinner SoCs with 3.4 kernel and reasonable dvfs settings
(adjusting core voltage depending on CPU clockspeed) it's obvious that it
makes a difference at which clockspeed the CPU idles since different
voltages lead to different consumption levels.

I have no multimeter that would be precise enough so I rely on the thermal
sensors in the 2 SoCs I used to show the difference the clockspeed makes
depending on dvfs settings.

I let a script walk through scaling_available_frequencies while being idle
and monitored temperature and in A83T's case also Vcore voltage. The
conclusion is obvious: What happens when switching between performance and
interactive/performance depends largely on the *voltage settings* defined
in the dvfs table.

This is a H3 with 'sane' dvfs settings on the left side and the commonly
used overvolted/overclocked settings the Orange Pi manufacturer chose to
advertise the H3 as being a '1.6 Ghz SoC':

http://kaiser-edv.de/tmp/h3vOAh/H3.png (on the left adjusted/sane
settings, on the right after a reboot at 19:15 the overvolted/overclocked
'defaults' every OS image for H3 boards is using ‹ this is where the heat
problems origin from the H3 is blamed for)


With sane settings the difference in idle temperature is 3°C (41°C at 480
Mhz and 44°C at 1200 Mhz), with 'default settings' (only two operating
points defined at the upper limit), the difference is 6°C (45°C at 480 Mhz
and 51°C at 1536 Mhz). Both dvfs tables as reference below [1] [2]

Since the A83T is accompanied by a PMU (AXP813) it's possible to monitor
Vcore voltage through sysfs. Here the core voltage is adjusted between
820mV at 480 Mhz and 1080mV at 1800 Mhz [3] and this results in a
difference of 4°C when being idle:

http://kaiser-edv.de/tmp/h3vOAh/A83T.png

It's obvious that consumption (SoC temperature) depends more on core
voltage than clock speed and therefore the switch to performance as
default governor seems like a waste of energy. A more sane approach would
be to stay with ondemand/interactive and adjust scaling_min_freq to the
operating point with the lowest voltage defined in the dvfs table (since
then no further saving can be achieved when clocking lower).

While I understand that switching to performance seemed like a good idea 2
years ago (OS images with fantasy governor and scaling_min_freq at 60 Mhz
in the wild) I doubt that it's still right when keeping voltage settings
in the dvfs table in mind.

Best regards,

Thomas

[1] Overvolted/overclocked default dvfs settings Xunlong (Orange Pi
manufacturer) used to promote the H3 as being able to clock up to 1.6 Ghz:

extremity_freq = 153600

LV1_freq = 153600
LV1_volt = 1500
LV2_freq = 12
LV2_volt = 1300


[2] Attempt to define 'normal' dvfs settings for H3. Adjusting voltage
between 980mV at 480 Mhz and 1240mV at 1200 Mhz:

extremity_freq = 129600
max_freq = 12
min_freq = 48000
LV_count = 7
LV1_freq = 129600
LV1_volt = 1320
LV2_freq = 12
LV2_volt = 1240
LV3_freq = 110400
LV3_volt = 1180
LV4_freq = 100800
LV4_volt = 1140
LV5_freq = 96000
LV5_volt = 1080
LV6_freq = 81600
LV6_volt = 1020
LV7_freq = 48000
LV7_volt = 980


[3] A83T dvfs settings: 820mV at 480 Mhz and 1080mV at 1800 Mhz

[dvfs_table]
vf_table_count = 3

[vf_table0]
;little
L_max_freq = 201600
L_boot_freq = 18
L_min_freq = 48000

L_LV_count = 8

L_LV1_freq = 201600
L_LV1_volt = 1080

L_LV2_freq = 18
L_LV2_volt = 1000

L_LV3_freq = 160800
L_LV3_volt = 920

L_LV4_freq = 12
L_LV4_volt = 840

L_LV5_freq = 0
L_LV5_volt = 840

L_LV6_freq = 0
L_LV6_volt = 840

L_LV7_freq = 0
L_LV7_volt = 840

L_LV8_freq = 0
L_LV8_volt = 840

;big
B_max_freq = 201600
B_boot_freq = 18
B_min_freq = 48000

B_LV_count = 8

B_LV1_freq = 201600
B_LV1_volt = 1080

B_LV2_freq = 18
B_LV2_volt = 1000

B_LV3_freq = 160800
B_LV3_volt = 920

B_LV4_freq = 12
B_LV4_volt = 840

B_LV5_freq = 0
B_LV5_volt = 840

B_LV6_freq = 0
B_LV6_volt = 840

B_LV7_freq = 0
B_LV7_volt = 840

B_LV8_freq = 0
B_LV8_volt = 840

[vf_table1]
;little
L_max_freq = 201600
L_boot_freq = 18
L_min_freq = 48000

L_LV_count = 8

L_LV1_freq = 201600
L_LV1_volt = 1080

L_LV2_freq = 18
L_LV2_volt = 1000

L_LV3_freq = 160800
L_LV3_volt = 920

L_LV4_freq = 12
L_LV4_volt = 840

L_LV5_freq = 48000
L_LV5_volt = 820

L_LV6_freq = 0
L_LV6_volt = 820

L_LV7_freq = 0
L_LV7_volt = 820

L_LV8_freq = 0

[linux-sunxi] Re: [PATCH 3.4 1/9] sunxi: defconfig: Use performance cpufreq governor by default

[Thomas Kaiser]

m.silentcr...@gmail.com wrote:
>
> 1) If the performance governor is the default, it means that a lot of 
> boards will run constantly at overvolted out-of-spec settings by default. 
> Now, I haven't heard of any issues with boards running at 1.425 or 1.45 
> volts. Nevertheless, we don't allow that in mainline by default either, so 
> I don't think that change is consistant. With the ondemand governor, the 
> CPU may still use these dvfs settings, but at least it will clock down if 
> there's no load. 
>
> 2) If the ondemand governor behaves too sluggish on lower frequencies, I 
> think the logical solution would be to clean up those dvfs tables and 
> remove these very low frequencies rather than changing the governor so it 
> won't clock down anymore. Personally, I use 384MHz as minimum frequency on 
> my A20 boards, just to give one example. 
>
> 3) If the interactive governor performs better than ondemand, why not make 
> it the default? 
>

Totally agree with that. Regarding scaling_min_freq I think choosing a 
reasonable value depends solely on the dvfs settings in use. If lower 
clockspeeds doesn't differ that mutch in voltage then it makes nearly no 
difference whether the SoC idles at eg. 60 MHz or 720 MHz. I just ended up 
with the latter value for Orange Pi PC now. With interactive governor and 
720-1200 MHz the Orange Pi performs identical as with performance while 
Vcore being most of the times at 940mV instead of 1180mV:

http://linux-sunxi.org/File:H3_testing_cpufreq_limits.png
http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect=findpost=724=7213=29411

Regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Banana Pi M3 (A83T based) soon ready to donate

[Thomas Kaiser]

Luc Verhaegen wrote:

>Keep it

Nope, this device is completely useless (at least for me). I already
finished my "review" (a severe warning regarding the board's manufacturer
combined with a few technical details I was able to collect).

http://forum.armbian.com/index.php/topic/474-quick-review-of-banana-pi-m3/

I will keep it the next 2 weeks but then it's free for anyone working on
A83T. Just drop me a note. Preferably from within Europe due to shipping
costs.

But if I understand correctly, A83T is already gone and replaced by 'R58'
instead? http://www.allwinnertech.com/uploads/150529/7-1505291G22Y25.jpg

Anyway, @Vishnu, can you please comment on the question whether the A83T
contains a SGX544MP1 or MP2? According to the fex files used for the
BPi-M3 it should be 2 CPU cores.

Thx,

Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for the lamobo-r1 board

[Thomas Kaiser]

Hi,

Maxime Ripard wrote:

>Quite the opposite actually, it would allow people that want to
>deviate from the standard to do so while allowing people that
>want to follow that standard to do so as well.

Well, the majority of people that buy boards because of this specific
26/40 pin header can't do that. They expect that everything works as with
the Raspberry Pi (a few GPIOs here, I2C there and so on) and will simply
have to give up if they (or let's better say the distro they use) switched
to mainline kernel and nothing works any longer _as expected_.

These people don't know where device trees grow and also don't care. They
expect compatibility to a 'de facto' standard and the hardware vendors
producing boards with this specific 26/40 pin header try to be compliant
to that by modifying pin definitions in the OS images they provide or
recommend. So maybe it simply doesn't matter how this stuff is defined
since it gets patched back in in every 'distro' ready for the average user.

At least that's the case for the Lamobo R1 we're talking about. As said
before: No one will use that board without also applying the OpenWRT
patchset to be able to use the internal switch IC. So I doubt anybody will
use the .dts we're talking here about since the OS images people will use
already include their own:

http://linux-sunxi.org/Lamobo_R1#Images

Best regards,

Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] FYI: Wiki problems

[Thomas Kaiser]

Hi,

currently it's not possible to edit anything in the wiki. Authentication
problems due to "Warning: Unknown: write failed: No space left on device
(28) in Unknown on line 0"

Best regards,

Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Banana Pi M3 (A83T based) soon ready to donate

[Thomas Kaiser]

Hi,

anyone interested in one of SinoVoip's Banana Pi M3 to improve A83T
support?

I've been selected to receive a free sample by SinoVoip due to being their
most active forum member (a bit weird since most of the times I advise
there against choosing SinoVoip products due to worst software/support
possible :-) and still can't believe that instead of sending a contract
killer to my address they obviously shipped the board instead:

https://nolp.dhl.de/nextt-online-public/set_identcodes.do?idc=7214605425

I'll take some pictures for our wiki, fill in informations there, provide
a working Debian image and a set of tools to combine any rootfs with
bootloader/kernel (none of the few linux images SinoVoip provides for
download currently work since they're all corrupted... and they ship the
devices without eMMC being populated) and write a review of the board.
Will take approx. 2 weeks counting from the board's arrival ‹ see tracking
URL above if you apply.

Then I'm done with it and would love to send the board to someone else
working on A83T who has a better use for it than me (don't need it, A20
still the best due to SATA even if it's slow for unknown reasons :-)

Thx, Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Banana Pi M3 (A83T based) soon ready to donate

[Thomas Kaiser]

Luc Verhaegen wrote:

>Keep it, you're doing good work.

Thx, but I don't have any use for such a device (lacks I/O bandwidth
compared to processing power). The only thing I'm really curious about
A83T is the performance. Allwinner's weird press-release is still online:

http://www.allwinnertech.com/en/news/compnews/452.html

It can't be big.LITTLE, just little.LITTLE with 2 x A7 quad-core clusters
each. And I really doubt that the "around 2.0GHz" claim is true (TBC).

Anyway: Since some of us are working on A83T and I have no use for this
board after I'm done testing it, I still want to donate it. Preferably to
some of you devs that aren't focused solely on mainline since most of the
problems unfortunate BPi-M3 customers will run into might be solveable
easily by tweaking rotten 3.4.39 stuff (had a first look into it today ‹
woohoo!)

Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for the lamobo-r1 board

[Thomas Kaiser]

Hi,

Hans de Goede wrote:

> The Lamobo-R1 has a gpio header idententical to the one found
> on the Banana Pi, i2c2 is routed to pins there.

That's the reason this header exists in this form and that's the reason
customers buy these boards that expose an 'RPi compatible' 26/40 pin GPIO
header. That applies also to the various Orange Pi's and other
$insert-your-favourite-fruit-here Pi  with different SoCs, eg.
Roseapple/Lemon Pi with Actions Semi's S500. Even boards that do not share
the RPi's naming scheme feature this GPIO header, eg. LeMaker's Guitar or
ODROID C1/C1+

Users expect this GPIO header being 'RPi compatible' regarding
hardware-Addons (RPi HATs), software support (each of the above boards has a
ported WiringPi lib) and tutorials they find on the net. Breaking this
compatibility with mainline kernel is not a good idea IMO.

Best regards,

Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for the lamobo-r1 board

[Thomas Kaiser]

Hi,

Hans de Goede:

> The Lamobo-R1 has a gpio header idententical to the one found
> on the Banana Pi, i2c2 is routed to pins there.

One thing I forgot to mention before. Please have a look into our Wiki at
the second right picture:

http://linux-sunxi.org/Lamobo_R1#GPIO_header

The Add-On is an I2C extender produced by the board's manufacturer. And the
Add-On also works on RPi and nearly all other ARM boards featuring the 26/40
GPIO header since it's meant to work this way. Even boards with SoCs that
can't provide this compatibility (due to different GPIO voltage levels) will
be supplied with Add-Ons that make them compatible to this 'pseudo GPIO
standard':


http://www.mikronauts.com/hardkernel/hardkernel-odroid-xu4-shifter-shield-re
view/

BTW: In the R1's case it won't make any difference whether you configure
I2C/SPI away or not since the 'distros' that are used with this specific
board (containing also kernel patches to make use of the BroadCom switch IC
that will never be accepted upstream) already ship with a dts making GPIO
RPi compatible. And they will patch I2C and SPI back in if they're missing.
My words above apply more to all the other sunxi SBC that feature the same
26/40 GPIO header.

Thx, 

Thomas


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for the lamobo-r1 board

[Thomas Kaiser]

Hi,

Hans de Goede wrote:

> On 22-11-15 20:59, Maxime Ripard wrote: 
> >> + { 
> >> +cpu-supply = <_dcdc2>; 
> >> +operating-points = < 
> >> +/* kHz  uV */ 
> >> +96140 
> >> +912000140 
> >> +864000135 
> >> +72125 
> >> +528000115 
> >> +312000110 
> >> +144000105 
> >> +>; 
> > 
> > Why are you using a custom set of OPPs here, the default ones were 
> > unstable? 
>
> The fex file uses non standard OPPs
>

Which fex file? In case you're referring to an 'official' one please  
keep in mind how SinoVoip 'develops' stuff. By doing copy 
(remember the .dts for the Banana Pi M2?). Anyway, the fex files used 
by R1 users since a year contain comparable OPPs:

https://github.com/igorpecovnik/lib/blob/next/config/lamobo-r1.fex
https://github.com/Bananian/fex/blob/master/BPI-R1/script.fex

Stuff contained in official SinoVoip OS images can not be regarded 
safe or even tested since noone uses these OS images due to being 
broken more or less. And Lamobo R1 users that were relying on mainline 
kernel the last months already used a .dts sharing the default OPPs: 

https://github.com/igorpecovnik/lib/blob/next/patch/sun7i-a20-lamobo-r1.dts

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for the lamobo-r1 board

[Thomas Kaiser]

Stefan Monnier wrote:
>
> When I looked for a DTS file for this board, I was told that the 
> bananapi DTS works just fine


Nope, there are some differences already outlined in the wiki (eg. powering 
of a connected SATA disk is AXP209's job -- unless you pull pin PB3 the PMU 
won't supply the disk with power).

The device tree people use in the wild for over half a year with working 
SATA disk and switch can also be found in the 
wiki: http://linux-sunxi.org/Lamobo_R1#Mainline_kernel

Unless the patches there for the switch won't also be applied networking is 
pretty useless. And the R1 still suffers from lousy GMAC throughput 
compared to other A20 devices (maybe a driver issue).

Regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Allwinner pack tools adventures

[Thomas Kaiser]

Ivan Kozic wrote:

> I didn't know if anyone would complain about it being not so structured, 
> as I've never updated any public wiki pages
>

You could start summarizing/editing the stuff below 
http://linux-sunxi.org/index.php?title=User_talk:Ikozic=edit=1 
as long as it's early "work in progress" and then move it to where it 
belongs to if you feel you might want feedback/corrections from others.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Banana pi BPI-M2 uboot 2015-7 and kernel 4.1.6 test

[Thomas Kaiser]

lion wang wrote:

 BPI team have test linux kernel 4.1.6 on BPI-M1,BPI-M1+,BPI-M2,BPI-M3


Where's the M3 stuff?

And I would assume the only bit of interest inside your forked kernel is 
one single file (since everything else already worked before and you didn't 
change a single line of code). The device tree definition for the M2 (that 
not you developed but a community member instead):

https://github.com/BPI-SINOVOIP/BPI-Mainline-kernel/blob/master/arch/arm/boot/dts/sun6i-a31s-bananapi-m2.dts

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Thomas Kaiser]

Hi,

Timo wrote:

 I think what Maxime was trying to say is, that while all of your boards 
 support Cpufreq, only the Cubietruck supports voltage scaling because only 
 Cubietruck has the power regulator nodes defined in it's dts file (just 
 have a look at the last lines of the Cubitruck dts file and compare that to 
 the dts file, let's say, for Bananapi). On the other boards, the frequency 
 is scaled, but the voltage always stays at 1.4V as set in U-Boot (that 
 means the voltages in the cpufreq operating points are not used on these 
 boards). At least that's what I understand after a recent email axchange 
 with Chen-Yu Tsai. 


Ah, now I think I understand. You're talking about these lines here?


https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269

So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support 
to the cubietruck, shouldn't adding these lines to the device trees of the 
other 5 A20 devices enable CPU voltage scaling there?

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Thomas Kaiser]

Leonardo Canducci wrote:

 I've submitted a bug [0] in the Debian BTS and tried kernel 4.0 and 4.1 
 from unstable and experimental branches with no success


I can confirm that it's neither working with 4.0.4 and 4.1 on cubietruck 
(always tried Wheezy):


http://forum.armbian.com/index.php/topic/108-no-cpufreq-support-in-cubietruck-debian-39-wheezy-405/#entry764

With the very same kernel/userland (kernel exactly identical) cpufreq stuff 
works on the other A20 devices I tested with: A20-Lime2, Banana Pi, Banana 
Pro, pcDuino3 Nano, Lamobo R1

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Thomas Kaiser]

Hi,

Hans de Goede wrote:

 Is the debian kernel building the axp209 mfd driver, and also 
 the axp20x regulator drive, and do these get loaded properly on the 
 cubietruck ? 


Unfortunately I've no idea since i fetch the kernel sources directly from 
git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

And this was the kernel config I used: 
https://github.com/igorpecovnik/lib/blob/429867a80c85011b6d31048481c0beb1c7bc76fa/config/linux-sunxi-next.config

What puzzles me is that exactly the same kernel (I used Igor Pečovnik's 
build system) provides working cpufreq support on 5 A20 devices and one it 
fails. 

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Thomas Kaiser]

Hi,

Maxime Ripard wrote:

 So any mechanical change is not something that can be done. Especially 
 for something that might blow up your board. 


Thanks for the warning. I already started to prepare to blow away the 
Lamobo R1 I've here by applying the cubietruck device tree settings (for 
this board there's only a reverse engineered power scheme available that 
looks good to my. But actually I've no idea what I'm doing :-)

Now with CONFIG_REGULATOR_AXP20X=y everything's fine on cubietruck. Thanks 
for providing both the solution and the comprehensive interrelationship 
between here and there (and of course for all the good work you all provide)

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Thomas Kaiser]

Hi,

Maxime Ripard wrote:

 On Fri, Jul 24, 2015 at 04:36:57AM -0700, Thomas Kaiser wrote: 

  And this was the kernel config I used: 
  
 https://github.com/igorpecovnik/lib/blob/429867a80c85011b6d31048481c0beb1c7bc76fa/config/linux-sunxi-next.config
  

 # CONFIG_REGULATOR_AXP20X is not set 


Thanks. Will give it a try with CONFIG_REGULATOR_AXP20X=y ASAP.
 

  What puzzles me is that exactly the same kernel (I used Igor Pečovnik's 
  build system) provides working cpufreq support on 5 A20 devices and one 
 it 
  fails. 

 And none of those 5 use CPU voltage scaling. 


Maybe I don't understand the whole meaning. But on a Banana Pi a few weeks 
ago [1] and on a pcDuino3 Nano I used the last days for USB/UAS benchmarks 
the cpufreq stuff was available below /sys/devices/system/cpu/cpu0/cpufreq/ 
and altering parameters always had an effect. But I will follow your 
advise, double check and report back.

Thx, Thomas


[1] http://www.lemaker.org/forum.php?mod=viewthreadtid=15543

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Banana Pi M2 (A31s based) ready to donate

[Thomas Kaiser]

In the meantime someone reverse engineered some stuff for the M2 and saud 
to send patches upstream:

http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested#2747

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Banana Pi M2 (A31s based) ready to donate

[Thomas Kaiser]

And in the meantime somewhere on baidu.com Sinovoip put their Android 
sources (using kernel 3.3) for the M2 
online: https://github.com/BPI-SINOVOIP/BPI-Kernel4.0/issues/1

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Adding upstream u-boot/kernel support for Lamobo R1?

[Thomas Kaiser]

Hi,

I added the ressources I use with the Lamobo R1 to its wiki 
page: http://linux-sunxi.org/Lamobo_R1#Mainline_U-Boot

Both defconfig/dts file work like a charm after several issues have been 
discovered and resolved:

- SATA power definition was missing in manufacturer's fex file: 
SATAPWR=SUNXI_GPB(3)
- CONFIG_GMAC_TX_DELAY=4
- Added SATA power definition in device tree

I used the board with both Kernel 3.4.106 and 3.19/4.0.4 for several weeks 
without issues (besides poor GMAC performance maybe related to b53 driver 
problems). 

What's missing to get it supported upstream?

Regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [RFC] A2x touchpad temperature readout

[Thomas Kaiser]

Hi,

schroete wrote on 18. Juni 2015 18:02:44 UTC+2:

 just seen that Hans did a temperature readout in sunxi-next in the 
 sun4i-ts module. 


If this is responsible for the value reported by 
/sys/devices/virtual/thermal/thermal_zone0/temp then the output seems to be 
wrong.

Steps to reproduce:

- ensure that the A20 board is idle and query 
/sys/devices/virtual/thermal/thermal_zone0/temp (will show you something 
below 37°C)
- press your thumb on the A20 while running and check again

Expected result: temperature 
https://www.dict.cc/englisch-deutsch/temperature.html exchange 
https://www.dict.cc/englisch-deutsch/exchange.html between thumb and SoC: 
If the SoC's temperature is below 37°C it should increase, if it's above it 
will decrease. What happens with kernel 4.0 or above: the temperature 
reported by thermal_zone0/temp will further decrease below 30° which seems 
to be impossible. Unfortunetaly I cannot provide patches but just report 
that there's something going wrong.

When I do a 'stress -t 900 -c 2 -m 2 -i 2' on an A20 board with kernel 
4.0.4 then temperature doesn't exceed 42.5°C (very unrealistic) when doing 
the same with kernel 3.4.107 and the sunxi-dbgreg module approach ('echo 
'f1c25004:90'  /sys/devices/virtual/misc/sunxi-dbgreg/rw/write;') 
temperatures reported rise above 50°.

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Banana Pi M2 (A31s based) ready to donate

[Thomas Kaiser]

Anyone interested in a chinese A31s SBC called Banana Pi M2?

The board works, UART is accessible but the software the vendor provides 
(and his attitude) really suck: 
http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/895-status-quo-of-m2-regarding-software-support#2538

If any of the A31/A31s developers is interested I could donate this piece 
of hardware (preferably in Germany/Europe -- shipping costs)

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Banana Pi M2 (A31s based) ready to donate

[Thomas Kaiser]

Hi,

Hans de Goede wrote:

 On 18-06-15 08:53, Thomas Kaiser wrote: 
  Anyone interested in a chinese A31s SBC called Banana Pi M2? 

 I'm interested, so that I can add upstream u-boot and kernel (dts file) 
 support for it. If you're ok with donating it to me let know and I'll 
 send you a private mail with my address (I'm in the Netherlands so 
 shipping should be ok).


Glad to hear that. Please send me address as well as the preferred shipping 
method based on your experiences (never sent anything to Netherlands before)
 

  The board works, UART is accessible but the software the vendor provides 
  (and his attitude) really suck: 
  
 http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/895-status-quo-of-m2-regarding-software-support#2538
  
 http://www.google.com/url?q=http%3A%2F%2Fwww.bananapi.com%2Findex.php%2Fforum%2Fgeneral-discussion-for-bpi-m2%2F895-status-quo-of-m2-regarding-software-support%232538sa=Dsntz=1usg=AFQjCNGMIaXb1jI1u8hf7KgGq7RMjx21zg
  

 I feel I have to respond to this, I agree that bananapi.com is not 
 a good community player and the BPI boards they sell are best avoided (*).


Yes, it seems they don't understand that it also helps themselves if they 
would contribute to the community. If they would just publish the fex file 
they used for their 3.3 based images I could add the necessary AP6218 stuff 
to the dts file I recreated from the dtb file they supply with their 
4.0.0-rc5 based images (http://pastebin.com/GzHMW31m ) and I could use the 
board with mainline utilizing both GBit Ethernet as well as Wi-Fi. But they 
refuse to provide this stuff.

Regarding the M2 as a reference. I put some stuff online -- maybe it is of 
help to you or others working on the M2 or A31/A31s in general:

- stuff from their Raspbian 2.0 image (kernel 3.3.0, u-boot 
2011.09-rc1-dirty): http://kaiser-edv.de/tmp/OYrTyl/
- console output from this Raspbian image: http://pastebin.com/bXtb1buf
- console output from their 'Bananian' rip-off (same settings as before but 
also display initialisation f*cked up): http://pastebin.com/MJSVSfBc
- console output from their Google Rpitc Image for M2 (u-boot 2015.04-rc4 
and kernel 4.0.0-rc2): http://pastebin.com/8uyu9hN6 
 

 However it is important to not mixup these bananapi people with the 
 original bananapi people from lemaker.org and the original bananapi 
 and bananapro boards. The people from lemaker.org are nice friendly 
 people who do work together with the linux-sunxi community, unlike 
 the people from bananapi.com.


Yes, I totally agree. But unfortunately the LeMaker guys seem to focus on a 
different set of SBCs now (2 based on Actions Semi's SoCs and one on i.MX6 
-- they published these images yesterday accidentally on their forum they 
messed up the last days totally: http://kaiser-edv.de/tmp/Wxnnxw/) so we'll 
have to see what that means regarding the Alwinner SBCs they supported in 
the past.
 
Regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: GMAC Reveice Clock Delay Chain value

[Thomas . Kaiser]

m.silentcr...@gmail.com wrote: 
 Sound interesting. How did your test runs work out?

I found a couple of settings for the Lamobo R1 that might work slightly better 
than the default 3/0 TX/RX delay settings. But on Banana Pi and Olimex Lime2 
the defaults (3/0 and 0/0) provided the best results.

Since I'm still not knowing what I'm doing or whether my modifications to try 
to write to the right 3 bits and make this register accessible using 
CONFIG_GMAC_RX_DELAY do really work (I'm no coder) I simply gave up and skip 
Cubietruck and pcDuino3 Nano that I would've run through the same series of 
tests otherwise.

Regards,

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Banana R1 router german article

[Thomas . Kaiser]

Small follow-up: I'm refering to GMAC send/receive clock delay chain. For 
Banana Pi/Pro it was necessary to set bit 10-12 of the gmac clk register to 3 
to get decent network throughput (for Cubietruck it's set to 1 currently). 

http://lists.denx.de/pipermail/u-boot/2014-September/190239.html

This is done in u-boot:

http://lists.denx.de/pipermail/u-boot/2015-January/202590.html

Since this is a very board specific value to compensate for trace lengths on 
the PCB (see explanation above) I had doubts that using also 3 on the Lamobo R1 
(which has a totally different PCB and uses a different PHY than Banana Pi/Pro) 
would make any sense. Igor tried a few other values (2,4,5,6,7,9,12) and came 
up with 4 giving better results. So now he sets CONFIG_GMAC_TX_DELAY=4

https://github.com/igorpecovnik/lib/blob/next/patch/add-lamobo-r1-uboot.patch

If I have the time I will set up an unattended test setup and brute-force 
through all possible values of CONFIG_GMAC_TX_DELAY and also 
CONFIG_GMAC_RX_DELAY (why shouldn't the other direction not also be affected? 
This is what we have right now with all A20 boards: asymmetric throughput).

With mainline kernel and adjusted SMP, network and cpufreq settings (also due 
to patched U-boot) I managed to get 940 Mbits/sec RX and 670 Mbits/sec TX: 
http://forum.lemaker.org/thread-12167-1-1-nas_performance_with_kernel_3_19_0.html

This is what I want to achieve on the Lamobo R1 as well and try to reach 940 
Mbits/sec TX on Banana Pi/Pro. But no idea whether the idea to set 
CONFIG_GMAC_RX_DELAY will work since code for this value in board/sunxi/gmac.c 
seems to be missing (and unfortunately I'm no coder)

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Banana R1 router german article

[Thomas . Kaiser]

Benjamin Henrion wrote:
 http://www.pc-magazin.de/ratgeber/banana-pi-r1-router-anleitung-openwrt-bananian-3021511.html
 
 Anyone has ever tested this router? I heard they had problems to make
 the BCM switch working properly.

I have it here and Igor Pečovnik already added support for Mainline with recent 
u-boot in his Debian build system (he also adjusted GMAC send/receive clock 
adjustments in u-boot because right now the network throughput between SoC and 
BCM switch that acts as PHY is pretty slow):

http://www.igorpecovnik.com/2014/09/07/banana-pi-debian-sd-image/
https://github.com/igorpecovnik/lib/tree/next/patch

The BCM is also working with sunxi 3.4.x.

When I still have the board next weekend (dedicated to a customer's project) 
I'll dig deeper into the network problem. Right now with Igor's u-boot 
adjustments we only get 350 Mbits/sec.

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH][RFC] Add standalone driver for the A20 Soc TP embedded temperature sensor

[Thomas . Kaiser]

thomas.kai...@phg-online.de wrote:
 In the meantime I realized that it's bit 7 of the touchpanel's TP_CTRL1 
 register so when sunxi-dbgreg.ko is loaded I should succeed with
 
 echo 'f1c25004'  /sys/devices/virtual/misc/sunxi-dbgreg/rw/read;
 
 Corentin's code in this module as well as the sunxi-dbgreg-workaround I use 
 set bit 4 to 1 but leave bit 7 untouched.

Just realized my mistake. The method I used (writing \x10 to TP_CTRL1 using 
sunxi-dbgreg.ko) led to bit 7 being cleared and therefore setting CHOP_TEMP_EN 
from enable to disable. Restoring the default by writing \x90 to TP_CTRL1 gives 
temperature readouts way closer to reality. If CHOP_TEMP_EN is disabled the 
temperatures reported show in some situations a rather large offset to the 
actual temperatures in one or the other direction. If  CHOP_TEMP_EN is enabled 
the deviation is much smaller.

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH][RFC] Add standalone driver for the A20 Soc TP embedded temperature sensor

[Thomas . Kaiser]

clabbe.montjoie wrote:
 For the temperature value, I cannot found any document on how to transform 
 the raw value in °C.
 [...]
 Under heavy loads, the temperature of both sensors rise linearly.

But based on a series of tests with and without heatsinks applied to the A20 I 
came to the conclusion that the values reported here must be already 
pre-calibrated. The base idle temperatures reported without an applied heatsink 
are way higher compared to the value of the very same A20 with heatsink:

http://forum.lemaker.org/forum.php?mod=redirectgoto=findpostptid=8137pid=40817

Does anyone have a clue how the A20's CHOP_TEMP_EN register (according to the 
A20's user manual: Chop temperature calibration enable: 0: Disable, 1: 
Enable) can be read/set?

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.