Forgot Password
Pentax Camera Forums Home
 

Reply
Show Printable Version Search this Thread
08-13-2009, 06:24 AM   #271
New Member




Join Date: Aug 2009
Location: Sofia
Posts: 22
Took a look at K20D/GX20 firmware v1.03 today.

Two interesting observations comparing to K10/K100:

1. A lot of function calls are done like this:

ROM:10641EEC ldi:32 #sub_1004C81C, r12
ROM:10641EF2 extsh r4
ROM:10641EF4 int #0x40

with or without instructions between the ldi and int. This breaks the analysis and has to be implemented in the disassembler. That requires proper register tracking as the current approach works only on consecutive ld/jmp instructions.

According to the manual:
Vector numbers 9 to 13, 64 and 65 are used by emulators for debugging interrupts and therefore the corresponding numbers "INT#9" to "#13", "#64", "#65" should not be used in user programs.


2. There is new command in modset.txt - CRE_RECOVERY_FW that seems to "Create recovery firmware". Has anyone tried that?

08-13-2009, 08:05 AM   #272
New Member




Join Date: Mar 2008
Posts: 19
[CRE_RECOVERY_FW] in MODSET.442 (k20d), power on :

Create Recovery Firmware

Error
(FileNotFound)
08-13-2009, 08:07 AM   #273
Veteran Member




Join Date: Jul 2009
Location: Russia
Posts: 343
Original Poster
QuoteQuote:
Took a look at K20D/GX20 firmware v1.03 today.
Two interesting observations comparing to K10/K100:

1. A lot of function calls are done like this:

ROM:10641EEC ldi:32 #sub_1004C81C, r12
ROM:10641EF2 extsh r4
ROM:10641EF4 int #0x40

with or without instructions between the ldi and int. This breaks the analysis and has to be implemented in the disassembler. That requires proper register tracking as the current approach works only on consecutive ld/jmp instructions.
We don't have manual for this LSI, and it can be different.
But as we know TBR table, we know address of INT #0x40 handler. So, it is not that scary. We must just provide xref to this handler in processor module (and it already knows TBR location). We also must add DSP TBR interrupt addresses and uncomment all entries, change comments in fr.cfg.

QuoteQuote:
2. There is new command in modset.txt - CRE_RECOVERY_FW that seems to "Create recovery firmware". Has anyone tried that?
No I have not tried that yet.

Worse thing is that is you see on my screenshot above, it have
call @r0 thing, and this is also quite common and much worse.
Exremely hard to understand.

Last edited by tr13; 08-13-2009 at 08:14 AM.
08-13-2009, 08:26 AM   #274
Veteran Member




Join Date: Jul 2009
Location: Russia
Posts: 343
Original Poster
Current tasks:

1) Look at checksum calculation to allow firmware updating. Starting with simple one character test patches.

2) Make total memory dump on large flash card - 4Gb total.
As you can see CPU_DUMP is not very suitable due to 20bit loading operators and 8 bit block counter.
But initial loading can be modified and shifting used later.

3) Add assembler ability to processor module (Patch menu). So anyone could just enter assembly instruction and it'll be translated to binary form.

08-13-2009, 10:30 AM   #275
Veteran Member




Join Date: Jul 2009
Location: Russia
Posts: 343
Original Poster
Just made working auto-comments for my FR module :-)
08-13-2009, 11:25 AM   #276
New Member




Join Date: Aug 2009
Location: Sofia
Posts: 22
QuoteOriginally posted by tr13 Quote
We don't have manual for this LSI, and it can be different.
But as we know TBR table, we know address of INT #0x40 handler. So, it is not that scary. We must just provide xref to this handler in processor module (and it already knows TBR location). We also must add DSP TBR interrupt addresses and uncomment all entries, change comments in fr.cfg.
The default handler (same as all unused IRQs?) seems like a debugging hook. It basically calls @r12 that it gets as argument, but performs some conditional action besides. And finishes with infinite loop instead of ret/reti. weird.
QuoteQuote:

Worse thing is that is you see on my screenshot above, it have
call @r0 thing, and this is also quite common and much worse.
Exremely hard to understand.
even call:D @r0 to make things more confusing with delayed instructions. It takes some time to get used to those RISC quirks like delayed branches.

Last edited by zezo; 08-13-2009 at 11:36 AM.
08-13-2009, 12:01 PM   #277
Veteran Member




