Access NitroFS when launched from DSi Menu (via HiyaCFW) or 3DS Menu

[Dionicio3]

I'm trying to write some software that accesses files from NitroFS. When trying to test on my DSi or 3DS, I'm unable to access NitroFS unless I launch it through a standard argv environment, which the DSi/3DS Menu obviously doesn't support. Am I just missing an easy way to do this, or does an easy way not currently exist?

[lifehackerhansol]

I believe the core issue is that NAND access is unsupported; otherwise, one should be able to resolve the path as an argument to nitroFSInit().

NAND writing is definitely bad (especially on DSi), but I don't think NAND reading would be too harmful to add.

Of course, would like some opinions on that matter.

[asiekierka]

I've been thinking about this for a while now.

On one hand, it is indeed not too difficult to add. It's just hooking up FatFS to a slightly different layout while making use of the AES engine, IIRC. One could also parse argv[0] from the DSi Launcher structure to make it work seamlessly.

On another hand, it encourages putting homebrew on the DSi NAND, which is - in my opinion - not a good thing to encourage. After all, the homebrew has to be written there first. It also means everyone has to pay the RAM/codesize cost of those implementations.

All in all, I'm not exactly willing to prioritize work on this.

[profi200]

Just a little hint if you decide to implement access to eMMC partitions. The IV for decryption is generated from the eMMC CID and for simplicity my driver converts it into mixed endian (word order is big but the individual words are little endian). However Nintendo uses the raw CID layout as TMIO spits it out. To convert back you can do this:

rawCid[0] = cid[3]>>8 | cid[2]<<24;
rawCid[1] = cid[2]>>8 | cid[1]<<24;
rawCid[2] = cid[1]>>8 | cid[0]<<24;
rawCid[3] = cid[0]>>8;

Should save you some time to figure out decryption.

[AntonioND]

I agree with @asiekierka on this one. This request feels like a bad idea to me.

[lifehackerhansol]

How about on TWL_FIRM?

It's not uncommon for many homebrew projects to be packaged as CIA. There are likely going to be developers who want to support an installation like that (I'd do that personally, only on 3DS though), and it would be hundreds of times safer than with a DSi. (it would also save boot time, since rebooting to DSi mode takes like 2 decades only to get into a menu where you boot yet another thing.)

Just throwing out ideas where read-only NAND functions would be useful.

[Dionicio3]

Yeah, TWL_FIRM is one of the main things I'm thinking about. On the topic of the original issue, I was moreso thinking of when it's installed to SDNAND, not the DSi's actual NAND

[lifehackerhansol]

Yeah, TWL_FIRM is one of the main things I'm thinking about. On the topic of the original issue, I was moreso thinking of when it's installed to SDNAND, not the DSi's actual NAND

If it's SDNAND, then you should be able to estimate the path by checking your ROM header's titleid and work it out via sd:/title/%08x/%08x/content/000000%02x.app, and pass that into nitroFSInit() as an argument.

[AntonioND]

I think one of the reasons for having NAND FS support is that it would allow us to have a NAND browser or similar. While I agree that it's niche, it's still nice to have. If the cost of adding this support isn't too high, I think it would be nice to have, yeah.