GodMode9 v1.8.0 boot issues with Luma 3DS chainloader

[BaamAlex]

When i update to the latest version the 3ds shuts down instantly. This problem doesn't happen with version 1.7.1. What can cause this issue?

[dothackjhe]

I am also having this exact same issue. Reverting to 1.7.1 fixes it, though...

[urherenow]

A bit more explanation would help. What model/firmware are you? How are you launching it? Are you trying to boot with it installed to firm0?

[dothackjhe]

Seeing I am also experiencing the same issue as the thread starter, I am also answering the questions as follows:

New Nintendo 3DS XL running on latest firmware (11.8, I think) and latest Luma3DS version.
Trying to launch it at cold boot.
I do not know how to answer the last question, lolz.

[Nemris]

Cannot reproduce the bug on my end.

[Wolfvak]

@BaamAlex and @dothackjhe please post more information about your systems, such as:

• system model
• system firmware
• exploit used to run GM9
• boot storage
• and any other information that may seem pertinent

[BaamAlex]

New 3ds, Luma 9.1 with Firmware 11.9. And i haven't installed it to firm0

[BaamAlex]

Boot Storage? What do you mean with this?

[Wolfvak]

I mean where have you installed it. Whether it's on FIRM0/1, somewhere in the FAT NAND partitions or in the SD card.

Regarding your other message, you still don't say exactly how you try to boot it, or from where.

[BaamAlex]

From sd card.

[Nemris]

Tested on:
• New3DS with Luma 9.1, OS 11.9.0-42E, fastboot3ds on FIRM0;
• Old3DS with Luma 9.1, OS 11.9.0-42E, boot9strap on FIRM0

Boots fine.

[Wolfvak]

But how exactly are you booting it? Are you using b9s, fb3ds, etc? Do you boot anything in between the first stage loader and GM9?

[urherenow]

I'm using b9s, and loading Godmode9 via Luma3DS hotkey at coldboot (I named it x_GodMode9.firm in the payloads folder). It loads instantly. No issues at all. Just updated to 11.9 just in case. Still works.

[al3x10m]

tested latest release on firm0 with and without sd...no issues

[BaamAlex]

B9S

[Wolfvak]

@BaamAlex so you have the GM9 firm placed in the SD card root, called boot.firm and it shuts down as soon as you power on the console?

[dothackjhe]

I'm in the exact same disposition as @BaamAlex

[d0k3]

@BaamAlex - thanks for opening that issue. If you are running GM9.firm directly from B9S now, can you maybe try running it via the Luma chainloader? Or is this what you always did?

[BaamAlex]

I have only the godmode9.firm in the payloads folder.

[d0k3]

Can you try these two test builds?

https://f.secretalgorithm.com/15JCyI/godmode9-bkpt.firm
https://f.secretalgorithm.com/YPtgV/godmode9-nolto.firm

Maybe make a photo if something of note happens.

[PistolsAtDawn]

d0k3, as we briefly discussed on reddit, here is my initial report and the test results of the two builds you just posted:

This was tested on a New 3DS XL (11.9 / Luma 9.1 stable [chain loaded with payload in SD card path /luma/payloads] / b9s 1.3) -

From a powered off state, launching gm9 (release build 1.80) by pressing and holding start opens gm9 with the top screen being mostly black but with some vertical lines (about 25% of the time it opens completely fine though).

Using the test build you posted here in the comments [reddit], I get basically the same behavior.

It seems like perhaps keeping the start button pressed too long causes this. I can somewhat reliably get the splash screen logo and the top pane to show normally if I'm very careful with how long I keep the start button pressed once the 3DS has rebooted.

1.7.1 doesn't behave this way. I can be "careless" with the start button being pressed and gm9 starts reliably.

New test results -

As you said would happen, the bkpt build crashed immediately. I attached the dump.

The nolto build more reliably boots without the blank screen on top, especially when not started from a cold boot. Pressing and holding start within gm9 for instance will more likely cause everything to reboot normally as well as when I reboot from within the 3DS home screen using the Quick Reboot cia I have installed.

I hope this was helpful. Thank you and everyone else who has contributed to this fantastic utility.

crash_dump_00000000.dmp.zip

[dothackjhe]

How does one install B9S on Firm0, by the way?

[BaamAlex]

@dothackjhe boot9strap is installed to firm0 iirc

[dothackjhe]

I wonder what makes GodMode9 1.8.0 not boot on us if that's the case, then.

[d0k3]

Okay, here's another one for everyone to test, especially @BaamAlex, @dothackjhe and @PistolsAtDawn :
https://f.secretalgorithm.com/12rT10/godmode9-sifix.firm

Let me know if that changes anything!

[ghost]

@d0k3 what's causing the bug that makes gm9 not boot for some users?

[d0k3]

If we knew, we'd already have fixed it, @Ty-Dye. We're trying to find out.

[ghost]

@d0k3 a theory I have, could it be a n3ds (or o3ds) only thing

or could it depend on the bootloader?

[Nemris]

@Ty-Dye For me, GM9 works both on an Old3DS and on a New one.

@d0k3 I have a theory of mine, without proof to back it up. Could the bug depend on the date a 3DS was manufactured, and LTO triggers it?

[urherenow]

What is LTO? And do you want newer or older machines? I have a launch-day O3DS I can try it on. My N3DS doesn’t have an issue though. Edit: And... I need to hunt around for that O3DS... recently moved back to Japan and have no idea where it's at.

[dothackjhe]

@d0k3 Do we have to rename the provided file or we should use it as is?

Sorry, dumb question..

[urherenow]

Ok, si I found my O3DS (Launch Day), and observed the problem of the blue light coming on and back off (machine would not boot). I then booted Luma without holding X, and realized my battery might have completely died, since I haven't used it in so long, so I checked the date and time. It was set for like May 3, 2033 or something. I fixed the date and time, then tried loading GodMode9 again, and it worked. Hope this helps.

[dothackjhe]

@urherenow So, it has something to do with the date, then?

I just checked my 3DS's calendar. Mine's set on the year 2037! I do not even recall messing with the calendar this badly. That might indeed be the culprit.

[urherenow]

Look at yours and find out. If not, then I have now booted it on N3DS and O3DS. Initially, O3DS didn't work, but my date and time were all whacked out. After fixing that, I can now boot the latest GM9. Heck, just to be sure, change the date and time to something wrong, then back to what it should be, using the latest Luma. Then try GM9 again.

[dothackjhe]

