Author Topic: Some information about PTP & GDB  (Read 8859 times)


0xAF

  • Contributor
  • Freshman
  • *****
  • Posts: 85
  • The devil in me...
Re: Some information about PTP & GDB
« Reply #1 on: November 27, 2012, 11:41:33 PM »
This is something new to me ...
Would you please explain what is the relation between PTP and GDB ?

// AF

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: Some information about PTP & GDB
« Reply #2 on: November 27, 2012, 11:59:44 PM »
i added a gdbstub to magic lantern that is controlled over PTP.
so you can debug tasks over it.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

jplxpto

  • Developer
  • Hero Member
  • *****
  • Posts: 506
Re: Some information about PTP & GDB
« Reply #3 on: November 28, 2012, 12:13:31 AM »
i added a gdbstub to magic lantern that is controlled over PTP.
so you can debug tasks over it.

You did an excellent job!

jplxpto

  • Developer
  • Hero Member
  • *****
  • Posts: 506
Re: Some information about PTP & GDB
« Reply #4 on: November 28, 2012, 12:15:18 AM »
This is something new to me ...
Would you please explain what is the relation between PTP and GDB ?

The idea started with my first post on the forum. Our friend g3gg0 accepted the challenge and implement the GDB Stubs.

http://www.magiclantern.fm/forum/index.php?topic=1761.msg5617#msg5617

jplxpto

  • Developer
  • Hero Member
  • *****
  • Posts: 506
Re: Some information about PTP & GDB
« Reply #5 on: November 28, 2012, 12:22:21 AM »
My idea is to create a bi-directional stream between the camera and the PC.
Thus, with some additional work and with the help of cache hacks, we can redirect the console firmware to a window in our PC.
All this without needing to have a serial RS232 or JTAG cable (we already have the USB cable so it can use the PTP).
The g3gg0 already implemented the most complex part .. cache-hackes & GDBStubs.

This man is always to score points ... heheh

..::T3::..

  • New to the forum
  • *
  • Posts: 4
Re: Some information about PTP & GDB
« Reply #6 on: November 28, 2012, 09:50:11 AM »
Well, it seems there is a physical uart available (on PowerShots):

http://chdk.wikia.com/wiki/UART

Also on the EOS PCBs a lot of testpoints are available:

http://www.centralds.net/en/astro60d.htm

I would wounder if anyone is brave enough to solder on its DSLR.

I did on a old IXUS 30, log msgs are nice. But I'm not a developer, so it's just gambling around.

0xAF

  • Contributor
  • Freshman
  • *****
  • Posts: 85
  • The devil in me...
Re: Some information about PTP & GDB
« Reply #7 on: November 28, 2012, 10:11:46 AM »
My idea is to create a bi-directional stream between the camera and the PC.
Thus, with some additional work and with the help of cache hacks, we can redirect the console firmware to a window in our PC.
All this without needing to have a serial RS232 or JTAG cable (we already have the USB cable so it can use the PTP).
The g3gg0 already implemented the most complex part .. cache-hackes & GDBStubs.

This man is always to score points ... heheh

I had similar idea for 400Plus, though I never got to the PTP stuff.
I will check the stubs in ML.

What g3gg0 did with the the cache hacks is fantastic, though it's like a voodoo magic to me ;)
I know the basic concept of how it works, but I would like to know more.
I'm soon going to start my work on 5DC, but I'm still doing work for 400Plus too, I would really like to know more about the cache hacks.

g3gg0, if I'm not way too much insolent, I would very grateful if you help me a bit with this.

// AF

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: Some information about PTP & GDB
« Reply #8 on: November 28, 2012, 11:40:09 AM »
sure i can explain it.
the most simple way would be: you tell me what and how you understood it and i will correct/complete that.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

0xAF

  • Contributor
  • Freshman
  • *****
  • Posts: 85
  • The devil in me...
Re: Some information about PTP & GDB
« Reply #9 on: November 28, 2012, 03:03:08 PM »
sure i can explain it.
the most simple way would be: you tell me what and how you understood it and i will correct/complete that.

That's cool, I will contact you soon. I need to prepare myself with good understanding of ARM caches first, so I should not be so newbie on this topic when we talk about it ;)
// AF

jplxpto

  • Developer
  • Hero Member
  • *****
  • Posts: 506
Re: Some information about PTP & GDB
« Reply #10 on: November 28, 2012, 03:23:51 PM »
That's cool, I will contact you soon. I need to prepare myself with good understanding of ARM caches first, so I should not be so newbie on this topic when we talk about it ;)

