[announce] c64_tools (DSP loader and IPC)

[bsp]

It's not that I do this everyday. Not 25 anymore

But I know that if I would not have used the phase of initial enthusiasm (have my Pandora only for ~2 weeks), laziness might have kicked in.

Anyway, 500 LOC later, the omapfb utility module is working fine.

No need to copy the framebuffer via memcpy() anymore.

One thing I had already anticipated: GPP access to the VID mem is dog-slow (uncached) (~20000ms vs ~4450.).

How do other applications handle this ? This makes quite a difference (almost factor 5).

EDIT: and yes, the scaler is working nicely. Thanks very much for the support, Notaz!

btw: did you remember to disable the GFX layer in SDL when you use VID1 ? Otherwise you'd be wasting ~43..86 MBytes/sec RAM bandwidth (16..32bits per pixel).

EDIT#2: I could post binaries but I'd rather usleep() now The demo also needs some polishing: Text output, key/button controls, PND packaging. Will do that tomorrow.

EDIT#3: wth, if I had followed this thread as a reader, I would want to see binaries now. Here they are. But beware: You MUST use Notaz latest kernel ("uImage-3") (posted earlier in this thread, you can also find it in the c64_tools-20Sep2013.tar.gz release, which I also attached to the opening post of this thread.

Usage: "./go64.sh" (as root) to load/boot the DSP. then "./c64_fractal_gpponly" for the ARM-only version of the effect. "./c64_fractal_dsponly" for..the C64+-only version. The effect runs for 3600 frames. Don't lctrl-c or the desktop-layer will not be re-enabled.

p.s.: and now, with the memcpy removed, the DSP-version is 3.63 (instead of 3.19) times faster. Yay!

p.p.s.: the dsp_cache_inv() call is not necessary / is not used now that the effect is rendered directly into the OS' omap framebuffer.

p.p.p.s.: the gpponly version renders the effect into an offscreen buffer which is then copied to the actual FB via memcpy()

p.p.p.p.s.: the ARM CPU load for the dsponly version is ~0..3% (measured using top, i.e. inaccurate)

p.p.p.p.p.s.: some (meaningless) stats: (yep, this time I kept track): 12695 lines of code, ~120 hours of work spread over the course of 16 days.

bin-22Sep2013.tar.gz

 

[PokeParadox]

Anyone able to post a video?

 

[notaz]

One thing I had already anticipated: GPP access to the VID mem is dog-slow (uncached) (~20000ms vs ~4450.).

Thats not supposed to be the case, are you mmap()ing using fd from /dev/fb1? That should give you write-through cached memory corresponding to fb1.


BTW I was surprised even ./c64_fractal_gpponly wants /dev/mem, it should have no business accessing it. If some code needs register access, it should all be provided by kernel module.

btw: did you remember to disable the GFX layer in SDL when you use VID1 ? Otherwise you'd be wasting ~43..86 MBytes/sec RAM bandwidth (16..32bits per pixel).

A while ago I've tested it and couldn't measure any difference. OMAP is also smart enough to not fetch pixel data from areas that are hidden by other layers, and when the scaler is used, it almost always covers most of the screen.

EDIT#3: wth, if I had followed this thread as a reader, I would want to see binaries now. Here they are.

Ok tested and it seems to work nicely. I guess it's time to think about how to include this in default firmware (and hope it will be used more then the other DSP frameworks).

Could you maybe put your code on some code hosting websites, like github.com? The build system we use (openembedded) pulls all sources from public web before building and it's not really good at pulling them from forum attachments. Some public version control host is preferred (git or svn, some others too), but wget'able tarball on http or ftp would also work.

I'm also not sure if libc64 is a good name, it sounds like "64bit C library", and google gives a lot of random hits on that name. Maybe libc64p or libc64dsp would be a better fit. Kernel module name is fine though.

We'll need to patch /usr/pandora/scripts/op_dsp.sh to be able to load your module too. It's a script that any pnd which wants to use the DSP can run without sudo password.

 

[rohezal]

Can you upload the source code of your demos too?

 

[levi]

libc64 sounds like a Commodore 64 emulator library to me

 

[bsp]

@Notaz:

