dom0ng
commented
3 months ago in pcileech_pcie_cfg_a7.sv you have rw 20 and 21 with 0s rw[20] <= 0; // CFGSPACE_STATUS_REGISTER_AUTO_CLEAR [master abort flag] rw[21] <= 0; // CFGSPACE_COMMAND_REGISTER_AUTO_SET [bus master and other flags (set in rw[143:128] <= 16'h....;)] in pcie_7x_0_core_top you have parameter MPS_FORCE = "FALSE"+ default BARS parameter [31:0] BAR0 = 32'hFFE00000, parameter [31:0] BAR1 = 32'h00000000, i bought this device to make fw, and i have FFFF0004 BAR0 and FFFFFFFF BAR1 Did you forget to change that, or is that how it should be?
- why you use 6h10+ 10h40 not 6h0A+ 10h0A? parameter [5:0] EXT_CFG_CAP_PTR = 6'h10, parameter [9:0] EXT_CFG_XP_CAP_PTR = 10'h40,
Q) rw[20] <= 0; // CFGSPACE_STATUS_REGISTER_AUTO_CLEAR [master abort flag]
A) Master Abort happen when the master device attempts to access the target device. If the target doesn't respond within a specific number of clock cycles, the master terminates the transaction. This termination is called a "master abort."
Usually happens when you try to read memory out of range (at least on pcileech-based project), it happens. Clearing it doesn't make any sense, it happens also on lot of real and original device.
Also when happens, I don't think they're any real and original device that clear it every ms. If you think it's a detection vector for any anti-fun company, then clear it.
Q) rw[21] <= 0; // CFGSPACE_COMMAND_REGISTER_AUTO_SET [bus master and other flags (set in rw[143:128] <= 16'h....;)]
A) Well, both device and driver can write to the command register, but in *MOST of case, those register are written by the driver at initialization and should be 0000 if no driver are present.**
Example of detection/illegal firmware : Firmware have no driver, but have rw[21] <= 1, mean have command register set to 0406.
Well, this shouldn't be possible in a real world scenario.
Q) "FFFF0004 BAR0 and FFFFFFFF BAR1"
A) You should be correct, most of them (real and original device) have I/O as BAR1 or BAR0. But the fact is :
On actual state, no anti-fun company monitor BAR (thoses values are mostly dynamic between motherboard) And its risky to access them also (can hang out a lot of system because of I/O)
Please note this is a example project, so is not perfect :-) Great catch tho. I'm glad you did buy the real device to clone it and not blindly copy paste this repo :-) This is indeed a mistake/forget.
Q) why you use 6h10+ 10h40 not 6h0A+ 10h0A?
A) Laziness, both way works. Starting at 40 allow me to take control of everything <40 using core_top. And everything after >40 using .coe file.
It's not suggested to do it this way (to match the configuration space) This is honeypot and will introduce invisible flaw (detection vector for the right brain), but it works for the example, proven to works on FACEIT, until they decided to block the real device.
in pcileech_pcie_cfg_a7.sv you have rw 20 and 21 with 0s rw[20] <= 0; // CFGSPACE_STATUS_REGISTER_AUTO_CLEAR [master abort flag] rw[21] <= 0; // CFGSPACE_COMMAND_REGISTER_AUTO_SET [bus master and other flags (set in rw[143:128] <= 16'h....;)] in pcie_7x_0_core_top you have parameter MPS_FORCE = "FALSE"+ default BARS parameter [31:0] BAR0 = 32'hFFE00000, parameter [31:0] BAR1 = 32'h00000000, i bought this device to make fw, and i have FFFF0004 BAR0 and FFFFFFFF BAR1 Did you forget to change that, or is that how it should be?