Hacking [Pre-release, WIP] Yet another rxTools?

[duke_srg]

Sure yeah will do 7 tests later tonight

I hope you have Class10 card, since with the latest changes it may have noticeable advantage over Class6 or below. Though most branded Class6 may be boosted too, since they're actually have better specs than class requires.

 

[Madridi]

I hope you have Class10 card, since with the latest changes it may have noticeable advantage over Class6 or below. Though most branded Class6 may be boosted too, since they're actually have better specs than class requires.

Yeah don't worry about that. These are the 2 types of cards that I have. Both are class 10:
https://www.amazon.com/Samsung-Clas...=UTF8&qid=1486724345&sr=1-5&keywords=Micro+sd

https://www.amazon.com/SanDisk-Ultr...=UTF8&qid=1486724411&sr=1-4&keywords=Micro+sd

The 3ds I will be doing the tests on will have the samsung one.

That being said, is it a possibility that we will see a performance difference in n3ds vs o3ds? Because I'll be using o3ds btw

 

[duke_srg]

That being said, is it a possibility that we will see a performance difference in n3ds vs o3ds? Because I'll be using o3ds btw

The controller mode used is just the same as was in DSi, so should be no difference between O3DS and N3DS in this case. Unless it is internally faster in N3DS.

Upd: updated branch with final SD/MMC driver improvements and progress bar flicker bug fixed. Will be a bit comfortable to work with.
Also checked EmuNAND dump speed, looks like over 7MB/s combined read/write, which is very good comparing ~8MB/s limit in this mode and two times slower with the default implementation.

 

[Madridi]

@duke_srg

Sorry, hadn't had the time to test yesterday.
So I just started a while ago, and unfortunately, it's failing from the first test.

So, I build the dev-a9lh branch, loaded it through the browser, and let it do the initial set up and everything (which worked without a problem)..
I reset the console just to make sure the set up was completed, then I proceeded to dump sysnand, and about 30 second in, I got an error screen.

So I thought maybe it was a fluke. I tried again, this time, about 4 and a half minutes in, I got the same screen. So I took a picture of it:

Spoiler: Error

Pressing any button would make the screen become like this:

Spoiler: Error 2

The power button can be pressed to turn off the system, so it is not frozen.

Let me know how you'd like me to proceed

Edit: Now that I look at the error screen, I can't be entirely sure, but I think I remember that the error I got the first time was for top.bgr .. This second time in the screenshot says bottom.bgr .. I might be wrong, but that's how I remember it

 

[duke_srg]

@duke_srgSo, I build the dev-a9lh branch, loaded it through the browser, and let it do the initial set up and everything (which worked without a problem)..

So you wiped /data and this time both font and firmware was processed completely from one launch with no issies? Sounds great!

About the error.
good news: if I rewrite splash screens with precached backgrounds, the issue will be solved and transfer speed will be even higher.
bad news: your card seems to be crappy than mine.
I'm using Transcend microSD 16Gb Class 10 and yesterday dumped EmuNand twice with no issues. I'll try with SysNand now, I believe I did it only once and maybe not the complete one. For now you could try with the second card you own, if that is not a big deal. Let me guess, now you're tried with Samsung Evo, right?

upd: nope, sysnand dumps fine for me

 

[Madridi]

So you wiped /data and this time both font and firmware was processed completely from one launch with no issies? Sounds great!

About the error.
good news: if I rewrite splash screens with precached backgrounds, the issue will be solved and transfer speed will be even higher.
bad news: your card seems to be crappy than mine.
I'm using Transcend microSD 16Gb Class 10 and yesterday dumped EmuNand twice with no issues. I'll try with SysNand now, I believe I did it only once and maybe not the complete one. For now you could try with the second card you own, if that is not a big deal. Let me guess, now you're tried with Samsung Evo, right?

upd: nope, sysnand dumps fine for me

Yeah, last time I tested the setup worked fine from one launch without an issue. I wrote about it here also. I wasn't sure if it was a fluke or something you had fixed.

Yeah, I also thought maybe it's my card. But I honestly have no problems with it so this was new for me. Yes, I tried with the samsung Evo one.

In any case, maybe the precached backgrounds will solve this, so I can give an accurate assessment on the dump time using all methods. Just let me know when I should start again

 

[duke_srg]

Yeah, last time I tested the setup worked fine from one launch without an issue. I wrote about it here also. I wasn't sure if it was a fluke or something you had fixed.

Yeah, I also thought maybe it's my card. But I honestly have no problems with it so this was new for me. Yes, I tried with the samsung Evo one.

In any case, maybe the precached backgrounds will solve this, so I can give an accurate assessment on the dump time using all methods. Just let me know when I should start again

You can change here
https://github.com/dukesrg/rxTools/blob/dev-a9lh/rxtools/source/lib/tmio/tmio.c#L293
to DIV_4 and try once again. If this will work, then the card is in charge. It is not necessary that card malfunction, the actual error returned by fatfs module, and most probably this issue may have a workaround. But before we should check this is the case, DIV_4 returns card clock to 8Mhz.

 

[Madridi]

You can change here
https://github.com/dukesrg/rxTools/blob/dev-a9lh/rxtools/source/lib/tmio/tmio.c#L293
to DIV_4 and try once again. If this will work, then the card is in charge. It is not necessary that card malfunction, the actual error returned by fatfs module, and most probably this issue may have a workaround. But before we should check this is the case, DIV_4 returns card clock to 8Mhz.

Testing now.

Few things I noticed:
- I was wrong. I had it the opposite. I am actually using the sandisk msd. It's my other 3ds that has the samsung Evo one.

- I am also wrong about the initial setup. It does work fine, but it's a 2 boot process. On first boot it seems like it's decrypting the firm. On second boot, it's probably extracting the font? (The process takes like 2 seconds)

- The time flicker fix is great! I thought that is just how it was. It looks much better now

Anyway, I'll report back once I have some dump data

Edit: sysnand dumped fine this time, but it feels like it took longer than it should have. It took 7.34 minutes

 

[duke_srg]

Testing now.

Few things I noticed:
- I was wrong. I had it the opposite. I am actually using the sandisk msd. It's my other 3ds that has the samsung Evo one.

- I am also wrong about the initial setup. It does work fine, but it's a 2 boot process. On first boot it seems like it's decrypting the firm. On second boot, it's probably extracting the font? (The process takes like 2 seconds)

- The time flicker fix is great! I thought that is just how it was. It looks much better now

Anyway, I'll report back once I have some dump data

Edit: sysnand dumped fine this time, but it feels like it took longer than it should have. It took 7.34 minutes

As I told, first it extracts font, this time nly progress bar is displayed. Second it decrypts firmwire - not only a progress bar, but also title and time remaining is displayed, if font was extracted and loaded. Both should normaly work in a single boot.
SysNand dump is strangely slower then EmuNand, I also noticed. So it worked fine for you with clock changed to DIV_4? It might be even slower compariong to another versions, since now top and bottom background are continuousle read to redraw screen with progress bar.

 

[dAVID_]

I hate to be that "that girl," but if you really want to be compete with the big boys, you need get into the A9LH race.

Yeah, make it A9LH compatible.

 

[Madridi]

As I told, first it extracts font, this time nly progress bar is displayed. Second it decrypts firmwire - not only a progress bar, but also title and time remaining is displayed, if font was extracted and loaded. Both should normaly work in a single boot.
SysNand dump is strangely slower then EmuNand, I also noticed. So it worked fine for you with clock changed to DIV_4? It might be even slower compariong to another versions, since now top and bottom background are continuousle read to redraw screen with progress bar.

Oh yeah, I forgot that I am supposed to see a title and time remaining.
Then no, I only saw a progress bar in the first boot, that had 3 changes. Took half a minute or something. Then on the second boot I got a 2 second progress bar only.

However, firmware decryption did happen, or else I wouldn't have been able to launch emunand through rxtools right? Cause it's launching fine

Yes, DIV_4 worked fine for both sysnand and emunand.

Now, for the times I have so far, it's not looking good
Rxtools-dev-a9lh browser sysnand 7.34m
Rxtools-dev-a9lh browser emunand 7.38m
Gateway a9lh 6.10m

Also just finished
Rxtools dev-a9lh a9lh sysnand 8.29m (Took around 3 seconds for it to start, and the time remaining still wrong, although flicker is fixed here too.. Not sure of dump validity of course but that's another story)

Edit: emunand dumping through a9lh has correct timing though

 

[duke_srg]

Yes, DIV_4 worked fine for both sysnand and emunand.

This gives no speed advantage, so time do not matter much in this case. With DIV_2 it gives me this:
sysnand - 5:28
emunand - 5:30
gateway - 7:13
And yes, sysnand dumps differs by 139kb only.

UPD: and yes, the error you experienced does not affect the actual process, just waits for the input.

 

[Madridi]

So I just finished all my tests. I tried to be as thorough as I possibly can to give you as big as a sample size as possible. A quick note, my nands are linked. Here are the results of my tests:
Rxtools dev-a9lh browser sysnand 7.34m
Rxtools dev-a9lh browser emunand 7.38m
Rxtools dev-a9lh a9lh sysnand 8.29m
Rxtools dev-a9lh a9lh emunand 7.39m
Rxtools master browser sysnand 8.24m
Rxtools master browser emunand 8.25m
Gateway Browser 6.14m
Gateway a9lh 6.10m
D9 browser sysnand 7.00m
D9 browser emunand 6.57m
D9 a9lh sysnand 6.57m
D9 a9lh emunand 6.53m

From the data above we can see that there is almost no difference between launching from browser or a9lh, and not much of a difference Sysnand and emunand (with the exception of rxtools a9lh sysnand).

This gives no speed advantage, so time do not matter much in this case. With DIV_2 it gives me this:
sysnand - 5:28
emunand - 5:30
gateway - 7:13
And yes, sysnand dumps differs by 139kb only.

UPD: and yes, the error you experienced does not affect the actual process, just waits for the input.

Yeah, I guessed that the speed boost had to do with the DIV_2..

Which error?

 

[duke_srg]

Which error?

The theme error, it is only reported and waits for user response. So you can just replace this line
https://github.com/dukesrg/rxTools/blob/dev-a9lh/rxtools/source/lib/draw.c#L325
with this
https://github.com/dukesrg/rxTools/blob/dev-a9lh/rxtools/source/lib/draw.c#L327
so it just closes file in both cases.
And check with DIV_2 again, and better to have emunand dump to compare with. Sysnand dump comparing is not strictly possible unless we have a9lh bootable RX.

 

[elBenyo]

I have some Menuhax systems so this is a good backup to have on them, Thank you for your hard work. A9LH would be nice but I won't fix something that isn't broken, so Luma will be on them till I have a reason to change it (Luma also has IPS ROM Patching for 3DS games).

 

[Madridi]

Alright got it, I'll have to try this later tonight. I'm off for a few hours

 

[Madridi]

@duke_srg

So I tried it with DIV_2, replacing line 325 with 327, and here is the result:

Spoiler: Complete?

[/IMG]

So when I was 4 minutes in, it said 1 and a half minute remaining. So I was expecting to see it finish in 5.30 minutes. However, the picture above happened less than half a minute later, at 4.28 minutes!
If you notice the text in the bottom of the picture, it seems like there is a problem there. So, I pressed a button to continue, got a screen, followed by B to go back one more screen, and here are the 2 screens I saw:

Spoiler: Problems

After all this, I checked my micro sd to see if it did at least dump correctly, but it did not. It stopped at 730MB (765,460,480 bytes)
So it seems to me, that dump does not continue once it encounters that issue.

Hope that helps

 

[duke_srg]

@duke_srgHope that helps

Checked with Class6 - emunand dump in 4:38. And it is verified to be the same, cycle was dump original, restore on second SD card and dump again.
Fixed progress bar a bit more, now only refreshes 1 per second at max, so should reduce sd command queue.
Emunand dump time reduced from 5:30 to 5:06.

 

[Madridi]

Checked with Class6 - emunand dump in 4:38. And it is verified to be the same, cycle was dump original, restore on second SD card and dump again.
Fixed progress bar a bit more, now only refreshes 1 per second at max, so should reduce sd command queue.
Emunand dump time reduced from 5:30 to 5:06.

A bit confused with the post. So the progress bar fix is a proposed solution to fix the issue I encountered?
Also, worth mentioning that the error above was sysnand for me. Didn't try emunand

 

[duke_srg]

A bit confused with the post. So the progress bar fix is a proposed solution to fix the issue I encountered? Also, worth mentioning that the error above was sysnand for me. Didn't try emunand

The background file load occurs every progress bar refresh so it makes addotional load to SD card. EmuNAND dump utilizes sd card more then sysnand but anyway I just dumped sysnand to Class6 card in 4:03. It could be faster than my Class10 because it is my working card so there are fragmentation, while Class6 card FAT partition was just copied file-by-file.