Hm, the guy in that thread is using the same DOS tool as found in the Startech firmware upgrade package, just telling it to write different vendor IDs so it can fool MacOS into loading and using the best vendor drivers available, he is also using settings defined in the CFG.INI text file.
He seems to be focused on the
uPD720200 & uPD720200a, and not on our chipset, which is the uPD720201/uPD720202.
Although it does not matter much, commands and settings are the same. In his OP in the instructions he is just detecting the chip revision and flashing different firmware depending on that.
He also says in the OP that his firmwares are “latest ORIGINAL” so there is no firmware mod.
The readme in his package (for our Rensas chipset it is linked in post 34 of that thread) and in the Startech firmware upgrade package explain all possible options in the CFG.INI text file.
That’s neat, I didn’t look at that readme yet.
The DOS zip is the “full vendor SDK” as it allows to define all settings, what ports should be disabled, forcing connected devices as “not removable”, power options and “battery charge mode” for ports, and a switch to block the generic FW update tool that runs in Windows from updating the chipset (to allow the illusion of vendor-specific firmware).
His link for the tools for our chipset is old, so they are flashing firmware version 2.0.0.6, not anywhere near the latest, even for 2013, as guys in the thread complain they had newer firmware on cards they bought. But he does not explain why nor answer him, I guess he isn’t much interested in that chipset.
Anyway, these are the options in his file for the uPD720200 & uPD720200a
[SubSystemVendorID]
FFFF
[SubSystemID]
FFFF
[UsePPON]
1
; Set to '1', if you control the VBUS by PPON pin function of uPD720200/200A.
; Set to '0', if you don't use PPON pin function of uPD720200/200A.
; This configuraiton is reflected in HCCPARAMS(Bit3) of Host Controller Capability
; Register. See the User's Manual(Table 3-78). Default Value is '1'.
[EnableDeviceNonRemovalPort1]
0
; Set to '1', if the Non-Removable Device is connected to Port1&Port3(U2DP1,U2DM1,
; U3TXDP1,U3TXDN1,U3RXDP1,U3RXDN1) or Port1&Port3 is unused.
; This configuraion is reflected in Device Removable(Bit30) of PORTSC Register
; on xHCI. See the User's Manual(Table 3-90). Default value is '0'
[EnableDeviceNonRemovalPort2]
0
; Set to '1', if the Non-Removable Device is connected to Port2&Port4(U2DP2,U2DM2,
; U3TXDP2,U3TXDN2,U3RXDP2,U3RXDN2) or Port2&Port4 is unused.
; This configuraion is reflected in Device Removable(Bit30) of PORTSC Register
; on xHCI. See the User's Manual(Table 3-90). Default value is '0'
[EnableClockRequest]
0
; Set to '0', if you want to disable the CLKREQ#(ClockRequest).
; There exist PCs which has problem in its CLKREQ# function for ExpressCard slot.
; It is recommended to disable CLKREQ# function, if the product is ExpressCard.
; Default value is "1".
The first two are just IDs (you are supposed to write an ID from the list in his OP instead of the FFFF), and IDs matter only for drivers, but for a KVM setup we are force binding the Rensas device to VFIO when in Linux anyway, and VFIO does not care.
The other options are all set as default apart from the last one, [EnableClockRequest]
that is some workaround for an ExpressCard bug on some PCs that report the CLKREQ# in a bad way.
In his OP he talks about ExpressCard so he might have done that because back then in 2012 when he wrote that post it was still a thing?
The config he uses for our Rensas chipset (from the package he posts in post 34 of that thread) is just plain default options, [EnableClockRequest] included.
All in all, I don’t think it’s necessary to test any of this, so I’ll leave it at this “preliminary stage conclusions”.
Anything he does is changing device IDs and this does nothing on the host if the card is just bound to VFIO.
I have no idea if Linux drivers for Rensas chipsets will work if you change the vendor ID (they probably won’t), but if it’s bound to VFIO it won’t work in the host anyway. In any case you can always change the IDs later if you want to move the card somewhere else.
There is also no indication in his thread about using specific or modded firmware for MacOS so whatever is latest firmware should be OK, the main point of his thread is changing the vendor ID so MacOS will load good drivers for this device.