qcs6490-rb3gen2: add usb_fw partition

[vivpuar]

add usb_fw partition to partition.conf for qcs6490-rb3gen2, required for USB type A port to work. usb_fw partition is part of QLI 1.6 release, adding it on qcom-ptool to align with QLI 1.0

How it is used on QLI 1.0:

• The firmware is flashed on the partition during factory testing
• Post that, user space will mount the partition and copy the file to /lib/firmware (Reference)
• When usb driver comes, it will load it over pcie

[sbanerjee-quic]

Why this firmware cannot be up streamed to linux-firmware project?
Are there any other github repo from where this firmware can be fetched from if not linux-firmware?

[ndechesne]

The USB mount script are really bad and not appropriate for QLI mainline, I would not want us to merge that.

Since we redistribute the firmware, we should have a recipe that install the firmware in lib/firmware instead of doing this custom partition and mount dance.

[ricardosalveti]

NAK, this is not standard and not generic enough, which will create a custom distro specific workaround for something that should be distributed as part of the OS.

[vkraleti]

@ndechesne @ricardosalveti Just to provide a bit of background, RB3Gen2 board uses a Renesas USB controller connected over PCIe, and its firmware must be loaded for USB Type A to function. Renesas does not plan to upstream this firmware, and Qualcomm does not have the necessary approvals to redistribute it.

Given these constraints, the proposed solution is to store and load the firmware from a dedicated partition that will never be erased. ODMs with redistribution rights can provision this partition during factory setup.

[ndechesne]

I am well aware of this firmware, but if you look at the recipe, the firmware is already redistributed.

[ricardosalveti]

@ndechesne @ricardosalveti Just to provide a bit of background, RB3Gen2 board uses a Renesas USB controller connected over PCIe, and its firmware must be loaded for USB Type A to function. Renesas does not plan to upstream this firmware, and Qualcomm does not have the necessary approvals to redistribute it.

Given these constraints, the proposed solution is to store and load the firmware from a dedicated partition that will never be erased. ODMs with redistribution rights can provision this partition during factory setup.

My main issue is that there is nothing really standard with this solution, and not every user will require this to be in place. Also, there is no guarantee that the partition will contain a valid firmware (as it will demand an extra flashing step after the user downloads the firmware blob from the vendor website).

Another pain point is that this firmware should really be managed by the OS, and any mount point logic we create will be custom and won't be applied to any generic distros (won't be used for systemready validation or generic linux distributions). Also, how would we expect this firmware to be updated, via capsule? And the distribution issue with the capsule will be the same, so won't really work.

This is a hardware issue and AFAIK there was a newer rev of the hardware that had a fixed eeprom, but something we still need to confirm.

[lumag]

@ndechesne @ricardosalveti Just to provide a bit of background, RB3Gen2 board uses a Renesas USB controller connected over PCIe, and its firmware must be loaded for USB Type A to function. Renesas does not plan to upstream this firmware, and Qualcomm does not have the necessary approvals to redistribute it.
Given these constraints, the proposed solution is to store and load the firmware from a dedicated partition that will never be erased. ODMs with redistribution rights can provision this partition during factory setup.

My main issue is that there is nothing really standard with this solution, and not every user will require this to be in place. Also, there is no guarantee that the partition will contain a valid firmware (as it will demand an extra flashing step after the user downloads the firmware blob from the vendor website).

Another pain point is that this firmware should really be managed by the OS, and any mount point logic we create will be custom and won't be applied to any generic distros (won't be used for systemready validation or generic linux distributions). Also, how would we expect this firmware to be updated, via capsule? And the distribution issue with the capsule will be the same, so won't really work.

This is a hardware issue and AFAIK there was a newer rev of the hardware that had a fixed eeprom, but something we still need to confirm.

Well. It should have been fixed at the EVK stage. I think it's too late to fix it with another respin.

However, Qualcomm should have enough marker and persuasion force to try hard to make Renesas release the firmware under a sensible licence. I think this should be solved by our business, sales and cc teams rather than by this engineering hacks. The file is already public, distributed from Renesas website, etc. We should be asking Renesas to adjust the licence, allowing it to be included into linux-firmware and/or redistributed.