Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jack001214

Pages: [1]
1
Impressive! Keep it up! I do not have  knowledge on disassembly and reverse engineering and i wish i could help.
Don't stop keep on going(you know i might own a 200D).

2
Quote
Yes, but currently the only notes on the Wi-Fi interface are these (for the old 6D). One could certainly attempt to find the stubs and try that proof of concept code.
My new task.

Quote
I've also found real-time logging via UART problematic while troubleshooting bricked cameras - it's just too slow to print all Canon's messages in real-time. No wonder they are printing only a tiny subset, and even that happens in a background task.
Bummer! Well that saved saved me from evaporating.  :D

Quote
Very interesting, mine isn't FPC.  Jack's has a K2 label, I have K1 - and inside 3 exposed pads.  Serial port without ground?

I think that could be a newer revision.
maybe to keep us out?

3
@kitor How did you measure the pitch of the FPC connector with that small size?

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.

4
Reverse Engineering / Re: Battery grip pins / UART
« on: June 22, 2019, 06:49:43 PM »
This UART connector is also available on the 200D(@kitor suggested)under the 'thumb resting rubber' which is very similar to the EOS R.



5
Quote
By looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.
It's exactly the same but the pins could be different.Now its time to dissect a old video player and hopefully find the right FPC cable


6
I have been looking through several ram dumps of 200D and i was wondering where is the output of the raw DryOS debug messages and for that i need the following question to be answered.(I'd really appreciate it) 

Where is the debug port for the 200D?
can the WIFI or NFC interface be used to send logs to the host (or any suitable interface for logs) ?


I have not been actively working on magic lantern either as i do not know what i am looking at.i just end up brut-forcing stuff which i know is not going to get me anywhere 
Thank you,

7
Quote
I have a 200D and am slowing porting magiclantern

How far did you get? I mean i am goofing around with my 200D too with the RAM dumps etc .If there was a list or some updates i'd follow it.

Also, any decoded buttons 'codes' are found yet?

8
Quote
Notice Canon's data structure is a bit larger than the 3 fields I've declared;
Yes i found my self nitpicking each log and found the same result against the ram dump.

Quote
That means, it doesn't point to the currently displayed buffer, but to the "back" one, for some reason. This code pattern was present on all DIGIC 6/7/8 models I've checked.
Ah! So now i see, when i was changing that region it affected a 'part' of the display which was probably the live view from the camera.


9
Great News! Future seems bright for these camera's!

Also, (if you dont mind) can you briefly explain the process which took place too find this address when the memory region is  not 'cache-able'?
Thanks,

11
So I got bored (again).To counteract that I decided to compile the latest branch and run it on actual EOS200D(it works).
The logs that the program created got me to tinker some memory location on the camera.
The first address I tinkered was the supposed 'gain control' which was noted as
Code: [Select]
DispDCtrl:e055f277:42:03: GAIN R:0x0eb G:0x0ec B:0x100
[0] 1.435252
in the log. I went ahead and set the contents of the area to '0x00'(random int) and surprisingly,the camera booted and the display was working perfectly(unexpected). Right after switching the camera to record, there were two separate 'boxes' created which had the live view shifted few places to one another and settled as soon as the camera was still.
I mean this was not useful too anyone but I was inspired. So yeah.

12
Awesome analysis and work through. I will try to find some stuff with my novice skills. Though you can always PM me to test some code  for the 200D.

Cheers!

13
Quote
If lucky, all you need to print Hello World is to modify the contents of that bitmap buffer (which will have to be identified from a RAM dump, starting from the argument of DISP_SetUpdateOSDVram).
...
How would i get a RAM dump? if i cant invoke many location's then  how would i go about getting a RAM dump then?

14
I recompiled the digic6 branch and dumped the autoexec.bin on my 200D.
What exactly is the OSD Vram? (On Screen Display?)


These two instructions are being executed together at every 'update'.
Code: [Select]
002FD1BA>    CtrlSrv:e04a0783:04:03: DISP_SetUpdateOSDVram(0x4169ea00)(0)
002FD2E2>    CtrlSrv:e04afd6f:04:03: refresh x=728 y=442 w=84 h=60

How can i poke this function? i mean what would be minimalist code required to poke a function

15
Quote
figuring out how to print things on the screen (i.e. a software-only task)
How were able to achieve that with the ROM dumpers?


Quote
- 200D: proof of concept code available;
Is it from the digic6-dumper branch? The same one which you gave me few months back?

16
M50 moved over here, alongside with other DIGIC 8 PowerShots.

Short recap for DIGIC 7:
- source code: digic6-dumper branch ( actually covering DIGIC 6, 7 and 8 )
- bootloader experiments: recovery branch ( portable code, running on DIGIC 2...8 )
- emulation: qemu branch (README.rst, HACKING.rst, no GUI yet, but file I/O is working)
- CPU info (Cortex A9 dual core), MMU configuration (mostly flat mapping), ROM layout (32MB at 0xE0000000, 16MB at 0xF0000000)
- see also Initial firmware analysis in QEMU docs
- 200D: proof of concept code available; I'm ready to enable the boot flag, too. Or, to capture DNGs from LiveView or other simple tasks.
- 800D, 77D, 6D2: find a couple of stubs (tutorial) to run the 200D PoC. Once you do that, I'm ready to enable the boot flag on these models, too.
- image sensor on all these models appears to run at 27 MHz x 12 channels (hypothesis), i.e. fast enough for 4K video.
- I have no plans to get any of these cameras; it's up to the user community to push the development further.

Have fun!
What is the main reason for limited support for the dual core camera's anyways?

17
I'm ready

18
What if i want to run some simple code on my 200D? Like a simple calculation and store it in the RAM or some accessible space. What can i do too access the full CPU instructions in assembler? I am not looking for fancy Screen gui's and touch or anything above those categories.

19
does ML even work for 200D?

Pages: [1]