ERROR: PCI CFG write to enable ROM access failed

[AreYouLoco]

Hi,

First of all thank you for that tool. I was sure someone made that on github.

My controller works on one kernel (stock 4.19.x) but not on other (backported mainline 5.3.x ). Nevermind.

I tried to check if it's firmware fault first. So I get update 2.0.2.6 (http://www.station-drivers.com/index.php?option=com_remository&Itemid=352&func=download&id=1348&chk=bd3c73072d43c63d1d5857cb9e99c919) from da Internets and extracted UPDATE.mem from there and tried to check version and possibly update with your tool.

Seems like I have latest one looking at the major version but maybe there is some small revision difference. But your tool doesn't allow me to backup anyway. Here is what I get:

user@linux:~/code/upd72020x-load$ sudo ./upd72020x-load -r -b 0x05 -d 0x00 -f 0x0 -o ./firmware_bak.bin
Doing the reading
bus = 5 
dev = 0 
fct = 0 
fname = ./firmware_bak.bin 
got firmware version: 202609
EEPROM installed
got rom_info: 19d207f
got rom_config: 0
setting rom_config: 700
ERROR: PCI CFG write to enable ROM access failed
ERROR: cant enable access to ROM 
 ======> FAILED

Generated file is empty! Not a surprise since it didn't work.

user@linux:~/code/upd72020x-load$ du -hs firmware_bak.bin 
0	firmware_bak.bin

Some background: Debian 10 4.19.0-6-amd64 @ Thinkpad T420

user@linux:~/code/upd72020x-load$ sudo lspci -vv -nn -s 05:00.0 -G -M -H 1 -xxxx -k -t
Decided to use intel-conf1
Mapping bus 05
Discovered device 05:00.0
05:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller [1912:0015] (rev 02) (prog-if 30 [XHCI])
Using cache /root/.pciids-cache
Initializing UDEV HWDB
	Subsystem: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller [1912:0015]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 0
	Region 0: Memory at 91c00000 (64-bit, non-prefetchable)
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
		Vector table: BAR=0 offset=00001000
		PBA: BAR=0 offset=00001080
	Capabilities: [a0] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited
			ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
00: 12 19 15 00 06 04 10 00 02 30 03 0c 10 00 00 00
10: 04 00 c0 91 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 12 19 15 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 00 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 70 c3 c9 08 00 00 00 00 00 00 00 00 00 00 00
60: 30 20 00 00 00 00 00 00 00 00 00 00 09 26 20 00
70: 05 90 86 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 11 a0 07 80 00 10 00 00 80 10 00 00 00 00 00 00
a0: 10 00 02 00 c0 8f 00 00 00 28 19 00 12 ec 07 00
b0: 40 00 12 10 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 10 08 00 00 00 00 00 00 00 00 00 00
d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 03 00 00 00 01 05 7f 20 9d 01
f0: 00 07 00 00 00 00 01 80 4d 4f 52 53 00 00 00 00

Summary of buses:
05: Secondary host bus (?)

Any thoughts what might be wrong?

[AreYouLoco]

I tried this Pull-Request: #3 and it seems to let me at least read the EEPROM.

I compared (with vbindif) firmware file I've extracted from the updater *.exe (later UPDATE.mem) I have downloaded with the one I dumped (later firmware_bak.bin) with that PR-fix and they differ (different firmware version?) but the structure is similar.

Only the firmware_bak.bin file dumped with that PR-fix is full 64kb (I think it was the limit somewhere in the code.). But the actual data ends almost! at the same spot (UPDATE.mem data and file ends at 0000 32D0 and dumped firmware_bak.bin data ends at 0000 32F0, the rest of firmware_bak.bin is just filled with 0xFF till the end).

So maybe there should be some trimming added to the dump option to save some kb. @qmfrederik?

---

The question is: Is this dumped file ok?

user@linux:~/code/k2026fwup1/upd72020x-load$ file firmware_bak.bin UPDATE.mem 
firmware_bak.bin: TeX font metric data
UPDATE.mem:       data

Some magic numbers issue? I am scared to run write/update command before discussing the consequences @markusj.

[qmfrederik]

I have downloaded with the one I dumped (later firmware_bak.bin) with that PR-fix and they differ (different firmware version?) but the structure is similar.

Have a look at the μPD720201/ μ PD720202 User’s Manual: Hardware. Section 6.3.2.3 describes the data format for the external ROM data, and 6.3.1 describes the data format for the firmware (which is stored in the external ROM data).

• It is possible that the firmware is prefixed with Vendor Specific Configuration Data. I don't think you'll see the Vendor Specific Configuration Data in the firmware that ships with the driver. Plus, I think this utility doesn't handle the Vendor Specific Configuration Data at all (i.e. if you flash a card with this utility, I think the Vendor Specific Configuration Data will be lost)
• You can get the version of the firmware by looking for the header code (55AA) and then reading the firmware version pointer (4 bytes further). This will give you the address of where the firmware version is stored. You can use this to compare firmware versions.

[AreYouLoco]

Both of the files have [55 AA] [AA 02] but then comes [39 20] UPDATE.mem and [39 60] firmware_bak.bin.

So [55 AA] is the header, good. [AA 02] is some reserved shit, whatever. Firmware version pointer is let's say [39 20]vs[39 60] (which is some value^^? should I select the two and I got value in hex or decimal? is it 20?) so counting 20 bits from header I should have 2-byte FW version? Is that correct?

When I put the pointer in [55 AA] in ghex and then I use 'go to byte' +0020 I do get [00 69] as a 2-byte FW version. So relatively counting from header. I am not sure how and from where to count the pointer thingie;(

So firmware_bak.bin FW version is [07 DE] and UPDATE.mem is [00 69].

But the documentation is pretty good tho. I think a bit more deep in dive and one would be possible to make some PR for that tool with firmware configuration editing. Very interesting but I am not that much into hex.

[qmfrederik]

Well, here's what the start of my firmware looks like:

0000000 55aa 3fc7 0014 00f6 010c 0054 0164 2c94
0000010 2dfc 0008 2013 1a5c ff63 0001 ff80 001e

So you have the 0x55aa magic value, and then 0x0014 as the offset for the version number. This means you'll need to jump to address 0x0014 to get the version number. The value at 0x0014 is 0x2013, which maps to version 2.0.1.3.

That said, there's a Linux kernel patch which provides support for flashing the firmware: https://lwn.net/Articles/809326/ .

[AreYouLoco]

Ok thanks for the input. Thats interesting cuz both of my firware files have only one 0x55AA header but its not at the begining of the file. I will double check but I am sure it was somewhere in the middle. Maybe try that patch but not feeling like recompiling kernel today.

What hex editor are you using if I may ask?

[qmfrederik]

If the 0x55AA header is not at the start of the ROM, then you most likely have a Vendor Specific Configuration Data (VSCD) section in your ROM. I don't think this utility handles VSCD very well; so I'd be careful in that case.

The hex output above came from hexdump. Visual Studio Code also has a couple of plug ins which have hex editors.

Which card do you have, and which problem are you trying to solve?

[markusj]

* It is possible that the firmware is prefixed with Vendor Specific Configuration Data. I don't think you'll see the Vendor Specific Configuration Data in the firmware that ships with the driver. Plus, I think this utility doesn't handle the Vendor Specific Configuration Data at all (i.e. if you flash a card with this utility, I think the Vendor Specific Configuration Data will be lost)

Indeed. Side note: I can not totally preclude that I did this to my card ... however, since the issues already where there before I started to experiment with this tool, I presume its just cheap hardware design.

The upload option (-u) should be safe, since it does not alter the ROM but only upload the firmware into the internal RAM of the chipset. Thus, the firmware is gone if you cut the power supply.

[j1warren]

In case somebody would need it.

0a:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03)

Changed that line

//unsigned char pcidevid[] = { 0x12, 0x19, 0x15, 0x00 }; //vendor id = 1912 devid = 0015
unsigned char pcidevid[] = { 0x12, 0x19, 0x14, 0x00 }; //vendor id = 1912 devid = 0014

ROM dumped with this tool (size is 0x10000)
0000 [0x28+0x4 bytes of VSCD] [0x3170 bytes of 2024 fw] ['0xff' till the end]

ROM after flashing it to v2026 from Windows via nec_k2026fwup1.exe

0000 [0x28+0x4 bytes of VSCD] [0x3170 bytes of 2024 fw] ['0xff's]
4000 [0x28+0x4 bytes of VSCD] [0x32D4 (**13012**) bytes of 2026 fw] ['0xff's]

VSCD sections are the same and the 0x32D4 (13012) bytes of 2026 fw section is the same as
13012 UPDATE2026.mem

So basically, it just made another copy in eeprom of the same VSCD section and then just plain UPDATE2026.mem

If you don't want to use Windows and your ROM has VSCD you can create the new FW by hand and flash it using this tool.

[markusj]

@j1warren thanks for your research

Based on the device IDs you provided, I added support for uPD720201.

I will close this issue for now since I think all relevant information has been gathered and there is nothing more to do (except maybe adding VSCD support, but I have no intentions to do that on my own).