Hi Diego,
Thanks a lot for your reply. Turns out I was using the October manual release which missed this information.
I tried this solution, and unfortunately it doesn't work. All it does is trigger a reboot and start the application normally again. I've found a number of problems, and confirmed via disassembly that "runBootloader" only does a soft reset, and nothing else.
The "0x1301fe00" in the RM points to zero-valued memory on device, so it is probably incorrect. The address used in the 2.7.1 SDK "0x130010f0" for the BOOTLOADER_TREE_LOCATION seems right (see flashiap1/drivers/fsl_iap.c). (also this 0x130010f0 is referenced elsewhere in the RM).
Using the 0x130010f0 address for the BOOTLOADER_TREE_LOCATION location, it points to the following data, which I've readout.

It seems to match to the "bootloader_tree_t" type correctly since I can see the version numbers and copyright string. So "runBootloader" resides at address 0x13014939.
Looking at the disassembled code for the function at 0x13014939 though, it's a bit disappointing. It takes no function parameters, and all it does is a normal system reset (using the ARM SCB module mapped at 0xe000ed04).

Basically, it just writes 0x5fa0004 to SCB->AIRCR, and then goes into a infinite loop, which is exactly how an ARM soft reset is done.
How else can I enter the bootloader? Or what is the correct address for "runBootloader" if there is one? This is all on the same 1B chip, and I've verified that bootloader mode works after mass-erase.