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

  • Thread starter Thread starter Maxternal
  • Start date Start date
  • Views Views 242,136
  • Replies Replies 1,263
  • Likes Likes 13
is there any progress on 3core other than Linux ?
Well, yesterday I had an idea of exactly how to accomplish putting SOME 3-core support into apps made with libogc (like most of the stuff you run from the HBC) It wouldn't be as versatile and easy to use from the programmer's point of view as Linux would be but it would theoretically give a big boost in processing power (kinda the "number crunching" that Marcan mentioned in his blog.) I'm coding up a test for this concept now but we'll see what actually becomes of it.
 
Well, yesterday I had an idea of exactly how to accomplish putting SOME 3-core support into apps made with libogc (like most of the stuff you run from the HBC) It wouldn't be as versatile and easy to use from the programmer's point of view as Linux would be but it would theoretically give a big boost in processing power (kinda the "number crunching" that Marcan mentioned in his blog.) I'm coding up a test for this concept now but we'll see what actually becomes of it.


So, theoretically, if someone ported Wii 64 to work in the tri-core Linux, one could get a potential speed boost?
 
I thought running linux in the background will use up some of the CPU.
Linux itself shouldn't, no. Running it in the background, it just kinda sits there and waits until the application asks for it's help. If Linux wasn't there to offer it's help, though, then the application itself would have to take care of everything by itself and so what extra CPU time you "save" by not running Linux is extra CPU time the application now has to spend anyway.

