reyalp
No, they are global variables in RAM. If you look at the boot process, it copies initialized globals starting at 0x1900, followed by the firmware BSS. If canon added a global variable between different firmware versions, the addresses will change.
I'll have to go look at the boot process in detail for educational purposes. If nothing else it will help me learn to read the ARM instructions faster.
To find them, you need to find the ROM code where they are referenced. Sometimes you can just search for the value (as a sequence of bytes) in an existing port, find references to that, and then find the corresponding code in your new port. In other cases the address we use is actually a member of a structure (or array) and so the address only referenced as some other pointer plus a constant in the canon code. Some of the ports have comments on how the various addresses are found. I tried to do this for everything I found in the
SD990 port.
Ok, so I'm working on the stubs_min.S for the 1.01b port now. My guess is that not much has changed because so far nobody has found anything horribly broken (from what it sounds like) and I didn't change anything in that file, but I want to understand this anyway so....
Looking at, for example, from the 1.02b port:
DEF(zoom_busy, 0x90E4 + 0x1C)
Based on the way that's written, it sounds like a struct. So I search for 0x90e4 in the 102b code and the most applicable hit looks like:
ROM:FF9409B4 zoomStructLoc DCD 0x90E4 ; DATA XREF: sub_FF94078C+4r
ROM:FF9409B4 ; ROM:FF940828r ...
(I then gave it that name.) So then I look for xrefs to this and find a bunch of stuff.
All the xrefs look pretty much the same. They're all "LDR R4, =0x90E4" etc. Looks like the usual setup for load register from indexed addressing mode stuff. So I'll just pick one.... The first thing (address wise) using this in 1.02b looks like:
ROM:FF94078C sub_FF94078C ; CODE XREF: taskcreate_FirmTransferWaitTask+64p
ROM:FF94078C STMFD SP!, {R4,LR}
ROM:FF940790 LDR R4, =0x90E4
ROM:FF940794 LDR R0, [R4,#4]
ROM:FF940798 CMP R0, #0
ROM:FF94079C LDMNEFD SP!, {R4,PC}
ROM:FF9407A0 BL sub_FF941600
ROM:FF9407A4 MOV R1, #1
ROM:FF9407A8 MOV R0, #0
...
ROM:FF9407C4 MOV R0, #0
ROM:FF9407C8 STR R0, [R4,#0x1C]
ROM:FF9407CC STR R0, [R4,#0x14]
ROM:FF9407D0 STR R0, [R4,#0x18]
ROM:FF9407D4 ADR R0, aZoomlens ; "ZoomLens"
...
So I try to pick some stuff such as 0x...0794 - 0x...079f = 04 00 94 E5 00 00 50 E3 10 80 BD 18 which probably won't change unless maybe the compiler decides to use different registers or something, then search for that in 101b:
Well, that sequence looks pretty damn common which I shouldn't be too horribly surprised about I guess. I get about 20 hits or something. It looks like one distinguishing feature of this sub is that it references a string that looks like "ZoomLens", so I click through the hits until I find what looks like the same thing in 101b:
ROM:FF94078C sub_FF94078C ; CODE XREF: taskcreate_FirmTransferWaitTask+64p
ROM:FF94078C STMFD SP!, {R4,LR}
ROM:FF940790 LDR R4, =0x90E4
ROM:FF940794 LDR R0, [R4,#4]
ROM:FF940798 CMP R0, #0
ROM:FF94079C LDMNEFD SP!, {R4,PC}
ROM:FF9407A0 BL sub_FF941600
ROM:FF9407A4 MOV R1, #1
ROM:FF9407A8 MOV R0, #0
ROM:FF9407AC BL sub_FF827D8C
ROM:FF9407B0 STR R0, [R4,#0x40]
...
ROM:FF9407C4 MOV R0, #0
ROM:FF9407C8 STR R0, [R4,#0x1C]
...
ROM:FF9407D4 ADR R0, aZoomlens ; "ZoomLens"
Which just happens to be exactly the same (which I really already knew because I diffed the disasm and knew that anything before 0xFFA9xxxx or so hadn't significantly changed).
So if the 0x90E4 had changed I should see something like "LDR R4, =0x90F0", and if the 0x1c had changed then I'm not sure how I'd know from this function because it looks like it's just initializing these struct members with 0's. So to check the index into the struct I suppose I'd need to find something that makes a more meaningful reference to that member.
Looking through the xref'd code for that, I see a bunch of things storing #1 or #0 in 0x1c, loading 0x1c, CMPing it with #0 and running conditional instructions, asserting if it's not 0 in certain places, etc. That seems to make sense for something that's supposed to be "zoom_busy" because it's getting 1 or 0 stored in it, and getting compared against 0 a lot which means it's being used as a boolean. GiveSemaphore is also getting called.... Anyway, basically seems to make sense though I'm not sure exactly how it was originally found.
So anyway, am I essentially going about this the right way?
