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

[the_randomizer]

It is not possible. Sven and Marcan are experts. If you can run unsigned code without an exploit...why need an exploit? If you have exploit, then what can you use it for. There are aspects to the os that need to be worked out. Even if you jump to piracy, it gets patched without a way to prevent updates. It is not possible as Sven said. If you celebrate Thanksgiving, happy Thanksgiving. Marcan and Sven gave time to respond, thanks for that.

And like I said, it's all too clear that neither an exploit nor unsigned code is feasible in vWii or in Wii U mode, so with that being said, in my opinion, this thread should be closed as nothing will come as a result of said discussion. Everything that has been said is being repeated, we get it people, the Wii U hacking scene was DOA before it even began.

 

[papermanzero]

Not "tricky and challenging", impossible with the WiiU's software stack.
But feel free to spend time thinking about it and come up with a solution! And by solution I mean something with detailed instructions, not just handwaving!

Nothing is impossible especially with software.
Because you don't know a solution doesn't mean it's impossible.
Furthermore the topic is not to create a solution about a secure dual stack (right now and immediately).

As said: The whole community said (long time ago) it's not possible to load Gamecube games via usb on the Wii. Well, crediar proved that it's possible.
GC Loading

 

[obcd]

The Title of this Thread is Coding vWii 3 core support.
The last couple of weeks we have learned that we are not (yet) clever enough to earn the exploit.
We also have learned that the vwii nand has 2 blocks.
One block is likely used to boot the arm in wiiu mode, the other to boot the arm in vwii mode.
Besides that, we have also learned that the wiiu might have methods to prevent reverting to older firmware.

And some want to close this thread full of interesting pieces of the puzzle?
It won't be tomorrow we will finish that puzzle. 2 many pieces are still missing.

 

[OncleJulien]

the flip side of the entitlement coin is scorched earth policy.

 

[the_randomizer]

the flip side of the entitlement coin is scorched earth policy.

Your point?

 

[Pogostick]

Nothing is impossible especially with software.
Because you don't know a solution doesn't mean it's impossible.
Furthermore the topic is not to create a solution about a secure dual stack (right now and immediately).

As said: The whole community said (long time ago) it's not possible to load Gamecube games via usb on the Wii. Well, crediar proved that it's possible.
GC Loading

Ah yes because the Wii and Wii U are the same in ways or so I assume. But Ray Lewis is right, let's wait for 30c3, grab a popcorn a beverage (What's your favorite beverage? ) and see if it holds any fruit we'll be looming for. This is far from over.

 

[OriginalHamster]

I agree with sven and his worries about piracy, however some developers as djtuei has achieved homebrew apps like Devolution totally piracy proof. Maybe create some system that punish pirates, like the infamous up side down HBC...

 

[OncleJulien]

Your point?

is made for me nearly every time you post.

 

[sven42]

I agree with sven and his worries about piracy, however some developers as djtuei has achieved homebrew apps like Devolution totally piracy proof. Maybe create some system that punish pirates, like the infamous up side down HBC...

So let's assume - just for the sake of this argument - that we would create some kind of piracy proof loader by using black magic and maybe some voodoo. What then?

There's no SDK magically appearing. There's no linux suddenly working. There's no way anyone will be able to write any homebrew app. We'd exactly be where we are right now!

Which brings us back to the original point of this thread: Someone needs to step up and work on porting linux to the vwii with three cores. This is *exactly* the same work that would have to be done if we released a full wiiu exploit. Not a single line of code written for the three core linux on vwii is wasted - the same damn thing can be and will have to be use in wiiu mode.
Unless someone comes up with that, we won't release the wiiu exploit, not even on 30c3.

 

[Ray Lewis]

Off to better places, lol.

 

[papermanzero]

So let's assume - just for the sake of this argument - that we would create some kind of piracy proof loader by using black magic and maybe some voodoo. What then?

There's no SDK magically appearing. There's no linux suddenly working. There's no way anyone will be able to write any homebrew app. We'd exactly be where we are right now!

Which brings us back to the original point of this thread: Someone needs to step up and work on porting linux to the vwii with three cores. This is *exactly* the same work that would have to be done if we released a full wiiu exploit. Not a single line of code written for the three core linux on vwii is wasted - the same damn thing can be and will have to be use in wiiu mode.
Unless someone comes up with that, we won't release the wiiu exploit, not even on 30c3.

Can you please stop being so aggressive? It's just a normal discussion. Thank you.

First of all, you don't need everything at the beginning. You can start a development process which includes hardware access, documentation and tools.
Let's say we have a loader and we will start with some kind of step by step approach.
What is the simplest and easiest way to start?

