@sidepipe Correct, after RouterBOOT finally implemented user-defined partitioning, it passed several parameters on the kernel command-line to communicate the partitioning structure to the kernel, and then they patched the kernel to look for those values. Before that time, AFAIK partition structure was just hard-coded into the kernel patches for a given board.
In RouterBOOT config, you would specify from 1-8 partitions, and then total NAND capacity would be equally divided into that many parts, except there would actually be 2 partitions for every configured one: one where the kernel lived by itself, and one where RouterOS lived. So for "2 partitions" there would be 4 (2 kernel and 2 OS). If partitions > 1, then "parts" would be # of RouterBOOT-configured partitions, "activepart" would be which 'partition' # was being booted, and "boot_part_size" would be the size of the kernel partition for that partition pair in octets (I don't know how RouterBOOT determines this as it is not user-configurable; perhaps it is hard-coded in a given board model's RouterBOOT).
So for example, on most mipsbe boards, boot_part_size is always 4194304 (4MiB), so on a 128MiB NAND with "2" partitions, there would be 4 literal partitions under-the-hood, arranged as:
4MiB (kernel 1)
60MiB (OS 1)
4MiB (kernel 2)
60MiB (OS 2)
All 4 would be the same underlying FS (YAFFS or UBIFS depending on board model). Kernel has to be called 'kernel' on the boot partition, and RouterBOOT knows how to read YAFFS on boards that use YAFFS, and how to read UBIFS on boards that use UBIFS.
Many moons ago, I got all of this to work on old Kamikaze builds. I took a version of the MikroTik kernel patches nearly verbatim and used that as the basis for the kernel in my own builds. With this OWRT frankenkernel, it was possible to dual-boot between RouterOS and OpenWRT on the same device.
Anyway, the main point I was trying to make is that as things stand, @tkellen isn't going to be able to take a stock LEDE image for this board and gain straightforward read-write access to the partitions on the NAND that RouterOS laid down. To your point, it would indeed be relatively easy to come up with a LEDE kernel that understands how to replicate the partition structure communicated to it by RouterBOOT, but nobody's done it yet.
As I recall, there is no difference from RouterBOOT's perspective between an ELF kernel image booted from flash and one booted from the network. You could literally extract a RouterOS kernel from an NPK and netboot the darn thing (though you'd better have an OS partition on flash that matches it, because it's going to try to mount it to finish the boot), and also it's no problem (assuming it is small enough to fit) to take an image intended for netbooting (complete with initramfs) and copy it to the boot partition while naming the file 'kernel'. It'll start. This being the case, what was puzzling me is the fact that clearly someone got working a bootable ELF image for this board, and ironically what it's being used for is wiping out the bootloader that it supports being booted by! Seems at that point like the thing to do would be to make building RouterBOOT-compatible ELF kernels a supported option in LEDE Buildroot.
(I don't know this for a fact, but my suspicion is that when it comes to bootloader console support, it doesn't exist in this particular RouterBOOT merely because the board has no user-exposed RS232 like some models do...RB7xx and RB9xx series boards have never had RS232 ports, while other RB series continue to supply them, even on new models being released in those series present-day. And on those models, RouterBOOT still supports the console. So I'm quite certain this is not an attempt by MT to make it harder to access or manipulate. I'd bet money all RB models without RS232 have a RouterBOOT built without console output.)
I'm hoping to get a hEXr3 myself to play with soon...if I manage to get this working myself I'll be sure to report back...