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

[Ninja_Carver]

FWIW, a full SMP port of Linux is probably not possible given only the information that I disclosed. However, any effort to start and get to a partial port (and subsequently identify what's missing) would already be a big milestone and a demonstration of interest.

marcan-san, I've been diligently working on such an implementation, though most of it has been happening behind-the-scenes.
I will be up front with you, I am absolutely terrible at programming. That said, I have a strong Linux background and figured I would see what I could do.
My preliminary test was successful, basically following the gc-linux wiki to the 'T' and building an SD card from scratch, I was able to boot 2.6.32-mikep5 using HBC.
Then I discovered another project (https://github.com/DeltaResero/GC-Wii-Linux-Kernel-3.0.y) which I tried to build as per the instructions, but alas, the vWii simply would not boot the zImage (result was black screen, though I did not personally test, so I can't say it wasn't user error).

At this point I'm back to vanilla linux-2.6.32 from kernel.org. Applied MIKE's latest patch, and built successfully, just waiting for my tester to get back to me on that for results. Once I've finalized the proper build process for cross-compiling this kernel for PPC, I would like to experiment with enabling SMP in the kernel config, currently CONFIG_SMP is not set.

My question to you is, could enabling SMP in the kernel at least 'show' us more of the CPU (for instance in a cat /proc/cpuinfo)? or does the IOS first have to be modified to extend that boundary.

I'm sorry if this isn't making very much sense. Honestly trying to learn as I go (never owned a Wii) and a lot of trial and error is involved.

Your feedback is appreciated. Thanks

EDIT: further on this, I found this little snippet of code in arch/powerpc/boot/dts/wii.dts. Could modifying these values do anything for us?

+    cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        PowerPC,gekko@0 {
+            device_type = "cpu";
+            reg = <0>;
+            clock-frequency = <486000000>; /* 486MHz */
+            bus-frequency = <162000000>; /* 162MHz core-to-bus 3x */
+            timebase-frequency = <40500000>; /* 162MHz / 4 */
+            /* Following required by dtc but not used */
+            i-cache-line-size = <32>;
+            d-cache-line-size = <32>;
+            i-cache-size = <32768>;
+            d-cache-size = <32768>;
+        };
+    };

 

[Cyan]

I would like to thanks Marcan/sven/comex/drmr for still coming here (even after all the flame fest few pages ago and the site reputation), explaining your point of view and providing help when users ask.
I'm sure a lot of users are reading in silence, like myself, even if we can't do anything with it ourselves we like to understand and learn how the console works.

I agree with what you said earlier, about learning how it works first instead of trying to do something specific without understanding. (edit: I'm still learning things on Wii, I'm far from understanding WiiU's internal)
You started to learn on older consoles, maybe it was easier to start on the old ones and advance with console development rather than users like maxternal starting now with the WiiU.
I hope what users learn now will be useful to them later.

 

[JoostinOnline]

@sven and marcan: Thanks guys, that's very helpful. I've been unclear on the matter.

 

[marcan_troll]

I will be up front with you, I am absolutely terrible at programming.

Not a very good start for this kind of bring-up. However, if you get together with someone who does know about PPC low-level programming (but may not know much about Linux), that could be an interesting combination

Then I discovered another project (https://github.com/DeltaResero/GC-Wii-Linux-Kernel-3.0.y) which I tried to build as per the instructions, but alas, the vWii simply would not boot the zImage (result was black screen, though I did not personally test, so I can't say it wasn't user error).

Low-level debugging this kind of set up is stupidly tedious but there's no easy way around it (at least not on retail units). Usually what I'd do is turn on the Sensor Bar output to signal "reached this code", and then do a binary search through the boot process until I find the part where it fails. You'll really want to get a debug console going beyond the very early startup code though, and for that you'll probably need to do something like hook up a USB gecko to the POST pins like I did, or set up some other kind of serial port.

I debugged the PS3 AsbestOS early boot by either rebooting the console or infinite looping it to signal whether I reached some code or not, until I got the debug-over-ethernet thing to work. Yes, it was horribly tedious, but what can you do...

At this point I'm back to vanilla linux-2.6.32 from kernel.org

I know that there was some significant PPC reorganization in the kernel at some point, but I forget what kernel version that was. I think it was before 2.6.32. As long as the PowerPC arch stuff looks reasonably similar between 2.6.32 and whatever the latest 3.x version is these days, you're probably fine. If there have been significant changes, then you should invest time into getting a more modern kernel working as a base, otherwise you'll have to redo a lot of work.

My question to you is, could enabling SMP in the kernel at least 'show' us more of the CPU (for instance in a cat /proc/cpuinfo)? or does the IOS first have to be modified to extend that boundary.

CONFIG_SMP will do nothing for you. It just builds the kernel with support for SMP, but it has no idea how to do anything on the Wii U. Obviously you need CONFIG_SMP, but that alone won't get you anywhere.

EDIT: further on this, I found this little snippet of code in arch/powerpc/boot/dts/wii.dts. Could modifying these values do anything for us?

+    cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        PowerPC,gekko@0 {
+            device_type = "cpu";
+            reg = <0>;
+            clock-frequency = <486000000>; /* 486MHz */
+            bus-frequency = <162000000>; /* 162MHz core-to-bus 3x */
+            timebase-frequency = <40500000>; /* 162MHz / 4 */
+            /* Following required by dtc but not used */
+            i-cache-line-size = <32>;
+            d-cache-line-size = <32>;
+            i-cache-size = <32768>;
+            d-cache-size = <32768>;
+        };
+    };

Changing the numbers won't make anything go faster (those numbers tell the kernel information about the CPU, they don't change the actual facts).
One of the steps to port Linux to run on 3 cores is indeed to create more CPU nodes in the devicetree. That alone won't make anything work though. You need to add support in the kernel for spinning up the extra cores, and arch setup code to configure the MSRs the way I described. In order for any of this to work, you have to execute the kernel in Espresso mode, which means resetting it and performing the memory race that I described. This is best done either in the kernel early-boot code (zImage wrapper) or in an external loader/wrapper for it. You'll have to write Starbuck (Mini) code to actually perform the race.

In other words, you should start outside of Linux, making sure you 1) get the Espresso into Espresso mode (via the race exploit), 2) you have a set of MSR settings that work on the hardware, and 3) you can spin up the two extra cores and verify that they indeed are executing instructions. Once you get that going you can plug Linux in after/around it and see what happens.

 

[Ninja_Carver]

Not a very good start for this kind of bring-up. However, if you get together with someone who does know about PPC low-level programming (but may not know much about Linux), that could be an interesting combination

Wow, I wasn't expecting that much of a thorough, well thought out response. Thanks! And ironically, the quoted text above is in fact the case

 

[Slimmmmmm]

I'm so curious of how this turns out.

I feel sad seeing a few highly skilled people spending time in this topic posting and wonder why they are not doing something more important with their time.

I think most of the people that want some sort of SDK in place to play with code do not have the skill set for this part of the action, but what can we do....really ? Produce extra time in our lives to learn something we most likely wont need....or wait for someone else.

It's not a good situation for any of the many, many sides to this.

I always keep my name out of the credits and try to help for good reasons, I'm gutted at this stand-off type position we've found ourselves in but I've learned how important it is to embrace the work on a platform and lay tribute to those that lay the way.

When a softmod does come out (optimism) we can't forget the lessons learned.

Writing code is like having a baby, a lot of work before it's even released and once it's out you don't want someone to come and change the life you planned for your child.

So once we get a way to tinker with some C and use the WiiU hardware including the gamepad we need to ALL add to the library of code....whether it be a small app, a fix or a single line of code. Documentation, testing and everything else in a professional manner of those deserving the gift in the first place.

 

[bravest]

Any update on the bootmii fix marcan? I would ask over IRC, however I am currently at work.

-bravest

 

[obcd]

