placing ML into shoot memory

[g3gg0]

i decided to start a thread about this topic.

in canon's firmware we have three options how to allocate memory and where to place data.

1) malloc
2) AllocateMemory (MemoryManager)
3) AllocateMemoryResource (RscMgr, Srm)

1) malloc
the first one, malloc, i am not sure where the memory is located and where it gets initialized. maybe alex can give some hint.


2) AllocateMemory
the second, AllocateMemory is a memory pool between 0x3D0000 and 0xD00000 on 7D and a few others.
its structures contain a reference to the string "MemoryManager".
it's initialized on startup right after "K250S READY" is written to debug port.
 > AllocateMemory_Init(&off_3D0000, 0xD00000)
the structure for every memory is 0x0C bytes big block starts with a pointer to next block, then a poiner to previous block.

Magic Lantern was either placed in malloc or in AllocateMemory region by patching the end address for initialization calls


3) AllocateMemoryResource
the new method that was tested on 60D and 7D in the last days is based on shooting memory where images get buffered when shooting until they are saved to card.
the manager that handles all requests is called RscMgr (ResourceManager) and closely tied to Srm (StorageManager?)

this memory is usually fragmented, which means you cannot simply allocate 1 MiB in one piece.
well, this might succeed, but you are likely to get a list of memory blocks that are in sum your requested size.
the good thing is, you can allocate up to 250 MiB depending on your camera.

it is initialized like that:
>    v3 = SRM_Initialize(0x13, 0x40D00000u, 0x1F300000, (int)StartupSequencer_NotifyComplete, 0x20000, startupCacheFreeCallback, 0);
>    if ( v3 )
>        DryosDebugMsg(0x8B, 6, (char *)&"SRM_Initialize (%#x)", v3);

the value 0x40D00000 tells the start address (0x00D00000 uncached) and its length (the rest of the memory).
so this memory region starts right after the AllocateMemory region-
some will notice that the LV buffers etc are also within that memory range. right. not sure yet how RscMgr manages
the memory chunks and which "application" gets which buffer.
it is likely that the RscMgr has some addresses like the LV buffers hardcoded.

as we now can patch the end of the RscMgr memory pool, simply by replacing 0x1F300000 with 0x1F200000, we
get some memory (2 MiB) at 0x1F200000 that remains unused.

what has to be checked, is the question if the LV buffers or some other memory users that RscMgr handles,
use hardcoded addresses and we cause trouble to them this way.
until now it looks stable.

[nanomad]

Thanks g3gg0, I'm off finding the right memory locations on the 1100D

So, from the 650D code:

Code: [Select]

ROM:FF0C44C8                 LDR     R0, =StartupSequencer_NotifyComplete
ROM:FF0C44CC                 LDR     R2, =startupCacheFreeCallback
ROM:FF0C44D0                 MOV     R3, #0
ROM:FF0C44D4                 MOV     R1, #0x20000
ROM:FF0C44D8                 STMEA   SP, {R0-R3}
ROM:FF0C44DC                 LDR     R3, =0x1F2C4000
ROM:FF0C44E0                 LDR     R2, =0x40D3C000
ROM:FF0C44E4                 LDR     R0, =0xC0220068
ROM:FF0C44E8                 MOV     R1, #0x12
ROM:FF0C44EC                 BL      SRM_Initialize

1100D/600D Code (600D starts at ROM:FF01360C)

Code: [Select]

ROM:FF0135FC                 LDR     R0, =StartupSequencer_NotifyComplete
ROM:FF013600                 MOV     R3, #0
ROM:FF013604                 ADR     R2, startupCacheFreeCallback
ROM:FF013608                 MOV     R1, #0x20000
ROM:FF01360C                 STMEA   SP, {R0-R3}
ROM:FF013610                 LDR     R3, =0x1F300000
ROM:FF013614                 LDR     R0, =0xC0220098
ROM:FF013618                 MOV     R1, #0x12
ROM:FF01361C                 RSB     R2, R3, R3,LSL#9
ROM:FF013620                 BL      SRM_Initialize


[g3gg0]

now you have to patch the DATA for the LDR. this is the address where the LDR     R3, =0x1F300000 gets the 1F3000000 from.
should be right below the function.
> #define RSCMGR_MEMORY_PATCH_END          0xF80.....   (yes, 0xF800!!! also on your cameras)

interesting that the 650D has 0x1F2C4000 bytes only.... hmm

after you defined that struct, make sure you set RESTARTSTART to 0x1FE00100  (original value minus 2MiB)

[nanomad]

Am I correct in assuming that we need to patch both the start and end addresses on the 1100D/600D otherwise it may not work properly?

If I only patch LDR R3 , the 0x40D00000 becomes 0x20E00000 (wrong caching bit and a possible waste of memory)

[g3gg0]

no, just patch the end address.

change 0x1F300000 to 0x1F100000, do not touch the start address

[g3gg0]

if you are interested where the LV buffer addresses come from, here the code that initializes the addresses.

Code: [Select]

int __fastcall RscMgr_Init(int zero_1, int zero_2, int priority, unsigned int rscMemoryBase, int memSize, int some_sub, int some_size_maybe, int (__fastcall *startupCacheFreeCallback)(int, int, int, int), int zero)
{
    // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]

    result = (int)RscMgr;
    if ( !RscMgr )
    {
        pRscMgr_ = (struc_RscMgr *)AllocateMemory(0x2B4);
        pRscMgr = pRscMgr_;
        if ( !pRscMgr_ )
            assert("pRscMgr != NULL", "RscMgr.c", 0xD2);
        pRscMgr_->name = "RscMgr";
        task = CreateTaskClass((_BYTE *)"RscMgr", priority, 0, 0xC8, srmEventDispatch);
        pRscMgr->hTaskClass = task;
        if ( task & 1 )
            assert("IS_ERROR( pRscMgr->hTaskClass ) == FALSE", "RscMgr.c", 0xD6);
        pRscMgr->field_C = zero_1;
        srmState = CreateSRMState(pRscMgr);
        pRscMgr->hCurrentStateObject = srmState;
        if ( srmState & 1 )
            assert("IS_ERROR( pRscMgr->hCurrentStateObject ) == FALSE", "RscMgr.c", 0xDA);
        if ( SearchFromProperty(0x3003E, (signed int)&pPropData, (int)&v43, v15) & 1 )
            assert("IS_ERROR( err ) == FALSE", "RscMgr.c", 0xDD);
        property_data = *(_DWORD *)pPropData;
        RscMgr = pRscMgr;
        pRscMgr->memAddr = rscMemoryBase;
        pRscMgr->memSize = memSize;
        pRscMgr->YUV422_LV_BUFFER_1.address = rscMemoryBase + property_data + 0xE00000;
        v17 = property_data + (((rscMemoryBase >> 0x19) + 1) << 0x19);
        pRscMgr->YUV422_LV_BUFFER_2.address = v17 + 0x1A300000;// 0x42000000 +
        pRscMgr->YUV422_LV_BUFFER_3.address = v17 + 0x1D116000;// 0x42000000 +
        pRscMgr->YUV422_LV_BUFFER_1.flags = 0xFFFFFFFF;
        pRscMgr->YUV422_LV_BUFFER_2.flags = 0xFFFFFFFF;
        pos = 0;
        pRscMgr->YUV422_LV_BUFFER_3.flags = 0xFFFFFFFF;
        do
        {                                       // code below refers to ->buf_smth_0 up to ->buf_smth_15
            addr = ((((unsigned int)pRscMgr->memAddr >> 0x19) + 1) << 0x19) + 0x36000 * pos + 0x1AA23980;
            v20 = (unsigned int *)((char *)pRscMgr + 8 * pos++);
            v20[0x29] = addr;
            v20[0x2A] = 0xFFFFFFFF;
        }
        while ( pos < 8 );
        pos = 0;
        do
        {
            addr = ((((unsigned int)pRscMgr->memAddr >> 0x19) + 1) << 0x19) + 0x36000 * pos + 0x1D588780;
            v23 = (unsigned int *)((char *)pRscMgr + 8 * pos++);
            v23[0x39] = addr;
            v23[0x3A] = 0xFFFFFFFF;
        }
        while ( pos < 8 );
        v24 = j_CreateMessageQueue("MEMORY_QUEUE_SRM", 6, 4);
        RscMgr->hMemoryQueue = v24;
        if ( v24 & 1 )
            assert("IS_ERROR( this->hMemoryQueue ) == FALSE", "RscMgr.c", 0xF7);
        v25 = j_CreateMessageQueue("STORAGE_QUEUE_SRM", 3, 4);
        RscMgr->hStorageQueue = v25;
        if ( v25 & 1 )
            assert("IS_ERROR( this->hStorageQueue ) == FALSE", "RscMgr.c", 0xFA);
        DryosDebugMsg(
            0x80,
            0x16,
            (char *)"hMemoryQueue (0x%X) hStorageQueue (0x%X)",
            RscMgr->hMemoryQueue,
            RscMgr->hStorageQueue);
        if ( SearchFromProperty(2, (signed int)&prop_data, (int)&v43, v26) & 1 )
            assert("IS_ERROR( err ) == FALSE", "RscMgr.c", 0xFF);
        v27 = RscMgr;


[nanomad]

EOSM, While the VM boots up

Code: [Select]

ROM:FF0C47D0                 LDR     R0, =StartupSequencer_NotifyComplete
ROM:FF0C47D4                 LDR     R2, =startupCacheFreeCallback
ROM:FF0C47D8                 MOV     R3, #0
ROM:FF0C47DC                 MOV     R1, #0x20000
ROM:FF0C47E0                 STMEA   SP, {R0-R3}
ROM:FF0C47E4                 LDR     R3, =0x1F294000
ROM:FF0C47E8                 LDR     R2, =0x40D6C000
ROM:FF0C47EC                 LDR     R0, =0xC0220068
ROM:FF0C47F0                 MOV     R1, #0x12
ROM:FF0C47F4                 BL      SRM_Initialize

Looks like 650D family cameras have less memory in this pool

[g3gg0]

yep, same here. subtract 2MiB from that 0x1F294000 and see if it crashes

[nanomad]

I'm still not totally convinced about patching only the end address though...
Any reason why we can't fix the start one at the correct location?

[g3gg0]

why would we want to change the start address?
we want to make RscMgr's memory pool smaller to use it partially for magic lantern.
thats the reason why we cut 2 megabytes from the end

[nanomad]

But since the start address is computed from the end address, aren't we ending up with a wrong start address too? (and wasting the memory between the old start and the new start)

(That is, if my computations aren't wrong)

[g3gg0]

btw, the RscMgr uses some data from the properties to determine some memory addresses.
  <Property Id="00000002" Length="000001E4">
    <String>Canon EOS 7D__...</String>
    <Data>
          43616E6F 6E20454F 53203744 00000000 00000000 00000000 00000000 00000000
          50020080 9A310000 F0140000 C00D0000 F0140000 BC0D0000 F0140000 BC0D0000
          300F0000 200A0000 200A0000 C0060000 300F0000 200A0000 200A0000 C0060000
          40140000 800D0000 800D0000 00090000 00000000 00000000 00000000 00000000
          200A0000 C0060000 40140000 800D0000 A0000000 78000000 9E020000 B0010000
          B0010000 20010000 B0010000 20010000 B0010000 20010000 B0010000 20010000
          A8000000 38000000 E7140000 B70D0000 00000000 00000000 2F0F0000 1F0A0000
          00000000 00000000 1F0A0000 BF060000 00000000 00000000 2F0F0000 1F0A0000
          00000000 00000000 1F0A0000 BF060000 15000000 00000000 9C020000 AF010000
          00000000 00000000 AF010000 1F010000 00000000 00000000 AF010000 1F010000
          00000000 00000000 AF010000 1F010000 00000000 00000000 AF010000 1F010000
          0010B446 333B6C46 02000000 C0060000 70070000 08000000 10050000 10050000
          05000000 60030000 60030000 08000000 10050000 10050000 05000000 60030000
          60030000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 B8040000 F0020000 F0080000 5A030000 F0080000
          5A030000
    </Data>
  </Property>

the red marked words of the properties are used to calculate some internal parmeter .


and this one determines the YUV buffer 1 start address

  <Property Id="0003003E" Length="00000004">
    <String>_x__</String>
    <Data>00780000</Data>
  </Property>

pRscMgr->YUV422_LV_BUFFER_1.address = rscMemoryBase + property_data + 0xE00000; // rscMemoryBase is 0x40D00000

the same property 0x3003E is also used in H264 codec as memory offset for some ENGIO operation.
the function PlayBack_H264DecForHdPath_c_H264DataSize get passed that parameter as 7th argument and
passes it again to AJ_stuff_Eng_IO_p3 which access EDMAC registers.

[g3gg0]

> SRM_Initialize(0x13, 0x40D00000u, 0x1F300000, (int)StartupSequencer_NotifyComplete, 0x20000, startupCacheFreeCallback, 0);

0x40D00000 is the start address
0x1F300000 is the length

now you change 0x1F300000 to 0x1F100000 and keep the start address the same.
nothing else changes.

[1%]

Code: [Select]

ROM:FF0C4510                 MOV     R1, #0x20000
ROM:FF0C4514                 STMEA   SP, {R0-R3}
ROM:FF0C4518                 LDR     R3, =0x1F2C4000
ROM:FF0C451C                 LDR     R2, =0x40D3C000
ROM:FF0C4520                 LDR     R0, =0xC02200B8
ROM:FF0C4524                 MOV     R1, #0x12
ROM:FF0C4528                 BL      sub_FF0EFDF4
ROM:FF0C452C                 CMP     R0, #0
ROM:FF0C4530                 MOVNE   R3, R0
ROM:FF0C4534                 ADRNE   R2, aSrm_initialize ; "SRM_Initialize (%#x)"

6D. So far no luck booting. Light stays solid.

Ok, I had to make clean, it wasn't taking the restart restart address. Now I boot without LV

#define RSCMGR_MEMORY_PATCH_END          0xF80C4518
RESTARTSTART   = 0x1FE00100

Code: [Select]

FF01361C: e88d000f stm sp, {r0, r1, r2, r3} ⬁
FF013620: e59f32b4 ldr r3, [pc, #692] ; 0xff0138dc: pointer to 0x1f300000 ⬁
FF013624: e59f02b4 ldr r0, [pc, #692] ; 0xff0138e0: pointer to 0xc0220098 ⬁
FF013628: e3a01012 mov r1, #18 ⬁
FF01362C: e0632483 rsb r2, r3, r3, lsl #9 ⬁
FF013630: eb0058ed bl AJ_SRM_Initialize

600D:
#define RSCMGR_MEMORY_PATCH_END 0xF8013620
#RESTARTSTART    = 0x1FF00100

I get a solid light and no boot.

[g3gg0]

600D: 0xF80138DC

dont patch the instruction. you have to patch the data word 0x1F300000.

[1%]

I tried
#define RSCMGR_MEMORY_PATCH_END 0xF80138DC
RESTARTSTART    = 0x1FF00100

Still get solid light

[g3gg0]

can you give 0xFF0138DC a try then?

edit: seems not to work.

[1%]

Yep, confirmed. Didn't work with FF.

for 6D maybe possible to take a whole MB out of allocatememory?

[g3gg0]

did you correct the RSCMGR address for 6D too? and still fails?

[1%]

I'll look and see if it has a dword. But no solid light just patching F80C4518.

0xff0c47a8: pointer to 0x1f2c4000

Changed this and still boots with no LV.

https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/commits/c65c6377a5593462812c493a5fddf6657f92c19b

https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/commits/f4b15f0551aacf06dfb7ac13098a63d678981265

[g3gg0]

as 6D has NSTUB(0xFF0C5438, init_task), you have to patch 0xFF01.....

[g3gg0]

btw now i understand what you meant with start address patching
i didnt notice that the start address is calculated based on length via RSB instruction to save space.

[g3gg0]

there we see all memory addresses the RscMgr handles.
memAddr is 0x40D00000.

    DryosDebugMsg(0x80, 0x16, &"--- Common Top ----");
    DryosDebugMsg(0x80, 0x16, &"IMGPLAY_WORK            0x%X 0x%08X %d", pRscMgr_->memAddr, 0xE00000, 0xE00000);
    DryosDebugMsg(0x80, 0x16, &"IMGVRAM1                0x%X 0x%08X %d", pRscMgr_->memAddr + 0xE00000, 0x410000, 0x410000);
    DryosDebugMsg(0x80, 0x16, &"DEVELOP_WORK            0x%X 0x%08X %d", pRscMgr_->memAddr + 0x1210000, 0x40000, 0x40000);
    DryosDebugMsg(0x80, 0x16, &"FENCING_WORK            0x%X 0x%08X %d", pRscMgr_->memAddr + 0x1250000, 0x10000, 0x10000);
    DryosDebugMsg(0x80, 0x16, &"LV_QUARK1               0x%X 0x%08X %d", pRscMgr_->memAddr + 0x1260000, 0x62780, 0x62780);
    memAddr = pRscMgr_->memAddr;
    DryosDebugMsg(0x80, 0x16, &"FREE1                   0x%X 0x%08X %d", memAddr + 0x12C2780, (((memAddr >> 0x19) + 1) << 0x19) - memAddr - 0x12C2780, (((memAddr >> 0x19) + 1) << 0x19) - memAddr - 0x12C2780);
    DryosDebugMsg(0x80, 0x16, &"EXMEM3_AREA             0x%X 0x%08X %d", ((pRscMgr_->memAddr >> 0x19) + 1) << 0x19, 0x1B00000, 0x1B00000);
    DryosDebugMsg(0x80, 0x16, &"FILE_HEADER             0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x3B00000, 0x400000, 0x400000);
    DryosDebugMsg(0x80, 0x16, &"BMPVRAM1                0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x3F00000, 0x80000, 0x80000);
    DryosDebugMsg(0x80, 0x16, &"BMPVRAM2                0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x3F80000, 0x80000, 0x80000);
    DryosDebugMsg(0x80, 0x16, &"--- Usually Mode ----");
    DryosDebugMsg(0x80, 0x16, &"MEMORY_MGR              0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x4000000, 0x18000000, 0x18000000);
    DryosDebugMsg(0x80, 0x16, &"---    NR Mode   ----");
    DryosDebugMsg(0x80, 0x16, &"NR_MEMORY_MGR           0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x4000000, 0x16000000, 0x16000000);
    DryosDebugMsg(0x80, 0x16, &"COMPOSITION_WORK_TOP    0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1A000000, 0x1116000, 0x1116000);
    DryosDebugMsg(0x80, 0x16, &"COMPOSITION_WORK_BOTTOM 0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1B116000, 0x1116000, 0x1116000);
    DryosDebugMsg(0x80, 0x16, &"---    DP Mode   ----");
    DryosDebugMsg(0x80, 0x16, &"DP_MULTI                0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x4000000, 0x8000000, 0x8000000);
    DryosDebugMsg(0x80, 0x16, &"DP_SINGLE               0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0xC000000, 0x10000000, 0x10000000);
    DryosDebugMsg(0x80, 0x16, &"--- Common Bottom ----");
    DryosDebugMsg(0x80, 0x16, &"IMGVRAM2                0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C300000, 0x410000, 0x410000);
    DryosDebugMsg(0x80, 0x16, &"DCFNO                   0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C710000, 0x4000, 0x4000);
    DryosDebugMsg(0x80, 0x16, &"LV_WB                   0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C714000, 0x2BC00, 0x2BC00);
    DryosDebugMsg(0x80, 0x16, &"LV_FACEYUV              0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C73FC00, 0xE1080, 0xE1080);
    DryosDebugMsg(0x80, 0x16, &"LV_HIST                 0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C820C80, 0x1880, 0x1880);
    DryosDebugMsg(0x80, 0x16, &"LV_ANGEL                0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C822500, 0x2080, 0x2080);
    DryosDebugMsg(0x80, 0x16, &"LV_FENCING              0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C824580, 0x20C80, 0x20C80);
    DryosDebugMsg(0x80, 0x16, &"ENGINE_MIRROR           0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C845200, 0x80000, 0x80000);
    DryosDebugMsg(0x80, 0x16, &"VSHADING_COMP_WORK      0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C8C5200, 0xDC000, 0xDC000);
    DryosDebugMsg(0x80, 0x16, &"DARKCUR_COMP_WORK       0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C9A1200, 0x20000, 0x20000);
    DryosDebugMsg(0x80, 0x16, &"LV_QUARK2               0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1C9C1200, 0x62780, 0x62780);
    DryosDebugMsg(0x80, 0x16, &"CAPTURE_WORK1           0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1CA23980, 0x1B0000, 0x1B0000);
    DryosDebugMsg(0x80, 0x16, &"FREE2                   0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1CBD3980, 0x316680, 0x316680);
    DryosDebugMsg(0x80, 0x16, &"AVERAGE_WORK_TOP        0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1CEEA000, 0x1116000, 0x1116000);
    DryosDebugMsg(0x80, 0x16, &"AVERAGE_WORK_BOTTOM     0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1E000000, 0x1116000, 0x1116000);
    DryosDebugMsg(0x80, 0x16, &"IMGVRAM3                0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1F116000, 0x410000, 0x410000);
    DryosDebugMsg(0x80, 0x16, &"LV_QUARK3               0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1F526000, 0x62780, 0x62780);
    DryosDebugMsg(0x80, 0x16, &"CAPTURE_WORK2           0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1F588780, 0x1B0000, 0x1B0000);
    DryosDebugMsg(0x80, 0x16, &"LV_MARGE_PDEF1          0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1F738780, 0x10000, 0x10000);
    DryosDebugMsg(0x80, 0x16, "LV_MARGE_PDEF2          0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1F748780, 0x10000, 0x10000);
    DryosDebugMsg(0x80, 0x16, "FREE3                   0x%X 0x%08X %d", (pRscMgr_->memAddr & 0xFE000000) + 0x1F758780, 0xFE000000 * (pRscMgr_->memAddr >> 0x19) + 0x408A7880, 0xFE000000 * (pRscMgr_->memAddr >> 0x19) + 0x408A7880);
}

[g3gg0]

okay some updates to this topic.
i investigated RscMgr and the memory areas it handles.
there are some good and some bad news...

good:
i understand RscMgr far better than before.

bad:
it doesnt work like thought it would work

bad:
memory addresses passed on initialization and total size is ignored for most blocks.
so we cannot simply make it smaller by changing the RscMgr memory size as i thought.

very good:
on 7D there is a 8MiB block unused memory at the end of RscMgr's RAM we can freely use.
we dont have to patch anything to use that memory.
also, we dont change anything to canons memory layout when using that memory.

good:
this could be true for other models aswell

bad:
models like the 600D and 1100D dont have that free region.

[1%]

6D seems to have that free block... this is why it doesn't do solid light?

ROM:FF20DA30 dword_FF20DA30  DCD 0x41FC0000          ; DATA XREF: ROM:FF20D778r
ROM:FF20DA34 aBank1_free30xX DCB "BANK1_FREE3             0x%X 0x%08X %d",0

I don't think its at the end though.

2 More:

ROM:FF20D6CC dword_FF20D6CC  DCD 0x41DD9B00          ; DATA XREF: ROM:FF20D3A4r
ROM:FF20D6D0 aBank1_free20xX0x08xD DCB "BANK1_FREE2             0x%X 0x%08X %d",0
ROM:FF20D6D0                                         ; DATA XREF: ROM:FF20D3A8o

ROM:FF20D524 dword_FF20D524  DCD 0x29200             ; DATA XREF: ROM:FF20D214r
ROM:FF20D528 aBank1_free10xX0x08xD DCB "BANK1_FREE1             0x%X 0x%08X %d",0