Add 2-bay HDD enclosure support

[cyberstudio10]

https://gbatemp.net/threads/2-drive-enclosure.608112/

[Leseratte10]

Wow. I'll probably need a while to "get back into" the code again to properly understand all these changes, but it's great seeing people taking up cIOS development again, given that I don't have as much time available for cIOS development as I'd like. Thanks for the PR!

So, just so I understand this correctly, this basically makes it so that if there's one USB device that "exports" multiple drives, this makes it so that it always opens the last one?

Given that the development of the HBC and all existing USB Loaders has basically stopped, I don't think there will ever be a way to signal from the USB Loader to the cIOS which device to mount, but have you thought about maybe doing something like checking all attached devices for a given file / identifier to determine which one to mount?

Also, does this PR "just" support single USB devices with two logical drives, or would it also support attaching a USB hub to the Wii and then attaching multiple regular USB devices to that hub? I'm guessing it won't, but do you have an idea how difficult it would be to add that?

[cyberstudio10]

I've considered several options such as the ones you surmised.

Any cIOS mod shall be drop-in replacements but not require any changes to the homebrew apps on top. (So any solution requiring a new signaling mechanism is rejected.) Let you said, HBC development is not very active nowadays.

Second, while 2-bay primarily benefits Wii U users, Wii users must be able to just take this cIOS and use it, and to them, there shall be no changes in existing behaviour. So the reverse scan order I originally proposed was rejected, too. If IOS 58 scans forward but had my cIOS scanned drives backward it would have been very difficult to comprehend when both IOS's are mixed and used on the same console.

As for hub, it sounded like something that v9/v10-beta53-alt did or would be able to do, but I didn't go in that direction because alt did not have a good reputation. I was not around the scene back then but I guess what happened was that a lot of efforts were spent on v9 building plug-and-play, multi-ports, etc. which negatively impacted compatibility and v10 (non-alt) went back to the v8 code-base. People saw no point continuing down the v9 path given that Nintendo had IOS 58. Given the backstory, following the v9 lineage was not a risk I would take, so no hub support. However, on a regular Wii I tested dual HDD on USB port 0 and FAKEMOTE on USB port 1, and that worked!!!

So the solution I chose was to repurpose the v9/v10-alt signaling mechanism. USB Loader GX and WiiXplorer use that to switch between 2 hard drives on 2 separate USB ports, but I take that to mean 2 hard drives on the same USB Port 0. The underlying cIOS implementation is very different from v9 (and a lot simpler) but the API to activate the second drive is the same. In USB Loader GX just change the "USB Port" option to "1" or "Both" (from 0). In WiiXplorer there is an option to use both USB ports. Some UI changes to USB Loader GX would help, but not necessary. For instance the option could be called "USB Drive" instead of "USB Port". The options remain "0", "1" or "Both". If 2 separate USB HDDs are used with v10-beta53-alt, choose the appropriate "USB Drive" and for a single enclosure with 2 HDD bays, also choose the appropriate "USB Drive". Same wording. That's only a UI clarification with no need of any changes to the actual code.

I did not know how the Reload IOS Block started working on the Wii Mini. I did not do anything to fix it, but it fixed itself. I speculate that the process of disk initialization/dismounting had some corruption that required a reload to correct, but by cleaning up initialization/unmounting code, that restart is now no longer required. In my opinion this alone deserves a "release".

I have solicited the community's help with testing. I have not garnered any feedback from anyone who has actually tried it out yet but I am very hopeful that given some time, we will get tested. In the meantime my son will use it as his daily cIOS to ensure the best stability. I probably won't be able to do anything for decade-old issues but at least I must make sure there shall be no regression.

Before I retired, I did code reviews at work and it was face-to-face or by video conference. That way I would have to explain the code and questions/feedback would be immediate. The direct interaction helped very much to refresh memory of code that you worked on some time ago. If that sounds like it would help, let me know.

[Leseratte10]

Thanks for your detailed response.

As for cIOS mods being a drop-in replacement, I definitely agree with that - but it also means that every stupid design decision from 10 years ago will need to be carried over, even if there might be better (or more compatible) solutions available now. HBC and homebrew development sadly stopped a long time ago. If I have some time to dedicate to cIOS development in the future, maybe I'll try adding something like a config file. Make a small homebrew app that writes a cIOS config file to the NAND, and have the cIOS read that on each initialization to trigger different behaviour. That way it could be implemented to behave exactly like the old cIOS when no config file is found, but if the file is present, people could do additional stuff like switch drive order, choose which drive to use, or any other stuff that might still be added in the future. And more importantly, these config changes done by the user would then also apply to old USB Loaders. The "old" way of having IOS Ioctl interfaces to be called by the USB Loader was okay-ish while the loaders were still being developed, but now they're just annoying. A config app would also make it way easier for users to switch between settings instead of having to re-install a cIOS, which would make it easier (less risky) to re-introduce stuff like Hub support that might break other stuff, because it wouldn't be enabled by default.

