Not really, as they usually use SD creator .pnd from the repo.Users that have their own boot scripts hopefully know what they are doing and would need to add the required options themselves. Since they've already figured out how to use custom boot scripts in the first place, that should not be an issue (it's a very simple modification, after all).
We really don't want that, this would add unwanted dependencies to your module and perhaps firmware version and create unnecessary obstacle for backward compatibility, should we want to do it on some future device.These 4 MBytes would not be lost after all: If the DSP is not used, the memory could still be used for applications, although there would be some special handling required (an extra mmap() call in the app., I could add that to the kernel module so the app. does not require root privileges).
I've looked at it too and it seems to be possible with some board support code changes in kernel itself. Basically board code declares CMA region at fixed memory address during early boot and your module can then request it by passing proper dev pointer when it loads. Your module would need to be rewritten as platform driver though, this is for dev pointer magic to work.After reading that you might have seen something that would allow for such a fixed-address mapping, I took another look at "dma-mapping.h" and "dma-coherent.c". There is a function called "dma_declare_coherent_memory()" which looks like it could be used for this purpose. I tried it out, but it always results in a kernel oops (17) / "kernel NULL pointer dereference at virtual address 00000114".
Before going further on with this I think you should understand that the DSP on Pandora doesn't even do floating point, while the CPU at least has a slow scalar FPU and a fast vector one (but not totally IEEE-754 compliant)How much does the overhead "cost" to execute an operation on the dsp? A floating point operation costs around 300 lines of C code in qemu (not sure how many instructions this means). Is it ok to let the dsp execute one floating point instruction? Or do we need to catch lets say 1000 instructions and give a pointer to the data struct (opcode param1 param2) to the dsp?
It's like you say, those emulators are fast enough as is on Pandora and not really worth the complexity of moving tasks to the DSP for. Even from a power consumption point of view I'm skeptical that you'll use less power moving a little bit of the runtime to the DSP - it may result in saving a little bit of clock and voltage on the CPU end but just having to keep the DSP on at all probably comes with a big chunk of static leakage power.bsp said:What's really needed is some kind of "killer application" for this. E.g. what rohezal said sounds reasonable (QEMU float emulation). Personally, I am thinking about moving the SID emulation of a C64 emulator to the DSP, or the SPC emulation of a SNES emulator but I will have to take a closer look at those emulators, first (I hope the sources are available?! different topic, though)
(EDIT: C64/SNES are maybe not the best targets since these emulators hardly use more than 50% CPU on a Ghz Pandora, just had a look via 'top')