Sent from Samsung MobileAndy Green andy.green@linaro.org wrote:On 03/16/2012 10:46 PM, Somebody in the thread at some point said:
If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
We also have what's currently only working on
I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module.
Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then.
1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor "syslink".
If you check out tilt-3.1 branch from our repo that has working syslink + tiler pieces needed by the mm decode pieces in Ubuntu and will build against SGX dkms.
-Andy
Mertsas,
On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas) mertsas@cisco.com wrote:
Sent from Samsung Mobile
Andy Green andy.green@linaro.org wrote: On 03/16/2012 10:46 PM, Somebody in the thread at some point said:
If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
We also have what's currently only working on
I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module.
Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then.
1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor "syslink".
If you check out tilt-3.1 branch from our repo that has working syslink
- tiler pieces needed by the mm decode pieces in Ubuntu and will build
against SGX dkms.
I seemed to have missed some conversation here. Just wanted to check if you still have trouble getting a kernel with rpmsg and pvr? I am not aware of the pvr part of things but for the rpmsg stuff, like Andy mentioned the one tilt has is a different from the up-streamed one. You will get a lot more features in the tilt version of it. The flip side being, it is dependent on ion. Can you elaborate what you are trying to achieve with rpmsg? You definitely need tiler driver support too to get h264 decoder working. Personally, I think , you are better off moving to rpmsg, as you can expect more support in future on this. I might not be aware of all the minute details but could help you out on the rpmsg part.
-Andy
-- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106%C2%A0 - http://twitter.com/#%21/linaroorg - http://linaro.org/linaro-blog
So what you are basically saying is forget rpmsg for the time being? Do you know if gst-ducati works with syslink then?
thank you so much for your help so far.
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 03/17/2012 04:14 AM, Somebody in the thread at some point said:
Mertsas,
On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas) mertsas@cisco.com wrote:
Sent from Samsung Mobile
Andy Green andy.green@linaro.org wrote: On 03/16/2012 10:46 PM, Somebody in the thread at some point said:
If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
We also have what's currently only working on
I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module.
Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then.
1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor "syslink".
If you check out tilt-3.1 branch from our repo that has working syslink
- tiler pieces needed by the mm decode pieces in Ubuntu and will build
against SGX dkms.
I seemed to have missed some conversation here. Just wanted to check if you still have trouble getting a kernel with rpmsg and pvr? I am not aware of the pvr part of things but for the rpmsg stuff, like Andy mentioned the one tilt has is a different from the up-streamed one. You will get a lot more features in the tilt version of it. The flip side being, it is dependent on ion. Can you elaborate what you are trying to achieve with rpmsg? You definitely need tiler driver support too to get h264 decoder working. Personally, I think , you are better off moving to rpmsg, as you can expect more support in future on this. I might not be aware of all the minute details but could help you out on the rpmsg part.
Agreed rpmsg has deprecated syslink going on, and medium or long term planning will need to be around that.
However for Ubuntu, there's not quite yet anything rpmsg-based that's workable to give him mm decode (it seems to be that he's interested in) that will provide userland pieces he can have as a normal mortal as well.
Rob Clark is working on something that should bear fruit soon, Nice guys will provide matching Ubuntu pieces and TILT will integrate it into our tracking.
Until then tilt-3.1 + Ubuntu packages already there seems the best choice to getting something known to work end-end quickly. Since it integrates to gstreamer already when he upgrades to rpmsg-based solution (userland too) it should hopefully be transparent.
-Andy
On 03/17/12 01:13, Andy Green wrote:
On 03/17/2012 04:14 AM, Somebody in the thread at some point said:
Mertsas,
On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas) mertsas@cisco.com wrote:
Sent from Samsung Mobile
Andy Green andy.green@linaro.org wrote: On 03/16/2012 10:46 PM, Somebody in the thread at some point said:
If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
We also have what's currently only working on
I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module.
Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then.
1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor "syslink".
If you check out tilt-3.1 branch from our repo that has working syslink
- tiler pieces needed by the mm decode pieces in Ubuntu and will build
against SGX dkms.
I seemed to have missed some conversation here. Just wanted to check if you still have trouble getting a kernel with rpmsg and pvr? I am not aware of the pvr part of things but for the rpmsg stuff, like Andy mentioned the one tilt has is a different from the up-streamed one. You will get a lot more features in the tilt version of it. The flip side being, it is dependent on ion. Can you elaborate what you are trying to achieve with rpmsg? You definitely need tiler driver support too to get h264 decoder working. Personally, I think , you are better off moving to rpmsg, as you can expect more support in future on this. I might not be aware of all the minute details but could help you out on the rpmsg part.
Agreed rpmsg has deprecated syslink going on, and medium or long term planning will need to be around that.
However for Ubuntu, there's not quite yet anything rpmsg-based that's workable to give him mm decode (it seems to be that he's interested in) that will provide userland pieces he can have as a normal mortal as well.
Rob Clark is working on something that should bear fruit soon, Nice guys will provide matching Ubuntu pieces and TILT will integrate it into our tracking.
Until then tilt-3.1 + Ubuntu packages already there seems the best choice to getting something known to work end-end quickly. Since it integrates to gstreamer already when he upgrades to rpmsg-based solution (userland too) it should hopefully be transparent.
-Andy
The reason we want rpmsg is to get h264 endcoding and decoding using gstreamer elements. I'm not sure if gst-ducati works with syslink as well? Andy is right that it is mm decode/encode I am interested in.
So if I have understood you right: For the time being, I should use tilt-3.1 with syslink and gst-ducati (or some other gst element?) to get mm h264 encoding/decoding working on the omap. And when rpmsg is in a stable upstream/tilt kernel, I can switch to that and still use gst-ducati?
- Martin
Martin,
On Mon, Mar 19, 2012 at 8:14 AM, Martin Ertsås mertsas@cisco.com wrote:
The reason we want rpmsg is to get h264 endcoding and decoding using gstreamer elements. I'm not sure if gst-ducati works with syslink as well? Andy is right that it is mm decode/encode I am interested in.
So if I have understood you right: For the time being, I should use tilt-3.1 with syslink and gst-ducati (or some other gst element?) to get mm h264 encoding/decoding working on the omap. And when rpmsg is in a stable upstream/tilt kernel, I can switch to that and still use gst-ducati?
at the current time, as andy said if you want a workable GST with decoders and encoders using gst-ducat, the only solution is 3.1 kernel with syslink2.0. I am not entirely sure about the exact status of Linaro releases with this regards (rsavelti can comment on that), but for sure if you use a plain 'ubuntu 11.10' with the TI OMAP 'release' PPA packages installed (see http://groups.google.com/group/pandaboard/browse_thread/thread/6aa2cbe99c369...) then you will get such a system. PVR drivers are working for UI, and PVR is used as well for video rendering (through GST pvrvideosink element). With all these packages installed, you can use gst-launch or any gst based application, and video codecs will be h/w accelerated through gst-ducati.
we are *currently* working on the next gen GST stack which will be based on 3.3+ kernel with rpmsg (aka syslink3) and a new graphics architecture based on our new omapdrm GEM based driver. This is work-in-progress at the moment, and we are publishing our 'experimental' work in our OMAP 'trunk' PPA (~tiomap-dev/omap-trunk in LP). At this point of time, we have updated libDCE , kernel, and firmware and we have some basic video decode working with this new stack, but 1) we haven't started the GST updates, 2) it's not recommended if you want something that 'just works'. Support for encoders, and support at GST level (gst-ducati) will be available in the coming weeks.
On 03/19/12 11:22, Dechesne, Nicolas wrote:
Martin,
On Mon, Mar 19, 2012 at 8:14 AM, Martin Ertsås <mertsas@cisco.com mailto:mertsas@cisco.com> wrote:
The reason we want rpmsg is to get h264 endcoding and decoding using gstreamer elements. I'm not sure if gst-ducati works with syslink as well? Andy is right that it is mm decode/encode I am interested in. So if I have understood you right: For the time being, I should use tilt-3.1 with syslink and gst-ducati (or some other gst element?) to get mm h264 encoding/decoding working on the omap. And when rpmsg is in a stable upstream/tilt kernel, I can switch to that and still use gst-ducati?at the current time, as andy said if you want a workable GST with decoders and encoders using gst-ducat, the only solution is 3.1 kernel with syslink2.0. I am not entirely sure about the exact status of Linaro releases with this regards (rsavelti can comment on that), but for sure if you use a plain 'ubuntu 11.10' with the TI OMAP 'release' PPA packages installed (see http://groups.google.com/group/pandaboard/browse_thread/thread/6aa2cbe99c369...) then you will get such a system. PVR drivers are working for UI, and PVR is used as well for video rendering (through GST pvrvideosink element). With all these packages installed, you can use gst-launch or any gst based application, and video codecs will be h/w accelerated through gst-ducati.
we are *currently* working on the next gen GST stack which will be based on 3.3+ kernel with rpmsg (aka syslink3) and a new graphics architecture based on our new omapdrm GEM based driver. This is work-in-progress at the moment, and we are publishing our 'experimental' work in our OMAP 'trunk' PPA (~tiomap-dev/omap-trunk in LP). At this point of time, we have updated libDCE , kernel, and firmware and we have some basic video decode working with this new stack, but 1) we haven't started the GST updates, 2) it's not recommended if you want something that 'just works'. Support for encoders, and support at GST level (gst-ducati) will be available in the coming weeks.
Ok. Thank you so much for all your help, it have been really helpful. Will work with linux-3.1 and syslink 2.0 then. Really appreciate the response.
- Martin
-
Andy Green -
C.A, Subramaniam -
Dechesne, Nicolas -
Martin Ertsas (mertsas) -
Martin Ertsås