With the help from Jason, Dzenik, and jmz52's help I was able to adapt my custom version of Marlin4MPMD to work with the LerdgeX hardware.  The majority of the work was spent adding in the STM32F4 HAL library instead of the STM32F0 HAL library, and then running through inconsistencies with the Lerdge hardware.  As a proof of concept I now have full functionality including motion, auto bed leveling, SD support, a janky looking version of the Marlin GUI, and Octoprint support.

Because it is derived from Marlin4ST originally, the fork is based off of an older Marlin 1.x base and is only compilable through openstm32, which is a lot more complicated to generate and install binaries through.  Given the current development state of STM32 arduino support, it made more sense for me to continue bare metal development to make this proof of concept.  The right way to move forward however is to provide HAL support through Marlin 2.0, which is what future efforts will entail.

One of the key difficulties developing for Lerdge was centered around the issue of the STM security bits.  By default, both the bootloader and the application binaries include a piece of code that will enable the security bits of the processor.  This is intended as a copy-protection feature that will erase the entire flash memory if the device is reprogrammed over SWD.  However, by side-loading our own custom binary that reads out the entire flash image we can extract the raw code for the bootloader and application binaries and modify them to disable this check.  I've added a patched version of the 1.0.2 bootloader.  This is import because it allows direct debugging and loading of application code on the processor without triggering a full erase.

The LCD code was another challenge in that we had an unknown panel with an unknown pinout connected via ribbon cable.  Through some sleuthing we were able to determine that the communication was done over a 16-bit parallel data interface to the panel and the FSMC peripheral was used to send/receive commands.  After deducing that standard 0x2A(row select), 0x2A(column select), 0x2C(RAM write) sequence was able to change the colors on the panel, I deduced it was similar model to the ILI3941.  However, reading the device ID provides 0x7796, which indicates it is likely a generic ST7796 panel instead, which coincidentally shares the same command set as the ILI device.  With this and some code provided by jmz52 to scale up the Marlin output to a larger resolution, I was able to provide the Marlin GUI to cover most of the Lerdge screen.

This was intended as a proof of concept more so something to be distributed, IMO the best course of action is to wait until full Marlin 2.0 support is provided.