We will need a way to run code on the starbuck. Using mini for it seems a logical step, as we have linux distro's that use it to deal with hardware. A running mini would also allow us to backup the vwii nand contents. You never know when such a backup comes in handy.
Does anybody has a clue why mini isn't working on the wiiu. I hear rumours team f0f had intentions to fix it. Is this still the case or is it something we need to look in ourselfs as well?

Oops, being Ninja'd

 

[marcan_troll]

Mini definitely works on the Wii U. What may not work is the installer installing bootmii-as-IOS. I can't remember what the state of that was when we released it, though, but AIUI we may have had a bug where it didn't install properly on the Wii U (and we never didn't bother to fix it at the time because, well, see below).

If you DO get Bootmii-as-IOS installed (i.e. the title is there), then it will definitely work. Of course, you won't be able to run PowerPC code without the exploit (i.e. you won't get the BootMii menu) because the Espresso now always requires an encrypted blob to boot on the Wii U... but you knew that already, right?

 

[obcd]

After carefully reading the f0f blog this morning, that part started to make sense. I wrongly thought that the mini loader (the code in ios 254 that loaded armboot.bin from the sd card) used an exploit that no longer existed on the vwii. Thanks for clearing that up.

 

[psi-]

Sorry if this is a question already answered here in this thread..

Why doing this through vWii? WiiU has a full browser, WebKit based. If I interpret the build number correctly it's not even close to recent (html/css test results imply as much). Then there're other services that use pretty much direct http (miiverse) that could be spoofed with proxy. Risk for exploit being fixed is just as big as with vwii getting updated and vWii smp linux made impossible. There surely are dozens of exploits (potentially with POC's) for html/jscript/imageloaders engine this old.

Sure you'll then need to escape from browser to IOS/kernel mode (if there even is such a separation, given how easily WiiU locks up irrecoverably I don't think there is protected kernel mode), but there must again be ways to do that but you'd already have reasonable environment to see what's where in full WiiU.

 

[marcan_troll]

They cannot fix the vWii Espresso exploit. It's a ROM. It's a design flaw even.

The Wii U does have a proper kernel with memory protection. Apps, games, and the browser run in user mode.

 

[the_randomizer]

They cannot fix the vWii Espresso exploit. It's a ROM. It's a design flaw even.

The Wii U does have a proper kernel with memory protection. Apps, games, and the browser run in user mode.

Good. Glad the exploit can't be fixed.

 

[ihateu3]

You know what? I was thinking on this some last night. I might not be a dev of any kind but I've been around long enough in enough scenes to know bullshit when I smell it. I've seen time and time again, once well-respected teams have a big announcement about the next big thing and then nothing comes of it.

The same situation that is playing out here. They then come on and heckle and demean and challenge anyone who wants to step up but yet still refuse to do anything themselves. Eventually they quietly go away. You want to know why all of this happens? Because the "well-respected" team could not deliver on the announcement and gave up. Rather than be honest, they were worried about losing face in the hacking community so the came up with a lame ass bullshit excuse to try and cover their asses.

So far I've heard:

we don't want to enable piracy
the wii u is not good enough
it's too much work to build a new scene
there is not enough interest in the wii u
we don't have enough time
and new ones keep coming out as time passes

I call bullshit. I think f0f just couldn't deliver on the announcement and hype they caused. Not saying they aren't talented and all that but I also have been around long enough to know when something stinks and this is starting to smell so bad I can barely sit in the same room as my Wii U.....

Either that or they have a financial stake in not developing homebrew. Either way, the only time hackers stop hacking is when they either hit a wall they cannot surpass or are financially motivated to stop hacking.

I think you are misunderstanding why they are choosing not to release the exploits...

Basically, they have an exploit, and without any SDK for the wii-u their exploit can only be used for one thing, ONE THING, piracy!!! This exploit does not magically make homebrew appear, software still has to be developed using an SDK. Releasing the exploit does not help the development of an SDK in any way. The lack of interest they site, is because nobody was even working on an SDK, so they believed the interest was not there and not worth their time.

They have stated that if an SDK is developed or far along enough, they would most likely resume support, we cannot expect them to be the WHOLE dev team and do everything!

