wraggster
May 8th, 2008, 00:57
Sven one of the main Wii Hackers discusses more about loaders on the Wii
Loading loaders
or: How to avoid strange lockups when loading a loader on the Wii.
I've been asked about this issue a few times in the last few days so I just decided to write this small post about it so that I can just link people to this.
The basic problem that currently might happen on the Wii is the following:
You are launching a ELF loader (like the twilight hack) but don't really like it. So you want to launch another loader which has more features like a menu from which you can choose your ELF or a nice GUI. If the author of this loader did everything right everything will just work fine and you'll be able to use your better loader then.
But what happens if your console suddenly locks up while loading the ELF and you don't know what to do? Well, you can blame the author of the other loader then because he forgot something :P
All ELF files on the Wii have to be loaded somewhere into the memory by some other code sitting somewhere else in the memory. The lockup you might have experienced is directly related to this:
To be able to loading something into the memory you have to have some code in the RAM. And if the new code wants to be at the same location as the old one you'll encounter this lockup - remember: unintentionally overwriting code you are currently running is a really bad idea(tm).
And if you want to load a loader this might very easily happen as the authors of both loaders might have had the same idea: "Let's just place this loader at 0x81330000. No other code will ever want to be loaded to that address". You see how this must end.
However, this problem can be very easily fixed (even if you are not the other of the bug^H^H^Hsecond loader): Just create a pre-loader that wants to be loaded to the default address. This pre-loader itself contains a full image of your real program and just loads this to your real address. As the original loader has already done its work here you can just overwrite it then with your loader.
Implementing this pre-loader is very simple. You just need some dol-loading code, a simple wrapper for that and some code like bin2s to convert your loader's DOL file into an object.
Don't have a clue yet? Just take the miniloader from my sdelfloader and create the loader.S file by typing the following on your console (you can omit the first file if you already have a dol file of your loader):
powerpc-gekko-objcopy -O binary great_loader.elf great_loader.dol
bin2s great_loader.dol > miniloader/source/loader.S
cd miniloader
make
You can then take the miniloader.dol/elf which will hopefully not lockup your Wii anymore.
http://svenpeter.blogspot.com/
Loading loaders
or: How to avoid strange lockups when loading a loader on the Wii.
I've been asked about this issue a few times in the last few days so I just decided to write this small post about it so that I can just link people to this.
The basic problem that currently might happen on the Wii is the following:
You are launching a ELF loader (like the twilight hack) but don't really like it. So you want to launch another loader which has more features like a menu from which you can choose your ELF or a nice GUI. If the author of this loader did everything right everything will just work fine and you'll be able to use your better loader then.
But what happens if your console suddenly locks up while loading the ELF and you don't know what to do? Well, you can blame the author of the other loader then because he forgot something :P
All ELF files on the Wii have to be loaded somewhere into the memory by some other code sitting somewhere else in the memory. The lockup you might have experienced is directly related to this:
To be able to loading something into the memory you have to have some code in the RAM. And if the new code wants to be at the same location as the old one you'll encounter this lockup - remember: unintentionally overwriting code you are currently running is a really bad idea(tm).
And if you want to load a loader this might very easily happen as the authors of both loaders might have had the same idea: "Let's just place this loader at 0x81330000. No other code will ever want to be loaded to that address". You see how this must end.
However, this problem can be very easily fixed (even if you are not the other of the bug^H^H^Hsecond loader): Just create a pre-loader that wants to be loaded to the default address. This pre-loader itself contains a full image of your real program and just loads this to your real address. As the original loader has already done its work here you can just overwrite it then with your loader.
Implementing this pre-loader is very simple. You just need some dol-loading code, a simple wrapper for that and some code like bin2s to convert your loader's DOL file into an object.
Don't have a clue yet? Just take the miniloader from my sdelfloader and create the loader.S file by typing the following on your console (you can omit the first file if you already have a dol file of your loader):
powerpc-gekko-objcopy -O binary great_loader.elf great_loader.dol
bin2s great_loader.dol > miniloader/source/loader.S
cd miniloader
make
You can then take the miniloader.dol/elf which will hopefully not lockup your Wii anymore.
http://svenpeter.blogspot.com/