regarding mmap/root privileges: That's because of some testcode I forgot to remove (reads the DSS GFX_BA0 register, see last page).
Both GPP and DSP executables can be run with regular user privileges once I have removed the testcode in the next source release.
The example apps in my last release already did not need to be run as root.

regarding the DSS GFX layer enable/disable: That's good to hear. The last TI display controller I was working with was not that clever and you had to be careful not to waste bandwidth.

regarding public code hosting: I had planned to put the package on my home page and also make a small web page for it. I also registered a repository at github but unless other people start to collaborate on this project, I'd suggest that you wget the latest (stable) release from my site (link(s) will follow).

I will stick with the name "libc64", though, I like it. The package name is "c64_tools", anyway, and that's not a common name. "libc64" is just a part of the package. The biggest "issue" here is that TI named their chip C64 -- if you google for that, you get a lot of Commodore C64 related results.


Now the system integration is something that needs some thought. It's not just a matter of loading the kernel module, the DSP has to be booted (c64_load), too.

There will probably be a, more or less long, period where different PNDs will require different DSP images.

I have not familiarized myself with PND development, yet, so I have to ask: Is there a way to run a single script in a PND with root privileges (dialog pops up with some message, asks for password, then ./go64 is run to load a DSP image inside the PND and if that returned no error, the rest of the PND then executes with regular privileges) ?

This is not an ideal solution, just a practical one. Once some real code is written for the DSP, there should be a standard DSP firmware image.

