Hacking USB Loader GX

[GreyWolf]

If you're using IOS58 with AHB_PROT disabled you don't need to patch anything. magic_patcher and RuntimeIOSPatcher can be removed (or just skipped with if statements.) I'm pretty sure magic_patcher is useless nowadays anyway. I think it does the same thing as the AHB_PROT permissions that the HBC, forwarder channel, and d2x cIOSes have.

 

[TheRiceKing]

If you're using IOS58 with AHB_PROT disabled you don't need to patch anything. magic_patcher and RuntimeIOSPatcher can be removed (or just skipped with if statements.) I'm pretty sure magic_patcher is useless nowadays anyway. I think it does the same thing as the AHB_PROT permissions that the HBC, forwarder channel, and d2x cIOSes have.

Forgive my ignorance but the only thing I do to softmod my Wii is the recommended configuration: 249 base 56, 250 base 57 using d2x cIOS release d2x-v10-beta53-alt and everything just works. I don't know what you are talking about IOS58. Am I still missing something? I never had issues with previous versions of USBLoader but now with the new version do I need to fiddle with IOS58? (I'm having a busy night and haven't had a chance to test the new release yet) Please clarify. Thank you

 

[GreyWolf]

Forgive my ignorance but the only thing I do to softmod my Wii is the recommended configuration: 249 base 56, 250 base 57 using d2x cIOS and evrything just works. I don't know what you are talking about IOS58. Am I still missing something? I never had issues with previous USBLoader but now with the new version do I need to fiddle with IOS58? (I'm having a busy night and haven't tested the new release yet) Please clarify. Thank you

Oh, no, that was for Cyan. The 1269 mod he mentioned is a test one so don't use it if you're working ok now.

 

[TheRiceKing]

Oh, no, that was for Cyan. The 1269 mod he mentioned is a test one so don't use it if you're working ok now.

Oh OK. Sounds like there's another release coming soon Thanks

 

[JacobM]

To all users having issues with their drive detection :
I changed the boot process, it's now using IOS58 by default (or more precisely, using the current IOS if AHBPROT is disabled, else use the argument in meta.xml).
Could someone test and report any issue ?
specially users with Wii 2 drives (because I didn't test), or a WiiU and a vWii (because I don't have a WiiU HDD).

1269 mod01
* changed boot process to use AHB if available
* Bonus (untested yet) : It should skip USB and cIOS reloading if using WiiU WiiVC! it's supposed to fix the channel mode. maybe not. I'm not sure the fw.img can be patched the same way vWii IOS are patched. I'll make a mod 02 later. I'll do wiiu vc inject tests later.

maybe I messed up, and nothing works. but I could boot and it works with my drive on Wii.
it might even boot faster as it skip one IOS reload.

Great work, you are pumping these out crazy fast!! My test environment is a WiiU on 5.5.1 with a WiiU USB drive and a vWii USB Drive (Ustealthed) with a clean install of USB Loader GX.

1269 mod01 is reported as "1268 mod" on boot.

Both vWii + WiiUWiiVC:
1. You fixed the Gamecube Settings freeze!! Thanks Cyan! (@Rockhoundhigh)
2. WiiU Pro Controller works perfectly in vWii and WiiUWiiVC


WiiUWiiVC Only:
1. WiiU WiiVC bootup is lightening fast! Wow!
2. The USB countdown is skipped. After booting, the system automatically unticks USB and and USB remains unticked on subsequent boots via vWii (is this expected?)
3. AHB is still not available (Expected). Although USB Loader GX's about screen reports AHB. Is that a hardcoded value by any chance? I've noticed this discrepency since 1262.
4. Same crashes as before with WiiU WiiVC mode + HID, no additional regressions!
5. What do you mean by channel mode? Is that referring to the grid layout inspired by the native Wii interface? If so, that still is broken (along with the banner bars and AHB).

 

[GreyWolf]

Great work, you are pumping these out crazy fast!! My test environment is a WiiU on 5.5.1 with a WiiU USB drive and a vWii USB Drive (Ustealthed) with a clean install of USB Loader GX.

1269 mod01 is reported as "1268 mod" on boot.

Both vWii + WiiUWiiVC:
1. You fixed the Gamecube Settings freeze!! Thanks Cyan! (@Rockhoundhigh)
2. WiiU Pro Controller works perfectly in vWii and WiiUWiiVC


WiiUWiiVC Only:
1. WiiU WiiVC bootup is lightening fast! Wow!
2. The USB countdown is skipped. After booting, the system automatically unticks USB and and USB remains unticked on subsequent boots via vWii (is this expected?)
3. AHB is still not available (Expected). Although USB Loader GX's about screen reports AHB. Is that a hardcoded value by any chance? I've noticed this discrepency since 1262.
4. Same crashes as before with WiiU WiiVC mode + HID, no additional regressions!
5. What do you mean by channel mode? Is that referring to the grid layout inspired by the native Wii interface? If so, that still is broken (along with the banner bars and AHB).

The AHB display is taken directly from the hardware register so if it doesn't say AHB_PROT is enabled when you boot the loader it should be properly disabled.

It sounds like whatever you're using to launch it from the WiiVC mode isn't granting AHB access. That's why the grid layout and banner display aren't working right. those assets are loaded from the system menu resources and it can't access them without AHB_PROT being turned off. The official forwarder and the HBC turn it on when loading the dol and d2x cIOS has it on by default.

 

[Cyan]

thank you for the tests.

actually the AHB is read from the hardware register, and is correct.
the problem is that, thanks to AHB, we can patch the IOS to get NAND access (to get the theme resources for the banner layout)
The issue is that the loader is currently not patching the IOS.

it patches the IOS if it's IOS58, or Hermes.
d2x already has NAND access, so there's no patch needed.
as a result, the loader didn't expect to patch anything else, and IOS255 is considered d2x, so no patch is applied.

I'll have to test and see if IOS255 can be patched the exact same way than all other IOSes, or if it's too much different (maybe it's written specifically for WiiVC, and there's no NAND/ES module to be patched)
without a test, I won't know.
if it works, that's good. if it doesn't I guess there will be no way to fix it as we can't reload to another cIOS.

 

[GreyWolf]

You shouldn't need to patch the IOS for NAND access with AHB_PROT off. The HBC/forwarder AHB flag actually gives AHB access, MEM2 access and NAND access all in one.

 

[Cyan]

MEM2 prot disabled allows edition of the IOS. I think it's needed to patch the ES and ISFS access.
That's why the wiiU fw.img can't access the resources, the ISFS is not patched.

I didn't test yet, I wasn't home this weekend, I'll do some test in coming days.
Before leaving home, I tried adding wiiu gamepad support, I don't know if I did things correctly. I probably messed up, or added only buttons but not the joysticks support.
seeing all that was needed to add WUPC lib, I'm not sure if I can tweak/trick the gamepad as if it was the gamecube controller's data or if I need to re-add all I removed.

 

[GreyWolf]

ES and ISFS work with just AHB_PROT off, too. I don't have Streamline patching anything at all and the system menu resources work just fine with just IOS 58.

I'm not sure about the WUPC controller myself as I don't have one but the diagonals should work. Maybe something in WiiPointer.cpp isn't right perhaps?

 

[Cyan]

really? what's the purpose of runtimeIOSPatch if it weren't needed from the start?
it was used only to patch system file install? that lib includes ES / ISFS patches too.

that's strange the ES/ISFS patches were needed for IOS58 and Hermes 4. that's even what make the boot process longer (patching IOS58 takes few seconds).
if we don't do it, system menu resources are not working.
Maybe we are doing things wrong? why is it not working?

I wonder if fw.img (IOS255) even has vWii NAND access at all. I suppose it does to read/save the savegame. I don't think the savegame is stored on wiiu, is it?


Yeah, I didn't test yet, I just suppose I'll have to do something to wiipointer.cpp like WUPC did.
or maybe the pointer is managed directly by libwiidrc, I didn't analyze it yet. the best is to try and see.

 

[GreyWolf]

I think maybe it has something to do with the WiiVC environment. Maybe it doesn't have the system menu resources? I don't have a Wii U so I don't have any way to experiment with it. :/

 

[JacobM]

I wonder if fw.img (IOS255) even has vWii NAND access at all. I suppose it does to read/save the savegame. I don't think the savegame is stored on wiiu, is it?

Save read/write is from vWii NAND. It is also possible to load channels/games stored on vWii NAND (https://github.com/FIX94/wiivc_chan_booter).

At some point I tried creating a WiiVC forwarder that would direct to the UNEO forwarder installed on my vWii NAND. From what I recall, it still did not allow system menu resources to load. I also think it was slightly less reliable to boot (it would get stuck loading the background image of USB Loader GX). I currently boot from an embedded forwarder (no noticeable change if it's loaded from WiiU NAND or WiiU USB). Hope that clarifies something!

 

[Some Chump]

Question to Badablek re Tabmod.

When switching to the WiiWare tab it defaults to emunand only selected, even if I previously selected real and emu nands. Is there a way to make the emunand and real nand selections stay permanently selected?

Love the mod, exactly what I've been looking for.

 

[Magnus87]

Wrong Thread. Sorry

 

[Badablek]

Question to Badablek re Tabmod.

When switching to the WiiWare tab it defaults to emunand only selected, even if I previously selected real and emu nands. Is there a way to make the emunand and real nand selections stay permanently selected?

Love the mod, exactly what I've been looking for.

@Some Chump : it was designed this way by the original author of the tabmod (probably because USBLGX clearly distinguishes emuNAND and real channels). I don't think we can mix both without making a lot of changes in the sources (like adding a new category with both channels).


@Cyan : Homebrew Channel acts really strange when launched from USBLGX (from its "real" channel, not by using the option to go to HBC). It shows indefinitely the disclaimer (like the one in hackmii installer) instead of loading the channel. Is it a normal behavior ? I didn't tried this before (because it's useless), but I'm curious

BTW new revision of USBLGX is really painful to compile. Did you only updated libogc ?

 

[Cyan]

hello,

for 1265+, you need to update both devkitPPC to r29-1 and libogc/portlib
I made a package with the updated libraries on sourceforge, but it contains libogc 1.8.16
you will have to update to 1.8.17 to get the WiiUPro controller's proper calibration from libogc. (I didn't upload a package with that version yet, just get it from devkitpro sourceforge repository and replace the files in libogc existing folder)
I removed libWUPC library as libogc now supports WiiU Pro controller natively.


The problem with launching channels from real NAND with USBGX is that it always reloads to cIOS first (expecting to be a game).
I tried to make the loader load the officially requested IOS, but I failed. The loader crashes before exiting if I reload to any IOS (lost of hardware access, like NAND, SD, USB, to save config, load the channel from nand, etc.)
I'll try again, but I don't know if I'll manage to properly launch channels with their required IOS (58, or another one), instead of cIOS.

 

[Badablek]

thanks, I will make a new devkitpro folder and update it (need to keep the old one for some homebrews)
it's hard to keep a clean compiling environment with a mix of old and new homebrews

thanks also for your explanation about channel launching. This was really by pure curiosity, IMHO USBLGX should only be used to launch emuNAND channels

 

[Cyan]

you know how to keep different devkitppc version for different homebrew needs?

create (extract) each devkitppc to different folders inside devkitpro.
example :
devkitPPC/ <-- I keep this one updated (also, autoupdate would replace it, if you ever launch the devkitpro installer again)
devkitPPC_r27/
devkitPPC_r29-1/

and before compiling, or in your makefile, set the path to the devkitppc you want. it will affect the environment variable only temporarily, for the current session (current MSdos window only):

build.bat

set DEVKITPPC=/f/devkitPro/devkitPPC_r29-1
set devkitPPC
make clean
make -j4

the second line is just a way to check it worked, it displays the temporary environment variable path.

or
makefile

export DEVKITPPC   :=   $(DEVKITPRO)/devkitPPC_r27
...

You still need to edit the libogc version manually to match the version used by your project.

There's a more complicated (automated) way if you want to also use different portlib/libogc path, which involve editing the "wii_rules" file in devkitppc folder, and then just "set" the devkitPPC variable to the folder with the wii_rules you want.

devkitppc_usbgx/ with wii_rules set to usbgx libogc and portlib path
devkitppc_oldhomebrewname/ with wii_rules set to specific libogc and portlib path
etc.

or edit the path to wii_rules in your makefile :

include $(DEVKITPPC)/wii_rules

or, overwrite the path in your makefile after wii_rules include:

add this to edit the path in your makefile (or if not using wii_rules) :

export LIBOGC_LIB   :=   $(DEVKITPRO)/libogc/lib/wii
export PORTLIBS       :=   $(DEVKITPRO)/portlibs/ppc

they will be loaded here:

export LIBPATHS   :=   $(foreach dir,$(LIBDIRS),-L$(dir)/lib) \
                   -L$(LIBOGC_LIB) -L$(PORTLIBS)/lib

 

[MrKatanaObiWan]

.