I added some information about Omar to the wiki
https://chdk.fandom.com/wiki/Digic_6_PortingI ended up re-discovering much what what srsa_4c wrote way back on
https://chdk.setepontos.com/index.php?topic=11316.msg119473#msg119473 because SX730 puts the Omar firmware in the main firmware data area *before* the ctypes for the main firmware. This causes the sig finder to pick up the Omar ctypes, and also breaks my assumption that the main firmware code ends around ctypes. I'm on updating finsig_thumb2 to deal with this now.
Some additional notes:
Omar is initialized from a very simple table in ROM, which looks like (sx710 101a)
0xdff00000 - target address for Omar TCM (mapped to 0 in Omar address space)
0xfc56bef0 - source address for Omar TCM code
0x00000ed0 - length of Omar TCM data
0x40700000 - uncached target address for Omar main code (Omar sees it as 0x700000)
0xfc56cdc0 - source address for Omar main code
0x0004f1c4 - length of Omar code
This is used by a function fc53a0b4 which is called via fc055ff0 from task_Startup.
Since all the code is in RAM, and it's initialized from a task we already control, running custom code on Omar should be quite easy. Not sure what we'd do with it, but it would be interesting to run cpuinfo at least.
You can load the Omar code in Ghidra easily, just using the offsets from the table described above and loading one chunk as an additional file. armv7le seems to do an adequate job.
Edit:
Another note: SX730 contains 3 *different* DryOS versions:
Omar and Marius are "DRYOS version 2.3, release #0059+p4"
Zico appears to be "DRYOS version 2.3, release #0058+p8"
and "DRYOS version 2.3, release #0059+p3" is also present.
This also has the potential to confuse the sig finder.