<ferric>
cosm: ah. what does 2 panel mean, btw? 2 hdmi ouputs?
<cosm>
ferric: yeah, I think it can be replaced with outputs (not necessarily HDMI) here
<cosm>
but I'm not completely sure, maybe some else can confirm
<ferric>
cool, thanks.
<cosm>
by the way, I'm not sure 5 layers is accurate for RK3188
<ferric>
what's 5 layers?
<cosm>
from what I've seen in the source code, there's: layer 0 (video), layer 1 (graphics), hardware cursor and probably background
RayFlower has quit [Quit: minab476vw3 tedgfjkhjl,kyjtrheg6s]
<cosm>
ferric: the LCDC supports multiple overlays, which can be used to accelerate various framebuffer-related stuff
<ferric>
oh nice.
<ferric>
so you can write to / accelerate different layers at differen times?
<ferric>
not times, but i suppose differently based on need
<cosm>
sort of
<cosm>
for example I'm using the video layer for XV support
<cosm>
so the video layer is basically a separate framebuffer, which get overlayed by the LCDC on top of the base (graphics) layer
<cosm>
and it can also do resizing in hardware (so the source framebuffer can be smaller/larger) than what actually gets displayed on top of the graphics layer
bgal has joined #linux-rockchip
<cosm>
^yeah, those parentheses were unnecessary
<ferric>
hehe
<ferric>
i see
<ferric>
cosm: so what's the advantage of having more different layers in hardware? just the ability to manipulate them with more granularity?
<ssvb>
ferric: you can move a layer around without copying anything, you can use different pixel formats for different layers (RGB for the desktop and YUV for video)
<cosm>
^that
<cosm>
and you can also do resizing with 0 cost for the CPU
<ferric>
aha.
<ferric>
does this affect userspace apps at all? or just, say, window managers?
<ssvb>
ferric: unfortunately compositing window managers are not very compatible with hardware layers in X11 desktop
<ssvb>
non-compositing window managers are fine
ferric has quit [Ping timeout: 240 seconds]
AstralixNB has quit [Ping timeout: 252 seconds]
ferric has joined #linux-rockchip
<ferric>
back.
<ferric>
ssvb: looks like aiglx adds support to X to do hardware 3d and compositing?
<ssvb>
aiglx (and anything related to glx) is not supported by the mali binary drivers
<ssvb>
it's only GLES and EGL
<ferric>
aha
<ferric>
sadface.
<ferric>
the mali is a powerful gpu though
<ssvb>
there is no desktop OpenGL support and the things like glxgears are not accelerated
_massi_ has quit [Quit: Leaving]
<ssvb>
but you can use kwin_gles as a compositing window manager
<ssvb>
basically glx=bad, egl=good, gles=good
FreezingCold has joined #linux-rockchip
<ferric>
ah, cool
<ferric>
do all video vendors still ship binary drivers for linux?
<ssvb>
this is complicated
<ssvb>
arm provides the mali400 drivers to the soc manufacturers, and the soc manufacturers provide the drivers to the end users
_whitelogger has joined #linux-rockchip
<ferric>
ssvb: right, the soc manufacturers aren't very good about releasing code are they?
<ferric>
they're like: got it to work, end of story!
<ssvb>
they are not good about releasing binaries either
<ferric>
ssvb: yeah, neither are the board manufacturers
<ferric>
but i guess they're all hardware shops
ssvb has quit [Quit: Leaving]
ssvb has joined #linux-rockchip
impulse___ has joined #linux-rockchip
impulse___ is now known as impulse2000
<impulse2000>
hi all
<impulse2000>
Can anybody help with RK3026 kernel build?
m1r has quit [Ping timeout: 240 seconds]
<ferric>
impulse2000: what do you need?
<impulse2000>
i have RK3026 tablet in died mode
<impulse2000>
maybe you know where can i get generic .config for compile kernel
<cosm>
yeah, I'm sure it's either not shipping now or it's fake
<ssvb>
cosm: if I understand it correctly, EVB is just a base board with connectors (kind of a docking station), everything essential like the SoC and RAM is on the module itself
<ferric>
yep. good ol' candy feng.
<cosm>
ssvb: yeah, I took another look and I think you're right
<cosm>
ssvb: but then 85 EUR is a bit steep just for that
<ssvb>
cosm: its price includes the RK3188-SOM-4GB module
<cosm>
haha
<cosm>
finally, puzzle solved
<cosm>
I hope they use x16 DRAM chips
<ssvb>
yep, I tried to check this, but the picture is blurry :)
<cosm>
haha, I've tried to do the same thing
ferric has quit [Ping timeout: 255 seconds]
FreezingCold has quit [Ping timeout: 252 seconds]
ferric has joined #linux-rockchip
<ferric>
cosm: how do you check if the bus is x16?
<cosm>
dmesg |grep Bus
<cosm>
sorry, ferric, that^ was for you
FreezingCold has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 245 seconds]
ncrmnt has joined #linux-rockchip
<ncrmnt>
hello all, is there anyone around today who knows rockchip's PLL stuff?
<ferric>
cosm: cool. i'll check my qx2.
<ferric>
ncrmnt: what's pll? phase lock loop?
<ncrmnt>
yep, I'm hacking 3.10 kernel to run on MK809III and (later) Pipo M6 Pro 3g
<ferric>
nice.
<ncrmnt>
Thought someone might give a hand.
<ferric>
ncrmnt: you need it to overclock the cpu or just make the kernel work?
* ferric
is useless, unfortunately.
<ferric>
unless you need a tester :-)
<ncrmnt>
Just to get it to work
<ncrmnt>
for a start
<ferric>
gotcha
<ncrmnt>
I now got it to boot without crashing after setting gpll
<ferric>
oh awesome.
<ncrmnt>
now it crashes somewhere around setting ddr clock
<ferric>
ncrmnt: how are you booting it? on an actual device and using serial?
<ferric>
(sorry for the n00b questions. :)
<ncrmnt>
On the actual device. I have HC-05 installed in bothdevices
<ferric>
ah cool
<ncrmnt>
Actually, you can't do a thing without a serial here
<cosm>
ncrmnt: just with the initial code dump from rockchip and the patch I've linked, my 802iv-compatible devices got to the point where they were waiting for a rootfs
<cosm>
ncrmnt: the one which got to the rootfs code was -T
<ncrmnt>
Well, I nailed down that insect: parent->ops->recalc_rate was nil
<ncrmnt>
And yes, my chip's labeled as -T
<ncrmnt>
cosm: Which branch and what dts did youuse to boot?
<cm8>
cosm: i had a lot of 3188-T kernels boot on 3188, e.g. kernels from freaktab.info forums, when even some agressively clocked 3188 kernels failed, so from experience no problem booting -T on non-T,
<markvandenborre>
looking at what the thing does...
<ncrmnt>
markvandenborre: Well, basically a DSP dev board with linux, and hw video decoder.
<ncrmnt>
No way as fast as recent rockchips, but the DSP's quite tasty.
<markvandenborre>
you may want to make that info more prominent in the repo
<ncrmnt>
Well, we've just posted the stuff lessthan 24 hours ago. Will be polishing the documentation in the upcoming month.
* markvandenborre
is looking into something that could do tesseract ocr image processing fast enough
<markvandenborre>
ncrmnt: good luck!
<ferric>
ncrmnt: congrats
<markvandenborre>
really nice to see you manage to convince management to do something like that
<cm8>
ncrmnt: I've a working toolchain and build on the device, currently running predecessor of rockchip-3.0-rbox-kk (i.e. before naobsd rebased 3.0-kk to rkchrome fork)
<ncrmnt>
Hopefully it takes off and will be able to do the same for the next chip.
<cosm>
ncrmnt: do you publish documentation for the video decoder?
<tonikasch>
wow, video decoder? that hantro thinguie?
<ncrmnt>
cosm: Well, we can't. So my college is refactoring their code to make a library with the smallest proprietary blob possible and a sane API
<ncrmnt>
the reference code was an insane proprietary crippled mess.
<ncrmnt>
I have a strange feeling NDAs have been invented so that noone sees the code BEFORE paying monies
<cosm>
haha
<tonikasch>
wow, so vpu will come to life under GNU/linux? :D
<ncrmnt>
tonikasch: The one on K1879?
<ncrmnt>
Well, it does work under linux. android is kind of... well.. slow on 324Mhz
<tonikasch>
oh, though we were talking about rk :p
<tonikasch>
sorry :S
<ncrmnt>
No, I was offtopicing ;)
<tonikasch>
:)
<ncrmnt>
Rk's VPU is a mystery to me. It's on2 AFAIK, that roumored to have good support in linux... But I saw no code, no libs, no blobs.
<ncrmnt>
just android blobs
<ncrmnt>
So unless someone hooks android's libs via libhybris to vdpau or whatever - we're screwed.
<cosm>
tonikasch: if you feel like running pre-alpha software, you can use my X driver with XV support and mplayer compiled with NEON support to watch pretty high resolution video
<tonikasch>
well. I was in talk with somebody at google that promised me to get in touch to their licensing company in order to make pressure over Rockchip to publish the code but... that was more than a month ago and I have had no reply... three days ago I replied but...
<tonikasch>
oh!
<tonikasch>
cosm I do feel... where could I find that? :)
<ncrmnt>
cosm: Does it need many kernel patches to work?
<ncrmnt>
Like will the rockchip-3.0 from linux-rockchip work with it?
<tonikasch>
or perhaps the omegamoons 3.0.101?
<cosm>
ncrmnt: a few, they're described in the readme file in the kernel repo
<mrueg>
how useable is kernel 3.10 on radxa?
<mrueg>
any big showstoppers still there?
<cosm>
tonikasch: you can probably cherry-pick my patches on that one, I don't know
<tonikasch>
cosm ok, I'll give it a try during the weekend, _thanks_ :)
<ncrmnt>
I see. thanks for your work, cosm.
<ncrmnt>
I'll forward port those to 3.10 once I get that pile of @#@@ to boot
<cosm>
ncrmnt: awesome, I didn't have time to fix 3.10 for my hardware
<cosm>
ncrmnt: what RK3188 hardware are you using, by the way?
<ncrmnt>
MK809III and Pipo M6 Pro 3G
<ncrmnt>
There's also an official rockchip's dev board at work
<cm8>
cosm: i tried to apply these patches manually, since git am failed to rockchip-3.0-rbox-kk (sdk 4.4.2 kernel), it booted, but screen stayed blank, there are quite some differences, e.g. the code for centering scaled windows is not to be found at all in kk sources; checking out lgeek/Linux3188 and building lead to a non-booting kernel (couldn't even use ssh), problem here: no mk809iii defconfigs and probably ddr pll init issues
<ncrmnt>
cm8: anything in the serial log?
<cm8>
ncrmnt: no serial console, sorry :/
<cosm>
cm8: yeah, that's going to be tricky to debug without a serial console
<ncrmnt>
Ah. RK3188 is so buggy I don't even try to play with it without a proper serial console.
<cosm>
ncrmnt: I think my kernel fork should work on MK809III
<ncrmnt>
cosm: it should, nothing big - it just needs some patches to make wifi work
<ncrmnt>
like poweron and rfkill pins
<ncrmnt>
took me a while to figure out that wifi rfkill gpio is configured in the _bluetooth_ platform data
<cm8>
I use a netbook to simply flash a tried and tested boot.img in case the hdmi lcdc does not init and ssh does not work, it's not too big a pain, but a proper debug log is missing - I tried netconsole, but most of the time a log is not sent, which means it panics too early for this method.. :)
<ncrmnt>
I have added board-mk809ii-ap6210.c there
<cosm>
ncrmnt: just wondering, what are you using mali for?
<cm8>
cosm: yes, basically, the predecessor branch which was based on rockchip-3.0 is gone now, but according to naobsd 3.0-rbox-kk should be the same, and it's running on a mk809iii v1.0
<ncrmnt>
cm8: my branch is based on rockchip-3.0 branch
<cosm>
cm8: ok, if I get the time I'll see if I can port the patches to it
<ncrmnt>
Okay, may be a stupid question. Is there a more or less complete list of branches with patches?
<ncrmnt>
For the sole reason I started multidev branch - I wanted separate board-* files for all boards I have in ONE kernel tree
<ncrmnt>
For the current stuff with RK3188 is complete chaos(tm)
<cosm>
ncrmnt: yes, it is!
<cm8>
cosm: I also modified the cpufreq tables for cpu / gpu / ddr to be natural (not fractional) multiples of 24 mhz, and experimented with the dram speeds, cat /proc/clocks is a real friend for that
<cm8>
ncrmnt: +1, adding the dozens of forks, each addressing a different issue, each based on slightly different sources :)
<ncrmnt>
cm8: Well, I suggest we team up and try to merge all this stuff into one useable branch. I can test and add support for MK809III and Pipo M6 Pro 3g, since I have them around.
<ncrmnt>
Since with DeviceTree we need a lot less hackery to get a lot of hardware supported
<cm8>
ncrmnt: my git knowledge revolves around cloning, applying+creating patches for personal use, plus i do not like to pay the github hydra
<cm8>
i can help test and document stuff on the wiki, but actively reorganizing stuff at github is currently out of my scope, i guess
<ncrmnt>
Well, I can organise stuff at my branch, no problem.
<ncrmnt>
But I want to see 3.10 first, since maintaining rockchips' out-of-date 3.0.36+ madness will be cumbersome
<ncrmnt>
So my plan is: Basic 3.10 booting, cosm's patches for fburbo ported to 3.10, ???
<ncrmnt>
Btw, did anybody manage to bring up ap6210 bluetooth?
<cm8>
I think most people out there would immensly appreciate: a) if devs enable IKCONFIG to include kernel config in built kernels b) a last-rites 3.0.36+ kernel that has the most appreciated and useful patches, a working 3.10 kernel :) c) defconfigs dedicated to the various devices out there
<cosm>
ncrmnt: I vaguely remember seeing a fork for that :)
<ncrmnt>
Oh... forks... There are just too many of them now.
<ncrmnt>
Okay, see you around, I'm off to get some sleep. enough of debugging for today.
<cosm>
good night
<cm8>
c) is immensely important - if people can rely on a config that has worked for someone else the places to troubleshoot reduce to log spotting and changing source files, the config would be less in question, i guess