Matty I made the switch to this from switchboot, it's a very nice upgrade. I dont use dual boot I have a basic setup but this JUST WORKS! Everything from automatically taking care of dead battery and booting once good to go to even backing up my sxos license, truly set and forget now. Thanks for this! Looking forward to upcoming V6.
Yes toggle feature is in v6. If you arer OK going through the "blinks" then 1 will be no logo, 2 static, 3 anim1, 4 anim2 etc etc
No worries.excellent thanks mate
installed it on my friends and he doesnt like the 'extra' time it adds haha (kids these days)
However, while the logo is showing, the particulars are being gathered. So I don`t think you will notice any difference.
Just do us a flavour... Test an old version (v1 or 2) and see what the boot time difference is (if you can)... Our baby has robbed our spare Switch as his is flat... And I can`t use Queen of Sheba`s as she has gone to bed to play S-turd-ew Valley.
@mattytrog Hey buddy, sorry to bug you in your own thread but I have a question for you. I'm toying around with UF2 firmware upgrades via the Switch USB port and the solderless adapter board I'm making. I was planning on firmware updates being possible with the Switch powered off to avoid USB conflicts, but I'm noticing that while powered off, inserting a USB cable causes the Switch to be powered back on, no matter how it was shut down. This is true with both AutoRCM and without. Obviously I want to avoid two USB devices talking on the same bus, but iirc using the Switch USB port for firmware updates was a feature of some internal modchips. Do you happen to have any idea how this is done?
Welcome to my world!
That has been an age old problem since we started doing this. And the key reason I made the USB strap for the modchip.
Its done Tegra side. Not changeable. (unless you want to go down the route of disconnecting VCC from the USB port. However, then you run the risk of upsetting power detector in M92T36 as it is expecting 5 or 15v or whatever)
My workarounds to this are, like I say, the USB strap, and / or the SAMD21 update payload which frees the USB bus. (basically just a brief init, mbist(mem check) and a reset...
As for using the USB port for dark magic once Horizon has booted, forget it. Unless you are lightning fingers with timing.
Hope I understood correctly!
To clarify... You MAY be able to engineer something in Atmosphere to free the ports off... But you could be making more problems than you solve eg wired joypads etc.
If you find a solution, I`m all ears.
Last edited by mattytrog,
Got it, thanks for the clarification. I am still confused on a few things though - I see that you have the ability to mount the UF2 with Switchboot:
"UF2 drive access from vol+ button(if strap is fitted of course) - Simply hold for around 12 seconds, a white blinking light will appear. Turn off console, disconnect from USB, turn on and reconnect - UF2 drive up!"
If I'm understanding correctly, you're doing this using the Switch USB port, while the console is on (thought not in Horizon). My goal is to be able to update the DragonMMC firmware and/or adjust settings via the Switch USB port, even if it requires the Switch to be in a certain mode. Just wondering how you achieved this, as from my understanding the Switch's USB port is always active (either as a device waiting for RCM data, or a host within Horizon). So, I'm just wondering if you've achieved this and how.
Ahhh...Got it, thanks for the clarification. I am still confused on a few things though - I see that you have the ability to mount the UF2 with Switchboot:
"UF2 drive access from vol+ button(if strap is fitted of course) - Simply hold for around 12 seconds, a white blinking light will appear. Turn off console, disconnect from USB, turn on and reconnect - UF2 drive up!"
If I'm understanding correctly, you're doing this using the Switch USB port, while the console is on (thought not in Horizon). My goal is to be able to update the DragonMMC firmware and/or adjust settings via the Switch USB port, even if it requires the Switch to be in a certain mode. Just wondering how you achieved this, as from my understanding the Switch's USB port is always active (either as a device waiting for RCM data, or a host within Horizon). So, I'm just wondering if you've achieved this and how.
That is sorcery...
Its a multi-stage process...
1) Person holds down button - enters mode. Steady blinking light on chip. Register is written to Eeprom advising chip of activation...
2) We make sure console is unplugged from USB. We power off
3) We power on, via RCM so payload will be pushed
4) SAMD21 bootloader reads the set register, pushes the SAMD21 update payload, which is in an Armoured-dildo array(arduino) within the code. Once sent, dbl_tap_reset pointer moved to UF2 bootloader, entering UF2 mode.
5) After sending, and JUST prior to entering UF2 mode via dbl_tap_ptr(I forget the exact name), we reset the "update" bit in the Eeprom, turning modchip back to normal.
6) Result - SAMD21 payload sent without buffering it to SD card(as we do in Switchboot/Fusee_suite) and UF2 mode is activated at the same time.
All the end user sees, is the steady flashing light advising of this special pending "update" mode, then they power off, make sure nothing is plugged into USB and power on. Job done.
Last edited by mattytrog,
That's a whole lot of clever magic! But, all of that is just telling me your secret ninja way of getting the modchip into UF2 update mode and back again without a button.
Let's say I have easy access to the reset button for the SAMD21 and can put it in UF2 bootloader mode easily. Assuming we've tied USB D- and D+ from the modchip to the Switch, as devices, how are we preventing both of them from chatting to the USB host? Or does your SAMD21 update payload do some of it's own magic to turn off the USB bus on the Switch so you can update?
This sir.
Basically, a scratch register is set that will survive reset(nicked some of the code ideas from Sept-primary, funnily enough). On this very soft reset, the USB port is freed. Once freed, the console is in a perpetual state of cabbageness until you power off.
I could have made it all fancy, init a framebuffer, had dancing naked flamenco dancers or something... But I wanted it to fit in a tiny space. The update payload on its own cashes in at around 900 bytes. Small enough for an array. Even smaller if you LZ it. But I couldn`t be arsed.
Last edited by mattytrog,
That's pretty fantastic. I don't suppose you've open sourced said payload?
Would love to try to add some kind of splash screen to it and maybe a reboot option on press of power button. That would be exactly what I need for DragonMMC.
Erm... Dunno. Might have it knocking around somewhere. Did it ages ago. Had new PC since then. I`ll knock you something up real quick if you like similar to what I did.That's pretty fantastic. I don't suppose you've open sourced said payload?
If you wanna email me a logo, I`ll build it into the source and let you have the lot tomorrow if thats any good. Its getting on for 1am here
But if size isn`t an issue, certainly can make one with a LZ logo and sense a button press to power off...
Well don't feel like you need to take on any extra work just for me, but if you're up for it that'd be fantastic! Would you be alright with it going up on our GitHub (with credits of course) so it might be useful to other madlads?
For DragonMMC, I'm using the SAMD21E18 so I have tons of extra space. That said, I still prefer to go light on the graphics. The attached image scales perfectly at 3x to fit the Switch LCD at a mere 13kb RAW BMP.
Thanks so much for the help! Definitely poke at our GitHub sometime to see if there's any bits you can use.
For DragonMMC, I'm using the SAMD21E18 so I have tons of extra space. That said, I still prefer to go light on the graphics. The attached image scales perfectly at 3x to fit the Switch LCD at a mere 13kb RAW BMP.
Thanks so much for the help! Definitely poke at our GitHub sometime to see if there's any bits you can use.
Awesome, very much appreciated! Be sure to let me know if you ever need anything.Will do sir!
Will work on it tomorrow after I have took lad to school
I think I'm going to cheat and handle this with a hall effect switch, similar as on the DI:
- Switch powers on, energizes eMMC, DragonMMC powers on.
- DragonMMC checks for GPIO pulled low via hall effect switch.
- If magnet not present, begin normal operation: read slide switch and set PMICs, then begin sleep cycle.
- If magnet present, push SAMD update payload, then *DBL_TAP_PTR = DBL_TAP_MAGIC; NVIC_SystemReset(); for bootloader.
- Once update stuff done, press power on Switch to reboot, which power cycles DragonMMC causing POR to normal operation.
Go get sleep! Also, unless you know of a decent push button under 1mm in height, there's not much else besides the hall effect switch that's effective. I could potentially use a 4 position slide switch instead of a 3 position slide switch I guess.Yep that would do it!
Thinking of alternatives to a hall sensor... I need sleep
Similar threads
-
- Article
-
The Real Jdbye
*is birb* -
Psionic Roshambo
-
BakerMan
The snack that smiles back, Ballsack! -
Xdqwerty
what are you looking at?
