kuldeepdhaka_ has quit [Ping timeout: 272 seconds]
kuldeepdhaka_ has joined #linux-sunxi
<kivutar>
hi, I would like to compile linux-sunxi 20140116-mali-r3p2-01rel2 from ssvb with builtin mali (not module), but when I do, I get duplicates definitions of functions
<ssvb>
kivutar: yes, currently it only works when built as a module
<kivutar>
ssvb, ok, is it normal that I have to disable CONFIG_MODVERSIONS to be able to modprobe it without -f ?
<ssvb>
modprobe should work just fine
<kivutar>
well, I get a no symbol version for module_layout
<kivutar>
I heard it is due to a missing Modules.symvers
<ssvb>
how do you build and install your kernel and modules?
<ssvb>
it is very likely that you are doing something wrong
<kivutar>
ssvb, well, this page also says branch sunxi-3.4 and not stage/sunxi-.34
<ssvb>
yes
<kivutar>
so, what branch is the good one then?
<ssvb>
'sunxi-3.4' is the stable branch, 'stage/sunxi-3.4' contains the latest fixes and will be promoted to stable eventually
<ssvb>
depends on your definition of 'good' :)
<kivutar>
I see :)
<kivutar>
and none of these contains r3p2 I suppose?
<kivutar>
oh, the wiki says it contains it, nice
<ssvb>
where?
<kivutar>
The userspace mali drivers must be updated to r3p2. This is automatically handled by the mali drivers at https://github.com/linux-sunxi/sunxi-mali.git after updating the submodules.
<kivutar>
sorry
<kivutar>
I misread again
nedko has quit [Quit: kernel panic]
<kivutar>
well, I will try the old r3p0 then
nedko has joined #linux-sunxi
akaizen_ has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
seppel has joined #linux-sunxi
nedko has quit [Ping timeout: 240 seconds]
nedko has joined #linux-sunxi
nedko has quit [Client Quit]
netlynx has quit [Quit: Leaving]
hero616 has quit [Remote host closed the connection]
<sehraf>
(works on cbb&ct so i guess it should work on cb2, too :P )
<sehraf>
cb3/ct *
<rinni>
sehraf: Thanks I'll try
<rinni>
sehraf: doesn't boot with this uboot :(
<fiola>
I'm increasing sunxi_fb_mem_reserve in bootargs in uEnv.txt, but after reboot "cat /proc/cmdline" shows exactly the same value as before, sunxi_fb_mem_reserve=16. Does something override that reverse later? This is on an A10-OLinuXino-LIME.
<sehraf>
mhh sry .. then you'll have to wait for one of the experts
<fiola>
s/reverse/reserve/
<ssvb>
fiola: looks like u-boot is not picking up your uEnv.txt
<ssvb>
fiola: check u-boot logs, and also the commands which are run by u-boot at start
<ssvb>
it might be that you have another uEnv.txt in some other directory, or a boot.scr file
<rinni>
sehraf: don't worry I can life with only one CPU for the moment
<fiola>
ssvb: That was it, the LIME image has a boot.src which hardcodes the reserve. It's a binary file though, is there a similar utility to the fex one for going to/from text format?
<ssvb>
fiola: try to simply delete (or rename) boot.scr
<ssvb>
fiola: u-boot should support uEnv.txt just fine, and it is more convenient
<fiola>
Righto, thanks. Yes, I found this advice just now --- https://groups.google.com/forum/?_escaped_fragment_=topic/beagleboard/6X-5iVwJqYw#!topic/beagleboard/6X-5iVwJqYw --- but it's very old, so I'll try moving the file aside. Thanks :-)
<rinni>
Does anyone know if cpu frequency scaling is supported in mainline kernel? I can't make it work on my Cubieboard2 (kernel 3.16.0-rc3)
<ssvb>
rinni: no, it does not
<ssvb>
rinni: why do you need it?
<rinni>
well my device is mostly idle so I'd like to lower it the cpu frequency to save energy
<ssvb>
rinni: the power savings are minimal, and don't give you anything useful on non-battery powered development boards
<rinni>
but on boot it says "/cpus/cpu@0 missing clock-frequency property"
avsm has quit [Quit: Leaving.]
<rinni>
ssvb: so I should just not care? But how do I see the frequency it runs at?
<ssvb>
rinni: you can use 'perf stat <some_application>' and will get cpu clock frequency reported among other things
<ssvb>
the application should do some data-crunching to collect enough statistics, "perf stat openssl speed sha256" would be a good choice
<ssvb>
rinni: and if you need to change the cpu clock frequency and core voltage, you can do this in u-boot
<rinni>
ssvb: thanks, mine runs at 960MHz, that's fine
<fiola>
Yeah, I read about that, and I do see the bad degradation on the 1080p visual whenever anything uses memory. I'll try reducing the pixel depth too
<fiola>
Oh excellent, I'll grab that. Thanks! :-)
<fiola>
But despite the artifacts, at least it's obeying my boot-time changes, that's a good start :P
<ssvb>
fiola: without the scaler mode, the framebuffer scanount wreaks havoc on the slow 16-bit memory bus, and this will manifest itself as the whole screen shaking on intensive load
<fiola>
Yeah, it's hilarious :P
<ssvb>
are you observing this visual effect already? :)
<fiola>
Yep
jebba has joined #linux-sunxi
<ssvb>
fiola: fix the fex file to have the scaler mode enabled for fb0, create the updated script.bin from it, reboot and try again :)
jebba has left #linux-sunxi [#linux-sunxi]
<fiola>
So far, only when doing something in an xterm which changes the current display, and I think it happens *every* time there's a change, so it's not usable. But if I run the same command over ssh then the memory use doesn't couple to the visual on HDMI.
<fiola>
For example, even a simple "echo hello; sleep 1" run in a loop in the xterm makes the display jump once a second, it's that bad. So yeah, I'll go look at fex next :P
<libv>
no wonder people are complaining about killing their androids
<libv>
on a20
<libv>
they dd images.
<libv>
probably a10 images, which then of course mess up the partition table.
<fiola>
ssvb: lima-memtester is running now without reporting problems so far, but *visually* the display is jittering vertically all the time, very badly. This gives me something to test against when I look at scaler mode in fex in a few mins.
CaptHindsight has quit [Ping timeout: 264 seconds]
<ssvb>
fiola: rest assured, the fex change should fix this screen shaking problem :)
zombu2 has joined #linux-sunxi
CaptHindsight has joined #linux-sunxi
megal0maniac_afk has joined #linux-sunxi
megal0maniac_afk is now known as megal0maniac
ninolein has quit [Ping timeout: 260 seconds]
ninolein has joined #linux-sunxi
netlynx has quit [Remote host closed the connection]
<megal0maniac>
It's pretty clear given the high CPU usage and stuttering video that mplayer is using CPU rendering for video playback on this A20. Is there a workaround other than compiling mplayer again? Precompiled binaries, a configuration setting, something like that?
<Turl>
megal0maniac: use vdpau-sunxi
<megal0maniac>
Turl: Will look into it, thanks
robb83 has quit [Remote host closed the connection]
<fiola>
Turl: is it the "H264 Yes(only progressive)" row of the table in http://linux-sunxi.org/Cedrus that is most relevant to playing mp4 ?
zombu2 has quit [Ping timeout: 240 seconds]
<Turl>
fiola: if your mp4 is using h264, then yes
zombu2 has joined #linux-sunxi
<Turl>
mp4 is just a container format
<fiola>
That's why I said "most relevant". Most of the time that I play mp4's I see the h.263 decoder being used.
<Turl>
h263 is pretty old, isn't it?
<fiola>
Typo on "264"
<Turl>
mkv is pretty common for H.264 content these days
<Turl>
ah
<fiola>
For example, I went into a random directory of videos from Youtube, and 34 of the files are .mp4; checking the video formats of those, I see that 28 of them are "VIDEO: [H264]". So, I reckon "most relevant" is fairly close.
<Turl>
yes, h264 is often found in mp4 as well
<fiola>
2 of the 34 are showing as MP4V, one as VP80, and one as FLV1. That adds up to 32 not 34, so two are MIA. :P But H264 is the clear leader in this limited sampling.
<fiola>
So if that row in the table is correct, then hopefully vdpau-sunxi will keep most people happy.
<ssvb>
yes, just try it :)
<fiola>
The comment was more for the benefit of others like megal0maniac, as he asked. This LIME isn't going to be doing any video nor even 3D. I'd like to trade off all media for making it work as perfectly as possible in 2D.
mmarker has quit [Remote host closed the connection]
mmarker has joined #linux-sunxi
<fiola>
A high res 2D workstation that doesn't burn significant joules is valuable for me.
popolon has joined #linux-sunxi
Undertasker has quit [Ping timeout: 264 seconds]
Undertasker has joined #linux-sunxi
<rinni>
Does anyone know how to interpret the temperature values form the sunxi touchscreen controller? I'm on kernel 3.16.0-rc3 on a Cubieboard2 and get values like 43000
<rinni>
should I divide them by 1000 to get °C?
<fiola>
I'd like to know about the temperature sensor on the A10 as well, as I notice the SoC is running quite hot, despite the mini heatsink.
<fiola>
Load average 0.03 (after disabling the USB-OTG), so it's not doing a lot. But the heatsink can't be touched for more than a second, except by a masochist.
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
<Black_Horseman>
hola
<rinni>
reading the module code it says "(ts->temp_data - 1447) * 100)" while on the mailing list some say (ts->temp_data - 1447)/10)
<rinni>
that would actually make my 1000 ...
<fiola>
So close to 1337 :P
<Turl>
there was a miscalibration on one of those
<Turl>
I never had such hot a SoC, even after keeping them at 100%
<fiola>
Turl: how do you read your temperature sensor(s)?
<ssvb>
fiola: the SoC should be pretty cold when your system is idle
<Turl>
fiola: I don't, I'm talking about touching the SoC
<fiola>
ssvb: After 3 loops of lima-memtester, no errors reported. So it's just the visual artifacts I'll have to go on after fixing fex for scalar mode. Pity, I wanted numbers.
<fiola>
Turl: I'm an engineers, what I don't measure I don't believe.
<ssvb>
fiola: oh, so it's hot when running lima-memtester? that's normal
<Turl>
fiola: :D
<ssvb>
fiola: because it is using both cpu and mali gpu at the same time
<fiola>
ssvb: No, lima-memtester is a new thing, I've been checking the heatsink periodically for a few days now, and it's always hot. But I want numbers.
<fiola>
I assume the SoC has a temperature sensor.
<ssvb>
fiola: and no memory corruption errors is good :)
<fiola>
Yeah, not surprised temp being high while running that. :P
<ssvb>
fiola: the screen shaking artifacts are just the symptoms of major performance problems on a poorly configured system
<fiola>
ssvb: yeah, I figured as much. Looking forward to fixing it, among other duties here.
<fiola>
Thanks, looking in a few mins.
Undertasker has quit [Read error: Connection reset by peer]
Undertasker has joined #linux-sunxi
alexst has joined #linux-sunxi
issue_ has joined #linux-sunxi
avsm has quit [Quit: Leaving.]
robb83 has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
Undertasker has quit [Ping timeout: 255 seconds]
akaizen has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Undertasker has joined #linux-sunxi
bertrik has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
paulk-collins has quit [Quit: Ex-Chat]
Andy-D has quit [Ping timeout: 255 seconds]
wickwire has quit [Remote host closed the connection]
<fiola>
ssvb: interesting micro-benchmark. I kicked it off on the LIME first, but as little was happening I compiled it on a 2.33MHz Core2 as well and kicked that off. Preliminary results are that x86 is over an order of magitude faster on most measurements than LIME, which I guess isn't surprising. LIME's only part way though still, so waiting.
<ssvb>
fiola: blanking the screen on the LIME using "echo 1 > /sys/devices/platform/disp/graphics/fb0/blank" is going to improve the memory performance a lot
<fiola>
I'll put it on a more comparable machine like a BBB or Pi.
<ssvb>
fiola: screen refresh is heavily taxing the dram controller (minus at least 500MB/s of memory bandwidth), and if you have not yet enabled the scaler mode, then it is a total disaster
<fiola>
ssvb: That's a good point, cheers. Although my LIME screen's been blanked for a couple of hours, as I'm on ssh to it currently. The first thing that disappeared of course was the daft xscreensaver eye candy, that's a somewhat silly thing to have on the board, blanking is perfectly suitable.
<fiola>
ssvb: Indeed, this is pre-scalar mod, had to fix dinner as a priority. :P
<ssvb>
oh, I guess, it might be the xscreensaver heating your cpu :)
<fiola>
Not mine, but other people's :P
<fiola>
Not sure if this is the right channel for something specific to the LIME, but I'd like to know if there's a temperature sensor to be read.
<fiola>
Actually, should be generic to any A10, right?
<fiola>
And hence to sunxi.
rinni has left #linux-sunxi [#linux-sunxi]
<fiola>
ssvb: Made a pair of blank/unblank scripts using your info, thanks for that. Very useful when you're flipping through video inputs but most boards have gone to sleep, so give them a scripted poke first.
akaizen has joined #linux-sunxi
<fiola>
LIME not even halfway through that benchmark that took the Core2 just a few mins. I think we're facing geological timescales here, but it's good info prior to the scalar change.
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
Undertasker has left #linux-sunxi [#linux-sunxi]
<Turl>
fiola: x86 boxes have way greater memory bw