With the launch of the Nintendo Switch 2 today, one of the first things homebrew enthusiasts set out to do was see if the MIG Switch flashcart would work on the console. Prior to release, retailers of the flashcart were claiming that it worked with the Switch 2, but thanks to the efforts of users on GBAtemp, it appears that it in fact does not work. Beginning with the post in this thread, here, with a photo of a Switch 2 and MIG Switch resulting in an error code. Whether or not there is a workaround or fix is uncertain. Furthermore, a MIG Switch retailer posted about having a Switch 2 unit a month ahead of launch, stating that the unit worked, with what appear to be misleading claims. The potentially shady practices shown here.

Source

 

[Inaki]

Right, I did see that, I was just clarifying that either way, you still need a hardware revision. In the case of the MIG Switch hitting that 180-190 MB/s, or the absolute 250 MB/s max, I don't foresee that happening. The thing about standards, you generally can't just use whatever you want when you design hardware, otherwise so many people would be using high end standards, probably where it isn't necessary anyways. There are restrictions, legal shenanigans, etc. when using certain standards. exFAT for example was created by Microsoft and introduced way back in 2006, yet if you were alive and used so many different devices that sported SD cards over, you will have noticed that a lot of them didn't allow for exFAT standards, at the very most FAT32. Some standards have restrictions that make their integration into devices like the MIG Switch, to be a bit of a pain to exist. I don't think Microsoft wants to associate their technologies with something that while not intended for piracy, obviously has a big enough reputation of being misused for piracy, it's enough to make any company reasonably turn away or refuse the usage of their stuff. There have been weird half baked attempts to incorporate exFAT in the past with some devices out there, but those outcomes generally ended with very wonky support for software. Good chance my knowledge is outdated now, I don't know if Microsoft is lax about their exFAT standards now, but if so, then hey, maybe a possibility. I do recall a lot of restrictions back in the day though.

But the pinout being the same, if the MiG Switch can internally work faster, a fw update may be enough. People did do tests with faster microSDs in the past and saw no difference in cart access, so that means at least a fw update would be required, I mean, just using a faster UHS-I card is not enough; but there's a chance, if nintendo is detecting MiG Switch by measuring speed, that is, that a fw update may make the linker work faster and fast enough to mimic real Switch 1 carts...

Again, we are playing around with "wishful" ideas here, nothing more.

I know about licensing and IP core inclusions and such, yes, but that, well... these are very obscure/already in the illegal side electronics and developers, let's say. I mean, if such a "software" or FPGA IP exists, they could easily use it.
NOTE: exFAT was made public/free by Microsoft recently, IIRC.
EDIT: yes > https://opensource.microsoft.com/blog/2019/08/28/exfat-linux-kernel/

 

[DeadSkullzJr]

But the pinout being the same, if the MiG Switch can internally work faster, a fw update may be enough. People did do tests with fasters microSDs in the past and saw no difference in cart access, so that means at least a fw update would be required, I mean, just using a faster UHS-I card is not enough; but there's a chance, if nintendo is detecting MiG Switch by measuring speed, that is, that a fw update may make the linker work faster and fast enough to mimic real Switch 1 carts...

Again, we are playing around with "wishful" ideas here, nothing more.

I know about licensing and IP core inclusions and such, yes, but that, well... these are very obscure/already in the illegal side electronics and developers, let's say. I mean, if such a "software" or FPGA IP exists, they could easily use it.
NOTE: exFAT was made public/free by Microsoft recently, IIRC.
EDIT: yes > https://opensource.microsoft.com/blog/2019/08/28/exfat-linux-kernel/

Using a UHS-II card to get the max UHS-I speed is kind of illogical though, especially considering the limitation at that point boils down to the I/O limitations and what it allows for. That would be like me using a PCI-E 4.0 NVMe SSD inside of a PCI-E 3.0 slot. It literally offers no benefits over just buying the model rated for the hardware in question. Just because it's a UHS-II or Express microSD card doesn't mean that it's basically capped 100% at the maximum limit, that's not how I/O communication works. It would perform at the exact same ratio as a standard UHS-I card in backwards compatibility mode. If there even is a difference, it's negligible.

 

[Inaki]

