A Git based version of Magic Lantern, for those unwilling or unable to work using Mercurial. The vast majority of branches have been removed, with those thought to be important brought in individually and merged.
R5 has a total of 5(?)GB of RAM. There's no ARM PAE enabled. According to MPU tables, there's almost DIGIC8 mapping (see #80) so 1 gig of cacheable RAM mirrored to 1G uncacheable + almost another 1G of uncacheable.
FIO function gained a few new entries: ReadIBus and WriteIBus. There's some translation going on, as BufferAddr is CPUAddr[%#x:%#x]
Digic X is missing "old" SRM / RscMgr at all. A few stubs that exist here and there are just dummy functions that throw an error or assert.
Interesting function name: SystemIF::MapCpuBuffer.cMapCpuBufferToIbusBuffer(), UnmapCpuBuffer() seems to suggest there's some memory banking happening?
dibus evshell command may give a clue how to at least read other ibus channels(?):
On older models there's a family of MEMIF functions. On R5 those are completely different when compared to any DIGIC 8 model + reference a lot of IBus addresses. Memif/MemifDynamicWindow.c, Peripheral::MemifDynamicWindow.c
When attempting to allocate own buffer for XCM, Assert went from MemifArbiter:
R5 has a total of 5(?)GB of RAM. There's no ARM PAE enabled. According to MPU tables, there's almost DIGIC8 mapping (see #80) so 1 gig of cacheable RAM mirrored to 1G uncacheable + almost another 1G of uncacheable.
FIO function gained a few new entries:
ReadIBusandWriteIBus. There's some translation going on, asBufferAddr is CPUAddr[%#x:%#x]Digic X is missing "old" SRM / RscMgr at all. A few stubs that exist here and there are just dummy functions that throw an error or assert.
debug_assert(0,"Resource::RscMgrOldApiStub.c",0x2b);System is substituted by RscMgr2. No
smemshowfixcommand - replaced byres_memshow <int>.Example output:
===
Some functions report addresses in form of more-than-32bit values:
Number above bit 31 seems to be related to "ibus address", as:
Interesting function name:
SystemIF::MapCpuBuffer.cMapCpuBufferToIbusBuffer(),UnmapCpuBuffer()seems to suggest there's some memory banking happening?dibusevshell command may give a clue how to at least read other ibus channels(?):In fact, while looking for existing XCM layer data it was on "2nd" IBus:
On older models there's a family of MEMIF functions. On R5 those are completely different when compared to any DIGIC 8 model + reference a lot of IBus addresses.
Memif/MemifDynamicWindow.c, Peripheral::MemifDynamicWindow.cWhen attempting to allocate own buffer for XCM, Assert went from
MemifArbiter: