dv_ has quit [Read error: Connection reset by peer]
dv_ has joined #imx6-dev
silviof1 is now known as silviof
cnxsoft has quit [Ping timeout: 250 seconds]
diego_r has joined #imx6-dev
erol_ has joined #imx6-dev
cnxsoft has joined #imx6-dev
raumzeit has joined #imx6-dev
raumzeit1 has quit [Quit: Leaving.]
diego_ has joined #imx6-dev
diego_r has quit [Disconnected by services]
diego_ is now known as diego_r
<Esmil>
silviof: Yes, but that will rebase more than his own commits
<Esmil>
..so then he'd need git rebase -i to then remove all but his own commits
<Esmil>
And that's when git cherry-pick is usually faster if he doesn't have too many of his own commits
<silviof>
Esmil: :-) , yea I have in my development branch somewhat of hundert patches. a cherry-pick is not the best solution :-P I use rebase --onto.
<erol_>
Trying to build uImage but I get following error "Specify LOADADDR on the commandline to build an uImage" any help ?
cnxsoft has quit [Ping timeout: 250 seconds]
diego_ has joined #imx6-dev
diego_r has quit [Disconnected by services]
diego_ is now known as diego_r
cnxsoft has joined #imx6-dev
cnxsoft has quit [Ping timeout: 250 seconds]
bard3307 has joined #imx6-dev
<JBD1986>
hey guys, currently using freescales imx_3.0.35_4.1.0 kernel. Odd issue, where having a webcam plugged in a boot time prevents the wlan0 interface from starting
<JBD1986>
a powered USB hub does not resolve this issue for me
<JBD1986>
interestingly enough, plugging in a usb floppy drive causes the same problem, but using a powered hub DOES solve that issue.
<JBD1986>
I'm not ruling out that it's a power issue, but I was wondering if anyone else had some strange issues with webcams and/or the uvcvideo driver in this kernel release?
<hste>
JBD1986:The gk802 works better with powered hub if not I get a lot of usb errors
<JBD1986>
hste, thanks for the comment
<JBD1986>
i actually have a non-branded webcam that doesn't cause this issue, that DOES use the same uvcvideo driver
<JBD1986>
powered hub AND no hub
<JBD1986>
so I think I can call this a power issue
<JBD1986>
I'm just trying to rule out any alternatives
<hste>
JBD1986: It also helps with a good power adapter that can deliver 3A or more
<JBD1986>
yeah, our power adapter is 5V rated at 2A
<JBD1986>
a little close for comfort
<erol_>
hste is 3.0.35-g97e29ab-dirty this the latest kernel you compiled for gk802?
<hste>
erol_: yes, but I know Esmil has the new ga kernel working
<erol_>
Esmil, any chances for you to share the new config, or zipped kernel?
<raumzeit>
Hi there. Anyone familiar with the vivante xorg EXA driver for 3.10.17 GA release? I already tried to find an answer yesterday, without success.. Maybe it was too late. I get this strange Xorg.log error message: "fb memory is not big enough to hold shadow buffer!" that oviously comes from the vivante xorg driver. Full Xorg.log: http://pastebin.com/iSHNxgET
raumzeit has quit [Remote host closed the connection]
raumzeit has joined #imx6-dev
fossxplorer has quit [Remote host closed the connection]
<jas-hacks>
raumzeit: try without fbmem=48M
<raumzeit>
I'll try again... However, I had no fbmem option in the beginning when I first encountered the problem. Btw. Before GA release, I used 3.10.17-1.0.0-beta and I experienced no such problem...
<raumzeit>
I unset this cmdline parameter and report back in a minute or so
raumzeit has quit [Remote host closed the connection]
raumzeit has joined #imx6-dev
<raumzeit>
After removal of the fbmem option, I get the same problem as before. x continously tries to start a screen but fails over and over again... http://pastebin.com/VaWvWhZP
<raumzeit>
I wonder, however, why the vivante exa driver recognizes just 8M fb memory, although I specified more via kernel cmdline before.
<raumzeit>
Maybe the open source vivante kernel driver reports wrong?
<rz2k>
video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=16 while [ 133.838] (II) VIVANTE(0): Use built in mode (bpp 32)
<rz2k>
try playing around the RGB and bpp params of video=
<rz2k>
I bet vivante did not test all interactions
<raumzeit>
ok.. I will do so...
<raumzeit>
Again, I think it is odd that fb memory is reported to be 8M only, although I specified differently. Today I tried to go through the sources of the exa driver to find some hint about it, but it only calls a generic xorg function to retrieve the memory size. This is why I suspect that maybe the kernel driver already propagates wrong to xorg
<raumzeit>
Is there a way to find out the framebuffer memory size via a commandline tool or via /proc/something ?
<jas-hacks>
raumzeit: in your xorg log it is assuming - Depth 24 pixmap format is 32 bpp
<raumzeit>
thats right
<raumzeit>
so I set these values in kernel commandline as well?
raumzeit1 has joined #imx6-dev
raumzeit has left #imx6-dev [#imx6-dev]
<raumzeit1>
\name
<jas-hacks>
'bpp=32'
<jas-hacks>
no 'RGB24'
<raumzeit1>
Tried that... no success...
<raumzeit1>
now, fbmem is reported to be 12MB
<jas-hacks>
raumzeit1: what resolution does the hdmi driver report when the kernel boots?
<raumzeit1>
I think, maybe the vivante fb kernel driver calculates memory size according to screen size and bpp and ignores any other settings...
<raumzeit1>
1920x1080
<raumzeit1>
the exa driver always allocates twice the memory, I found that in the exa driver sources...
<raumzeit1>
sry... it doesnt allocate, it checks if there is twice the memory, such that xrandr may rotate the screen using a second frame buffer
<jas-hacks>
raumzeit1: what's does this line report "Console: switching to colour frame buffer device"
<raumzeit1>
switching to frame buffer device 240x67
<raumzeit1>
???
<raumzeit1>
should it report different?
<jas-hacks>
raumzeit1: which vivante libs are you running against fb or x11?
<raumzeit1>
x11
<raumzeit1>
aa moment... I installed the x11 libs after the system got up... I reboot again...
<raumzeit1>
same as before... Console: colour dummy device 80x30
<raumzeit1>
Console: switching to colour frame buffer device 240x67
<raumzeit1>
I have wandboard.org 3.10.17-1.0.0 GA kernel, vivante binary drivers for x11 and the vivante 3.10.17-1.0.0 GA EXA driver running
<jas-hacks>
raumzeit1: are /dev/fb0 and /dev/fb1 present?
<raumzeit1>
yes
<raumzeit1>
both are chmod 666 and belong to group video
<jas-hacks>
I suspect the framebuffer size is still 640x480 (80x30) which is why the fb memory is small. Pass the kernel 640x480 as the resolution.
<raumzeit1>
ok...
<raumzeit1>
I hope my monitor supports this resolution ;)
<raumzeit1>
now its Console: switching to colour framebuffer device 80x30
<raumzeit1>
do you have a running x11 with hw acceleration?
<jas-hacks>
have only tested 3.10.17-1.0.0_beta
<raumzeit1>
as I stated earlier, the error comes from the vivante exa driver, It fails upon a check whether there is enough fb memory available to store a second screen with same resolution...
<raumzeit1>
aah, that was working for me too
<raumzeit1>
:(
<raumzeit1>
I thought I go for the GA release...
<jas-hacks>
I will the test the GA release when I have some freetime
<raumzeit1>
and I really suspect the guys from vivante to dynamically allocated fb memory in the kernel module according to the current fb resolution. They may just ignore any settings passed via kernel commandline
<raumzeit1>
That would be nice. I read your blog anyway, so as soon as you get a working system with 3.10.17 GA or find a more detailed hint on what may be going wrong, it would be nice if you write about it
<raumzeit1>
I will also dig into this over the weekend, if I find some time
<jas-hacks>
the fb memory is already allocated to a front (/dev/fb0) and shadow buffer (/dev/fb1).