<tkaiser>
With the usual fex settings developed last week this will to overvolting (close to 1.5V which exceeds the 1.4V max) as soon as cpufreq scaling exceeds the minimum 648MHz
<tkaiser>
I've been able to run ssvb's cpufreq-ljt-stress-test with 1200MHz at the 'lower' voltage and the test passed while running cpuburn-a7 on all cores in parallel. So this is a clear sign that this 'lower' voltage exceeds 1100mV massively and must be close to 1300mV
<tkaiser>
But when it's 1.27V in reality then it's like a fixed voltage since 1.5V should be avoided according to H3's user manual. And then max cpufreq should also be further decreased to get some security headroom.
<tkaiser>
s/security/safety/
<tkaiser>
If they would've used the SY8106A accessible through I2C like on any other H3 Orange Pi there would've been no need to change anything and the board would also run with lower consumption and stays cooler
JohnDoe4 has joined #linux-sunxi
<jelle>
ahh
huehner has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 268 seconds]
<ssvb>
tkaiser: you can try different test points with a multimeter on the Orange Pi One board to check what is the real VDD-CPUX voltage for both states of its voltage regulator
<tkaiser>
ssvb: Thx, unfortunately my Multimeter died
<tkaiser>
But the higher voltage must be _too_ high
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #linux-sunxi
<ssvb>
tkaiser: somebody with an alive multimeter and an Orange Pi One board could probably help us
HeHoPMaJIeH has quit [Read error: Connection reset by peer]
<tkaiser>
Yes
<ssvb>
is the Orange Pi One schematic already available?
pstef has quit [Ping timeout: 265 seconds]
<tkaiser>
Not that I know
<tkaiser>
Latest commit to their github repo: Apr 7, 2015.
<tkaiser>
And in the past Steven provided a link to the schematics weeks/months after board release.
<tkaiser>
And I still doubt that the Orange Pi PC schematic is correct. Seems like partially copy&paste from Orange Pi Plus
<KotCzarny>
maybe that's the way they produce new board ;)
<tkaiser>
ssvb: Do you have your OPi PC up and running?
<ssvb>
tkaiser: yes
<tkaiser>
Does /sys/class/thermal/thermal_zone1/temp looks reasonable?
<tkaiser>
Ok, you are running mainline...
<tkaiser>
My concern is kernel 3.4.x and thermal read-outs being too low
IgorPec has joined #linux-sunxi
<tkaiser>
Which might become dangerous in combination with VDD-CPUX being too high and thermal throttling jumping in too late
IgorPec has quit [Ping timeout: 250 seconds]
<ssvb>
tkaiser: btw, "1.3V is recommended even for 1008 MHz already" statement is not quite true
popolon has quit [Quit: WeeChat 1.3]
<ssvb>
using conventional math notation, "LV4: core vdd is 1.20v if cpu frequency is (816Mhz, 1008Mhz]" can be interpreted as 1008Mhz is included in the interval and 816Mhaz is not
<tkaiser>
LOL, the more I try the less I understand. I used 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' two times in each test setup.
<KotCzarny>
termal throttle?
<tkaiser>
1) with 2 'dvfs' entries on Orange Pi One. High temperatures and slow since throttling occures
<tkaiser>
2) with only lower voltage: Both runs identical, no throttling
<tkaiser>
3) the very same SD card inside an Orange Pi PC (adjusted script.bin) with identical heatsink
<tkaiser>
In case you want to use mainline kernel with Armbian there's another place to look
<topi`>
at least there is a Jessie image
<KotCzarny>
tkaiser, as for the temperature chart, remember the rule 'its not the clock, its the voltage applied' ?
<topi`>
I'll test it first with 3.4.x and then, if that works and the HW is OK, will dabble further to the mainline land
<topi`>
I just received 3 OPi PC's and 4 Camera modules, although I'm pretty sure I ordered just 3 camera modules... :)
<tkaiser>
KotCzarny: I know this. There's a Vcore chart but that's just the result of a function trying to calculate Vcore from cpufreq based on contents of script.bin
<topi`>
anyways, the price is kind of competitive for having 3x motion detecting cameras ;)
<tkaiser>
Since there's no way to read out the voltage on H3 since there's no PMIC
<tkaiser>
topi`: You should then apply the other fixes mentioned above. I integrated a patch for better camera quality and am not sure whether this is already included in the 1st test images
<ssvb>
tkaiser: you can read the SY8106A voltage settings over I2C
<topi`>
tkaiser: do I need the mainline kernel for the camera patches?
paulk-collins has joined #linux-sunxi
<tkaiser>
ssvb: I've been in Orange Pi One mode ;)
<tkaiser>
topi`: No, IIRC in mainline CSI support is still missing
<topi`>
ok, so 3.4.x is it
<tkaiser>
BTW: Camera with Armbian untested so far, I've been too busy with basic stuff. So it might be worth a try to use loboris' Ubuntu 15.04 Mate image in case you don't get it working
<tkaiser>
Feedback welcome
<topi`>
I presume there's no way to use systemd on Jessie without a new kernel?
<tkaiser>
Systemd is default
<topi`>
I remember trying to get systemd working on a 3.4.x kernel and it was fruitless
<tkaiser>
That's working
<KotCzarny>
systemd is evil
<KotCzarny>
just drop it
<apritzel>
3.4 is even more evil ;-)
<tkaiser>
ssvb: Thx for the reminder, I will implement I2C readout for the PC to check/verify whether my formula is working correctly :)
<topi`>
on a quad-core, and fast eMMC, you'll begin to appreciate systemd's advanced features like multi-threaded startup
<KotCzarny>
apritzel, not the 3.4, but blobs in 3.4 ;)
<topi`>
I have one quad-core i.MX6 board (hummingboard) and another hummingboard with the single-core SoM and the difference in boot time is day and night
<KotCzarny>
topi, and advanced features like braindead design and crappy coding
<wens>
morning
<topi`>
KotCzarny: well, these are the unfortunate side effects of modern day coding ;)
<topi`>
anyhow, upstart got its chance, but squandered it
<KotCzarny>
topi, nope, they are the poettering effect
<topi`>
but, as long as my board boots and my userspace shit works, I'm happy
<topi`>
KotCzarny: I agree with you, systemd's init process consumes disproportionate amounts of ram
maz_ is now known as maz
<topi`>
but it's kind of easy to forget nowadays when even cheap boards like OPi have 1GB of RAM
<KotCzarny>
topi, its not only that, its the twisting linux philosophy that apps should do one thing, but do it perfect
apritzel has quit [Ping timeout: 248 seconds]
<topi`>
KotCzarny: nah, that was in the 70s :) what's wrong with doing multiple things? python/twisted can do a thousand different network protocols/services and I think it's just all good
<KotCzarny>
topi, nothing, as long you do it good
<topi`>
I'd say having multiple shell commands communicate via pipes is just so old skool
<topi`>
but now I'll try to concentrate on getting my OPi PC to boot :) let's see how it goes... where is my damn 3.3V usb-uart cable???
<tkaiser>
ssvb: should 'i2cdetect -y 0' list the SY8106A?
avph has quit [Ping timeout: 268 seconds]
khuey is now known as khuey|away
avph has joined #linux-sunxi
avph has quit [Read error: Connection reset by peer]
nove has joined #linux-sunxi
sigjuice has quit [Ping timeout: 240 seconds]
MoeIcenowy_ has quit [Ping timeout: 240 seconds]
Tartarus has quit [Ping timeout: 240 seconds]
steev has quit [Read error: Connection reset by peer]
TheSeven has quit [Remote host closed the connection]
ninolein has quit [Quit: No Ping reply in 180 seconds.]
lynxis has quit [Remote host closed the connection]
xenoxaos has quit [Ping timeout: 240 seconds]
fl__0 has quit [Ping timeout: 240 seconds]
jukivil1 has quit [Ping timeout: 240 seconds]
afaerber has quit [Ping timeout: 240 seconds]
souther has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
sigjuice has joined #linux-sunxi
TheSeven has joined #linux-sunxi
avph has joined #linux-sunxi
MoeIcenowy has joined #linux-sunxi
afaerber has joined #linux-sunxi
fl_0 has joined #linux-sunxi
lynxis has joined #linux-sunxi
xenoxaos has joined #linux-sunxi
souther has joined #linux-sunxi
jukivili has joined #linux-sunxi
steev has joined #linux-sunxi
Tartarus has joined #linux-sunxi
khuey|away is now known as khuey
_massi has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
zerotri has quit [Ping timeout: 268 seconds]
zerotri has joined #linux-sunxi
reinforce has joined #linux-sunxi
alexst has joined #linux-sunxi
maz_ has joined #linux-sunxi
maz_ has quit [Remote host closed the connection]
maz has quit [Quit: Leaving]
maz has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 255 seconds]
KotCzarny has joined #linux-sunxi
kivutar has quit [Ping timeout: 265 seconds]
matthias_bgg has left #linux-sunxi ["Leaving"]
alexst has quit [Ping timeout: 250 seconds]
kivutar has joined #linux-sunxi
jstein has joined #linux-sunxi
alexst has joined #linux-sunxi
alexst_ has joined #linux-sunxi
alexst has quit [Ping timeout: 248 seconds]
Netlynx has quit [Quit: Leaving]
yann|work has quit [Ping timeout: 264 seconds]
reinforce has quit [Quit: Leaving.]
p1u3sch1 has quit [Ping timeout: 265 seconds]
p1u3sch1 has joined #linux-sunxi
<tkaiser>
Seems I got the origin for different thermal read-outs when using H3 with 3.4.x kernel. It's the u-boot version. When using 2011.09-rc1 the reported values look at least reasonable (20¡C above ambient when idle), when using 2016.1 they're off (below ambient temperature and so on)
<tkaiser>
I 'injected' ssvb's kernel 3.4.39 with yann|work's patches and the patches up to 3.4.110 into loboris' OS image.
<tkaiser>
Both kernels show identical read-outs when started by 2011.09-rc1. If I use 2016.1 with the 'Armbian' 3.4.110 kernel temperatures are way too low
<KotCzarny>
hoodedfigure: but you should be using lircd i think for ir
<hoodedfigure>
KotCzarny, thank you so much. I will check that links. Can you analyze with lirc?
<tkaiser>
Unfortunately the temperatures are also off at the upper spectrum.
<hoodedfigure>
KotCzarny, I mean like, read raw ir pulse data or so
<tkaiser>
Same board, same kernel, same settings, running cpuburn-a7 for a few minutes. 75¡C with the old u-boot, just 52¡C reported with mainline u-boot
<tkaiser>
And throttling starts around 80¡C when it's in reality maybe +100¡C :(
<ssvb>
tkaiser: keep in mind that the mainline kernel has no dvfs yet and runs the CPU at 1008MHz
<ssvb>
that's probably lower than what is used by the 3.4 kernel
<tkaiser>
Sure, but I'm talking about 3.4.x -- especially concerned about OpenELEC users since they also combine 3.4.39/3.4.110 with mainline u-boot
<tkaiser>
And they report pretty high temperatures all the time... that might be 20¡C higher in reality
<KotCzarny>
hoodedfigure: you want it to learn new remote or just apply ir diode to some experiment?
<ssvb>
ok, so the temperature sensor reading is way off?
<tkaiser>
Unfortunately true
<hoodedfigure>
KotCzarny, I want to map an old IR keyboard, gather a bit of metadata like key codes and so
vagrantc has joined #linux-sunxi
<tkaiser>
ssvb: A rather dumb workaround would be to adjust cooler_table and ths_para in this situation?
<KotCzarny>
hoodedfigure: lirc can do that, but last time i was teaching it new remote on banana pi m1, i had to play some tricks (driver only knew about nec protocol, but i got my remote working anyway)
<ssvb>
tkaiser: still we need to verify the temperature difference (with a thermocouple?) to confirm that it really exists
<tkaiser>
I put heatsinks on all my 3 H3 now ;)
<ssvb>
tkaiser: it might be possible that some clock is different between the mainline u-boot and the allwinner's bootloader
<hoodedfigure>
KotCzarny, thanks. Can you give me some hints to avoid those hickups you were having? (I'm a bit under pressure because it's a narrow scaled university project)
<hoodedfigure>
I pretty much have to get it working as fast as possible
<KotCzarny>
hoodedfigure: the last paragraph (but read the whole page first)
<tkaiser>
ssvb: ok
<hoodedfigure>
KotCzarny, are you the author of that wiki article?
<KotCzarny>
nope
<hoodedfigure>
KotCzarny, can I come back tomorrow to get some help if I get stuck?
<tkaiser>
In case your H3 has no heatsink applied and you're running 3.4.x -- based on my experience it's enough to put your thumb on the SoC for a rough estimate. When you do this and 32¡C become 27¡C then something's wrong
<KotCzarny>
hoodedfigure: sure, there are helpful people usually
<hoodedfigure>
KotCzarny, will you be here, too?
<KotCzarny>
who knows, i come and go (and my internet is crappy this week)
<hoodedfigure>
KotCzarny, okay then, thanks again and have a good evening (if you live in the evening region of our planet)
<KotCzarny>
but you should do fine, that lirc page is quite complete
<ssvb>
tkaiser: unfortunately I have a shortage of SD cards and don't have one with boot0 and a rootfs for Orange Pi PC at hand
<tkaiser>
ssvb: FEL boot to the rescue ;)
<ssvb>
yes, but this only works (properly) with the mainline u-boot
<hoodedfigure>
Good night, everyone
<tkaiser>
Ah, you want to compare yourself -- I understand
<tkaiser>
But with mainline u-boot it's easy in case you can then read out the thermal value
hoodedfigure has left #linux-sunxi ["Leaving"]
<ssvb>
yes, I still can check if the temperature sensor is providing meaningful values (something higher than ambient temperature)
<KotCzarny>
and use another sunxi device for a room thermometer
<ssvb>
yes, the temperature reads as 33C on an idle opipc and drops to 31C if I touch the SoC with a finger
tkaiser has joined #linux-sunxi
<tkaiser>
ssvb: Thx. And it should still feel warm (since it's more close to 45¡C)?
<ssvb>
tkaiser: a thermocouple reading is ~41C and is very slowly climbing up
<tkaiser>
The H3 OpenELEC folks adopted the new pmuic_type fex for the Orange Pi One with these two voltages pretty quickly
<ssvb>
the H3 temperature sensor shows 35C in the mean time
<tkaiser>
Combining a potential overvoltage situation with another situation where thermal throttling jumps in 20¡C too late isn't that good
<tkaiser>
How precise are these thermocouples?
<ssvb>
have no idea
<ssvb>
and I'm measuring it at the chip package surface, while the SoC sensor is supposed to measure it at the core
<KotCzarny>
and still, inside is colder ;)
<tkaiser>
True. And at unlike A20 where the thermal sensor was present more by accident than design it seems it has to serve in the H3 like in all newer SoCs
<ssvb>
I would not be very much worried about a measurement error in the ballpark of 5C or 10C
<tkaiser>
Me too
<ssvb>
we need to check how it behaves at higher temperatures
<tkaiser>
But at the upper limit being 20¡C off
<tkaiser>
Yes
<tkaiser>
I prepare some test setups with the 'old' u-boot where results might be calibrated enough
<tkaiser>
And then compare with mainline u-boot to get an idea how thermal graphs differ
<tkaiser>
Thinking about starting single threaded sysbench runs every 120 seconds to increase CPU utilisation to get two nice graphs
<tkaiser>
To be able to compare
<plaes>
montjoie: o/
<plaes>
montjoie: are you subscribed to linux-sunxi?
<ssvb>
tkaiser: and under cpuburn, the SoC sensor reads 65C and the thermocouple reads 61C
<ssvb>
maybe a more significant difference between the core temperature and the surface temperature is showing up
<tkaiser>
ssvb: Strange. I got 52¡C (mainline) vs. 75¡C (2011.09). Internal read-outs. No real measurement. Just 'it hurts' yesterday
<tkaiser>
There I used my thumb with high temperatures. Not with applied heatsinks not that easy. Sh*t, I should've ordered one more OPi One
<tkaiser>
Like I did with the PC for exactly this reason
yann|work has joined #linux-sunxi
<ssvb>
tkaiser: ok, I actually have a mostly useless sd card with pine64 android, now will try to use it to do opipc temperature measurements with boot0
<tkaiser>
Cool
<KotCzarny>
ssvb, make multiboot cards?
<tkaiser>
I schedule some thermal tests for tomorrow since now ambient temperature here would drop and might influence measurements (not significantly but IMO it's better to ensure identical boundary conditions)
mosterta has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
jelly-home is now known as jelly
<ssvb>
tkaiser: running tests with boot0 now
apritzel has joined #linux-sunxi
<tkaiser>
ssvb: :)
<ssvb>
tkaiser: cpuburn-a7 running at 1.3GHz shows 70C on the internal sensor and 63C on the thermocouple
<ssvb>
that's a bit higher
<ssvb>
now let me boot the mainline u-boot with 672MHz DRAM clock speed
<tkaiser>
ssvb: I had 75¡C at 25¡C ambient temperature. It climbs slowly and needs at least 10 minutes
<tkaiser>
At 1200 MHz (since loboris kernel didn't activate the 1296MHz operating point)
<tkaiser>
O, just realised that I need to do a test with mainline kernel on the Orange Pi One to see whether the lower or the higher Vcore voltage will then be used.
<tkaiser>
In case it's the latter this might be also somewhat risky even if dvfs isn't working yet?
mossroy has quit [Quit: Quitte]
WarheadsSE has quit [Quit: WeeChat 1.3]
<ssvb>
tkaiser: now this is weird, with the DRAM clock speed *up* to 672MHz in the mainline u-boot (and running same cpuburn-a7 at 1.3GHz), the SoC reported temperature is 61C and the thermocouple temperature is 60C
khuey|away is now known as khuey
<tkaiser>
Interesting. I had used 624 MHz... and can remember that it has been readjusted to 672 when thermal throttling occured. And then values were weird
<KotCzarny>
i wonder if it applies to the rest of h3 family (with mainline uboot and allwinner kernel)
<tkaiser>
KotCzarny: One of the 2 problems does.
<tkaiser>
If Xunlong releases Orange Pi Lite there are 7 H3 based Orange Pi variants available.
<tkaiser>
So it would make sense to create some sort of a metapage that collects everything that applies to all these devices
<KotCzarny>
they should just make this thing modular
<tkaiser>
And relink from the device pages but there's still too much specific to individual boards
<tkaiser>
The pages for Orange Pi Plus and especially 2 (Mini) are rather orphaned
yann|work has joined #linux-sunxi
<ssvb>
tkaiser: ok, after a few more tests I can confirm that the internal sensor reports ~61C at 672MHz DRAM and ~65C at 624MHz DRAM, and with boot0 I'm getting ~70C reported again
<tkaiser>
Weird!
<tkaiser>
The dependency on DRAM clock... WTF?
<ssvb>
the thermocouple reported 61C-63C for all these cases, and I believe that it is just the same temperature (maybe just measured at slightly different spots on the surface)
<tkaiser>
And in your case it's just 9¡C difference. I measured 23¡
alexst_ has quit [Quit: leaving]
<tkaiser>
Ok, the thermocouple result is important
<tkaiser>
Even if it's off
mosterta has quit [Ping timeout: 240 seconds]
<tkaiser>
Given thermal throttling starts doing its job at 80¡C Orange Pi One users with overvolted settings will get more in trouble when using mainline u-boot than boot0
<tkaiser>
Since temperatures might exceed 80¡C in reality and then thermal throttling starts too late.
<tkaiser>
(I would assume there's also some safety headroom left but...)
<ssvb>
well, considering that it's kind of illogical to expect higher temperature at lower DRAM clock speed, I would probably assume that the internal sensor might have some small systematic error depending on clock settings
<tkaiser>
ssvb: I just wanted to ask :)
<ssvb>
on my opipc board the measurement error does not seem to be significant enough to worry about it
<tkaiser>
Agreed
<tkaiser>
I'll double check tomorrow taking different DRAM clocks into account
<ssvb>
are you sure that you measured the 23C difference when using exactly the same script.bin and cpufreq settings?
<tkaiser>
Not now. But later. Fortunately this is stuff I put into monitoring. I fooled myself so often that this is now almost the 1st thing. Setting up basic monitoring.
bfree has quit [Remote host closed the connection]
khuey is now known as khuey|away
bfree has joined #linux-sunxi
WarheadsSE has joined #linux-sunxi
<tkaiser>
I get back to you tomorrow. Many thanks for testing this stuff!
ricardocrudo has quit [Remote host closed the connection]
tkaiser has quit [Ping timeout: 250 seconds]
clonak has quit [Ping timeout: 240 seconds]
clonak has joined #linux-sunxi
tkaiser has joined #linux-sunxi
clonak has quit [Excess Flood]
<tkaiser>
ssvb: One last question that puzzles me: With lima-memtester you're relying on mainline u-boot and 3.4.x. And then the spinning cube is displayed. Did you altered something regarding u-boot? Since with these Armbian H3 3.4.x images we get no HDMI output at all and it seems to be related to u-boot but I've no idea why
<ssvb>
tkaiser: why do you think it is related to u-boot?
cosm_ has quit [Ping timeout: 265 seconds]
<ssvb>
which kernel is used in Armbian H3 3.4.x images?
<tkaiser>
Since I put our 3.4.110 kernel on one of loboris' images (uboot 2011.9) and I got a display.
<tkaiser>
It's basically all yann|work put on top of your lima-memtester branch + patches to get from 3.4.39 to 3.4.110
FDCX has quit [Quit: Leaving]
<ssvb>
I guess, bisecting might help
<ssvb>
one of these extra patches might have broken hdmi
FDCX has joined #linux-sunxi
clonak has joined #linux-sunxi
<GeneralStupid>
is it worth trying the mainline kernel with my orange pi PCs? i have some USB issues
<tkaiser>
Hmm... ok, might be an idea. I'll remove all of them and try again. Thx again!
<tkaiser>
Hmm... but why does 3.4.110 work when I start it from u-boot 2011.9 and not when started out of mainline u-boot? Anyway I'll try first and ask later :)
doppo has quit [Ping timeout: 264 seconds]
naobsd has joined #linux-sunxi
<ssvb>
GeneralStupid: if it has all the features that you want, then why not?
doppo has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]