Having taken over the MCU and being able to load my own firmware, I had a few different directions I could go. First off, thanks to a hackaday member (who I'm not mentioning because I didn't ask if was ok first), I have a lerdge-K board to test with. It technically has a broken port on it, but for what I'm doing, that matters exactly zero. 

I'm working now on writing up the bootloader dumping process, and one goal is to build a firmware that if loaded using the default firmware, saves off flash, CCRAM, and SPI RAM. This will be the "You can always go back" sketch. To do that, I have to get SDFAT playing nicely with ST's arduino core and thus far, I'm not having a ton of success. It *might* be simpler to write it as a CubeMX project rather than Arduino, but time is not pressing here. I can afford to tinker, or wait.

And speaking of waiting, waiting brought a USB PR to the official ST arduino core. I integrated that into my build, but my macbook air crashes every time I plug in the lerdge, because the CH drivers are probably buggy. With no serial and no USB, I fell back on debug via LED (similar to my fan debugging for the Malyan M200) and now have a marlin 2.0 build which starts up, runs for four seconds, and then resets when the watchdog kicks in.

This implies that the watchdog isn't getting fed, and given what I just went through with the M200, I'm going to start by validating which timers are in use for PWM and make sure the temperature ISR isn't getting obliterated by ST's "only hardware PWM, ever" core.

The other thing I've been doing is researching the LCD. Once I can get code running solidly, I can afford to build some tests around this, but for now, I'm looking at how the bootloader interacts, and I've basically worked out a few key things.

1. The LCD uses "normal" exit from sleep, write to ram, set x and y commands. As in I can find other LCDs that use the same commands.

2. The Bootloader initializes LCD pins that don't seem to be connected on the Lerdge-X, supporting the theory that the X and K use the same bootloader (this would certainly make sense - the S does NOT, from what I can tell). most graphics are done using point by point drawing rather than a blit from RAM (the equivalent for LCD). 

So, now the less fun work begins. Working out timer conflicts if any. Figuring out how to configure the library and gain access to the SD card. I published to Github my preliminary pins file for Marlin 2.x. One day this will likely be a PR, but it will be AFTER I figure out all the conflicts.

There will likely not be an example configuration file for the lerdge, because this is a board you stick in other machines, not a machine definition by itself.