Gecko dotNET mono discussion

[dcx2]

To get MonoDevelop: Follow Hawkeye's instructions here.  (BTW, debugging works ^_^)  BTW, you do need to run MonoDevelop as root.

Get the latest libftdi from the repos (is 0.16-2, I think; don't know if we need to build libftdi from the source, which is 0.17-1)

Go to "USBGecko.cs" and add "#define MONO" at the top.

Go to FST.cs and modify the FST constructor so that the lines referencing IconReader are commented out.  IconReader comes from a windows dll that we don't have on Linux.  In USBGecko::Connect(), there is a call to Disconnect() that needs commented out.  You can't disconnect if you aren't connected or you will crash.  (I plan on eventually adding directives so that you won't need to comment these things out...)

The current roadblock is in MainForm::CUSBGecko_Click, there's a call to gecko.sendfail() in a while loop that's checking UnknownStatus().  UnknownStatus does not appear to work correctly.

[giantpune]

i just tried the above with the sources from r60.  when i build the thing and run it, i get the gui popping up for about 2 second and then it dies with this...
[spoiler]
** ERROR **: Structure field of type Byte[] can't be marshalled as LPArray
aborting...
Stacktrace:

  at FTDIUSBGecko.USBGecko.Connect () [0x000d0] in /home/j/c/geckoDotNet_60/Gecko dotNET/USBGecko.cs:355
  at FTDIUSBGecko.USBGecko.Connect () [0x0003f] in /home/j/c/geckoDotNet_60/Gecko dotNET/USBGecko.cs:323
  at GeckoApp.MainForm.CUSBGecko_Click (object,System.EventArgs) [0x00075] in /home/j/c/geckoDotNet_60/Gecko dotNET/MainForm.cs:326
  at GeckoApp.MainForm.MainForm_Shown (object,System.EventArgs) [0x00000] in /home/j/c/geckoDotNet_60/Gecko dotNET/MainForm.cs:275
  at System.Windows.Forms.Form.OnShown (System.EventArgs) <0x00069>
  at System.Windows.Forms.Form.SetVisibleCore (bool) <0x0069d>
  at System.Windows.Forms.Control.set_Visible (bool) <0x00032>
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control.set_Visible (bool) <0xffffffff>
  at System.Windows.Forms.Application.RunLoop (bool,System.Windows.Forms.ApplicationContext) <0x002cb>
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) <0x00053>
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) <0x00037>
  at GeckoApp.Program.Main () [0x0000b] in /home/j/c/geckoDotNet_60/Gecko dotNET/Program.cs:17
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

   /usr/bin/mono [0x47a5ef]
   /lib/libpthread.so.0 [0x7f29149e3190]
   /lib/libc.so.6(gsignal+0x35) [0x7f29144144b5]
   /lib/libc.so.6(abort+0x180) [0x7f2914417f50]
   /lib/libglib-2.0.so.0(g_logv+0x53a) [0x7f2915041e0a]
   /lib/libglib-2.0.so.0(g_log+0x83) [0x7f2915041ea3]
   /usr/bin/mono [0x4ec014]
   /usr/bin/mono [0x4eb0be]
   /usr/bin/mono [0x4ec949]
   /usr/bin/mono [0x4edd11]
   /usr/bin/mono [0x4f33aa]
   /usr/bin/mono [0x4fbb0a]
   /usr/bin/mono [0x4516b9]
   /usr/bin/mono [0x41d1a7]
   /usr/bin/mono [0x41e897]
   /usr/bin/mono [0x4821bd]
   [0x405c0168]

Debug info from gdb:

