Toggle sidebar

Homebrew Official [Release] EmuNAND9 - Open Source EmuNAND Formatter & Manager

  • Thread starter Thread starter d0k3
  • Start date Start date
  • Views Views 253,871
  • Replies Replies 961
  • Likes Likes 87
madridi4ever said:
@d0k3 , @Shadowtrance

This post involves both original and UI versions, and both Emunand9 and Decrypt9:

I just updated the apps. Last version I had was from last month. Launching through browser does not work anymore. Something is broken there now..
Tried it through HBL, it works there..

I'd appreciate if you guys can look into it. Thanks!
Click to expand...
Thanks for pointing that out! I thin it is a similar issue as this one. Will look into it, fix coming soon.

EDIT: Wait, there is something you could try. I'm interested in wether this has to do with the drawing system only... If you launch it through the browser, do you get a black screen? What happens if you press start after waiting for a few secs (~15s)?
 
Last edited by d0k3,
  • Like
Reactions: kiwiis and Madridi
d0k3 said:
Thanks for pointing that out! I thin it is a similar issue as this one. Will look into it, fix coming soon.

EDIT: Wait, there is something you could try. I'm interested in wether this has to do with the drawing system only... If you launch it through the browser, do you get a black screen? What happens if you press start after waiting for a few secs (~15s)?
Click to expand...
d0k3 said:
No, the one attached to that last post is the bootstrap version (ie. standard ARM9 payload). But check the edit in my last post above.
Click to expand...
I get a black screen, which seems to be a hard lock on the system. Can't do anything besides a hard shutdown. Can't even shut down normally
 
madridi4ever said:
I get a black screen, which seems to be a hard lock on the system. Can't do anything besides a hard shutdown. Can't even shut down normally
Click to expand...
Alright, this will need some looking into. More info soon...

--------------------- MERGED ---------------------------

There's one more info that could help me... the third release works, but the one from 20160112 doesn't correct?

Check here:
https://github.com/d0k3/EmuNAND9/releases
 
  • Like
Reactions: kiwiis and Madridi
d0k3 said:
Alright, this will need some looking into. More info soon...

--------------------- MERGED ---------------------------

There's one more info that could help me... the third release works, but the one from 20160112 doesn't correct?

Check here:
https://github.com/d0k3/EmuNAND9/releases
Click to expand...

I tried the .bin from that version and it hardlocks as well.
 
d0k3 said:
But the one from 'third release' works, correct?
Click to expand...
I just noticed something... what offset are you using? For the Decrypt9WIP.bin, the correct offset is 0x0.

For the Decrypt9WIP.dat it is 0x12000, as written in this commit. Now, there might be some trouble with CakeHax right at this moment. For BootCTR (and any other ARM9 payload loader) I recommend using the Decrypt9.bin from the release with offset 0x0.
 
Yeah, I think some of the offsets were wrong because BootCtr seems to assume (as did I) that all .bin/.dat payloads are 0x12000. So that's what i've been using.

I will retest with 0x0 for Decrypt9.bin, but just to be clear, what are the offsets for Emunand9 (0x12000)?

EDIT: In BootCtr's defense the config uses .dat payloads in its examples, but it does mention .bin payloads (just without mentioning the offset change)
 
Last edited by kiwiis,
kiwiis said:
Yeah, I think some of the offsets were wrong because BootCtr seems to assume (as did I) that all .bin/.dat payloads are 0x12000. So that's what i've been using.

I will retest with 0x0 for Decrypt9.bin, but just to be clear, what are the offsets for Emunand9 (0x12000)?
Click to expand...
For the .bin it is always 0x0, for the .dat it is always 0x12000.
 
Ok, give me a few and I'll retest since I used the wrong offsets in error for the .bins originally (the .dat results should be correct as they were using 0x12000)

Latest Decrypt9 .bin - Hardlock
Emunand9 "Third Release".bin - Hardlock
Emunand9 "20160112".bin - Hardlock

So no change in the results, unfortunately.
 
Last edited by kiwiis,
kiwiis said:
Ok, give me a few and I'll retest since I used the wrong offsets in error for the .bins originally (the .dat results should be correct as they were using 0x12000)

Latest Decrypt9 .bin - Hardlock
Emunand9 "Third Release".bin - Hardlock
Click to expand...
Dammit... if you can compile yourself, could you compile from source and try again? If not... @m45t3r maybe you can try it? I somewhat think that the recent libctru update could have to do something with it.
 
@d0k3

