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

[ÐeltaResero]

Then just donate a few dollars like me and a bunch of others have! If everyone chips in a little bit then Maxternall will have a Wii-U in no time.

This type of logic would probably be more practical after the holidays. As for the Linux side of things here, is there anyone else currently working on this? The SMP part is years ahead of my time and the only thing slightly useful that I have found was on "http://linux-kernel.2935.n7.nabble.com/PATCH-V3-Add-Smp-support-for-Allwinner-A20-0-3-td723286.html". Other than maintaining the kernel with the mainline version, I've only been fixing bugs as they are found.

Outside of this, I did get the XFree86 Cube driver (by Nuvalo) to compile and work again with the Xorg 7.6 & 7.7 (latest current versions) on Wii consoles, but I still eventually need someone to test this on vWii mode on a WiiU console. This driver will almost certainly not work in WiiU native mode.

Also, if someone could test the two boot methods for vWiiU (as mentioned on "http://code.google.com/p/gbadev/) the with my 2.6.34 kernel modifications that might help me narrow down why 2.6.x boots and 3.x doesn't. A compiled MINI demo can be found here: "https://spideroak.com/browse/share/DeltaResero/wii/Testing/". The password is "delta" and it should be called "2_6_34-MINI-zImage.tar.xz".

 

[bravest]

The 3.0 kernel is not compatible with vWii?

As for SMP I believe all that is required is to compile the kernel with CONFIG_SMP=y as well as the cache coherency flag. Then a modified wii.dts must be provided with 3 cpus.
Then once the vmlinux image is loaded into memory, run the core bringup stub and have CPU0 jump to the linux entrypoint.
The secondary cores should jump to entry+0xc0 (defined to be the entry point for other cores).

There may be some timing issues as I am not sure as to what CPU0 is doing in the mean time.

-bravest

 

[Deletedmember331810]

The 3.0 kernel is not compatible with vWii?

As for SMP I believe all that is required is to compile the kernel with CONFIG_SMP=y as well as the cache coherency flag. Then a modified wii.dts must be provided with 3 cpus.
Then once the vmlinux image is loaded into memory, run the core bringup stub and have CPU0 jump to the linux entrypoint.
The secondary cores should jump to entry+0xc0 (defined to be the entry point for other cores).

There may be some timing issues as I am not sure as to what CPU0 is doing in the mean time.

-bravest

You should make your way to efnet @ #vwii. Thanks for your input!

 

[ÐeltaResero]

The 3.0 kernel is not compatible with vWii?

As for SMP I believe all that is required is to compile the kernel with CONFIG_SMP=y as well as the cache coherency flag. Then a modified wii.dts must be provided with 3 cpus.
Then once the vmlinux image is loaded into memory, run the core bringup stub and have CPU0 jump to the linux entrypoint.
The secondary cores should jump to entry+0xc0 (defined to be the entry point for other cores).

There may be some timing issues as I am not sure as to what CPU0 is doing in the mean time.

-bravest

The 3.0 kernel is compatible with vWii just not with both both methods (see this for more info: "http://code.google.com/p/gbadev/issues/detail?id=9"). As for SMP, I know at the very least we'll need to add support into the wii.dts file like you said. I assume we'll need to implement cache coherency somehow and add the address locations for the additional cores too , but everything else after that would just be guess work for me as I have never done anything like this in the past.

 

[Maxternal]

As far as adding it to wii.dts, I'm not entirely sure about that (although I'm not ruling it out) since the Linux code seems to be able to distinguish between having a processor with multiple threads (like cores/hyper threading) and having multiple physical CPU's. The PS3's DTS file, for instance, just shows one processor (although I DO realize that it doesn't exactly have cores either.)

adding Espresso (and perhaps a separate Espresso-vWii) to the CPU table so it can distinguich it by it's PVR would probably be a good idea, too.

I could be wrong, though, since I admit I still really need to set apart a good amount of time all at once to dig through Linux code (5 minute pockets of free time here and there just isn't cutting it for me) and I still haven't quite nailed down where the the threads-per-processor number is defined that the 360 code uses.



Also, thanks very much bravest for that entry+0xc0. I'll have to play with that a bit. I assume that's referring to the entry point of the kernel itself as opposed to the wrapper so (as far as the timing you mentioned) I might have to hunt that down, see what the memory map is like at that point and have the cores wait for the wrapper to finish loading the kernel.

 

[bravest]

As far as adding it to wii.dts, I'm not entirely sure about that (although I'm not ruling it out) since the Linux code seems to be able to distinguish between having a processor with multiple threads (like cores/hyper threading) and having multiple physical CPU's. The PS3's DTS file, for instance, just shows one processor (although I DO realize that it doesn't exactly have cores either.)

adding Espresso (and perhaps a separate Espresso-vWii) to the CPU table so it can distinguich it by it's PVR would probably be a good idea, too.

I could be wrong, though, since I admit I still really need to set apart a good amount of time all at once to dig through Linux code (5 minute pockets of free time here and there just isn't cutting it for me) and I still haven't quite nailed down where the the threads-per-processor number is defined that the 360 code uses.



Also, thanks very much bravest for that entry+0xc0. I'll have to play with that a bit. I assume that's referring to the entry point of the kernel itself as opposed to the wrapper so (as far as the timing you mentioned) I might have to hunt that down, see what the memory map is like at that point and have the cores wait for the wrapper to finish loading the kernel.

Exactly right about the entry point, the wrapper is not the one I was referring to. I believe the wrapper ungzips the compressed kernel image and device tree blob (compiled from wii.dts) and then jumps to the entry point of the kernel which should be 0xc0000000 once everything is correctly loaded. The kernel start routine for powerpc processors expects some values to be passed to certain registers which I think the wrapper handles.

It should be possible to modify the wrapper to signal its completion by modifying http://lxr.free-electrons.com/source/arch/powerpc/boot/main.c?a=powerpc . Right before the wrapper calls kentry() the executing core could flag mini via IPC to kick the other cores out of their spinlocks.

The code for the actual kernel entry point is found here: http://lxr.free-electrons.com/source/arch/powerpc/kernel/head_32.S?a=powerpc
CPU0 will enter at _start, and I believe that the secondary processors should then longjump to entry+0xc0 which is 0xc00000c0 .

See these lines specifically:

218        . = 0xc0                        /* for prep bootloader */
219        li      r3,1                    /* MTX only has 1 cpu */
220        .globl  __secondary_hold
221 __secondary_hold:
222        /* tell the master we're here */
223        stw    r3,__secondary_hold_acknowledge@l(0)
224 #ifdef CONFIG_SMP
225 100:    lwz    r4,0(0)
226        /* wait until we're told to start */
227        cmpw    0,r4,r3
228        bne    100b
229        /* our cpu # was at addr 0 - go */
230        mr      r24,r3                  /* cpu # */
231        b      __secondary_start

If CONFIG_SMP=y , this section of code will be available. The .= directive ensures that this assembly will be located at offset 0xc0 . The SMP only code puts each processor in a holding state until CPU0 signals it to continue to __secondary_start where the secondary cpu will be initialized.

It is possible that some tweaks to the current powerpc SMP code are necessary, however we wont know until we complete this step.

-bravest

 

[bravest]

Is anyone available to test my kernel patches?

-bravest

 

[obcd]

bravest
at the moment, it's mostly maxternal that compiles stuff and nonx who does the testing on wiiu for him.
Ninja Carver could give you an account on our linux development server. We use that to upload our code for testing.
maxternal lives in South America. He usually enters the irc after midnight (our local time) and he doesn't show up often in the weekends.
I noticed you were on our irc channel last night but didn't got much response there. You could try to send a PM to max as well.
He was working on a side project to backup the vwii nand in a bootmii compatible file format last night.

 

[Maxternal]

Is anyone available to test my kernel patches?

-bravest

Sorry, not yet. Work has been CRAZY this last week or so. The little side coding obcd mentioned that I had done was something that I finally got around to and had occurred to me a quite while ago. I'm excited to get to it as soon as I can, though. (Both you and some code Joostin sent me that I haven't had a chance to look at yet.)

 

[Pogostick]

Hey guys were there any contests to win a Wii U between 5/9/13 and 12/6/13 because if one hasn't happened or is still happening, I have an idea!

 

[ÐeltaResero]

Hey guys were there any contests to win a Wii U between 5/9/13 and 12/6/13 because if one hasn't happened or is still happening, I have an idea!

You might have better luck trying to get a used one or looking into using coupons and other promotions. Here in Canada there was a $50 price drop, but generally it's still cheaper in the United States.

 

[Pogostick]

Well it depends on what Maxternal wants. Hey Maxternal, what kind of Wii U do you want?

 

[bravest]

Nice quint post dummy.

-bravest

 

[Pogostick]

Thanks!

 

[rednekcowboy]

So it appears that f0f will be "spilling the beans" at 30C3 this year:

Abstract:

About a year ago Nintendo released their latest video gaming console, the Wii U. Since 2006, the Wii has led to one of the most active homebrew scenes after its security system was completely bypassed. This talk will discuss the improvements made in Wii U's architecture and explain how it was broken in less than 31 days. The talk is targeted at those who hack (or design) embedded system security, but gamers might also find it interesting.

Description:

The talk will consist of several parts. First, we will discuss the Wii U: what it is, what makes it tick, and how it compares to its predecessor, the Wii.

Next, we will cover two different approaches that we used to attack the Wii U system. The focus will be on how our results were achieved instead of on what those results are, so you can reproduce the attacks at home. Along the way we'll describe the Wii U's security architecture.

The third and final part of the talk will cover where to go from here: What is broken, what is yet to be broken, things that still have to be done to create a viable homebrew ecosystem, the balance between the effort required and the reward for users and hackers, and the potential upsides and downsides of different approaches.

Basic knowledge of embedded systems and CPU architectures is recommended for attendees, although we will try to explain required concepts as we go along.

Before and after the talk we will also be available in the hackcenter for those who would like to discuss further details or embedded security in general.

 

[sven42]

no, we won't.

 

[pwsincd]

no, we won't.

that depends on what beans are to be spilt...

 

[rednekcowboy]

no, we won't.

Not necessarily releasing your results, but it sounds like the method used to obtain those results will be revealed. Essentially leading to the same end result anyways, no?

One should be able to safely assume (yes, I know this makes an ass out of u and me) that if the method and steps are released someone will use the method to obtain the same results that f0f did? So, in other words, releasing the exploit without releasing the exploit kind of thing.

FWIW, any chance of sending me the notes of that symposium? Not likely that I'll know what to do with them, but it would be nice to play around and learn a little from it as my Wii U is basically sitting here gathering dust anyways......

 

[bravest]

Not necessarily releasing your results, but it sounds like the method used to obtain those results will be revealed. Essentially leading to the same end result anyways, no?

One should be able to safely assume (yes, I know this makes an ass out of u and me) that if the method and steps are released someone will use the method to obtain the same results that f0f did? So, in other words, releasing the exploit without releasing the exploit kind of thing.

FWIW, any chance of sending me the notes of that symposium? Not likely that I'll know what to do with them, but it would be nice to play around and learn a little from it as my Wii U is basically sitting here gathering dust anyways......

Where's the fun in spilling the beans? If everything is simply handed to you, it breeds complacency and entitlement.
Since you have a Wii U, have you considered working on the linux port? You are one of the few people in a position to actually test it.

-bravest

 

[rednekcowboy]

Where's the fun in spilling the beans? If everything is simply handed to you, it breeds complacency and entitlement.
Since you have a Wii U, have you considered working on the linux port? You are one of the few people in a position to actually test it.

-bravest

My friend, I was one of the original testers and still, from time to time (though it hasn't happened for a little while) load up one of the new kernels and test it. With work, kids and life in general, lately spare time has been severely lacking however. Though my Christmas vacation will be starting next week (Wed) so I'll have a couple of weeks of free time to pitch in again.

All I'm saying is that while I would love to be at the conference and would enjoy the discussion (though admittedly would likely be lost in it) I would like the information from it. They are going to be discussing it anyways so no harm in asking for something that they are going to be doing anyways. FWIW, the part I am referring to is this:

The focus will be on how our results were achieved instead of on what those results are, so you can reproduce the attacks at home.