chdk in the DIGIC6 world - page 18 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 ... 13 14 15 16 17 [18] 19 20 21   Go Down

chdk in the DIGIC6 world

  • 201 Replies
  • 136591 Views
*

Offline reyalp

  • ******
  • 13878
Re: chdk in the DIGIC6 world
« Reply #170 on: 07 / December / 2019, 19:10:38 »
Advertisements
Quote from: srsa_4c on 07 / December / 2019, 14:15:08
Quote from: reyalp on 06 / December / 2019, 17:12:36
"DRYOS version 2.3, release #0059+p3" is also present.
Interesting. That belongs to a blob that appears to be an alternative firmware for the main core. It starts at 0xfd260000. It has several references, one from ExecuteInitFactorySetting_FW. Also present in M100.
finsig_thumb2 now lists all the DryOS versions it can find in stubs. The digic 7 EOS cameras have 6!
Code: [Select]
// Found DryOS versions:
// 0xe001a0a8 other "DRYOS version 2.3, release #0059+p4"
// 0xe05b0a90 main  "DRYOS version 2.3, release #0059+p4"
// 0xe0cd4d08 other "DRYOS version 2.3, release #0059+p4"
// 0xe0f767b4 other "DRYOS version 2.3, release #0059+p3"
// 0xe143f868 other "DRYOS version 2.3, release #0059+p4"
// 0xe1e60360 other "DRYOS version 2.3, release #0054"

It now attempts to identify the main one by searching for a pointer to one of the strings (relatively) near the start of the main firmware code. The same is done for ctypes. Using the wrong ctypes wouldn't hurt CHDK, but it's useful to see it in disassembly.

It also uses the main ROM version string as the end of code instead of ctypes. Weirdly, SX730 seems to be the only camera in the dumps I have that put the Omar firmware between the end of ROM code and the main ctypes.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #171 on: 08 / December / 2019, 08:44:52 »
Quote from: srsa_4c on 07 / December / 2019, 14:15:08
It starts at 0xfd260000. It has several references, one from ExecuteInitFactorySetting_FW.
That is a quite useful blob. It loads to RAM at 0x8000, using the same facility that diskboot and fw updater use. Has the full set of flash manipulation routines, providing nice base for a disaster recovery tool for cameras that don't have an official fw upgrade.
It also exports a function named "Remove" as eventproc. That function is also present in main firmware, providing an alternative for removing a file.

edit:
In new D4+ cams, ExecuteInitFactorySetting_FW reboots the main firmware with a boot flag (0x23456789) set, to take care of resetting settings.
« Last Edit: 08 / December / 2019, 08:57:12 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #172 on: 22 / December / 2019, 11:01:39 »
I'm not sure which is the best place to post this, but it concerns D6 and D7 ports.

It turns out, unaligned LDR PC instructions need to be avoided (it's not the instruction itself that is a problem, but the constant's alignment).
The relevant excerpt from "ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition" is:
Quote
A3.2.2
(...)
Any load instruction that is not faulted by the alignment restrictions and that loads the PC has UNPREDICTABLE behavior if it the address it loads from is not word-aligned. (sic)
That means, if you're going to patch CreateTask that is not on a word aligned address, you need to make a patch like following (and patch 2.5 words):
Code: [Select]
// CreateTask patch, must be aligned as the original
        ".align  2\n"
        ".short 0\n"                        // added for alignment
"patch_CreateTask:\n"
        "ldr.w   pc, _createtask_my\n"      // Do jump to absolute address CreateTask_my
        ".short 0\n"                        // added for alignment
"_createtask_my:\n"
        ".long   CreateTask_my + 1\n"
Logged
*

Offline srsa_4c

  • ******
  • 4451
DIGIC7, MMU
« Reply #173 on: 29 / December / 2019, 11:49:48 »
A few notes about memory translation on DIGIC 7.

The translation tables are in ROM (initially), occupying the 0xe0000000...0xe0004900 area. The first 0x80 bytes are used for other purposes (ARM code, data), 2 separate core-specific L1 tables are used to define that memory range.
The bootloader copies those 0x4900 bytes to 0xdffc0000 (which is a TCM-like area, 256kB 160kB in length). That's the reason why the main fw's large code blob is copied to 0xdffc4900. The RAM copy of the tables is identical to the ROM version, except for the addresses of the 2 (core specific) L2 tables which are adapted to point to the RAM copy.
MMU related routines are located in the small RAM code blob (0x1900000-).
*As far as I can tell, the ROM tables are used when the main firmware starts booting and the RAM copy is used after that.

The structure of those 0x4900 bytes in M100 (and probably the other D7 cams):
0...0x3fff: TTBR1 table, 0x80 bytes at the beginning are not table data
0x4000...0x43ff: L2 table, core0
0x4400...0x47ff: L2 table, core1
0x4800...0x487f: TTBR0 table, core0, first entry points to the core0 L2 table
0x4880...0x48ff: TTBR0 table, core1, first entry points to the core1 L2 table

edit:
*I queried TTBR0 and TTBR1 on a running M100, and found that the ROM tables are used. The RAM copy is used while the ROM is written.
edit2:
The RAM area at 0xdffc0000 (actually, mirrored 4 times in the 0xdff00000 range) is only 160kB long, the rest is not implemented.
« Last Edit: 18 / August / 2020, 14:58:42 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 13878
Re: chdk in the DIGIC6 world
« Reply #174 on: 04 / January / 2020, 02:39:11 »
Just for fun, here's code to run the CPUID instruction on sx730 100d Omar core. The code and commands to produce the necessary blobs are in comments.