I mean, you had to change the version number from 1 to 9 to get loaders to support dual HDD, and maybe that's also what fixed IOS Reload - stupid loaders gatekeeping functionality behind a cIOS version number check. That's also why I named the cIOS "d2xl" instead of a different name, as there's some loaders that check for d2x compatibility by checking if the version string starts with "d2x".

As for code reviews refreshing code I worked on a long time ago, that would be a great idea if there was any code in the cIOS that I worked on :P - basically, I never had anything to do with cIOS development. When I started working on any kind of serious Wii modding, cIOS development had already ended, so what I did to the cIOS so far was getting it to compile again, adding a hack fix for Wii Mini support, and just playing around with the code in general to try and figure out how it works. And then I got sidetracked again with all the other projects (Wiimmfi, LE-CODE, other non-Wii-related projects ...) that I'm working on.

Though, interestingly there's been a new commit (and release) on the old repo by davebaol regarding UStealth support (#9), so I'll have to take a look at that, too. Didn't think there would ever be any new updates to that repo again.

[cyberstudio10]

I looked at the FAT interface briefly. There can be at most 8 USB partitions, named usb1: to usb8:. Nothing written on stone says they must come from the same disk. We do a scan to find partitions on as many disks as we can, over any number of drive bays and any number of USB ports... and to the user it is just a path. That would have been ideal, and transparent to existing applications.

But the problem is we have to support the Read Sector and Write Sector interfaces in the EHCI module, and those have no concept whatsoever of devices, disks, ports or LUNs. It has always been assumed to be one disk. The Set Port extension is not very pretty, but our hands are tied. We are not able to do fundamentally better because of Read/Write Sector. They take only a 32-bit LBA sector number addressing up to a 2TB disk and that's the hard limit. If an extension is created to address larger disks and multiple disks, we will have to create a new suite of incompatible apps. If everything goes through FAT then we would have had a nice user experience and support this transparently without the user's involvement.

I wonder if you have any plans to PR Leseratte10/d2x-cios to davebaol/d2x-cios. Just asking...

I've marked the binaries on 2022-02-28 as "v2". Let me try and see if I get a black screen from that.

[Leseratte10]

Exactly, because there's just the one "set port" API, things are going to get ugly. But if the cIOS were to support USB hubs and everything and be able to initialize however many drives a user has connected to their Wii, then a cIOS config file (that can be written by a homebrew app) could then be used to be like "okay, the drive with vendor ID X and product ID Y and serial number Z is considered 'drive 0' no matter where it's connected to, and the drive with vendor ID ABC is considered 'drive 1'", and then people could do stuff like attach a USB hub to their Wii Mini and add up to two useable USB drives plus however many Wii accesssories they want to that hub. That (config file) is just a first idea I had, not sure how well that would work in practice. Maybe there's a better way.

As for PRing my changes in this repo back to davebaol's repository, I did not plan to do that as it seems like development over there is completely dead. The last actual code changes were in 2012 (to add WiiU support), and after that nothing has happened over there. That's almost 10 years without any updates. In 2019 (when I softmodded my Wii Mini with Bluebomb) I opened a bug report over there asking how to compile the cIOS (as nobody I asked knew how to properly compile them). I did get a response from davebaol after pinging him, but even with that the project seemed pretty dead.

When I started working on my fork back in 2019 I was hoping to have a bit more time available to dedicate to the cIOS, but that didn't happen. But still, considering that development in the original repository has ceased a long time ago, I don't see a good reason to merge my fork back into the original repository, having to rely on davebaol to merge future changes or to make new releases.

[cyberstudio10]

Just tried "v2" (2022-02-28). Reload IOS Block still functioned without any black screen! WiiXplorer says d2x cios v9+ required.

This is the first time I work on open source. The dynamics are new to me. Forking is easy but there's got to be a central repository to integrate work from many different people. Whoever is the most active would serve as that central repository, and such is the democratic nature of open source. If there are no plans to merge back to the origin d2x I totally support your decision. I think d2xl can carry the banner going forward. The foundation is very solid with the whole thing on docker and CI. To the user d2xl is the go-to source for Wii Mini, and I am adding work that is of interest to some Wii U owners. It does not need to be d2x's replacement or successor, it just needs to offer a compelling alternative to certain classes of users. I have no ambition to expand my cIOS work any work further, but I believe what we have in hand is useful and deserve a release if sufficiently tested. Progress will be slow and work will be sparse, but I think that will be fine.