So they are choosing to not release this, because in its current state it is only good for piracy. If however, nobody succeeds into porting Linux, I do hope that they eventually release their work after the console is a generation old, where piracy would not harm it.

And yes I know, and they know that piracy will happen with the wiikey, its just their solution would make it much more easy (but then again it would stop criminals from profiting by making wiikey or cloned chips).

 

[the_randomizer]

I think you are misunderstanding why they are choosing not to release the exploits...

Basically, they have an exploit, and without any SDK for the wii-u their exploit can only be used for one thing, ONE THING, piracy!!! This exploit does not magically make homebrew appear, software still has to be developed using an SDK. Releasing the exploit does not help the development of an SDK in any way. The lack of interest they site, is because nobody was even working on an SDK, so they believed the interest was not there and not worth their time.

They have stated that if an SDK is developed or far along enough, they would most likely resume support, we cannot expect them to be the WHOLE dev team and do everything!

So they are choosing to not release this, because in its current state it is only good for piracy. If however, nobody succeeds into porting Linux, I do hope that they eventually release their work after the console is a generation old, where piracy would not harm it.

And yes I know, and they know that piracy will happen with the wiikey, its just their solution would make it much more easy (but then again it would stop criminals from profiting by making wiikey or cloned chips).

Well, when you put it that way, it makes a lot more sense. If there is no SDK for Wii U homebrew development, why release an exploit?

 

[ihateu3]

Well, when you put it that way, it makes a lot more sense. If there is no SDK for Wii U homebrew development, why release an exploit?

Exactly...

 

[the_randomizer]

Exactly...

Of course, I do admit that I misconstrued the hell outta Marcan's posts, but his intent was not to discourage, but to test us, if we were up to the task. It will be a tremendous undertaking, there's no denying that, but it's by no means impossible if we have the desire and if the effort is put forth

 

[ihateu3]

Of course, I do admit that I misconstrued the hell outta Marcan's posts, but his intent was not to discourage, but to test us, if we were up to the task. It will be a tremendous undertaking, there's no denying that, but it's by no means impossible if we have the desire and if the effort is put forth

Not trying to veer off topic to much more in this thread, but I think that people had very high hopes when F0F initially released the good news... Time went by, and people eagerly awaited the awesomeness to hit that they seen on the original wii. Everyone had very high hopes, and then F0F drops the bomb that they are not releasing exploits, people get upset with them without even fully understanding why they chose to do so.

It was the build up and the hype that everyone had hopes for something, and when they chose to not release, those hyped up people did not take the time to understand why they chose to not release (they where sitting at the sidelines patiently drooling), they only seen it as a big and major let down, since their hopes where built up so high... That's where the anger came from

I am sure F0F is not too happy themselves to put all that work into something that as of now can only help piracy... They could use some help with this as well, they don't wanna be the sole devs!

 

[the_randomizer]

Not trying to veer off topic to much more in this thread, but I think that people had very high hopes when F0F initially released the good news... Time went by, and people eagerly awaited the awesomeness to hit that they seen on the original wii. Everyone had very high hopes, and then F0F drops the bomb that they are not releasing exploits, people get upset with them without even fully understanding why they chose to do so.

It was the build up and the hype that everyone had hopes for something, and when they chose to not release, those hyped up people did not take the time to understand why they chose to not release, they just seen it as a major let down, since their hopes where built up so high...

I am sure F0F is not too happy themselves to put all that work into something that as of now can only help piracy... They could use some help with this as well, they don't wanna be the sole devs!

Oh, they won't be, I've been involved with some behind-the-scenes action. Rest assured, f0f will not be alone on this undertaking. Something will come of it.

 

[ihateu3]

Oh, they won't be, I've been involved with some behind-the-scenes action. Rest assured, f0f will not be alone on this undertaking. Something will come of it.

If anything, I trust that they really do have an exploit, and that does prove that there is potential, and should also provide so motivating factors... Even if the devs working on it are not as talented, F0F seems to have no problem helping those who deserve it! I really do believe they wanna see the wii-u opened up as well, but don't wanna be the only guys doing work for mooches...