What's happening now is a period where there isn't going to be much interesting to see. I'm looking at how the firmware and bootloaders manipulate the lerdge hardware for clues to how I will do it myself. Most of this is done in binaryNinja, and the process is intexact. I name a function, rename it as I understand what it does, rename it as I make progress.
The LCD controller remains unknown, and right now I can't init FSMC to attempt to read the id out. However, I have been able to decipher chunks of functionality. How? Well, while many LCD controller commands are unique, they tend to share some commonalities, which is why I've guessed this is likely a fill:
The 2A is X location, the 2B is Y, and the other variable is probably a color. The loop repeats a write.
How about some others?
This is some of the code which intializes the LCD. Unfortunately it doesn't save off the results of the id/model read, but once I can init the FSMC correctly, I'll write my own version.
And what about the SD Card?
There we go. The SD Card initialization code. I am slowly learning the details of the FSMC & SDIO components, but it's going to be a while. In the mean time, I'll be soldering leads to the lerdge-x wifi printing module. This accepts a standard ESP8266-S1, and the header has nice pin tops for the SWD leads. Pictures of that when it's done, and then I'll 100% dump the lerdge-K board. The bootloader actually initializes some hardware that doesn't exist on the -X, which makes me think the X and the K share very, very similar hardware.
Oh, and one Hackaday user reports that the base bootloader, when flashed on the -S, boots up. I haven't done so, and I frankly didn't expect it to work. The -S bootloader, when downloaded from Lerdge's website, is certainly different.
One goal, when SD works, is to build a dumper which saves off the firmware, CCRAM, SPI Flash, and if possible, display RAM. Then, should there be updates, users can save off their own.