mid-kid / cakehax Goto Github PK

5245c7b prevents booting, at least with bigpayload from spider. Tried to fallback FatFS 11a and update to 12b with the same result, both with devkitARM 45 and 46.
/sdmmc/ files are not affected, tried both current and previous with not updated fatfs.

CakeHax stopped working starting with this commit
ec40102

See, for example here:
http://gbatemp.net/threads/download-decrypt9-open-source-decryption-tools-wip.388831/page-185#post-6558023 (and the previous posts)

The only thing in that D9 commit is updating submodules (including CakeHax). As of now, CakeHax does not work in any of my tools anymore.

But GW Browser entrypoint is OK (if a software enhanced both CakeHax and GW Browser entrypoint).
This issue has existed for several years.
It still exists even after #2 getting fixed.

BTW, I can only confirm -4 Browser (v1024) is not working, but don't know about other older than 4.5.0-10's Browser (= 4.0.0-7's v2050).

Here is the link for the code. I don't know which is wrong, comment or code. Probably the code is wrong because bit 5 (0x20) has no effect. Both are correct. I was wrong. I should have a rest.
d07d6dd#diff-4b52b1f3e4eec8cb9278f2e8d842871fR11

In my case, I want it to leave as it is because it disables to write after 0x08100000. If the code is not necessary, I suggest to remove those code.

Even the current ARM11 payload is something sort of a "universal" payload. They share all code after set_app_offsets.
This also reduces troublesome works to maintain Brahma.

Suggested by Steveice10 on 4dsdev.
"Although I feel like a universal payload launcher would be a better idea than a template for various projects to inject into. Like the homebrew launcher, but for ARM9. Would avoid .dat naming conflicts and make entrypoint compatibility easier."

A simple arm9 payload that uses FatFs to load other payloads with a simple menu to select them would do. A start for this could be the current chainloader.

The issue has been confirmed on rxTools, please see roxas75/rxTools/issues/279.
The following patch fixes it, but I don't know why it makes difference. It was by chance.

diff --git a/source/payload/main.c b/source/payload/main.c
index d16306b..cc046c6 100644
--- a/source/payload/main.c
+++ b/source/payload/main.c
@@ -62,6 +62,7 @@ void main()
     *(uint32_t *)0x080FFFC0 = (uint32_t)framebuffers->top_left;
     *(uint32_t *)0x080FFFC8 = (uint32_t)framebuffers->top_right;
     *(uint32_t *)0x080FFFD0 = (uint32_t)framebuffers->bottom;
+    *(uint32_t *)0x080FFFD4 = (uint32_t)framebuffers->bottom;

     // Select the first framebuffer for each screen, since we only write that one.
     *(uint32_t *)0x080FFFD8 = 0;

per https://gbatemp.net/threads/release-cakesfw.391200/page-31#post-5565762