upd72020x-load icon indicating copy to clipboard operation
upd72020x-load copied to clipboard

Skips devices incorrectly under Ubuntu 22.04

Open matthew-turnaroundfactor opened this issue 2 years ago • 2 comments

The check-and-init script is skipping uninitialized devices on Ubuntu 22.04. Bypassesing the "continue" command here makes it work: https://github.com/markusj/upd72020x-load/blob/master/upd72020x-check-and-init#L30

The dmesg output (sudo dmesg | grep "0000:01:00.0") looks like this:

[    0.406998] pci 0000:01:00.0: [1912:0014] type 00 class 0x0c0330
[    0.407068] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00001fff 64bit]
[    0.407355] pci 0000:01:00.0: PME# supported from D0 D3hot
[    0.411415] pci 0000:01:00.0: BAR 0: assigned [mem 0x600000000-0x600001fff 64bit]
[    0.413161] pci 0000:01:00.0: enabling device (0000 -> 0002)
[    5.413222] pci 0000:01:00.0: xHCI HW not ready after 5 sec (HC bug?) status = 0x801
[    5.413261] pci 0000:01:00.0: quirk_usb_early_handoff+0x0/0x20c took 4882924 usecs
[    6.445832] xhci_hcd 0000:01:00.0: failed to load firmware renesas_usb_fw.mem: -2
[    6.462131] xhci_hcd: probe of 0000:01:00.0 failed with error -2

This output came from a system with the renesas chip on device 01:00.0 that did not yet have the loader installed.

I think a --force option like what this fork adopted might be the easiest way to deal with this: https://github.com/Artanejp/upd72020x-load/blob/master/upd72020x-check-and-init#L17

That way we can use force knowing it won't break anything for us and others can try skipping so as not to disrupt working chips. It feels like lspci or lsusb should have the info to tell if the chip is working, but I don't see how to find it. That would be more resilient than looking in dmesg.

I agree. Artanejp has more changes that might be worthy to merge back, I will see when I can take care of this. However, I do not use the card any more, so I can not do any testing.

markusj avatar Jun 26 '23 20:06 markusj

Thanks. Yeah, we use this chip in one of our boards, so it's nice to be able to load the firmware with your systemd service, but it's also not quite the same as what the cards probably do. In the fork I made I just skipped the check completely and try to load every time: https://github.com/turnaroundfactor/upd72020x-load/tree/matthew-turnaroundfactor-always-program

For us that never seems to cause a problem, but we're in a controlled environment (not someone's desktop PC) so I'm not sure if doing it that way will break other peoples' setup.