Re: HDMI

[Trammell Hudson]

On Sun, Aug 16, 2009 at 06:43:17PM -0400, Al Bogdan wrote:
> Can't override HDMIOutputSizeToVGA() to just do nothing?

Unfortunately the big limitation in the way ML works is that it
can not change anything in Canon's code. Their firmware is burned
in ROM and we can't change it at runtime.

If you look at the hoops we jump through in 5d-hack.c to just
change one function call, you can see that it is rather difficult.
In this case the startup code copies 64 KB of ROM into RAM, does a
fixup by hand of any branches and rewrites a few instructions:

http://bitbucket.org/hudson/magic-lantern/src/tip/5d-hack.c#cl-64

The other way that we can modify things is by overriding a Canon
task through the dispatch hook. This allows us to replace their
task with one of our own, such as the hotplug_task() in hotplug.c
or the (much more vital) gui_main_task():

http://bitbucket.org/hudson/magic-lantern/src/tip/gui.c#cl-59

This one is a complete re-write by decompiling the assembly by
hand, then adding the hack at line 120 that prevents the picture
style event from ever being delivered and instead awakens our
menu drawing code.

Canon's DlgLiveViewApp() is about a hundred times longer...

> No way to trick it into thinking it is in VGA mode already? Can I assume
> it detects full HD mode by accessing hardware registers instead of
> firmware variables?

There was one possibility that I explored to try to trick it -- if the
photostudio_struct->off_0x230 | 6 != 0, the HDMI regs will
not be re-written. But when I set this value the camera won't record
and the HDMI output gets hosed.

Another option is to write a general purpose branch fixer and have it make
a copy of the DlgLiveViewApp() while re-writing any branch instructions
to have the correct offsets. Then we can modify the RAM copy of the
routine to NOP the calls to ChangeHDMIOutputSizeToVGA()* and update the
dynamic gui data structure that points to the event handler.

That might not be too bad. If no one else wants to give it a go, I may
hack on it this week. A general purpose way to replace Canon code would
make so many things easier.

--
Trammell

*: I really dislike Canon's function naming convention!

[Al Bogdan]

Tramm,

Thanks for the details. Exactly the info I was looking for, plus it
looks like you worked the solution out in your reply. The general
purpose branch fixer sounds like the best bet!

Al

[Trammell Hudson]

On Mon, Aug 17, 2009 at 06:43:05AM -0700, Al Bogdan wrote:
> [...] The general purpose branch fixer sounds like the best bet!

The one complication with it is that the ARM compilers mix readonly data
and code together to allow for small offsets with PC based addresing.
This means that sometimes things that look like instructions are not:

ff810920: e59f1020 ldr r1, [pc, #32] ; ff810948 <_start+0x109
48>
ff810924: e1a0000d mov r0, sp
ff810928: e3a02000 mov r2, #0 ; 0x0
ff81092c: eb001a9b bl ff8173a0 <_start+0x173a0>
ff810930: e28dd074 add sp, sp, #116 ; 0x74
ff810934: e49df004 pop {pc} ; (ldr pc, [sp], #4)
ff810938: 0012bc00 andseq fp, r2, r0, lsl #24
ff81093c: 00047550 andeq r7, r4, r0, asr r5
ff810940: 00124968 andseq r4, r2, r8, ror #18
ff810944: 0000019b muleq r0, fp, r1
ff810948: ff811dbc undefined instruction 0xff811dbc

You can see the first instruction does a PC relative load of
the constant stored at 0xff810948. This constant is not a valid
instruction, but what if it were? And worse, what if it were a
branch instruction? The naive relocation script might try to re-write
it, leading to all sorts of problems.

In fact, everything in this dump from 0xff810938 on is constant data.
The 'pop {pc}' instruction returned from this subroutine, but
obj-dump just continued to try to translate them as instructions.
Likewise, you can't just stop at the 'pop {pc}' instruction since
it is just fine to have multiple return points from a funciton.

If you haven't read it, the Story of Mel features a quote that is
appropos here:

"You never know where it's going to put things",
he explained, "so you'd have to use separate constants".

Luckily gcc does not do that, to the best of my knowledge,
even with -Os.

--
Trammell

[Al Bogdan]

So much for the simple elegance of brute force.

Instead of an automated process would the idea work manually with
careful inspection? In this case I would assume there are only a few
calls at most?