SX720 Porting thread

srsa_4c

4451

Re: SX720 Porting thread

« Reply #80 on: 10 / April / 2016, 10:55:55 »

Advertisements

Quote from: asm1989 on 10 / April / 2016, 10:44:39

need to prep up a new sd to SCRIPT since this is flagged BOOT

Both flags can be enabled on the same card. Just don't forget to unlock the card when running a CBasic script.

Quote

And any clue why with this enable "ldr r0, =hook_CreateTask\n" it wont boot?

This LDR instruction reads the content of a word in memory: the word containing the address of hook_CreateTask. If that word of memory is not accessible (due to protection for example), it most likely causes an exception. In this case, it should be accessible, so - I don't know the answer.

Logged

srsa_4c

4451

Re: SX720 Porting thread

« Reply #81 on: 10 / April / 2016, 11:07:34 »

Oh, I think I got it. It's alignment. The patch code assumes word alignment, but the source/destination may not be word aligned. We'll probably have to switch to halfwords.

Logged

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #82 on: 10 / April / 2016, 11:16:39 »

Great thanks srsa_4c how can I switch to halfwords?

Got the rom and ram too

RomlogSX720.zip (86.77 kB - downloaded 21 times.)

Logged

srsa_4c

4451

Re: SX720 Porting thread

« Reply #83 on: 10 / April / 2016, 12:49:07 »

Quote from: asm1989 on 10 / April / 2016, 11:16:39

Great thanks srsa_4c how can I switch to halfwords?

The simplest (though not very efficient) way would be simply calling one of the firmware's memcpy variants (I don't think any of those depend on a running operating system). But we need to take a look at the disassembly first.
In the meantime, you could work on finding the bitmap overlay related firmware variables.

Logged

reyalp

13944

Re: SX720 Porting thread

« Reply #84 on: 10 / April / 2016, 14:11:42 »

Quote from: srsa_4c on 10 / April / 2016, 11:07:34

Oh, I think I got it. It's alignment. The patch code assumes word alignment, but the source/destination may not be word aligned. We'll probably have to switch to halfwords.

Good catch

We could align our source, but the destination might not be, so one of the memcpy functions seems like the best bet. I agree they don't rely on the OS being ready, but the one in RAM (which I called dry_memcpy) would require the cache to be flushed so the one in ROM is probably the better choice.

I used the following successfully on g7x

Code: [Select]

        // Install CreateTask patch
// use memcpy in case source or destination not word aligned
        "ldr     r0, =hook_CreateTask\n"    // dest: Address to patch (hook_ has thumb bit off)
        "adr     r1, patch_CreateTask\n"    // src: Patch data
        "mov     r2, #8\n" // two words
        "bl      _memcpy\n" // shouldn't need to preserve any extra regs, cache func called just below

I guess we could just do a loop with ldrh/strh too

Logged

Don't forget what the H stands for.

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #85 on: 10 / April / 2016, 14:49:18 »

reyalp with this lines it boots and shutdown after a few secs (show the canon mesage of no pictures, nothing from chdk) and second later green led it blinks once and shutsdown, but only if the are after " blo loc_fc02002a\n" ,

EDIT: about the thumb bit at CreateTask_my() { ... it is set " ldr.w pc, =(hook_CreateTask + 8 + 1) \n"

Attached rom log with this shutdown and main.bin.dump

If put them after " blo loc_fc020046\n" it hangs and don't boot

RomlogSX720-2.zip (397.54 kB - downloaded 20 times.)

« Last Edit: 10 / April / 2016, 14:56:41 by asm1989 »

Logged

reyalp

13944

Re: SX720 Porting thread

« Reply #86 on: 10 / April / 2016, 15:28:01 »

Quote from: asm1989 on 10 / April / 2016, 14:49:18

reyalp with this lines it boots and shutdown after a few secs (show the canon mesage of no pictures, nothing from chdk) and second later green led it blinks once and shutsdown, but only if the are after " blo loc_fc02002a\n" ,
...
If put them after " blo loc_fc020046\n" it hangs and don't boot

The thing you are trying to patch is in the 0xbfe region, so the patch must be *after* the original has been copied there. (the loop involving loc_fc020046)

Quote

EDIT: about the thumb bit at CreateTask_my() { ... it is set " ldr.w pc, =(hook_CreateTask + 8 + 1) \n"

I don't understand the question. For testing, you should comment out everything from push r0 through pop r0.

Looking at this I see another problem

Code: [Select]

"    stmdb   sp!, {r1, r2, r3, r4, r5, r6, r7, lr}\n"  // modified to SX720 but was push instead pos push.w in g7x
"    mov     r5, r2\n" // modified to SX720
"    ldr     r2, =0x00008164\n"  // modified to SX720
"    ldr.w   pc, =(hook_CreateTask + 8 + 1) \n"  // Continue in firmware (thumb bit set)

The first 3 instructions of the original CreateTask are replicated, but they are all 16 bit instructions:

Code: [Select]

bfe14a62: 	b5fe      	push	{r1, r2, r3, r4, r5, r6, r7, lr}
bfe14a64: 	4615      	mov	r5, r2
bfe14a66: 	4a85      	ldr	r2, =0x00008164	; [pc, #532] (0xbfe14c7c)
bfe14a68: 	461c      	mov	r4, r3

Your patch code should include the mov r4, r3, because this gets overwritten in the patch, but is not duplicated.

G7x and sx280 don't have this problem, because the first instruction (push.w rather than push) is 32 bit.

edit:
The romlog is a bit weird
PC is faaf0f3c which isn't valid. That's probably direct cause of the exception.
LR is fc333050, which is a return from CreateBinarySemaphoreStrictly (arm veneer) in Close, but if that's correct, I would expect it to have the thumb bit set. From the stack dump, it looks like Close was ultimately called from config_load_defaults

« Last Edit: 10 / April / 2016, 16:07:16 by reyalp »

Logged

Don't forget what the H stands for.

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #87 on: 10 / April / 2016, 16:23:23 »

if I add it after loc_fc020046 it does not boot, we may need something else

added the mov r4, r3 before the " ldr.w pc, =(hook_CreateTask + 8 + 1) \n" // Continue in firmware (thumb bit set) but does not change behaviour, also if everything is commented between push - pop

maybe we have an issue with the Close / close stubs?

Logged

reyalp

13944

Re: SX720 Porting thread

« Reply #88 on: 10 / April / 2016, 16:53:39 »

Quote from: asm1989 on 10 / April / 2016, 16:23:23

if I add it after loc_fc020046 it does not boot, we may need something else

I assume you mean after
"blo loc_fc020046"
right?
Since the patch is modifying the code that is copied by that loop, the patch must happen after the loop is done.

Quote

added the mov r4, r3 before the " ldr.w pc, =(hook_CreateTask + 8 + 1) \n" // Continue in firmware (thumb bit set) but does not change behaviour, also if everything is commented between push - pop

Maybe there are even more problems, but not having that mov was definitely a problem.

Quote

maybe we have an issue with the Close / close stubs?

~~I think the Close stub is correct.~~
edit:
The sig finder close stub is correct. Close in the last stubs_entry2 I have from your code is 0xfc33303e, which is an ARM address. This is not correct, and would explain the crash.

« Last Edit: 10 / April / 2016, 16:56:17 by reyalp »

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: SX720 Porting thread

« Reply #89 on: 10 / April / 2016, 18:33:33 »

Quote from: reyalp on 10 / April / 2016, 14:11:42

I guess we could just do a loop with ldrh/strh too

Yeah, but I thought a well known function looks less obscure and the additional clock cycles don't really matter much at this point.

From the RAM dump, it looks like the framebuffers have been rearranged a bit. The buffers of the bitmap overlay are at the end of the dump, at 0x1FD00000 and 0x1FE80000 (the space between them is unusually large, enough for 1024x768 pixels), opacity buffers are at 0x1FB80000 and 0x1FC40000.
The buffers are configured for 640x480 in this dump.

Side note: this is not the first time I see potentially unused space around the overlay buffers - in this case I can't imagine what would set them over 960x540 resolution. And I think the overlay buffers, unlike other framebuffers, are permanent.

Logged