Tracked down the necessary patch to make ipmi work again.
*When excuting a command like:
modprobe ipmi_si ports=0xffc0e3 type=bt
The system would get an oops.
The trouble here is that ipmi_si_hardcode_find_bmc() is called before ipmi_si_platform_init(), but initialization of the hard-coded device creates an IPMI platform device, which won't be initialized yet.
The real trouble is that hard-coded devices aren't created with any device, and the fixup is done later. So do it right, create the hard-coded devices as normal platform devices.
This required adding some new resource types to the IPMI platform code for passing information required by the hard-coded device
and adding some code to remove the hard-coded platform devices on module removal.
To enforce the "hard-coded devices passed by the user take priority over firmware devices" rule, some special code was added to check and see if a hard-coded device already exists.*
The patch was backported to 4.19.37. Used the backported version from here. https://github.com/raspberrypi/linux/commit/6bba17f6bce39e46fdf8c0fe190bdc3f57ef8f8f
Once applied to the 4.19.19 sources
modprobe type=kcs ports=0xca2 ipmitool sensor
works. I tried it with an debian usb system with pristen 4.19.19 sources.
Is it woth the effort to prepare the patch for the xcp-ng kernel "kernel-4.19.19-188.8.131.52.xcpng8.0.x86_64.rpm"?
I assume it has to be signed by microsoft to make it work with secure uefi.