Slightly unrelated: From what I've heard, people still don't know how to write to eMMC in a stable way (and if that's true, then I suspect that SD writes are equally unstable since they use the same sector writing mechanism). So here some of my findings and ideas:

TimeoutsSome DSi sd/mmc writing functions seem to contain timeout counters (and I had used something similar up to including unlaunch v0.9). I think that timeout handling should be completely removed.First of, the sd/mmc controller is generating its own error flags (including timeouts), and it's better to use that flags instead of using manually generated timeouts (ie. check error flags alongsides with ready flags when reading SD_IRQ_STATUS). With manually generated timeouts things could derail badly (eg. software aborting write while hardware is still trying to finish writing).Second, some writes may be slower than expected (writing to worn-out sectors may be slower, and if the sector dies completely then broken-sector replacement will occur, which will make the write even slower). So, regardless of the timeout mechanism used, the timeout must be large enough for worst-case write timings.Officially, worst case timeout should be somehow computed from the CSD register, but I am just using a fixed setting of SD_CARD_OPTION=40D0h, which should work with all eMMC chip variants used in the DSi (I haven't tried writing anything to 3DS or to SD cards, but I hope 3DS is also fast enough to work with that value, whilst, for external for SD/MMC cards, it might depend on whether it's an old/new slow/fast card). Ah, and for special cases, one might need much larger timeouts (eg. when/if using erase-multiple-sector commands).

Error handlingYeah, to be honest, despite of checking the error flags in SD_IRQ_STATUS, I am not really having an error handler for them - because I think that timeouts and other errors should never happen during normal operation (exceptions would be ejecting an SD card during access, or writing to a totally dead worn-out card, or sending an unsupported command, or using too small values in SD_CARD_OPTION, or the like).Nethertheless, of course it wouldn't be bad to implement some error handling. Though I am unsure what to do best in which situation... A fatal error blue screen would be better than silently ignoring the error. In some cases it might help to retry sending the command a few times, or to prompt the user whether to retry/ignore/cancel, or to re-insert the ejected card. And maybe one might want to try to keep finishing further writes before locking up in fatal error screen. And, one would somehow need to implement showing the prompt's or error messages in the user interface, which may be easy or difficult, depending on how the existing user interface looks like (eg. wheter currently displaying a text screen, or animated graphics layers).Well, and aside from SD_IRQ_STATUS flags (errors spotted by the sd/mmc controller), one should also check flags in CSR register (errors spotted by the sd/mmc storage chip itself). I am not actually doing that either, and I am vaguely remembering that there might be special cases like errors for the current command not being reported until after sending the next command (Nintendo seems to send a separate GET_STATUS command after each READ/WRITE_MULTIPLE command, maybe for that reason).

Restoring eMMC backupsMost important should be comparing the (encrypted) MBR's on sector 0 of the eMMC chip with that from the MMC image, if they don't match up then the MMC image is from a different console, or it's a decrypted image - which would both brick the console.Be sure to support both Samsung 240Mbyte and ST 245.5MByte images, and if there's the 40h-byte no$gba footer appended at the end of the image, omit those last bytes when writing. For 245.5MByte chips: I don't know if existing DSi tools support making a full backup of those chips though.As it'll take some time to write the whole image, it may be extra important to check battery level before starting, and to ignore power button irq during writing, and of course to display some progress bar & ready message.And a special caution related to DSi shop: If the console had never accessed the shop at time when making the eMMC backup, then accessing the shop (creating the dev.kp file), and then restoring the backup (without dev.kp), then the shop is reportedly getting confused, and you can't any longer access the shop from your console (of course, the shop is now mostly closed anyways, and you'd only loose access to the 3DS transfer tool).

Uninstalling unlaunchWell that's the reason why I had wondered about eMMC writing issues at all. The official way to uninstall unlaunch would be truncating the launcher's .tmd file back to 520-byte size, and strip the read-only attributes for both .app and .tmd file (or restore a complete eMMC backup), but there appear to be no tools capable of doing that in a stable fashion yet (apart from hardmods).The reasons why I haven't implemented an uninstall function myself are that it would convert the console back to the useless original state with the health safety touch to continue nag screen. And, my own ASM coded FAT engine is still a bit limited in functionality (it can increase the .tmd filesize with new clusters appended as needed, but it can't yet decrease the filesize and deallocate old clusters, and also can't delete/create files or such things).EDIT: Also see apache's next post. If the console boots up okay with-unlaunch and without-sd-card-inserted, then you can probably safely truncate .tmd to 520-byte size, otherwise you'll carefully need to repair more things about getting an intact and matching launcher .app/.tmd pair. That issues may occur if you had used unlaunch v0.6, or if have somehow tried to upgrade/downgrade/region-change your launcher version.

Last edited by nocash on Tue Aug 14, 2018 8:56 pm, edited 4 times in total.

Another factor about uninstalling Unlaunch could produce unsafe conditions. If Launcher.app was corrupted/swapped out/changed or the first part of the TMD was modified outside of Unlaunch's knowledge. So blindly truncating TMD back without first verifying that the TMD/Launcher pair would be valid would result in a brick from Stage2 rejecting it. Could be mitigated by requiring user provide the valid files needed to restore then rather then trying to fix what's already there.

As for the other issues. I never really thought about the underlying hardware. Thought the software took care of that. But I can see where things could go wrong. I've done a few full nand restores with a modified build of fwtool back when I was testing/working on RocketLauncher. Lack of decent nand tools was why RocketLauncher was never released. One of the only devs able to work on this was busy with other things so it was just held back by that. Anyways, even before reading your notes on this, I stopped using fwtool. Mainly because I don't need to touch nand again. Unlaunch seems perfectly fine installing to it and since it disables white list check, I haven't even gotten around to uninstalling the "RocketLauncher" version of the white list. Though even so, I have no reason to even without Unlaunch as I have no plans on ever changing nand's FW version from 1.4.

I'm wondering how the 3DS arm9 tools work. (stuff like GodMode9/Decrypt9). You should look at them. They use arm9 to handle SD/MMC stuff. (as long as 3DS is kept in CTR mode. Legacy mode switch results in arm9 losing access to SD/MMC and having arm7 handle it like on DSi) I'm curious if those are also coded to handle the things you've mentioned.

Hello! I hope this is the right place -- I didn't really know where else to put this. I'm having trouble with unlaunch and starting the rom cartridge on boot. It doesn't seem to work with my "R4i Gold 3DS Plus" -- it just hangs at a black screen? I'm using a DSi with unlaunch v1.2

Hello, not sure if anybody reported this problem yet: holding A to boot into sysNAND works maybe twice in 10 tries, most of the time it just freezes indefinitely and I have to force power off. This happens on every unlaunch version aside from 0.8, that one works every single time. Everything aside from this works perfectly fine, using HiyaCFW and bootthis.dsi and such. I'm using a 1.4.5E normal-size DSi console, later downgraded to 1.4E but that didn't help. I've dumped the NAND and tried replicating the issue with No$GBA to no avail, emulated it works every single time. Both cameras are working perfectly fine in the DSi camera app.

highmans wrote:

Hello! I hope this is the right place -- I didn't really know where else to put this. I'm having trouble with unlaunch and starting the rom cartridge on boot. It doesn't seem to work with my "R4i Gold 3DS Plus" -- it just hangs at a black screen? I'm using a DSi with unlaunch v1.2

That feature also doesn't work with my R4i Gold 3DS, works fine with the oldest R4 though.

Also new, there's a patreon page for my projects, https://www.patreon.com/martin_korthDon't know if it'll bring in any money, but it would be nice, I am meanwhile totally bankrupt : /

Anyways, other things:

Booting the original launcher via button A works perfectly stable for me. Some older unlaunch versions did completely hang when running launcher on firmware v1.4.5, but then that should have happened always. I've never heard of situations where it's working in 2 of 10 cases.In the new version, you can hold down DPAD UP (together with Button A), that will output some color codes on upper screen, that will give some hint at which bootstage it's hanging. You should see the unlaunch gif for a short moment, then RED blank screen, then BLUE, then GREEN, and finally a WHITE screen (with the original launcher gui appearing).Caution: Please keep DPAD UP pressed all time (the colors are updated only while the button is pressed, if you release it while seeing the RED screen then it'll stay at that color even when reaching the stages where it should show blue/green).

R4i or the like... yeah, I can support them, if somebody buys one of that carts for me.

In the new version, you can hold down DPAD UP (together with Button A), that will output some color codes on upper screen, that will give some hint at which bootstage it's hanging. You should see the unlaunch gif for a short moment, then RED blank screen, then BLUE, then GREEN, and finally a WHITE screen (with the original launcher gui appearing)

Thank you for the quick response! When it hangs, it always does so on the RED screen.

Thank you for the quick response! When it hangs, it always does so on the RED screen.

Okay, that's tracking it down a little. The colors are shown in this order:

- RED shown shortly before restarting stage2 (the code from boot sectors, which should be still residing intact in memory).- stage2 is then doing some initialization and loading the launcher to memory- BLUE shown when patches in stage2 are forwarding further patches to the launcher- GREEN shown when having finished that patching- stage2 is then doing some more stuff and does then actually start the launcher- launcher is then doing a lot more stuff like wifi init and touchscreen init and showing user interface

So well, it does apparently hang while still in stage2 and before starting the launcher. That's a bit unexpected because stage2 doesn't do too many hardware specific things other than loading the launcher files from eMMC, and no firmware specific things other than encountering different filesizes when loading different launcher versions.

Hmmm, yeah, I guess it must be some timing/initialization issue making your console tend to behave a bit differently than others. I could add some CRC check on the stage2 code to make sure that it's really still intact in memory (and reload it from eMMC if needed, just in case it got destroyed somehow when originally triggering the exploit). On the other hand, I could also get rid of using stage2 completely, and instead load the launcher directly on my own - which probably requires only a little bit of testing and adding 1-2 small details to get it working.

Hello nocash, I get this error (v1.0 to 1.4), but I could assure that it is because my camera socket is damaged and that is why it is not detected, will it be possible to fix that in some update? Is this verification so necessary?

With regards to the R4i Gold 3DS -- I could send you mind to test, but I'd prefer to have it back if possible... Is there any information I could dump from the cart and provide you or does it require specialized hardware/software?

Most modern DS flashcarts spoof existing game roms. There's not much you can do in that case. You can either send him the header of the SRL of the rom dump you made from the flashcart or tell him the game/came code so he can find the rom and check it. A full rom dump would most likely not be much different then the actual game it was spoofing. (or a stripped down version of the game with a modified NitroFS section.

It's most likely a hardware issue where the flashcart isn't responding fast enough to certain commands or not quite behaving like a real retail cart in some way. He'll have to have the cart himself to test to find the issue as it's not really something one can test on No$GBA.

Though one idea is to add a debug color system for it much like with 1.4 adding it for testing issues with loading stage2/Launcher. Do one for the cart loader too. it could help maybe debug issues with some carts without having to go out and buy/donate them.

Regarding the carts I have, not sure if this helps or anything, but I did have to disable Secure Area checking in NTR Launcher before my DS-Xtreme would boot. The way the cart is handling that may not be quite up to spec with retail carts so NoCashe's code may be bugging out with it too if it works in any way similar to NitroHax's cart loading code which is what NTR Launcher is currently using. NTR Launcher can't handle any TWL carts though so I wouldn't have any idea why my Cyclo iEvo cart won't boot.

The Secure Area issue being resolved may fix quite a few flashcarts. I recall people reporting a lot of other carts working with NTR Launcher after I made that change to make my DS-X bootable.

Hey, I would just like to ask if you could add a hotkey to boot a file called, let's say bootme.dsi I know that there is already one for bootthis.dsi but Robz8 DSiMenu++ uses that to boot DSiWare, meaning you can't use it for anything else unless you stop using DSiMenu++ or start using .launargv files.

I can confirm that I have exactly the same issue as gabo12 when I hold A button it hangs on unlaunch screen latest release and dsixl 1.4.5e. Had same problem on v0.9. when I hold A and Up button it stays on red too.

Also a weird issue when running DSiware renamed to boothis.dsi on the root of the SD card the games Warioware Touch and Jeckyl and Hyde have no sound yet if I use the normal method to run them through the dsimenu they work absolutely fine. All the House MD games hang with black screen and bgm in endless loop. Again these games work fine with the normal method. I presume this is an issue with Unlaunch as unlaunch is trying to run those ROMs renamed to BOOTTHIS.DSI (I capitalized that because of the pedantic coments)holding X button while console boots. I removed everything of dsimenu++ from my SD card and put only a dsiware ROM renamed to BOOTTHIS.DSI and turned the console on while holding the X button. As I already mentioned those particular games have strange behaviour. All other DSiware ROMs work fine (with sound and no hangs). I posted this as a bug report because it obviously is something of a bug and you invite everyone to comment using this forum or email you. Oh well won't be bothering any more. Good luck with your project.

Last edited by Sion.zaphod on Sat Aug 25, 2018 8:38 pm, edited 1 time in total.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum