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

[duke_srg]

@brennerei @nedron92
Are you using firmware.bin from 9.6?
As I said, CFW part is untouched, so as soon as EmuNAND is detected, it should work fine. Can't say for MSET, but for me launching CFW from spider much more reliable then the menuhax I'm using.
Does anyone else succeeded to launche rxMode EmuNAND on the latest preview?

 

[brennerei]

@brennerei @nedron92
Are you using firmware.bin from 9.6?
As I said, CFW part is untouched, so as soon as EmuNAND is detected, it should work fine. Can't say for MSET, but for me launching CFW from spider much more reliable then the menuhax I'm using.
Does anyone else succeeded to launche rxMode EmuNAND on the latest preview?

How exactly do I know which firmware.bin I'm using? I wasn't aware you could select this.

 

[duke_srg]

How exactly do I know which firmware.bin I'm using? I wasn't aware you could select this.

Well, not for now. If old rxTools was working, that one should be fine tool.
Seems like I've found the issue, the EmuNAND detection was fiexed but size was not altered which affects NATIVE_FIRM reboot on units with bigger NAND size. I fixed this too but it is still in the development commits, I'll rebuild the preview tonight, hold on!

 

[brennerei]

Well, not for now. If old rxTools was working, that one should be fine tool.
Seems like I've found the issue, the EmuNAND detection was fiexed but size was not altered which affects NATIVE_FIRM reboot on units with bigger NAND size. I fixed this too but it is still in the development commits, I'll rebuild the preview tonight, hold on!

Ah, I see. I thought we could choose like cakes for a minute lol. And yes, I was using rxtools before so nothing should have changed. Glad you found the problem though, will test it out when the update's live! (:

 

[duke_srg]

Ah, I see. I thought we could choose like cakes for a minute lol. And yes, I was using rxtools before so nothing should have changed. Glad you found the problem though, will test it out when the update's live! (:

If you have a build environment, you can build -dev fork with the fix. And actually firmware file/partition to boot selection is planned

 

[duke_srg]

@brennerei, @nedron92 preview relese updated. Checked this build myself with wiped changes from MBR - boots fine.

 

[Domukuro Wolfield]

With this rxTool is possible to run old flashcards? I use rxTool 3.0 and don't works :/ Today install Luma 3DS and the flashcards works fine.

 

[duke_srg]

With this rxTool is possible to run old flashcards? I use rxTool 3.0 and don't works :/ Today install Luma 3DS and the flashcards works fine.

Yes, it have DSi patches by @TuxSH, but I believe it was edded even before 3.0.

@d0k3 3DS NAND CTR FAT16 cluster heap starts at offset of 768 sectors (0x60000), so EmuNAND partition start should adjust it to boundry unit of SD card. As the best practice it must be calculated from NCSD CTR partiton offset and FAT16 partition hidden+reserved+2xfat+root entries fields from partition boot record.

 

[MelonGx]

N3DS firm generating python script cannot generate N3DS firm properly now.

I tried it several times and it returned a 2KB 0004013820000002.bin every time.
Maybe Nintendo replaced a dummy file on remote NUS server?

 

[duke_srg]

N3DS firm generating python script cannot generate N3DS firm properly now.

I tried it several times and it returned a 2KB 0004013820000002.bin every time.
Maybe Nintendo replaced a dummy file on remote NUS server?

Try to download with the direct link from the browser. Nintendo for sure could remove older firmware.

 

[MelonGx]

Try to download with the direct link from the browser. Nintendo for sure could remove older firmware.

OMG, 0004013800000002.bin DLed from O3DS python script is 2KB either.

 

[duke_srg]

OMG, 0004013800000002.bin DLed from O3DS python script is 2KB either.

Check 9.6 and 10.4 versions please. I'm unable to check now, nut have them downloaded earlier anyway.

 

[DjoeN]

N3DS firm generating python script cannot generate N3DS firm properly now.

I tried it several times and it returned a 2KB 0004013820000002.bin every time.
Maybe Nintendo replaced a dummy file on remote NUS server?

yes, seems Nintendo replaced the Firmware files with dummies
Lucky i have backups

 

[MelonGx]

Check 9.6 and 10.4 versions please. I'm unable to check now, nut have them downloaded earlier anyway.

For N3DS, [NUS URL]/0004013820000002/00000018 NG, 00000019 NG, 0000001A OK, 0000001B OK.
For O3DS, [NUS URL]/0004013800000002/00000049 NG, 0000004A NG, 0000004B OK, 0000004C OK.

 

[duke_srg]

yes, seems Nintendo replaced the Firmware files with dummies
Lucky i have backups

Great, keep it all and .TMD as well. I have a plans for firmware choice in rxTools Anyway we already need to host MSETs and patched H&S.

 

[DjoeN]

Well it's only backups for N3DS and O3DS firmware 10.5 :/ and no TMD
Only that stuff the python script downloaded.

 

[duke_srg]

Well it's only backups for N3DS and O3DS firmware 10.5 :/ and no TMD
Only that stuff the python script downloaded.

Should not be a problem, actually tmd's is not removed from server. At least that was true for MSETs

 

[d0k3]

Yes, it have DSi patches by @TuxSH, but I believe it was edded even before 3.0.

@d0k3 3DS NAND CTR FAT16 cluster heap starts at offset of 768 sectors (0x60000), so EmuNAND partition start should adjust it to boundry unit of SD card. As the best practice it must be calculated from NCSD CTR partiton offset and FAT16 partition hidden+reserved+2xfat+root entries fields from partition boot record.

So... is this the same for both, O3DS and N3DS? I see it is nicely aligned to 64k. For RedNAND (which for many is the new standard type of EmuNAND), it is not, though, as a RedNAND has a base offset of 1 sector.

 

[duke_srg]

So... is this the same for both, O3DS and N3DS? I see it is nicely aligned to 64k. For RedNAND (which for many is the new standard type of EmuNAND), it is not, though, as a RedNAND has a base offset of 1 sector.

I did not check N3DS, it is defenetely aligned, but I need fat partition boot sector to say for sure is it 768 or 1024k sectors aligned.
For optimal performance, SD FAT 32 partition must stay where it is located by default, since SD card internal controllers have a special treatment for at least first 2 bound units (I.e. 2x4MB for SD HC and 2x16 for SDXC 64-128GB) for MBR and FAT access acceleration. Moving it forward may reduce performance and wearing.
As we anyway can't move CTR FAT partition here, we can, at lelast, ensure that actual FAT and cluster heap is aligned to SD card bounding unit. And it must be calculated at EmuNAND creation time based on the exact FAT boot sector information.

 

[brennerei]

@brennerei, @nedron92 preview relese updated. Checked this build myself with wiped changes from MBR - boots fine.

Just tried it out and it's still freezing! :/ Must be something else