Start again with screens turned on#2570
Conversation
Reverts melonDS-emu@2e9434f, after hardware testing, the console does boot up with the powcnt1 register being set to 1
|
When in the boot chain is your code running? My testing shows that the BIOS bootloader sets POWCNT to 0, then the firmware initializes it. |
Right after stage1 (since it is a stage2 firm).
By doing a full bios boot, you can see yourself that the first write to powcnt is done by the stage2, and in my gcdfirm payload I'm not setting that bit explicitly at all (and it works on hw) |
|
that is indeed true for the DSi, the BIOS doesn't touch POWCNT1 at all... however, there's no way to verify it for the DS, since the BIOS sets POWCNT1 to 0 there. I guess we can explicitly change the reset value in DSi::Reset(). |
|
Right, that's shared for the ds as well 😅, I guess it could also be confirmed there by flashing a custom firmware |
|
Unless you're able to somehow replace the BIOS (which is built into the SoC), you can't make that claim about the DS. It might be true, but there's no way to verify it. Keep in mind that LCD stuff works somewhat differently in the DSi. |
Ah, so it's not done by the firmware, right, well, applying your suggestion and setting it to 1 only on dsi |
|
the rationale behind that change was to mirror what I could observe - the screens start powered off. if POWCNT1 is inited to 1 in DS mode, you get a spurious white flash on boot... however, that seems fine for DSi mode, so let's do this. on the DSi, you also have that "LCD init" flag in DISPSTAT, so the LCDs take some time to actually power on. the firmware checks the flag (on the ARM7), so it'd be interesting to see how long it takes to get set. (would also be interesting to see if that flag is affected by POWCNT1 at all) |
2 participants
Reverts 2e9434f, after hardware testing, the console does boot up with the powcnt1 register being set to 1 (tested when booting straight from gcdfirm)
