Luma3ds: Luma ignores config.bin in CTRNAND

Created on 15 Nov 2016  路  8Comments  路  Source: LumaTeam/Luma3DS

Copied arm9loaderhax.bin to CTRNAND, also created config in rw/luma/config.bin. But once inserted an SD card, even thought there is no luma folder nor arm9loaderhax.bin in the SD card, still, Luma ignores the config.bin already saved and set in rw/luma/config.bin and tries to create a new config.bin in the SD card.

This behavior stops when there is a config.bin in the SD card. But this is an unwanted behavior as there was already a config.bin in CTRNAND. Luma should not ignores that.

Preferably Luma adds an option to choose default CTRNAND config.bin if it exists, otherwise falls back to SD card or visa versa.

invalid

Most helpful comment

Given that users won't update their CTRNAND arm9loaderhax.bin payload as much as often as on their SD card, the config.bin from CTRNAND will be incompatible with sd:/arm9loaderhax.bin.

Therefore, both instances of Luma3DS need to use separate config.bin files.

All 8 comments

I can't detect if Luma was booted off CTRNAND or SD, and going back and forth from SD and NAND would mess up the code.

You shouldn't need to. If config.bin is not in ctrnand, then load from SD. Period. Even if an SD is present.

Basically, I don't see why loading config from ctrnand isn't the default, if present...

What about a key that lets you save the config to NAND?

What I mean is: mount ctrnand -> change main dir to ctrnand:/rw/luma -> look for config.bin -> if it exists, stop. Else mount SD -> if it fails, go back to ctrnand again to create the folder, else change main dir to sd:/luma -> look for config.bin -> if it succeeds, stop. Else create it.

This is a mess, let's add to it that the luma folder is not just used for config.bin but for a lot of other files and payloads and I can't mix SD and CTRNAND files.
People would start complaining about not finding the luma folder to copy a payload to on SD after following the guide, which has them creating config.bin on ctrnand too, and they would have to delete the ctrnand folder in order to have luma recreate the SD folder.

I think the current way things work is way better.

Given that users won't update their CTRNAND arm9loaderhax.bin payload as much as often as on their SD card, the config.bin from CTRNAND will be incompatible with sd:/arm9loaderhax.bin.

Therefore, both instances of Luma3DS need to use separate config.bin files.

by "a lacking feature", i think you mean "a pseudo-feature that only a minority wants and that isn't much of use and pretty much of an hassle to implement".
having two different builds just makes things more complicated to use; which clearly is against Luma's concept.
whereas i can still understand why you would boot a payload from ctrnand, i clearly don't understand why you don't want a simple folder on your sd card. this just makes everything more risky, and that's pretty pointless too. it makes things more complicated for everyone for little to no gain.

also, doing a fork is a thing. maintaining it is another thing. you're going to lose more than you are going to gain by doing so.

Would it be possible to add a way of saving the config to NAND without taking out the SD card that wouldn't clutter the code?

I just forked a9lh and luma to try and deal with this issue.
By setting a flag with a9lh before luma is loaded, it is possible for luma to know where it was booted from, and to have 2 seperate configs, one for the luma on NAND, one for the one on SD.

Was this page helpful?
0 / 5 - 0 ratings