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

[dojafoja]

Ya, looooooooooong time reader, first time poster. I didn't even create my account until I was about to post :-P I don't generally post in forums unless I have something to contribute. Therefore you probably won't see me much but I know a few devs who I believe could get Linux running using what documentation is available. One guy I'm almost positive can do this, just need to spark his interest. I sent him a message right before making this post so I will report back when and if he replies :-P but he's not the only guy I have faith in so I will reach out to the and see if they are interested.

 

[obcd]

Let's just say "welcome" dojafoja.
If you are a long time reader you will probably notice that there is more wasted than usefull space.
If we still would use paper for all those messages, the Amazone forest would be history...
Marcan was kind enough to post his document pictures of the die shot. I really appreciate this gesture.
I couldn't find such detailed pictures on the decapping discussion forum.
Either they weren't there or they were burried in the wasted space.
(There was a link to Marcan's pictures but it didn't work...)
They basically proof my previous assumption was wrong and the 16K bootrom is indeed part of the espresso (small square in the center)
No hard feelings in the name of hacking science. A corrected wrong assumption is better than no assumption at all.

For those wondering why we need to reverse the existing stuff...
For instance, we know (because they told us at 30C3) that the wiiu boot0 code window (a the espresso high mem boot address 0xFFFFF800) is disabled in boot 2 and can be reenabled by swapping the bit again.
We don't know what bit of what register. That information is somewhere hidden in the boot2 code...
As Team f0f already discovered these secrets, it feels a little like reinventing the wheel. As they don't seem to intend to share it at the moment I see no other option.
I don't suppose anyone has some Ghettohci code to share either? (My father always said, if you don't ask, you will never get anything..) The gpio - usbgecko solution might be faster, but I don't think they still make usbgecko's, so that approach only bebefit's the happy few still in posession of such a device.
I wonder if it would be to ambitious to try to use the usb ethernet adapter with a minimal ip stack to create a high speed wiiu debugging port.
There are linux drivers for it's asix chipset and there exist some open source ipstack code. It would benefit from high speed and easy availability at the same time.
It also could be used without the need to open the console...

 

[bravest]

I believe the instruction to disable the boot0 mapping is

mtspr scr, r3

-bravest

 

[nitr8]

I believe the instruction to disable the boot0 mapping is

mtspr scr, r3

-bravest

I don't know why but I believe having seen this line of code on one of f0f's slides... :eek:

 

[obcd]

Wasn't that the first instruction executed just before it started to run the decrypted ancast image?
That instruction basically moves the contents of r3 to the special purpose register scr.
r3 is 32 bit, so this still gives us 4294967296 possible combinations.
The help is nevertheless appreciated.

 

[bravest]

I believe scr is a write once register that is reset to default after h_reset. Precisely which flag was set is irrelevant because it cannot be disabled by a simple write, which is why f0f used reset fuzzing.

-bravest

 

[obcd]

They said the bit could be toggled to enable boot0 mapping again.
You could be right about scr being write once, but in that case it's not the one that disables boot0.

 

[Maxternal]

That particular bit of that SPR that disables the PPC boot ROM is not able to be undone but the Cafe OS writes to the other bits of it a few times during init as it's what is used to spin up the other cores. All of this, of course, happens after the boot ROM has finished and been disabled so it's definitely not completely write-once.
http://fail0verflow.com/blog/2013/espresso.html
as for boot0 (the ARM boot ROM) you can get instructions for that on wiibrew.
http://wiibrew.org/wiki/Hardware/Hollywood_Registers#HW_BOOT0

 

[Coto]

I believe the instruction to disable the boot0 mapping is

mtspr scr, r3

-bravest

mtspr scr,r3;
bits 0-5 store 31 dec
11-20 (& r3 results in SPR[index])
21-30 store 467 dec

works on special registers (SPRs)
mtspr scr, r3; //requires a proper format (above)

so basically you copy r3 contents on scr(another reg), plus affect SPR indirectly

more human: r3 is a local var given a branch (LR) is used, a copy of such data
is stored on scr(special content register?), plus bits 11-20 of R3 affect SPR indirectly.
(SPR[0] is Link Register, so data is copied to LR too..!)

 

[Maxternal]

If anyone's curious about what information is actually in r3 when it's written to SCR as well as the state of several other SPR's shortly after the other cores are spun up, run this on your Wii U http://vwii.idfbest.com/upload/SPR dump.dol with this meta.xml http://www.mediafire.com/download/fw5dbbj7aihw7u8/meta.xml and post the file sd:/trnx-log.txt when it's done.

EDIT : made a little edit in the meta.xml for any of you who don't have bootmii IOS installed.

 

[obcd]

Ok, rechecked the presentation. The register that maps the arm boot 0 at 0xFFFF0000 (and not 0xFFFF800) is the same as the Wii register.
The mtspr scr,R3 is what disables the espresso bootrom just before the decoded ancast binary is executed.

 

[marcan_troll]

I take it all of that unmarked space on Latte is theoretically GPU?

Mostly. There's also all the random peripherals (digital part of USB, SD, DSP, etc.) but I think the majority of that is all merged together in the oddly-shaped block below MEM1 (surrounding the analog and memory blocks that are marked there). The GX is probably the stuff surrounding eFB/eTC, and the whole right half would be the r7xx (including the memory controller and video output portions). Annotating digital logic blocks is mostly random guesswork anyway so I didn't bother taking guesses.

BTW, I tweeted those dieshot annotations quite some time ago.

that particular bit that disables the PPC boot ROM is not able to be undone but the Cafe OS writes to it a few times durring init as it's what is used to spin up the other cores. all of this, of course, happens after the boot ROM has finished and been disabled
http://fail0verflow.com/blog/2013/espresso.html
as for boot0 (the ARM boot ROM) you can get instructions for that on wiibrew.
http://wiibrew.org/wiki/Hardware/Hollywood_Registers#HW_BOOT0

Thank you for being the only voice of sanity around here. Seriously, reading this thread is a facepalm fest between your posts.

 

[Pogostick]

By the way I just spreaded the word about to Kuribo64.net.

 

[nitr8]

If anyone's curious about what information is actually in r3 when it's written to SCR as well as the state of several other SPR's shortly after the other cores are spun up, run this on your Wii U http://vwii.idfbest.com/upload/SPR dump.dol with this meta.xml http://www.mediafire.com/download/fw5dbbj7aihw7u8/meta.xml and post the file sd:/trnx-log.txt when it's done.

EDIT : made a little edit in the meta.xml for any of you who don't have bootmii IOS installed.

How long does it take until the "Waiting for ARM to reset PPC" message disappears? After running that DOL with the given META.XML i only hear the drive something like "self-testing" - the same way like when booting a normal Wii.

It's almost sitting there for more than 10 minutes...

 

[jodf]

Just to let you guys know, i got an usb gecko (working fine) and don't need it anymore. So if i could help sending it to someone (obcd, maxternal or someone else) just pm me or write here

 

[bravest]

I'll try running it as soon as I can get my hands on an sd reader

-bravest

 

[Maxternal]

How long does it take until the "Waiting for ARM to reset PPC" message disappears? After running that DOL with the given META.XML i only hear the drive something like "self-testing" - the same way like when booting a normal Wii.

It's almost sitting there for more than 10 minutes...

Thanks for testing. That was untested when I posted it. Unfortunately, looks like I didn't QUITE do it right. I'll have to make some adjustments and recompile when I get a chance here.

 

[Coto]

Thanks for testing. That was untested when I posted it. Unfortunately, looks like I didn't QUITE do it right. I'll have to make some adjustments and recompile when I get a chance here.

I trust you'll do it fine. Unlike "god" coders that are a bit sad to read.

 

[Maxternal]

Just to let you guys know, i got an usb gecko (working fine) and don't need it anymore. So if i could help sending it to someone (obcd, maxternal or someone else) just pm me or write here

Tempting offer.
I have to admit, though, I have practically NO soldering experience (used one once with little success.) and while I'm sure I could find some good use for a USB gecko on a normal Wii, I have my doubts that it would help this particular project out much in my hands (I'd probably destroy a $400+ investment in console hardware if I were to attempt to do any soldering myself).

 

[Quincy]

Tempting offer.
I have to admit, though, I have practically NO soldering experience (used one once with little success.) and while I'm sure I could find some good use for a USB gecko on a normal Wii, I have my doubts that it would help this particular project out much in my hands (I'd probably destroy a $400+ investment in console hardware if I were to attempt to do any soldering myself).

It's a shame that you live in Costa Rica, else I could've soldered it in. There must be some hardware shops that offer services like this. Maybe someone in your friend circle knows someone or a shop etc?

Oh by the way, I'm glad to see the way this is headed, great work guys!