Such a DSP firmware could contain e.g.
  - the TI codecs (MP3, MP4, ..)
  - a graphics blitter engine (needs to be written) (I cannot do it because it would interfer with my real job. TI has some example code and there's also DirectFB which has some rudimentary C64+ DSP acceleration (albeit quite slow))
  - vector/matrix math utilities (needs to be written but TI already has the IQmath library which I would suggest to use for that purpose)
  - multichannel sound mixer (needs to be written)
  - other utility libraries written for specific apps/emulators/games/..

I also proposed the "load overlay" c64_load feature a few pages back. Once implemented, this can be used to dynamically load additional DSP code sections / extend the baseline DSP firmware.

For that, different areas within the DSP image need to be reserved (at absolute addresses), so there will probably be
  1) the firmware area
  2) another larger section for custom code/data
  3) and maybe a few small ones for utility functions (which should be moved into the firmware area once they're stable so that other applications can rely on them / use them, too).

I would volunteer to code that feature if I see that there's actual interest in DSP development / code gets written.

last but not least, thanks for trying out the binaries. Now I know that this works on at least one other Pandora, too.
 

 

[Hồng Thất Công]

Wow!  Awesome!  Let's make use of this and build a full speed Dreamcast emulator for the Pandora 1!! :rolleyes:

Edit: Eyes rolling added

 

[Exophase]

Wow!  Awesome!  Let's make use of this and build a full speed Dreamcast emulator for the Pandora 1!!

*rolleyes*

 

[milkshake]

Can we have a video of the demo running?

 

[bsp]

@milkshape/anyone_who_wants_to_make_a_video: please use the bins from the latest release. yesterday's bins zoom *3, the new version shows the effect in fullscreen (EDIT: no button controls, yet. will save that for a rainy day or when PND packaging it (see question above). And if someone really puts this on YT: The original demo effect code was written in the 1990ies by Jet/Avena. Please credit him.).

So, here's the new release. Get it from http://tkscript.de/c64_tools/ .

** Changes

 23-Sep-2013
   - added: the c64.ko kernel module now supports select() (=> OS friendly message reception)
   - added dsp_poll_enable() API function (increases message throughput by ~500% but is
      not OS friendly (high GPP usage). default=use select).
   - the dsp_cache_inv() and dsp_cache_wbinv() now fall back to flush_cache_all() since all
      other functions (see "c64_kmod/dev.c") cause system instabilities. disabling interrupts
      during cache invalidates did not change that.
   - added "tests/omapfb.c" utility code for framebuffer access on OMAP3 / Open Pandora.
   - added "c64_fractal" GPP example and "demo_fractal" component on DSP-side.
      (a single precision floating point heavy effect. uses TI's IQmath library on the DSP side.
       the source also contains several other alternative (slower) implementations.)

 

[WizardStan]

I have not familiarized myself with PND development, yet, so I have to ask: Is there a way to run a single script in a PND with root privileges (dialog pops up with some message, asks for password, then ./go64 is run to load a DSP image inside the PND and if that returned no error, the rest of the PND then executes with regular privileges) ?

In your script, call "gksudo ./go64". It does exactly what you want, pop up a password dialog and promote the user to super for that single command. It's like "sudo" only graphical.
edit: although, having taken a few seconds to think about it, that's probably not the best way to do it. If it's going to be standard part of the system then it should probably just be on the NAND and installed at boot (optionally) with a "install/remove" script.

Although from a practical perspective, can multiple applications access the DSP at once?

 

[bsp]

@WizardStan: thanks for the info! will try that.

It is possible for multiple applications to access the DSP (although for now, only one DSP image can be loaded at the time). Please also read my previous post on this page (DSP firmware considerations, ..).

EDIT: I just re-tested the multi-client feature (ran the fractal benchmark and two RPC benchmarks simultaneously). Interesting how little impact the RPC benchmarks had on the fractal FPS rate (just ~27% slower).

 

[WizardStan]

It is possible for multiple applications to access the DSP (although for now, only one DSP image can be loaded at the time). Please also read my previous post on this page (DSP firmware considerations, ..).

So you need a system whereby an application can "install" or "remove" the standard image without affecting any other system that might be using it. It wouldn't be fun to be using a DSP MP3 player, and playing a game which uses DSP side by side, and then have your game crash because you stopped the music.So there's a standard DSP image in the firmware. Whenever an application needs it, it calls "./go64" to load the image into memory, yeah? Does it get removed somehow? Is there a reason it can't just be (optionally) started at boot?

edit: I've learned more about the DSP in the last 5 posts than I ever did actually trying to study the thing.

 

[notaz]

It's possible to ask for root from a .pnd, but it's better to not do that. At least c64.ko should reside in firmware anyway, because we update kernels occasionally, and modules must match kernels. I think /usr/pandora/scripts/op_dsp.sh should be taught about c64_tools and module+c64_load/dsp_image loading. PNDs can then run this script with sudo and no password will be needed because it's in sudoers.

About DSP sharing, it should be kernel module's job. It could track who has /dev/c64 open and loaded what image was loaded. When some app closes it's /dev/c64 file descriptor, the kernel code would unload the image, and when everyone closes their FDs, it could even shut down the DSP.

We also need support for custom DSP images. If I ever use the DSP, I'll want a custom image (hence the suggestion of op_dsp.sh loading the images).

 

[bsp]

@WizardStan: The kernel module does not get automatically removed ATM. There are two good reasons why you would not want to autostart the DSP at boot: 1) The DSP consumes power. Seems to be not much when it's idle but exact measurements would have to be done in that regard. 2) In general, only the services/modules that are actually used should be loaded. Your example fits the "proposal" in my previous post: the MP3 decoder would be part of the firmware image, the game would overlay the standard DSP image with a custom image.

@notaz: That could be done by in the kernel module but a simple BASH script could do the job: call fuser /dev/c64 in op_dsp.sh stop, and remove the module if there are no users left (resp. go64.sh, which, after the proper modifications, i.e. start/stop args, later an overlay_load, overlay_unload should be called there, so that the op script stays simple). I hope you read what I wrote about custom DSP images (see post above). For now we need devs who use the DSP, then I'll add the overlay support to c64_load. (maybe I'll add it "just because" it's kewl to have that feature).

EDIT: also, it's not the kernel module's job to load/unload DSP images. that's what c64_load is for. go64.sh is the utility script that handles kernel module load/unload and DSP image load/unload.

 

[Linux-SWAT]

Has the DSP its own clock or is it based on the core ?

 

[bsp]

DSP/ARM clocks are coupled but the clock setup of the Pandora is quite complex.

Did some analysis / register dumps today.

I tried to set the DSP clock via tconf (javascript-based DSP setup in CCS).

Did not change anything (clockrate 800 changed to 430).

Here are the register dumps (boooring stuff):


pandora:/home/bsp# ./reg_read 48004000
800MHz: read reg[0x48004000] = 0x00000001 (0000 0000 0000 0000 0000 0000 0000 0001)
430MHz: read reg[0x48004000] = 0x00000001 (0000 0000 0000 0000 0000 0000 0000 0001)
--> IVA2_CLK is enabled

