[opensuse-arm] How to not do upstream
Hi Andrew, openSUSE fellows, While trying to get a stable working base on at least a single SoC family (OMAP), I've stumbled over a bunch of issues, all of which are frustrating of their own, but are driving me insane in combination. OMAP graphics ============== There are 2 competing implementations for graphics on OMAP. Well, actually 3: * omapfb (open source kernel+xorg, no xrandr, limited ) * omapdrm (open source kernel part, open source Xorg part, can piggy-bag on closed source driver for EXA) * pvr (closed source) So what's the big deal with the situation as is? Well, omapfb is reasonably fast, but doesn't work in 3.4. It did work in 3.2. Also mode setting doesn't work with it. It also renders everything in software, so it doesn't use the graphics hardware. Omapdrm is a nice future facing technology that is still in staging upstream, so I can overlook the fact that I needed a bunch of patches to actually make it work at all. It does its mode setting job reasonably well given the early state of development. Funnily enough it seems to not exploit the hardware completely on OMAP3, since omapfb can do 1080p there while omapdrm can not. Oh well. Also, Rob has been very helpful to get me going with the open source parts, so kudos to him! The omapdrm Xorg driver however is crawlingly slow. It takes _seconds_ to move a window in xfce when running on 1080p. So we have an awesome kernel+user space bundle that could do most of the things users want (2d, easy mode setting), but is basically useless, since it's unbearable to work with. Has anyone ever tried to work with it? The omapdrm driver has a special hack to piggy bag on the pvr driver when it's installed. So you can install the pvr driver and get accelerated graphics. Well, tough luck of you don't work for Canonical (or Linaro which is apparently Canonical in disguise), because they only release Ubuntu binary .debs that _link directly against Xorg. How could you possibly design binary drivers any worse? Every time the ABI changes in Xorg, the driver doesn't work. Different compiler flags potentially break it too. Since openSUSE has an Xorg ABI version of 12 and current Ubuntu which the TI folks build against is 11, we're out of luck. No acceleration for us. But then again, acceleration would also only be there for OMAP4, because OMAP3 drivers are compiled for soft float only. What a mad world. As to running the pvr driver directly, I can't comment either, thanks to the above facts. Pandaboard ES ============== So far, I was always under the impression that TI was a reasonably good citizen when it comes to keeping things open source and in a working state there. They have their code in upstream Linux and in upstream u-boot. Or do they? Apparently to run Linux on the OMAP4460 SoC, you basically have to have VCC logic in the kernel which simply isn't upstream yet. So using an upstream kernel, you can basically not use the Pandaboard ES which does use that SoC. Isn't that insane? That board is publicly available for more than 1/2 year now! I haven't tried yet, but at least u-boot support is supposed to be synchronized between the pandas by now. That's at least some good news. Pandaboard ============== Our pandaboards ended up being reasonably unstable. Some times they were able to endure for weeks without crashing, some times only for hours. Thanks to some hints on IRC I finally updated u-boot to have updated voltage controls. Apparently there are 2 ways to do voltage control: * statically in firmware * dynamically in the OS You always want the static one in firmware to work right to get you going. But eventually it's nice to have voltage control in the OS as well, right? Especially when firmware's initial settings weren't all as optimal as you might expect, which isn't unheard of in the firmware world. Well, turns out there is a Ubuntu kernel that has voltage control. Upstream doesn't. Again, the same problem as for the ES, just that it hit me on non-ES boards this time. At least updating u-boot got me a stable board. Hooray. Beagleboard ============== This is my favorite. After updating u-boot to get panda boards stable, suddenly my beagle board wouldn't boot anymore. It'd crash randomly, some times just freeze seconds after the boot. The only variable here is the boot loader. Does anyone even test upstream code? I mean, seriously. I tried u-boot 2012.04 and 2012.07-rc1 now with the same 3.4 kernel that worked just fine before on the older Linaro u-boot snapshot we had. Both show very similar crashes, so it's probably an issue that has never been addressed. So I went into the #beagle IRC channel to ask for help. Unlike the #pandaboard channel where people actually ended up being helpful, all I got was: [3:13pm] <aholler> use 3.2.x [3:16pm] <aholler> everything above is broken on the beagleboard, at least here. Are you kidding me? There's a user in the IRC channel who reports that upstream completely breaks for him. There wasn't even any objection to that comment, so I assume more people have had issues there. I'm also quite sure that if I'm having issues with upstream u-boot + upstream kernel that this is not because of any special environment I might have. It's most likely because upstream is simply not working. Is TI even supporting upstream sources or is it just a nuisance to get off the table so merging with Linaro and Ubuntu trees is easier? This is certainly not a way to foster a community and puts a lot of work on _our_ table which really should be in the SoC vendors' and specifically Linaro's hands. Annoyed, Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 12/07/2012 16:09, Alexander Graf a écrit :
Hi Andrew, openSUSE fellows,
While trying to get a stable working base on at least a single SoC family (OMAP), I've stumbled over a bunch of issues, all of which are frustrating of their own, but are driving me insane in combination.
OMAP graphics ==============
There are 2 competing implementations for graphics on OMAP. Well, actually 3:
* omapfb (open source kernel+xorg, no xrandr, limited ) * omapdrm (open source kernel part, open source Xorg part, can piggy-bag on closed source driver for EXA) * pvr (closed source)
So what's the big deal with the situation as is? Well, omapfb is reasonably fast, but doesn't work in 3.4. It did work in 3.2. Also mode setting doesn't work with it. It also renders everything in software, so it doesn't use the graphics hardware.
In fact it works in 3.4 (or maybe 3.5?) with an additional module: modprobe panel-tfp410 modprobe omapfb mode=dvi:1440x900MR-24@60 Maybe your talking about xorg driver which is NEON optimized? omapfb XOrg driver does not work (for me) but if you use the generic XOrg fbdev driver with omapfb module, it works. (But no idea about performances, since I only displayed an xterm).
Omapdrm is a nice future facing technology that is still in staging upstream, so I can overlook the fact that I needed a bunch of patches to actually make it work at all. It does its mode setting job reasonably well given the early state of development. Funnily enough it seems to not exploit the hardware completely on OMAP3, since omapfb can do 1080p there while omapdrm can not. Oh well. Also, Rob has been very helpful to get me going with the open source parts, so kudos to him!
The omapdrm Xorg driver however is crawlingly slow. It takes _seconds_ to move a window in xfce when running on 1080p. So we have an awesome kernel+user space bundle that could do most of the things users want (2d, easy mode setting), but is basically useless, since it's unbearable to work with. Has anyone ever tried to work with it?
The omapdrm driver has a special hack to piggy bag on the pvr driver when it's installed. So you can install the pvr driver and get accelerated graphics. Well, tough luck of you don't work for Canonical (or Linaro which is apparently Canonical in disguise), because they only release Ubuntu binary .debs that _link directly against Xorg. How could you possibly design binary drivers any worse? Every time the ABI changes in Xorg, the driver doesn't work. Different compiler flags potentially break it too.
Since openSUSE has an Xorg ABI version of 12 and current Ubuntu which the TI folks build against is 11, we're out of luck. No acceleration for us. But then again, acceleration would also only be there for OMAP4, because OMAP3 drivers are compiled for soft float only. What a mad world.
As to running the pvr driver directly, I can't comment either, thanks to the above facts.
Stay on omapfb module + generic fbdev driver may be a good start if it is not too slow. I have not much time to try all the solutions.
Pandaboard ES ==============
So far, I was always under the impression that TI was a reasonably good citizen when it comes to keeping things open source and in a working state there. They have their code in upstream Linux and in upstream u-boot. Or do they?
Apparently to run Linux on the OMAP4460 SoC, you basically have to have VCC logic in the kernel which simply isn't upstream yet. So using an upstream kernel, you can basically not use the Pandaboard ES which does use that SoC. Isn't that insane? That board is publicly available for more than 1/2 year now!
I haven't tried yet, but at least u-boot support is supposed to be synchronized between the pandas by now. That's at least some good news.
What is this VCC logic? You are talking about power SoC: TWL6030 and/or TPS62361?
Pandaboard ==============
Our pandaboards ended up being reasonably unstable. Some times they were able to endure for weeks without crashing, some times only for hours. Thanks to some hints on IRC I finally updated u-boot to have updated voltage controls. Apparently there are 2 ways to do voltage control:
* statically in firmware * dynamically in the OS
You always want the static one in firmware to work right to get you going. But eventually it's nice to have voltage control in the OS as well, right? Especially when firmware's initial settings weren't all as optimal as you might expect, which isn't unheard of in the firmware world.
Well, turns out there is a Ubuntu kernel that has voltage control. Upstream doesn't. Again, the same problem as for the ES, just that it hit me on non-ES boards this time.
At least updating u-boot got me a stable board. Hooray.
ok.
Beagleboard ==============
This is my favorite. After updating u-boot to get panda boards stable, suddenly my beagle board wouldn't boot anymore. It'd crash randomly, some times just freeze seconds after the boot. The only variable here is the boot loader.
Does anyone even test upstream code? I mean, seriously. I tried u-boot 2012.04 and 2012.07-rc1 now with the same 3.4 kernel that worked just fine before on the older Linaro u-boot snapshot we had. Both show very similar crashes, so it's probably an issue that has never been addressed.
Not tested. Sorry.
So I went into the #beagle IRC channel to ask for help. Unlike the #pandaboard channel where people actually ended up being helpful, all I got was:
[3:13pm] <aholler> use 3.2.x [3:16pm] <aholler> everything above is broken on the beagleboard, at least here.
Are you kidding me? There's a user in the IRC channel who reports that upstream completely breaks for him. There wasn't even any objection to that comment, so I assume more people have had issues there.
I'm also quite sure that if I'm having issues with upstream u-boot + upstream kernel that this is not because of any special environment I might have. It's most likely because upstream is simply not working.
Is TI even supporting upstream sources or is it just a nuisance to get off the table so merging with Linaro and Ubuntu trees is easier? This is certainly not a way to foster a community and puts a lot of work on _our_ table which really should be in the SoC vendors' and specifically Linaro's hands.
I think TI cannot (do not want to?) test all upstream kernel releases and some updates might break things because people do not test enough before posting patches. Some patches for pandaboard breaks beagleboards because all is linked somewhere and the guy did not test on beagleboards, only on pandaboards...
Annoyed,
Alex
I understand that you are annoyed. I am also when I try a released upstream kernel which just does not work on the board. When I have a patch, I try to get it integrated upstream. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 12.07.2012, at 16:33, Guillaume Gardet wrote:
Hi,
Le 12/07/2012 16:09, Alexander Graf a écrit :
Hi Andrew, openSUSE fellows,
While trying to get a stable working base on at least a single SoC family (OMAP), I've stumbled over a bunch of issues, all of which are frustrating of their own, but are driving me insane in combination.
OMAP graphics ==============
There are 2 competing implementations for graphics on OMAP. Well, actually 3:
* omapfb (open source kernel+xorg, no xrandr, limited ) * omapdrm (open source kernel part, open source Xorg part, can piggy-bag on closed source driver for EXA) * pvr (closed source)
So what's the big deal with the situation as is? Well, omapfb is reasonably fast, but doesn't work in 3.4. It did work in 3.2. Also mode setting doesn't work with it. It also renders everything in software, so it doesn't use the graphics hardware.
In fact it works in 3.4 (or maybe 3.5?) with an additional module:
modprobe panel-tfp410 modprobe omapfb mode=dvi:1440x900MR-24@60
Maybe your talking about xorg driver which is NEON optimized? omapfb XOrg driver does not work (for me) but if you use the generic XOrg fbdev driver with omapfb module, it works. (But no idea about performances, since I only displayed an xterm).
Hrm. Interesting :).
Omapdrm is a nice future facing technology that is still in staging upstream, so I can overlook the fact that I needed a bunch of patches to actually make it work at all. It does its mode setting job reasonably well given the early state of development. Funnily enough it seems to not exploit the hardware completely on OMAP3, since omapfb can do 1080p there while omapdrm can not. Oh well. Also, Rob has been very helpful to get me going with the open source parts, so kudos to him!
The omapdrm Xorg driver however is crawlingly slow. It takes _seconds_ to move a window in xfce when running on 1080p. So we have an awesome kernel+user space bundle that could do most of the things users want (2d, easy mode setting), but is basically useless, since it's unbearable to work with. Has anyone ever tried to work with it?
The omapdrm driver has a special hack to piggy bag on the pvr driver when it's installed. So you can install the pvr driver and get accelerated graphics. Well, tough luck of you don't work for Canonical (or Linaro which is apparently Canonical in disguise), because they only release Ubuntu binary .debs that _link directly against Xorg. How could you possibly design binary drivers any worse? Every time the ABI changes in Xorg, the driver doesn't work. Different compiler flags potentially break it too.
Since openSUSE has an Xorg ABI version of 12 and current Ubuntu which the TI folks build against is 11, we're out of luck. No acceleration for us. But then again, acceleration would also only be there for OMAP4, because OMAP3 drivers are compiled for soft float only. What a mad world.
As to running the pvr driver directly, I can't comment either, thanks to the above facts.
Stay on omapfb module + generic fbdev driver may be a good start if it is not too slow. I have not much time to try all the solutions.
I'm moving everything towards omapdrm + fbdev atm. So far it's been the most solution with the best results for me.
Pandaboard ES ==============
So far, I was always under the impression that TI was a reasonably good citizen when it comes to keeping things open source and in a working state there. They have their code in upstream Linux and in upstream u-boot. Or do they?
Apparently to run Linux on the OMAP4460 SoC, you basically have to have VCC logic in the kernel which simply isn't upstream yet. So using an upstream kernel, you can basically not use the Pandaboard ES which does use that SoC. Isn't that insane? That board is publicly available for more than 1/2 year now!
I haven't tried yet, but at least u-boot support is supposed to be synchronized between the pandas by now. That's at least some good news.
What is this VCC logic? You are talking about power SoC: TWL6030 and/or TPS62361?
Yup.
Pandaboard ==============
Our pandaboards ended up being reasonably unstable. Some times they were able to endure for weeks without crashing, some times only for hours. Thanks to some hints on IRC I finally updated u-boot to have updated voltage controls. Apparently there are 2 ways to do voltage control:
* statically in firmware * dynamically in the OS
You always want the static one in firmware to work right to get you going. But eventually it's nice to have voltage control in the OS as well, right? Especially when firmware's initial settings weren't all as optimal as you might expect, which isn't unheard of in the firmware world.
Well, turns out there is a Ubuntu kernel that has voltage control. Upstream doesn't. Again, the same problem as for the ES, just that it hit me on non-ES boards this time.
At least updating u-boot got me a stable board. Hooray.
ok.
Beagleboard ==============
This is my favorite. After updating u-boot to get panda boards stable, suddenly my beagle board wouldn't boot anymore. It'd crash randomly, some times just freeze seconds after the boot. The only variable here is the boot loader.
Does anyone even test upstream code? I mean, seriously. I tried u-boot 2012.04 and 2012.07-rc1 now with the same 3.4 kernel that worked just fine before on the older Linaro u-boot snapshot we had. Both show very similar crashes, so it's probably an issue that has never been addressed.
Not tested. Sorry.
So I went into the #beagle IRC channel to ask for help. Unlike the #pandaboard channel where people actually ended up being helpful, all I got was:
[3:13pm] <aholler> use 3.2.x [3:16pm] <aholler> everything above is broken on the beagleboard, at least here.
Are you kidding me? There's a user in the IRC channel who reports that upstream completely breaks for him. There wasn't even any objection to that comment, so I assume more people have had issues there.
I'm also quite sure that if I'm having issues with upstream u-boot + upstream kernel that this is not because of any special environment I might have. It's most likely because upstream is simply not working.
Is TI even supporting upstream sources or is it just a nuisance to get off the table so merging with Linaro and Ubuntu trees is easier? This is certainly not a way to foster a community and puts a lot of work on _our_ table which really should be in the SoC vendors' and specifically Linaro's hands.
I think TI cannot (do not want to?) test all upstream kernel releases and some updates might break things because people do not test enough before posting patches. Some patches for pandaboard breaks beagleboards because all is linked somewhere and the guy did not test on beagleboards, only on pandaboards...
Annoyed,
Alex
I understand that you are annoyed. I am also when I try a released upstream kernel which just does not work on the board.
When I have a patch, I try to get it integrated upstream.
No worries, this rant was more towards Linaro and TI than you :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 12/07/2012 16:36, Alexander Graf a écrit :
On 12.07.2012, at 16:33, Guillaume Gardet wrote:
Hi,
Le 12/07/2012 16:09, Alexander Graf a écrit :
Hi Andrew, openSUSE fellows,
While trying to get a stable working base on at least a single SoC family (OMAP), I've stumbled over a bunch of issues, all of which are frustrating of their own, but are driving me insane in combination.
OMAP graphics ==============
There are 2 competing implementations for graphics on OMAP. Well, actually 3:
* omapfb (open source kernel+xorg, no xrandr, limited ) * omapdrm (open source kernel part, open source Xorg part, can piggy-bag on closed source driver for EXA) * pvr (closed source)
So what's the big deal with the situation as is? Well, omapfb is reasonably fast, but doesn't work in 3.4. It did work in 3.2. Also mode setting doesn't work with it. It also renders everything in software, so it doesn't use the graphics hardware. In fact it works in 3.4 (or maybe 3.5?) with an additional module:
modprobe panel-tfp410 modprobe omapfb mode=dvi:1440x900MR-24@60
Maybe your talking about xorg driver which is NEON optimized? omapfb XOrg driver does not work (for me) but if you use the generic XOrg fbdev driver with omapfb module, it works. (But no idea about performances, since I only displayed an xterm). Hrm. Interesting :).
Omapdrm is a nice future facing technology that is still in staging upstream, so I can overlook the fact that I needed a bunch of patches to actually make it work at all. It does its mode setting job reasonably well given the early state of development. Funnily enough it seems to not exploit the hardware completely on OMAP3, since omapfb can do 1080p there while omapdrm can not. Oh well. Also, Rob has been very helpful to get me going with the open source parts, so kudos to him!
The omapdrm Xorg driver however is crawlingly slow. It takes _seconds_ to move a window in xfce when running on 1080p. So we have an awesome kernel+user space bundle that could do most of the things users want (2d, easy mode setting), but is basically useless, since it's unbearable to work with. Has anyone ever tried to work with it?
The omapdrm driver has a special hack to piggy bag on the pvr driver when it's installed. So you can install the pvr driver and get accelerated graphics. Well, tough luck of you don't work for Canonical (or Linaro which is apparently Canonical in disguise), because they only release Ubuntu binary .debs that _link directly against Xorg. How could you possibly design binary drivers any worse? Every time the ABI changes in Xorg, the driver doesn't work. Different compiler flags potentially break it too.
Since openSUSE has an Xorg ABI version of 12 and current Ubuntu which the TI folks build against is 11, we're out of luck. No acceleration for us. But then again, acceleration would also only be there for OMAP4, because OMAP3 drivers are compiled for soft float only. What a mad world.
As to running the pvr driver directly, I can't comment either, thanks to the above facts. Stay on omapfb module + generic fbdev driver may be a good start if it is not too slow. I have not much time to try all the solutions. I'm moving everything towards omapdrm + fbdev atm. So far it's been the most solution with the best results for me.
Ok.
Pandaboard ES ==============
So far, I was always under the impression that TI was a reasonably good citizen when it comes to keeping things open source and in a working state there. They have their code in upstream Linux and in upstream u-boot. Or do they?
Apparently to run Linux on the OMAP4460 SoC, you basically have to have VCC logic in the kernel which simply isn't upstream yet. So using an upstream kernel, you can basically not use the Pandaboard ES which does use that SoC. Isn't that insane? That board is publicly available for more than 1/2 year now!
I haven't tried yet, but at least u-boot support is supposed to be synchronized between the pandas by now. That's at least some good news.
What is this VCC logic? You are talking about power SoC: TWL6030 and/or TPS62361? Yup.
We have TPS63360 as kernel module (which should support TPS6236x, so must be compatible with TPS62361?) but nothing about TWL6030 power (only PWM which is not enabled in openSUSE kernel, and CONFIG_TWL6030_USB as a kernel module).
Pandaboard ==============
Our pandaboards ended up being reasonably unstable. Some times they were able to endure for weeks without crashing, some times only for hours. Thanks to some hints on IRC I finally updated u-boot to have updated voltage controls. Apparently there are 2 ways to do voltage control:
* statically in firmware * dynamically in the OS
You always want the static one in firmware to work right to get you going. But eventually it's nice to have voltage control in the OS as well, right? Especially when firmware's initial settings weren't all as optimal as you might expect, which isn't unheard of in the firmware world.
Well, turns out there is a Ubuntu kernel that has voltage control. Upstream doesn't. Again, the same problem as for the ES, just that it hit me on non-ES boards this time.
At least updating u-boot got me a stable board. Hooray.
ok.
Beagleboard ==============
This is my favorite. After updating u-boot to get panda boards stable, suddenly my beagle board wouldn't boot anymore. It'd crash randomly, some times just freeze seconds after the boot. The only variable here is the boot loader.
Does anyone even test upstream code? I mean, seriously. I tried u-boot 2012.04 and 2012.07-rc1 now with the same 3.4 kernel that worked just fine before on the older Linaro u-boot snapshot we had. Both show very similar crashes, so it's probably an issue that has never been addressed.
Not tested. Sorry.
So I went into the #beagle IRC channel to ask for help. Unlike the #pandaboard channel where people actually ended up being helpful, all I got was:
[3:13pm] <aholler> use 3.2.x [3:16pm] <aholler> everything above is broken on the beagleboard, at least here.
Are you kidding me? There's a user in the IRC channel who reports that upstream completely breaks for him. There wasn't even any objection to that comment, so I assume more people have had issues there.
I'm also quite sure that if I'm having issues with upstream u-boot + upstream kernel that this is not because of any special environment I might have. It's most likely because upstream is simply not working.
Is TI even supporting upstream sources or is it just a nuisance to get off the table so merging with Linaro and Ubuntu trees is easier? This is certainly not a way to foster a community and puts a lot of work on _our_ table which really should be in the SoC vendors' and specifically Linaro's hands. I think TI cannot (do not want to?) test all upstream kernel releases and some updates might break things because people do not test enough before posting patches. Some patches for pandaboard breaks beagleboards because all is linked somewhere and the guy did not test on beagleboards, only on pandaboards...
Annoyed,
Alex
I understand that you are annoyed. I am also when I try a released upstream kernel which just does not work on the board.
When I have a patch, I try to get it integrated upstream. No worries, this rant was more towards Linaro and TI than you :).
Alex
Yes, I know. ;) Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 12/07/2012 16:59, Guillaume Gardet a écrit :
Le 12/07/2012 16:36, Alexander Graf a écrit :
On 12.07.2012, at 16:33, Guillaume Gardet wrote:
Hi,
Le 12/07/2012 16:09, Alexander Graf a écrit :
Hi Andrew, openSUSE fellows,
While trying to get a stable working base on at least a single SoC family (OMAP), I've stumbled over a bunch of issues, all of which are frustrating of their own, but are driving me insane in combination.
OMAP graphics ==============
There are 2 competing implementations for graphics on OMAP. Well, actually 3:
* omapfb (open source kernel+xorg, no xrandr, limited ) * omapdrm (open source kernel part, open source Xorg part, can piggy-bag on closed source driver for EXA) * pvr (closed source)
So what's the big deal with the situation as is? Well, omapfb is reasonably fast, but doesn't work in 3.4. It did work in 3.2. Also mode setting doesn't work with it. It also renders everything in software, so it doesn't use the graphics hardware. In fact it works in 3.4 (or maybe 3.5?) with an additional module:
modprobe panel-tfp410 modprobe omapfb mode=dvi:1440x900MR-24@60
Maybe your talking about xorg driver which is NEON optimized? omapfb XOrg driver does not work (for me) but if you use the generic XOrg fbdev driver with omapfb module, it works. (But no idea about performances, since I only displayed an xterm). Hrm. Interesting :).
Omapdrm is a nice future facing technology that is still in staging upstream, so I can overlook the fact that I needed a bunch of patches to actually make it work at all. It does its mode setting job reasonably well given the early state of development. Funnily enough it seems to not exploit the hardware completely on OMAP3, since omapfb can do 1080p there while omapdrm can not. Oh well. Also, Rob has been very helpful to get me going with the open source parts, so kudos to him!
The omapdrm Xorg driver however is crawlingly slow. It takes _seconds_ to move a window in xfce when running on 1080p. So we have an awesome kernel+user space bundle that could do most of the things users want (2d, easy mode setting), but is basically useless, since it's unbearable to work with. Has anyone ever tried to work with it?
The omapdrm driver has a special hack to piggy bag on the pvr driver when it's installed. So you can install the pvr driver and get accelerated graphics. Well, tough luck of you don't work for Canonical (or Linaro which is apparently Canonical in disguise), because they only release Ubuntu binary .debs that _link directly against Xorg. How could you possibly design binary drivers any worse? Every time the ABI changes in Xorg, the driver doesn't work. Different compiler flags potentially break it too.
Since openSUSE has an Xorg ABI version of 12 and current Ubuntu which the TI folks build against is 11, we're out of luck. No acceleration for us. But then again, acceleration would also only be there for OMAP4, because OMAP3 drivers are compiled for soft float only. What a mad world.
As to running the pvr driver directly, I can't comment either, thanks to the above facts. Stay on omapfb module + generic fbdev driver may be a good start if it is not too slow. I have not much time to try all the solutions. I'm moving everything towards omapdrm + fbdev atm. So far it's been the most solution with the best results for me.
Ok.
Pandaboard ES ==============
So far, I was always under the impression that TI was a reasonably good citizen when it comes to keeping things open source and in a working state there. They have their code in upstream Linux and in upstream u-boot. Or do they?
Apparently to run Linux on the OMAP4460 SoC, you basically have to have VCC logic in the kernel which simply isn't upstream yet. So using an upstream kernel, you can basically not use the Pandaboard ES which does use that SoC. Isn't that insane? That board is publicly available for more than 1/2 year now!
I haven't tried yet, but at least u-boot support is supposed to be synchronized between the pandas by now. That's at least some good news.
What is this VCC logic? You are talking about power SoC: TWL6030 and/or TPS62361? Yup.
We have TPS63360 as kernel module (which should support TPS6236x, so must be compatible with TPS62361?) but nothing about TWL6030 power (only PWM which is not enabled in openSUSE kernel, and CONFIG_TWL6030_USB as a kernel module).
Oh, just noticed that CONFIG_REGULATOR_TWL4030 says it supports: TI TWL4030/TWL5030/TWL6030/TPS659x0 PMIC (Checked in 3.5-rc6) Guillaume
Pandaboard ==============
Our pandaboards ended up being reasonably unstable. Some times they were able to endure for weeks without crashing, some times only for hours. Thanks to some hints on IRC I finally updated u-boot to have updated voltage controls. Apparently there are 2 ways to do voltage control:
* statically in firmware * dynamically in the OS
You always want the static one in firmware to work right to get you going. But eventually it's nice to have voltage control in the OS as well, right? Especially when firmware's initial settings weren't all as optimal as you might expect, which isn't unheard of in the firmware world.
Well, turns out there is a Ubuntu kernel that has voltage control. Upstream doesn't. Again, the same problem as for the ES, just that it hit me on non-ES boards this time.
At least updating u-boot got me a stable board. Hooray.
ok.
Beagleboard ==============
This is my favorite. After updating u-boot to get panda boards stable, suddenly my beagle board wouldn't boot anymore. It'd crash randomly, some times just freeze seconds after the boot. The only variable here is the boot loader.
Does anyone even test upstream code? I mean, seriously. I tried u-boot 2012.04 and 2012.07-rc1 now with the same 3.4 kernel that worked just fine before on the older Linaro u-boot snapshot we had. Both show very similar crashes, so it's probably an issue that has never been addressed.
Not tested. Sorry.
So I went into the #beagle IRC channel to ask for help. Unlike the #pandaboard channel where people actually ended up being helpful, all I got was:
[3:13pm] <aholler> use 3.2.x [3:16pm] <aholler> everything above is broken on the beagleboard, at least here.
Are you kidding me? There's a user in the IRC channel who reports that upstream completely breaks for him. There wasn't even any objection to that comment, so I assume more people have had issues there.
I'm also quite sure that if I'm having issues with upstream u-boot + upstream kernel that this is not because of any special environment I might have. It's most likely because upstream is simply not working.
Is TI even supporting upstream sources or is it just a nuisance to get off the table so merging with Linaro and Ubuntu trees is easier? This is certainly not a way to foster a community and puts a lot of work on _our_ table which really should be in the SoC vendors' and specifically Linaro's hands. I think TI cannot (do not want to?) test all upstream kernel releases and some updates might break things because people do not test enough before posting patches. Some patches for pandaboard breaks beagleboards because all is linked somewhere and the guy did not test on beagleboards, only on pandaboards...
Annoyed,
Alex
I understand that you are annoyed. I am also when I try a released upstream kernel which just does not work on the board.
When I have a patch, I try to get it integrated upstream. No worries, this rant was more towards Linaro and TI than you :).
Alex
Yes, I know. ;)
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 12.07.2012, at 16:09, Alexander Graf wrote:
Hi Andrew, openSUSE fellows,
While trying to get a stable working base on at least a single SoC family (OMAP), I've stumbled over a bunch of issues, all of which are frustrating of their own, but are driving me insane in combination.
[...]
Beagleboard ==============
This is my favorite. After updating u-boot to get panda boards stable, suddenly my beagle board wouldn't boot anymore. It'd crash randomly, some times just freeze seconds after the boot. The only variable here is the boot loader.
Ok, debugged this down a bit further. The following gets me going: diff --git a/config/armv7hl/omap2plus b/config/armv7hl/omap2plus index f831dc4..5a605de 100644 --- a/config/armv7hl/omap2plus +++ b/config/armv7hl/omap2plus @@ -572,7 +572,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # ARM CPU frequency scaling drivers # -CONFIG_ARM_OMAP2PLUS_CPUFREQ=y +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set # CONFIG_ARM_EXYNOS4210_CPUFREQ is not set # CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set # CONFIG_ARM_EXYNOS5250_CPUFREQ is not set @@ -587,9 +587,8 @@ CONFIG_CPU_IDLE_GOV_MENU=y # # At least one emulation must be selected # -CONFIG_FPE_NWFPE=y -# CONFIG_FPE_NWFPE_XP is not set -# CONFIG_FPE_FASTFPE is not set +# CONFIG_FPE_NWFPE is not set +CONFIG_FPE_FASTFPE=y CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_NEON=y What I did is I basically went from a working base (f17) and tried to replace as many options in our omap2 kernel as reasonable with the ones from there. This is what got me rolling. I don't think the floating point emulation is really the culprit here. I'd much rather guess on cpufreq. For some reason cpufreq is broken with upstream u-boot, but did work with the old x-loader+linaro u-boot combo. I'm running out of time I can spend on this. If someone else (preferably Linaro / TI) could take a look, I'd greatly appreciate it. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (2)
-
Alexander Graf -
Guillaume Gardet