We are designing our carrier board to support both the AGX Xavier and AGX Orin. Can the same Cypress USB firmware below support both platforms at the same time?
Thank you.
I can’t answer, but I suspect that if the firmware loads into the Cypress device, then this would be independent of any operating system. The one place it might matter is if device tree is somehow required to tell the firmware where to load (the physical address and any options). Maybe someone else has experience with third party firmware who can give you a better answer.
Note that devices which are “plug-n-play” probably won’t need any device tree to find them, but the Cypress USB root HUB itself might need a device tree. On the other hand, if it is PCI, then the firmware should “just work”.
Thanks for your advice. Let me elaborate more on our use case to understand the problem. Based on the reference design of AGX Xavier and AGX Orin, we are designing a carrier board to support both modules using JetPack 5.2.1.
Most of the hardware design is similar to the two reference boards except the USB parts. The USB of our board references the design by AGX Orin. For that, the Cypress USB CYPD4226 uses GPIO to control a USB channel switch (PI3DBS12212A) whilst the same Cypress chip on AGX Xavier uses I2C instead to control another switch (TUSB1046-DCI).
What we are not sure is the case where AGX Xavier module is used on our board. For that, we want to know whether it is possible to use the CYPD4226 firmware for AGX Orin and its USB can still work (possibly require little change of Kernel DTS).
As the CYPD4226 firmware is only provided as a binary without source code, we cannot modify its firmware.
This is far from what you are asking, and someone else will have to give a complete answer. However, I think you’ll find this background useful.
The GPIO uses the device tree to determine function. Typically one sets that with the PINMUX spreadsheet, although you could directly edit the device tree. I can’t give you a complete answer, but to speed things up, I’ll point out some related information. There are other devices which are set up similarly with the device tree, but the PINMUX spreadsheet includes the things which are part of the SoC and reference carrier board. When you add a plug-n-play device you don’t need to worry about the device tree, but if you add a non-plug-n-play device on a carrier board at a particular physical address, then you would probably add a custom node to the spreadsheet for your device. To load firmware the kernel has to find the device (either via device tree or via plug-n-play software).
Being that the device is a USB HUB or controller, and not an endpoint device, I do not know if it is plug-n-play or not. If this chip is wired to PCI, then probably it is plug-n-play and you don’t need a device tree edit. If this device is wired to the memory controller, then you will need a device tree node for software to find this device (which is in part the driver finding it and the firmware load; firmware load has to take place prior to the driver taking ownership of the device, otherwise you could get a crash which brings the system down).
i2c and GPIO are usually set up via device tree, so even if the chip itself is plug-n-play, you might need to work on the device tree for the particular I/O which talks to the chip. This includes making sure power rails for the i2c or other communications is active (it is possible to enable i2c but have it fail because the power rail for the i2c is not active).
If you “cd /proc/device-tree”, then you’ll see pseudo files which reflect the current device tree. Unless boot stages have edited the device tree, these will be an exact match to the device tree file. Notice that many of those files or directories include a hexadecimal base address, which is where the hardware exists at. One arbitrary example: “pcie@140a0000”. Within that (and within any node naming a device at a physical address) there is a node “compatible”. This is what assigns a driver to a physical address device. The devices PCIe talks to are plug-n-play, but the PCIe HUB itself is not plug-n-play.
You can in fact extract a device tree (file) to look at based on the existing “/proc/device-tree” (you might need to “sudo apt-get install device-tree-compiler”) instead of looking at the running Jetson:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
(useful to have as a reference in case you start editing)
Notice that the “compatible” is related to the kernel driver. If and only if this is a module format driver, there are also optional load instructions in “/etc/modules-load.d/” and “/etc/modprobe.d/”. An example is that of passing an argument upon load, e.g., something you would see on kernel command line if this were added directly to boot. You can think of dynamic module loading as being able to take arguments, and unlike the integrated kernel components which require arguments at the time the kernel loads or via “/etc/sysctl.conf”, modules can have arguments also set during modprobe; those arguments are in one of the above module directories. Each module or driver has a name, and the name is something you add to the “compatible” entry.
The shorter answer is that if the device tree names the device, or if the device is plug-n-play, then the device can be found. It might be that the driver load can contain some firmware upload to the device, or it might be something else performing the upload. I don’t know. But if the device cannot be found, and if the driver is not associated with the device, then it won’t matter if the firmware is loaded or not, it would always fail. I can’t tell you any specifics for actual firmware upload, I can only tell you what those prerequisites are.
The cypress fw on website only supports Xavier but not Orin.
But I see this description in the Additional Files part on JetPack 35.2.1 webpage:
These FW files add support for Cypress on Jetson AGX Orin.
So, it looks like the firmware can support AGX Orin? The JetPack 35.2.1 webpage:
Oh sorry. I misunderstood your website with the one on download center.
This firmware should work with Orin.
So, is it possible for my previous question below? Could you advise?
Thanks for your info. I should be able to understand this consideration for the possible issues and changes.
Hi,
I just double confirmed with our team that this firmware only supports Orin but no Xavier.
Thanks for this info. So, that means it is not possible for our use case with this Orin firmware for AGX module even though USB parts on our carrier board are mostly the same as the Orin reference hardware, right?
Hi,
If you are using Cypress PD, then you have to use this firmware with Orin.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.