Well, when the device boots a "normal" way, it is done via the CPU reset vector. CS signals get pulled low, device registers are clered. Then the OS loader initializes pretty much everything to zero, memory areas are cleared and devices get a fresh start, starting from "known zeroed states".

When ubiboot (or other kexec-like boot loader) is used, the first stage kernel gets this "good initialization". When the 2nd stage kernl boots, device drivers have been running and HW is not in pristine state any longer. Even as the kernel itself gets a fresh start all the devices remain in the state the previous kernel left them.

Well, what I think is that the difference should be visible in working of the target kernel, so for example when you boot the L2fixed kernel with ubiboot or directly, there might be differences in dmesg, and more so in syslog as there could be info from applications that might reveal something.

So, If you could start the same kernel both with ubiboot and flashed directly, and after it had booted up attempt to use SIP call.
Take /var/log/syslog and dmesg from both cases. Also the ubiboot.dmesg might be good even though I think it's the target kernels logs that are important.

Then, of course debugging the SIP call itself, I am not that familiar with it but indeed you could traceroute the destination, check your iptables etc..