Direct boot to ofw- urgent

[psinghvirk]

Hello I am using picofly and new firmware 2.80 everything working fine. Is there anyway to reverse the function logic. Example. Press vol+/vol- for cfw boot and by default boot( ofw with or without SD card )without pressing any key as factory default. It will be very helpful if you can please do this urgently waiting for your reply.

[Quas7]

If I am not mistaken, this would be a setting/feature of hekate and not the modchip FW.

[psinghvirk]

This is a feature of chip firmware it happens before bootloader is even loaded. On code level I think it's just swapping the logic for boot so pins pressed will boot to cfw then ofw and no pins detect will boot too hekate. But I am not sure if it's going to effect anything else that why I requested here. Also I currently don't have the tools to pack forward from sotce code again right now. But this will be very helpful if author of the code can do this. I have searched web and many people have asked question about this but never found anything safe and solid. Waiting for update thanks.

[Quas7]

Related...

CTCaer/hekate#98

#19

I can take a look once more where the CPU GPIOs are referenced. Maybe it is in the busk part and not in usk.

Edit: nope... I see nothing. If you find a line referencing CPU GPIOs I can invert what you are asking for.

[psinghvirk]

Hey, thanks for getting back to me — really appreciate your time.

I went through the full source again, and I think I found a simple and clean way to do what I want without needing to mess with any GPIO-level logic.

Right now, in main.c, it’s using this line:

bool ofw = boot_detect(); // Checks if VOL+ and VOL- are pressed

And later:

if (ofw)
{
printf("Load OFW\n");
// OFW boot logic...
}
else
{
printf("Load Hekate\n");
// Hekate boot logic...
}

So basically, if VOL+ and VOL- are pressed, it boots into OFW — and if nothing is pressed, it goes to Hekate.

But I want the opposite behavior:

No buttons pressed → Boot into OFW

VOL+ and VOL- held → Boot into CFW (Hekate)

So I just flipped the logic in main.c like this:

bool cfw = boot_detect();

if (!cfw)
{
printf("Load OFW\n");
// OFW boot logic...
}
else
{
printf("Load Hekate\n");
// Hekate boot logic...
}

Everything else stays exactly the same. This seems like the cleanest way to do it without changing any of the GPIO checks in boot_detect() or touching the lower-level stuff in busk.

Let me know if you see any issues with doing it this way or if there's a better approach. Appreciate your help again!

[Quas7]

Hi, no problem you are welcome.
But I have no idea to what line of code in main.c you are refering to with your comment above.
I mean, the whole program flow is not really that simplistic.
Or is this just some way to tell me in Arduino-code-style, what you actually want to establish? Because that is really quite clear already to me. ;)

The main() is directly calling for this sequence and the only point where some buttons are checked is
L110: bool force_button = detect_by_pull(1,0,1);
but that call is clearly for pico hardware itself and not for the Nvidia CPU.

usk/main.c

Lines 85 to 123 in d3dca67

	int main()
	{
	// stop watchdog
	*(uint32_t*)(0x40058000 + 0x3000) = (1 << 30);
	// init reset, mosfet and LED
	detect_board();
	// clocks & voltage
	init_system();
	// fuses counter
	init_fuses();
	// LED & glitch & emmc PIO
	upload_pio();
	if (is_tiny())
	{
	gpio_put(led_pin(), 0);
	sleep_us(100);
	put_pixel(0);
	sleep_us(100);
	}
	// check if this is the very first start
	if (watchdog_caused_reboot() && boot_try == 0)
	{
	halt_with_error(1, 1);
	}
	// is chip reset required
	bool force_button = detect_by_pull(1, 0, 1);
	// start LED
	put_pixel(PIX_blu);
	// test pins
	self_test();
	// wait till the CPU has proper power & started reading the eMMC
	wait_for_boot(2500);
	// ensure the BCT has not been overwritten by system update
	bool force_check = fast_check();
	was_self_reset = force_button || !is_configured(cid_buf + 1);
	// perform payload rewrite if required
	if (!force_check || was_self_reset) {
	rewrite_payload();
	}

So, if I do not get a hint, where the buttons are either evaluated or the branch takes place I have no starting point to change code. :(

[Quas7]

After quickly reading a bit about the whole functionality of "VOL+ & VOL-" I really believe it is not based on the modchip FW but is a feature of Hekate that is somehow bypassing the recovery mode (RCM) via payload injection for OFW boot.

For a non-modded Switch this button combination enables the RCM during boot and obviously this is not handled by any modchip:
https://www.nintendo.com/au/support/articles/how-to-update-nintendo-switch-in-recovery-mode/

Also confirming the Hekate payload idea:
https://www.reddit.com/r/SwitchPirates/comments/zexuxe/boot_into_ofw_sysnand_on_modded_oled/

[psinghvirk]

Hi, thanks again for the reply — and totally understood on your point about program flow.

Just to clarify what I was referencing:

In main.c, the line:

bool force_button = detect_by_pull(1, 0, 1);

is checking the button state via GPIOs on the RP2040 side. Then a few lines later, this condition appears:

if (!force_button)
{
// try booting cfw
...
}

So in effect:

No buttons held → enters the CFW boot path

Buttons held → skips it and goes to OFW

Since this logic is only used once, it looks like simply inverting the condition:

• if (!force_button)

• if (force_button)

should cleanly reverse the boot behavior without needing changes elsewhere.
I double-checked and didn’t find any other place where this value is referenced for boot path decisions.

Let me know if I missed something or if you'd prefer this handled differently — and thanks again for taking the time to look into it.

[Quas7]

I understand that you really wish for that solution and I am really sorry to tell you otherwise. :(

The pico GPIOs are not connected to the Switch VOL buttons. Only the Nvidia CPU is connected to those.
Therefore there is no direct connection between this function and the OFW/CFW boot selection. :(
This looks more like forcing a FW update mode or similar by the buttons on the pico itself.
I can provide you with an inverted call there but it will just brick the pico until flashed via USB again to a working FW.

[psinghvirk]

Hi again! Really appreciate all your help and your detailed responses so far — they've been incredibly helpful in understanding the flow.

After reviewing everything and your clarification that the Pico doesn’t have access to the VOL+/VOL- buttons (and that the Switch handles boot selection depending on whether a payload is present),

Rather than showing a "No SD card" screen when no payload is present, can we simply fall back to booting OFW directly. This keeps the behavior intuitive:

If the payload exists → CFW boots

If not → OFW boots

The Pico button (for USB boot/firmware flashing) still works as-is

If for any reason this path isn’t viable, would it be possible as a fallback to make the device shut down gracefully when no payload is detected — instead of sitting idle? Just to avoid battery drain in edge cases.

Thanks again for your time and support — let me know what you think or if you’d prefer a different approach!

[Quas7]

So, in your scenario you would like remove the SD card or put in SD card without payload.bin to make sure to boot into OFW instead of VOL-buttons pressed during boot.

Unfortunately, I doubt that the pico does access the SD-card during its bootup magic.
The pico fires the content of "payload.h" into the communication between CPU and eMMC storage and does not read anything from the SD-card as far as I can follow the code.
In my understanding, the SD content is handled via Hekate.
Also note that after glitching the pico is set to low-power/no-operation via a zzz() call.

But maybe it would be easier to add a little on/off or tactile switch to the reset line or power line of the modchip to deactivate it "hard"? The micro-switch could be placed next to the USB-C connector.
Or you can use a reed-switch inside the caseing completely invisible and only activate the modchip with a small magnet from the backside of the Switch on the right point.
I am not the first one coming up with reed switch ideas for the Switch but Sthetix (check his other videos) is using it for something else: https://youtu.be/y5-TPVecVsw?t=1010

But I have the feeling that you did not install the modchip yourself, right?
If that is the case, please dont try to add that mod to it as there is a non-zero to quite high chance of damaging a perfectly working Switch. Or start training up with SMD soldering for a few weeks - everybody has to start with some motivation. ;)

[psinghvirk]

Hello thanks for clarifying the process. I will look into that a bit further. One more question on this. Can you explain the logic on picofly and no SD card image on boot when no bootloader is present. What is that handled by and is there any way to change that behaviour means change that screen or insert switch off before that screen. So when boot without keys goes to cfw if no bootloader is present then turn off. Not showing that fly or no SD card image at all. Thanks in advance again for all the help you have given so far.

[psinghvirk]

Hello if it's possible can you please edit one logic and share. It would be very helpful that if we can somehow just shutdown the switch without the nonusb of Pico pic when it's missing SD card or bootloader. . Or just wait on that screen with blank screen. So no Pico and no SD card message. If you can somehow do that it will be great help. Really appreciate all the help you have given so far. Thanks. Waiting to hear back from you.

[Ixolaro]

Hello, where exactly are you seeing the logic