GodMode9 v1.8.0 boot issues with Luma 3DS chainloader
BaamAlex opened this issue · 163 comments
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?
I am also having this exact same issue. Reverting to 1.7.1 fixes it, though...
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?
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.
Cannot reproduce the bug on my end.
@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
New 3ds, Luma 9.1 with Firmware 11.9. And i haven't installed it to firm0
Boot Storage? What do you mean with this?
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.
From sd card.
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.
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?
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.
tested latest release on firm0 with and without sd...no issues
B9S
@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?
I'm in the exact same disposition as @BaamAlex
@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?
I have only the godmode9.firm in the payloads folder.
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.
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.
How does one install B9S on Firm0, by the way?
@dothackjhe boot9strap is installed to firm0 iirc
I wonder what makes GodMode9 1.8.0 not boot on us if that's the case, then.
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!
@d0k3 what's causing the bug that makes gm9 not boot for some users?
If we knew, we'd already have fixed it, @Ty-Dye. We're trying to find out.
@d0k3 a theory I have, could it be a n3ds (or o3ds) only thing
or could it depend on the bootloader?
@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?
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.
@d0k3 Do we have to rename the provided file or we should use it as is?
Sorry, dumb question..
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.
@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.
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.
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.
@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.
I only ever keep one, which is GM9.
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...
Mine's on 11.9.
Update:
@d0k It still will not boot to GM9 even with the latest file you've just provided.
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.
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.
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.
@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.
@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 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.
@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.
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?
If d0k3 himself is not aware what causes it, I do not know who would.
@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.
My consoles aren't affected, but I'm available to help testing each commit.
@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.
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.
@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.
@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.
@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 <tore.anon@gmail.com>
Date: Tue Feb 12 00:03:55 2019 +0100
Fix #455
:040000 040000 115ecd0dc468f1d9705717c5f9cff43758fa8081 4094fa1ef5e274b59464f9bb845effa3f426845b M arm9
@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.
@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
@d0k3 is this update stable if loaded with fastboot3ds? or/and should I still hold off on 1.8
@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.
@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.
@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!
@PistolsAtDawn Yeah, I meant "/sdcard/luma/payloads."
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
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?
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
Using the Luma nightly and the 1.80 release of GodMode9, I cannot reproduce the problem.
Anyone got a link to the latest nightly build of Luma3DS?
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.
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.
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.
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.
@d0k3 - Sorry, but it doesn't look like my DS flashcart is supported (CycloDS Evolution).
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.
@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
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.
When i use godmode9 installed to firm0 it boots flawlessly. Several times tested yesterday.
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.)
Maybe i should try FB3DS XD
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)
Oh! I can't believe I forgot to test ctrnand gm9
@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?
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.
@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.
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)?
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.
@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.
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
Does the not working one have one or 2 IPS panels by chance? You can check the viewing angle to find out.
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.
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.
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.
I have a Galaxy Edition n3DSXL, dual IPS screens, GP9 1.8.0 will not boot on it., 1.7.1 works fine.
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.
@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
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?
@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)
@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.
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.