[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <89224e37-f97d-4f50-bc4a-95da28407328@smile.fr>
Date: Tue, 29 Oct 2024 17:15:32 +0100
From: Romain Naour <romain.naour@...le.fr>
To: Richard Weinberger <richard@...ma-star.at>,
Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: Richard Weinberger <richard@....at>, upstream@...ma-star.at,
linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
andersson@...nel.org, upstream+rproc@...ma-star.at, ohad@...ery.com,
s-anna@...com, t-kristo@...com
Subject: Re: [PATCH] rpmsg_ns: Work around TI non-standard message
Hello Richard, All,
Le 15/10/2024 à 20:00, Richard Weinberger a écrit :
> Am Dienstag, 15. Oktober 2024, 19:56:08 CEST schrieb Mathieu Poirier:
>>>> In my opinion the real fix here is to get TI to use the standard message
>>>> announcement structure. The ->desc field doesn't seem to be that useful since
>>>> it gets discarted.
>>>
>>> This is for the future, the goal of my patch is helping people to
>>> get existing DSP programs work with mainline.
>>> Not everyone can or want to rebuild theirs DSP programs when moving to a mainline
>>> kernel.
>>
>> That's an even better argument to adopt the standard structure as soon as
>> possible. Modifying the mainline kernel to adapt to vendors' quirks doesn't
>> scale.
>
> Well, I can't speak for TI.
> But I have little hope.
I'm also using an AM57xx SoC with DSP firmware and I had the same issue while
updating the kernel from 5.10 to a newer version.
remoteproc rpmsg description field changes [1] is required by the DSP firmware
based on TI-RTOS that is loaded by remoteproc using the new (as of 2013) but
still experimental RPMSG_NS_2_0 [2].
RPMSG_NS_2_0 broke compatibility with existing rpmsg structs [3] (defined in
upstream kernel) for all devices except OMAP5 and newer SoC (Newer 64bits SoC
DRA8 and Jacinto doesn’t need this change thanks to the new IPC-lld implementation).
This rpmsg description field has been added to ipcdev long time ago (14/03/2013)
and requires this kernel vendor change since then (all DSP firmware generated by
AM57xx TI SDK need it).
Note:
RPMSG_NS_2_0 is not the only vendor changes you need to rebase on newer kernels...
DSP firmware generated by TI SDK are using the vendor MessageQ API [4] that
requires AF_RPMSG socket support [5] in the kernel.
This driver was never upstreamed since the IPC 3.x is deprecated nowadays and
replaced by the IPC-lld on newer SoC (IPC-lld uses the upstream generic
rpmg-char driver).
All theses patches were moved out of ti-linux-kernel (6.1 since) to a meta-tisdk
yocto layer that is used only for am57xx vendor kernel. See the latest SDK
release for AM57xx [7].
So, DSP firmwares on AM57xx will requires theses two vendor patches since it's
how the TI IPC stack was designed more than 10 years ago.
It's nice to see newer TI SoC able to use upstream kernel using the standard
structure.
[1]
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-rt-linux-5.10.y&id=7e3ea0d62a4bf0ca04be9bc320d13f564aab0a92
[2]
https://git.ti.com/cgit/ipc/ipcdev/commit/?id=e8a33844cd2faa404e457d13f9d54478ec8129e7
[3]
https://git.ti.com/cgit/ipc/ipcdev/commit/?id=1264ed112ef8c0eed6ff30503b14f81b8ff11dd7
[4]
http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_message_q_8h.html
[5]
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-rt-linux-5.10.y&id=f4b978a978c38149f712ddd137f12ed5fb914161
[6]
https://git.ti.com/cgit/ti-sdk-linux/meta-tisdk/commit/?h=am57x-9.x&id=25e56a0615fb8e973e516b5a225ee81f655f98db
[7] https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-AM57X/09.02.00.133
Best regards,
Romain
>
> Thanks,
> //richard
>
Powered by blists - more mailing lists