pandora:/home/bsp# ./reg_read 48004004 ; CM_CLKEN_PLL_IVA2
800MHz: read reg[0x48004004] = 0x00000017 (0000 0000 0000 0000 0000 0000 0001 0111)
430MHz: read reg[0x48004004] = 0x00000017 (0000 0000 0000 0000 0000 0000 0001 0111)
--> IVA2 DPLL in lock mode
--> IVA2_DPLL_FREQSEL == 1 (reset value) (not documented)

pandora:/home/bsp# ./reg_read 48004040 ; CM_CLKSEL1_PLL_IVA2
800MHz: read reg[0x48004040] = 0x00081400 (0000 0000 0000 1000 0001 0100 0000 0000)
430MHz: read reg[0x48004040] = 0x00081400 (0000 0000 0000 1000 0001 0100 0000 0000)
--> IVA2_CLK_SRC: DPLL2_FCLK is CORE_CLK/1 ("selects the IVA_DPLL bypass source clock")
--> IVA2_DPLL_MULT is 20
--> IVA2_DPLL_DIV is 0 (reset value)

pandora:/home/bsp# ./reg_read 48004044 ; CM_CLKSEL2_PLL_IVA2
800MHz: read reg[0x48004044] = 0x00000001 (0000 0000 0000 0000 0000 0000 0000 0001)
430MHz: read reg[0x48004044] = 0x00000001 (0000 0000 0000 0000 0000 0000 0000 0001)
--> IVA2_DPLL_CLKOUT_DIV: DPLL2 CLKOUTX2 divided by 1

pandora:/home/bsp# ./reg_read 48004a40 ; CM_CLKSEL_CORE
800MHz: read reg[0x48004a40] = 0x0000130a (0000 0000 0000 0000 0001 0011 0000 1010)
430MHz: read reg[0x48004a40] = 0x0000130a (0000 0000 0000 0000 0001 0011 0000 1010)
--> L3_CLK is CORE_CLK/2
--> L4_CLK is L3_CLK/2
--> GPTIMER 11 clk is CM_32K_CLK
--> GPTIMER 10 clk is CM_32K_CLK

pandora:/home/bsp# ./reg_read 48004904 ; CM_CLKEN_PLL_MPU
800MHz: read reg[0x48004904] = 0x00000037 (0000 0000 0000 0000 0000 0000 0011 0111)
430MHz: read reg[0x48004904] = 0x00000037 (0000 0000 0000 0000 0000 0000 0011 0111)
--> MPU_DLL_FREQSEL is 3 (0.75Mhz - 1.0Mhz)
--> DPLL1 in lock mode

pandora:/home/bsp# ./reg_read 48004940 ; CM_CLKSEL1_PLL_MPU
800MHz: read reg[0x48004940] = 0x0013e80c (0000 0000 0001 0011 1110 1000 0000 1100)
430MHz: read reg[0x48004940] = 0x0013e80c (0000 0000 0001 0011 1110 1000 0000 1100)
read reg[0x48004940] = 0x00144c0c (0000 0000 0001 0100 0100 1100 0000 1100) 1.1Ghz ARM
--> MPU_DPLL_DIV is 12 (DPLL1 div)
--> MPU_DLL_MULT is 1000
--> MPU_CLK_SRC: DPLL1_FCLK is CORE_CLK/2

pandora:/home/bsp# ./reg_read 48004a00 ; CM_FCLKEN1_CORE
800MHz: read reg[0x48004a00] = 0x40006000 (0100 0000 0000 0000 0110 0000 0000 0000)
430MHz: read reg[0x48004a00] = 0x40006000 (0100 0000 0000 0000 0110 0000 0000 0000)
--> UART1 functional clock is enabled
--> UART2 functional clock is enabled
--> MMC3 functional clock is enabled