Using a UHS-II card to get the max UHS-I speed is kind of illogical though, especially considering the limitation at that point boils down to the I/O limitations and what it allows for. That would be like me using a PCI-E 4.0 NVMe SSD inside of a PCI-E 3.0 slot. It literally offers no benefits over just buying the model rated for the hardware in question. Just because it's a UHS-II or Express microSD card doesn't mean that it's basically capped 100% at the maximum limit, that's not how I/O communication works. It would perform at the exact same ratio as a standard UHS-I card. If there even is a difference, it's negligible.

Well, but the thing is UHS-I can do 250MB/s read ( 180-190MB/s sustained in practice ). Now the thing is MiG Switch team being able to make use of that speed with a fw update or not. I mean, physically it seems possible as it is, it depends on the microcontroller/FPGA/whatever their chipset has, is it able to use the microSD slot and provide 180-190MB/s speeds to the outside or in the cartridge interface ?

btw, again, it seems the Switch 1 cartridge slot was limited to 90MB/s, the [Switch 1 carts being capable of more speed than what the Switch 1 cartridge reader can reach] is the key point in the speculation here, if that's not the case then I am talking bullshit here it could be any other type of challenges or quirk-checking...

 

[DeadSkullzJr]

Well, but the thing is UHS-I can do 250MB/s read ( 180-190MB/s sustained in practice ). Now the thing is MiG Switch team being able to make use of that speed with a fw update or not. I mean, physically it seems possible as it is, it depends on the microcontroller/FPGA/whatever their chipset has, is it able to use the microSD slot and provide 180-190MB/s speeds to the outside or in the cartridge interface ?

btw, again, it seems the Switch 1 cartridge slot was limited to 90MB/s, the Switch 1 carts being capable of more speed than what the Switch 1 cartridge reader is the key point in the speculation here, if that's not the case then I am talking bullshit here it could be any other type of challenges or quirk-checking...

Software updates aren't always guaranteed to fix the issue though, because not all pieces of hardware have the capabilities to communicate the way you want them to. If this was the case, then every device running a microSD card should be exFAT, SDXC, SDUC, etc.. capable with as many partition format standards available through a software update. But this isn't the case, let's just take the New Nintendo 3DS for example, it's limited to FAT32, natively supports up to 32 GB. You can obviously use partition sizes higher than that, but the I/O will struggle the higher you go because the hardware was never designed for such sizes. A firmware update isn't going to make that SD slot become exFAT capable, because the hardware I/O has zero capabilities to interpret that partition format at all. Software can't just make it understand the formatting. You would not only need a hardware revision, but you would also need to revise the system software to account for that change too. In the case of systems like the Nintendo Switch, where they didn't start out with the microSD card capabilities we see today, the only reason a system update worked for that was because the hardware I/O was more than capable of handling the change already, the system software just wasn't designed to take full advantage of that change until an update came. Had it not been for the hardware they used, that software update would have been just another generic bug fix update.

Correct me if I'm wrong though, anyone please.

 

[Inaki]

Software updates aren't always guaranteed to fix the issue though, because not all pieces of hardware have the capabilities to communicate the way you want them to. If this was the case, then every device running a microSD card should be exFAT, SDXC, SDUC, etc.. capable with as many partition format standards available through a software update. But this isn't the case, let's just take the New Nintendo 3DS for example, it's limited to FAT32, natively supports up to 32 GB. You can obviously use partition sizes higher than that, but the I/O will struggle the higher you go because the hardware was never designed for such sizes. A firmware update isn't going to make that SD slot become exFAT capable, because the hardware I/O has zero capabilities to interpret that partition format at all. Software can't just make it understand the formatting. You would not only need a hardware revision, but you would also need to revise the system software to account for that change too. In the case of systems like the Nintendo Switch, where they didn't start out with the microSD card capabilities we see today, the only reason a system update worked for that was because the hardware I/O was more than capable of handling the change already, the system software just wasn't designed to take full advantage of that change until an update came. Had it not been for the hardware they used, that software update would have been just another generic bug fix update.

Correct me if I'm wrong though, anyone please.

AFAIK, internal format management is done in software, adding a new format is a matter of adding a driver. Now, this driver may be in software in a microcontroller or, less probably in an FPGA. For the Switch, remember FAT32 and exFAT support were just part of the drivers found in the firmware, ARM64 code, basically.