Update: Merely fixing the calendar did not make it work for me for some reason. I'm still having the same issue: it will not boot to GM9 1.8.0.

@d0k3 I tried the edited file you provided. Despite my 3DS' date and time being fixed, it still will not boot to GM9 1.8.0.

[d0k3]

@urherenow - I have my doubts the date can really have anything to do with that. Is it possible you only had problems when you cold booted? I need testers with consoles that exhibited those problems, your O3DS apparently is also affected.

Here's a new test build, if the last one didn't solve your problems:
https://f.secretalgorithm.com/13bJ3G/godmode9-sifix-wait.firm

@dothackjhe - you can use that file as is. If there are multiple files inside the Luma payload folder, you will get a menu allowing you to choose one.

[dothackjhe]

I only ever keep one, which is GM9.

[urherenow]

No, my O3DS seriously works now. I only had the initial glitch and hadn't used the system in probably more than a year. FW 11.6 is on it...

[dothackjhe]

Mine's on 11.9.

Update:

@d0k It still will not boot to GM9 even with the latest file you've just provided.

[urherenow]

FW version shouldn't matter because it boots before firmware anyway. Just for grins, I updated to 11.9, and it still booted. Replaced luma with it (named it boot.firm on SD root), and it still boots. My console is not effected, I guess.

EDIT: but disclaimer, even though it shouldn't matter with b9s anyway, I roll my own, and I bake the keys into it.
Edit2: Used the release from here. Works. I'm unable to help, I guess.

[PistolsAtDawn]

@dothackjhe

I just checked my 3DS's calendar. Mine's set on the year 2037! I do not even recall messing with the calendar this badly. That might indeed be the culprit.

I had this happen too, but only once. I set the time in both gm9 and the 3DS system settings and now I can't get it to repeat. I believe this is normal based on the Quick Start Guide here on this repo.

@d0k3 - godmode9-sifix.firm and godmode9-sifix-wait.firm were basically no change when they were the only payload in /luma/payloads and I held Start to chain load to gm9 (cold boot). I think that sifix-wait seems to load normally a slightly higher percentage of the time.

Again from a cold boot I tested the sifix and sifix-wait builds by assigning a different hot key, holding that new key down and pressing the power button. Loading this way actually seemed to decrease the percentage of the time that gm9 loaded normally with the test builds. Almost every time I get a completely black top screen.

From a soft reboot sifix-wait would load normally a little bit more often than sifix would (regardless of which hot key was assigned).

Finally, I noticed that if I boot to Luma's chainload menu by holding start and selecting any of the multiple payloads (stable or test), gm9 loads properly _every time_!

Could polling for button presses somehow be the difference? When using Luma's chainload menu I was not holding down any hot key, just pressing once on my selection. Even when I attempt to glitch the top screen again by holding any button or combo of buttons down from the Luma chainload menu, gm9 loads normally.

[d0k3]

Thanks everyone for testing, especially @PistolsAtDawn for the detailed bug report. This may be very helpful!

I won't be able to do another test build today, but there's something you could try in the meantime:

• Try running GodMode9.firm differently. Put multiple firms into the payloads folder, run it directly from b9s (put it on the SD card root as boot.firm) or install fastboot3DS and run it from there.
• Can anyone affected do a git bisect, starting from v1.7.1? You will need dkA r52, be able to compile GodMode9 yourself and have some basic knowledge in handling git.

[PistolsAtDawn]

@d0k3 You're welcome. Happy to help. I do software QA professionally, but I'm not working at the moment so therefore have the time.

Putting the sifix/wait payloads on the root of the SD card renamed as boot.firm starts gm9 normally _every_ time (cold or warm boot). At worst, the top screen shows minor graphical distortions for a split second, then everything works normally.

I can't do a bisection without some specific steps to take as I've never done one, but I run Linux, so I'm quite comfortable with a shell. If nobody else can help, I can be available for this with some assistance.

[vladashram]

@PistolsAtDawn It's pretty straightforward, you just pick a commit between 1.7.1 and 1.8.0(usually about halfway), and compile the source from that commit. The purpose is to try to figure out which commit broke it., by process of elimination.

[dothackjhe]

Good insight @PistolsAtDawn! I'll check it out.

Update:

It worked! :D

[urherenow]

@dothackjhe that's not very helpful. WHAT worked? Which commit broke it on your system (assuming you went back a commit at a time until one worked, which it the newest one that works?). I can't be of help since the latest works for me anyway, otherwise I'd be able to figure it out myself.

And for those not used to troubleshooting like this, please "make clean" in-between checking out different commits.

[dothackjhe]

@urherenow In case you missed it, the solution is to keep more than one ".firm" file inside /luma/payloads. In this case, I placed both the GM9 of version 1.7 and the modified version of 1.8 which d0k3 provided. This opens up an option to select whichever version to boot to at cold boot. Choosing the modded 1.8 works at this point.

[urherenow]

well, that's weird. I do have multiple files in there. Still have the old dectrypt9, hourglass9, and a payload for Gateway, etc... If that really was an issue it would explain why it always worked for me. But... the actual release still doesn't work for you? Just a modded one posted here in this issue?

[dothackjhe]

If d0k3 himself is not aware what causes it, I do not know who would.

[d0k3]

@PistolsAtDawn - I'll provide detailed instructions on how to do the git bisect tomorrow. Do you already have git installed and cloned the repo? I can give you any instructions you need.

[Nemris]

My consoles aren't affected, but I'm available to help testing each commit.

[d0k3]

@everyone:
Here's another test build. This is v1.7.1, but compiled with the most recent toolchain (dkA r52). Try it, see if it exhibits the same problems. If it does, compiler optimizations may cause this (maybe some timinig issues?):
https://f.secretalgorithm.com/mmFay/godmode9-v1.7.1-r52.firm

Choosing the modded 1.8 works at this point.

@dothackjhe - I'm somehow assuming even the unmodded release will work that way. Can you try?

@PistolsAtDawn - this is much easier via direct chat, so maybe you're available on IRC, Discord, Telegram or even Reddit? Here's a good description on how to do a git bisect:
https://git-scm.com/docs/git-bisect

Don't worry, it's much easier than it looks at first glance, and you don't even have to read the whole thing to do it. You will need to be able to compile, though.

[PistolsAtDawn]

Sure, I'm not too intimidated by using git, it's setting up the dev tools that I need to figure out, but I see devkitPro has pretty good documentation. I'd prefer to quarantine the dev environment to a VM, so I'm preparing my desktop computer for that now.

