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

[naxil]

http://www.gc-linux.org/wiki/Download#Kernel_Images_for_the_Nintendo_Wii

Maxternal i have found this page... the best complete distro for wii? with wifi internet support ecc? web broswer, irc client? exist?

 

[the_randomizer]

"To reboot or something of the WiiU, Unix-ish stuff was coming u" -- Twitter Translate

I like my translation better He pretty much found a way to boot Unix or a Unix type OS, how, that isn't explained.

 

[papermanzero]

PMZ, most of us are clearly not qualified to understand your point of view here, so, a suggestion:
take as long as you need to create a working example of the concepts youve laid out in this thread, we'll wait...even if it takes years.

I didn't want to disturb the thread anymore.
But a short answer: No, I don't want to contribute in these projects or show anything because I don't have the time for that.
I also don't have to prove anything. Let's leave it at that.

Now back to topic.
I wish everyone a successful project.
Cheers

 

[obcd]

In terms of hardware graphics acceleration, is it not possible to simply use one of the Open-ATI drivers for Linux?

We are still in vwii mode. In that mode, we have no access to the wiiu gpu. The linux uses a framebuffer setup for it's graphics output.

 

[sven42]

What it NOW appears to be is that Fail0verflow wasn't actually planning to do that last bit of vWii->Wii U conversion themselves. What they wanted (once no more progress could be made in vWii mode) was to have a developer that (1) they trusted not to just use the exploit for piracy themselves and (2) was already skilled enough (and had enough free time and interest) to make that conversion vWii->Wii U Linux conversion themselves in a relatively short time, STILL without having to release the exploit to the general public until the Linux port was ready to accompany it.

Pretty much - we're all too lazy to work on WiiU Linux so we're trying to outsource that work

I think our relationship with GBATemp makes us fail #1 for them and #2 we don't really yet qualify for either SO while what we're doing isn't wasted by any means (and I do still intend to continue.) They will want someone with more skillz/better reputation to step in eventually and finish the job.

Yup, but at least you seem to be one of the few people in here who are actually trying to do some work instead of sitting on their ass and complaining that we don't release some warez loader for them. Oh, sorry. Backup loader. No one of you obviously pirates any games, and we won't be able to see through that bullshit when you call them backups, right? right?

Seriously though, I really appreciate your efforts. And again, if you do have technical questions: #wiiudev at efnet. I'll be glad to help if you're stuck at some specific part!

Anyone know Japanese? https://twitter.com/mernao/statuses/292814477164937216

Don't get your hopes up, that looks like a kiosk wiiu with an internal linux build. I doubt that guy wrote his own kernel patches.
It really doesn't surprise me that Nintendo uses linux internally.

 

[rednekcowboy]

Pretty much - we're all too lazy to work on WiiU Linux so we're trying to outsource that work


Yup, but at least you seem to be one of the few people in here who are actually trying to do some work instead of sitting on their ass and complaining that we don't release some warez loader for them. Oh, sorry. Backup loader. No one of you obviously pirates any games, and we won't be able to see through that bullshit when you call them backups, right? right?

Seriously though, I really appreciate your efforts. And again, if you do have technical questions: #wiiudev at efnet. I'll be glad to help if you're stuck at some specific part!




Don't get your hopes up, that looks like a kiosk wiiu with an internal linux build. I doubt that guy wrote his own kernel patches.
It really doesn't surprise me that Nintendo uses linux internally.

I saw a few Japanese forums doing a quick search yesterday that were talking about loading Unix from the Wii U, somehow booting it before the Wii U OS, but they were all mostly from Jan of last year and then nothing, so likely you are correct. I'm sure if someone actually accomplished this, it would have been all over the place like wildfire.

Like I said, I don't know near enough to help out on creating the initial environment, but if I actually had an environment to work in, I might be able to pitch in at some point. Not everyone wants a backup launcher but I won't insult your intelligence by claiming that's not what the majority here want. Myself, every console I've had has been hacked from the moment the hack was available. I like being able to play with the internals and playing around with the homebrew that other talented people develop (after all that is a good way to learn how shit works).

Thanks again for offering Max your expertise.

 

[JoostinOnline]

sven42 I hope you won't judge us all by those who demand warez or people like papermanzero who insist they know more than you about everything. While I've expressed my doubts on the "test", I do understand the reasons behind it.

While I don't have the skills to develop a framework, I have tried to pitch in what small ways I can, mainly code optimization. It's not much, but I figure it's better than nothing.

 

[sven42]

Nah, no worries. I know how the dumbest people are usually the loudest

