Hacking Coding vWii 3-core support - everything you need to know.

  • Thread starter Thread starter Maxternal
  • Start date Start date
  • Views Views 242,152
  • Replies Replies 1,263
  • Likes Likes 13
The picture Ray is showing was the second device team f0f describes in their 30c3 presentation.
I see the words ghetto ftdi which is likely an ftdi usb to serial TTL converter.
Apparantly, marcan had some code that made interfacing usb2serial possible. It allows bidirectional communication to the wiiu. (ghettohci)
The wiiu adapter was connected to another usb 2 serial ttl adapter to provide the pc serial port.
Only 3 wires are used, likely RXD TXD and GND.
The goodfet adapter is an usb 2 Jtag adapter known to google as well.. I think they only use the ftdi chip in it to use it as an usb 2 serial bridge. (That's why they have the thin wires soldered to the board) (He probably didn't had 2 ghetto ftdi boards lying around, that's my guess, or the wiiu code couldn't handle the ghetto ftdi chip)

The third method Team f0f used for communication was an usb gecko connected to some unused wiiu gpio lines.
There exist pictures of that setup as well. You have to emulate the gamecube EXI bus with these gpio lines in software to get that setup running, and you need an usb gecko.
Apparently, this method has a much bigger transfer rate. (Against 115200 baud for setup 2 in the picture Ray is showing.)

The disadvantage of method 3 is the fact that you have to solder the wires in your wiiu which will void it's warranty.
 
my warranty's probably already void from the moment I installed HBC ... my soldering skills, though, would leave the Wii U DESPERATELY needing those unavailable warranty repairs, though. >.<
 
my warranty's probably already void from the moment I installed HBC ... my soldering skills, though, would leave the Wii U DESPERATELY needing those unavailable warranty repairs, though. >.<

Hear Hear. By the way, thanks for all your hard work and everything you've done for this scene!
 
  • Like
Reactions: kehkou
It depends Max, if you took a vwii nand backup before you installed the HBC, you could perhaps restore such a virgin backup and erase all homebrew traces?
 
  • Like
Reactions: Ray Lewis
It depends Max, if you took a vwii nand backup before you installed the HBC, you could perhaps restore such a virgin backup and erase all homebrew traces?
The problem is that I wouldn't be able to dump the NAND until AFTER installing HBC (or with a little soldering which I would assume would also leave traces) so I would be unable to get a completely clean NAND dump to restore.

On the other hand, there's always that slight chance that they'd accept my console if I just completely wiped the NAND clean and claimed my vWii never worked (except I've already done a Wii -> vWii transfer and then extracted my Mii's out of vWii for use in Wii U mode so I they still might notice :ph34r: .)
 
  • Like
Reactions: Ray Lewis
You only need two resistors to connect the sensor bar port to a USB to TTL dongle (divider to drop 12V to 5V or 3.3V, depending on flavor). And no resistors to hook it up to a proper RS232 DB9 port - RS232 will happily take 12V/0V signaling. The diagram that we showed in the slides (sensor bar direct to serial connector) isn't literally what we used (we used a TTL adapter and two resistors), but it would work. You just need to invert the logic in the software when bitbanging if you're doing real RS232.

Also, we tested the communications (both lolserial and ghettohci) on a Wii first, because it's easier (booting into HBC is way faster with BootMii-Boot2 and we could use the gecko for debugging the other methods).

And yes, sven was using the hacked up GoodFET because he didn't have another USB-TTL lying around. I learned my lesson a couple of years ago and bought a dozen to keep around.
 
You only need two resistors to connect the sensor bar port to a USB to TTL dongle (divider to drop 12V to 5V or 3.3V, depending on flavor). And no resistors to hook it up to a proper RS232 DB9 port - RS232 will happily take 12V/0V signaling. The diagram that we showed in the slides (sensor bar direct to serial connector) isn't literally what we used (we used a TTL adapter and two resistors), but it would work. You just need to invert the logic in the software when bitbanging if you're doing real RS232.

Also, we tested the communications (both lolserial and ghettohci) on a Wii first, because it's easier (booting into HBC is way faster with BootMii-Boot2 and we could use the gecko for debugging the other methods).