I would say it's the Wii. We have everything there: we have SDKs, we have documentations about the hardware, we have tools and so on (So we have already a basis).
Let's create an enhanced Wii.
As first step you are only extending the RAM memory of the Wii. Everything else stays like before.
So we have the same CPU instructions (only one core) and the same GPU instructions.
What to do? We have to extend the memory map and adjust the memory instructions?
However this is not such a huge task like creating a full SDK for the whole WiiU (with triple Core instructions and non fixed function GPU instructions).

The next step would be to enhance the CPU clockrate of one core.
Everything else stays like in step 1. Extended RAM, same GPU instructions.

All in all, you would divide the work into small pieces (according to a software/hardware Roadmap).
So you don't have to eat an elephant at once.

The only question is how to create such an environment.
I understood that creating a piracy proof loader in a secure way is complex.
But I am only making a suggestion how to start with an alternative homebrew solution.

Maybe somebody knows a creative and very innovative method of creating a homebrew environment in a secure way.
Like djtuei did with devolution.

 

[sven42]

Can you please stop being so aggressive? It's just a normal discussion. Thank you.

Nope, I'll be as aggressive as I want to be because that seems to be only way to get my point across here. I'm also an asshole.


But here's the deal again, and it's not going to change no matter how much you bitch or whine:
We need people who are capable of writing a homebrew SDK which can then be used to write WiiU homebrew applications. The first challenge (more RAM and higher frequencies aren't challenges - they are one line patches) is to bring up the three cores and get them to work with some library.
Making them work with libogc is insanely hard because you'd have to rewrite the whole scheduler. Then there's also the small problem that libogc is partly ripped off from the SDK.
Making the cores work on Linux is still hard, but a lot easier than making them work with libogc. You later also get your GPU drivers for free.

And here comes the nice thing again: Bringing up the cores in Linux or some other SDK is exactly the same process as bringing them up in full WiiU mode. Again, no work whatsoever is lost. This is the first real step!
We don't need no fancy loaders to do this thing step by step. We already have the vWii for that.

The problem is that we (f0f + some trusted wii homebrewers) so far haven't had the time and/or motivations to start working on that SDK. Without that SDK there will be no WiiU homebrew. So unless someone skilled enough steps up and starts working on that there's no point in releasing a WiiU exploit.

If you're working on this you can also feel free to come to #wiiudev in efnet and ask technical(!) questions - I'll be glad to help if you're stuck somewhere. Just don't expect me to do any heavy lifting.

 

[papermanzero]

Nope, I'll be as aggressive as I want to be because that seems to be only way to get my point across here. I'm also an asshole.

I don't believe that. :-P

But here's the deal again, and it's not going to change no matter how much you bitch or whine:
We need people who are capable of writing a homebrew SDK which can then be used to write WiiU homebrew applications. The first challenge (more RAM and higher frequencies aren't challenges - they are one line patches) is to bring up the three cores and get them to work with some library.
Making them work with libogc is insanely hard because you'd have to rewrite the whole scheduler. Then there's also the small problem that libogc is partly ripped off from the SDK.
Making the cores work on Linux is still hard, but a lot easier than making them work with libogc. You later also get your GPU drivers for free.

And here comes the nice thing again: Bringing up the cores in Linux or some other SDK is exactly the same process as bringing them up in full WiiU mode. Again, no work whatsoever is lost. This is the first real step!
We don't need no fancy loaders to do this thing step by step. We already have the vWii for that.

The problem is that we (f0f + some trusted wii homebrewers) so far haven't had the time and/or motivations to start working on that SDK. Without that SDK there will be no WiiU homebrew. So unless someone skilled enough steps up and starts working on that there's no point in releasing a WiiU exploit.

If you're working on this you can also feel free to come to #wiiudev in efnet and ask technical(!) questions - I'll be glad to help if you're stuck somewhere. Just don't expect me to do any heavy lifting.

I don't want to bitch or whine.
I fully agree with you.
The only thing I would like to bring up are alternative ways to reach the goal.
I am only sharing my experience and ideas from other projects. To be honest, I don't even have a WiiU and that's why I also don't know the system in details.

The challenge to run three cores with a Linux is too much effort as a first step. I agree, someone has to do that. However I think this can be shifted to a later point in time.
That's why I explained, it would be simpler to start with some easy stuff (more RAM, higher frequency of one Core).
You can use libogc and devkit pro to adjust every necessary instruction.
In this case you would rise the attractiveness of the WiiU concerning homebrew. More developers would jump on the system again.

In parallel you clearly have to develop a TriCore System. But also in this case it could be simpler to start with a DualCore Linux and later develop a TriCore Linux based on the experience with the DualCore version. I am only explaining that people cannot reach the top of mount everest in one day. They have to climb up every level over a certain period. Thus you gain experience and you are happy you reached the next level (which keeps the motivation).

If the vWii is capable of providing additional RAM and higher frequencies (As said I don't know the system in details) than you should work on that first. This would establish a healthy homebrew community. Think about it: If nobody can use the potential and technical possibilities of the system over a long period nobody will care about the system in the future as well. But if you provide new features and new possibilities you are rising the interest of the developers (you make them curios).
Either you are waiting for a Tri Core Linux (which will take a lot of time) to finally built a SDK for a community which has no interests anymore.
Or you are starting to adjust the current SDK (based on the Wii) and provide new features over time so that a potential homebrew community can already grow.

If you can modify the vWii as basis for further developments then why not doing that.

Release 1: vWii or similar sandbox with higher CPU Clock Rate / Adjusted libogc + Devkit Pro
Release 2: vWii or similar sandbox with more RAM / Adjusted libogc + Devkit Pro
Release 3: U Pad Integration / Adjusted libogc to use U Pad for Multiscreen apps
Release 4: HD Integration and Booting in 1080p / Adjusted libogc to use HD resolution
Release 5: Dual Core Support

Timeline:
Roadmap
|---------------------------> Release 1 --------------------> Release 2 ---------------------> Release 3 ----------------> Release 4--------->Release5--------->

Development of Homebrew Apps
|Wii Homebrew-----------> U Homebrew 1---------------> U Homebrew 2---------------->U Homebrew 3------------>U Homebrew 4---->U Homebrew 5-->

vWii or similar sandbox with higher CPU Clock Rate
|--------------------------->X

Multicore Development / Dual or Tri Linux
|---------------------------------------------------------------------------------------------------------------------------------------------------->X

It's only an example. If it's not possible or if nobody wants to do that than I am fine.
I just wanted to demonstrate a different approach.

 

[jammybudga777]

completely agree. small steps lead to bigger ones over time. there needs to be a reasonable low starting point for people to have a snoop and play/experiment with. i dont see logic in learning to swim in the deep sea

 

[marcan_troll]

If you think a dual core OS is easier to write than a tri-core OS, you are clearly completely clueless about software and OS development. It doesn't work like that.

Stop making up roadmaps like some clueless pointy-haired boss and start realizing the facts: that there's nobody out there willing to do any of the platform development work, and that it's impossible to build a sandbox to keep piracy away (while people chip at the problem slowly) without Nintendo's cooperation, and that's fundamental, and it doesn't matter how much "security" you throw at it, it is not possible. Devolution is neither piracy-proof nor a comparable example. I'd go into the technical details of why you can't just "add security like devolution" to an exploit, but it doesn't seem you're paying attention to technical facts (some of which sven has already explained), so there's no point. The whole "enabling the system step by step" thing is pure nonsense - you can already pick and choose Wii U features to use, there is absolutely zero reason why that would make it harder to get started, and zero reason to artificially limit features (and no, that wouldn't stop piracy).

 

[jammybudga777]

guess im clueless then ......... anyone wanna buy a wii u from the uk???

 

[papermanzero]

If you think a dual core OS is easier to write than a tri-core OS, you are clearly completely clueless about software and OS development. It doesn't work like that.

Stop making up roadmaps like some clueless pointy-haired boss and start realizing the facts: that there's nobody out there willing to do any of the platform development work, and that it's impossible to build a sandbox to keep piracy away (while people chip at the problem slowly) without Nintendo's cooperation, and that's fundamental, and it doesn't matter how much "security" you throw at it, it is not possible. Devolution is neither piracy-proof nor a comparable example. I'd go into the technical details of why you can't just "add security like devolution" to an exploit, but it doesn't seem you're paying attention to technical facts (some of which sven has already explained), so there's no point. The whole "enabling the system step by step" thing is pure nonsense - you can already pick and choose Wii U features to use, there is absolutely zero reason why that would make it harder to get started, and zero reason to artificially limit features (and no, that wouldn't stop piracy).

Tri Core development is definitely more complex than dual core development.
Especially due to the asymmetry (and the threads you have to take care about). You know that.

I can give you the same advice:
Don't be so arrogant and think you are the master of programming. You are only a poor developer who is frustrated and who lost his interests in console homebrew.
I know programmer who reached more than you.

First, I said it's a different approach and an idea to reach the goal in a different way.
Second, I also explained I don't know the architecture or the system of the WiiU.
Third, It's the principle I explained. How to realize the approach is a completely different discussion.

 

[sven42]

Tri Core development is definitely more complex than dual core development.
Especially due to the asymmetry (and the threads you have to take care about). You know that.

I'm not quite sure what you're smoking - but I want something of that!

 

[jammybudga777]

call me a dummy but........ working around 1 core is difficult but surely the more cores thats added the more work that has to go into it???? or maybe im just thick as fuck

 

[sven42]

call me a dummy but........ working around 1 core is difficult but surely the more cores thats added the more work that has to go into it???? or maybe im just thick as fuck

Writing apps that make use of three threads vs. two threads? (The emphasis being on *threads* here fwiw) Sure, that's a little bit more complex.

Bring up three cores vs. two cores on linux? Nope, same deal.