[Thread debugging using libthread_db enabled]
[New Thread 0x7f29089b4910 (LWP 21525)]
[New Thread 0x7f291329a910 (LWP 21521)]
[New Thread 0x7f29154ee910 (LWP 21520)]
0x00007f29149e20cb in read () from /lib/libpthread.so.0
  4 Thread 0x7f29154ee910 (LWP 21520)  0x00007f29149e28f1 in nanosleep ()
   from /lib/libpthread.so.0
  3 Thread 0x7f291329a910 (LWP 21521)  0x00007f29149e13c1 in sem_wait ()
   from /lib/libpthread.so.0
  2 Thread 0x7f29089b4910 (LWP 21525)  0x00007f29149e28f1 in nanosleep ()
   from /lib/libpthread.so.0
* 1 Thread 0x7f29156be730 (LWP 21517)  0x00007f29149e20cb in read ()
   from /lib/libpthread.so.0

Thread 4 (Thread 0x7f29154ee910 (LWP 21520)):
#0  0x00007f29149e28f1 in nanosleep () from /lib/libpthread.so.0
#1  0x0000000000553fa2 in ?? ()
#2  0x00007f29149daa04 in start_thread () from /lib/libpthread.so.0
#3  0x00007f29144c07bd in clone () from /lib/libc.so.6
#4  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f291329a910 (LWP 21521)):
#0  0x00007f29149e13c1 in sem_wait () from /lib/libpthread.so.0
#1  0x00000000004e32ba in ?? ()
#2  0x000000000050305a in ?? ()
#3  0x000000000056da83 in ?? ()
#4  0x000000000058b6e1 in ?? ()
#5  0x00007f29149daa04 in start_thread () from /lib/libpthread.so.0
#6  0x00007f29144c07bd in clone () from /lib/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f29089b4910 (LWP 21525)):
#0  0x00007f29149e28f1 in nanosleep () from /lib/libpthread.so.0
#1  0x000000000056cb34 in ?? ()
#2  0x00000000005026be in ?? ()
#3  0x00000000417f0fa5 in ?? ()
#4  0x0000000001d60e70 in ?? ()
#5  0x00007f29089b4910 in ?? ()
#6  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f29156be730 (LWP 21517)):
#0  0x00007f29149e20cb in read () from /lib/libpthread.so.0
#1  0x000000000047a764 in ?? ()
#2  <signal handler called>
#3  0x00007f29144144b5 in raise () from /lib/libc.so.6
#4  0x00007f2914417f50 in abort () from /lib/libc.so.6
#5  0x00007f2915041e0a in g_logv () from /lib/libglib-2.0.so.0
#6  0x00007f2915041ea3 in g_log () from /lib/libglib-2.0.so.0
#7  0x00000000004ec014 in ?? ()
#8  0x00000000004eb0be in ?? ()
#9  0x00000000004ec949 in ?? ()
#10 0x00000000004edd11 in ?? ()
#11 0x00000000004f33aa in ?? ()
#12 0x00000000004fbb0a in ?? ()
#13 0x00000000004516b9 in ?? ()
#14 0x000000000041d1a7 in ?? ()
#15 0x000000000041e897 in ?? ()
#16 0x00000000004821bd in ?? ()
#17 0x00000000405c0168 in ?? ()
#18 0x00007fffdf428880 in ?? ()
#19 0x000000000050351a in ?? ()
#20 0x00000000405c0173 in ?? ()
#21 0x0000000000000001 in ?? ()
#22 0x00007f290f814af0 in ?? ()
#23 0x08ccabe9157d4c0c in ?? ()
#24 0x00000000406d3100 in ?? ()
#25 0x08ccabe915346afa in ?? ()
#26 0x00007f2912b9bd20 in ?? ()
#27 0x00007f290f814af0 in ?? ()
#28 0x00000000413e1150 in ?? ()
#29 0x08ccabe915346afa in ?? ()
#30 0x08ccabe9157d4c0c in ?? ()
#31 0x08ccabe9157d4c0c in ?? ()
#32 0x0000000000000001 in ?? ()
#33 0x08ccabe915346afa in ?? ()
#34 0x0000000000000001 in ?? ()
#35 0x00007f2912b9bd20 in ?? ()
#36 0x00000000406ce0a0 in ?? ()
#37 0x00007f2912b98f40 in ?? ()
#38 0x00007fffdf4287d0 in ?? ()
#39 0x0000000000000000 in ?? ()

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================


The application was terminated by a signal: SIGABRT
[/spoiler]

But I'm very happy to at least see the gui.  Also, Im glad to see that the mono version has not been forgotten.  Keep up the good work.

[dcx2]

Not r60...the r# builds are test builds.  The # actually corresponds to the current SVN version.  The latest source was 0.60.

I remember that error now.  In libftdi.cs, there's a struct ftdi_context, with a byte[] member.  Change byte[] to IntPtr to solve the "byte[] can't be marshalled as LPArray"

The next time I update sources, it will include modifications that make building mono easier, so you don't need to comment this out and change that etc.

[dcx2]

Okay, I don't think the FTDI driver was being initialized correctly.  I'm still hunting it down.  In the mean time, if someone is feeling adventurous, they could look into setting /etc/udev/rules.d so that we don't need to run MonoDevelop as root.

http://go-mono.com/forums/#nabble-td1587071

[dcx2]

lol, whoops...libftdi::Write() is making a call to ftdi_read_data, when it should be ftdi_write_data.

Also, I was wrong about initializing.  I thought we might need to call ftdi_init() or ftdi_new() but it looks like ftdi_usb_open() does that for us?

I'm still iffy about that ftdi_context struct.  But, now...UnknownStatus() writes to the FTDI device successfully.  I confirm that 1 byte was sent.  It then tries to read the status from the device, but I get 0 data back, which according to http://www.intra2net.com/en/developer/libftdi/documentation/group__libftdi.html means that there is no data available?

[dcx2]

baka!  My Wii was off, that's probably why read kept failing...

Anyway, read returns bytes sometimes, but not always.  Not sure why.

[giantpune]

what exactly is making you run monodevelop as root?  i never do.  granted, im not getting very good results with this project :) ,but i get the exact same results when i run it normally and as root.

[dcx2]

When you eventually get to LFTDI::OpenBySerialNumber(String) (in libtdi.cs), there's a call to ftdi_usb_open.  This will fail if you don't run as root.

According to this post (external), who also happens to be using libftdi to talk over USB...

I was able to change the USB device permissions in my Karmic by adding a rule in /etc/udev/rules.d.
I am now able to run and debug my mono app using MonoDevelop without having to run as root.

If someone could figure out what a rule is, and what line it goes on in that file, that would be helpful...   ;D

[dcx2]

So if you install libftdi-dev from the repos, there are examples in /usr/share/doc/libftdi-dev/examples and see if you can build simple.c.  (remember to use -lftdi switch to link against the library).

I'm able to get Gecko dotNET to read the chipid from the device.  I even successfully connected and see the game name string...but I'm not exactly sure which of the things that I did was the correct thing to do, and sometimes it still doesn't work.

[dcx2]

WIN!

I can do searches and look around in Memory Viewer!   ;D :cool:  I haven't gotten vdappc yet, but it's open source so that's not hard, right?

Turns out that ftdi_read_data will return 0...if there's nothing there yet.  If you loop on this, you can wait for data to arrive.  That fixed the reliability issue.

Now this is a little messy, so I need to clean it up before I release it.  And I need to integrate the changes into svn.  But it will come some time this weekend for sure, and it will be much easier to build and run.

[hawkeye2777]

WIN!

I can do searches and look around in Memory Viewer!   ;D :cool:  I haven't gotten vdappc yet, but it's open source so that's not hard, right?

Turns out that ftdi_read_data will return 0...if there's nothing there yet.  If you loop on this, you can wait for data to arrive.  That fixed the reliability issue.

Now this is a little messy, so I need to clean it up before I release it.  And I need to integrate the changes into svn.  But it will come some time this weekend for sure, and it will be much easier to build and run.

Sources please? I can also write up a quick guide on getting libftdi to work on normal user.

Also, just grab the powerpc and vdappc executables from my PyiiASMH app.

EDIT: I can handle packaging too, once we get to that point (managing a PPA, etc.).

[giantpune]

here the vdappc i compiled ubuntu 9.10 AMD64.  think theres also a mac binary in there, too. But the sources are there if you need those. http://www.multiupload.com/XP34VPAFQD 

i tried seeing how far along i could get in a mac, and i got stuck at the libftdi.  The only version i saw was kinda old and it took a lot to get it to even install for me.  It would tickle me pink if that old lib worked though.

[dcx2]

Okay, the sources should be updated on the main thread to be mono-compatible.

In MonoDevelop, the first time you'll need to go to Project -> Gecko dNet Options, then go to the Compiler node, Define Symbols: field, and add ";MONO" to the list, so it looks like

DEBUG;TRACE;MONO

MonoDevelop will then switch out all the Windows code for mono code in all the places it needs switched.  Remember to run as root, until we figure out how to make udev rules for the FTDI's VID/PID.

[giantpune]

woohoo!  it works.  for some reason, my monodevelop didnt have the same project settings as you described, so i just put #define MONO in a few files.  i have 2 small issues.
1 - to run this, i open a terminal and do "sudo mono geckodotnet.exe".   it only finds the disassembler if it is in the current directory of the terminal.  meaning that i have to cd to the folder where the exe is before i run it if i want to disassemble and whatnot.
2 - using this changes/removes the /dev/ttyUSB0 where the gecko usually is found.  this kills my wiiload abilities and anything else that usually looks for the gecko there.  if i unplug the usb calbe and plug it back in, i get /dev/ttyUSB0 back.

aside from these little things, it works great in ubuntu 9.10 amd64.  thank you!!

EDIT>>
i found another bug that is a bit more annoying.  in the windows version, there is a nice right click menu with things like "convert hex to dec".  in the mono version, i get a context menu, but it only has copy, paste, and the other usual things for a right click menu.  there is no "convert dec to hex" or anything.

EDIT AGAIN>>
i was wondering about just using /dev/ttyUSB0.  in linux "everything is a file".  that is the file used for the usb gecko.  wiiload writes to that file when it sends data to HBC and it doesnt need to be root.  and when i do "cat /dev/ttyUSB0"  i can read from that file without root.  is there something im missing that would keep geckoDotNet from using that same method?  it would allow running without root and also keep it from messing up the existing ttyUSB0.

the sources for wiiload should be in the download of the hackmii installer.  if you cant find them, ive got it here.

[dcx2]

for some reason, my monodevelop didnt have the same project settings as you described, so i just put #define MONO in a few files

The MONO symbol is not defined because the "normal" build procedure is for Windows.  Rather than defining the symbol in each file, you can define it globally in the project file.  I'll try to get a screenshot for you.

1 - to run this, i open a terminal and do "sudo mono geckodotnet.exe".   it only finds the disassembler if it is in the current directory of the terminal.  meaning that i have to cd to the folder where the exe is before i run it if i want to disassemble and whatnot.

When it launches vdappc, it uses the path "./vdappc".  I'll see if I can't tweak this a bit so it finds the directory that contains gecko dotNET.

I don't know why the context menu is missing, but I can look into that (it's important!)  Perhaps we should use mono 3.5...there might be improvements that mono 2.0 is missing.  I also can't find if monodevelop has a form designer, which makes it so much easier to navigate around the app source code...

I also don't know why it breaks /dev/ttyUSB0, or why it doesn't read/write /dev/ttyUSB0 instead of using libftdi.  Most of this was written by Link, and there might be reasons he did it this way.  But, hopefully, hawkeye will post a guide on modifying udev rules so we don't need root.