And yes, sven was using the hacked up GoodFET because he didn't have another USB-TTL lying around. I learned my lesson a couple of years ago and bought a dozen to keep around.

Being serious Marcan. Did you ever try side channel hacking? I believe you mentioned that idea. Nobody seems to know what that is or care...at least publicly.
 
Does this mean USB support was added to mini or he used the native IOS feature ?

GhettOHCI is called GhettOHCI because it's probably just about the simplest, crappiest USB host driver you could possibly write. So yes, I added something that could vaguely be called USB support to mini.
 
I guess you are not willing to share GhettOHCI with us?
I once tried to add mass storage usb support in mini but never succeeded in finishing it.
A hurdle I discovered was the fact that mini didn't had a heap that could be used to allocate the DMA buffers used by the usb stack.
I assume an usb to serial can work without DMA as the amount of data is much smaller and speed isn't an issue.

Anyway, thanks for giving a little more in depth information. I am happy I am not always hitting the ball wrong....
 
I guess you are not willing to share GhettOHCI with us?
I once tried to add mass storage usb support in mini but never succeeded in finishing it.
A hurdle I discovered was the fact that mini didn't had a heap that could be used to allocate the DMA buffers used by the usb stack.
I assume an usb to serial can work without DMA as the amount of data is much smaller and speed isn't an issue.

Anyway, thanks for giving a little more in depth information. I am happy I am not always hitting the ball wrong....


Not familiar with USB drivers, why do you need a heap for that? Aren't statically allocated buffers enough here? Not that implementing a dynamic memory allocator is terribly hard either (it's a 1 week coding project for second year students at my university).
 
Not familiar with USB drivers, why do you need a heap for that? Aren't statically allocated buffers enough here? Not that implementing a dynamic memory allocator is terribly hard either (it's a 1 week coding project for second year students at my university).
Delroth, is it something you have already, could whip up quickly, or were you speculating there? If it is needed, maybe you could talk with OBCD and/or Maxternal (and others). That would be constructive;-) If it is needed.
 
Not that implementing a dynamic memory allocator is terribly hard either (it's a 1 week coding project for second year students at my university).

I guess that has to do with a node/tree refresh. total memory allocated(statically) - used memory(app node) spews max usable memory. To identify everyapp using it, I'd use an index, size ,address(which would be no lower than base+address) and not higher than base+size
 
  • Like
Reactions: Ray Lewis
Delroth, is it something you have already, could whip up quickly, or were you speculating there? If it is needed, maybe you could talk with OBCD and/or Maxternal (and others). That would be constructive;-) If it is needed.

Maybe you could try reading the posts you are replying to.
 
GhettOHCI is called GhettOHCI because it's probably just about the simplest, crappiest USB host driver you could possibly write. So yes, I added something that could vaguely be called USB support to mini.
Thank you for the answer. So I guess basic enumeration, descriptors management and support of the attached device ?
Could you please just confirm that the OHCI controller has the registers mapped as described in this document (page 122)
ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf
And the base addresses registers are the same as for the Wii ?
I was wondering if OHCI0 and OHCI1 are associated with the 2 Wii port and if there are 2 more for the WiiU additional ports ?

It would be nice to use 2 USB to serial adaptors, one on the WiiU and the other on a PC.
 
  • Like
Reactions: Coto
I explained what they did for the OHCI controller on the Wii U here. It's a standard OHCI controller, except with the usual 32-bitwise byte swapping due to the host being big endian.

And yes, it's just about the dumbest possible support for enumeration. Descriptors are ignored other than a sanity check on VID/PID. Single device. No hubs. No hotplugging. No IRQs - it only queues one transaction and blocks for completion. Everything is hardcoded except the port that the device is plugged into. It's ~550 lines of code for the whole thing, including the FT232 driver. It doesn't need a heap (though it does need buffers in MEM2, but Mini already has macros for putting variables in MEM2 sections). I could share it, but where's the fun in that? I'd rather people learn how to implement this kind of thing so they can do it on other devices ;)
 

Site & Scene News

Popular threads in this forum