What DOES happen, though, is that Linux would then allow you to be running more than one thing at a time so if YOU had something else running in the background (like a web server, antivirus, or you're just using music player at the same time) then THAT might cause a problem.
 
Linux itself shouldn't, no. Running it in the background, it just kinda sits there and waits until the application asks for it's help. If Linux wasn't there to offer it's help, though, then the application itself would have to take care of everything by itself and so what extra CPU time you "save" by not running Linux is extra CPU time the application now has to spend anyway.

What DOES happen, though, is that Linux would then allow you to be running more than one thing at a time so if YOU had something else running in the background (like a web server, antivirus, or you're just using music player at the same time) then THAT might cause a problem.

Oh, okay.
Linux will use some memory too, but it shouldn't be too much..?
 
How large of a Linux build do you think would be required to provide the services that would be useful to homebrew? Also, is there any way to unload the parts of the memory that the Wii U reserves for its own software? If you could free up that gigabyte of memory, or even part of it . . .
 
How large of a Linux build do you think would be required to provide the services that would be useful to homebrew? Also, is there any way to unload the parts of the memory that the Wii U reserves for its own software? If you could free up that gigabyte of memory, or even part of it . . .
The build really shouldn't be all that big (although not sure of exact numbers off the top of my head ATM) You have to remember, though, that right now we're dealing with vWii on Wii U so we only get access to the same memory we had on a normal Wii and that's only ~78mb
 
The build really shouldn't be all that big (although not sure of exact numbers off the top of my head ATM) You have to remember, though, that right now we're dealing with vWii on Wii U so we only get access to the same memory we had on a normal Wii and that's only ~78mb

The bare-bones Linux kernel running a few services on my router uses 8 mb of memory. It is definitely possible to squeeze something useful in there, but it would be important to only load services when they are needed. One thing I do like about Linux is you can really strip it down.
 
my idea is to get it to boot off of a disk image file that you just copy onto your SD card instead of having it format everything and then have it autoboot the Linux app with the bare minimum it needs and then exit back to HBC when done. I'd like something that can just be copied and pasted without all the technical prep involved.

(since that might involve long load times, it could also be made to stay in Linux when done and exit to a very simple Linux GUI to avoid the long load times the second time around if you have multiple Linux apps installed and just want to switch)


BUT, of course, first we have much more important things to tackle (3 cores and new drivers) so that's much farther down the to-do list still.
 
  • Like
Reactions: Ray Lewis
I haven't been here for a while, really impressed about how much has been done and if my damn wii u wasn't broken I would load this right away. Still would love to help make this as I probably could help somewhat however I have legal contracts which screw that up. Keep up the work and I can't wait for 3 cores to work together. On a final note, do you think that once this is done it will serve as a good platform for unlocking development. Will be interesting to see. Cheers, Andy.
 
This is getting pretty interesting, you seem to be having some real progress. I wish you luck!
 
I've added a "miscellaneous tools" section to the download page on the googlecode site.
as usual, here's the link to the site https://code.google.com/p/gbadev/

This is for tools I've had to code up in the investigation process, trying to figure out how things work.
So far, I've only added a ancast image decrypter but more to come.
for information about an ancast image, go here : http://wiiubrew.org/wiki/Ancast_Image
Basically, it's what Nintendo uses to store some of those things that have an extra layer of encryption on Wii U like the System Menu and the NANDLoaders (the things that look like IOS512 and IOS513) so this would be the tool to use if you're curious about their contents.

The way you use it:
1. You extract the downloaded ZIP file onto the SD card
2. You get the right(*) APP file for the title you're interested in our of a NAND dump rename it to 00000017.app and place it in the bootmii folder on the SD card
3. Run the "launch bootmii" option from HBC
4. The Wii U hardware will decrypt the encrypted portion of the file, dump it into sd:/bootmii/dump.bin and then reset the console back to the Wii U menu.

(*) the right APP file, depending on which one you're interested in is :
00000003.app for the 1-512 title
00000001.app for the 1-513 title
0000000c.app for the OLD system menu
00000017.app for the NEW system menu (after this last 4.0 update)

If you think it's taking too long, to check on it's progress take a look at the sensor bar with a digital camera. The LED's will turn on while it's decrypting so before that it's still loading and after that it's dumping it to the file.

enjoy
 
Partially off-topic but here it goes:

has anyone tried to to install a decrypted system menu to their vWii? (or at least if someone with a hardware NAND flasher setup and a backup; try it).
I am guessing that would mean the decypter would need to be modified to output a file with the encrypted contents decrypted plus extra stuff vs just the encrypted portion (or did I misinterpret what the decrypter does)

basically, I would like someone to test (or post if they already have tested it) repacking a system menu wad with the decrypted 00000017.app and see if the system menu will still function with it decrypted.




I would try it myself but I have no hardware flasher nor the soldering skills to install one and have vWii even function by the time its installed.

if it does work, that would allow something like Priiloader to work with vWii if its patches were updated for the vWii system menu as everyone's decrypted system menu (from same region and firmware version) should the same.
 
  • Like
Reactions: Ray Lewis
Partially off-topic but here it goes:

has anyone tried to to install a decrypted system menu to their vWii? (or at least if someone with a hardware NAND flasher setup and a backup; try it).
I am guessing that would mean the decypter would need to be modified to output a file with the encrypted contents decrypted plus extra stuff vs just the encrypted portion (or did I misinterpret what the decrypter does)

basically, I would like someone to test (or post if they already have tested it) repacking a system menu wad with the decrypted 00000017.app and see if the system menu will still function with it decrypted.




I would try it myself but I have no hardware flasher nor the soldering skills to install one and have vWii even function by the time its installed.

if it does work, that would allow something like Priiloader to work with vWii if its patches were updated for the vWii system menu as everyone's decrypted system menu (from same region and firmware version) should the same.
I was actually contemplating something like that at one point. You could start by trying to install the decrypted system menu as another title for testing as not to run the risk of bricking by overwriting the real one. (maybe 00000001-00000001 instead of 00000001-00000002 since vWii has no boot1/boot2)

My first impression would be just using a hex editor to overwrite the encrypted part of that APP/DOL file and then changing the entry point (and the corresponding SHA1 in the TMD) ... BUT I'm not sure that would work since it would take up the same memory area that the 1-512 uses which would be used by the IOS to load a NON-encrypted title like this.
Moving it to another memory area that doesn't overlap seems like it should work but it might require some patching which wouldn't be quite as simple.

getting the separate copy of the system menu to autoboot would be a bit more dangerous, though. The process of booting an encrypted title and a non-encrypted title would be different and I'm not sure how the IOS determines which one to do. It might just be hard coded that when it sees exactly 00000001-00000002 it will always be encrypted and not in any other moment. It could also be that the system menu IOS is set to always run an encrypted title and the others are not or there could some flag that's set.

If the system menu HAS to be encrypted (as long as there's not any integrity checks of the system menu from the Wii U side beforehand ... I'm not exactly sure about the boot process for vWii) you might be able to replace the 00000017.app file with a MODIFIED version of the 00000003.app file from the 1-512 title. I assume the IOS leaves an argument for the 1-512 title, telling it what title to load from NAND so I'd think you could make a modified version with that argument already in place so that it always autoboots the same title so THAT'S what you'd theoretically have to replace the 00000017.app content with.

seems possible at least
 
  • Like
Reactions: the_randomizer
Hence, having hardware ways to recover and backup would be invaluable for this type of testing. Thanks Max.

Edit: this is why I get frustrated. If ways to backup would be shared and verified it would open up options. Instead, nobody wants to explore and take risks because failure=brick. 360 crap never worried me. Oops, hardware flash to recover. Started a thread in this but apparently nobody who knows will share.
 

Site & Scene News

Popular threads in this forum