bsp
Very Active Member
- Joined
- Dec 2, 2006
- Messages
- 314
Ok, that was a tough one.
But good news everyone: The overlay loader is working very nicely. It was more work than initially expected but so be it.
What really kept me busy the past 6h was that I noticed that the fastcall RPCs did not work as expected under certain conditions (DSP/ARM not seeing the same data sometimes).
My solution was to move the "todsp" and "togpp" message 'registers' (in L1DSRAM) to two separate cachelines.
"todsp" may only be written (and read) by the GPP, "togpp" only by the DSP.
This also meant a rewrite of the fastcall protocol, of course. Fortunately, this did not slow things down (0.002166 millisec / RPC).
Seems like the L1DSRAM is not as tightly coupled as I initially thought (or is this a hardware bug??) it's not a documented feature, after all.
But well, this works so far (did a lot of stresstests). All DSP example components have been moved into separate .out files. Up to 5 DSP image .out files can now be loaded/used simultaneously, yay!
And Notaz will be pleased to hear that I went the extra mile to add an "emergency unload" feature to the kernel module which, when fops release is called, unregisters all components registered by the overlay images loaded by the app, in case an application crashes w/o doing that the proper way. So, no need for ugly/mandatory application parachutes / signal handlers -- yay again.
Damn, at times this was a real nightmare to code but I guess we're close to "achievement unlocked -- the DSP!"
I'll edit this message later today and create a new release. Just too tired now (4:40am..). But kindof happy
EDIT: New release available at http://tkscript.de/c64_tools/
But good news everyone: The overlay loader is working very nicely. It was more work than initially expected but so be it.
What really kept me busy the past 6h was that I noticed that the fastcall RPCs did not work as expected under certain conditions (DSP/ARM not seeing the same data sometimes).
My solution was to move the "todsp" and "togpp" message 'registers' (in L1DSRAM) to two separate cachelines.
"todsp" may only be written (and read) by the GPP, "togpp" only by the DSP.
This also meant a rewrite of the fastcall protocol, of course. Fortunately, this did not slow things down (0.002166 millisec / RPC).
Seems like the L1DSRAM is not as tightly coupled as I initially thought (or is this a hardware bug??) it's not a documented feature, after all.
But well, this works so far (did a lot of stresstests). All DSP example components have been moved into separate .out files. Up to 5 DSP image .out files can now be loaded/used simultaneously, yay!
And Notaz will be pleased to hear that I went the extra mile to add an "emergency unload" feature to the kernel module which, when fops release is called, unregisters all components registered by the overlay images loaded by the app, in case an application crashes w/o doing that the proper way. So, no need for ugly/mandatory application parachutes / signal handlers -- yay again.
Damn, at times this was a real nightmare to code but I guess we're close to "achievement unlocked -- the DSP!"
I'll edit this message later today and create a new release. Just too tired now (4:40am..). But kindof happy
EDIT: New release available at http://tkscript.de/c64_tools/
Code:
** Changes
05-Oct-2013
- added: DSP auto suspend / resume (in suspend, DSP consumes no power).
The DSP is automatically suspended when the last application using it quits.
Vice versa, it resumes execution / is restarted when the next app. connects.
- added: support for dynamically loaded overlay images (4*256k + 1*1024k).
Overlays are unregistered when dsp_close() is called and their refcount becomes 0.
In case an application crashes, an "emergency unload" mechanism in the kernel module
takes care of this to prevent DSP code areas from getting lost.
The DSP build system automatically creates 4 .out file variants for the 256k areas
(linked to different base addresses).
Which of these 4 variants is loaded when dsp_component_load() is called depends on
what area is available / not already in use by other applications.
"demo_calc", "demo_checksum", "demo_calc_fastcall" are examples for "area2" (256k) overlays.
"demo_fractal" is an example for an "area3" (1024k) overlay.
- added: DSP-side global syscalls table. Currently includes some c64_tools utility functions,
cache management utilities, and mem/string handling functions.
- changed: DSP components no longer require DSP/BIOS (=> considerable decrease in code size)
For DSP component development, the following (free as in beer) TI packages are required:
$HOME/ti/c64xplus-iqmath_2_01_04_00
$HOME/ti/fastRTS_c62xc64x_1_42
$HOME/ti/TI_CGT_C6000_7.4.5
- changed: cleaned up DSP build system and moved common .mk code into include files
- changed: cleaned up "core" tconf and split it into multiple .tcis (see dsp/tci/ folder).
"config.tci" is the central memory configuration file.
It is included by the new gen_link_areas.tks script, which generates the DSP linker
command files (.cmd) and the "overlay_sections.c" source, which is also included
by the GPP-side build.
Unless you want to change the memory layout, you do not need to worry about this, though.
- fixed: added mtx_clients mutex to kernel module to fix some (potential) multiprocess concurrency issues
- changed: partially rewrote fastcall protocol to use two separate ARM/C64+ cachelines.
A more complex handshake protocol is used now but fortunately that
did not have a negative effect on the performance
Last edited by a moderator:
