Joy-Con Custom Firmware

[LemmaEOF]

I'm tempted to try and make a modified joy-con firmware that includes not only standard joy-con functions but also connection for the MFi spec, so joy-cons can be used with the iPhone and Apple TV. Before I start something like that, I need to know:

• How hard is it to get a joy-con to update its firmware, period?
• How hard is it to get a joy-con to update to non-Nintendo-made firmware? (does firmware need signed keys, etc.)
• How much capacity do the joy-cons have for stuff like MFi? (it's not worth it to try if the joy-cons don't even have enough ram/rom to manage the standard BLE/HID stacks and the separate MFi stack)

[CTCaer]

• Somewhat easy. You need a custom hidraw in linux to enable DFU mode and a simple "flasher" program. You can flash only the SPI though. You can't touch the ROM. The actual format for these "firmwares" is Broadcom PatchRAM.

• You just write a compatible Patchram that patches the ROM and RAM on boot, and you flash it at the correct address inside the SPI

• You can write around 448KB of PatchRAM. The RAM capacity is 64KB + 288KB.

For more on PatchRAMs check https://github.com/shuffle2/nxpad. Read the commits and the IDA parser script. It explains some of the entries in a PatchRAM. Also check the issue there, I explain the initial PatchRAM "loader" at the start of SPI. I can provide some more info on PatchRAMs if you want.

Additionally, there is a less time consuming way to flash though. I have a custom Joy-Con "firmware" that when you flash it via DFU the first time, you can then write to SPI anywhere via spi write subcmd, instead of going into DFU mode and you just reboot the controller. Maybe I can also provide you the incomplete flasher I have, but with your own risk.

Lastly, if you don't have a SPI Programmer, buy one. You will need it, if the PatchRAM you wrote in SPI does not work correctly. The joy-con do not have a recovery mode, they just bootloop.

[TuxSH]

Additionally, it would be very nice to have something to transmit UART data given by the console to the PC via bluetooth and vice-versa for low-level debugging.

How hard would it be to implement such a feature (I know that you need to remove auto-pairing/make the joycon not drop the BT connection) and/or is there anyone working on it?

[CTCaer]

It's probably possible. But it would be easier to change the initial patchram-loader to check for a key press and load stock or custom fw. And that means that it would be easier to create your own patchram from scratch to only do this job: Initialize UART and stream it through bt. Because adding stuff is not so easy as patching stuff.

But patching should also be doable. Maybe sth like copying and stripping the uart buffer to bt buffer. (I utilized usb-uart together with bt through stock patchram before).

I know there are some people trying to get this working (I'm not one of them). But I don't know if they made any progress.

[TuxSH]

And that means that it would be easier to create your own patchram from scratch to only do this job: Initialize UART and stream it through bt.

Doesn't that mean you lose the ability to reflash that joycon. Sorry, I'm not really experienced/comfortable enough with joy-con stuff.

[CTCaer]

The SPI region locking is actually locked in PatchRAM-level. I have unlocked patched fw that allows you to make a firmware update through normal bthid.

Also, if you are creating your own fw from scratch, I assume that you'll give unrestricted access to SPI.

Last and most important, the DFU function is baked in ROM. You can only restrict it with PatchRAM. So with default config it should always be enabled.

[ghost]

Could this be used to enter rcm mode?

[CTCaer]

nope. Joy-con has a pull up resistor there.

[daurnimator]

Has anyone made progress on a joycon custom firmware?