Think about what to do with the boot ROM

Even our minimal SDK depends on some features of the proprietary boot ROM (such as function calls into it for utility functions and hardware control functions).

A dump of the proprietary boot ROM has been attached to this issue. It was created by running esptool.py dump_mem 0x40000000 0x60000 rom_dump.bin rom_dump.bin

The way I see it, we can either

1. Load the boot ROM into qemu (full-featured, a bit tricky to implement, licensing issues mean we can't distribute it ourselves)
2. Patch the SDK, so that it doesn't try to use these functions (programs that run on real hardware would still probably have to call them, meaning all programs would need 2 separate builds)
3. Re-implement relevant functions (no licensing issues, compatible, but hard work)

A relevant resource (although for a different, Xtensa-based ESP): https://ratzzo.net/index.php/posts/a-guide-to-reverse-engineering-the-esp8266-internal-rom