But anyway, this isn't a test per se - we really need someone to come up with a homebrew SDK. We think Linux is the best bet for that (aka the least effort to get a really nice framework running). please don't make the mistake to confuse linux with ubuntu or whatever you have running on your desktop though. i'm really only talking about the kernel itself and a really, really simple userland.
If anyone comes up with something else - sure, go ahead. fine with me as well as long as it works.
But we do need a SDK to get homebrew bootstrapped - because once that has happened people like redneckcowboy and you can start to poke around the hardware and hopefully create some fun homebrew apps.

 

[delroth]

And we need a SDK that's not half-illegal like libogc. To this date I'm still surprised Nintendo haven't sued the people who asm2c'd code from the official Nintendo libraries and called it libogc. It makes a really bad precedent and people assume it's "ok" to do such things.

 

[JoostinOnline]

And we need a SDK that's not half-illegal like libogc. To this date I'm still surprised Nintendo haven't sued the people who asm2c'd code from the official Nintendo libraries and called it libogc. It makes a really bad precedent and people assume it's "ok" to do such things.

Because Nintendo is cool like that. They understand.

 

[obcd]

M$ obviously didn't understand with the first xbox. Everything created with the official xdk could not be distributed.
The sources could be distributed without problems, but not the final programs.

 

[papermanzero]

sven42 I hope you won't judge us all by those who demand warez or people like papermanzero who insist they know more than you about everything. While I've expressed my doubts on the "test", I do understand the reasons behind it.

While I don't have the skills to develop a framework, I have tried to pitch in what small ways I can, mainly code optimization. It's not much, but I figure it's better than nothing.

Why are you going offtopic again? If you don't accept my opinion it's ok. But don't bash like that.
I have never said I know everything, I just don't agree with svens views. If you cannot accept that it's your problem, but don't act like that.
In general a user should be so tolerant to accept a different opinion
So thanks to JoostinOnline for his efforts of destroying this thread.

I hope that we can stay ontopic from now on, without blaming, bashing, flaming or something else.
Thanks.

 

[obcd]

In a short summary, this is what Sven is telling:

We think Linux is the best bet for that (aka the least effort to get a really nice framework running)

Anyone who thinks he has a better (easier) option, and who can state that with some solid technical background, we are all ear.

I have no knowledge of PS3 and xbox360 homebrew sdk's.
I do know that they used the official sdk for most xbox homebrew.
Some parts of the wii libogc also came from reversing and studying the official sdk.
It basically means I have no knowledge of a console homebrew framework designed from NULL that became mature enough to be used for the creation of homebrew games and emulators.

I don't see why the situation would be different for wiiu. Creating a working 3 core linux is hard, but creating a framework not based upon linux is
even harder. It could have faster startup times, but a carefully tweaked linux isn't that bad either.
If another framework would appear, it could take advantage of the drivers that are used in linux as well.

Extending libogc to run different Threads on different cores is an option we (Specially Maxternal) are examining.
It means we'll have to reprogram parts of every homebrew to have it take advantage of the other 2 cpu cores.
It also means we will never be able to use the power of the wiiu gpu.

Unless someone can prove that it's possible to reenable wiiu features from within the vwii sandbox, in my opinion it's a dead end.

Linux pretty much runs on the hardware independant of the original (cafe) Os. That's what makes it's code reusable for wiiu once we
have an exploit.

 

[sven42]

Some parts of the wii libogc also came from reversing and studying the official sdk.

They came from opening up the SDK in a disassembler and converting it to C without understanding what's going on
Just look for the fun _SHIFTL/_SHIFTR macro. that's really just a fancy way to express a compiler optimized mask (usually a rlwinm instruction in the SDK corresponds to one of those macros when a simple & would've been enough...)

Extending libogc to run different Threads on different cores is an option we (Specially Maxternal) are examining.
It means we'll have to reprogram parts of every homebrew to have it take advantage of the other 2 cpu cores.
It also means we will never be able to use the power of the wiiu gpu.

Pretty much. Basing this on libogc (seriously bad idea imho, even when you ignore the legal troubles associated) you have two possibilities:
1) Rewriting the whole threading framework from scratch. The current schedular is already interesting to look at and works essentially by pure chance. If you're going this way you might as well go for Linux because this is insanely harder.

2) Adding special functions like vwii_core_start(COREID, ptr), etc. This could help people who really just want to use the other two cores for number crunching and handle all the coherency fun themselves. The first apps that would benefit from this approach coming to my mind are emulators like Wii64. This is not a lot of work fwiw, and obviously doesn't qualify for "We're gonna give you the WiiU exploit if you do this"

Unless someone can prove that it's possible to reenable wiiu features from within the vwii sandbox, in my opinion it's a dead end.