If pinouts, contacts and buses support it and if the protocolary part is in an FPGA or a microcontroller, and it fits, those things are then only limited by speed/bandwidth and memory/flash space. Work with filesystems is 99% of the time software based, block based storage device access is the one at hardware level.

 

[Valwinz]

i can confirm the R4 does no work

 

[master801]

Just to point out, Microsoft released exFAT's specifications freely so it could be integrated into the Linux kernel (one of the prerequisites for integration is no closed-source code.)

Not patent-free.

https://opensource.microsoft.com/blog/2019/08/28/exfat-linux-kernel/

https://www.microsoft.com/en-us/legal/intellectualproperty/tech-licensing/programs

Also, I seriously doubt the microcontroller they stuck on is even capable of such speeds, let alone to FPGA by itself. You'd need on-board DRAM for such speeds, which it doesn't.

 

[DeadSkullzJr]

AFAIK, internal format management is done in software, adding a new format is a matter of adding a driver. Now, this driver may be in software in a microcontroller or, less probably in an FPGA. For the Switch, remember FAT32 and exFAT support were just part of the drivers found in the firmware, ARM64 code, basically.

If pinouts, contacts and buses support it and if the protocolary part is in an FPGA or a microcontroller, and it fits, those things are then only limited by speed/bandwidth and memory/flash space. Work with filesystems is 99% of the time software based, block based storage device access is the one at hardware level.

But this seems to imply that I can make an early 2000s microSD (non-HC) device compliant with an SDHC card, or make a console understand 4 TB or more of storage with the appropriate partition format, all through software, without issues. This doesn't sound right because we would have had way more support for so many devices up to this point if this was true. Drivers from what I understand are hardware dependent, which means no amount of software will be able to fabricate features and general capabilities that the hardware isn't truly capable of handling.

Post automatically merged: Jun 5, 2025

Just to point out, Microsoft released exFAT's specifications freely so it could be integrated into the Linux kernel (one of the prerequisites for integration is no closed-source code.)

Not patent-free.

https://opensource.microsoft.com/blog/2019/08/28/exfat-linux-kernel/

https://www.microsoft.com/en-us/legal/intellectualproperty/tech-licensing/programs

Also, I seriously doubt the microcontroller they stuck on is even capable of such speeds, let alone to FPGA by itself. You'd need on-board DRAM for such speeds, which it doesn't.

Thanks for the heads up.

 

[Inaki]

But this seems to imply that I can make an early 2000s microSD (non-HC) device compliant with an SDHC card, or make a console understand 4 TB or more of storage with the appropriate partition format, all through software, without issues. This doesn't sound right because we would have had way more support for so many devices up to this point if this was true. Drivers from what I understand are hardware dependent, which means no amount of software will be able to fabricate features and general capabilities that the hardware isn't truly capable of handling.

Post automatically merged: Jun 5, 2025

Thanks for the heads up.

There have been devices that got SDHC/SDXC capability after initial launch and via fw update. It depends on several factors, sure. Speed, RAM space, flash storage space for a bigger fw, physically having the same access to the interface or the interface being the same. I am not saying this is the case with MiG Switch, I am always saying IF they can or IF the device has these factors in place...

 

[cearp]

What is funny, is that Nintendo had to buy a mig switch in order to test that it's blocked.

I guess they could bump up the checks and succeed in blocking it, but it would be pretty embarrassing if it happened to still work.
So I bet they must have bought one to test

 

[DeadSkullzJr]

What is funny, is that Nintendo had to buy a mig switch in order to test that it's blocked.

I guess they could bump up the checks and succeed in blocking it, but it would be pretty embarrassing if it happened to still work.
So I bet they must have bought one to test

This assumes that it's blocked and isn't a compatibility layer issue or something along the lines. There's no certainty of what's causing it not to work yet.

 

[cearp]

This assumes that it's blocked and isn't a compatibility layer issue or something along the lines. There's no certainty of what's causing it not to work yet.

Ok interesting, thanks.
I'm not ruling out a mig flash update though, I won't be shocked if they eventually make it work.
I don't have a mig flash so I'm not waiting thankfully.

 

[DeadSkullzJr]

