Segger J-Link to program P2

Per the docs:

I can quickly program devices in bulk via nrfjprog. This process was great, I use it all the time for Boron devices. We ended up creating a Python script allowing me to do a bunch of steps in the commissioning process. I use to always just use this single command in Python in in seconds everything was loaded:
os.system("nrfjprog -f NRF52 --program {{my program}}.hex --chiperase --reset")

However, now I'm onto P2 modules and per the docs:

This technique cannot be used to program the P2 (RTL8271D) or Gen 2 (STM32F205) devices, but you can use the Segger tools like J-Flash instead of nrfjprog to program Gen 2 devices with the Segger J-Link.

Looks like there is PyLink to control J-Link with Python. So it looks doable to still use a Python script. Before I try to automate it, I thought I'd try it with J-Flash light manually, However, my J-Flash Lite doesn't have the right Realtek device for the P2(RTL8271D). Can I just choose one of the other ones or what am I missing?

Also, there are some cautionary tales to never "erase chip" on a P2 in the docs and use the correct address when flashing the .HEX. P2 Flashing

Just to make sure I don't mess this up, would someone be able to provide a screen shot like this when using J-Link Flash to flash a .HEX file that was created using the hex file generator?

Once I can do it in J-Flash Lite, then I'd try and update my Python script to do it. I did the first 30 P2 modules manually, via "Particle: Flash Application and Device OS" from VS Code. It's certainly doable just takes a lot more time compared to SWD/JTAG and trying to speed things up eventually.

There currently isn't a device file for for the Segger J/LINK to program the Realtek RTL872x MCU, unfortunately.

It is possible to program the P2 using the Particle debugger or a generic CMSIS/DAP debugger using SWD, just not the J/LINK at this time. Be sure you don't accidentally overwrite prebootloader-mbr or chip erase when using SWD as the device will never be able to be recovered because of SecureBoot.