deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
ricardocrudo has joined #cubieboard
mherweg1 has quit [Ping timeout: 250 seconds]
anunnaki has joined #cubieboard
anunnaki has quit [Client Quit]
anunnaki has joined #cubieboard
zenojis has quit [Ping timeout: 240 seconds]
zenojis has joined #cubieboard
TheSeven has quit [Ping timeout: 245 seconds]
TheSeven has joined #cubieboard
ricardocrudo has quit [Remote host closed the connection]
t3st3r has quit [Remote host closed the connection]
hramrach has quit [Write error: Broken pipe]
tomboy64 has quit [Write error: Connection reset by peer]
tomboy64 has joined #cubieboard
hramrach has joined #cubieboard
bizarro_1 has quit [Quit: Leaving]
DV has quit [Ping timeout: 252 seconds]
t3st3r has joined #cubieboard
syeekick has quit [Ping timeout: 264 seconds]
syeekick has joined #cubieboard
DV has joined #cubieboard
JohnDoe_71Rus has joined #cubieboard
deffrag has joined #cubieboard
Al_Cho has quit [Remote host closed the connection]
DV has quit [Ping timeout: 276 seconds]
DV has joined #cubieboard
DV has quit [Ping timeout: 245 seconds]
shineworld has joined #cubieboard
DV has joined #cubieboard
DV has quit [Ping timeout: 276 seconds]
_massi_ has joined #cubieboard
DV has joined #cubieboard
<shineworld>
looking at script.fex of A10 vs A20, for Android, I've found a lot of differences (is ok) but one is very interesting: [disp_init].disp_mode from 0 "screen0(screen0, fb0)" to 4 "clone(screen0, screen1, fb0) (2 screens, one standard framebuffer)"
<shineworld>
Truly I don't know what is the right value to use with Android 4.2.2......
<JohnDoe_71Rus>
shineworld: hi
<shineworld>
Hi JohnDoe_71Rus
<JohnDoe_71Rus>
i test only hdmi + cvbs and clone don't work for me
<shineworld>
... I'm trying to figure out WHY changing display from HDMI to LCD and moving resolution to 800x480 the system have so much exceptions with sistemui
<shineworld>
in my test with HDMI and 4 (default from cubieboard team) all works fine
<shineworld>
but moving to LCD with reduced display size the system have a lot of issues
<shineworld>
I've got script.bin values from 1.05 img file
<shineworld>
JohnDoe_71Rus, can you share your adb logcat (I need to see some initialization logs error)
syeekick has quit [Remote host closed the connection]
sassmann has joined #cubieboard
fossxplorer has joined #cubieboard
<JohnDoe_71Rus>
shineworld: don't remember
shineworld has quit [Read error: Connection reset by peer]
shineworld has joined #cubieboard
<shineworld>
JohnDoe_71Rus, I've got values from A20 tablet of my daughter (missed that she have one allwinner powered)
<shineworld>
PS: looking in sources there are some missing pars on script.bin
<JohnDoe_71Rus>
i use script.bin from cubietech sdk 1.05
<shineworld>
for example in [disp_init] is missing fb0_width & fb0_height which cause a premature stop in settings recovering
<shineworld>
this is very strange .... but is it
<shineworld>
there is also lcd_max_bright & lcd_min_bright which isn't used at all in sources
<shineworld>
.... and so on....
deasy has joined #cubieboard
tat__ has quit [Read error: Connection reset by peer]
tat has joined #cubieboard
maribu has joined #cubieboard
<maribu>
Hi, there! Has anyone problems with the cubietruck randomly turning off during operation?
<maribu>
Mine worked fine for a couple of month now, but started to do this a few day ago and intervalls are becoming shorter
<maribu>
Just tody it happend again. When I rebooted it (had to press the power-button on the cubietruck) it crashed when starting X.
<maribu>
I rebooted 4 times and every time the cubietruck turned of when starting X. On the 5th try starting X worked (I'm currently using my cubietruck)
<maribu>
I first thought it might be the power supply and used instead of the 1.2A power supply a 2.0A supply instead, but this didn't help
<maribu>
Theres only one usb-device directly connected to my cubietruck: A powered usb hub. The sata-hdd also is externally powered. So the power supply only needs to power the cubietruck. I'm right now using the 1.2A power supply again (as the 2.0A supply didn't made a change). But I guess 1.2A should be more than needed, shouldn't it?
<maribu>
Is overheating possible in a 20°C room? My cubietruck only has the passive cooler and is placed in the standard case. Nothing is standing near the case, which could prevent air circulation.
<sbx320>
overheating shouldn't be an issue
<sbx320>
my cubietruck is running in a drawer without any air circulation 24/7 for several months now and it's barely warmer than when I operated it outside
<sbx320>
I'd try putting some generic cpu & gpu load onto the device to ensure it's not some issue with X etc.
tat_ has joined #cubieboard
tat has quit [Ping timeout: 252 seconds]
<maribu>
Thanks, sbx320. I am using the fbturbo driver for X, but I'm haven't run any OpenGLES code at all. The fbturbo driver provides some 2d acceleration, so surfing the web and scrolling should provide both CPU and GPU usage (only 2d, of course), but this does not seem to result in crashes
tat_ has quit [Remote host closed the connection]
<maribu>
I have done this all the time, but my cubietruck started to turn of randomly only a few days ago
<maribu>
I'm also using CedarX with libvdpau-sunxi and mplayer all the time. But right not my cubietruck didn't turn off when using mplayer so far
<maribu>
Also I haven't done any kernel, X.org oder fbturbo update recently
<maribu>
I have updated mesa, but I don't think that mesa interacts with the GPU at all
<maribu>
Maybe I should try blacklisting mali kernel modules, as I'm not using OpenGLES I wouldn't miss them at all
maribu has quit [Remote host closed the connection]
maribu has joined #cubieboard
<maribu>
Looks like blacklisting mali and mali_drm does not work using /etc/modprobe.d. The fbturbo X.org driver might load them manually ignoring my blacklist :-(
<maribu>
At least this time my cubietruckt started at the first try :-)
<maribu>
Looks fine so far. I'll try disconnecting hdd and usb-hub in 2h
<maribu>
Thanks!
Midnightmyth has quit [Read error: Connection reset by peer]
Freyr has quit [Read error: Connection reset by peer]
Freyr has joined #cubieboard
fossxplorer has quit [Remote host closed the connection]
fossxplorer has joined #cubieboard
popolon has joined #cubieboard
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
popolon has joined #cubieboard
popolon has quit [Changing host]
JohnDoe_71Rus has joined #cubieboard
mherweg has joined #cubieboard
deffrag_ has joined #cubieboard
deffrag has quit [Ping timeout: 252 seconds]
bizarro_1 has joined #cubieboard
jluisn has joined #cubieboard
DV__ has joined #cubieboard
lauri has quit [Ping timeout: 276 seconds]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<ssvb>
maribu: are you back?
<maribu>
Hi, ssvb! Yes, I am. Turned out my script.bin is actually quite up to date.
<maribu>
The minor voltage adjustion in the patch you mentioned before are already part of my script.bin
<ssvb>
ok, you could try to increase the dcdc3 voltage a little bit more, but your symptoms are a bit strange
<ssvb>
typically the board freezes on a failure, but if I understand it correctly, yours just powers down?
<maribu>
Correct
<maribu>
I'm now compiling a new kernel from github.com/linux-sunxi/linux-sunxi
<ssvb>
another thing to check is the FAST_MBUS setting in u-boot
<ssvb>
are you familiar with compiling/upgrading u-boot?
<maribu>
Yes, I am. I'm currently using a u-boot compiled my self as I had trouble to get my cubietruck booting with the one in the binary package in my distro
<maribu>
I might just give the current binary package a try
<maribu>
Ok, I have installed the offical u-boot from my distro. I'm rebooting now and hopefully be back online in a minute ;-)
maribu has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
maribu has joined #cubieboard
<maribu>
booting with my distros u-boot now works fine. But shutting off my cubietruck with lime-memtester still works reliable :-(
<maribu>
The package also updated my script.bin, so I'll double check the voltage values again
<ssvb>
'normal' MBUS speed is 300MHz, and 'fast' MBUS is 400MHz
<maribu>
mbus_clk is 300. So this is not the problem
<ssvb>
maribu: yes, in any case it looks like your problems are not related to misconfigured DRAM, because what you have now is very failsafe and conservative
<maribu>
I'll give the official kernel from my distro a try
Scolytus has joined #cubieboard
<ssvb>
maribu: btw, what is the CPU clock speed?
<ssvb>
maribu: that's another possible source of failures if it is overclocked
<maribu>
1008MHz as max clock. I'll try what happens when I limit it to 720Mhz
inkwizytor has joined #cubieboard
<maribu>
Oh, it is actually limited to 912MHz. With installing the patched u-boot package I also have overwritten my script.bin
<ssvb>
maribu: hmm :) and if I remember correctly, it got somewhat more stable as a result, right?
qermit has quit [Ping timeout: 245 seconds]
<ssvb>
maribu: the lima-memtester failures could be possibly explained by the fact that CPU + Mali consumes more power than the CPU alone
<ssvb>
maribu: this can make your PSU the primary potential culprit again
<ssvb>
maribu: are you sure that your hdd is really using the external power? is it an external 5.25" usb hdd or something?
nighty-_ has joined #cubieboard
<maribu>
the power plug of the hdd is connected to the power supply of an sata-to-usb adapter, but the data plug is connected to the sata plug of the cubietruck directy
<maribu>
actually I would think that the system has become more stable with running at 912MHz. It still crashes immedeatly after running lima-memtester. I'll try the new kernel now with cpu limit to 720MHz