Join Date: Jul 2009
Location: Russia
Posts: 343
Original Poster
QuoteOriginally posted by zezo Quote
The default handler (same as all unused IRQs?) seems like a debugging hook. It basically calls @r12 that it gets as argument, but performs some conditional action besides. And finishes with infinite loop instead of ret/reti. weird.
You are wrong here.
ROM:10003F00 10 04 90 44 .long loc_10049044 ; int 64
This is from GX20 v1.02.
And this procedure is big.
Btw, FR module is unable to disassembly it till the end.
"ROM:10049276 97 .byte 0x97 ;
ROM:10049277 DD .byte 0xDD ;
ROM:10049278 C2 .byte 0xC2 ; T
ROM:10049279 0B .byte 0xB
ROM:1004927A AA .byte 0xAA ; "

Unable to make code from this :-)

QuoteQuote:
even call @r0 to make things more confusing with delayed instructions. It takes some time to get used to those RISC quirks like delayed branches.
I don't see much trouble with delayed execution. But can be wrong here.
08-13-2009, 12:24 PM   #278
New Member




Join Date: Aug 2009
Location: Sofia
Posts: 22
QuoteOriginally posted by tr13 Quote
You are wrong here.
ROM:10003F00 10 04 90 44 .long loc_10049044 ; int 64
Quite possible. I was thinking about 256-enty interrupt table at 10003C00
That would make int 64 at 10003D00, but I'm not up to speed yet, so correct me if I'm wrong.
QuoteQuote:
I don't see much trouble with delayed execution. But can be wrong here.
Not a problem. Just takes some time to notice the :D and its side effects at first. Sometimes a piece of code makes no sense at all until you see the :D and the following instruction. Hopefully ld cannot follow the corresponding @r call, so it does not confuse the analysis ;)

08-13-2009, 12:58 PM   #279
Veteran Member




Join Date: Jul 2009
Location: Russia
Posts: 343
Original Poster
QuoteOriginally posted by zezo Quote
Quite possible. I was thinking about 256-enty interrupt table at 10003C00
That would make int 64 at 10003D00, but I'm not up to speed yet, so correct me if I'm wrong.
Look at my site under Firmware Info. Interrupt go in reverse order from 255 till 0, each offest takes four bytes. So, this is 65th from bottom.

QuoteQuote:
Not a problem. Just takes some time to notice the and its side effects at first. Sometimes a piece of code makes no sense at all until you see the and the following instruction. Hopefully ld cannot follow the corresponding @r call, so it does not confuse the analysis
COuld you provide us some primers, please?
Look very interesting.
08-13-2009, 01:33 PM   #280
New Member




Join Date: Aug 2009
Location: Sofia
Posts: 22
Delayed branch/jump just means that the instruction following the call:D is executed before the jump for better pipeline utilization, and that's heavily used by the compiler reordering optimiser.
Code:
Trivial example:

ROM:105617C2 ldi:32 #sub_105D4E64, r12
ROM:105617C8 call:D @r12
ROM:105617CA ld @r8, r4

Effective order of execution:

ldi:32 #sub_105D4E64, r12
ld @r8, r4
call @r12

Not so trivial example with conditional jump:

ROM:10561822 cmp #1, r0
ROM:10561824 beq:D loc_1056182A
ROM:10561826 ldi:8 #1, r2

Effective order of execution:

ldi:8 #1, r2
cmp #1, r0
beq loc_1056182A

It's easy to miss the ldi:8 here.

Delayed instructions are subject to some restrictions that don't break the
pipeline - something like register-register and short immediate-register ops only.

It does not make sense writing

call:D @r12
ldi:32 #sub_105D51CA, r12

because the CPU has to fetch the 32-bit value and stall the pipeline anyway.
Hope that it makes some sense ;)
08-13-2009, 01:42 PM   #281
New Member




Join Date: Aug 2009
Location: Sofia
Posts: 22
QuoteOriginally posted by tr13 Quote
Look at my site under Firmware Info. Interrupt go in reverse order from 255 till 0, each offest takes four bytes. So, this is 65th from bottom.
Ouch. You're right. That's why it did not make sense assigning the same sub for syscall and unhandled interrupts.

BTW 97D is undefined opcode in CM71-00101-4E so it's some later CPU in gx20

Last edited by zezo; 08-13-2009 at 01:51 PM.
08-13-2009, 04:10 PM   #282
Pentaxian
Class A's Avatar

Join Date: Aug 2008
Location: Wellington, New Zealand
Posts: 9,193
QuoteOriginally posted by zezo Quote
Effective order of execution:

ldi:32 #sub_105D4E64, r12
ld @r8, r4
call @r12
Yes, but note that if the delayed instruction had manipulated @r12, it would not have affected the target address for the call.

Have you seen this FR60 MB91350A Series HARDWARE MANUAL (see p. 68)? While it is not exactly the one needed, I guess it still should be useful.

QuoteOriginally posted by zezo Quote
Effective order of execution:

ldi:8 #1, r2
cmp #1, r0
beq loc_1056182A
I think you've got ldi:8 and cmp swapped.
08-13-2009, 04:24 PM   #283
New Member




Join Date: Aug 2009
Location: Sofia
Posts: 22
QuoteOriginally posted by Class A Quote
Yes, but note that if the delayed instruction had manipulated @r12, it would not have affected the target address for the call.
That's exactly one of the forbidden post-delayed instructions, so you shound not really do that:

Instructions Prohibited in Delay Slots
The following instructions may not be used in delayed branching processing by the FR family CPU.
LDI:32 #i32,Ri LDI:20 #i20,Ri

But we are getting into architectures here which was not the purpose of the post. The manual explains it pretty well with pipeline state diagrams and everything.

QuoteQuote:

I think you've got ldi:8 and cmp swapped.
That was on purpose. The code would look like that if written by human and not by compiler. Instructions refer to different registers and the LD does not affect the flag register, so order does not really matter, but it's more logical this way.
08-13-2009, 05:33 PM   #284
Veteran Member
Das Boot's Avatar

Join Date: Feb 2008
Location: Sparkle City, South Cackalacky
Photos: Gallery
Posts: 689
Is there a performance gain from coding this way - a reduction in clock cycles? Or is it something the compiler does to throw people off reversing the code? I don't have a problem with it, it's kind of like comparing two programs written in Motorola and Intel convention.
08-13-2009, 06:20 PM   #285
Pentaxian
Class A's Avatar

Join Date: Aug 2008
Location: Wellington, New Zealand
Posts: 9,193
QuoteOriginally posted by zezo Quote
The manual explains it pretty well with pipeline state diagrams and everything.
Which manual are you using?
I'm not actively involved in re-engineering the code, just curious about this RISC language.
When I look at the disassembled code my fingers start itching since it seems to be rather straightforward to lift the code to a higher level of abstraction, but unfortunately I have no time for this.

QuoteOriginally posted by zezo Quote
That was on purpose. The code would look like that if written by human and not by compiler.
Sure but strictly speaking it is not the "effective execution order" (even though the order doesn't matter in this case).


QuoteOriginally posted by Das Boot Quote
Is there a performance gain from coding this way - a reduction in clock cycles?
Yes, no obfuscation intent here. These special instructions just help the RISC CPU to keep its pipeline filled. In general, a pipeline can execute n operations each requiring m seconds in sometimes considerably less then n*m seconds, provided the pipeline doesn't run out of operations to execute.
Reply

Bookmarks
  • Submit Thread to Facebook Facebook
  • Submit Thread to Twitter Twitter
  • Submit Thread to Digg Digg
Tags - Make this thread easier to find by adding keywords to it!
camera, check, dslr, firmware, fr, ida, information, k-x, pentax, photography, pm, post, progress, script, site, software, update, ver, version
Thread Tools Search this Thread
Search this Thread:

Advanced Search


Similar Threads
Thread Thread Starter Forum Replies Last Post
DFS hack eccentricphotography Pentax DSLR Discussion 24 10-12-2010 11:08 AM
Yet another hack job -- OM to PK ?? RioRico Pentax SLR Lens Discussion 15 10-07-2010 07:49 AM
K20D Firmware Ver - Pentax Web Site Ver? ChipB Pentax DSLR Discussion 2 02-23-2010 04:14 PM
Teleconverter hack? Raptorman Pentax SLR Lens Discussion 4 01-20-2010 03:51 AM
News Site News and Site Suggestions hidden from guests Adam Site Suggestions and Help 0 11-30-2009 12:38 AM



All times are GMT -7. The time now is 07:46 AM. | See also: NikonForums.com, CanonForums.com part of our network of photo forums!
  • Red (Default)
  • Green
  • Gray
  • Dark
  • Dark Yellow
  • Dark Blue
  • Old Red
  • Old Green
  • Old Gray
  • Dial-Up Style
Hello! It's great to see you back on the forum! Have you considered joining the community?
register
Creating a FREE ACCOUNT takes under a minute, removes ads, and lets you post! [Dismiss]
Top