<t3st3r>
i.e. lower frequency can run under lower voltage but if you're about to raise freq, voltage should be uplifted as well to ensure stable operation. I can see some AXP driver arrived but it looks simple and I fail to see where this part hidden?
<t3st3r>
ahh so vanilla 3.17 will be unable to scale freq at all?
<ssvb>
it just runs at the highest clock speed
<t3st3r>
(and get CPU quite hot)
<ssvb>
same as having 'performance' cpufreq governor
<ssvb>
power consumption is not constant and depends on the CPU usage and the type of workload
<ssvb>
idling at the highest clock speed does not heat up the CPU much
<t3st3r>
Well, it heats up far more than it would if it would be downclocked and voltage reduced.
<t3st3r>
so most of time I would prefer something like "interactive" unless I need rock solid performance.
<ssvb>
how much more?
<ssvb>
got the numbers?
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
<ssvb>
power consumption is very easy to measure with the cheap 'charger doctor' or similar devices
<ssvb>
'far more' is a very vague statement
<t3st3r>
ssvb> got the numbers? <- haven't measured exactly but I can feel difference by just touching CPU.
<ssvb>
slightly warm in both cases?
<t3st3r>
and IIRC in idle state on low ferquency like 60MHz and minimal voltage it supposed to be rather cold.
<t3st3r>
after all CMOS consumption is proportional to frequency, voltage and number of gates switching.
<ssvb>
do you want to reduce the electricity bill?
<t3st3r>
well, I've been just curious if it makes sense to try 3.17 to give it a try but it looks like if power management would be broken beyound ways I'm going to consider.
<ssvb>
at 60MHz the system is very laggy because it fails to increase the clock frequency fast enough
<t3st3r>
I basically do not want system to be warm or use extra power when not needed, that's just wrong.
<ssvb>
having bad performance is even worse, unless you are running on the battery power
<ssvb>
of course you are free to stay away from the mainline kernel, the choice is up to you
<t3st3r>
At 1st glance I do not notice big difference. And most of time it runs as non-interactive networked device. Maybe it makes sense if you care about desktop, etc
<ssvb>
so typing in the ssh shell at 60MHz is not laggy as hell for you?
<t3st3r>
Also what is common way to spin up something like own Ubuntu? I've thought about using Linaro root file system but it seems to be BACKDOORED O_O
<t3st3r>
ssvb> so typing in the ssh shell at 60MHz is not laggy as hell for you? <- not really, and using vnc seems to ramp up CPU. Yet it is possible to ramp up CPU to smth a bit higher if it annoying.
<ssvb>
your experience seems to be very different from what the other people have observed
Akagi201 has quit []
<ssvb>
is it really idling at 60MHz? what kind of device is that?
<ssvb>
for example, cubieboard/cubietruck configure the lowest clock frequency for cpufreq as 720MHz
<t3st3r>
well, not really sure how to see freq during ssh login without chance to influence it?
<t3st3r>
60 MHz is pretty low so almost anything tends to cause upclock.
<ssvb>
try to run "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq"
<t3st3r>
I'm using USB connection which passes "ethernet" to PC, hopefully its okay.
WarheadsSE has quit [Ping timeout: 244 seconds]
<ssvb>
you can also try "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" and check if you see any differences
<ssvb>
basically, at the maximum clock speed, the experience working in a text editor in the console is about as good as on the PC
<ssvb>
with the ondemand or interactive governors and idling at 60MHz it is rather uncomfortable
<ssvb>
but, of course, your perception of what is slow and what is fast may be rather different
<t3st3r>
interesting... attempt to use ssh seems to quickly ramp up to 960 (maximum which is indefinitely stable on this board with usb) and unwilling to go down at all :)
WarheadsSE has joined #linux-sunxi
<t3st3r>
if I set minimum to 300, it would actually jump between 300 and 960 during ssh session.
<t3st3r>
and even if I provoke such "oscillation", using editor seems to be okay (in mcedit) and not like if I can easily distinguish it from local mc.
popolon has quit [Quit: WeeChat 1.0.1]
pwhalen has quit [Ping timeout: 272 seconds]
xeros has quit [Ping timeout: 272 seconds]
WarheadsSE has quit [Ping timeout: 244 seconds]
pwhalen has joined #linux-sunxi
zumbi has quit [Ping timeout: 245 seconds]
zumbi has joined #linux-sunxi
xeros has joined #linux-sunxi
naobsd has quit [Quit: Page closed]
WarheadsSE has joined #linux-sunxi
zumbi has quit [Ping timeout: 245 seconds]
zumbi has joined #linux-sunxi
hipboi has joined #linux-sunxi
petr has quit [Ping timeout: 244 seconds]
hipboi has quit [Ping timeout: 245 seconds]
petr has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
hipboi has joined #linux-sunxi
akaizen has joined #linux-sunxi
viccuad has quit [Read error: Connection reset by peer]
Skaag has joined #linux-sunxi
wenbin has joined #linux-sunxi
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
naobsd has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
amitk has joined #linux-sunxi
pwhalen has quit [Ping timeout: 260 seconds]
pwhalen has joined #linux-sunxi
Zboonet has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Read error: No route to host]
akaizen has joined #linux-sunxi
scream_ has joined #linux-sunxi
naobsd has quit [Ping timeout: 246 seconds]
Wes-_ has quit [Read error: Connection reset by peer]
Wes- has joined #linux-sunxi
amitk_ has joined #linux-sunxi
amitk has quit [Ping timeout: 272 seconds]
<mripard>
ssvb: afaik, wens is the only one who worked on it, and some time ago
<wens>
:|
philippe_fouquet has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 260 seconds]
naobsd has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 258 seconds]
akaizen has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Andy-D has joined #linux-sunxi
rafaelMOD has quit [Quit: Leaving]
orly_owl has quit [Ping timeout: 246 seconds]
orly_owl has joined #linux-sunxi
sehraf has joined #linux-sunxi
gzamboni2805 has joined #linux-sunxi
gzamboni2805 has quit [Client Quit]
gzamboni123 has joined #linux-sunxi
gzamboni123 has quit [Client Quit]
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
<mripard>
wens: thanks for your mail, somehow I missed that page ;)
<mnemoc>
moin
arend has joined #linux-sunxi
rz2k_ has quit [Remote host closed the connection]
bertrik has joined #linux-sunxi
<rellla>
mnemoc: hi. are you doing the git pushes by hand or by cronjob?
<hramrach_>
ssvb: yes, I did fel boot and then used otg networking on a13 tablet and needed that patch otherwise networking would not come u[
<ssvb>
hramrach_: ok, thanks
<ssvb>
hramrach_: this all seems to be rather buggy on a20
<hramrach_>
yes, seems so
Andy-D has quit [Ping timeout: 245 seconds]
Andy-D has joined #linux-sunxi
FR^2 has joined #linux-sunxi
rz2k_ has joined #linux-sunxi
megal0maniac has quit [Ping timeout: 272 seconds]
megal0maniac has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
megal0maniac has quit [Ping timeout: 272 seconds]
<ssvb>
wens: do you have easy access to BOOT_SEL pins on your A31 board?
<ssvb>
wens: the A31 manual does not seem to document the VER_REG anymore in the SYSTEM CONTROL section
<ssvb>
wens: but at least the A20 document explained that the bit 8 there is the status of UBOOT_SEL pin (FEL button)
<ssvb>
wens: and we can read VER_REG in the FEL mode as "./fel read 0x1C00024 4 ver_reg"
megal0maniac has joined #linux-sunxi
<ssvb>
appears that on my A31s based MSI Primo81 tablet, the VOL+ button is directly connected to the UBOOT_SEL pin
akaizen has joined #linux-sunxi
<ssvb>
when the button is pressed, the VER_REG reads as 0x30, while normally it reads as 0x70 (which would mean that the status of UBOOT_SEL is now moved to bit 10)
<ssvb>
just not in the user manuals from Allwinner
<ssvb>
still I wonder, how comes that my A31s tablet is trying to boot from the SD card with the BOOT_SEL bits set to 0b11? is the SD card boot somehow chained from boot0/boot1?
wenbin has quit [Quit: Leaving]
castor3 has quit [Ping timeout: 272 seconds]
castor3 has joined #linux-sunxi
Net147 has joined #linux-sunxi
tgaz has quit [Ping timeout: 245 seconds]
<wens>
mripard: it wasn't published in my cover letter
tgaz has joined #linux-sunxi
<wens>
ssvb: afaik, boot1 is _smart_, it checks for a valid boot0 signature on mmc, and if found, sets some magic value and reboots
<wens>
brom/boot0 finds that value, and boots from mmc
<ssvb>
wens: ok, but then I wonder why DRAM does not seem to be initialized in this case?
<wens>
it reboots, so you have to do everything again?
<ssvb>
wingrime: high DRAM clock speed is not very useful unless MBUS is also clocked high
xavia has joined #linux-sunxi
<wingrime>
Hm, uboot change it too?
<ssvb>
wingrime: yes, using '.mbus_clock' in 'dram_para'
<ssvb>
wingrime: and high MBUS clock speed needs high dcdc3 voltage
<wingrime>
Hm, so, anyone saw 700 mhz dram ?
<wingrime>
Workable...
<ssvb>
I have not tried anything higher than 648MHz, because that would be more than the DDR3-1333 chips are supposed to handle :)
<ssvb>
wingrime: anyway, even 600MHz was not really reliable on your board
<wingrime>
Wait a80, thats will be more interesting to play
<ssvb>
that's another story, a80 has a different dram controller
rafaelMOD has joined #linux-sunxi
<ssvb>
wingrime: please remember that "being just able to boot the system and idle it for a while" != "run the system reliable on all realistic workloads with decent uptime" :)
<wingrime>
Indeed
<wingrime>
Thats all in terms off probability
<ssvb>
I would actually suggest you to try downclocking dram until the lima-memtester program stops failing
<ssvb>
first go to 576MHz and if this does not help, try 552MHz next
<mnemoc>
rellla: is it misbehaving or missing something?
<ssvb>
wingrime: you can also try increasing dcdc3 voltage in fex, this improves reliability