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

[Pogostick]

Why would you want to? Using a Gamecube emulator on vWii mode wouldn't be wise or feasible. A virtual machine is the way to approach it.

Well Dolphin's a Wii emulator also so the Gamecube part would be incompatible (at least for now).

 

[Matando]

Can anyone test the following? I made some slight modifications to the payload.
Ideally it should boot into linux. Rename vmlinux to ppcboot.elf and put it in the usual place.

https://mega.co.nz/#!RVhBVSLZ!X0Ss81J3rVp6CGf8tLc-vyRBP3Q_bt5fJjdXiqW3Fe0

After launch it displays "waiting for arm to reset" and the fully restarts back to the WiiU menu

 

[bravest]

I later realized there's a bug in that build.

I'll have a new one ready tomorrow afternoon. Make sure to check back

-bravest

 

[bravest]

Can you try the same method but replace the old boot.elf with the following? I enabled debug prints which should give me a better idea of what exactly went wrong.
Thank you so much for the help by the way


-bravest

 

[Matando]

Can you try the same method but replace the old boot.elf with the following? I enabled debug prints which should give me a better idea of what exactly went wrong.
Thank you so much for the help by the way


-bravest

hmmm... it did the same exact thing

it says loading ios 254...
and then waiting for arm to reset.

it then resets the console and the wiiu controller turns back on by itself

 

[Maxternal]

hmmm... it did the same exact thing

it says loading ios 254...
and then waiting for arm to reset.

it then resets the console and the wiiu controller turns back on by itself

try running it with this meta.xml in the same folder
http://www.mediafire.com/download/fw5dbbj7aihw7u8/meta.xml
it will give you a lot more information about what's happening.
the last few lines will probably be the most important especially when it says something returned a number.

 

[Matando]

try running it with this meta.xml in the same folder
http://www.mediafire.com/download/fw5dbbj7aihw7u8/meta.xml
it will give you a lot more information about what's happening.
the last few lines will probably be the most important especially when it says something returned a number.

For some reason the meta.xml is not loading properly. it keeps coming up "No Description available" in HBC. Im currently trying to figure out why... hold on

LOL... you forgot the </long_description> tag

 

[JoostinOnline]

For some reason the meta.xml is not loading properly. it keeps coming up "No Description available" in HBC. Im currently trying to figure out why... hold on

Replace

<arguments>

with

</long_description><arguments>

 

[Matando]

Replace

<arguments>

with

</long_description><arguments>

Thanks "JoostinOnline" I just figured it out, and then saw your post

it says "Invalid Entrypoint 0xc0000000"

*It says "Invlid Entrypoint" because bravest provided a vmlinux file when bravest should have provided the zimage file

 

[bravest]

I was aware of the vmlinux issue, that was the bug I was referring to
I'm going to push out a new build tonight some time that should fix the issue, I'm just glad the arm changes are working properly now.


-bravest

 

[Maxternal]

For some reason the meta.xml is not loading properly. it keeps coming up "No Description available" in HBC. Im currently trying to figure out why... hold on

LOL... you forgot the </long_description> tag

thanks. fixed it now for anyone else who wanted to use the same link

 

[bravest]

New zImage:

http://s000.tinyupload.com/?file_id=51594736704287714516

I can't guarantee that it will work but I'd love to see the output.

-bravest

 

[Matando]

it loads the ppcboot.elf and then then this: http://img543.imageshack.us/img543/7139/otjc.jpg

 

[bravest]

it loads the ppcboot.elf and then then this: http://img543.imageshack.us/img543/7139/otjc.jpg

Very interesting. I'll push another build out tonight sometime.

-bravest

 

[bravest]

http://s000.tinyupload.com/?file_id=19439493609224876844

Here is the new build. It is being built as NTSC (480i-60) by the way.

-bravest

 

[Matando]

http://s000.tinyupload.com/?file_id=19439493609224876844

Here is the new build. It is being built as NTSC (480i-60) by the way.

-bravest

same effect

*I just tried a kernel I compiled and it flashed that screen, but then sucessfully booted into linux.

Could you share your patches, and info on the kernel version you're using?

 

[bravest]

My changes went as far as modifying the wii.dts file to have 3 cpus as well as modifying the wii_defconfig to have SMP=y . Minor changes so far

I am using the gc-linux from this repo : http://git.infradead.org/users/herraa1/gc-linux-2.6.git

-bravest

 

[Matando]

did you want to use a more "updated kernel" -> https://code.google.com/p/gbadev/source/checkout?repo=kernel

also I am looking at the wii.dts file right now... however the latest rev doesn't compile for me. my assembly isn't up to par so I can't figure out why. so just: "git checkout dae374b46237" to get a working rev.

 

[Ninja_Carver]

My changes went as far as modifying the wii.dts file to have 3 cpus as well as modifying the wii_defconfig to have SMP=y . Minor changes so far

I am using the gc-linux from this repo : http://git.infradead.org/users/herraa1/gc-linux-2.6.git

-bravest

Hell yeah dude! now lets 'cat /proc/cpuinfo' and see if your changes actually did anything.

I recall when i was working on the kernel, simply turning CONFIG_SMP=y prevented it from booting (or output to screen).

 

[Maxternal]

My changes went as far as modifying the wii.dts file to have 3 cpus as well as modifying the wii_defconfig to have SMP=y . Minor changes so far

I am using the gc-linux from this repo : http://git.infradead.org/users/herraa1/gc-linux-2.6.git

-bravest

Cool.

and did you make changes to the boot.dol's code so that the other cores would actually reach the linux kernel code? (in the version in the download page now they spin up and then spin in an infinite loop ... not sure what version you're using)

If you want something to compare to, I tried making said change here
https://code.google.com/p/gbadev/source/detail?r=df3ed347047ff57cc79300edf485db37d1858585
and here
https://code.google.com/p/gbadev/source/detail?r=fdf88e5aa9cf2d89d3fd5a1c521e1bea7720bf8f
making those cores be sent to that secondary entry point you pointed out but NOT spin them up until they get to the wrapper...
...and then made the wrapper supposedly spin up BOTH cores here
https://code.google.com/p/gbadev/so...2c9569391d4d583e0b7ec32fad8e7e2c4&repo=kernel
instead of from the boot.dol code.

That new boot.dol is here http://vwii.idfbest.com/upload/boot4smp.dol

...

I tried compiling the kernel and having a tester run it but it just gave a black screen. I supposedly had told the other cores to turn the sensor bar on when they were done with their init (right before being sent to the kernel) BUT that didn't happen.
I also remember that while it was compiling I thought of several things I had forgotten to take care of (and I can't remember all of them ATM ... I'll have to write them down next time it occurs to me).
- first is that this part worries me https://code.google.com/p/gbadev/source/browse/arch/powerpc/kernel/head_32.S?repo=kernel#220
because it looks like 32-bit PPC Linux has only ever had to deal with 2 separate (single core) processors for SMP before so I still need to compare to the other head_XX.S files and see if there's any different way it's handled with more threads OR just invent my own way to handle it. (for now I think I should have just had the wrapper init ONE extra core if I was going to use that code ... but oh well)
- It seems to me the caches would cause problems so that the new cores flag to the first one that they're ready, it'll never see the flag because it's still stuck in the new cores' caches.
- I had skipped over the part where the HID5 value was set
( https://code.google.com/p/gbadev/source/browse/armboot/stubsb1/stub_sb_on.s#105 )
because when set to the same value the Cafe OS uses, single core Linux didn't start (can't be sure about SMP=y, though ) and I'd think it would be best for all the cores to have the same state. Core 0 has just come out of the boot ROM so I kinda think it'd have that set to a different value than the others and checking that is STILL on my to-do list.
- EDIT : I think the other thing that was worrying me goes along with the first one on the list. Both new cores have the same place to acknowledge that they've arrived so if the first core sees a core number at that address I don't know how it can tell whether or not the other core had already arrived or not. I'd assume they'd arrive almost simultaneously in this case but I don't think you can really be 100% certain.