The result is 0x411fc143 = Cortex-R4, just like the main core. I expect it's not an identical core though. It appears to have a 2k TCM which gets configured at 0x8000800 and used for stack in the startup code (edit: stack starts at 0x8000800, TCM is larger). I don't think there's any reason to run this on other d6 cams. d7 seems quite different.

I haven't tried, but we might be able to just modify the code in memory before the final *(d20f0110)=3.

The camera seemed to operate normally with the patch, for one test shot at least.
« Last Edit: 08 / January / 2020, 12:49:32 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #175 on: 04 / January / 2020, 16:23:39 »
Quote from: reyalp on 04 / January / 2020, 02:39:11
Just for fun, here's code to run the CPUID instruction on sx730 100d Omar core.
Nice. I guess it should be possible to get the whole set of registers that cpuinfo collects and evaluate their dump. And maybe a speedtest, although clocks might change more than on the primary core.
Logged
*

Offline reyalp

  • ******
  • 13878
Re: chdk in the DIGIC6 world
« Reply #176 on: 04 / January / 2020, 18:51:48 »
Quote from: srsa_4c on 04 / January / 2020, 16:23:39
Nice. I guess it should be possible to get the whole set of registers that cpuinfo collects and evaluate their dump. And maybe a speedtest, although clocks might change more than on the primary core.
Yes, I think we could just run the cpuinfo_get_info code, and process the buffer in the main core as normal.

One issue is finding a place to put it that doesn't overwrite anything important. For this test, I just used some strings that aren't likely to be used in normal operation. I *think* omar can access the whole regular RAM, so we could just umalloc something on the in the main firmware, but I haven't verified how the MPU is configured yet. On sx730, this appears to be done around 0000013c. It also seems to access the same MMIOs as the main core.

I tried writing to the 0xdff* that maps to omar TCM after it's initialized. It seems to work, values set read back in the main firmware, although I haven't verified that the changes are seen inside the omar core.

It should be relatively easy to make a sig finder for omar dryos, to get the usual task / message queue / eventflag stuff. Adding a task hook would be easy too, since everything is in RAM. Modifying existing tasks would be much easier too. I don't have a good reason to run anything on it at the moment.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #177 on: 05 / January / 2020, 16:30:41 »
Quote from: reyalp on 04 / January / 2020, 18:51:48
One issue is finding a place to put it that doesn't overwrite anything important.
On sx280, the unoccupied space in the 0xdff00000 area seems untouched, also, areas reserved for other cores are usually generously sized.
Quote
Adding a task hook would be easy too, since everything is in RAM.
A possible issue is missing basic kernel functions. The Omar fw in sx280 does not seem to include SleepTask, for example. Fortunately, other functions such as TakeSemaphore can be used as replacement and its low level version is also available.
Quote
I don't have a good reason to run anything on it at the moment.
Me neither. I could imagine using it for drawing the overlay or compressing something. But we don't know its speed.

edit
As it turns out, the sx280 Omar fw does not complete its initialization until there's demand - a face ID related function has to be used. Nope. It does run, but changed data (0x406xxxxx) appears to fit in cache without workload(?)

edit2
Previous edit corrected.
« Last Edit: 08 / January / 2020, 11:15:55 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #178 on: 08 / January / 2020, 11:31:33 »
Quote from: reyalp on 04 / January / 2020, 18:51:48
Quote from: srsa_4c on 04 / January / 2020, 16:23:39
Nice. I guess it should be possible to get the whole set of registers that cpuinfo collects and evaluate their dump. And maybe a speedtest, although clocks might change more than on the primary core.
Yes, I think we could just run the cpuinfo_get_info code, and process the buffer in the main core as normal.
I managed to get cpuinfo, finally. Resulting cpuinfo.txt files (main core and omar) and the patch for sx280 is attached.
To actually run the cpuinfo code on omar, an address (from omar's view) has to be written to 0xdff03ffc. I used 0x3000 which appeared at 0xdff03000 from main core. I put the resulting bytes in a file and used the patched cpuinfo module for evaluation.
One thing that stands out is that omar seems to have a 32kB ATCM vs 16kB on main core.
Logged
*

Offline reyalp

  • ******
  • 13878
Re: chdk in the DIGIC6 world
« Reply #179 on: 08 / January / 2020, 13:30:59 »
Quote from: srsa_4c on 08 / January / 2020, 11:31:33
I managed to get cpuinfo, finally. Resulting cpuinfo.txt files (main core and omar) and the patch for sx280 is attached.
Nice work.
Quote
To actually run the cpuinfo code on omar, an address (from omar's view) has to be written to 0xdff03ffc. I used 0x3000 which appeared at 0xdff03000 from main core. I put the resulting bytes in a file and used the patched cpuinfo module for evaluation.
One thing that stands out is that omar seems to have a 32kB ATCM vs 16kB on main core.
Which seems a bit odd, even the lower 16K doesn't seem to be close to fully used, and the BTCM only obviously uses the lower 2k for exception stack. The code referencing the *TCM_START_ADDR and END_ADDR matches the values from CPU info.

For hooking the main blob, we could avoid needing to allocate a full copy by doing the patch from Omar in the small ATCM blob before the initial jump to RAM code.

An oddity in the MPU regions is the 64M starting at 0xEC...
Logged
Don't forget what the H stands for.
Pages: 1 ... 13 14 15 16 17 [18] 19 20 21   Go Up
« previous next »
 

Related Topics