It would be great if the .cfg file could contain the latest GameCube .bnr download URL
http://banner.rc24.xyz/
Thanks!
http://banner.rc24.xyz/
Thanks!
Reading symbols from F:\Homebrew\Wii\USBLoaderGX\trunk\boot.elf...done.
(gdb) info line *0x80c358dc
Line 120 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/FileOperations/File.cpp" starts at address 0x80c358d4 <_ZN5CFile4seekEli+52> and ends at 0x80c358e0 <_ZN5CFile4seekEli+64>.
(gdb) info line *0x80c3a76c
Line 85 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/SoundOperations/SoundDecoder.cpp" starts at address 0x80c3a76c <_ZN12SoundDecoder6RewindEv+40>
and ends at 0x80c3a780 <_ZN12SoundDecoder4ReadEPhii>.
(gdb) info line *0x80b6598c
Line 180 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/menu.cpp" starts at address 0x80b6598c <_Z8MainMenui+188> and ends at 0x80b659ac <_Z8MainMenui+220>.
(gdb) info line *0x80b65588
Line 54 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/main.cpp" starts at address 0x80b65588 <main+124> and ends at 0x80b6558c <main+128>.
(gdb) info line *0x80b5f990
No line number information available for address 0x80b5f990 <__crtmain+60>
(gdb) info line *0x80d06650
Line 215 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d06640 <__lwp_thread_handler+76> and ends at 0x80d06654 <__lwp_thread_handler+96>.
(gdb) info line *0x80d065f4
Line 204 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d065f4 <__lwp_thread_handler> and ends at 0x80d065fc <__lwp_thread_handler+8>.
(gdb)
Ok so I’ve deleted the entire USB loader gx folder from the apps folder on my sd card and I’ve replaced it with the one in your signature and it’s still doing that same thing.I suppose you are using r1268, so I checked your dumped memory addresses on that version.
Code:Reading symbols from F:\Homebrew\Wii\USBLoaderGX\trunk\boot.elf...done. (gdb) info line *0x80c358dc Line 120 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/FileOperations/File.cpp" starts at address 0x80c358d4 <_ZN5CFile4seekEli+52> and ends at 0x80c358e0 <_ZN5CFile4seekEli+64>. (gdb) info line *0x80c3a76c Line 85 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/SoundOperations/SoundDecoder.cpp" starts at address 0x80c3a76c <_ZN12SoundDecoder6RewindEv+40> and ends at 0x80c3a780 <_ZN12SoundDecoder4ReadEPhii>. (gdb) info line *0x80b6598c Line 180 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/menu.cpp" starts at address 0x80b6598c <_Z8MainMenui+188> and ends at 0x80b659ac <_Z8MainMenui+220>. (gdb) info line *0x80b65588 Line 54 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/main.cpp" starts at address 0x80b65588 <main+124> and ends at 0x80b6558c <main+128>. (gdb) info line *0x80b5f990 No line number information available for address 0x80b5f990 <__crtmain+60> (gdb) info line *0x80d06650 Line 215 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d06640 <__lwp_thread_handler+76> and ends at 0x80d06654 <__lwp_thread_handler+96>. (gdb) info line *0x80d065f4 Line 204 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d065f4 <__lwp_thread_handler> and ends at 0x80d065fc <__lwp_thread_handler+8>. (gdb)
What I think : it's a sound issue !
Maybe you decided to use a theme (in the loader, or a patched non official system menu maybe?), or added new sound files to be played instead of the system menu's official sound, and these files are located on USB (instead of SD, like I always suggest).
Your USB might have issue initializing fast enough, as a result the sound file can't be played when needed.
Solution :
- put all homebrew resources on SD (covers, themes, cheats, settings, etc.)
- don't use custom sound files
- or don't use a slow to initialize drive.
immediate solution : reset your settings (delete GXGlobal.cfg file, or even the entire usbloader_gx folder)
You want to learn how it works, or you want a guide to setup and use?Hey guys, just wanted to ask about the emunand for the wii. How does that work? I mean, I've tried to find tutorials but I'm so confused about it. USB Loader GX has an option for dumping NAND, and probably want to have an emunand, but what would the benefits of having one be? Isn't it slower to load?
I want to install it, but I'm curious on how it works? What are the benefits of having that setup? Yeah, I saw your guide and was reading, but I'm quite confused as it seems that every loader has an emunand set up? It's just that I have also a 3DS and remember having an emunand, but that was because (I suppose) it was like a safety method for not bricking real nand (but then came a9lh and b9s)... So, it was basically obsolete, but for the wii, ti seems that people use emunand more than on 3ds. Thanks a lot for the previous help!do you have the official Wii system menu, or did you replaced it when following a hacking guide (for example dark menu ?).
can you try another SD card?
If it's not caused by the audio, it's crashing while trying to load the main menu, so there's something bad (maybe a bad game? or bad cover ?). But to find the problem you'll have to move or rename some folders.
for example, rename your wbfs folder to wbfs_back, create a new empty wbfs folder, so you don't have any wii games loaded at all when launching the loader.
if it works without crashing the loader, you'll know it's a wii game issue. if it still crash, try with the games folder (if you have gamecube games), etc.
if you find the problematic element, restore it (rename it back to original folder) and move half the content to another folder. try again. if it crash, it's one of the half you kept. if it works, it's in the other half. etc.
You want to learn how it works, or you want a guide to setup and use?
here is a guide I wrote : https://gbatemp.net/posts/6592730
Hope it'll help.
You don't even have the USB connected?it’s just by opening up USB loader gx via the forwarder channel and within homebrew.
to know how it works, you need to know how the console works to read a disc or the files on the internal memory.
The running application don't mount the devices and don't access the file itself. Instead, it asks the IOS (which acts as bridge between software and hardware, like a driver) the file they want to access, then the IOS mount the drive, locate the file, and give it to the application.
App/game <---> IOS <---> CD/NAND
the cIOS is a patched IOS which redirect the mounted devices.
App/game <---> cIOS <---> USB/SD/CD/NAND
when you launch a Wii game from USBLoaders, the loader use the cIOS which has access to USB. when the game request a file, the cIOS take it from USB (instead of CD) and send it to the running application. the game don't know the file is from another place, it runs as if it was the original file from served by the IOS from the game Disc. the game trusts the IOS and communicate only with it, it doesn't care where the provided file comes from.
EmuNAND is working the same way.
You create a copy of your internal Wii memory content (the files and folders in the internal file system) on an SD or USB FAT32 partition, and tell the cIOS to redirect the file access request and provide another file from the external device, instead of the original internal memory, to the asking application.
it's wrongly called "emulated NAND", but it's in fact a "redirected NAND access", it's not emulated.
Most USBLoaders have that option, because it's included in the cIOS itself. It's just an option to enable or not to load (or save) files to another location than the original place.
It's slightly different than 3DS, because the 3DS emuNAND is a full binary chipset data (8GB NAND -> 8GB 1:1 exact binary data copied on a hidden partition on SD card, it's not a FAT32 but the full copy of the chipset memory, not its file system).
the wii does not require the full NAND binary as a partition, only the files stored in a folder.
Dumping a NAND File system takes about 1 minute and is easy to recreate whenever it's needed! compared to full chipset dump which takes 30min/1hour.
You can even have multiple dumped version at the same time (PAL, NTSC, Kids, Friend, etc.) and it's not tied to a specific console which means you can take your SD card 'on the go' and continue playing your own games on your friend's console.
It's also different in the sense that you don't choose to boot either the normal NAND, or the copied partition. instead, you always boot the normal NAND which has a patched IOS (the d2x cIOS you installed in softmod guides) with the added ability to serves/redirect files in real time. It's an option you choose per launched game, and not per console boot.
But the "boot into a full redirected NAND copy" mode exists too, it's what is called "neek". although it has better compatibility, it's also slower to boot and harder to setup and manage or integrate in backup loaders.
so, you have 2 different emuNAND method :
1. real time cIOS emuNAND redirection as individual option from the real NAND (like LayeredFS),
or
2. full neek emuNAND rebooted environment (like redNAND on 3DS).
The purpose of emuNAND on Wii is to :
- prevent brick on real NAND. Useful when creating and testing a new system menu theme, or installing channels which can have bad data or can be malware, bricking only the copy.
- have a lot more space to install channels and data (VC, Wiiware, savegame, etc.), up to 2TB instead of 512MB! Unline 3DS the emuNAND is not the same size than NAND. The available space is as big as the FAT32 partition. (theoretically 16TB, but currently only 2TB)
what you did wrong? you didn't follow the guide.loaded nswitch and then it stays on the screen "Reloading bootmii IOS" and the Wii starts blinking blue light on and off and tht's it.
What am I doing wrong?
USBLoaderGX is fast booting into neek, it doesn't rely on bootmii files or nswitch.
linking ... boot.elf
/home/florian/devkitPro/v27-usb/portlibs/ppc/lib/libvorbisidec.a(info.o): In function `tagcompare':
info.c:(.text+0x40): undefined reference to `__locale_ctype_ptr'
info.c:(.text+0x70): undefined reference to `__locale_ctype_ptr'
info.c:(.text+0x90): undefined reference to `__locale_ctype_ptr'
/home/florian/mkw-patch/usbloadergx-code/source/libs/libfat//libcustomfat.a(directory.o): In function `_FAT_directory_entryGetAlias':
f:\Homebrew\Wii\USBLoaderGX\branches_sourceforge_svn\libs\libcustomfat\libogc\wii_release/f:/Homebrew/Wii/USBLoaderGX/branches_sourceforge_svn/libs/libcustomfat/libogc/../source/directory.c:225: undefined reference to `__locale_ctype_ptr'
f:\Homebrew\Wii\USBLoaderGX\branches_sourceforge_svn\libs\libcustomfat\libogc\wii_release/f:/Homebrew/Wii/USBLoaderGX/branches_sourceforge_svn/libs/libcustomfat/libogc/../source/directory.c:233: undefined reference to `__locale_ctype_ptr'
collect2: error: ld returned 1 exit status
when something is wrong, it usually reboot the console.Is this a known issue, or is a matter of configuration?
which size is your drive? if it's bigger than 2TB that's your issue. GPT table format is not supported with emuNAND or Neek, you need MBR.The drive is formatted as FAT32
I am not wise to answer if something is correctly setup, because I used ModMii, and wanted to use USBLoaderGX. All I can tell you for a fact is that USBLoaderGX seems to be doing it's job perfectly, because the EmuNand channels appear.if it reboots, it's usually when something is missing (missing cIOS, IOS, or path to the file to load not found, device not initialized, etc.)
I can't tell what's wrong with the information you provided. try again, try to launch neek from other method (nswitch, or boot2).
is your cIOS emuNAND mode (not neek) working fine to launch installed channels ?
ModMii said:==================================================
4.3U Emulated NAND created by ModMii on 13/11/2018
==================================================
setting.txt built using this serial: CUECASROTAS
Priiloader v0.7 [mod for neek2o] Installed
WiiFlow Forwarder Channel Installed
nSwitch Channel Installed
Post Loader Forwarder Channel Installed
cIOS249 rev14 Installed
NMM (No More Memory-Cards) Installed
------
Errors
------
Multi-Mod Manager (MMM) v13.4: Invalid
WiiFlow: Invalid
nSwitch: Invalid
Postloader: Invalid