Hacking WIP [Trinket] [Rebug] [Others] SWITCHBOOT_UF2 / FUSEE_UF2 modchip software

  • Thread starter Thread starter mattytrog
  • Start date Start date
  • Views Views 348,442
  • Replies Replies 1,803
  • Likes Likes 29
did you get chance to look at my poor attempt at a dongle? :cry:
It's not a poor attempt. It's very good!

We can build a bespoke version of software for your dongle. I'll take a look and tell you what to solder. Had to drive down skeg this afternoon to sort some electrics so been busy :(
 
It's not a poor attempt. It's very good!

We can build a bespoke version of software for your dongle. I'll take a look and tell you what to solder. Had to drive down skeg this afternoon to sort some electrics so been busy :(

No rush mate, I appreciate what your doing, just gives you another burden to maintain another dongle though.
I assume it’s just the first file that is bespoke, the second which you update regular is just the same as everyone else?
 
No rush mate, I appreciate what your doing, just gives you another burden to maintain another dongle though.
I assume it’s just the first file that is bespoke, the second which you update regular is just the same as everyone else?
Incorrect. First file. Leave standard... No need to flash that. Just the second one ;)
 
Had an hour today... Implementing a feature that I have seen elsewhere today.

Manage SXOS emunands - select different emunands to boot, clone your original etc...

Some screenies...

On holiday for a couple of days so just doing bits and bobs when I can.

Cheers :)
Screenshot1.jpg




Screenshot2.jpg
 
Last edited by mattytrog,
Nice.

Only emunand on files I guess...

Yep, hidden emunand would require sd card partitioning to be altered and destroy partition information & likely all your information would be lost. With files - all you need to do is rename/move the files - which is trivial & not likely to cause any damage to your sd card files/layout.
 
Yep, hidden emunand would require sd card partitioning to be altered and destroy partition information & likely all your information would be lost. With files - all you need to do is rename/move the files - which is trivial & not likely to cause any damage to your sd card files/layout.
Yep. It's a file renaming exercise. Nothing to it.

Think memcpy, memset, f_rename...

That pretty much sums it up.
 
Right... v1.37SX beta coming later today

Changelog:
  • This is intended for SXOS users using SD card file-based emunands
  • Have up to 5 emunands
  • Clone emunands facility... but (VERY SLOW) so use your computer. Still just as slow. Maybe. ;)
  • All emunand partitions are separate, with its Emutendo folder copied
  • Exfat and Fat32(split) emunands supported
  • Removed "dump all keys" option due to stack space. Use standard version for that ;)

There is a "setup" procedure within SwitchbootSX(what a shyte name).

