Ok, so it failed on the first try this time:If it was without dblerror fix, it is posibly hang on error reading before interface boot.
Ok, so it failed on the first try this time:If it was without dblerror fix, it is posibly hang on error reading before interface boot.
00035344 534C3634Good. I actually mixed up CID with CSD. So we have now your SD card CSD, now you can get the next commit where CID and CSD are in place so we cold see CID also.
Thanks!00035344 534C3634
47800360 AC3000EA
BTW, have you made EmuNAND dump/restore cycle somehow?Thanks!
Do you feel it is dumping a bit more stable, since there was several successfully. Or more looks like random?
It's random I think. I mean, the first couple of builds I tested yesterday, One failed on the third dump, the other failed on the fifth. The last 2 builds I tested when I was trying to get the CID and CSD, they both crashed on the first time. It does work sometimes though opposed to not working at all. That's an improvement I supposeThanks!
Do you feel it is dumping a bit more stable, since there was several successfully. Or more looks like random?
--------------------- MERGED ---------------------------
BTW, have you made EmuNAND dump/restore cycle somehow?
UPD: according to CID you have Sandisk 64GB card, is this right?
Well, stable means it works everytime, but this isn't the case.. So I'm not sure about the stable definition here. I can only say that it has improved lolSo we could say the last commits with card detect pullup fix is definitely stable since before that u derrun occurs always at half NAND dump?
Not as far as I remember. However, I installed a9lh about 11 months ago. 3 months after that, I was bricked due to a stupid user error, which is fixed now. Them I was away for around for 4 months with my main 3ds while this one was at home. I only came back last month, and haven't touched this 3ds for anything except for these testing.As for dump/restore EmuNAND, I meant have you done this recently just to ensure the data area of the EmuNAND is updated and there is no unstable sectors.
I recommend to do so, it should not fail in case of a working card and if card is dyiing you won't be surprised suddenlyif it fails in future.
Transferred to 64GB microSDXC, restored EmuNAND and dumped 5 times - no issues.So with the exception of the 3 months after a9lh installation (which required emunand back up and restore) I haven't touched the 3ds
That's good to hear, though I anticipate future problems with users.Transferred to 64GB microSDXC, restored EmuNAND and dumped 5 times - no issues.
So I recommend you to refresh emunand by dump/restore cycle with any way you prefere - D9 or emunandtool.
Yes, just backup/ restore emunand and try to dump once more.That's good to hear, though I anticipate future problems with users.
So, just back up with d9, then restore? Then try latest commit?
Well, I just dumped emunand and restored it with D9.. Then tried to dump emunand with rxTools, and it crashed with the diagnostic msg again..Yes, just backup/ restore emunand and try to dump once more.
At least we have a safe guard now, since in the default libriary which all is using all sdcard errors are just ignored
Well, I just dumped emunand and restored it with D9.. Then tried to dump emunand with rxTools, and it crashed with the diagnostic msg again..
It's worth noting that since the msg was added (after the issue of the error not appearing was fixed) it has been failing from the first try everytime.
Whether that's a coincidence or not, I don't know..
I am trying the latest build on my main 3ds. Like I said, I didn't want to touch this 3ds, but a dump wouldn't hurt.Nope, there was nothin added besides the actual text message. The only thing to play with is dblerror, on which depends how many retries will be handled before error reported.
I am trying the latest build on my main 3ds. Like I said, I didn't want to touch this 3ds, but a dump wouldn't hurt.
4 dumps so far, no errors. Fast as well. Didn't time the first run, 4.24 minutes on the second run, 4.23 on the third run, 4.22 on the fourth run
This 3ds is o3ds (Zelda ocarina of time edition) using the samsung Evo card (64gb), while the 3ds I have been using was o3ds XL (red super smash one) with the sandisk (64gb)
Edit: just to add some info on the past stuff we discussed:
- pasta mode also doesn't work here
- with the initial set up, It decrypted firmware in first boot, and extracted font on second boot, just like my other 3ds. So both of my 3ds's are doing that
Sadly my tests will still have to continue on this sandisk card. Like I said, I didn't want to touch the other 3dsSo don't touch Sandisk card until we didn't make a workaround to handle the issue
Pasta mode is a weird thing, anyway will be fixed as soon as we got someone who is ready to tuch CFW subsystem. We'll have a customized patching and pasta mode is just a sigchecked sysnand.
Can you check one time with only decrypted firmware removed and only font file removed. You will see the progress bar changes differently and identify it on clean install.
Or just make a of clean install, I just can't imagine how the progress could be reversed
No!I'm confused about the last part, remove what and keep what? And what do you mean by a clean install? Isn't what I'm doing everytime a clean install?
It happened exactly like expectedNo!
1st try: remove font but keep firmware, on boot you'll see a progress of font extraction
2nd try: remove decrypted firmware files but keep font file, on boot you'll see a progress of firmware extraction (with caption and percents)
Notice the steps and speed, that's the only way for now to sence the difference between those two processes.
This is font extraction, since firmware exists in this case!It happened exactly like expected
1st try: extracted firmware, like it always does for me, since it always decrypts firm for me on first boot and extracts font on second boot
Oops, yes I meant extracted font.This is font extraction, since firmware exists in this case!
But in both cases opened menu after progress bar?Oops, yes I meant extracted font.