From: Howard Chu <hyc@symas.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: TI DSP updates
Date: Thu, 03 Sep 2009 03:24:25 -0700 [thread overview]
Message-ID: <4A9F9959.5010408@symas.com> (raw)
In-Reply-To: <mailman.7.1251972002.477.openembedded-devel@lists.openembedded.org>
> Date: Thu, 03 Sep 2009 10:00:37 +0200
> From: Koen Kooi <k.kooi@student.utwente.nl>
> On 03-09-09 04:17, Howard Chu wrote:
>> > These are the changes I made to use the latest Codec engine, DSP
>> > modules, etc. for OMAP3530 to build. Tested and working with
>> > gstreamer-ti on an Always Innovating Touch Book with linux-omap_2.6.29
>> > kernel / Angstrom...
> Thank you for your work on this! Your work does seem to be based on an
> outdated OE checkout, could you try to rebase it on the current
> org.openembedded.dev branch?
Ah, I thought I had rebased with HEAD just before I posted. But sure, I'll try
updating again.
>> > To get a working codec server on the Touch Book, which has 256MB of RAM,
>> > I had to modify the default server config:
> To move the memorymap more stuff has to get changed, but there's an
> easier way that also works with 512MiB and 1024MiB RAM:
>
> put 'mem=80M@0x80000000 mem=128M@0x88000000' in your bootargs and make
> sure your kernel has the arch-has-holes.diff applied to make that
> memoryhole work.
Interesting. I guess that's more future-proof but currently no OMAP3530 can
have more than 256MB of RAM... Also, not sure what else you're referring to
that needs to be changed. The dsplink driver doesn't care. The codec server
only needs to know where the end of memory is, and it arranges the rest of the
map itself. It chose to use only 29M of memory, and I can't complain about
that, better than eating up 40M. Here's the datasheet it generated for this
codec server:
http://highlandsun.com/hyc/cs.x64P.DataSheet.html
The gstreamer ticodecplugin just needs to be pointed at that server.tcf file
to use the same config. If I'm missing the point you're making, please explain
again, thanks.
If I had known about that memory hole trick I would probably not have bothered
rebuilding any of this, could've just downloaded a new codec combo and run
with it. Live and learn...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
next parent reply other threads:[~2009-09-03 10:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.7.1251972002.477.openembedded-devel@lists.openembedded.org>
2009-09-03 10:24 ` Howard Chu [this message]
2009-09-03 2:17 TI DSP updates Howard Chu
2009-09-03 8:00 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A9F9959.5010408@symas.com \
--to=hyc@symas.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.