Sorry for the late reply. I took my time testing old versions of both decrypt9 and emunand9 to see exactly when the browser version stopped working.

Decrypt9: Last working one is from 18th December. It stopped working in the latest 2
Emunand9: Apparently that never worked! Went all the way back to first version. Same symptoms.

I hope that helps :)
 
  • Like
Reactions: d0k3 and kiwiis
madridi4ever said:
@d0k3

Sorry for the late reply. I took my time testing old versions of both decrypt9 and emunand9 to see exactly when the browser version stopped working.

Decrypt9: Last working one is from 18th December. It stopped working in the latest 2
Emunand9: Apparently that never worked! Went all the way back to first version. Same symptoms.

I hope that helps :)
Click to expand...
It does! With this information, it is very likely that this is a CakeHax problem, and this commit is at fault. Now, I need to find out how to work around this...
 
  • Like
Reactions: kiwiis and Madridi
So, after some testing...

Earlier versions of Decrypt9WIP used CakeHax at this commit:
https://github.com/mid-kid/CakeHax/commit/3978943b5efc2588fdbf4ef669500c1159a6ab9e
... and everything was fine.

EmuNAND9 and later versions of Decrypt9WIP used CakeHax at this commit or later:
https://github.com/mid-kid/CakeHax/commit/c762a2110f118ccba2aa30564eb2b460c4ac8f7e
... and the Decrypt9 CakeHax binary was broken (that's the commit directly after the one above).

Reverting to that earlier commit is out of question, CakeHax needs to be updated for ctrulib 1.0.0. I guess I could use some help. @mid-kid is there anything I need to change in the Decrypt9 source code to make it work again?

Framebuffers should be okay, I guess (especially given that the lower screen is not even used for the standard version):
Code: 
#define TOP_SCREEN0 (u8*)(*(u32*)((uint32_t)0x080FFFC0 + 4 * (*(u32*)0x080FFFD8 & 1)))
#define BOT_SCREEN0 (u8*)(*(u32*)0x080FFFD4)
#define TOP_SCREEN1 TOP_SCREEN0
#define BOT_SCREEN1 BOT_SCREEN0

Then it also uses GW Launcher.dat start.s (vs the one provided by patois with Brahma)...
Code: 
#ifdef EXEC_GATEWAY

.section ".init"

.global _start
.extern main

.align    4
.arm

_vectors:
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool

_start:
    ldr sp,=0x22140000

    @@wait for the arm11 kernel threads to be ready
    ldr r1, =0x10000
    waitLoop9:
        sub r1, #1

        cmp r1, #0
        bgt waitLoop9

    ldr r1, =0x10000
    waitLoop92:
        sub r1, #1

        cmp r1, #0
        bgt waitLoop92

    ldr sp,=0x22160000
    ldr    r3, =main
    blx r3
.pool

InfiniteLoop:
    b InfiniteLoop

#endif // EXEC_GATEWAY
(might I add, I don't have a clue about assembler)

... and GW .ld, for which the only difference is:
ram : ORIGIN = 0x08000000, LENGTH = 128K (in gateway.ld)
ram : ORIGIN = 0x23F00000, LENGTH = 128K (in bootstrap.ld)

But, again, this is like it always was. Even your (mid-kids) pull request to include CakeHax in Decrypt9 (in Archshifts repo) did it that way.
 
Last edited by d0k3,
d0k3 said:
So, after some testing...

Earlier versions of Decrypt9WIP used CakeHax at this commit:
https://github.com/mid-kid/CakeHax/commit/3978943b5efc2588fdbf4ef669500c1159a6ab9e
... and everything was fine.

EmuNAND9 and later versions of Decrypt9WIP used CakeHax at this commit or later:
https://github.com/mid-kid/CakeHax/commit/c762a2110f118ccba2aa30564eb2b460c4ac8f7e
... and the Decrypt9 CakeHax binary was broken (that's the commit directly after the one above).

Reverting to that earlier commit is out of question, CakeHax needs to be updated for ctrulib 1.0.0. I guess I could use some help. @mid-kid is there anything I need to change in the Decrypt9 source code to make it work again?

Framebuffers should be okay, I guess (especially given that the lower screen is not even used for the standard version):
Code: 
#define TOP_SCREEN0 (u8*)(*(u32*)((uint32_t)0x080FFFC0 + 4 * (*(u32*)0x080FFFD8 & 1)))
#define BOT_SCREEN0 (u8*)(*(u32*)0x080FFFD4)
#define TOP_SCREEN1 TOP_SCREEN0
#define BOT_SCREEN1 BOT_SCREEN0

Then it also uses GW Launcher.dat start.s (vs the one provided by patois with Brahma)...
Code: 
#ifdef EXEC_GATEWAY

.section ".init"

.global _start
.extern main

.align    4
.arm

_vectors:
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool
    ldr pc, =InfiniteLoop
    .pool

_start:
    ldr sp,=0x22140000

    @@wait for the arm11 kernel threads to be ready
    ldr r1, =0x10000
    waitLoop9:
        sub r1, #1

        cmp r1, #0
        bgt waitLoop9

    ldr r1, =0x10000
    waitLoop92:
        sub r1, #1

        cmp r1, #0
        bgt waitLoop92

    ldr sp,=0x22160000
    ldr    r3, =main
    blx r3
.pool

InfiniteLoop:
    b InfiniteLoop

#endif // EXEC_GATEWAY
(might I add, I don't have a clue about assembler)

... and GW .ld, for which the only difference is:
ram : ORIGIN = 0x08000000, LENGTH = 128K (in gateway.ld)
ram : ORIGIN = 0x23F00000, LENGTH = 128K (in bootstrap.ld)

But, again, this is like it always was. Even your (mid-kids) pull request to include CakeHax in Decrypt9 (in Archshifts repo) did it that way.
Click to expand...

CakeHax was updated for DevkitARM r45 a while ago (it doesn't use ctrulib), and it's working just fine in CakesFW.
Possible breaking changes: https://github.com/mid-kid/CakeHax/commit/c762a2110f118ccba2aa30564eb2b460c4ac8f7e https://github.com/mid-kid/CakeHax/...bf8e#diff-9d34cfe2f65558e4d98a0883817d8a8dR70
I think the problem is probably somewhere in payload, so you should look there.
 
Last edited by mid-kid,
mid-kid said:
CakeHax was updated for DevkitARM r45 a while ago (it doesn't use ctrulib), and it's working just fine in CakesFW.
Possible breaking changes: https://github.com/mid-kid/CakeHax/commit/c762a2110f118ccba2aa30564eb2b460c4ac8f7e https://github.com/mid-kid/CakeHax/...bf8e#diff-9d34cfe2f65558e4d98a0883817d8a8dR70
I think the problem is probably somewhere in payload, so you should look there.
Click to expand...
Alright, thanks a ton! I reverted this commit, and everything worked again. The other one didn't cause any trouble. Now, I don't want to do my own fork of CakeHax just for this, so... any ideas what I could change in Decrypt9 to make it work with current CakeHax? I guess changes would only be required in teh draw system, but I might be wrong,

Also, on a related note... CakeBrah can't load the Decrypt9 bootstrap.bin, while there is no trouble with it in either Brahma 2 or my BrahmaLoader fork.
 
d0k3 said:
Alright, thanks a ton! I reverted this commit, and everything worked again. The other one didn't cause any trouble. Now, I don't want to do my own fork of CakeHax just for this, so... any ideas what I could change in Decrypt9 to make it work with current CakeHax? I guess changes would only be required in teh draw system, but I might be wrong,

Also, on a related note... CakeBrah can't load the Decrypt9 bootstrap.bin, while there is no trouble with it in either Brahma 2 or my BrahmaLoader fork.
Click to expand...

If you want to load the bootstrap.bin, you have to inject that to another location in the CakeHax.dat file (look in the readme). Also you'd have to fix the framebuffer offsets (look here).
To just fix the gateway payload, I think:
Code: 
#define BOT_SCREEN0 (u8*)(*(u32*)0x080FFFD0)
should do it.
 

Site & Scene News

Go to forum More news

Popular threads in this forum

Help on 3DS prices...

Homebrew  reBadge - an open source Nintendo Badge Arcade and Theme Shop revival, done with ❤️

Homebrew Homebrew app  [WIP] Spoti3DS – Native Spotify Connect Client for 3DS

Homebrew  NightClock : a relaxing clock app

Hacking  How do I fix 3DS blue light black screen?

Gaming Homebrew ROM Hack Others  I overhauled a plugin for Pokémon X/Y/OR/AS — spawn any Pokémon, shop anywhere, edit your team, know your enemy, teleport and many more!

Homebrew  A new theme website! Themezer now supports 3DS/2DS Themes, Splashes, and Badge Packs!

Homebrew  Twilight Princess Port Indev by Game of Tobi