DI issues -- seems to just not work

So, first, a bit of background. I'm into SMG hacking (I have my own board about it but that's not my point here), and getting into a project called SMG2.5. We're aiming at removing the requirement of obtaining an ISO to get into SMG hacking, for obvious legality reasons. For that, I'm trying to code a little Wii program that will dump all the needed files from a SMG1 or SMG2 disc.

I was looking at the provided APIs for DVD access, and I must say the documentation is poor. But I found a nice little pearl into ftpii, called libfst, that handles reading Wii discs for me.

Problem is, I can't even get the DI interface to work.

My code is available here: [github.com]

The Wii I'm running this on, runs off system menu 4.3E with no modifications other than a standard HBC install done via Letterbomb.

My version of devkitPro is recent enough I think. installed.ini says my libogc version is 1.8.11.1, and devkitPPC version is 26.

Now, about what happens when running that code:
* DI_Init() returns zero, which would indicate a success.
* DI_GetError() however, always returns -6 (ENXIO). As if di_fd wasn't initialized properly. According to the code, there is a possibility that DI_Init() returns zero without initializing it, if AHBPROT isn't 0xFFFFFFFF. I don't know how AHBPROT works, though. All I know is that it has to do with restricting PPC access to certain I/O ports.
* DI_GetStatus() always returns 0xA, which causes my code to enter an endless loop. The drive also never spins up or attempts to do anything.

I have searched a lot but failed to find anything helpful. All the code I've seen either does the same thing as mine, or goes through weirdass libraries and abstraction layers I'm too lazy to try to reverse-engineer.

So I figured I'd come here and ask. Did I do something wrong in my code, or do I just need to install something particular on my Wii? I found mentions of DVDX but according to the wiki it is outdated and HBC handles its functionality.



Edited 1 time(s). Last edit at 02/01/2013 07:09PM by Mega_Mario.

How exactly are you loading the compiled app? From SD/USB? (the alternative is over wifi with wiiload) If so, you need a <no_ios_reload /> tag in the meta.xml for it to be loaded with AHBPROT set correctly.

Many open source projects contain code to check this before doing things which require AHBPROT, I would advise finding and adding some such code to your app so as to avoid issues from people using crappy homebrew loaders etc.

EDIT : adding this to the start of your app and then checking HAVE_AHBPROT should work (if it's 1, you're all set)

#define HAVE_AHBPROT ((*(vu32*)0xcd800064 == 0xFFFFFFFF) ? 1 : 0)

Edited 1 time(s). Last edit at 02/01/2013 08:46PM by SifJar.

I'm loading it from a SD card. I haven't made a meta.xml file or anything past the .dol because I'm lazy, but I'll try it out.

Also, if HAVE_AHBPROT is already 1 when starting the app, does that mean DI stuff will work? Because I remember that at some point in my code I had forgotten to call DI_Init() and it wouldn't work either.

Thanks for the info anyway :)

Edit- I just tried adding that tag you mentioned, and it worked I guess. When I pressed 1, the DVD drive started spinning. However, the screen turned black. But that looks like a crash somewhere further in my code. I'll look into that.



Edited 1 time(s). Last edit at 02/01/2013 10:01PM by Mega_Mario.

If HAVE_AHBPROT is 1, it means that DI_Init() should work. Other DI stuff won't work until it's initialized. I didn't look too closely at your code, so I'm not sure what could be causing the issue you are now experiencing. I'll have another look, but I'm not very experienced in developing so may not be able to offer much more help I'm afraid. Hopefully someone who knows better will see the thread though.

EDIT: looks to me like you used fatInitDefault(), which will initialize the SD card, then try to initialize the SD card again using fatMountSimple() wihin the function initdisc(). That doesn't seem right to me, I'd guess it may be on fatMountSimple() that it crashes.



Edited 1 time(s). Last edit at 02/01/2013 11:35PM by SifJar.

Possible, however my code would hang in the DI_GetStatus() loop, which means that fatMountSimple() passed... but perhaps that was because of the IOS reloading stuff. I'm gonna try without that call and see.

Edit- removing the libfat function calls for now, gets rid of the blackscreens. However it seems to be freezing somewhere else. Will investigate tomorrow.



Edited 1 time(s). Last edit at 02/02/2013 12:18AM by Mega_Mario.

IOS reloading stuff? I don't see that anywhere...but if IOS was reloaded, you'd have to reinitialize DI, which would also mean keeping HW_AHBPROT during the IOS reload, which is more complicated than simply reloading IOS. Reloading IOS normally will lost HW_AHBPROT access.

But unless I've overlooked it, I don't see any IOS reloading. I'll try and have a closer look tomorrow.

Oh. By 'IOS reloading' I meant how the <no_ios_reload /> tag was missing from my meta.xml file. Sorry for the confusion.



Edited 1 time(s). Last edit at 02/02/2013 12:51AM by Mega_Mario.

Ah, ok. Understand now.

Does DI_GetError still return -6, or is that fixed/changed now due to HW_AHBPROT?

That is all fixed, all thanks to <no_ios_reload />. I can now read files from the disc fine.

I'm just concerned about homebrew loaders that aren't HBC. If they're that important, how would I handle that in the code?

If they're half decent, they'll provide HW_AHBPROT access, which can be checked as mentioned above. If they don't give that access, just display an error telling users to stop using their pathetic loader and switch to something that works properly e.g. (updated) HBC. You need an IOS exploit to get HW_AHBPROT access from within your own code, so you should have the code only work when the access is already there.



Edited 1 time(s). Last edit at 02/03/2013 12:06AM by SifJar.

The proper way to do it would be to fix the FST library to not use unencrypted reads, then you wouldn't need any IOS patches.

The FST library seems able to decrypt stuff on its own, seeing as it contains the common keys. Haven't dug deeper into the code though.

I don't think tueidj was talking about that. Basically, the way the FST library works, it requires IOS patches, which means requiring HW_AHBPROT. Tueidj was saying the library can be fixed to not require IOS patches, so it would work without HW_AHBPROT. My guess is that this is quite a complex task, seeing as no one seems to have done it.

Well I don't know what requires IOS patches and what doesn't, so a bit of info would be welcome.

I noticed that while it reads all the file info fine, it fails at reading the files themselves, and just returns the same 16-byte pattern over and over again (which appears to be decrypted zeros).

Filesystem structures are read using DI_OpenPartition() and DI_Read(), which uses DVD_LOW_READ. File reads however, use DI_ReadDVD() which uses either DVD_READ or DVD_READ_UNENCRYPTED. Which one would be the one that requires patches there?

I tried changing file reads to use DI_OpenPartition() and DI_Read(), but then FST_Mount(), which has nothing to do with that, started hanging... weird. I'll investigate.

DVD_READ_UNENCRYTED would require patches based on tueidj's post.

Yep.

I found out why the FST lib was freezing anyway, I overlooked some steps in the disc reading process after having modified how _read() reads data. I'll try out with my fix tomorrow.

Something that also bugs me is that the FST library embeds the Wii common keys inside its code. Isn't that illegal? Wouldn't I instead be supposed to read the keys from the Wii, or have the user provide a keys.bin file?

Keys aren't copyright.

Okay, then it's all good.

Oh and actually I found out that those keys aren't even needed. If I use DI_OpenPartition() and DI_Read(), IOS will handle cluster decryption transparently for me. That takes a lot of complication out!

Somebody probably should have suggested that earlier.

As for DVD access, from what I read I'd need to update HBC and use <ahb_access /> instead of <no_ios_reload/>.

My program is often crashing after running for a while, and the crash happens in the IRQ handler. I read that this happens when using <no_ios_reload/> and loading the app before HBC has finished initializing its network stuff. But if I don't have full AHB access, I can't access the DVD drive, which defeats the purpose of my program.

Guess I'll just update HBC and tell users to do so if they haven't done it already :)