Making the firmware relocatable

RaduP

926

Re: Making the firmware relocatable

« Reply #10 on: 09 / September / 2009, 19:53:56 »

Advertisements

I am not sure what cached vs uncached means in terms of Canon cameras, or what the difference is. Is it just a speed difference or are there other issues? And do you have a suggestion on where should I put the firmware for the A530?

Logged

reyalp

14114

Re: Making the firmware relocatable

« Reply #11 on: 09 / September / 2009, 20:46:07 »

Quote from: RaduP on 09 / September / 2009, 19:53:56

I am not sure what cached vs uncached means in terms of Canon cameras, or what the difference is.

http://chdk.setepontos.com/index.php/topic,1910.0.html
http://chdk.setepontos.com/index.php/topic,2317.msg23777.html#msg23777
http://chdk.setepontos.com/index.php/topic,156.msg24092.html#msg24092

See also CAM_UNCACHED_BIT in the CHDK source.

Quote

Is it just a speed difference or are there other issues?

"only" speed AFAIK, but remember the camera may expect some things to execute within a given time. If they didn't need it, they wouldn't bother with an instruction cache. Maybe it would just be slow, or maybe it will fail.

Note also (as I mentioned earlier) you have to deal with cache coherency when you are copying code around.

Quote

And do you have a suggestion on where should I put the firmware for the A530?

No, as I've said from the beginning I believe the entire concept is unworkable. You'd be much better of relocating small chunks as needed, similar to how CHDK copies code to hijack specific tasks, but automated and at run time.

Logged

Don't forget what the H stands for.

RaduP

926

Re: Making the firmware relocatable

« Reply #12 on: 09 / September / 2009, 20:57:35 »

Quote from: reyalp on 09 / September / 2009, 20:46:07

"only" speed AFAIK, but remember the camera may expect some things to execute within a given time. If they didn't need it, they wouldn't bother with an instruction cache. Maybe it would just be slow, or maybe it will fail.

I guess the reason why they bothered was because the firmware is in flash rom, which is very very slow. If it's in the RAM, it should be quite fast.

Quote

Note also (as I mentioned earlier) you have to deal with cache coherency when you are copying code around.

I am not sure what that means, I will read those threads you linked.

Quote

No, as I've said from the beginning I believe the entire concept is unworkable.

Well, then i guess the RAW buffer (at least one of them) is the best idea so far, at least as a proof of concept.

Quote

You'd be much better of relocating small chunks as needed, similar to how CHDK copies code to hijack specific tasks, but automated and at run time.

Unfortunately, I am not sure it can be used to make the camera ignore the missing lens errors.
And it might also not work because if a function calls another function, you have to relocate that one too, and so on, or you might lose the execution control (it might just jump back into the ROM code).

Logged

RaduP

926

Re: Making the firmware relocatable

« Reply #13 on: 11 / September / 2009, 01:13:59 »

Ok, some small good news.
I moved all the firmware to the raw buffer, then jumped in there, and it worked!
Now, I didn't modify any locations, so the program control was lost fairly soon and went to the ROM firmware, but at least it shows that the code can run there fine, if only for just a few instructions.

Logged

hudson

43

Re: Making the firmware relocatable

« Reply #14 on: 17 / September / 2009, 08:18:53 »

I have taken a different approach in the Magic Lantern firmware for the Canon 5D Mark II. Instead of trying to relocate the entire firmware and worrying about finding every code reference, my approach has been to relocate to RAM just the functions that I need to change. Since I am targetting Canon dialog code that is called through a function pointer, my code is able to walk the GUI structures in RAM to find the pointer to the ROM routine and update it there. On the next redraw or event cycle the relocated code will be called instead and can execute my modified instructions.

reloc.c has the routines that do the copy and instruction fixup. The only instructions that are currently fixed are:

* B
* BL
* LDR rN, [ pc, off ]

If the B or BL or target of LDR are within the relocating region, they are not touched. Otherwise the offsets are adjusted. If the 12-bit offset of the LDR is out of range the constant value is copied from ROM into RAM in a small block of fixups.

