It might be possible to add DSONE to ntrboot_flasher.

[Apache Thunder]

Can you add chip ID 0x454D to your DSOne code? I want to test my MMD cart on it but I can't get the project to compile with your modified flashcart core.

(I'm guessing it's because you aren't using https://github.com/DS-Homebrew/ntrboot_flasher_nds fork?)

 

[moon_rabbit]

Can you add chip ID 0x454D to your DSOne code? I want to test my MMD cart on it but I can't get the project to compile with your modified flashcart core.

(I'm guessing it's because you aren't using https://github.com/DS-Homebrew/ntrboot_flasher_nds fork?)

I think ntrboot_flasher_nds also uses the same core, but I don't know why.

Here is the build file with 0x454D added.

 

[Apache Thunder]

Thanks. I just now ended up finding the fix. It looks like maybe you were testing this on 3DS build of ntrboot flasher which you just now posted that you did.

To make this work on that DSi fork build you can alter the following function at the end of DSOne.cpp:

bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) {
    // todo: we just read and write the entire flash chip because we don't align blocks
    // properly, when writeFlash works, don't use memcpy
    logMessage(LOG_INFO, "DSONE: Injecting Ntrboot");

    // don't bother installing if we can't fit
    if (firm_size > m_max_length - (twl ? 0 : 0x7E00)) {
        logMessage(LOG_ERR, "DSONE: Firm too large!");
        return false; // todo: return error code
    }

    uint8_t* buffer = (uint8_t*)malloc(m_max_length);
    readFlash(0, m_max_length, buffer);

    if (twl) {
        memcpy(buffer, firm, firm_size);
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
    } else {
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
        memcpy(buffer + 0x7E00, firm, firm_size);
    }

    writeFlash(0, m_max_length, buffer);

    return true;
}

Then add TWL bool to injectNtrBoot in device.h like follows:

virtual bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) = 0;

The fork I'm using supports DSi's ntrboot which what ever it is you are testing on does not. These changes are specific to that build though so probably will have to maintain this as separate branch.

I may still test your version on 3DS if what I did still has issues on the DSi build.

EDIT:

Creates dump correctly like my attempt with the DSTT code but like that one it also hangs at "Writing at 0x0".

Checked the logs, looks like it dies at the erase_block(0) step.

[INFO]: DSONE: Init
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Init
[DEBUG]: DSONE: Reset
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Erasing Flash
[DEBUG]: DSONE: erase_block(0x00000000)

 

[moon_rabbit]

Thanks. I just now ended up finding the fix. It looks like maybe you were testing this on 3DS build of ntrboot flasher which you just now posted that you did.

To make this work on that DSi fork build you can alter the following function at the end of DSOne.cpp:

bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) {
    // todo: we just read and write the entire flash chip because we don't align blocks
    // properly, when writeFlash works, don't use memcpy
    logMessage(LOG_INFO, "DSONE: Injecting Ntrboot");

    // don't bother installing if we can't fit
    if (firm_size > m_max_length - (twl ? 0 : 0x7E00)) {
        logMessage(LOG_ERR, "DSONE: Firm too large!");
        return false; // todo: return error code
    }

    uint8_t* buffer = (uint8_t*)malloc(m_max_length);
    readFlash(0, m_max_length, buffer);

    if (twl) {
        memcpy(buffer, firm, firm_size);
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
    } else {
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
        memcpy(buffer + 0x7E00, firm, firm_size);
    }

    writeFlash(0, m_max_length, buffer);

    return true;
}

Then add TWL bool to injectNtrBoot in device.h like follows:

virtual bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) = 0;

The fork I'm using supports DSi's ntrboot which what ever it is you are testing on does not. These changes are specific to that build though so probably will have to maintain this as separate branch.

I may still test your version on 3DS if what I did still has issues on the DSi build.

EDIT:

Creates dump correctly like my attempt with the DSTT code but like that one it also hangs at "Writing at 0x0".

