SX720 Porting thread - page 9 - DryOS Development - CHDK Forum supplierdeeply

SX720 Porting thread

  • 158 Replies
  • 42357 Views
*

Offline srsa_4c

  • ******
  • 4078
Re: SX720 Porting thread
« Reply #80 on: 10 / April / 2016, 10:55:55 »
Advertisements
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.

*

Offline srsa_4c

  • ******
  • 4078
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.

*

Offline 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

*

Offline srsa_4c

  • ******
  • 4078
Re: SX720 Porting thread
« Reply #83 on: 10 / April / 2016, 12:49:07 »
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.


*

Offline reyalp

  • ******
  • 12294
Re: SX720 Porting thread
« Reply #84 on: 10 / April / 2016, 14:11:42 »
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
Don't forget what the H stands for.

*

Offline 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
« Last Edit: 10 / April / 2016, 14:56:41 by asm1989 »

*

Offline reyalp

  • ******
  • 12294
Re: SX720 Porting thread
« Reply #86 on: 10 / April / 2016, 15:28:01 »
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 »
Don't forget what the H stands for.

*

Offline 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?


*

Offline reyalp

  • ******
  • 12294
Re: SX720 Porting thread
« Reply #88 on: 10 / April / 2016, 16:53:39 »
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 »
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4078
Re: SX720 Porting thread
« Reply #89 on: 10 / April / 2016, 18:33:33 »
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.

 

Related Topics