OTG update of firmware of board_B from board_A

[chaserhkj]

Hi there. This idea is basically a casual wandering-off of my ADHD brain over the last weekend, but I eventually managed to implement it myself (although very rough), so I decided to share it here.

So I have got the deskhop hardware assembled last week and has been tweaking around with the firmware to my need a lot. All changes are in my fork.

One of the problems I have during hacking is that it's not very easy to flash firmware on deskhop on my setup. The main reason is that two of my hosts are a Gaming Windows desktop and a Linux Workstation. The Windows machine does not have any coding/development stuff whatsoever and most of my development tools are on Linux (like any sane people may do), so I can only update firmware from Linux. Also I have the deskhop board enclosed in 3D printed enclosing and then put to the back of my desk (so that I do not need to look at the cables)

This makes it a convoluted process for me to update the firmware on both boards once I have made a change. I have to pull deskhop out of the back of my desk and pry the enclosure open, and then transfer my keyboard and mouse plugs to my Linux workstation, then while press BOOT on each board and plugging them into my Linux machine to enter bootloader and upload firmware.

I know there are shortcut keys for entering bootloader on both boards, but the problem apparently is I have to change plug which requires physically pulling the hardware out. Ideally, I want to have a script running on my Linux host polling for pi picos in bootlooader mode, and then press the entering bootloader keys for A and B consecutively to upload the code.

I looked into how this could be implemented and came across this project implementing a serial-interface bootloader on rp2040 chips. This idea is I keep board A with the stock bootloader and connected to Linux host, so I can directly update code on A by using the aforementioned script and press firmware upload key for A. When I need to flash firmware for B I press another key bind to instruct B to boot into serial bootloader, and then switch A to a UART relay mode so that my Linux host could relay through A to B and flash firmware.

The idea sounds straightforward, but oh trust me my process to implement it was not straightforward at all and I had a lot of issues and fell into a lot of traps that some new starters in embedded programming like me may well fall into. But after one weekend I did get one working version in my fork. and I can now just stash deskhop to the back of my desk and hopefully never need to pull it out again.

I want to know what is @hrvach 's thought in this feature? Is there anyone else who would be interested in this? The fork is very far from merge-able (since it is a custom build I deleted a lot of feature code that I do not need), but I could try to port the changes to main branch if there are indeed interests.

Here is a short list of changes so far I have made in the fork in case anyone is interested

• Use hard-coded screen maps to determine output switch, since I have very irregular screen setups
• Since I sometimes switch my screen layout as well (main screen for work vs main screen for game), I add multiple screen layout profiles and uses raw hid frames sent from my host by a script to switch between them.
• The UART relay's host side is actually sent through HID frames as well! It is a bit slow, but well fast enough for firmware of this size and it avoids adding another descriptor.

[kpfleming]

I implemented DFU support in a branch, although I've now abandoned it (see below). It would have allowed firmware flashing (and configuration download/upload) without requiring physical access to the boards at all.

Separately, @hrvach has implemented major upgrades in the upcoming 0.6x release, one of which is that it will now be possible to upload firmware to just one board and then it will push the updated firmware to the other board. That branch may also offer the ability to upload firmware without having to put the board into 'boot' mode.

[hrvach]

Hey! The upcoming release has firmware upgrade a bit overhauled to address the problem of weird key combinations and accessing the boards. I was looking into implementing mass storage to serve the config page and then figured out it could also be used to upgrade firmware based on the same code. Because it essentially runs from RAM, you can upgrade the flash while the device keeps operating (although serial transfer makes the mouse movements a bit jerky, I have to implement some queue prioritization).

TL;DR - to upgrade, you'll have to press a key combo to put the board into config mode (security feature) and then simply copy on the usb drive that appears ... after the upgrade is done, it should get pushed to the other board automagically. No software required at all.

Also make sure to check @kpfleming 's variant (https://github.com/kpfleming/deskhop/), he has some awesome skills and ideas including a standalone PCB with additional power connectors, DFU upgrade mode and a bunch of other improvements.

As soon as I get some time (very busy at work) I'll update the docs and promote the RC to stable, seems stable enough. Btw you did a whole lot of functionality in one weekend, respect! I like the inotifywait approach, and the HID carrying data idea is pretty cool too. I saw you found some bugs (fix mod key stuck commit), would you be OK with me using those fixes?

[chaserhkj]

I never noticed that there is a RC branch before this (oops), but I'll surely check it out!

Also it was until I looked at you guys' ideas that I realized that I can actually write the flash in normal firmware, I just need to use the appropriate functions to directly interface with the flash. It seems that I've got too used to working with full OSes that I kinda of implicitly think that you have to update the main firmware from a bootloader. Nonetheless hacking with the bootloader was fun and I learned a lot about how these chips work and how to handle the binary code using objcopy, etc.

The HID data packets have been something I wanted to do with QMK keyboards for ages (e.g. switching keyboard layers according to software context by HID packets from a host daemon) but kept getting postponed. It's on deskhop that I actually had the chance to try it! I thought about using the same mechanism to do dynamically configurable screen layouts, but eventually ditched the idea to just hard code the layout since I'll probably be the only one using the fork.

The new web config in RC branch looks neat, I think what might be more valuable to merge into the config interface might be the screen bound check code I put in that can check bounds in more complex screen setup (here and here) , since this looks like a popular request from the main feature request thread. We'll need the UI to do that efficiently on the web interface as well, though.

As for the fixes, unfortunately I am not sure all of them work (I reverted one after finding out it doesn't work), but if any of them can be any use to you feel free to port it.