Curiosity about downgrading

That actually has nothing to do with it. Wii game discs use a special optical media; they are not normal DVDs. An unmodified wii console is unable to even read a "backup" game.

Pretty dumb of me. That never came to my attention. But thanks for telling me that.

Sorry for bumping this old topic, but since we were talking a lot about Priiloader here, I want to discuss about something I've found on its code google page:

"Priiloader does not provide as complete protection as Bootmii/boot2, but it's still useful for solving many of the most common bricks, accessing it through the Homebrew Channel or Bootmii/IOS to fix them. It is the best protection that can be installed in consoles that can not install Bootmii/boot2. In theory, the only elements that would impede the functioning of Priiloader if they are deleted or corrupted are:

* IOS36
* Homebrew Channel IOS (usually IOS34 and IOS61)
* System Menu IOS (usually IOS30, IOS50, IOS60 and IOS70)
* System Menu (in this case even if it is corrupt but it's bootable Priiloader still works, but not if it was deleted)"

About the bold text, if Priiloader takes the system menu's filename, shouldn't the system menu IOS boot Priiloader regardless of what happened to the actual system menu? Priiloader is fine, pretends it's the actual system menu, and it is booted. You couldn't boot the actual system menu from there, if the same is missing, but Priiloader should be able to boot HBC, then reinstall the system menu using a specific app.

Or I'm wrong and missed something?



Edited 1 time(s). Last edit at 07/15/2010 05:00AM by Aobx.

Well, thats why it still works when it SM is corrupted. However, if SM is deleted, the Wii's delete process (a function of ES I think) deletes the deleted title's TMD, ticket and ALL contents (i.e. the whole folder on NAND, e.g. title/00000001/00000002 for SM), including the Priiloader DOL, so it is important whether SM is still partly existent or not.

A while ago (before BootMii was released IIRC), crediar showed a video of Preloader 0.30 which allowed him to delete the SM and still boot Preloader, but when he released preloader 0.30, he didn't release the installer, so a third party installer was made which installed in the same method as before, and crediar's new hack was never released. This may have been a boot2 hack, in which case it wouldn't have worked on newer Wii's anyway, but it was never confirmed AFAIK if this was definitely how it worked (although there aren't many other options I believe).

Nice knowing that. Thought everything going deleted was hardcoded, so it wouldn't delete an entire folder. Thanks again, SifJar.

While reading this topic again and all our discussion about Priiloader, we've made clear that the system menu IOS missing/corrupted isn't much of an issue, as long as Priiloader's booting IOS is fine (thus you can reinstall the system menu IOS). Also, we've made clear that Priiloader's booting IOS must have ES_DiVerify to identify Priiloader's dol as system menu. Suppose I install a clean unpatched IOS in Priiloader's booting IOS slot, that means I would get a full brick, wouldn't I?

Priiloader's booting IOS is usually the system menu's IOS (I could be wrong, but I believe that changing the IOS in the Priiloader settings causes Priiloader to reload to that IOS when launching the system menu, but Priiloader itself still runs on the system menu's IOS). Therefore, a missing/corrupted system menu IOS would cause a brick even if Priiloader is installed. Furthermore, ES_Identify is not required at all if Priiloader does not reload IOS. Even if ES_Identify was required, Priiloader would still run, but it would not be able to load the system menu. However, it could still launch the HBC or most homebrew applications, allowing an IOS with ES_Identify to be installed (this was exactly what happened with Preloader in this situation).

Oops, I forgot to add I'm already considered that Priiloader's IOS is changed, thus it has to be reloaded. Maybe I caused you to explain that again.

I thought it was just the opposite. Thought Priiloader changed the system menu tmd to set its booting IOS as the one chosen by the user. As Priiloader takes system menu name, boot2 would check the tmd to launch Priiloader with the IOS selected by the user. Then, Priiloader itself would reload to the system menu IOS and boot the renamed system menu. Guess I was wrong.

Supposing I was right, I think when Priiloader reloaded to the system menu IOS, the IOS would come without higher privilegies, hence needing ES_DiVerify. As Priiloader does not need any patch in the system menu IOS, this fact could be enough to prove I'm mistaking things.

I think it's more like you said, jbc. But why would someone change the IOS Priiloader uses to boot system menu, then? Doesn't Nintendo make the system menu IOS to be the best one to be used with system menu? So why change?

there isn't much point changing it, and jbc is right in that it doesnt change the tmd

I was discussing with jbc007 through PM about an old quote from him:

"'LU64+' wiis have new hardware, which is incapable of running old (pre October 23, 2008) IOSes. If an 'LU64+' wii is downgraded to a system menu which uses an old IOS (3.3 and earlier), it will not be able to run the system menu IOS, and will therefore brick."

The question was: "If IOS15 v257 is so old, why does it work with TBR and alikes, even on LU64+ Wiis?" We mainly based our talk in this article: [hackmii.com]. There, bushing confirmed IOS16 worked properly, even being old, though he doesn't know the explanation of why. Also, he confirmed in response to a comment that IOS15 is very similar to IOS16, thus it might work too. In fact, it works, in its oldest revision.

jbc007 pointed a theory seen in a comment, that newer versions of IOS15 (but still older than 23 October, 2008) try to initialize a hardware that IOS16 doesn't bother to do. That action wouldn't work this way, in LU64+ Wiis, so maybe IOS15 comes to a halt and doesn't work for as long as its loaded.

We stopped there, jbc actually advised me to bring this discussion here to see if someone has more info about this. In case you know something about this, please post here.

AFAIK, one theory about why these IOS work is because they are early IOS, and have only a kernel, no external modules, everything is in the kernel. That theory was given IIRC by WiiPower (no idea where, don't ask me to give a link :P), and he knows a fair bit about the Wii, so could well be quite accurate.

EDIT: It took me a while to figure out what you meant about the theory you posted, but I think I get it now, and I guess it makes sense, but don't the latest revisions of IOS15 work fine on all hardware?

What I understand by what you're saying is, the issue with timing isn't an issue, because the old revisions of IOS15 don't even try to initialize the hardware that in newer Wii's takes longer to initialize, so it doesn't matter when they don't initialize fast enough. Is that about right? I guess that makes sense too. But perhaps that is linked to what I said too, maybe the other hardware isn't initialized because of the missing modules, and in other IOS, the extra modules are reliant on the hardware which was changed, and thats why they don't work?



Edited 1 time(s). Last edit at 07/26/2010 09:16PM by SifJar.

Quote
SifJar
but don't the latest revisions of IOS15 work fine on all hardware?

All revisions of IOS 15 (and all other IOSes) released since October 23, 2008 work on all wiis. However, IOS 15, unlike most IOSes, had several revisions before October 23, 2008. Most likely, starting with one of them, compatibility with newer wiis was lost until the October 23 update.

Quote
SifJar
What I understand by what you're saying is, the issue with timing isn't an issue, because the old revisions of IOS15 don't even try to initialize the hardware that in newer Wii's takes longer to initialize, so it doesn't matter when they don't initialize fast enough. Is that about right? I guess that makes sense too. But perhaps that is linked to what I said too, maybe the other hardware isn't initialized because of the missing modules, and in other IOS, the extra modules are reliant on the hardware which was changed, and thats why they don't work?

That was a theory I saw. It seems quite possible that it is linked to WiiPower's theory as you said. Of course, I am unaware of any definitive answer.

Thanks for adding to the discussion, SifJar. Both explanations are pretty similar, since they rely on the IOS doesn't starting any hardware. If someone with a LU64+ tested early revisions of IOS15, it could be nice.

I suppose there won't be any damage, if done right. Correct me if I'm wrong, but I think one tester should have a trucha bugged IOS besides IOS15 (just to be safe). Then he/she could try to use all the early revisions of IOS15 in some app that needs it, like Trucha Bug Restorer. From the moment the app stops working, then the current IOS15 is the starting point for not being compatible with LU64+. Of course, that would go until the first IOS15 from or after 23 October, 2008.

I still don't understand why some revisions of IOS15 would be incompatible. If the oldest revision is compatible, why would ones in between not be? IOS15 is still very similar to the original revision, just with bugfixes AFAIK (this is what happens with all IOS). New features aren't added, they are saved for new versions of IOS (i.e. new IOS number). So with no new features added, IOS15 should always require the same hardware, in all revisions, so all should be compatible.

Anyway, what benefit is there to finding an incompatible revision? Merely for interest, or is there actually a reason it would be useful?

I believe it's for interest. If you find the exactly IOS15 revision where things go wrong, you could compare it to all its previous releases to determine what makes it incompatible with LU64+. Knowledge almost always proves itself useful. There might be some future situation similar to this one, and knowing this stuff might be helpful.

People around here always say it's best to have the highest working revision for a specific purpose. So, for instance, if IOS15 v258 works fine, then it's better than IOS15 v257, regardless it's also working. Not sure of details, since one user here said that higher revisions tend to fix security exploits, rather than making the IOS more stable.