At the time I began looking at this, I saw a couple of primary options. The first was to port Marlin 1.x to SMT32 by simply converting the core functions, however, as I was reading, I found a thread where the marlin developers were discussing STM32 support in 2.0.x

Having never interacted with github before, I admit it took me way longer to discover the branch drop-down than it should have. 

Hooray: There's Marlin 2.0.x with a layout that indicates there's a HAL for some different architectures--but nothing for STM32.

This was not surprising.

I knew there was an arduino core for STM32 called Stm32duino, and I figured I would simply write the HAL. So I ordered a couple of bluepill development boards from China for five bucks each, and sat down to learn everything I could from what I had on hand already.

The V1 (and some V2) minis run on an STM32F103C<x> class microprocessor. I say "class" because the STM32 hardware is sometimes a bit odd. In theory from the chip description, you know how much flash is available, how much ram, how many timers, and so on.

In reality, it's probably far, far cheaper for ST to use the same core parts on most chips and badge them differently. Most C8s come with 128k of flash even if they're labeled as 64k.

The Mini's processor clearly says C8 on some boards and CB on some, but the motion controller firmware is ~84k regardless, so Malyan (the manufacturer) were taking advantage of it.

I knew there was a bootloader on the core machine, because without a programmer, I could update my firmware, but I didn't know how large the firmware was, where it jumped to, or anything about it.

To make things more difficult, Malyan set the read protection bit on the CPU, meaning that ST-Link devices couldn't simply read out the firmware and bootloader. 

So, while I waited for my bluepills, I broke out a hex editor, Hex-fiend, and began looking at firmware revisions.

The first few bytes of any ARM image are usually the initial stack pointer and a series of interrupt addresses that are used for the vector table, and these vector addresses uniformly pointed out past the end of the ROM image.

No worries - since I knew there was a bootloader, I already expected that image's actual address would be the flash base + some offset.

In particular, I was looking for interrupts which would map to either an infinite loop or a immediate return.

And it turns out, if you posit an 8k bootloader, everything begins to line up.

My Bluepills arrived around this time, and that's when the real fun began.