pandora:/home/bsp# ./reg_read 48004d00 ; CM_CLKEN_PLL
800MHz: read reg[0x48004d00] = 0xf0371037 (1111 0000 0011 0111 0001 0000 0011 0111)
430MHz: read reg[0x48004d00] = 0xf0371037 (1111 0000 0011 0111 0001 0000 0011 0111)
--> DPLL3 is in lock mode
--> CORE_DPLL_FREQSEL = 3 (0.75Mhz - 1.0Mhz)
--> Power down the DPLL3_M3X2 HSDIVIDER path
--> DPLL4 is in lock mode
--> PERIPH_DPLL_FREQSEL = 3 (0.75MHz - 1.0Mhz)
--> PWRDN_TV, PWRDN_DSS1, PWRDN_CAM, PWRDN_EMU_PERIPH

pandora:/home/bsp# ./reg_read 48004d04 ; CM_CLKEN2_PLL
800MHz: read reg[0x48004d04] = 0x00000011 (0000 0000 0000 0000 0000 0000 0001 0001)
430MHz: read reg[0x48004d04] = 0x00000011 (0000 0000 0000 0000 0000 0000 0001 0001)
--> second DPLL5 in low power stop mode
--> PERIPH2_DPLL_FREQSEL = 1 (reset value), not documented

pandora:/home/bsp# ./reg_read 48004d40 ; CM_CLKSEL1_PLL
800MHz: read reg[0x48004d40] = 0x09900c00 (0000 1001 1001 0000 0000 1100 0000 0000)
430MHz: read reg[0x48004d40] = 0x09900c00 (0000 1001 1001 0000 0000 1100 0000 0000)
--> CORE_DPLL_CLKOUT_DIV: DPLL3 output clock is divided by 1
--> CORE_DPLL_MULT: DPLL3 multiplier factor is 400
--> CORE_DPLL_DIV: DPLL3 divider factor is 12

pandora:/home/bsp# ./reg_read 48004d44 ; CM_CLKSEL2_PLL
800MHz: read reg[0x48004d44] = 0x0483600c (0000 0100 1000 0011 0110 0000 0000 1100)
430MHz: read reg[0x48004d44] = 0x0483600c (0000 0100 1000 0011 0110 0000 0000 1100)
--> PERIPH_DLL_MULT: DPLL4 multiplier factor is 864
--> DCO_SEL: 8 (undocumented) (lock frequency is comprised between x Mhz and y Mhz)
--> PERIPH_DLL_DIV: DPLL4 divider factor is 12

pandora:/home/bsp# ./reg_read 48004d48 ; CM_CLKSEL3_PLL
800MHz: read reg[0x48004d48] = 0x00000009 (0000 0000 0000 0000 0000 0000 0000 1001)
430MHz: read reg[0x48004d48] = 0x00000009 (0000 0000 0000 0000 0000 0000 0000 1001)
--> DIV_96M: 96 Mhz clock divider factor M2 is DPLL4 clock divided by 9

pandora:/home/bsp# ./reg_read 48004d4c ; CM_CLKSEL4_PLL
800MHz: read reg[0x48004d4c] = 0x0000780c (0000 0000 0000 0000 0111 1000 0000 1100)
430MHz: read reg[0x48004d4c] = 0x0000780c (0000 0000 0000 0000 0111 1000 0000 1100
--> PERIPH2_DPLL_MULT: DPLL5 multiplier factor is 120
--> PERIPH2_DPLL_DIV: DPLL5 divider factor is 12

pandora:/home/bsp# ./reg_read 48004d50 ; CM_CLKSEL5_PLL
800MHz: read reg[0x48004d50] = 0x00000001 (0000 0000 0000 0000 0000 0000 0000 0001)
430MHz: read reg[0x48004d50] = 0x00000001 (0000 0000 0000 0000 0000 0000 0000 0001)
--> DIV_120M: 120Mhz clock is DPLL5 clock divided by 1

pandora:/home/bsp# ./reg_read 48004d70 ; CM_CLKOUT_CTRL
800MHz: read reg[0x48004d70] = 0x00000003 (0000 0000 0000 0000 0000 0000 0000 0011)
430MHz: read reg[0x48004d70] = 0x00000003 (0000 0000 0000 0000 0000 0000 0000 0011)
--> CLKOUT2_EN: sys_clkout2 is disabled
--> CLKOUT2_DIV: sys_clkout2/1
--> CLKOUT2SOURCE: source is 54 Mhz clock

pandora:/home/bsp# ./reg_read 48004d24 ; CM_IDLEST_CKGEN
800MHz: read reg[0x48004d24] = 0x00000000 (0000 0000 0000 0000 0000 0000 0000 0000)
430MHz: read reg[0x48004d24] = 0x00000000 (0000 0000 0000 0000 0000 0000 0000 0000)
--> DPLL5_M2_CLK is not active
--> USB HOST 120M_FCLK is not active
--> DPLL5 is bypassed

pandora:/home/bsp# ./reg_read 48004c40 ; CM_CLKSEL_WKUP
800MHz: read reg[0x48004c40] = 0x00000014 (0000 0000 0000 0000 0000 0000 0001 0100)
430MHz: read reg[0x48004c40] = 0x00000014 (0000 0000 0000 0000 0000 0000 0001 0100)
--> "reserved for non-GP devices" bits = 2 (reset_value)
--> CLKSEL_RM: reset manager clock is L4_CLK / 2
--> CLKSEL_GPT1: GPTIMER 1 clock source is 32K_FCLK

pandora:/home/bsp# ./reg_read 48005000 ; CM_FCLKEN_PER
800MHz: read reg[0x48005000] = 0x0006c840 (0000 0000 0000 0110 1100 1000 0100 0000)
430MHz: read reg[0x48005000] = 0x0006c840 (0000 0000 0000 0110 1100 1000 0100 0000)
--> EN_GPT5, EN_UART3, EP_GPIO3, EN_GPIO4, EN_GPIO6, EN_UART4

pandora:/home/bsp# ./reg_read 48005010 ; CM_ICLKEN_PER
800MHz: read reg[0x48005010] = 0x0007efff (0000 0000 0000 0111 1110 1111 1111 1111)
430MHz: read reg[0x48005010] = 0x0007efff (0000 0000 0000 0111 1110 1111 1111 1111)
--> EN_UART4, EN_GPIO6, EN_GPIO5, EN_GPIO4, EN_GPIO3, EN_GPIO2, EN_UART3,
EN_GPT9, EN_GPT8, EN_GPT7, EN_GPT6, EN_GPT5, EN_GPT4, EN_GPT3, EN_GPT3,
EN_GPT2, EN_MCBSP4, EN_MCBSP2

I saw that both "MPU" and "DSP" have their own PLL multipy/divide bits.

Changing the clock-rate of the ARM via System->CPU Speed (or similar) does not affect the DSP.

However, the interesting bits of the dump above are in the CM_CLKSEL1_PLL_IVA2 register:


pandora:/home/bsp# ./reg_write 48004040 00080a00
read reg[0x48004040] = 0x00081600 (0000 0000 0000 1000 0001 0110 0000 0000)
write reg[0x48004040] = 0x00080a00
re-read reg[0x48004040] = 0x00080a00 (0000 0000 0000 1000 0000 1010 0000 0000)

pandora:/home/bsp# ./c64_fractal_dsponly
[...] omapfb_plane_enable: ok, plane 0 is now disabled.
[...] loc_setup_fb1: ok, plane 1 is now disabled.
[...] omapfb_plane_setup: OK, plane 1 is configured size=(128; 128) geo=(0; 0; 800; 480) bpp=32.
[...] omapfb_plane_setup_dsp_mem: plane 1 virt_addr=0x41293000, phys_addr=0x9c050000 size=0x00010000.
[...] omapfb_init: OK.
[...] 3600 iterations in 32118 millisecs.
[...] omapfb_plane_enable: ok, plane 1 is now disabled.
[dbg] omapfb_exit: [1] unmapped 65536 bytes @virt=0x41293000 (phys=0x9c050000).
[...] omapfb_plane_enable: ok, plane 0 is now enabled.


==> DSP at half speed (400Mhz on 1Ghz Pandora (DM3730), 215 MHz on the others (?!))

pandora:/home/bsp# ./reg_write 48004040 00081400  
    read reg[0x48004040] = 0x00080a00 (0000 0000 0000 1000 0000 1010 0000 0000)
   write reg[0x48004040] = 0x00081400
 re-read reg[0x48004040] = 0x00081400 (0000 0000 0000 1000 0001 0100 0000 0000)

pandora:/home/bsp# ./c64_fractal_dsponly 
[...] omapfb_plane_enable: ok, plane 0 is now disabled.
[...] loc_setup_fb1: ok, plane 1 is now disabled.
[...] omapfb_plane_setup: OK, plane 1 is configured size=(128; 128) geo=(0; 0; 800; 480) bpp=32.
[...] omapfb_plane_setup_dsp_mem: plane 1 virt_addr=0x41132000, phys_addr=0x9c050000 size=0x00010000.
[...] omapfb_init: OK.
[...] 3600 iterations in 16263 millisecs.
[...] omapfb_plane_enable: ok, plane 1 is now disabled.
[dbg] omapfb_exit: [1] unmapped 65536 bytes @virt=0x41132000 (phys=0x9c050000).
[...] omapfb_plane_enable: ok, plane 0 is now enabled.

 ==> DSP at default speed (800Mhz on 1Ghz Pandora (DM3730), 430 MHz on the others (?!))

..and of course:


pandora:/home/bsp# ./reg_write 48004040 00081600
read reg[0x48004040] = 0x00081400 (0000 0000 0000 1000 0001 0100 0000 0000)
write reg[0x48004040] = 0x00081600
re-read reg[0x48004040] = 0x00081600 (0000 0000 0000 1000 0001 0110 0000 0000)

pandora:/home/bsp# ./c64_fractal_dsponly
[...] omapfb_plane_enable: ok, plane 0 is now disabled.
[...] loc_setup_fb1: ok, plane 1 is now disabled.
[...] omapfb_plane_setup: OK, plane 1 is configured size=(128; 128) geo=(0; 0; 800; 480) bpp=32.
[...] omapfb_plane_setup_dsp_mem: plane 1 virt_addr=0x4125c000, phys_addr=0x9c050000 size=0x00010000.
[...] omapfb_init: OK.
[...] 3600 iterations in 14780 millisecs.
[...] omapfb_plane_enable: ok, plane 1 is now disabled.
[dbg] omapfb_exit: [1] unmapped 65536 bytes @virt=0x4125c000 (phys=0x9c050000).
[...] omapfb_plane_enable: ok, plane 0 is now enabled.

==> DSP overclocked to 880Mhz (473 Mhz)


so yes, overclocking works. I have not dared to go higher than 10%, yet

EDIT: no risk no fun:


pandora:/home/bsp# ./reg_write 48004040 00081800
read reg[0x48004040] = 0x00081400 (0000 0000 0000 1000 0001 0100 0000 0000)
write reg[0x48004040] = 0x00081800
re-read reg[0x48004040] = 0x00081800 (0000 0000 0000 1000 0001 1000 0000 0000)
pandora:/home/bsp# ./c64_fractal_dsponly
[...] omapfb_plane_enable: ok, plane 0 is now disabled.
[...] loc_setup_fb1: ok, plane 1 is now disabled.
[...] omapfb_plane_setup: OK, plane 1 is configured size=(128; 128) geo=(0; 0; 800; 480) bpp=32.
[...] omapfb_plane_setup_dsp_mem: plane 1 virt_addr=0x401c9000, phys_addr=0x9c050000 size=0x00010000.
[...] omapfb_init: OK.
[...] 3600 iterations in 13572 millisecs.
[...] omapfb_plane_enable: ok, plane 1 is now disabled.
[dbg] omapfb_exit: [1] unmapped 65536 bytes @virt=0x401c9000 (phys=0x9c050000).
[...] omapfb_plane_enable: ok, plane 0 is now enabled.


==> DSP overclocked to 960Mhz!!

I immediately changed that back to 800Mhz, I have no idea whether this could damage the hardware. It's a rather unprotected register so hopefully the system would just crash.

p.s.: It would not damage the hardware immediately but might reduce its life span . We used a 550Mhz (instead of ~450Mhz) config on similar HW for years w/o issues. You have been warned, though

 

[Linux-SWAT]

However, the interesting bits of the dump above are in the CM_CLKSEL1_PLL_IVA2 register:

Yeah, that's exactly where i woulda have looked into .

Btw, i (we) appreciate the way you populate this thread as it's publicly helpful (for those who get into low level magic).

 

[Hồng Thất Công]

How do I learn all this good low level crap?

 

[ekianjo]

How do I learn all this good low level crap?

You stop wasting your time on the boards making comments, and get to work