There have been devices that got SDHC/SDXC capability after initial launch and via fw update. It depends on several factors, sure. Speed, RAM space, flash storage space for a bigger fw, physically having the same access to the interface or the interface being the same. I am not saying this is the case with MiG Switch, I am always saying IF they can or IF the device has these factors in place...

Right, that's why I brought up the Nintendo Switch, it's a prime example of a system that allowed more SD capabilities through a firmware update. BUT, it was only because the hardware for said features was already there. Take the hardware out, that firmware update would have been just another bug fix update or something.

Post automatically merged: Jun 5, 2025

Ok interesting, thanks.
I'm not ruling out a mig flash update though, I won't be shocked if they eventually make it work.
I don't have a mig flash so I'm not waiting thankfully.

I'm sure they'll figure a way around it. If I'm being honest though, the more I think about it, even if I got a Nintendo Switch 2, I don't think I would play original Nintendo Switch games on it realistically. I mean maybe I would for the games that got free updates and such, but the idea of trading native hardware support through an original model Switch for software compatibility layering is.... kind of yucky in my mind. I've played with a few platforms already that have that sort of dependency, and it never is just as good as the native deal during my tests. Some cases you actually lose capabilities for odd reasons.

 

[Inaki]

Right, that's why I brought up the Nintendo Switch, it's a prime example of a system that allowed more SD capabilities through a firmware update. BUT, it was only because the hardware for said features was already there. Take the hardware out, that firmware update would have been just another bug fix update or something.

Post automatically merged: Jun 5, 2025

I'm sure they'll figure a way around it. If I'm being honest though, the more I think about it, even if I got a Nintendo Switch 2, I don't think I would play original Nintendo Switch games on it realistically. I mean maybe I would for the games that got free updates and such, but the idea of trading native hardware support through an original model Switch for software compatibility layering is.... kind of yucky in my mind. I've played with a few platforms already that have that sort of dependency, and it never is just as good as the native deal during my tests. Some cases you actually lose capabilities for odd reasons.

In the end, it would be like doubling the speed they have now, we shall see, who knows.

On the way you see the Switch 2... I am kinda there with you. Apart from other reasons about why the Switch 2 doesn't look as appealing as Switch 1 did ( some months after launch, admittedly, but even launch time was more appealing I think ).

But it is also true that last gen and current gen, both, in the x86 consoles and in the ARM based Switch, they have gone the software way, so to say, mid hardware compatibility, mid API layer compatibility ( mostly for GPU, but not just GPU, but also the higher level usage layer, like actually transforming the calls to way more than mere substitutions, more like what Wii-U and Switch emulators do, like higher level emulation for graphics ) and this makes it more natural to use these kind of transformations and upgrades, so I don't know, it makes sense, I guess.

 

[designgears]

I have the V2 Mig Flash (with the button), proper dumps of my actual cartridges with mig dumper. I tried on the initial firmware and the day 1 firmware, neither one worked... as expected based on others videos. Not surprised in the slightest, that reseller spamming that it worked was an obvious grift.

I am curious to how they're detecting it. Disc jitter from Xbox 360 days comes to mind as one of the clever ways they were doing such detection.

It could be as simple as power draw, read/write speeds, or they know the flash cart will respond to certain things an official cart won't, etc.

 

[impeeza]

or they know the flash cart will respond to certain things an official cart won't,

I decant for this but that can be corrected on Switch 1 also with a LOTUS firmware update, so why they didn't do it also on SW1?

 

[Exnor]

My Sky3DS does not work... Then again, i don't have a Switch 2, so.

 

[designgears]

I decant for this but that can be corrected on Switch 1 also with a LOTUS firmware update, so why they didn't do it also on SW1?

That's a good question; they could have implemented several things to hinder custom firmware and the like and never did.

 

[console]

Because Nintendo company did quiet add extra security layers in Nintendo Switch 2 to make harder for MIG flashcart to prevent working and will not play games.

MIG v2 flashcart with added security layers should help to make working on Nintendo Switch 2.

There are more news upcoming.

 

[FluffyLunamoth]

What is funny, is that Nintendo had to buy a mig switch in order to test that it's blocked.

I guess they could bump up the checks and succeed in blocking it, but it would be pretty embarrassing if it happened to still work.
So I bet they must have bought one to test

No, no it doesn't. It means they blocked whatever thing MIG is using, or they changed the way the games are loading.