DryOS system information functions
indy arm
In 550d 109, at FF073FFC, we have got "dryShellHelp", the documentation and functions addresses/names reachable from the internal DryOS shell.
this command line shell is only accessible from the console, using dedicated hardware, maybe connected in the battery slot.
This shell allows having information about running tasks, malloc'ed and system memory, ARM memory settings, etc...
So it would be cool to be able to have this info for debug purpose too, right ?
I rewrote some of this functions with output to the log file (dumped using dumpf() )
see attached code and output
they can be modified for screen output too, of course...
Add the supplied code to ML and you can call, from debug.c :
debug_mkcfg();
// debug_ps(); // do not really work
debug_sysmem();
debug_malloc_mem();
debug_memmap();
debug_objinfo();
debug_objsize();
debug_task(); // ID and args are buggy...
debug_dminfo(); // work partially
then
dumpf()
this code WON'T run on a different firmware/model, since functions/structures addresses has to be converted.
DryOS seems close to ITRON4.0, an open source real time OS from Japan industries.
Indy
arm.indy
See 'DRAM' section:
Magic Lantern is loaded after the BSS end (0x8a9e0) rounded to
0x8b000.
Head start is also at 0x8a9e0.
Heap end is at 0x103958
0x100000 seems filled with code from the bootcode (visible in a dump,
not here)
So the maximum length for ML with 550 1.0.9 seems 0x100000-0xb0000 =
327 Kbytes
Any confirmation or infirmation ?
Indy
== ITCM ==
00000000 : DRY_VECTOR_ADDR
000004b0 : DRY_HANDLER_ADDR
0x00000214(532)
000006c4 : DRY_HANDLER_END_ADDR
000006c4 : DRY_IRQ_STACK_START
000006c4 : DRY_RESET_STACK_START
0x0000093c(2364)
00001000 : DRY_IRQ_STACK
00001000 : DRY_RESET_STACK
00001000 : ITCM_END_ADDR
== DTCM ==
400006f8 : DRY_VECTOR_FUNC
0x00000400(1024)
40000af8 : DRY_VECTOR_ARG
0x00000400(1024)
40001000 : DTCM_END_ADDR
== ROM ==
ff810000 : text start
0xffd37f60(ul)
ffd37f60 : romdata start
0x00025828(153640)
ffd5d788 : romdata end
== DRAM ==
00001900 : data start
0x00025828(153640)
00027128 : bss start
0x000638b8(407736)
0008a9e0 : heap start
0x00078f78(495480)
00103958 : DRY_HEAP_END
00103958 : DRY_SYS_OBJS_START
0x000072a8(29352)
0010ac00 : DRY_SYS_MEM_START
0x00104000(1064960)
0020ec00 : DRY_ERREX_STACK_START
0x00000400(1024)
0020f000 : DRY_ERREX_STACK
0020f000 : DRY_EXCEP_STACK_START
0x00001000(4096)
00210000 : DRY_EXCEP_STACK
> 37KViewDownload
>
> shell_debug.c
> 23KViewDownload
Alex
> 327 Kbytes
> Any confirmation or infirmation ?
Well... when autoexec.bin exceeds around 180k, problems start to
appear. The first ones are strings trimmed randomly (e.g. instead of
AGC it displays just A... or it displays half of the input source in
the audio meters...). These problems are sometimes solved by "make
clean; make", other times I have to remove some code... not related to
the corrupted message. For example, I've removed some rarely used
functions like flash / no flash or LV metering.
Other problems I've noticed due to this were crashes in play mode
(after 10 pictures or so), crashes when using trap focus and other
remote release functions, or freezing Canon's LCD brightness dialog.
This happened in early 2010 builds and in a few 2011 ones.
On the other hand, when enabling debugging functions (DebugMsg, debug
console, prop/mem spy), autoexec.bin increases by ~10k, but I don't
notice any side effects.
I've also tried to dump what it appears to be autoexec.bin loaded in
RAM (i.e. from 0x800000, dumped a file with the same size as
autoexec.bin). There are quite a bit of differences between the
original autoexec.bin and the dumped copy, but it may be due to static
variables (I don't know how these are allocated by gcc).
> --
> http://magiclantern.wikia.com/
>
> To post to this group, send email to ml-d...@googlegroups.com
> To unsubscribe from this group, send email to ml-devel+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en
Trammell Hudson
> this is the output from debug_memmap()
> 0x8b000.
> Head start is also at 0x8a9e0.
> Heap end is at 0x103958
Those values are after the magic lantern firmware has been loaded,
right? The start of the DryOS bss has already been moved from
around 0x5F000 to 0x5F000 + size of magic lantern image and bss in
copy_and_restart():
INSTR( HIJACK_INSTR_BSS_END ) = (uintptr_t) _bss_end;
The other values in the memory dump are are shifted upwards by the
appropriate ammount.
To find the original values, you would need access to the serial
console. There are pins inside the camera body and perhaps in the
battery connector to access this serial port, although it is inert
until activated.
--
Trammell
arm.indy
see FF014B2C memmap in 550d 109. FF0155B8 in 600d 101.
Indy
Michael Richards
By the bug description/weirdness described I wonder if perhaps ML is stomping on RAM somewhere and causing the random behavour. I'm not familliar with the ARM processor being used but perhaps JTAG, NEXUS or BDM is available? This would make the debugging far simpler. I know on the PPC stuff I'm working on I can actually stop and step through the code manually watching whatever memory addresses I like to determine what a routine is doing. So far I haven't managed to get this working in IDA but the latest 6.1 does have support for some external debugging stuff (haven't had time to play with it yet).
arm.indy
Good idea, but it is difficult to find hires photo of Canon DSLR. I
tried to find them on the net, without success.
I often heard that additional contacts inside the battery slot are
also used to access it. the problem is then to supply power to the
camera while accessing to these contact.
yes, based on the firmware content, there IS a serial console.
Indy
Morgan Look
I have been examining the photos of grips on ebay, and I notice that they seem to miss some of the pins in the battery bay.
http://cgi.ebay.com/BATTERY-GRIP-CANON-EOS-600D-550D-Rebel-T3i-T2i-B2R-/280689598297?pt=Batteries_Chargers&hash=item415a675f59
Note the gap in the two rows of pins, it may be possible to hack up contacts to those remaining pins and look for serial data.
Morgan.
Andrew Coutts
port. Here are some pictures of my t1i/500d and a canon grip with it,
maybe this can help somebody.
http://imgur.com/a/IdDNn#LjKwI
You can also print information about free memory with a function in
the firmware. i can't get it exactly right now, but I found this on
the 500d:
[FAC] GetFreeSizeOfMemory Free[3534280]
[FAC] GetTotalSizeOfMemory [10485760]
[FAC] GetSizeOfMaxRegion [3329964]
[FAC] GetNumberOfAllocatedBlock [5230]
> I have been examining the photos of grips on ebay, and I notice that they seem to miss some of the pins in the battery bay.http://cgi.ebay.com/BATTERY-GRIP-CANON-EOS-600D-550D-Rebel-T3i-T2i-B2...
Morgan Look
Notice your grip has 6x2 rows of pins, but there is 8x2 contacts on the camera.
As indy pointed out, the trick is getting at them while powering the camera.
Maybe glue something like this onto the grip to make up the missing pins...
http://newzealand.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=7024779
A quick snoop with a scope should pretty easily determine which is tx, and what the voltage levels are.
Morgan.
arm.indy
For these functions on powwershot camera.
> 37KAfficherTélécharger
>
> shell_debug.c
> 23KAfficherTéléchargerhttp://chdk.wikia.com/wiki/DryOS_Shell
Andrew Coutts
related to some sort of debugging cable setup.
a couple of interesting ones (500d dump):
ff0c4d50: '[DP] DpSetDebugMode : dwFlag = %ld\n'
ff0e58f0: 'Set Debug Flag 0x%08lX(0x08%lX)'
ff0e5910: 'Clear Debug Flag 0x%08lX(0x08%lX)'
ff1707c4: 'EnableSerialPort'
ff20652c: '[LVAE] EP_SetLVAEDebugPort() >> OFF'
ff206550: '[LVAE] EP_SetLVAEDebugPort() >> ON'
ff2065d4: 'lvae_setdebugport'
ff4719aa: 'SendSerialDataToLCD'
ff4720cf: 'Signature Of SerialIO '
ff4720e6: 'Initialize SerialIO'