I won't be available today for live chat for a good 3-4 hours from the time of this comment. Let's try reddit's chat. I haven't used it yet and we both already have accounts.

The test build from 1.7.1 with the updated dev tools loads fine from cold or warm boot.

[dothackjhe]

@d0k3 I tried the non-modded 1.8.0 version of GM9 along with other payloads (version 1.7.1 and the modded version), it worked.

For some reason, it just will not boot if either the modded or non-modded version of 1.8.0 is alone in the "/.../payloads" folder.

[PistolsAtDawn]

@dothackjhe - /sdcard/payloads isn't the correct folder. /sdcard/luma/payloads/ is where the gm9 firm files should go if you're chainloading through Luma. It makes no sense to me that you'd be successful putting the payload on the root directory named as boot.firm, but not when launching through Luma unless you have a filepath issue.

Also, are you using boot9strap 1.3 and Luma 9.1? Knowing these things is necessary to understand why you're having issues. Please let us know these things if changing the location of the .firm files does not fix your issue.

[PistolsAtDawn]

@d0k3 - I think I found it. The second commit I tested produced a .firm file that would NOT boot no matter what I tried. Completely black screens. The rest were perfect. Here's the terminal output:

10ec95b8fe626b492f878354ce0022a4aa6a7224 is the first bad commit
commit 10ec95b8fe626b492f878354ce0022a4aa6a7224
Author: d0k3 <[email protected]>
Date:   Tue Feb 12 00:03:55 2019 +0100

    Fix #455

:040000 040000 115ecd0dc468f1d9705717c5f9cff43758fa8081 4094fa1ef5e274b59464f9bb845effa3f426845b M  arm9

[Wolfvak]

@PistolsAtDawn could you upload the full source tree + built binaries (once compiled, zipping it up is enough) of the commit before it breaks down and the first one that breaks everything?

Having the source, compiled objects, linked ELFs and generated FIRMs for each commit handy for easy comparison would help a lot in narrowing down where this bug is.

[PistolsAtDawn]

@Wolfvak - I think I can. I will need to step through the git bisect again. Give me just a few minutes to work on that and I'll come back and post the files.

Update: tested them again, and again the second round was broken (the 3 after that were good).

GM9 v1.7.1-24-g2b8d4fcc.tar.gz
GM9 v1.7.1-36-g10ec95b8 (bad).tar.gz

[ghost]

@d0k3 is this update stable if loaded with fastboot3ds? or/and should I still hold off on 1.8

[PistolsAtDawn]

@Ty-Dye - For me 1.8 works fine if you put it on your sd card root directory renamed to boot.firm, or if you have multiple GodMode9.firm files in /luma/payloads/, then when you power on the 3DS while holding the Start button you will see Luma's chainloader menu. If you pick the 1.8 firm file there, it will load normally.

[d0k3]

@Ty-Dye - Github issues is not a forum, you should really only add to the conversation with further (useful) bug reports or with information on how to solve the problem. Otherwise you're only adding noise. That being said, for all that we know it should be perfectly safe to run GM9 v1.8.0 from fb3ds.

@PistolsAtDawn - thanks a ton for all your help! This will most likely help us fix the problem.

[PistolsAtDawn]

@d0k3 - Happy to help. Now off to go close a Launchpad bug I opened six months ago that I never got back to. They were asking me to do a kernel bisection to see why I was having USB performance issues on 18.04 but not on 16.04. I think they've fixed it in the meantime fortunately. If not, now I'm more comfortable with bisections, so this was a useful exercise for me!

[dothackjhe]

@PistolsAtDawn Yeah, I meant "/sdcard/luma/payloads."

[TheGinGear]

New 3ds XL, firmware 11.9.0-U, b9s, run as luma payload on 9.1. Had this issue (3ds turning off imediately when holding start, similar to b9s not finding a boot.firm file on root). If you add another .firm file into the /luma/payloads/ folder in addition to the gm9.firm file (renaming as no effect), and boot gm9 1.8.0 from the chainloader menu, suddenly gm9 1.8.0 is bootable. Even with a completely empty x.firm file.
Addendum: when using 1.8.0 as boot.firm on root it also boots just fine

Another Addendum: Choosing to reboot from the rosalina menu while holding start works as well

[urherenow]

Now that I think about it... how is this NOT a Luma3ds issue? boot.firm = gm9. Period. Regardless of FW version or anything else software related.

luma/payload/xxxx = Luma chain loading. The latest Luma commit slightly altered an .s file to fix a fastloader bug. Perhaps that fix might take care of this issue as well?

[d0k3]

Now that I think about it... how is this NOT a Luma3ds issue? boot.firm = gm9. Period. Regardless of FW version or anything else software related.

luma/payload/xxxx = Luma chain loading. The latest Luma commit slightly altered an .s file to fix a fastloader bug. Perhaps that fix might take care of this issue as well?

Well... you may just be right. Can everyone having issues (@BaamAlex, @dothackjhe, @PistolsAtDawn, @TheGinGear) switch to the most recent Luma 3DS hourly and try again (only GodMode9.firm inside the Luma payload folder)?
https://github.com/hax0kartik/luma-hourlies/releases

[PistolsAtDawn]

Using the Luma nightly and the 1.80 release of GodMode9, I cannot reproduce the problem.

[dothackjhe]

Anyone got a link to the latest nightly build of Luma3DS?

[Nemris]

@dothackjhe https://github.com/hax0kartik/luma-hourlies/releases/tag/151-luma3ds-4e5f6e1

[PistolsAtDawn]

Out of curiosity I just now tried the firm files (normal/dev) from the previous bad bisect step (v1.7.1-36-g10ec95b8) with the latest Luma nightly, and it still fails to load.

I'm not sure if this is significant or not, but I thought I should let it be known.

[d0k3]

Duh. That means the nightly does not fix it.

Anyways, I've got something slightly risky for you to try, @PistolsAtDawn - don't do it if you don't have a ntrboot flashcart ready to fix your system.

Use GM9 to install GM9 v1.8.0 to FIRM0. Do several reboots, see if you can trigger the issue. If you can't, it's clearly a Luma bug. If you can, it's a GM9 bug.

[james-d-elliott]

I'm going to assume the previous commit doesn't work and it was related to the stack pointer issue (Luma Issue 1232). If so it may be of benefit to link to it so other devs who may be experiencing issues can nail the source of it more easily.

Previous commit: https://github.com/hax0kartik/luma-hourlies/releases/download/150-luma3ds-474eb30/boot.firm