I am detecting, but not fixing up ADD rN, pc, off instructions. For the code that I am currently targetting there are only two references that are out of range, and they related to debugging printf formats so I just NOP out the call to DebugMsg(). My plan is to fix these automatically in a newer version of the code by reserving a fixup space at the end of the allocated buffer as well.

The first proof of concept is to rewrite the portion of the DlgLiveViewApp() function that switches from 1080i HD to 480p on the HDMI port when recording is started. I have a video showing this in action:

Logged

RaduP

926

Re: Making the firmware relocatable

« Reply #15 on: 17 / September / 2009, 14:06:26 »

Quote

Instead of trying to relocate the entire firmware and worrying about finding every code reference, my approach has been to relocate to RAM just the functions that I need to change. Since I am targetting Canon dialog code that is called through a function pointer, my code is able to walk the GUI structures in RAM to find the pointer to the ROM routine and update it there. On the next redraw or event cycle the relocated code will be called instead and can execute my modified instructions.

reloc.c has the routines that do the copy and instruction fixup. The only instructions that are currently fixed are:

* B
* BL
* LDR rN, [ pc, off ]

But if you do that, don't you have to relocate the functions that are used by that function as well? And since many functions are linked with lots of other functions, isn't that relocating like half of the firmware?

Logged

hudson

43

Re: Making the firmware relocatable

« Reply #16 on: 17 / September / 2009, 14:23:34 »

Quote from: RaduP on 17 / September / 2009, 14:06:26

But if you do that, don't you have to relocate the functions that are used by that function as well? And since many functions are linked with lots of other functions, isn't that relocating like half of the firmware?

No, since the B and BL instructions are fixed up so that the destination offsets are correct for the relocated function.

Code: [Select]

			uint32_t offset = instr & BRANCH_OFFSET;

			// Sign extend the offset
			if( offset & 0x00800000 )
				offset |= 0xFF000000;
			uintptr_t dest = pc + (offset << 2) + 8;

			// Ignore branches inside the reloc space
			if( func_offset <= dest && dest < func_end )
				continue;

			int32_t new_jump = (dest - new_pc - 8);
			new_jump >>= 2;
			uint32_t new_instr = 0
				| (instr & ~BRANCH_OFFSET)
				| (new_jump & BRANCH_OFFSET);

This works since the destination functions are high in memory (starting at 0xFF810000), and the new %pc values are around 0x40000. There are just enough bits to make the relocation happen without requiring bounce trampolines or other hacks.

Logged

RaduP

926

Re: Making the firmware relocatable

« Reply #17 on: 17 / September / 2009, 14:41:03 »

Well, if you do a B in another function, how are you going to get the control back to your function? Or you don't care about that? the BLs should be easier, IF the called function will actually return gracefully to the function that called it, but is that guaranteed?

Logged

hudson

43

Re: Making the firmware relocatable

« Reply #18 on: 17 / September / 2009, 14:53:15 »

Quote from: RaduP on 17 / September / 2009, 14:41:03

Well, if you do a B in another function, how are you going to get the control back to your function? Or you don't care about that? the BLs should be easier, IF the called function will actually return gracefully to the function that called it, but is that guaranteed?

All of the B instructions are either in tail position, which requires an offset fixup, and my modified function is done running and the called function will return to the caller of my function, or they are internal jumps that are %pc relative and do not require any fixup.

The important part is that my function is never called directly; it is only ever called through a function pointer in a dialog structure. By modifying the data structure in RAM, it ensures that my function will be called to process events rather than the Canon one in ROM.

Logged

RaduP

926

Re: Making the firmware relocatable

« Reply #19 on: 17 / September / 2009, 15:24:09 »

Oh, ok, I see. We have slightly different needs.
My primary need is to get over the lens errors, and also be able to play with the lens motor, etc. I know, that can damage the camera, and I do have a few broken cameras I want to try that on.

Logged