GTA04 SoC/CPU and LCD size
lists4pghanghas at gmail.com
Tue Oct 7 16:13:49 CEST 2008
On Tue, Oct 7, 2008 at 6:02 PM, thomasg <thomas at gstaedtner.net> wrote:
> On Tue, Oct 7, 2008 at 1:53 PM, Andy Green <andy at openmoko.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> > No -- I mean that GTA02 has "risc coprocessors" too like the OMAP
>> > discussed here, they are not automatically any benefit unless they are
>> > actually deployed to do something was the point. I don't think it's any
>> > secret we likely won't be using the Glamo again.
>> > If the DSP is deployed in vendor or third party provided reference codec
>> > implementations like WMV9, there are patent and copyright issues going
>> > to be all over them from our POV.
>> >> for this there is another solution. No vendor provides support for
>> >> patented codecs and stuff in
>> >> Linux Market but anyone can install it from huge no of community repos
>> >> available. And when TI
>> Yes, but these implementations run on normal CPU. Stuff may or may not
>> get ported to magic DSPs; just saying that first, availability of magic
>> DSP vendor or third party "IP" reference codecs is not meaningful for
>> us, and second, it's likely that proprietary DSP coprocessor concept
>> found only on one family will suffer from at least the hurdle of effort
>> needed to make special Free implementations.
>> >> I suggest that we should be active on the beagleboard mailing list,
>> >> strongly backed by TI, to have an informed view on this
>> > Of source the situation with s3c6410 3D stuff is unclear right now too.
>> >> situation about any 3d core always remains fuzzy. Complete freedom in
>> >> this area will come only with GPLed graphics core :-)
>> Yes somehow these products are at the intersection of the remaining
>> closed flashpoints, GSM, WLAN firmware, blobs in GPS we dodged, 3D...
>> - -Andy
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>> -----END PGP SIGNATURE-----
> Like I said, there will be (or already is, didn't do any further research a
> FOSS driver for the DSP in the OMAP3. After all it doesn't look that magic,
> it just is pretty damn fast.
> The beagleboard people are on it and already using it and it seems to do a
> great job in decoding videos and other things.
> It also seems that the beagleboard guys are not only in touch with TI but
> also that TI is heavily included in the development of this platform and
> highly interested in the open source platform.
> Of course that wont help with the PowerVR issue, because that's a 3rd party
> product (the only relevant one in OMAP3 afaik).
> But however, there is omapfb for unaccelerated graphics output.
> Maybe some of the beagleboard developers are reading this list, too - it
> would be great if they could enlighten us.
As I already mentioned for PowerVR also, there will be a open source
kernel driver with a binary user space
you can have a look at the following portion from the url
OMAP3530 used on BeagleBoard contains a graphics accelerator (SGX)
based on the SGX core from Imagination Technologies. PowerVR SGX530 is
a new generation of programmable PowerVR graphics and video IP cores.
Only the kernel portions of Linux drivers will be open source. The
PowerVR folks will provide binary user-space libraries. Using the
EMail contact at TIs Mobile Gaming Developers page there are Linux
v2.6 OMAP3430 SDKs for OMAP3 Zoom and SDP supporting OpenGL ES v2.0,
OpenGL ES v1.1 and OpenVG 1.0 available.
This is the maximum you will be available to get from any vendor
without signing a NDA.
I still dont understand openmoko is so keen on Samsung. Is it giving
them some platform maturity advantage as all their
products till now had Samsung SoC. There is no doubt OMAP3 is better.
And I am sure that TI would have contacted them
and offered all the help because they are seemingly contacting and
endorsing every open source project out there.
More information about the hardware