Darkknight512
Active Member
BTW: I talked with TI today.
We are free to include these codecs in the community codec pack
Sounds great!
Gstreamer-ti
- Thread starter klaxonn
- Start date
Sounds great!
notaz
Certified Guru
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.
skeezix
Internal Development
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
jeff
klaxonn
Member
- Joined
- Feb 25, 2011
- Messages
- 92
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 :
Any idea ?
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
Additional debug info:
gstalsasink.c(520): set_hwparams (): /GstPipeline
Unable to set hw params for playback: Invalid argument
Any idea ?
slaeshjag
¯\_(ツ)_/¯
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.
captain_coconut
Member
- Joined
- Oct 9, 2008
- Messages
- 132
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
Additional debug info:
gstalsasink.c(520): set_hwparams (): /GstPipeline
Unable to set hw params for playback: Invalid argument
Any idea ?
Sorry no idea, but just wondering if you tried using osssink instead.
slaeshjag
¯\_(ツ)_/¯
What about vorbis and FLAC?
Last edited by a moderator:
captain_coconut
Member
- Joined
- Oct 9, 2008
- Messages
- 132
Awesome, great stuff. I'm excited to hear what you guys did to get this all working.
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
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
klaxonn
Member
- Joined
- Feb 25, 2011
- Messages
- 92
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};
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.
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?
notaz
Certified Guru
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.
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.
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.
klaxonn
Member
- Joined
- Feb 25, 2011
- Messages
- 92
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.
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
notaz
Certified Guru
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).
klaxonn
Member
- Joined
- Feb 25, 2011
- Messages
- 92
Yes, i think you're right, i had this page in my bookmark : http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15255.html
milkshake
Advanced Member
any updates on this ?
notaz
Certified Guru
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.
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.