Checked the logs, looks like it dies at the erase_block(0) step.

[INFO]: DSONE: Init
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Init
[DEBUG]: DSONE: Reset
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Erasing Flash
[DEBUG]: DSONE: erase_block(0x00000000)

Erase command isn't working, it's stuck in "while".
You can also try using a type 2 command.

But since it's the same chip
I think there might be an unlock code needed to erase/write.

The chip ID is also different.
If dump is working, you may need to adjust 0x87 to something else, or tweak flash_command entirely.

 

[Apache Thunder]

Yeah looks like that would be the case. Since there's nothing in the bootme.nds files/rom dumps that have any flash code I'm not sure how I'd find out what commands to use.

I did try enabling the type 2 commands for it but no dice. Still hangs. If the 87 cmd wasn't working me thinks it would have hung at the chip reset/chip id part? I think it uses cmd 87 to obtain those/do chip reset. The dump code would have also died but that seems to work as the dump contains the blowfish data as well as correct NTR secure area data. (EDIT: Seems to be using cmd 0 for read flash so maybe not there. Maybe chip_reset isn't actually happening but surely this would just result in chip ID returning random results which isn't happening here.... )

(tested your 3DS build and it hangs there too)

Anyways cool to see DSOne support seems to work at least.

EDIT: Yeah maybe cmd 87 isn't doing anything after all. Checked the rom and guess what matches the chip ID it returns.

The chip id displayed in the log is the full u32 and it matches that first u32 value of the rom header so yeah chip ID isn't actually returning the correct data it seems.

 

[moon_rabbit]

Yeah looks like that would be the case. Since there's nothing in the bootme.nds files/rom dumps that have any flash code I'm not sure how I'd find out what commands to use.

I did try enabling the type 2 commands for it but no dice. Still hangs. If the 87 cmd wasn't working me thinks it would have hung at the chip reset/chip id part? I think it uses cmd 87 to obtain those/do chip reset. The dump code would have also died but that seems to work as the dump contains the blowfish data as well as correct NTR secure area data. (EDIT: Seems to be using cmd 0 for read flash so maybe not there. Maybe chip_reset isn't actually happening but surely this would just result in chip ID returning random results which isn't happening here.... )

(tested your 3DS build and it hangs there too)

Anyways cool to see DSOne support seems to work at least.

It seems to be related to the basic commands of the CPLD or FPGA.
But I don't know anything about this yet, so I'll have to find out the relationship between the commands and the main chip.

 

[moon_rabbit]

Is anyone hoping for DSONEi support?

I don't have it and need someone to test it for me.
I might be able to port just the updater code, but that would require some research into firmware encryption.

I only need the dumped firmware file.
I will provide the ntrboot_flasher file for DSONEi.
It will only enable the dump function, so there is no chance to go wrong.

If anyone needs it, please leave a comment.

 

[realworld]

Is anyone hoping for DSONEi support?

I don't have it and need someone to test it for me.
I might be able to port just the updater code, but that would require some research into firmware encryption.

I only need the dumped firmware file.
I will provide the ntrboot_flasher file for DSONEi.
It will only enable the dump function, so there is no chance to go wrong.

If anyone needs it, please leave a comment.

dsonei official firmwre
bin format: down.supercard.sc/download/evolution/dsonei_update_ndsi145.zip

nds format: down.supercard.sc/download/evolution/dsonei_update_chs_ndsi145.zip
down.supercard.sc/download/evolution/dsonei_update_eng_ndsi145.zip

 

[moon_rabbit]

dsonei official firmwre
bin format: down.supercard.sc/download/evolution/dsonei_update_ndsi145.zip

nds format: down.supercard.sc/download/evolution/dsonei_update_chs_ndsi145.zip
down.supercard.sc/download/evolution/dsonei_update_eng_ndsi145.zip

Yes I know these files, but to be sure I need the dumped firmware file.