DIGIC 6 findings continued.
When JediDraw messages are intercepted, all Canon drawings disappear - except for text (which keeps accumulating on screen as, apparently, JediDraw is needed for erasing text). The JediDraw message does include one RGBA buffer address,
so it might be possible to redirect the drawing (with unknown consequences)*. I have not yet been able to find the message responsible for drawing text.
This time, I used an Xtensa side wrapper to replace the original message handler. It can be copied to an arbitrary place in Xtensa program memory (I used the unused part of the 0xbff20000...0xbff27fff area), and the address of 'jdraw_replacement' needs to be written at the appropriate place in the message handler table (
related post).
# xtensa-elf-as try1.s -o try1.o
# xtensa-elf-objcopy -O binary try1.o try1.bin
# to check generated code: xtensa-elf-objdump -d try1.o
.text
.begin
.literal_position
orig_jedidraw:
.word 0x80AD1A2C
jdraw_enabled:
.word 0xbff07ffc
.word 0
.align 4
jdraw_replacement:
entry a1, 32
l32r a3, jdraw_enabled
l32i a3, a3, 0
beqz a3, jd_skip
mov a10, a2
l32r a8, orig_jedidraw
callx8 a8
mov a2, a10
retw
jd_skip:
movi a2, 0
retw
.end
When copying stuff to the 0xbff2xxxx area, following precautions are needed:
- The procedure should happen in or after zicokick_start. There's an unused Canon debug callback that lets hijack this function.
- Whole words need to be written
edit:
*Looking at the Xtensa side code, only the first 4 words of this particular message are used, the rest (including the framebuffer address) is ignored.
Message handlers (the ones I've seen) only have a single argument: a pointer that points to the message body (I managed to dump message content on the Xtensa side to prove this).
The Xtensa core is able to reach near the end of physical RAM (I copied stuff there from the Xtensa side), so I assume it is able to address the whole RAM.
