On 21.06.2023 22:20, Christian Lamparter wrote:
On 6/19/23 12:12, Anne Macedo wrote:
On 19.06.2023 10:19, Christian Lamparter wrote:
On 6/19/23 00:46, Anne Macedo wrote:
Cards based on Renesas uPD720202 have their firmware downloaded
during
boot by xhci-pci. At this step, the status of the firmware is read
and
it takes a while for this read to happen (up to a few seconds). The
macros RENESAS_RETRY and RENESAS_DELAY are used to retry reading
this
status byte from PCI a few times. If it can't read the status byte
in
RENESAS_RETRY tries, it times out.
However, since this may vary from card to card, these retry and
delay
values need to be tweaked. In order to avoid having to patch the
code to
change these values, CONFIG_USB_XHCI_PCI_RENESAS_RETRY and
CONFIG_USB_XHCI_PCI_RENESAS_DELAY are introduced.
If applied, this patch helps to fix errors such as:
ROM Download Step 34 failed at position 136 bytes
Firmware Download Step 2 failed at position 8 bytes with (-110)
while loading xhci-pci when using these cards.
This error in particular has been noticed by this e-mail [1].
[1] https://lore.kernel.org/lkml/20190626070658.GP2962@vkoul-mobl/
Can you tell me on what hardware (is it something older, with maybe
a Synopsys/Designware PCIe host controller?) do you experience these
errors and what delay+retry values are you configuring in order to
get your DUT up an running?
It's a PH61 Rev 1.2 board with the Renesas uPD720201 host controller.
I'm using 10 as the delay and 6000 as the retry.
Oh? Is this an old MSI PH61 mainboard or is this an add-in pcie card
(found something on amazon with that name and rev too)?
It's the add-in pcie card, exactly the one that's available on Amazon.
If it's an add-in pcie card, could it be that the EEPROM chip on it
is (getting) a bit wonky? Or do you have a really fast machine?
(Latest crop of i7/i9 Alder/Raptor Lake or Ryzen 5000/7000 Series)
I do have a fast machine, but I believe the EEPROM chip might have gone
wonky
for sure. It was the first card I found on my local retailer for adding
USB-C
headers to my setup.
From what I can tell, the quoted [1] link to Vinod's mail was just
an update during development. This was v3 of the patch series back
then (and it went on to v10 I think, so this wasn't an issue with
what's in the kernel right now).
I see. That was the only reference I found to the timeout error I was
seeing, so that's why I decided to tweak these retry+delay values.
Note: If you are interested I still got the "uPD720201/uPD720202
User's
Manual" back then from Renesas site. (Nowadays they want you to
register or something.). This document was the base for the code and
maybe there's something in there you can quote to extend the
retries/delays.
Definitely interested! I did find a .pdf on Google though, I can check
it.
There's also Renesas loader code floating around on github.
ACK - I believe I saw this one as well.
(From what I vaguely remember. Most of the transfer was fast and
no retries where necessary, but some register write took so long.
Vinod also posted hints about a newer firmware for the
uPD720201/uPD720202. Have you tried that as well?)
I was using the upd72020x-fw AUR package on my Arch Linux build,
if that's any relevant. However, it's quite old and I don't really
know
how it works. I missed these hints, sorry, could you point me to
them?
Yes, I was talking about "K2026090.mem". I didn't know this version
existed,
but Vinod knew about it:
https://patches.linaro.org/project/linux-arm-msm/patch/20200113084005.849071-5-vkoul@xxxxxxxxxx/
Looking on google leads to startech.com and they have/had this as a
product:
https://www.startech.com/en-de/cards-adapters/pciusb3s22
The K2026090.mem Firmware file is in the "[renesas upd72020x] firmware
update.zip"
(see in the "RE202.A10" folder).
Will try that!
I don't know how it works with pcie cards that are supposed to have the
firmware
stored on the EEPROM chip. In my case of the WNDR4700 - there is no
extra chip and
the driver has to upload the firmware - I just have to put the file
renamed as
renesas_usb_fw.mem into /lib/firmware/ and it works.
I wrote a bpf program to trace the PCI read/write calls from this
specific Renesas
device [1]. On the manual you mentioned, there's a step on the firmware
download
where a register is changed when the firmware download finishes. On my
bpftrace,
I see that it takes a long while for it to actually change, so I'm not
sure what could be
the problem.
I also wrote a patch for my dev environment to allow me to erase the ROM
as needed [2], but
it hangs for a long time as well until the timeout is reached.
I *think* that the kernel module erases the ROM at some point when
starting up and then polls
if the ROM has been reset.
I've been thinking about Greg's suggestion of setting this timeout
dynamically, and I was taking
a look at different ways to deal with waiting and timeouts on kernel
modules. Do you think it's
worth it to implement something like a better waiting logic for this
module?
I didn't find anything on the card and in the manual that could point me
to a way of discovering
how long to set the timeout on it.
[1]
https://github.com/retpolanne/kernel-workspace/blob/main/bpf/renesas-pci-trace.bt
[2]
https://github.com/retpolanne/kernel-workspace/blob/main/patches/erase-rom.patch
Regards,
Christian