I'm also interested in knowing more about this topic. Perhaps g3gg0 can explain this better for all those interested.

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: Some information about PTP & GDB
« Reply #11 on: November 28, 2012, 04:18:48 PM »
i wont explain 4-way set associative caches in detail.
there are enough online guides available.

e.g. http://www.ecs.umass.edu/ece/koren/architecture/Cache/tutorial.html

in short:
when the cpu reads DATA or INSTRUCTION first the cache is asked.
the ADDRESS that should get read from memory is split in 2 parts:
 ADDRESS = (TAG | OFFSET)

cache has two RAMs that are not visible normally.
one is called TAG-RAM, the other DATA-RAM.
now the cache looks in TAG-RAM if the address is cached and returns the data if there was a hit.

if(TAGRAM[GET_OFFSET(address)] == GET_TAG(address))
{
    return DATARAM[GET_OFFSET(address)];
}

if there was no hit, the data is placed in cache like this:

DATARAM[GET_OFFSET(address)] = data_from_ram;
TAGRAM[GET_OFFSET(address)] = GET_TAG(address);

that happens all the time when something is read from ram/flash.


when patching cache content via MCR/MRC we manually set the OFFSET and then can read/write TAG and DATA.
this way we are telling the cache: "hey you already have somewhen read the data the CPU just wanted to read. just read it from you DATA_RAM"

now the cache supports another feature - locking.
when locking one of the four caches, the cache logics wont overwrite its content anymore.
the patch is "permanent" until RESET or someone invalidates the cache contents.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

jplxpto

  • Developer
  • Hero Member
  • *****
  • Posts: 506
Re: Some information about PTP & GDB
« Reply #12 on: November 29, 2012, 01:25:55 AM »
Alex or Nanomad...

I think it should be created with a new post to this topic. Cache hacks deserves a post. They are very important!

jplxpto

  • Developer
  • Hero Member
  • *****
  • Posts: 506
Re: Some information about PTP & GDB
« Reply #13 on: November 29, 2012, 02:23:38 AM »
My idea is to create a bi-directional stream between the camera and the PC.
Thus, with some additional work and with the help of cache hacks, we can redirect the console firmware to a window in our PC.
All this without needing to have a serial RS232 or JTAG cable (we already have the USB cable so it can use the PTP).
The g3gg0 already implemented the most complex part .. cache-hackes & GDBStubs.

This man is always to score points ... heheh

I thought about creating a consoleproxy that this is a service that accepts connections from any TELNET client and transfers the characters to/from the camera by CHDK PTP / ML.

0xAF

  • Contributor
  • Freshman
  • *****
  • Posts: 85
  • The devil in me...
Re: Some information about PTP & GDB
« Reply #14 on: November 29, 2012, 03:06:13 PM »
I thought about creating a consoleproxy that this is a service that accepts connections from any TELNET client and transfers the characters to/from the camera by CHDK PTP / ML.

I think there should be easier way of exporting the console to USB...
You should check the console engine in the camera, it may be easily intercepted.

In VxWorks there is another trick that you may use, you can write a console driver for VxWorks and register it.
You need to have few functions to make a console driver (i.e. Create(), Open(), Read(), Write(), IOCtl() ).
Then create the device with these functions iosDrvInstall() and iosDevAdd().
Then open the new device, get the FH and redirect the STDIN/STDOUT there with ioGlobalStdSet().

I learned this by reading one of the very earlier sources of 400d hack, this is how 'owerlord' made his blinking driver and dumped the logs in first place.

This is his (owerlord) post: http://chdk.setepontos.com/index.php?topic=1359.msg14519#msg14519, and somewhere in this thread are the sources too ... though I can send them to anyone interested.
// AF

jplxpto

  • Developer
  • Hero Member
  • *****
  • Posts: 506
Re: Some information about PTP & GDB
« Reply #15 on: November 30, 2012, 02:38:42 AM »
I think there should be easier way of exporting the console to USB...
You should check the console engine in the camera, it may be easily intercepted.

In VxWorks there is another trick that you may use, you can write a console driver for VxWorks and register it.
You need to have few functions to make a console driver (i.e. Create(), Open(), Read(), Write(), IOCtl() ).
Then create the device with these functions iosDrvInstall() and iosDevAdd().
Then open the new device, get the FH and redirect the STDIN/STDOUT there with ioGlobalStdSet().

I learned this by reading one of the very earlier sources of 400d hack, this is how 'owerlord' made his blinking driver and dumped the logs in first place.

This is his (owerlord) post: http://chdk.setepontos.com/index.php?topic=1359.msg14519#msg14519, and somewhere in this thread are the sources too ... though I can send them to anyone interested.

Thank you ... I did not know it.! I'll test that. I had seen these functions but I was unaware of the utility ...
I never studied VxWorks!