Edit: Well maybe not. Maybe just ignore me. :) I might see if any of my collection of DS units experience this.

[d0k3]

Well... it turned out even my 3DS has that issue, but for me it's only slight distortion when showing the splash. I installed to FIRM0, booted at least 25 times (several of these boots had the START button pressed throughout), and I was unable to trigger that issue.

We still need someone with more serious problems to try it (and fail to reproduce) before we can safely declare this a Luma issue.

[PistolsAtDawn]

@d0k3 - Sorry, but it doesn't look like my DS flashcart is supported (CycloDS Evolution).

[d0k3]

Okay, we need someone with an ntrboot flashcart and a console that exhibits serious problems in the Luma v9.1 / GodMode9 v1.8.0 combo then.

To be clear - the risk is very small. There is not even one known case where the GM9 bootloader (that is GM9 installed to FIRM0) didn't work. I just tried although I have no access to my ntrboot cart until the weekend.

@BaamAlex - what about you? You can be the guy to solve this once and for all.

[TheGinGear]

@PistolsAtDawn @BaamAlex can you also test using gm9 as boot.firm? or rebooting using the rosalina menu while holding start? I just want to check if our issues are actually identical

If you haven't already, try triggering the chainload menu by adding another firm file as well, and see if gm9 1.8.0 works from there too

[PistolsAtDawn]

Okay, we need someone with an ntrboot flashcart and a console that exhibits serious problems in the Luma v9.1 / GodMode9 v1.8.0 combo then.

I just ordered a Ace3DS Plus cart from Digitopz.com for $9. I've wanted a dedicated ntrboot cart for a while now anyway. I'm sure it will take a couple of weeks to arrive from China at the earliest and assuming everything ships smoothly. If nobody else can test in the meantime, I'll test when I get it.

@TheGinGear - I did all that, yes (minus Rosalina menu, used Quick Reboot cia instead). I did not however ever have my 3DS _shut down_. Just black screens and a hard freeze requiring me to hold the power button down for good 15+ seconds to shut down.

[BaamAlex]

When i use godmode9 installed to firm0 it boots flawlessly. Several times tested yesterday.

[LilithValentine]

I have launched GM9 from FB3DS and from Luma3DS (latest nightly) and I haven't had any issues on my test systems (old and new3DS.)

[BaamAlex]

Maybe i should try FB3DS XD

[TheGinGear]

I'm not with the 3ds right now, but could someone test how the splash screen being before or after the payload could effect it? (or no splash screen) @dok3

the only other thing I can think of is the allocation size of the sdcard, or the use of an older fat filesystem. (I don't recall if the sd some 3ds's sell with have fat16 or not, but not everyone uses 32k. I use 64 on my n3ds which showed no issue)

[TheGinGear]

Oh! I can't believe I forgot to test ctrnand gm9

[james-d-elliott]

@PistolsAtDawn quick question. You stated: "From a powered off state, launching gm9 (release build 1.80) by pressing and holding start opens gm9 with the top screen being mostly black but with some vertical lines (about 25% of the time it opens completely fine though)." Are you saying start launches GM9? Or launches the Luma3DS chainloader then you select GM9? I'm assuming Godmode9.firm must be the only file in your Luma3DS payloads folder?

[PistolsAtDawn]

Start launches gm9 when gm9 is the only payload in /luma/payloads/, yes.

When there are multiple payloads and Start loads the chainload menu, I haven't been able to reproduce the problem unless I use the second build from the bisection I posted here.

[d0k3]

@AuroraWright, @TuxSH - to summarize, there are weird issues (graphical errors, black screens, shutdowns) in GM9 v1.8.0 when booted via Luma 9.1. It only happens when there is exactly one payload (GodMode9.firm) inside the Luma payloads folder and START is used to boot it. You can read up above, but this issue discussion has gotten quite large.

These bugs are not reproducible any other way (chainloading via fb3ds, GM9 installed as FIRM0, multiple payloads inside the Luma payloads folder, etc...), as confirmed by multiple testers now. Using the Luma nightly instead makes the issues pop up less frequently, but it does not fix it completely.

We can test more stuff if that helps to shed some light, of course.

[james-d-elliott]

Thanks, just trying to reproduce it on some of mine.. I have tried 5. 3x N3DS, 1x O2DS, 1x N2DS (no issues yet). Can you also post your Luma3DS settings (SELECT on boot)?

[profi200]

Just leaving this here: https://github.com/AuroraWright/Luma3DS/blob/master/arm9/source/firm.c#L256

It's probably this line breaking GM9's screen init. It inits the screens even though GM9 doesn't request it. This broke fastboot3DS some time ago until we added more checks to skip full screen init.

[PistolsAtDawn]

@james-d-elliott - Mine is set as:
Screen brightness: 3
Splash: Before
Splash duration: 1
PIN lock: Off
New 3DS CPU: Clock+L2
Enable loading external FIRMs and modules
Enable game patching
(The rest are off)

Just now I tried booting gm9 (the firm from the bad bisect I posted above) from Luma's chainloader. Changing the Splash settings from Before to either Off or After made no difference. Previously I was having success going through the chainloading menu with other builds that exhibited quriks, but absolutely nothing I've tried will boot that particular build.

[jdalmanza]

some additional data, hope it helps:

4 separate NN3DSXL consoles all on 11.9.0-42U
All upgraded from gm9 1.71 -> 1.8.0 by renaming old gm9 folder and .firm file and copying new (no-overwrite)
All modded with this guide (https://3ds.hacks.guide/) using the ntrboot exploit
All running Luma 9.1
All access gm9 from cold boot (START + Power)
gm9 is the only firmware in the luma payload folder

NN3DSXL Model: Red works as expected
NN3DSXL Model Majora's Mask - Does not boot, holding start + power lights blue light for a couple of seconds and then light goes out, console never boots until I let go of START
-- I reverted back to 1.7.1 and am able to boot that version successfully
NN3DSXL Model Pikachu works as expected
NN3DSXL Model SNES works as expected

Please let me know what additional information you need

[profi200]

Does the not working one have one or 2 IPS panels by chance? You can check the viewing angle to find out.

[james-d-elliott]

I was thinking the same thing. I'm betting it has one or more IPS, which is why it's so rare. 3DS Ident can also tell you.

[profi200]

On my N3DSL XL it only affects the topscreen which is an IPS panel. It sometimes inits with horizontal garbage stripes or just stays black with backlight on.

[TheShadowRunner]

N3DS with top IPS panel here, no problem launching GM9 1.8.0.
I launch it using https://github.com/hartmannaf/BootCtr9/releases
Hope it helps, somehow.

[RayGobot]

I have a Galaxy Edition n3DSXL, dual IPS screens, GP9 1.8.0 will not boot on it., 1.7.1 works fine.

[jdalmanza]

@profi200, I'm not sure, I've never checked. I'll have to look and see.

[d0k3]

Okay, everyone, I know this has gotten quite large, and it's difficult to not lose track. So, in short: No one was able to reproduce this bug outside of Luma 3DS. This is more likely a Luma 3DS bug than it is a GodMode9 bug.

I suggest everyone having this issue to switch to fastboot3DS. Find instructions here (read the quick start section), downloads here. Also make sure you setup loading GM9 via a keycombo from fastboot3DS (use slot 2 for that and make sure to select a keycombo).

I'm only leaving this open for a little while more hoping someone will prove me wrong. I may try in the meantime to make fastboot3DS setup a little easier for novice users.

[TheGinGear]

@d0k3 Please don't recommend fastboot3ds to novice users en masse. As a helper from the nh assistance discord, that would make the process EXPONENTIALLY harder for any user having issues; and the majority of the userbase who would see that guide are people coming from the hacks.guide site, trying to download the latest version of gm9; so I would expect a portion of users would just think blindly installing fastboot3ds over an install of b9s is how the guide is meant to be read.

Alternatively, you could literally just reccomend adding an empty .firm file to the luma/payloads folder. No risk, No hassle, and fits the only userbase that actually encounters this issue.

You could recommend both, even. Ask luma users to add the firm, or exclusive gm9 users to use fastboot3ds

[jdalmanza]

So, @TheGinGear, when I upgraded from 1.7.1 to 1.8.0 I left the 1.7.1 firm in the luma payloads folder, however I renamed {firmware}.old so as not to attempt to load. I tried both with the renamed 1.7.1 and without (where 1.8.0 is the only one present) and saw the same behavior. I suppose I could try to rename the old firmware to something g else and see if that addressed the issue, or did I misinterpret what you were saying earlier?

[TheGinGear]

@jdalmanza The issue seems have to been discovered; when booting gm9 directly through luma straight from a powered-off state, it crashes when initializing ips screens. This can be solved by booting it literally any other way; even by adding a completely empty x.firm file to ths payloads folder (as this prompts luma to boot gm9 from the chainloader selection menu rather than from a state where the screens are off)

[d0k3]

@TheGinGear - that recommendation is buried in one of (almost) hundred comments of a GitHub issue. I'd assume users who go as far as to search here know how to follow instructions. I won't recommend a hacky workaround (dummy.firm file, nope).

Still thinking about what to do to make this as easy as possible, but the current state is not acceptable.

[TuxSH]

around which commit did gm9 start to break?

Don't automatically frame it as a luma bug, either. You know very well that 3DS baremetal screeninit is a mess, no matter where the code is sourced from.

It's also weird that the issue only happens when launching with only one payload. In that code path, the screens are initialized once, brightness is setup twice, framebuffers are setup twice, screens are cleared twice.

[TuxSH]

Maybe it's an I2C-related issue? I've recently switched to @profi200 's i2c code, in both luma and b9s.

Try to remove backlight using I2C.
Try to ensure that framebuffer format, framebuffer select and stride are set correctly, and that lcd fill is unset.

[d0k3]

Sorry, @TuxSH - I just wanted to reply, didn't want to edit your comment. Now I can't revert it, duh. Did I delete important information?

Here's the reply again:

around which commit did gm9 start to break?

Thanks for getting back. Well, @PistolsAtDawn actually did a git bisect

@d0k3 - I think I found it. The second commit I tested produced a .firm file that would NOT boot no matter what I tried. Completely black screens. The rest were perfect. Here's the terminal output:

10ec95b8fe626b492f878354ce0022a4aa6a7224 is the first bad commit
commit 10ec95b8fe626b492f878354ce0022a4aa6a7224
Author: d0k3 [e-mail]
Date: Tue Feb 12 00:03:55 2019 +0100

Fix #455

:040000 040000 115ecd0dc468f1d9705717c5f9cff43758fa8081 > 4094fa1ef5e274b59464f9bb845effa3f426845b M arm9

More useful info:

Out of curiosity I just now tried the firm files (normal/dev) from the previous bad bisect step (v1.7.1-36-g10ec95b8) with the latest Luma nightly, and it still fails to load.

I'm not sure if this is significant or not, but I thought I should let it be known.

Realistically, this commit can't be the cause of this issue. The problem has to lie deeper.

[TuxSH]

You can revert it/click on history.

10ec95b8 seems like a totally random commit, are you sure you aren't having overflows or any kind of UB in your code?

[d0k3]

Well, you can never be sure there's nothing of the sort. We checked the code, though, and couldn't find anything. It's especially weird this only happens with Luma.

[TuxSH]

try to comment initScreens in luma. If it doesn't work then the problem is maybe on your end.

https://github.com/d0k3/GodMode9/commit/10ec95b8fe626b492f878354ce0022a4aa6a7224

are you sure this shouldn't be 3, 3 and 7 btw? strncasecmp stops at the first null byte encountered.

[profi200]

@TuxSH
It does happen with the latest stable Luma which doesn't even have the I2C code change. Can't be that. That code doesn't do anything important different either compared to the old I2C code.

Latest commit on Luma master is broken btw. FSREG errors.

[TuxSH]

needs latest ctrulib commit this time

[profi200]

I tried an older commit (673ec9fc). Commenting out initScreens() in loadHomebrewFirm() makes it work flawlessly. If there is another FIRM in the payloads folder there is no difference (as others have discovered already).

My explanation for this is if the chainloader menu appears it has enough time to stabilize while it hasn't when there is only 1 FIRM in there since it goes straight into FIRM launch.

[TuxSH]

I'm still unsure whether this is a 100% luma bug. We haven't touched that code since _ages_, yet it suddently breaks with gm9.

As I've mentioned there are bugs (?) in d0k3's code, and maybe there are bugs in his interrupt handlers? Like for example any gpu-related interrupt (but they should be disabled).

[profi200]

Can't rule that out. I'm not very familiar with GM9s codebase. Something noteworthy is fb3DS caused issues in Luma and other CFWs when it didn't reset the GIC before FIRM launch. It does since a good while and everything is fine. How it can cause issues in other FIRMs when they disable interrupts is beyond me though.

[Wolfvak]

GM9 doesn't use any GPU interrupts, only PXI stuff (and even then, any spurious/unset interrupts are properly handled by being acknowledged and ignored).

The ARM9 CPU runs with interrupts disabled all the time.

[TuxSH]

is the bug happening on O3DS?

[profi200]

New 3DS exclusive. Probably only affects units with IPS screens (like mine).

[TuxSH]

so an I2C/MCU-related bug. You know, the kind of ones that happened long ago. Does removing i2c_init in gm9 solve anything (I remember having issues with it in my exploit code).

[d0k3]

Nah, I don't have IPS screens, and I have trouble sometimes, too (slight distortion when displaying PNG images).

As I've mentioned there are bugs (?) in d0k3's code,...

Bug reports and pull requests are always welcome. Right now there are no known bugs in GM9 except this one. Only the cart dumper has compatibility issues with a select few games (one known atm, Mario Kart DS Kiosk Demo).

[profi200]

Interesting. But IPS screens stop working entirely it seems. Either displays black or horizontal garbage stripes.

edit:
Removing I2C_init() in GM9 makes no difference.

[TuxSH]

What if you add a wait of 3ms at the very start of gm9?

[profi200]

No difference.

[Wolfvak]

Waiting was already attempted in this build https://github.com/d0k3/GodMode9/issues/466#issuecomment-475870601

[d0k3]

Alright, this is locked now. Why? See above, there are >100 comments, and all are about the same. When using Luma 3DS to boot GodMode9 v1.8.0, with only one payload in the payloads folder, there are sometimes varying issues.

We checked the GodMode9 source code and tried everything we can, but we can't get that issue resolved on the side of GodMode9. There may be a way to fix it in Luma 3DS. Quoting @profi200 here:

Just leaving this here: https://github.com/AuroraWright/Luma3DS/blob/master/arm9/source/firm.c#L256

It's probably this line breaking GM9's screen init. It inits the screens even though GM9 doesn't request it. This broke fastboot3DS some time ago until we added more checks to skip full screen init.

We do fully understand @TuxSH and @AuroraWright do not want to implement that fix right away and rather want to take their time testing it some more.

For the time being, it is not recommended to use Luma 3DS to boot GodMode9.firm. We suggest switching to fastboot3DS instead. Be aware that some reading and some configuration is required. An easier, noob-friendly way of setting up fastboot3DS is coming up, and I'll announce it when it is ready.

If you experience any issues booting GodMode9 with another chainloader (fastboot3DS, GodMode9), please open a new issue. If you think you got new info that could fix this, contact me or @Wolfvak elsewhere (GBAtemp, IRC, Discord, Reddit).

[d0k3]

Okay, there's a new Luma 3DS nightly build with a possible fix. Everyone who had problems before, please try this and tell me if it worked for you. I'm especially interested in @PistolsAtDawn's results.
https://f.secretalgorithm.com/zhoWR/boot.firm

I'm going to unlock comments now, but please, behave. Do not write any comments unless you (a) previously had issues with chainloading GodMode9.firm v1.8.0 on Luma 3DS v9.1 and (b) tried the Luma nightly (linked above) and can tell us somehing about how it worked for you.

[PistolsAtDawn]

@d0k3 - Testing using the Luma nightly you linked here, I can't reproduce the problem with the 1.80 release of gm9, but I do still get two black screens using the bad build from my git bisect. This is the same behavior as with the last Luma nightly I tested.

I verified that my Red N3DSXL has one IPS panel (top) using the latest release of 3DSident which curiously crashes with an ARM 11 exception screen that won't let me save the dump.

@jdalmanza - Your Majora's Mask model wouldn't boot gm9 v.1.80 at all, which was worse than what I experienced. I think a retest on that model would be very helpful here.

[Chillstice]

@d0k3 I've been experiencing issues in regards to Godmode9 hanging at the splash screen and that nightly build of Luma fixed that issue for me. c:

[d0k3]

@PistolsAtDawn, @Chillstice, thanks, both of you. Yes, the Luma 3DS nightly seems to fix it, but as @PistolsAtDawn pointed out, there are still ways to trigger that issue. As for me, I'm basically sure it will come back as long as it is not completely fixed.

I mentioned it before, the recommended solution is to switch to fastboot3DS. We made that a lot easier for everyone, see here:
https://github.com/d0k3/OpenFirmInstaller/releases/tag/v0.0.9

I'll still keep this issue open for visibility for a few more days, but, as I previously stated, we see no way of fixing this from the side of GodMode9, thus recommending fastboot3DS as chainloader for GodMode9.

[d0k3]

@PistolsAtDawn - sorry for keeping you that busy. Once you get a chance, could you retry that one bad GM9 commit with the most recent Luma nightly?

Also, just to make sure, you tested that build booting from another loader (GM9 itself, fastboot3ds), too?

[PistolsAtDawn]

@d0k3 - Still no change with the Luma nightly and the bad GM9 commit. I haden't tried fastboot3ds yet, and I was until now unaware that GM9 had the capability of booting to another payload. I have to admit I'm a learn-as-I-need-it kind of person, so I missed that one for lack of a previous need. So anyway here's what I tried:

• The most recent Luma nightly with GM9 v1.80: success

• The most recent Luma nightly with the bad commit: both screens black, non-responsive 3DS (power button must be held for 15ish seconds to turn off). Same as with other Luma nightlies.

• The most recent Luma nightly -> GM9v1.80 payload > Bad commit payload: both screens black

• With GM9 v1.80 renamed to boot.firm on SD card root, and the bad commit in /gm9/payloads/GodMode9.firm: both screens black

• With fastBoot3DS (really nice, BTW!) > GM9v1.80 set to Start: success

• With fastBoot3DS > Bad commit set to X on an empty boot slot: both screens black

I considered that maybe I did something wrong with the bisect, but the builds directly before and after the bad commit never gave me trouble, both times I ran the bisection.

I tried to summon jdalmanza here hoping they could retest this as their Majora's Mask model would black screen on the GMv1.80 release and this seemed to be the worst of the reports. I agree with you that we need more research, and happily through mostly-unrelated circumstances I will soon be in possession of several more N3DSXLs: a black model (US), another red, a SNES Edition and a Hyrule Edition. I'll test this on those and report back what I see. This might take a week or so for me to do this as I'm waiting on various shipments.

[TuxSH]

Thank you for confirming that latest Luma3DS commits have fixed the issue on its end.

(and that the bad commit was itself hosed).

[Wolfvak]

I still have my doubts about the bug being fixed on the Luma side because of https://github.com/d0k3/GodMode9/issues/466#issuecomment-476158461

That nightly was from 16 days ago, far before any "fix" was even attempted...

[AuroraWright]

@Wolfvak that's because Luma nightlies had changed the i2c library with the FB3DS one, and this "bug" is about spamming i2c reads without waiting enough (so changing the library probably changed timings and stuff).

[profi200]

As mentioned in #GodMode9 the only way to fix this once and for all is using interrupts + reverse engineering GSP for possible differences/bugs. We got it pretty stable in fb3DS but it's basically the same code everyone else uses.

[PistolsAtDawn]

So I received my Ace3DS+ card today, flashed ntrboot to it and used it to hack a Red N3DSXL, a Black N3DSXL and a SNES Edition XL.

The SNES Edition _will not boot_ to Godmode9 (v1.80) with either Luma 9.1 or the last Luma nightly (179-luma3ds-e57b546). It immediately turns itself back off again. Adding a copy of the gm9.firm file to the /luma/payloads/ folder triggers the chainload menu upon holding start, and from there I can load gm9 successfully.

What additional information can I provide?

[urherenow]

Whether 1 or both screens are IPS on the SNES model, although I get the feeling the Devs already have an idea of the problem, with no means of dealing with it at the moment. You should either switch to fastboot3ds, or add another .firm file (even a blank one) to the payloads folder.

[profi200]

The truth is we don't really know what the bug is. Only it is New 3DS only and it's caused by the MCU.

[d0k3]

Thanks, @PistolsAtDawn for all the effort you put in so far. Did you also test booting GM9 from fastboot3DS on the SNES Edition XL 3DS? Also, sorry for taking that long to get back.

In general, we're assuming there are are problems chainloading from Luma 3DS, but not from fastboot3DS, so that's what needs to be ensured.

[PistolsAtDawn]

You're welcome, @d0k3.

I just tested booting GM9 (v.1.80) from fastboot3DS on the SNES edition. It worked great, as I expected. I'm going to consider my involvement on this issue done unless I hear otherwise from you or another dev.

Thanks again for all the great tools!

[d0k3]

Thanks for being a great tester, @PistolsAtDawn! We will need more help soon for sure, @Wolfvak is currently working on a big ARM11 refactor, which will require some testing, especially with consoles such as yours.

@TuxSH, @AuroraWright - the issue is obviously not fixed, it's just not that easy to trigger anymore.

[TurdPooCharger]

What happens if you make a Luma3DS build that purposely loads or shows the Luma3DS chainloader screen with just the single GodMode9.firm v1.8.0 payload and then automatically launch it?

[d0k3]

Well, try it, @TurdPooCharger. I'd say that will make it more unlikely to occure, too. Maybe even removing the forced Luma screeninit would fix it somehow.

[profi200]

As mentioned earlier (https://github.com/d0k3/GodMode9/issues/466#issuecomment-477156306) removing forced screen init does indeed help.

[cwyn-ne]

Hey, having a similar(?) issue.
Following this Fredminer CFW tutorial, and I got to the section where I'm to create a SysNAND backup in Godmode9, but when trying to boot it up (START + Power) the blue power light turns on for a few seconds then fades (the screen remains dark). I've checked everything, my firm file is in the correct luma/payloads folder, I have the gm9 folder in the root. Not really sure what to try at this point, and I'm assuming skipping the SysNAND backup wouldn't be very wise (I've never tried doing anything like this before so I'm completely new to everything). Also created a GitHub account purely to post this so I'm not really sure if this is in the correct place lol.

[urherenow]

@cwyn-ne boot.firm is in the root of your sd, right? (Not trying to insult your intelligence... I’ve seen it happen before). And... you don’t continue to hold power, do you? Just tap the power button while holding start.

In the payloads folder, rename Godmode9 to x_Godmode9, and just hold the x button and tap the power button. Did that work?

[u32004]

Okay, there's a new Luma 3DS nightly build with a possible fix. Everyone who had problems before, please try this and tell me if it worked for you. I'm especially interested in @PistolsAtDawn's results.
https://f.secretalgorithm.com/zhoWR/boot.firm

I'm going to unlock comments now, but please, behave. Do not write any comments unless you (a) previously had issues with chainloading GodMode9.firm v1.8.0 on Luma 3DS v9.1 and (b) tried the Luma nightly (linked above) and can tell us somehing about how it worked for you.

I can confirm this works. I was having the same problem, no gm9 launching upon pressing start in boot.
With that build now Godmode works perfectly. New 3DS XL Snes Edition (eur), Luma 9.1 + GM9 1.8.

[legoj15]

I have noticed that if you enter the Luma3DS settings/config screen (by holding SELECT on boot), then tapping START (to save preferences), and then pressing and holding START (or whatever button you have assigned the GM9 firm), GodMode9 boots normally, with both screens working, every time

[TheStraubulous]

I also have this issue. When installing latest Luma today, first boot holding start worked and godmode9 loaded and I finished installing CFW. However every other time now unless I have more than 1 payload in the payload folder I just got the blue light on/off and nothing happens.
N3DS
Latest Luma

[GITitdoneboi]

I have noticed that if you enter the Luma3DS settings/config screen (by holding SELECT on boot), then tapping START (to save preferences), and then pressing and holding START (or whatever button you have assigned the GM9 firm), GodMode9 boots normally, with both screens working, every time

THANKS, That worked for me!

[aznnoodles420]

I seem to be having the same issue on my New Nintendo 3ds XL and I have discovered that it must be something nintendo changed in the new Models of the New Nintendo 3ds XL as my original one bought on release has no issues but my fire emblem model has this problem

[dothackjhe]

@aznnoodles420 Have you tried it on Luma3DS 10?

Luma3DS had just had its new updated version recently.

[aznnoodles420]

Ya I did. No change so I set up fastboot3ds and now it works but like I said this problem is only affecting one of my New Nintendo 3ds XL. The one I bought around launch works fine but my Fire Emblem New Nintendo 3ds XL has issues. This leads me to believe that they made some sort of change on the newer models

[TheGinGear]

If you would all read the previous messages, the cause of the issue has been discovered and solved. When directly chainloading gm9 1.8.0 from luma 9.1, IPS type screens initialize incorrectly. IPS screens are more common on New devices. You can get around this by booting gm9 by any different way than off> b9s > luma 9.1 > directly chainloading gm9 1.8. You can either update to luma 10, or place another .firm file in the /luma/payloads/ folder as to bring up the chainloader menu. And yes, another method is to first boot the luma configuration page first, as seen above.

[profi200]

I disagree with the "solved" part. The real problem still has not been identified and this issue keeps popping up. While it works fine with fb3DS there is no guarantee it may not also happen with it as bootloader.

While i was digging in boot11 i found how to actually reset the GPU but i don't know if this solves anything: https://github.com/derrekr/fastboot3DS/blob/master/source/arm11/hardware/gfx.c#L254-L255

[helltoast]

I came across this issue, is it still being worked on? non-XL n3DS here, NA Mario edition from November 2016, NT panels. using latest Luma. already tried resetting the rtc. putting multiple payload in the folder "fixes" it, I'm assuming fastboot would as well.

I also have an European launch n3DS (NT), Japanese 2016 one (NT) and a NA 2016 one (IPS) for testing if anyone is interested, all regular sized (don't ask)

EDIT: updated Luma and gm9 on the European one, it works. firmware 11.3.

[BaamAlex]

I tried the latest version from gm9 on another new 3ds non xl. Works fine with it

[helltoast]

alright, so I finished installing b9s on all of them, here are my results:

JP: 2014, 11.0, works [TN]
EU: 2014, 11.3, works [TN]
NA: 2016, 11.10, doesn't work (powers off instantly) [TN]
NA: 2016, 11.5, doesn't work (top screen shows gm9 logo, hangs) [IPS]

these are all non-XL n3DS'. tested with latest Luma (10.0.1 hotfix) and gm9 (1.8.0).

EDIT

updated the European one to 11.10, still works. also changed the region of the Japanese one to NA and updated it, also works.

[Insurr]

I'm having issues with this too. Now I first ran into it while setting up using the guide and installing Luma 10.0.1, the GodMode9 title would appear in the top screen but nothing would happen and I'd have to manually turn off the 3ds to get anywhere. The method for entering Luma first and then Godmode9 didn't help. This I DID fix by downloading the alternate boot.firm linked above, after which GodMode9 worked fine.

Unfortunately I ran into stability issues with that setup and decided I better update Luma just in case (seems to have worked so far). This time around Godmode does actually load entirely in the top screen unlike during my first attempt, but I have to do the trick with Luma menu->Godmode menu to actually get the bottom screen to load. Thankfully that does seem to work.

On an EU New 3D XL.

[trlkly]

I also have a Mario edition new 3DS (refurbished by GameStop), albeit the North American variety, and ran into the same problem, even using the latest Luma. All I did was simply follow the guide from https://3ds.hacks.guide. I have the lastest firmware (11.10.0-43). When I got to the point of booting GodMode9, it would just shut off.

I actually just went ahead and used the older version to complete the guide. However, I can confirm now that having two payloads (i.e. the old version and the new version) allows the new version to work properly.

[HedioOnlyTheName]

I have noticed that if you enter the Luma3DS settings/config screen (by holding SELECT on boot), then tapping START (to save preferences), and then pressing and holding START (or whatever button you have assigned the GM9 firm), GodMode9 boots normally, with both screens working, every time

omg it worked thank you 3000

[obsidianspider]

I have noticed that if you enter the Luma3DS settings/config screen (by holding SELECT on boot), then tapping START (to save preferences), and then pressing and holding START (or whatever button you have assigned the GM9 firm), GodMode9 boots normally, with both screens working, every time

_Originally posted by @legoj15 in https://github.com/d0k3/GodMode9/issues/466#issuecomment-498357664_

I can confirm this workaround is working for me on a n3DSXL running 11.10.0.-43U, Luma 10.0.1 and GodMode9 1.8.0. It's not as nice as just holding Start when I boot, but it works.

[Wolfvak]

Okay I think I got it fixed in the last commit - @BaamAlex and everyone else, can you test it out?

[TurdPooCharger]

I tried compiling the current master branch on my Manjaro Linux laptop. It gives these errors. :-(

[xxxxxxxxxxxxx@xxxx-pc GodMode9-master]$ git init
Initialized empty Git repository in /home/xxxxxxxxxxxxx/Desktop/GodMode9-master/.git/
[xxxxxxxxxxxxx@xxxx-pc GodMode9-master]$ make
fatal: No names found, cannot describe anything.
make: Warning: File 'Makefile.common' has modification time 10893 s in the future
Building arm9/arm9.elf
make[1]: Warning: File '../Makefile.build' has modification time 10893 s in the future
[ARM9] source/fatfs/ffsystem.c
[ARM9] source/fatfs/ff.c
[ARM9] source/fatfs/ffunicode.c
.
.
.
[ARM9] ../common/pxi.c
[ARM9] ../common/spi.c
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
Building arm11/arm11.elf
make[1]: Warning: File '../Makefile.build' has modification time 10874 s in the future
[ARM11] source/hw/codec.c
[ARM11] source/hw/hid.c
.
.
.
[ARM11] ../common/pxi.c
[ARM11] ../common/spi.c
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
Creating output/vram0.tar
add: easter.bin
add: font_default.pbm
add: GodMode9_splash.png
[FLAVOR] GodMode9
[VERSION] 
[BUILD] 2019-10-13 14:31:07
[FIRM] output/GodMode9.firm
[FIRM] output/GodMode9_dev.firm
make: warning:  Clock skew detected.  Your build may be incomplete.
[xxxxxxxxxxxxx@xxxx-pc GodMode9-master]$

[Wolfvak]

those aren't errors, they're just warnings about having the wrong clock for some reason.
why are you downloading the zip, then initializing a new git repo on the dir? just clone the repo and build that instead

[TurdPooCharger]

Sorry, still learning devkitarm. git clone https://github.com/d0k3/GodMode9/ works so much nicer. Thanks.

Alright, I compiled master again with no errors. What's weird is that the output GodMode9.firm has the size of 465 KiB. Previous builds were around 485 KiB.

On my n3DSXL, my compiled copy has the banner colors still washed out. Maybe it's my setup.

Can you provide your build here so I can double check?

[Wolfvak]

Anyone having problems, please use this https://cdn.discordapp.com/attachments/431968729488818186/633061313165393950/GodMode9-v1.8.0-144-g915cb2d1-20191013185856.zip

BTW, the size difference is because the README is only embedded on release builds, not personal builds

[KMulvena]

I was having some compatibility issues on my 3DS XL running Luma v10.2 and GodMode v1.9.1 where it would just keep saying "The payload is invalid or corrupted". Using GodMode v1.8 instead seems to work fine for me.