So let me get this strait. We need to insall an additional hack ontop of Aroma, this ISFShax? I thought that was a hack that was mostly used to unbrick some machines and was mostly for, wii U techs for lack of a better term. We couldn't use this plugin with just vanilla Aroma?
Just because we use ISFShax for redNAND and brick protection, doesn't mean we can't use it for more things. Maybe in the future it will also become the way to launch Aroma instead of FailST, we will see...
Aroma is mostly about the PPC side of things. It does some IOSU patches in the mocha module, but all in all it doesn't have great facilities to do IOSU (the ARM side) patches, especially if they become more complex. There is basically no way to do these patches in a nice way in aroma as a plugin. They would need to be be integrated into mocha (which would be possible, but still annoying to do).
Stroopwafel on the other hand makes IOSU patching very easy and has a plugin system for that, so that's what I chose. There are multiple ways of launching stroopwafel, ISFShax is just the most convenient way for a permanent setup. Also this was just more of an experiment to test out some facilities in stroopwafel and a new mechanic of implementing redNAND and to see if it was really as easy as it seemed. The redNAND included in the latest stroopwafel works very similar to this plugin.
how does this compare with rednand? I assume same performance?
It's basically the same, just with a different target device type. There are a few more subtle differences, but the performance relevant path is basically the same.
To better illustrate the performance impact, this is all the code that is added to the critical path, that is executed once per r/w operation:
C:
static int read_wrapper(void *device_handle, u32 lba_hi, u32 lba, u32 blkCount, u32 blockSize, void *buf, void *cb, void* cb_ctx){
return real_read(device_handle, lba_hi, lba + sdusb_offset, blkCount, blockSize, buf, cb, cb_ctx);
}
static int write_wrapper(void *device_handle, u32 lba_hi, u32 lba, u32 blkCount, u32 blockSize, void *buf, void *cb, void* cb_ctx){
return real_write(device_handle, lba_hi, lba + sdusb_offset, blkCount, blockSize, buf, cb, cb_ctx);
}
static void crypto_hook(trampoline_state *state){
static u32 usb_crypto_handle = 0;
if(state->r[5] == sdusb_size){
if(learn_usb_crypto_handle){
learn_usb_crypto_handle = false;
usb_crypto_handle = state->r[0];
debug_printf("%s: learned mlc crypto handle: 0x%X\n", MODULE_NAME, usb_crypto_handle);
}
if(usb_crypto_handle == state->r[0]){
state->r[0] = NO_CRYPTO_HANDLE;
}
}
}
You can also mount the MLC partition of a redNAND as USB on the sysNAND using SDUSB
If you find a HDD, which exposes 4k sectors (compared to the standard 512B) you could theoretically go up to 16TB. I connected a 10TB 4kn drive and formatted it. In the log I could see that it was detected and formatted with the full 10TB. The Data Management showd it only with 2TB tough, but NUSspli detected it with the full capacity.
Maybe I could make a plugin to emulate 4k sectors on a 512byte sector drive.
Striping over two drives would also be interesting for performance, since then two USB ports could be utilized simoustanously. Already thought about doing that with the SDcard and the eMMC, but that is way down the prio list... Maybe if I feel like it one day....
Why are people using an emuNAND/redNAND on the Wii U
I think most redNAND users use it to work around a bad eMMC. But before SDUSB that was also a way to use the SD for game storage, since you could basically have an arbitary size Internal sorage with that. Also the write perofrmance on redNAND is better than the internal memory (because on redNAND SCFM is usally disabled). Also maybe having a second test system could be useful to some people. And if you have multiple Wii Us in different locations you can take your system with you on the SD.
Is there any chance to also achieve this as part of the vWii HDD?
If we could have a big HDD with a FAT32 partition for homebrew and vWii stuff and another primary NTFS partition (of up to 2 TB) that then can be used to be formatted into the Wii U format, that'd be great.
I was expecting this question. I have thought about this, but I want to do other things first. As I already wrote this was more of an experiment.
Also there are a few problems or at least things that need to be considered with this:
- USB inits too late to use it for coldbooting homebrew
- People might want to have a NTFS partition as a real NTFS partition, so another way to mark the partition to use for WFS might be better, but not sure yet.
- I don't really like using USB for the Wii U
Advantage for me is instead of 2 USB drives that I have to physically switch out for my Wii U games and for all my Wii and Wiiware games, I can just keep the vWii drive connected at all times and with all my Wii U games being loaded on the second partition of my SD card. Hell, now I can migrate all of my emulator and Nintendont games from my SD card to the vWii drive that still has plenty of space, freeing up space for Wii U games on the SD card.
Why don't you just put all the Wii / GC games on the SD card and the Wii U games on USB? Also VC injectes might be an option? I don't really get why people have these two HDD setups. (OK it made sense in the past when larger SD cards where expensive and we didn't know how to do VC injects, but today?)
Very useful. But isn't it going to wear out the SD card quickly? The Wii U supposedly hammers USB drives with writes constantly.
I second that. I never saw any evidence for that other than "ohh my cheapo flash drive died". I used a SATA SSD as MLC (which should get even more access than USB, since the system runs from it) and I couldn't get the SMART counters for the wear (GB written, total flash writes, max write count) to nuge in over 6h of playing MK8 and a little of other games. Of course other games might write more or less, but honestly there isn't much going on, the system is pretty simple, most will just be saves.
I might put some instrumentation in to collect some more precise statistics...
The main reason USB flash drives aren't recommended isn't because they're unreliable (although they certainly are), limited number of write cycles is an inherent flaw of flash storage and that is just as true for SD cards.
And flash gets also used in SSDs, which run Windows and also as storage in datacenters which hammer them with Terabytes each day. It's about what kind of flash gets used, which quality it has and how it is managed.
SSDs usally get the best flash, if it is too bad for that, it might go to SD cards, if it is too bad for that it might go into a flash drive, if it is to bad for that, they scrape their names of the package and it goes into some other flash drive. You get the idea...
It is expected for most flash drives that they die and that might happen while it is plugged into a Wii U or while you stand in front of the room and want to open your presentation.
And of course there are enough bad SD cards. That's why I recommended using the endurance branded one. There Sandisk and Samsung actually give numbers for how man TBW it should last and there I have more confidence that they did their due diligence and implemented proper wear leveling, which might not be true for all SD cards.
I would be interested in this. I probably wouldn't use a USB HDD (they're slower than SD cards), but external SSDs are pretty cheap, and the speed advantage can't be overlooked.
Both are limited by USB in terms of thoughput. The only advantage a SSD might give you on the Wii U would be the access time. I didn't find that it makes a hughe difference, even if it is connected directly via SATA internally (instead of USB).
I think it's probably more difficult to do it with USB, because the Wii U wants complete control over any USB drive it sees, but normally ignores the SD card (in Wii U mode)
To take away its stranglehold over USB drives, we first need to patch out the existing USB drive detection (so it won't ask to format anything inserted that is not what the Wii U expects) and r/w routines, only to then reimplement all of it to work with drives that are partitioned differently.
Nah it's much simpler. The same approch I use for SDUSB should also work for that. I would just hook where the device gets attached to SAL, clone the structure and change the dev type for the one that should show up as SD and adjust the size and add the offset to the writed and reads for the wfs partition and attach both structures.
the r/w speed on the Wii U's SD reader is not that good
The physical speed is the same as the eMMC (internal Memory). What makes SD access slow on the Wii U, is the not so good FAT32 driver of the Wii U (prfile). But when we use it with SDUSB the USB partion will be in wfs anyway and therefore getting good performance.
So why the high endurance sd is important? I know that it will 'endure' but... theres' something more?
It's just that I have more trust in them that they are not garbage. The manufacturer gives actual numbers for how much writing it can sustain. Of course you should still make backups. Every storage media can suddenly die.
I find one thing very funny...before Tiramisu/Aroma was developed for the Wii U, pretty much nobody cared that the Nand chips were dying. So really...NOBODY really cared.
You might not have cared, but media outlets even back in 2019 seemed to care enough to report on it and even Nintendo cared enough to replace these units. Also the affected users certainly cared.
Or to fix it. In case you haven't noticed, not every existing wii u is affected by this problem.
He talked about the users who were affected, and they were - by definition- affected. Of course we know that not everyone is affected, that's why we check the logs and don't recommend replacement without evidence of a eMMC problem
before Tiramisu/Aroma was developed for the Wii U, pretty much nobody cared that the Nand chips were dying. [..]. Whereby... back then,
users were more likely to “accidentally” brick their consoles by mishandling CBHC xD
Which might also just be a result of your bias, if you are more around people who mod their consoles you are more likely to meat someone which a CBHC brick. The same trap voultar fell for when he asked his followers for 160-0103 consoles. When I bought random consoles with that error off ebay, not one had a CBHC brick, but I got a few with bad eMMC. When some normal user who never modded his console hits that error, he gives Nintendo a call and if they replace it, like they did back then, you won't see it on a modding / homebrew oriented forum.
Also you migh remember the thread on wii-homebrew.com, where you already made a fool of yourself. Yeah I started that in 2020, before Tiramisu was a thing and Haxchi was state of the art. If you search the forums you will also find threads with symptoms of NAND corruption from years ago, before Tiramisu. Just back then no one really understood it or had a solution. You read muche more about it since we have an understanding of the problem and solutions.
Or rather, not to the extent that it's always overdramatized.
Maybe, we don't have statistics on it, do you? We know it's less than a third of the consoles as a high estimate (but probably a good portion lower), but other than that?
Therefore...an emunand is unnecessary for the wii u.
Good thing then that there is no emunand, on the Wii U we only have redNAND. But in case you mean redNAND, I guess there is a good bunch of people which surely have a different opinon about it
And what's more, the rednand on the wii u sucks
Interesting opinion
And just plain wrong. I mean you could argue that the Wii U is slow in general and therefore redNAND is also slow. But if you compare it the internal memory, redNAND is depending on the workload only very slightly faster or up to 2,70 times faster when installing game updates. (MLC only redirection with SCFM disabled, which is the most common and crypto disabled and a fast SD card). Of course you can make it slow, if you just find a slow enough sd card, or put it into 1 bit mode.
So I would be interesting where this statement comes from. I know it's not empirical evidence, so what does make you think it should be slower?
However, I never thought WiiU could reach full 25 MB/s reading speed from SD card.
I always thought it only supported early Class10 SD cards.
25MB/s is the theoretical maximum the bus can do. The same limit applies to the eMMC. That's 4 bit data mode at 50Mhz (it's more like 52Mhz, in reality)