It uses "markers" which are just id files (you will see a 1-byte marker file in each emunand folder...)
Once set in Switchboot, forget it (unless you want to change emunands ofcourse...

A "release" will be out (much) later today. Got to tidy this bomb-site of a kitchen out. Don`t ever get yourself a "teenage daughter" as they seem to be messier than any cat or dog.
 
Last edited by mattytrog,
OK... Ready for a beta test I think...

Attached is "SXBoot v1.0.2" beta

Works fine for me.

PREREQUISITES:

  • Using SD card file-based emunand

USAGE:

  • In new SXOS menu, you will see a "Setup Emunand folders / slots". Select this...
  • Folders created in sxos folder: emunand1, emunand2 etc etc.
  • Your emunand will now reside in "slot 1".
  • To use it, select "Use emunand slot 1" from the main SXOS menu in SXBoot.
Your emunand will be moved from emunand1(slot1) to emunand(SXOS default or slot 0)

Clone or copy your emunand to the different slots as you like...

This is a biggie... IMPORTANT

In each emunand folder(1 - 5), you will find a "marker" file. If you see a "marker" file, you can copy another emunand to this directory...

If it is completely empty... DO NOT COPY ANYTHING TO THE FOLDER AS THE EMUNAND IS INSERTED INTO THE DEFAULT "WORK" SLOT. Look in sxos/emunand to confirm!

Keep the "marker" files where they are...


I`m just testing this implementation...

Back up your emunand beforehand. I`m not perfect.

This is a test really... I`m aware the error handling is shyte but I`ll fix that...

How it works:
Emunands are organised into "slots". Slots are identified with a "marker" file. The selected emunand is taken out of its slot and inserted into the "work" slot, which is "sxos/emunand". If a different emunand is selected, the old one is put back into its slot, with its "Emutendo" folder, ready for use next time and the new desired one inserted into the "work" slot.

Just lots of renaming, memcpying, memsetting in this mod. No idea if I`m making sense, but it works for me.

Idea:
Move your emunand to a slot and get SXOS to recreate a fresh one for you...

Let me know how it goes...
 

Attachments

Last edited by mattytrog,
Hello,

I am having a problem with the payload.bin location.
If payload.bin is in the sdcard root it works fine, but if I remove it and put to bootloader/payloads/payload.bin it stops working and boots right away to the switchboot.bin (that is in the modchip).

Any ideas?
 
Hello,

I am having a problem with the payload.bin location.
If payload.bin is in the sdcard root it works fine, but if I remove it and put to bootloader/payloads/payload.bin it stops working and boots right away to the switchboot.bin (that is in the modchip).

Any ideas?

You are using Fusee-UF2?
 
  • Like
Reactions: angelo_
Well, I tried to update this time but I can't access the storage of the RCMx86 I have. The proccess I did last time was outside of the Switch, using a 3v3 voltage regulator and directly plugging to my PC usb. I have installed the SWITCHBOOT UF2 and in the second part of storage I dropped switchboot.bin instead of Fusee-UF2.bin.

Now when I try to update the storage partition never mounts (tried Windows and Linux). Running dmesg outputs:
usb 2-9.2: new high-speed USB device number 69 using xhci_hcd
usb 2-9.2: device descriptor read/64, error -71
usb 2-9.2: device descriptor read/64, error -71
usb 2-9-port2: unable to enumerate USB device

Any idea how to proceed? I have tried using the Switchboot update option and rebooting the RCMx86 while on HOS too.
 
Well, I tried to update this time but I can't access the storage of the RCMx86 I have. The proccess I did last time was outside of the Switch, using a 3v3 voltage regulator and directly plugging to my PC usb. I have installed the SWITCHBOOT UF2 and in the second part of storage I dropped switchboot.bin instead of Fusee-UF2.bin.

Now when I try to update the storage partition never mounts (tried Windows and Linux). Running dmesg outputs:
usb 2-9.2: new high-speed USB device number 69 using xhci_hcd
usb 2-9.2: device descriptor read/64, error -71
usb 2-9.2: device descriptor read/64, error -71
usb 2-9-port2: unable to enumerate USB device

Any idea how to proceed? I have tried using the Switchboot update option and rebooting the RCMx86 while on HOS too.

Hmmm... Are you doing it while fitted to console? If so, you have:

Problems with your USB lines (wrong way around / poor GND connection)

OR

You have corrupted the bootloader. In which case, you will need a Raspberry pi and OpenOCD to recover it. There is a Raspi image with openocd in my modchip thread OP so you can unbrick.
 
  • Like
Reactions: angelo_
@mattytrog thanks for the update on this I will be trying it out and upgrading soon. I have a probably weird question for you. So I have a Trinket M0 installed in my switch and currently its pretty easy to press the reset button through the back of the case. I bought a thin "dockable" case off amazon like this: https://www.amazon.com/FYOUNG-Protective-Accessories-Controller-Protector/dp/B07BGWCFTZ in hopes of helping when holding it in your hand not pressing the reset button on the chip which pushes the volume up button.

I put the case on and found it was pressing reset button by itself and holding it down which I dont know what damage this could cause but one of the joycons would stop working and wouldnt charge etc. So my question is, is there anything I can do to fix this problem? is the reset button still needed to enter chip programming mode or would it be possible to desolder?
 

Site & Scene News

Popular threads in this forum