It definitely does the same function, but there most likely are some minor differences. Using the U-boot from Ph3 would probably work (but since you said you've already extracted module 0800, you can just use the one from there). But the further we go (with kernel, and then user space software), the higher the chance there are some minor differences. Maybe In1 uses different video bit rate, maybe it uses some different GPIO lines - we can't tell if they're 100% compatible.
Also note, most wrapper tools are only able to flash u-boot. So if you're seeing "ERROR: can't get kernel image!" on the serial console, or if the kernel starts booting - these tools will not help. Use the `dji-firmware-tools` instruction in that case.
Finally,
This TIs `sfh.exe` utility is only really designed to flash u-boot. For kernel, there's a different procedure. Though I guess you could use the same way to flash the kernel, but you'd have to get sources of the `sfh.exe` and modify it to write to different place, and to expect larger input binary. Or I don't know, maybe the command line parameters it supports are enough to cheat it into flashing the kernel.
But you won't be able to flash root filesystem using `sfh.exe`, as it doesn't support the hardware parity which UBI File System utilizes (root filesystem is made with UbiFS). With invalid hardware checksums, sectors will be marked as bad after first read - so it will boot at most once.
You will find proper instructions for writing the root filesystem
on github.
There's also the encrypted partition - it can be copied normally, but its content is different for each drone, as it's encrypted using a key stored in external SHA204 chip. So if rewriting everything from a specific board, it might be wise to save the content of this one. There are ways to make everything work without it, but this adds yet another level of complication to the whole process.