amitk has joined #linux-exynos
gautam__ has joined #linux-exynos
disdi has joined #linux-exynos
<disdi> hi this is regarding the post http://libv.livejournal.com/27388.html , where it has been asked to support and help linux-exynos community. I would like to volunteer for this work but would like to know which are the areas that are issues that are most urgent
ssk has joined #linux-exynos
<ssk> How to run Android JB as domU(duest os) in xen 4.5 hypervisor.
<ssk> I want to install android JB as domU(guest OS) in Xen hypervisor.what are the necessory changes i have to make.can any one help me on this.Up to now i only cahgedin fstab file.
disdi has quit [Quit: Page closed]
aballier has joined #linux-exynos
gautam__ has quit [Ping timeout: 252 seconds]
ssk has quit [Ping timeout: 244 seconds]
ssk has joined #linux-exynos
gautam__ has joined #linux-exynos
ssk has quit [Quit: Leaving]
ssk has joined #linux-exynos
disdi has joined #linux-exynos
<disdi> hi this is regarding the post http://libv.livejournal.com/27388.html , where it has been asked to support and help linux-exynos community. I would like to volunteer for this work but would like to know which are the areas that are issues that are most urgent
<Wizzup> hi
<Wizzup> It depends on the kind of work you can and want to do. There's a lot of wiki work and organising, writing to be done, as well as programming and testing
<Wizzup> Basically, if you have an exynos based board, you can help testing/programming. If you don't, you can still help out (a lot) with the wiki
<Wizzup> There are now some working guides for getting mainline (or: linux-next) kernels working on some chromebooks, there's a guide that works for the odroid u2//u3 kernels (mainline), and there are some guides on how to create a rootfs
<Wizzup> but new u-boot guides are definitely required - where the mainline u-boot is used, and then at some point those guides need to merged & cleaned up
<Wizzup> ssk: I don't know the answer to your question
<Wizzup> There's not much know on virtualisation; and what board are you talking about exactly?
<Wizzup> I mean, there is some stuff known on virtualisation. I know there's working kvm (on some kernel) on snow, but I don't know the status of mainline
<Wizzup> disdi: basically, there's this page, but it mostly lists my own items: http://linux-exynos.org/wiki/User:Wizzup/Wiki_Wishlist . but looking at the main page there's no obvious "current status" or "tasks that people should pick up" page
<Wizzup> I guess I can try to do that
<disdi> ok
<Wizzup> I'll try to do that now
<disdi> that would be great
<Wizzup> currently wiki reg is disabled due to spam, but I can make you an account now
<disdi> sure I would love to contribute
<disdi> is their some kernel drivers left for mainlining
<disdi> ?
<Wizzup> There is definitely some kernel work to be done
<Wizzup> I am not up to date fully, but javier__ and afaerber have been doing a lot of good work on that (and others as well, but I don't think they are in the irc channel)
<disdi> I was looking specially for this?
<disdi> actaully there is no update on the wiki for that
<disdi> it says " This page is very outdated. Someone needs to update it. :) "
<Wizzup> per device there is some status
<disdi> For "Provide an overview of what drivers went mainline in which version, and what is planned"
<disdi> hoe this is to be done
<Wizzup> follow samsung soc list, I think, ping javier__ & afaerber, etc
<disdi> I guess the patches are sent directly to linux-arm mailing list?
<disdi> ok I will consult them
zombah has joined #linux-exynos
<Wizzup> there's a samsung soc mailing list I think
<ssk> hi to Wizzup and disdi .i great to have good conversation , i will also work and contribute the pages on Arndale 5420and 5250.
<disdi> @ssk: g8
<Wizzup> cool!
<Wizzup> pm me an email+preferred nickname for a wiki account :)
prahal has quit [Ping timeout: 255 seconds]
prahal has joined #linux-exynos
<disdi> Kindly confirn ur email-id
<disdi> @Wizzup: Kindly confirn ur email-id
dlezcano has joined #linux-exynos
<disdi> merlijn@wizzup.org ?
<ssk> i forwarded my mail id.
<Wizzup> yes
prahal has quit [Ping timeout: 240 seconds]
<disdi> I too have sent a mail for the same
<Wizzup> done
<ssk> disdi:ya i got it.As i will completed my part will come for pages.
<disdi> @ssk: thanks
dlezcano has quit [Remote host closed the connection]
prahal has joined #linux-exynos
<gautam__> anyone has run android on arndale 5250 board with kernel > 3.13?
disdi has quit [Quit: Page closed]
ssk has quit [Quit: Leaving]
ssvb has quit [Ping timeout: 252 seconds]
zombah has quit [Ping timeout: 252 seconds]
zombah has joined #linux-exynos
gautam__ has quit [Ping timeout: 252 seconds]
dlezcano has joined #linux-exynos
gautam__ has joined #linux-exynos
Tenkawa has joined #linux-exynos
Tenkawa has joined #linux-exynos
ssvb has joined #linux-exynos
Tenkawa has quit [Quit: leaving]
gautam__ has quit [Ping timeout: 244 seconds]
<prahal> sclk_g3d was changed to "DIV(CLK_SCLK_G3D, "sclk_g3d", "mout_g3d", DIV_G3D, 0, 4)," what happens when I continue to set the 533mhz rate on sclk_g3d ? does that mess the divider ? (it needs to be value 1, the divider that is)
<prahal> beforehand it was "GATE(CLK_SCLK_G3D, "sclk_g3d", "div_g3d", GATE_IP_G3D, 0,"
<prahal> ie I get a wrong clock with regards to mali . Ie MMU page fault seems to point there
<prahal> sorry I get Mali MMU page faults while running two es2gears at the same time as gnome-shell
<prahal> and the only clue so far is an overclock of some sort
afaerber_ has joined #linux-exynos
afaerber has quit [Ping timeout: 246 seconds]
amitk has quit [Quit: leaving]
liquidAcid has joined #linux-exynos
Tenkawa has joined #linux-exynos
<Tenkawa> hello al
<Tenkawa> anyone got a minute to help me with a chromebook 1 3.19 kernel hiccup?
<Tenkawa> recompiled it this morning and generated a new image and now it cant boot it (appears to be dtb related)
<Tenkawa> trying to gret back to default exynos_defconfig and even it won't boot
<Tenkawa> oh well.. time for experiments
<Tenkawa> bbl
Tenkawa has quit [Quit: leaving]
afaerber_ is now known as afaerber
<afaerber> prahal, unless my scrollback is incomplete, you forgot to mention what exynos soc and board you are talking about ;)
<afaerber> prahal, but since you're asking about specific code changes, the linux-samsung-soc list would probably be a better place to catch the Samsung people - haven't seen tfiga around here recently
<daniels> prahal: oh
<daniels> prahal: just uploading a commit which might help
<daniels> prahal: not been able to test with mali as i've been caught up doing tegra bringup stuff, but as soon as i have i'll post it
* daniels glares at his terrible upload speed
<prahal> afaerber: sorry. This is OdroidU2 exynos4412 prime
<prahal> I changed u-boot since it worked well (es2gears in a composited xorg session, here gnome shell) . Upstream (denx) except I tried to use the hardkernel value for mpll (880mhz instead of u-boot 800mhz)
<prahal> daniels: thanks
<prahal> by the way I had a small issue but still ... es2gears / glxgears had transparent background. I fixed it by moving ARGB8888 before XRGB8888 in exynos_drm_plane.c formats array
<prahal> is it nuts ?
<prahal> + DRM_FORMAT_RGB565 to this array to get 16 bpp mode (fbdev and xorg) correct colors
<daniels> prahal: np, let me know how you go
<daniels> prahal: as to argb vs. xrgb, sounds like your xorg driver is broken
<prahal> I was told there was an issue with mali blob long ago . Though I revisited the issue argb vs xrgb as well my glxgears does not go through mali and sitll exhibit the same glitch
<prahal> daniels: exynos5 ^ ?
<prahal> gtg , be back soon
<afaerber> prahal, there are patches for libdrm on linux-samsung-soc
<daniels> prahal: oh i see, exynos4. afraid i've no idea then.
<afaerber> "[v2] libdrm: improvements to userspace exynos component"
<liquidAcid> prahal, so you tried setting the mpll to 880mhz again?
<liquidAcid> afaerber, i should send a v3 shortly
<liquidAcid> but i don't think these are going to fix any of prahals problems
<afaerber> ah, that's you :)
<liquidAcid> :)
<liquidAcid> does someone know if this is the correct way to switch a crtc off?
<liquidAcid> drmModeSetCrtc(fd, crtc_id, 0, 0, 0, NULL, 0, NULL);
<prahal> liquidAcid: yes 880mhz . It has been a while last I checked.
<liquidAcid> cool, and did the emmc explode again? :D
<prahal> I used my revert CLK_SET_RATE_PARENT in div mmc_pre4
<liquidAcid> prahal, did you use assigned-clocks for that?
<prahal> no, plain old clk-exynos4.c revert I carried back when I was with initial hardkernel u-boot
<liquidAcid> ah, ok
<prahal> no main issue is this mali paging . I have been able to fix my issues with mali blobs
<liquidAcid> prahal, ah, which issues exactly?
<prahal> mostly totem/evolution get a mali crash if I do not set /proc/sys/kernel/randomize_va_space to 0 <- ugly
<liquidAcid> i've been doing some benchmarks with my preloader stuff, according to memeka i'm getting good scores
<liquidAcid> prahal, that's COMPAT_BRK, right?
<liquidAcid> prahal, but that's the x11 blob i guess, so i can't really comment on that
<prahal> no seems not
<prahal> I already have COMPAT_BRK=y
<liquidAcid> that's strange, i don't have it set, so the heap should be randomized and the blob survives a glmark2 run
<liquidAcid> have you already checked where exactly it crashes?
<prahal> mind I can only trigger this one with totem or evolution
<prahal> (this under a gnome-shell session, would need to test with metacity
<daniels> i'd be looking at the x11 driver rather than the blob per se then
<daniels> there are definitely some sync issues with 4xx (understatement), so it could be as simple as delaying a drm buffer unref
<prahal> ie the clutter-gtk examples plays fine, but not the advanced applications (I started to believe another of mdrjr mines in the mali blobs ... ala exit 1 he added if machine description had no ODROID string
<prahal> the blobs are buggy but when the builder start adding mines inside :/
<liquidAcid> prahal, he really did that?
<liquidAcid> which blob is that?
<liquidAcid> prahal, i have no x11 setup here, just running the fbdev blob
<prahal> well turns out dsd already lost a fair amount of time on this machine description trick
<prahal> that did not made me happier
<liquidAcid> prahal, so that check only seems to be in the x11 blob then?
<prahal> not in all of them (the github ones I also have miss this check
<prahal> the ones that comes from older images
<liquidAcid> prahal, i have this one: http://builder.mdrjr.net/tools/r4p0-mp400-fbdev.tar
<liquidAcid> liquid@chidori ~ $ uname -a
<liquidAcid> Linux chidori 3.19.0-debug+ #1 SMP PREEMPT Mon Feb 23 15:57:26 CET 2015 armv7l SAMSUNG EXYNOS (Flattened Device Tree) GNU/Linux
<liquidAcid> and works ok here
<prahal> so that is random ... well this one was nasty. Not the kind of plain ascii string in the binary .. the kind that require assembly or sheer luck (I started with sheer luck in my debugging session
<prahal> the fun thing with the randomize_va_space issue is that it vanish if running under gdb
<daniels> yeah, i'd say it's as much blind luck as anything
<liquidAcid> prahal, have you tried stracing it yet?
<prahal> I was able to reproduce under gdb with "set disable-randomization" ...
<daniels> try xf86-video-armsoc from github.com/dsd
<prahal> daniels: indeed . sheer luck . I trusted so was not at all looking for such an issue
<prahal> liquidAcid: yes . I spent a fair amount of time on this session
dlezcano has quit [Ping timeout: 250 seconds]
<liquidAcid> guess you could try the r5p0 blob and check if it has the same issues
<prahal> daniels: I have dsd armsoc . Though the kernel I use has umplock remove (and libUMP.so is also gone with the mali blob I use) . There is the r4p0 branch still (quite old but worth a try).
<prahal> daniels: this is about the argb vs xrgb issue ?
<prahal> liquidAcid: the second issue is a segfault in X resource manager (triggered by evolution once the randomization issue was worked around).
<daniels> prahal: ah - partly, but mostly about timing/sync issues i'd guess may be biting you
<prahal> I had it back when using r3p2 so ended up reusing the hack : I add an XInitThreads in libx11 XOpenDisplay
<prahal> back then it was an issue with X mutex not initialized if no XinitThreads call
<liquidAcid> prahal, someone also patched the binaries to do that
<daniels> ah yes - xlib really should do that anyway ...
<prahal> indeed . I had the ld preload and all but this one happens even with it . The backtrace shows no trace of mali in this one (cairo-xlib get_font_options > XGetDefault > XrmQGetResource > __GI___pthread_mutex_lock < segfault there
<prahal> but only with evolution mail ... go figure :)
dlezcano has joined #linux-exynos
Kurlon has joined #linux-exynos
<liquidAcid> terminate called after throwing an instance of 'std::bad_alloc'
<liquidAcid> what(): std::bad_alloc
<liquidAcid> great, and no backtrace
nashpa has quit [Quit: Going away]
nashpa has joined #linux-exynos
Kurlon has quit [Read error: Connection reset by peer]
dlezcano has quit [Ping timeout: 265 seconds]
zombah has quit [Quit: Leaving]
ssvb has quit [Ping timeout: 244 seconds]
ssvb has joined #linux-exynos
liquidAcid has quit [Quit: Leaving]
ard has quit [Ping timeout: 265 seconds]