crowell / gbadev Goto Github PK

take the stub we have that's already similar to the beginning of 1-512, make 
the same changes to it that our patches make to 1-512, and then just jump to it 
directly, patching the jump over the beginning of 1-512

This way if 1-512 is ever updated by Nintendo, we're not dependent on any of 
it's code.

What steps will reproduce the problem?
set the debug=1 argument in the meta.xml and run it from HBC

What is the expected output? What do you see instead?
You'd expect it to show a lot of debug into and then enter Linux but nothing is 
seen when it's supposed to enter Linux.

See if it still runs normally after just patching a nop over the register pokes 
at the beginning of 1-512

Hopefully that would make us able to just init the other cores at any time.

I got a wii u at home and i heard it can't read dvd on the new wii u disc 
drive. I was thinking can it read dvd on external dvd by connect on usb port on 
wii u

since I'm told you can't actually access the necessary registers from ES in 
order to do the race attack (I'm assuming this refers to the ones to reset PPC 
since that's the only ones we really need to use) I was wondering what would 
happen if we tried to use the syscall 0x59 (load_PPC) instead ... or even 0x41 
( ppc_boot(const char *path) ) and see if it can help us achieve the same 
thing. It would have to be asynchronous and give us enough time. We might also 
have to have it reload the whole DOL from the entry point again ... but 
something to play around with

The idea would be to make something useful for the "number crunching" concept 
from a LiboGC app as mentioned by Marcan since for that, the IOS would still 
have to be intact. We would possibly also have to put back the code we had 
patched once we're done with the race attack. That could be done either from 
within the IOS itself or by PPC once it's started up again. PPC might be 
simpler but ARM would be safer.

Hello,

I currently have a pre-2008 Wii now, so that means the awesome boot2 hack is 
working and proper. I'm still "thinking" about buying a Wii U... Most likely I 
will, even just for PPC GNU/Linux development, homebrew and "kicks". When The 
Wii U consoles and gamepads get cheaper (or I can always use Craigslist) I may 
buy one, and I may even help with testing and debugging...

I'm running an installed Debian Jessie GNU userland with DeltaResero's GC-Linux 
kernel 3.10 "MIKEp7". I'm using specifically this kernel because that's the 
closest version that usually ships with Jessie.

It works absolutely fantastically with zram, zcache and swap enabled, and also 
with adjusted swappiness. I'm using cwiid and wminput instead of XWiimote, 
because I can't get it to work right with DBus complexities, or whatnot... 
Don't get me started with trying to get systemd or other things running in 
Debian on there, it's a PITA.

tl;dr:
Would it be possible to use DeltaResero's latest versions of his Linux kernel 
with Trinux, at least by default? Because it would be much more easier to use 
that and enable multi-core support, have every module for vWii patched and 
working, and improve the overall experience of GNU/Linux on the Wii U. Because, 
let me tell you something, Linux on the original Wii is slow as balls anyway, 
and I'm itching for a good upgrade to get the most out of this fantastic, new 
gaming console. Besides, 1080p is much, much needed nowadays....

And, maybe, if you don't like this idea of having a ppcboot.elf, why not remove 
it make patches or something that will patch or configure the kernel for 
multi-core support?

Link to his GitHub page:
https://github.com/DeltaResero

Have a chat with him sometime, too, if it'll help this project. :)

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

hunt down the source of the code dump from the boot10.dol.

It would be good both to have a different ppcboot.elf location like always 
being in the folder with boot.dol OR having it setable by an argument and then 
passed to the ARM code to make the code useful in more varied situations.

What steps will reproduce the problem?
1. ./build all

What do you see instead?
arm-eabi-none-gcc: Command not found


Please provide any additional information below.

Solution:
1. change line 10 in "armboot/starlet.mk" to "$(DEVKITARM)/bin/arm-none-eabi-"
2. run "./build clean"
3. run "./build all"

right now we can only run a ppcboot.elf that does NOT use any of the same 
memory area that 1-512 does. (Linux does not overlap ... BootMii does)

This is because when the bootROM gets done with the 1-512's memory area, it 
executes our patched code immediately and there's no time AFTER that to load a 
ppcboot file SO we've had to load if BEFORE the race attack.

We need to figure out a simple way of having PPC wait for ARM to flag it that 
the ppcboot.elf file is loaded so it can proceed to jump to it's entry point.

I can only assume this is because the IOS isn't shut down properly and leaving 
unsolved issues with Bluetooth (not turning it off or something of that nature) 
that would usually taken care of automatically when reloading the IOS the 
normal way.

[deleted issue]

just to be safe, have it check if it's on a Wii U or not
"register is 0xd8005A0
0xCAFE0050 is the value on WiiU"

For some reason, the FS Toolbox Wii U mod (that we based the NAND reading code 
off of) ALSO crashes when trying to directly dump
/title/00000001/00000200/content/0000003.app
BUT
when you tell it to dump the whole NAND, that file still ends up in there and 
is completely intact.

Ideas to get around this:
The only differences I can see in when it dumps the whole NAND is that
1. It reads the containing folders out first.
2. Now that I think of it, it also might have dumped the ticket folder by the 
time it gets around to dumping the actual title (just a last minute hunch, 
though)

We could try mimicking that behavior and see if it changes anything.

probably just a case of making armboot.c in nswitch dependant on a armboot.bin 
and making that dependant on all it's .c, .s and .h files in the nswitch 
Makefile

the build script can still be useful for showing the hashes of the files and 
copying the boot.dol to the upload folder (since it'll now be all we really 
need)

this may also involve moving the armboot folder into the nSwitch folder (it 
might be nice to add the armboot and other new files to the Programmer's 
Notepad project file while we're at it.)