How to use a USB storage device for zcu104?

[hc161180051]

Hello, I want to use a USB storage device for zcu104 with Linux on bao. I've tried to modify the .dts file and add the device in linux+freertos.c, but it doesn't seem to work. May I ask if you have any advice, and what else should I do?
Thanks!

[hc161180051]

linux+freertos.c

usb dts

error

[josecm]

You are missing the device id that allows Bao to setup an SMMU entry for the USB DMA. The SMMU is likely blocking the USB DMA transactions. Take a look at how the GEM DMA is configured using the .id = 0x877 field. Looking at your device tree fragment, it should be .id = 0x860 (did not confirm this in the ZUS+ documentation).

Let me know if this helps.

[josecm]

Also, you should not be adding the smmu node or the iommu fields to the guest's device tree because the SMMU is reserved for the hypervisor and cannot be used by guests.

[hc161180051]

You are missing the device id that allows Bao to setup an SMMU entry for the USB DMA. The SMMU is likely blocking the USB DMA transactions. Take a look at how the GEM DMA is configured using the .id = 0x877 field. Looking at your device tree fragment, it should be .id = 0x860 (did not confirm this in the ZUS+ documentation).

Let me know if this helps.

Thanks for your advice, it helpes a lot! I will try again later on.

[hc161180051]

You are missing the device id that allows Bao to setup an SMMU entry for the USB DMA. The SMMU is likely blocking the USB DMA transactions. Take a look at how the GEM DMA is configured using the .id = 0x877 field. Looking at your device tree fragment, it should be .id = 0x860 (did not confirm this in the ZUS+ documentation).

Let me know if this helps.

I have added the SMMU id for the USB DMA but it seems doesn't work. Is there anything to pay attention to when setting the interrupt ID? Here are the modified codes.

I would greatly appreciate it if you could provide me with some more suggestions

[josecm]

@hc161180051 Now that I look at your config again, another issue comes to mind. Are you using size 0x100 for USB device? This raises a couple of flags. First, because the minimum mappable region is 1 page (i.e., 4KiB or 0x1000). In this case, Bao will most likely fail to map the device for Linux. This being the case when Linux would try to access you would see an ERROR message from Bao saying the guest was trying to access an invalid address.

Also, if you are changing the bao-demos config files directly, you should manually delete the wrkdir/imgs/zcu104 so that the makefiles fetch the new config and dts.

[josecm]

@hc161180051 I've been looking deeper into this. I've been able to boot Linux with USB passthrough without any errors or that "deferred probing" message, but there is a major caveat: we need to pass through some calls from the Linux guest directly to the firmware so that the driver can control the reset lines. This has the problem that it breaks isolation, as Linux could invoke calls that would mess up with devices assigned to other guests by messing with reset, clock or power controls. The immediate band-aid solution would be to add some firmware API-aware code to Bao that performs checks on the SMC calls of the guest to firmware and allows only those pertaining to its assigned devices. However, I was still not able to attach a device (I'm trying to use a flash drive). I'll keep you posted and soon will share the configuration and patch needed to achieve this.

This is not the first time we have run into this kind of issue. We have been discussing possible solutions to this problem but have still not found something that scales. In the worst case, we will end up adding that firmware call filtering layer to Bao. However, as we will need to do this on a platform-by-platform basis, it will be something that will take time.

[hc161180051]

@hc161180051 I've been looking deeper into this. I've been able to boot Linux with USB passthrough without any errors or that "deferred probing" message, but there is a major caveat: we need to pass through some calls from the Linux guest directly to the firmware so that the driver can control the reset lines. This has the problem that it breaks isolation, as Linux could invoke calls that would mess up with devices assigned to other guests by messing with reset, clock or power controls. The immediate band-aid solution would be to add some firmware API-aware code to Bao that performs checks on the SMC calls of the guest to firmware and allows only those pertaining to its assigned devices. However, I was still not able to attach a device (I'm trying to use a flash drive). I'll keep you posted and soon will share the configuration and patch needed to achieve this.

This is not the first time we have run into this kind of issue. We have been discussing possible solutions to this problem but have still not found something that scales. In the worst case, we will end up adding that firmware call filtering layer to Bao. However, as we will need to do this on a platform-by-platform basis, it will be something that will take time.

Thank you very much for your help ! I also tried to use a flash driver recently but it didn't work. I'll keep trying and wait for your good news ! Thank you again!

[hc161180051]

@josecm Hello，I'm very sorry to brother you. May I ask if there is any progress on the patch mentioned earlier?

[hc161180051]

@josecm I'm very sorry that I bother you again. I've tried many methods but I still couldn't successfully mount a USB or flash device. If you have any progress， could you give me some suggestions？ Furthermore, I have some doubts about why GEM DMA works but USB doesn't. I will be very grateful if you could help me answer.