Re: Linux kernel with rpmsg and possibility for compiling powervr drivers

2012-03-16 Thread C.A, Subramaniam
Mertsas,

On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas)
mert...@cisco.com wrote:





 Sent from Samsung Mobile

 Andy Green andy.gr...@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;a=shortlog;h=refs/heads/tilt-android-tracking

 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  -
 http://twitter.com/#!/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




-- 

Thank you and Regards
Subbu

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Linaro embedded Linux distro?

2012-02-20 Thread C.A, Subramaniam
On Mon, Feb 20, 2012 at 12:40 PM, Wookey woo...@wookware.org wrote:
 +++ Fathi Boudra [2012-02-20 09:34 -0800]:
 Hi

 On 20 February 2012 08:42, Zach Pfeffer zach.pfef...@linaro.org wrote:
  During ELC a few people asked me if Linaro had something bigger than
  nano and smaller than Ubuntu that they could use to build stuff. Of
  course I said Android, but a lot of people actually want a regular
  Linux platform where they can easily recompile what they need to hack
  on, add their own libs and scripts and generally work in an embedded,
  cross build way.

 We provide 6 Ubuntu based images that we can consider as profiles.
 It's easy to customize or build your own image that will better fit
 your use case or requirements.

 In our case, we use live-build [1] which allow to put your
 customization on top of our images [2] or even from scratch.
 Tom has written a wiki page [3]. The page needs some update (I'm
 willing to help) to add upcoming armhf images and latest live-build
 with cross support.

 We should be clear what is meant by 'cross-support' in this context.
 This is cross image-creation, not cross-building. If the
 _cross-building_ part of this is important to punters then we don't
 yet have a very good answer (not everything in the developer image
 will crossbuild directly from the archive yet), although we are
 getting there as multiarch, and sbuild-with-cross-support mature.

 But in general most people who think they want to cross-build
 everything are wrong :-) In fact they really just want to cross-build
 a few things that they build over and over, and getting most of the
 system as binaries is just fine. I'm interested to hear of
 counter-examples (the main one being complier improvements/options
 which one wants to apply across the board).

 Another thing to note is that if the people asking for 'embedded
 linaro linux' want smaller images we could run our packages through
 the emdebian-grip tools to get smaller packages/images. (typically
 2/3rds size). I'm not sure anyone has got round to trying this, not
 least because now everyone has SD-card based systems disk space mostly
 stopped being an issue. People using 'proper flash' still care.

 Wookey
Would there be a buildroot like setup? Like Wookey mentioned size does matter.

 --
 Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
 http://wookware.org/

 ___
 linaro-dev mailing list
 linaro-dev@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-dev



-- 

Thank you and Regards
Subbu

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Linaro embedded Linux distro?

2012-02-20 Thread C.A, Subramaniam
On Mon, Feb 20, 2012 at 1:55 PM, Wookey woo...@wookware.org wrote:
 +++ C.A, Subramaniam [2012-02-20 13:32 -0600]:
 On Mon, Feb 20, 2012 at 12:40 PM, Wookey woo...@wookware.org wrote:
 Would there be a buildroot like setup? Like Wookey mentioned size does 
 matter.

 No, if you want to use buildroot, use buildroot (or openbricks, or
 yocto, or OE). Debian/Ubuntu are binary distros and there is no mileage in
 trying to occupy that space when other distros already do it well.

 Making it relatively painless to rebuild or cross-rebuild your
 package-set debian-style is a useful goal, but not supporting loads of
 different package config options - that is something a source-based
 distro can do so much better.

 We do plan to support minimal builds for bootstrapping purposes which
 might be useful in this regard, but that's not really what it's for.

Well minimal is all I care... not buildroot. But I would expect it to
be  20M in size. Does that make sense or am i speaking gibberish
:-) ?

 Wookey
 --
 Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
 http://wookware.org/

 ___
 linaro-dev mailing list
 linaro-dev@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-dev



-- 

Thank you and Regards
Subbu

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev