I've gathered this information so far:
- New wiis (mine) do not allow for installing IOSses without reverting IOS first.
- Reverting
- New wiis (mine) do not allow for installing IOSses without reverting IOS first.
- Reverting
Sadly, latest version found in http://gbatemp.net/index.php?showtopic=190786s3phir0th115 said:The installer for cIOS rev 14 and above should support what you're asking for. You just need to make sure you tell it to not reload the IOS, and it should work for you.
s32 __IOS_LoadStartupIOS()
{
ÂÂÂÂreturn 0;
}
Why exactly do you want to install a cIOS to IOS 254? If it's just for homebrew purposes that's fine, but you might want to pick a different number if you want to use it to play games...matsurisan said:Basically, the IOS installer has to:
- Not automatically load an IOS on startup (as that overwrites the nice work cboot2 done to load it adding bugs on the fly)
- Be able to select target IOS id (so that I can write 254 and only 254)
- Be nicely patches-based using the original IOSs as sources, not needing me to provide an illegal-to-redistribute pre-made IOS with ninty code inside of it.
Let's just say I meant >200 and my short term memory is too bad to say a correct number :/tueidj said:Why exactly do you want to install a cIOS to IOS 254? If it's just for homebrew purposes that's fine, but you might want to pick a different number if you want to use it to play games...matsurisan said:Basically, the IOS installer has to:
- Not automatically load an IOS on startup (as that overwrites the nice work cboot2 done to load it adding bugs on the fly)
- Be able to select target IOS id (so that I can write 254 and only 254)
- Be nicely patches-based using the original IOSs as sources, not needing me to provide an illegal-to-redistribute pre-made IOS with ninty code inside of it.
matsurisan said:The question here is: What IOS >200 installer can I use which will work when chained from cboot2?
Basically, the IOS installer has to:
- Not automatically load an IOS on startup (as that overwrites the nice work cboot2 done to load it adding bugs on the fly)
- Be able to select target IOS id (so that I can write 254 and only 254)
- Be nicely patches-based using the original IOSs as sources, not needing me to provide an illegal-to-redistribute pre-made IOS with ninty code inside of it.
matsurisan said:Sadly, latest version found in http://gbatemp.net/index.php?showtopic=190786s3phir0th115 said:The installer for cIOS rev 14 and above should support what you're asking for. You just need to make sure you tell it to not reload the IOS, and it should work for you.
Does fail with -1053, which means even if I do not choose to reload IOS, it still has reloaded it during libogc init, effectivelly screwing the job cboot2 done.
WiiCrazy said:I don't think you need cboot2 to run TBR... so why? To reduce the steps in TBR?
You're right (in my case).WiiCrazy said:I don't think you need cboot2 to run TBR... so why? To reduce the steps in TBR?
Just for the record, libogc was patched over a month ago to not reload IOS on program startup. If it is up-to-date there's no reason to implement that function yourself.matsurisan said:Somebody would have to rebuild the cios installer adding the following:
Code:s32 __IOS_LoadStartupIOS() { ÂÂÂÂreturn 0; }
Touching the NAND at all is a risk. Overwriting anything from ninty is a higher risk.WiiCrazy said:Patching an unused ios and especially non system menu ios is not a risk I think or is it?
On newer systems only downgrading back to 3.2 and so on causes a risk I guess since old ios is not compatible with new boot2 versions. (because of the timing issue bushing mentioned in his blog post.)
matsurisan said:Touching the NAND at all is a risk. Overwriting anything from ninty is a higher risk.WiiCrazy said:Patching an unused ios and especially non system menu ios is not a risk I think or is it?
On newer systems only downgrading back to 3.2 and so on causes a risk I guess since old ios is not compatible with new boot2 versions. (because of the timing issue bushing mentioned in his blog post.)
It's best to be as clean as possible when it comes to the NAND, specially on non-vuln-boot1 devices, as recovery might be impossible without ripping the wii open, soldering stuff and using a NAND flasher when the convenient bootmii on boot2 is not available.