Closed kakaroto closed 5 years ago
Thank you! You right, the first mistake relates with default configuration of OpenIPC. Please, try this fix https://github.com/ptresearch/IntelTXE-PoC/commit/4e6f844a06c204356a330da728b35ebdcb85a2a1
What version of Intel system studio do you use?
Thanks @h0t for the quick fix. The patch in https://github.com/ptresearch/IntelTXE-PoC/commit/4e6f844a06c204356a330da728b35ebdcb85a2a1 works for the config issue but now the command needed is patch -p2
instead of patch -p0
.
Also note that the files in OpenIPC/Config use CRLF line endings while the files in OpenIPC/Data is LF line endings, so patching the config files gave me a "HUNK FAILED (different line endings)" for Config/BXTP/Default_TCI.xml and Config/OpenIpcConfig.xml (until I did dos2unix on them). There were no issues in patching the files in the Data directory.
Note that I was using patch
from a linux system to patch a Windows IPC installation.
I am using Intel System Studio 2018.1.051_ultimate_edition_windows which has DAL 1.9.9588.110 and OpenIPC 1.1740.2381.100 (same as you as far as I can see). Do you have any guesses about the stepping issue? I've tried a fresh install of Windows 10 on a new PC and a new install of System Studio and followed your instructions and I'm getting the same behaviour on this second PC as well. Did you try a fresh install to see if it works? And if not, then are you able to see what's the difference between your working install and the fresh one ? Thank you!
Hi @kakaroto
We've found that stepping determination procedure (in encrypted OpenIPC's Python scripts) for Broxton P is extended in System Studio 2019 Beta, so there are chips with newer stepping than B3 (as in our case), but System Studio 2018's OpenIPC doesn't know them. We recommend to simply change
Hi @markel777,
Great, thanks for that, I can confirm it works!
I'd suggest having a different patch file for the target System studio version (2018 vs 2019 beta, and maybe windows vs linux version due to the CRLF/LF issue with the current patch).
Current patch (from the issue-ipc-configuration
branch) requires patch -p2
instead of patch -p0
(Change the "./a/OpenIPC/ ./b/OpenIPC/" into "OpenIPC_orig/ OpenIPC/" to fix it) and the Config files fail to get patched due to CRLF/LF difference.
Downloading the linux build of System Studio is slow, so I'll look into whether there are CRLF differences between windows and linux versions and I can fix and send a pull request tomorrow.
Thanks again for the great work!
Thanks! I will fix this problem. Could you give me version of you boards please?
The default ipc configuration problem solved in https://github.com/ptresearch/IntelTXE-PoC/commit/de438152026f24ae07149f680218f4d690f5438f
@kakaroto What is your DbC-cable length?
@h0t Great, thanks for the fix. I'm using the SVT CCA, but I've just tried again with the USB debug cable and it worked without problems, I'm not sure why it didn't work with DbC before. I have the 10 feet DbC cable.
The Gigabyte Brix GB-BPCE-3350C I have has a "rev:1.2" on the motherboard's silkscreen. I can also confirm that I have it working on a Beelink M1 (though that one has a low profile flash (WSON8 I think?) which required me to solder wires to it as I can't use the SOIC clip on it), which I tested on first since it was very hard to find the BRIX (had to have it shipped in Europe then forwarded to me in Canada).
By the way, I can also confirm that the files in the OpenIPC Config directory use CRLF on Windows but LF on Linux installation of System Studio 2018.
Hi, I'm trying to reproduce the PoC on a similar Apollolake machine without success. I managed to test on the same Gigabyte GB-BPCE-3350C hardware you used to make sure the issue isn't from my hardware. First missing step in your README has to do with setting the configuration. When attempting to run
ipc = ipccli.baseaccess()
, we run into this problem :Setting the config to "BXTP_Default_TCI" (as it appears in your console screenshot) gets it further, the console output looking much more similar now to yours.
The second issue in your README is that all the screenshots of consoles show that you are using the SVT CCA (due to lines with "DCI: CCA FPGA image is already up to date", etc.. ) but your instructions specify using a usb debug cable. I've tried the usb debug cable (bought from datapro.net) without success (nothing is detected) though I didn't spend much time on it as I also have the SVT CCA and I'm trying to reproduce your efforts using the same hardware.
Now my issue is that instead of getting these messages (which is what your screenshots show) :
I instead get this :
So my issue here is that the stepping could not be determined. In your screenshot, it detected stepping B3, but it didn't for mine, which is why it couldn't use the LMT config and I don't have access to the mdu_dfx_agg_tap0 device. My devicelist actually looks like this :
I'm wondering if the reason the stepping can't be determined is related somehow to the missing configuration step. Is there anything else I need to change for it to work? So far I haven't been able to figure out what I needed to do to get it working.
Thanks.