I'm pretty sure it isn't. I managed to get the additional MEM1 at the cost of losing access to most other hardware
We know a lot about how the vwii sandbox is implemented since Nintendo was nice enough to leave cafe2wii.elf with full debugging symbols on the NAND. To enable any of the additional hardware you have to be able to write to a certain register. However, that register is completely disabled by the time you reach vWii mode and only becomes writable after a full reset again.

Linux pretty much runs on the hardware independant of the original (cafe) Os. That's what makes it's code reusable for wiiu once we
have an exploit.

yes!

 

[JoostinOnline]

Why are you going offtopic again? If you don't accept my opinion it's ok. But don't bash like that.
I have never said I know everything, I just don't agree with svens views. If you cannot accept that it's your problem, but don't act like that.
In general a user should be so tolerant to accept a different opinion
So thanks to JoostinOnline for his efforts of destroying this thread.

I hope that we can stay ontopic from now on, without blaming, bashing, flaming or something else.
Thanks.

From the PM you sent me:

Short question: Do you want to destroy the thread "Tri Core Linux for WiiU"?
If not, why do you provoke people? Are you some kind of judge who decides what's wrong?

Hmm, you seem to have confused me with yourself. Most of your posts have been dedicated to telling f0f members that they are wrong and derailing the thread.

 

[papermanzero]

Hmm, you seem to have confused me with yourself. Most of your posts have been dedicated to telling f0f members that they are wrong and derailing the thread.

And why are you going back to this discussion if a) you were not involved and b) we already closed the discussion due to offtopic?
Bashing or flaming against users is never useful (you just added fuel to the fire).
I hope we can finally close the discussion and focus on the topic.

To get back to topic:

The Xbox360 homebrew is clearly different:
You can use XNA to create homebrew (which is available for everyone) .
Furthermore you can use the customized Linux (Xell).
Xell boots as second stage boot loader and has (as far as I know) no legal issues (in comparison to libogc or XNA/X360 devkit development).
Also a dedicated GPU driver was created to use the GPU for homebrew apps.
Maybe you can use some aspects of Xell and the Free60 project.

 

[the_randomizer]

Can parts of the Xbox 360 SDK be ported or used in any way for the Wii U homebrew or used as a reference in anyway?

 

[papermanzero]

Can parts of the Xbox 360 SDK be ported or used in any way for the Wii U homebrew or used as a reference in anyway?

Depends on which SDK you mean.

The Xell based approach: Yes, maybe. However you have to think about the architecture of the WiiU.
You have e.g. to create new GPU drivers.
It's a fully customized Linux adjusted for the 360 architecture.

The XNA /360 approach: No. This is MS own solution to create applications and games.
A leaked devkit was used to get access to this approach.

 

[Maxternal]

2) Adding special functions like vwii_core_start(COREID, ptr), etc. This could help people who really just want to use the other two cores for number crunching and handle all the coherency fun themselves. The first apps that would benefit from this approach coming to my mind are emulators like Wii64. This is not a lot of work fwiw, and obviously doesn't qualify for "We're gonna give you the WiiU exploit if you do this"

I was actually working on this approach a little as well hoping to make a small library or just a group of header files for others to be able to use until Linux was finished. (Thus comments about IOS patching/loading on #wiiudev) Which I would also hope would help me to get a simpler environment to experiment with how the cores behave together when a problem arises in Linux development (there's probably a better way but that's what I keep telling myself, anyhow.)

We know a lot about how the vwii sandbox is implemented since Nintendo was nice enough to leave cafe2wii.elf with full debugging symbols on the NAND. To enable any of the additional hardware you have to be able to write to a certain register. However, that register is completely disabled by the time you reach vWii mode and only becomes writable after a full reset again.

I assume you meant RAM here? Just in case it's not a typo, where would I look on NAND to find this?

The Xbox360 homebrew is clearly different:
Furthermore you can use the customized Linux (Xell).
Xell boots as second stage boot loader and has (as far as I know) no legal issues (in comparison to libogc or XNA/X360 devkit development).
Maybe you can use some aspects of Xell and the Free60 project.

I was actually looking at 360 Linux a bit to get an idea of what to expect. Of course it's not quite a copy/paste solution since you can't trust the interrupt controller (also involved in multi-core stuff) to behave the same on both processors and there are other fundamental differences between 64-bit(360) and 32-bit(WiiU) PPC processors as well as the fact that WiiU has one thread per core and and the 360 has 2 per core.
It's not a bad starting point, though.

 

[JoostinOnline]

I assume you meant RAM here? Just in case it's not a typo, where would I look on NAND to find this?

I don't see how they could leave a file on volatile memory.

Edit: But I think that he means on the Wii U side, because I just dumped all the strings and I can't find anything that resembles that.