On Wed, Aug 23, 2023 at 10:51:33AM -0500, Nishanth Menon wrote: > On 09:23-20230823, Mathieu Poirier wrote: > > On Tue, Aug 22, 2023 at 03:12:05PM -0500, Nishanth Menon wrote: > > > On 13:25-20230822, Mathieu Poirier wrote: > > > > Hi Nishanth, > > > > > > > > On Mon, Aug 07, 2023 at 09:02:47AM -0500, Nishanth Menon wrote: > > > > > On many platforms, such as Beaglebone-AI64 with many remote > > > > > processors, firmware configurations provided by the distributions can > > > > > vary substantially depending on the distribution build's functionality > > > > > and the specific remote cores enabled in that variant. Ensuring > > > > > consistent udev rules mapping remoteproc nodes to constant remote > > > > > proc device indices across distributions (yocto, ubuntu, debian and > > > > > it's variants, ...) on a board basis can be challenging due to the > > > > > various functions of these distributions. Varied device node paths > > > > > create challenges for applications that operate on remote processors, > > > > > especially in minimal embedded systems(initrd like) that may not > > > > > have udev-like capabilities and rely on a more straightforward bare > > > > > filesystem. This challenge is similar to that faced by I2C, RTC or the > > > > > GPIO subsystems. > > > > > > > > > > > > > I'm puzzled by this patch. I can see how using an alias can help in boards with > > > > various HW configuration. That said, and as written above, FW files for remote > > > > processors can vary based on the build's functionality. As such "remoteproc3" > > > > will reference the same HW device on all distributions but the functionality > > > > enacted by the FW may be different. As such I don't see how an alias can help > > > > here. Can you provide a concrete example that highlights the benefits? > > > > > > Correct - *if* remoteproc3 is the constant node reference. > > > > > > To take a trivial example: We ran into this issue with: > > > https://github.com/kaofishy/bbai64_cortex-r5_example/blob/main/Makefile#L28 > > > > > > remoteproc18 apparently changed numbering in a different build. > > > > > > > We are going around in circles. In the above link using an alias will > > guarantee that "remoteproc18" is available but won't guarantee the > > functionality enacted by the FW loaded in that remote processor, which is distro > > dependent. > > Apologies, but I am trying to comprehend the relationship and probably > am failing to see the linkage. Let me try: > > If I understand you correctly, you are concerned that distros do not > have a mechanism to provide consistent firmware to the correct remote > proc for a specific functionality.. > The point is that aliases will guarantee a naming convention for remote processors but won't guarantee their functionality. Sure, we can add aliases but it won't solve all your problems. > if so, distro loads / provides the requisite firmware. How > the package distribution scheme works to distribute the firmware > and versioning provided varies - One typical pattern has been to use > linux-firmware repo[1] (at least in other domains - say GPU, wlink or > the likes) and provide package distribution. The other pattern could > be build and deploy based on tag (this would be no different from any > other package deployment). > > On the other hand, If we are looking at the fact that there can be > different types of firmware that could be loaded to a remoteproc > providing different functionality - that is correct, and at least in > case of TI processors very valid That is exactly what I am referring to. >- something like openAMP endpoint > solutions probably help? I am not familiar with openAmP endpoints but certainly willing to consider it as an option. > > Let me know if I am off-track here.. > You are on track. > [1] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-ipc?h=ti-linux-firmware > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
