Gstreamer-ti


Ugh, a memory hole, that could easily destabilize the firmware. I'd much prefer if dsplink could be configured to use end or RAM instead, but I understand this can be very difficult thing to do with all that TI stuff.
 
Well, if it works, back to the old 'boot menu' for starting up with key down, so that it could be different boot param files .. like boot1.txt and boot2.txct or something, so could have a memory hole or not? with the hole, could get tight for running apps of course.. or do you think it would get in the way in more nefarious ways?


jeff
 
We played our first video, a xvid with mp3 avi.


For now, just the video part was using DSP, it needs tweaking with the memory.


When we want to only play sound, we have a problem with alsa :

ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: Could not get/set settings from/on resource.


Additional debug info:


gstalsasink.c(520): set_hwparams (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0:


Unable to set hw params for playback: Invalid argument

Any idea ?
 
That error does kinda ring a bell... Link to the source file where that function fails? Iirc, the ALSA-setup on firmware is very picky about how you set it up, I think there was a simlar issue with QtSpotify.
 
We played our first video, a xvid with mp3 avi.


For now, just the video part was using DSP, it needs tweaking with the memory.


When we want to only play sound, we have a problem with alsa :

ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: Could not get/set settings from/on resource.


Additional debug info:


gstalsasink.c(520): set_hwparams (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0:


Unable to set hw params for playback: Invalid argument

Any idea ?

Sorry no idea, but just wondering if you tried using osssink instead.
 
Yes osssink worked. Alsasink too when you overwrite the default plugin.


We have now sound files working with totem : MP3, AAC.
 
Last edited by a moderator:
There is no DSP codec for vorbis.


EDIT : neither for flac. But gstreamer can read these files, just not using the DSP.
 
Last edited by a moderator:
Could you give us the boot parameters for the kernel you used?


Did you have to patch the kernel at all, or did that work out without patching?


We're thinking of including DSP RAM reservation with the next Hotfix, so it would be great to find that out :)
 
For now the boot parameters are :


setenv bootargs ubi.mtd=4 ubi.mtd=3 root=ubi0:rootfs rw omapfb.mode="lcd:800x480-16@65" vram=12M omapfb.vram="1:4M,2:4M,3:4M" omapdss.def_disp=lcd mem=99M@0x80000000 mem=128M@0x88000000


ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr};


But it is used for a boot.txt located in a sd card which boot the nand, as i don't know how to change for a direct boot for nand.


For now, a patch is needed for the kernel to allow a memory hole, as we didn't try to allocate the memory at the end.


I couldn't test much and my priority was to have a DSP working with these initial usual conditions.
 
setenv bootargs ubi.mtd=4 ubi.mtd=3 root=ubi0:rootfs rw omapfb.mode="lcd:800x480-16@65" vram=12M omapfb.vram="1:4M,2:4M,3:4M" omapdss.def_disp=lcd mem=99M@0x80000000 mem=128M@0x88000000


ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr};

Does this mean that the DSP is using the memory range 0x86300000 ~ 0x87999999? Can I ask why the DSP needs to have a chunk of memory in the middle of main memory rather than at the beginning or the end? Also, are there any implications for the performance of other programs or for memory management? I guess main memory is being fragmented, but there aren't many applications that would need a huge chunk of contiguous memory, right?
 
mem=99M@0x80000000 mem=128M@0x88000000
This looks suspicious - does it really use 29 MB or RAM? The Gumstix article you linked before suggests using "mem=96M@0x80000000 mem=128M@0x88000000" instead.

For now, a patch is needed for the kernel to allow a memory hole, as we didn't try to allocate the memory at the end.
Could you share that patch?


Could you also point me to the recipes you have used? These seem to be newer than in openpandora.org git.

Does this mean that the DSP is using the memory range 0x86300000 ~ 0x87999999? Can I ask why the DSP needs to have a chunk of memory in the middle of main memory rather than at the beginning or the end? Also, are there any implications for the performance of other programs or for memory management? I guess main memory is being fragmented, but there aren't many applications that would need a huge chunk of contiguous memory, right?
AFAIK they just have physical addresses hardcoded in the driver, so we have to clear Linux away from there. Some messed up stuff, I'm also worried that hole thing may cause trouble.
 
This looks suspicious - does it really use 29 MB or RAM? The Gumstix article you linked before suggests using "mem=96M@0x80000000 mem=128M@0x88000000" instead.

I used 99M@0x80000000 because it was generally the examples given on the net. Maybe it's hardcoded somewhere, i can't remember.


Like i said, i wanted to try with the most used parameters before optimize all these values.

Could you share that patch?


Could you also point me to the recipes you have used? These seem to be newer than in openpandora.org git.

I adapted this patch for the 2.6.27 kernel.


I used the recipes from http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-ti.

linux_linux-omap-pm-2.6.27_arch-has-holes.diff.txt
 

Attachments

  • linux_linux-omap-pm-2.6.27_arch-has-holes.diff.txt
    7.9 KB · Views: 241
Thanks for the info, I'll see if this can be integrated in firmware (would prefer tracking down proper authorship of that memhole patch, I think it was Russell King).
 
Ditto.


Get that dsp memory allocated one end of the available ram, and we're looking good!
 
Memory hole patch is now merged to firmware kernel (as it's part of mainline and newer kernels have it anyway). I've tried doing some things with the hole set up on pandora and it seemed to work ok.


dsplink modules and DSP blob will be included too (was surprised newest OE recipes built on our old OE, just with a few hacks). That's ti-dsplink-module, ti-cmem-module, ti-lpm-module, ti-sdma-module, ti-codecs-omap3530-server.


What's left is gstreamer configuration and gstreamer itself (unless there is something else, I've never had it working myself), we won't be adding it to firmware because pandora should not play media by default (patent issues). Hopefully someone can make a guide or maybe cook a pnd.
 

Similar threads

Back
Top