Switch fastrpc recipe to GitHub version

[quic-ekangupt]

Switched the fastrpc recipe from the CodeLinaro version to the GitHub version. This update includes:

1. Transition to the GitHub version of fastrpc, ensuring compatibility with all features supported by the CodeLinaro version.
2. Exposing header files to be used by developers for easier integration and development.
3. Addition of new features and improvements to enhance stability and performance.

The GitHub version of fastrpc has been tested on multiple platforms, confirming its reliability and robustness.

[github-actions]

Test Results

 3 files  ±0   6 suites  ±0   1m 53s ⏱️ ±0s
23 tests ±0  23 ✅ ±0  0 💤 ±0  0 ❌ ±0 
57 runs  ±0  57 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 9637e0c. ± Comparison against base commit 48f8317.

[github-actions]

Test jobs for commit 9637e0c

• Job 71123 on qrb2210-rb1
• Job 71124 on qcs6490
• Job 71125 on qcs9100

[lumag]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?

[lumag]

Checking two lines? Please use LICENSE.txt as a LIC_FILE here.

[quic-ekangupt]

Ack

[lumag]

This should be done by make install.

[ricardosalveti]

Yeah, can't we instead fix upstream to have all headers installed via make install? We shouldn't be tracking the headers we want via HEADER_FILES, this is something that the individual project should be able to do.

[lumag]

And please, install only the headers that make an actual API for the library.

[quic-ekangupt]

I'll test the change and update this, thanks.

[lumag]

Is this really necessary? If so, why?

[quic-ekangupt]

Moving headers installation to make install. This will be removed in the next patch

[ricardosalveti]

First, do we need this recipe to be tracking an unreleased version? Otherwise I would prefer if we could instead rename the recipe based on a released tag (latest is v0.1.4, so fastrpc_0.1.4.bb). If we need to track a newer revision, can't we work just creating another tag upstream?

[sbanerjee-quic]

+1 regarding the use of version and the recipe file name reflecting the version.
@quic-ekangupt if the intent is to be able to use the tip of fastrpc for purpose of develpment against the tip you can use devupstream.

[ricardosalveti]

Isn't enable the default here?

[quic-ekangupt]

yes, I'll remove this

[quic-ekangupt]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

[lumag]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.

No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

[vkraleti]

Can't these services be part of fastrpc.git itself and a makefile can install these? That way fastrpc project can be easily extended to other distributions as well.

[quic-ekangupt]

I'll try this out. Thanks.

[quic-bkumar]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.

No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

[lumag]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Could you possibly share your CI details? How are you testing the kernel + userspace combos on the targets? Is it only a manual testing? Can we integrate simple FastRPC tests into the meta-qcom CI? Into Linaro's QC LT kernel CI?

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

FastRPC has been a gray zone for multiple reasons. One of them was the lack of activity. Everybody expected that the project is in the 'odd-fixes' state and didn't expect anything. You have opened this can and started contributing to both kernel and userspace parts. So I'd say now we are expected to be a good player.

[quic-bkumar]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon.
We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

Could you possibly share your CI details? How are you testing the kernel + userspace combos on the targets? Is it only a manual testing? Can we integrate simple FastRPC tests into the meta-qcom CI? Into Linaro's QC LT kernel CI?

FastRPC does not have CI within GitHub; instead, it is managed through separate Jenkins automation. A few FastRPC tests can be integrated into meta-qcom to help prevent potential issues.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

FastRPC has been a gray zone for multiple reasons. One of them was the lack of activity. Everybody expected that the project is in the 'odd-fixes' state and didn't expect anything. You have opened this can and started contributing to both kernel and userspace parts. So I'd say now we are expected to be a good player.

FastRPC has been gaining momentum lately, with active contributions to both kernel and user space components. Our goal is to be a dependable presence in this domain. As part of Qualcomm's effort to foster community collaboration, the FastRPC user space library has been open-sourced. Over the past year, we've rolled out numerous features and bug fixes, reaffirming our commitment to long-term support. So, I’d say we’re holding our own quite well!

[lumag]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

Could you possibly share your CI details? How are you testing the kernel + userspace combos on the targets? Is it only a manual testing? Can we integrate simple FastRPC tests into the meta-qcom CI? Into Linaro's QC LT kernel CI?

FastRPC does not have CI within GitHub; instead, it is managed through separate Jenkins automation. A few FastRPC tests can be integrated into meta-qcom to help prevent potential issues.

Yes, please. At the very least it would be nice to have a set of userspace apps that I can run on the target and verify that ADSP, CDSP and SDSP accept workloads.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

FastRPC has been a gray zone for multiple reasons. One of them was the lack of activity. Everybody expected that the project is in the 'odd-fixes' state and didn't expect anything. You have opened this can and started contributing to both kernel and userspace parts. So I'd say now we are expected to be a good player.

FastRPC has been gaining momentum lately, with active contributions to both kernel and user space components. Our goal is to be a dependable presence in this domain. As part of Qualcomm's effort to foster community collaboration, the FastRPC user space library has been open-sourced. Over the past year, we've rolled out numerous features and bug fixes, reaffirming our commitment to long-term support. So, I’d say we’re holding our own quite well!

As I wrote, it was a gray zone. The kernel driver was merged before we established all the rules for DMA-BUF drivers. If it was submitted now, you'd have been asked to provide a completely open-source toolchain & userspace in order for people to understand and test how the driver works. All accelerator drivers provide a reference open toolchain in addition to the fully-optimized closed source one.

Likewise, for the kernel driver there was a discussion which ended with Simona's "Yeah, if fastrpc just keeps growing the story will completely different."

I support the idea of FastRPC driver and userspace components evolving, but if you want to evolve them, you have to follow the rules.

TL;DR. Without a testing suite that one can execute on the target devices I consider merging this to be risky. There were already backwards compatibility issues both on the driver and on the userspace side. We have a known working snapshot, switching to a newer source sounds risky.

[quic-bkumar]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

You can find a README in the test folder that will provide you with the information.

Could you possibly share your CI details? How are you testing the kernel + userspace combos on the targets? Is it only a manual testing? Can we integrate simple FastRPC tests into the meta-qcom CI? Into Linaro's QC LT kernel CI?

FastRPC does not have CI within GitHub; instead, it is managed through separate Jenkins automation. A few FastRPC tests can be integrated into meta-qcom to help prevent potential issues.

Yes, please. At the very least it would be nice to have a set of userspace apps that I can run on the target and verify that ADSP, CDSP and SDSP accept workloads.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

FastRPC has been a gray zone for multiple reasons. One of them was the lack of activity. Everybody expected that the project is in the 'odd-fixes' state and didn't expect anything. You have opened this can and started contributing to both kernel and userspace parts. So I'd say now we are expected to be a good player.

FastRPC has been gaining momentum lately, with active contributions to both kernel and user space components. Our goal is to be a dependable presence in this domain. As part of Qualcomm's effort to foster community collaboration, the FastRPC user space library has been open-sourced. Over the past year, we've rolled out numerous features and bug fixes, reaffirming our commitment to long-term support. So, I’d say we’re holding our own quite well!

As I wrote, it was a gray zone. The kernel driver was merged before we established all the rules for DMA-BUF drivers. If it was submitted now, you'd have been asked to provide a completely open-source toolchain & userspace in order for people to understand and test how the driver works. All accelerator drivers provide a reference open toolchain in addition to the fully-optimized closed source one.

Likewise, for the kernel driver there was a discussion which ended with Simona's "Yeah, if fastrpc just keeps growing the story will completely different."

I support the idea of FastRPC driver and userspace components evolving, but if you want to evolve them, you have to follow the rules.

TL;DR. Without a testing suite that one can execute on the target devices I consider merging this to be risky. There were already backwards compatibility issues both on the driver and on the userspace side. We have a known working snapshot, switching to a newer source sounds risky.

Let's address the driver discussions separately, as the FastRPC user space will remain consistent for users regardless of the driver. We are currently evaluating the accell framework, and during the migration phase, it is crucial to maintain support for fastRPC to ensure uninterrupted development. Have you checked this one? https://github.com/[quic/toolchain_for_hexagon](https://github.com/quic/toolchain_for_hexagon)

[lumag]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

You can find a README in the test folder that will provide you with the information.

I've tried this on my X13s. Running the tests with older implementation fails because it can not find libapps_std_skel.so and libapps_mem_skel.so, bt at least it is able to create used PD. Running the test with your implementation fails:

hap_example function FAILED
Please look at the mini-dm logs or the adb logcat logs for DSP output
Error occurred with selector 7: 104
openat(AT_FDCWD, "/dev/fastrpc-cdsp-secure", O_RDONLY|O_NONBLOCK) = 5
openat(AT_FDCWD, "/usr/lib/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = 6
openat(AT_FDCWD, "/dev/fastrpc-adsp-secure", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
ERROR 0x68: Unable to create FastRPC session on domain 3

Note, I'm running the fastrpc_test with -d 3 -U 1, so the fact that it looks for fastrpc-adsp is really surprising.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

FastRPC has been a gray zone for multiple reasons. One of them was the lack of activity. Everybody expected that the project is in the 'odd-fixes' state and didn't expect anything. You have opened this can and started contributing to both kernel and userspace parts. So I'd say now we are expected to be a good player.

FastRPC has been gaining momentum lately, with active contributions to both kernel and user space components. Our goal is to be a dependable presence in this domain. As part of Qualcomm's effort to foster community collaboration, the FastRPC user space library has been open-sourced. Over the past year, we've rolled out numerous features and bug fixes, reaffirming our commitment to long-term support. So, I’d say we’re holding our own quite well!

As I wrote, it was a gray zone. The kernel driver was merged before we established all the rules for DMA-BUF drivers. If it was submitted now, you'd have been asked to provide a completely open-source toolchain & userspace in order for people to understand and test how the driver works. All accelerator drivers provide a reference open toolchain in addition to the fully-optimized closed source one.
Likewise, for the kernel driver there was a discussion which ended with Simona's "Yeah, if fastrpc just keeps growing the story will completely different."
I support the idea of FastRPC driver and userspace components evolving, but if you want to evolve them, you have to follow the rules.
TL;DR. Without a testing suite that one can execute on the target devices I consider merging this to be risky. There were already backwards compatibility issues both on the driver and on the userspace side. We have a known working snapshot, switching to a newer source sounds risky.

Let's address the driver discussions separately, as the FastRPC user space will remain consistent for users regardless of the driver. We are currently evaluating the accell framework, and during the migration phase, it is crucial to maintain support for fastRPC to ensure uninterrupted development.

I think we are on the same page here. As I wrote, my main concern is to prevent breaking existing devices.

Have you checked this one? [https://github.com/quic/toolchain_for_hexagon](https://github.com/%5Bquic/toolchain_for_hexagon%5D(https://github.com/quic/toolchain_for_hexagon))

Broken link. I will take a look, but this seems to be a Hexagon compiler. Does it comrise the full toolchain? Can I use it with the headers and libs from SDK to build an app?

[quic-bkumar]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

You can find a README in the test folder that will provide you with the information.

I've tried this on my X13s. Running the tests with older implementation fails because it can not find libapps_std_skel.so and libapps_mem_skel.so, bt at least it is able to create used PD. Running the test with your implementation fails:

hap_example function FAILED
Please look at the mini-dm logs or the adb logcat logs for DSP output
Error occurred with selector 7: 104
openat(AT_FDCWD, "/dev/fastrpc-cdsp-secure", O_RDONLY|O_NONBLOCK) = 5
openat(AT_FDCWD, "/usr/lib/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = 6
openat(AT_FDCWD, "/dev/fastrpc-adsp-secure", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
ERROR 0x68: Unable to create FastRPC session on domain 3

Note, I'm running the fastrpc_test with -d 3 -U 1, so the fact that it looks for fastrpc-adsp is really surprising.

Same issue as qualcomm/fastrpc#145, @quic-ekangupt is already looking into this. falling back to adsp is a legacy code, qualcomm/fastrpc#164 for the fix.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

Let's agree to disagree. Should we concentrate on refining the fastRPC library, which already offers a complete solution, or should we implement extensive changes to Hexagon RPC to support all existing applications? I believe the first option is more practical.

FastRPC has been a gray zone for multiple reasons. One of them was the lack of activity. Everybody expected that the project is in the 'odd-fixes' state and didn't expect anything. You have opened this can and started contributing to both kernel and userspace parts. So I'd say now we are expected to be a good player.

FastRPC has been gaining momentum lately, with active contributions to both kernel and user space components. Our goal is to be a dependable presence in this domain. As part of Qualcomm's effort to foster community collaboration, the FastRPC user space library has been open-sourced. Over the past year, we've rolled out numerous features and bug fixes, reaffirming our commitment to long-term support. So, I’d say we’re holding our own quite well!

As I wrote, it was a gray zone. The kernel driver was merged before we established all the rules for DMA-BUF drivers. If it was submitted now, you'd have been asked to provide a completely open-source toolchain & userspace in order for people to understand and test how the driver works. All accelerator drivers provide a reference open toolchain in addition to the fully-optimized closed source one.
Likewise, for the kernel driver there was a discussion which ended with Simona's "Yeah, if fastrpc just keeps growing the story will completely different."
I support the idea of FastRPC driver and userspace components evolving, but if you want to evolve them, you have to follow the rules.
TL;DR. Without a testing suite that one can execute on the target devices I consider merging this to be risky. There were already backwards compatibility issues both on the driver and on the userspace side. We have a known working snapshot, switching to a newer source sounds risky.

Let's address the driver discussions separately, as the FastRPC user space will remain consistent for users regardless of the driver. We are currently evaluating the accell framework, and during the migration phase, it is crucial to maintain support for fastRPC to ensure uninterrupted development.

I think we are on the same page here. As I wrote, my main concern is to prevent breaking existing devices.

Have you checked this one? [https://github.com/quic/toolchain_for_hexagon](https://github.com/%5Bquic/toolchain_for_hexagon%5D(https://github.com/quic/toolchain_for_hexagon))

Broken link. I will take a look, but this seems to be a Hexagon compiler. Does it comrise the full toolchain? Can I use it with the headers and libs from SDK to build an app?

My bad, try this. quic/toolchain_for_hexagon. This package includes the LLVM toolchain required for Hexagon, with limited featues. Yes, this toolchain can be utilized to compile the sources for DSP.

[lumag]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

You can find a README in the test folder that will provide you with the information.

I've tried this on my X13s. Running the tests with older implementation fails because it can not find libapps_std_skel.so and libapps_mem_skel.so, bt at least it is able to create used PD. Running the test with your implementation fails:

hap_example function FAILED
Please look at the mini-dm logs or the adb logcat logs for DSP output
Error occurred with selector 7: 104
openat(AT_FDCWD, "/dev/fastrpc-cdsp-secure", O_RDONLY|O_NONBLOCK) = 5
openat(AT_FDCWD, "/usr/lib/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = 6
openat(AT_FDCWD, "/dev/fastrpc-adsp-secure", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
ERROR 0x68: Unable to create FastRPC session on domain 3

Note, I'm running the fastrpc_test with -d 3 -U 1, so the fact that it looks for fastrpc-adsp is really surprising.

Same issue as quic/fastrpc#145, @quic-ekangupt is already looking into this. falling back to adsp is a legacy code, quic/fastrpc#164 for the fix.

So.... the test doesn't work :-(

Also, the tests depend on the particular version of the fastrpc, so I can not run them to compare legacy fastrpc vs new fastrpc behaviour.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

Let's agree to disagree. Should we concentrate on refining the fastRPC library, which already offers a complete solution, or should we implement extensive changes to Hexagon RPC to support all existing applications? I believe the first option is more practical.

I see two distinct issues: the libadsprpcd library and the daemons. I think the daemons should be able to be used interchangeably. Currently FastRPC ecosystem doesn't provide open-source support for onboard sensors, while HexagonRPC clearly does it.
So, we need to converge with that project in order to be able to provide support for both usecases.

[lumag]

Also, for the sake of mentioning it here. @laklimov reported an issue on SM8250: qualcomm/fastrpc#146. Current FastRPC recipe has been tested on SM2850, so it is a regression.

[quic-bkumar]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

You can find a README in the test folder that will provide you with the information.

I've tried this on my X13s. Running the tests with older implementation fails because it can not find libapps_std_skel.so and libapps_mem_skel.so, bt at least it is able to create used PD. Running the test with your implementation fails:

hap_example function FAILED
Please look at the mini-dm logs or the adb logcat logs for DSP output
Error occurred with selector 7: 104
openat(AT_FDCWD, "/dev/fastrpc-cdsp-secure", O_RDONLY|O_NONBLOCK) = 5
openat(AT_FDCWD, "/usr/lib/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = 6
openat(AT_FDCWD, "/dev/fastrpc-adsp-secure", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
ERROR 0x68: Unable to create FastRPC session on domain 3

Note, I'm running the fastrpc_test with -d 3 -U 1, so the fact that it looks for fastrpc-adsp is really surprising.

Same issue as quic/fastrpc#145, @quic-ekangupt is already looking into this. falling back to adsp is a legacy code, quic/fastrpc#164 for the fix.

So.... the test doesn't work :-(

Also, the tests depend on the particular version of the fastrpc, so I can not run them to compare legacy fastrpc vs new fastrpc behaviour.

The tests were validated on the targets supported by meta-qcom. We will certainly enable them for other targets as well.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

Let's agree to disagree. Should we concentrate on refining the fastRPC library, which already offers a complete solution, or should we implement extensive changes to Hexagon RPC to support all existing applications? I believe the first option is more practical.

I see two distinct issues: the libadsprpcd library and the daemons. I think the daemons should be able to be used interchangeably. Currently FastRPC ecosystem doesn't provide open-source support for onboard sensors, while HexagonRPC clearly does it. So, we need to converge with that project in order to be able to provide support for both usecases.

Hexagon RPC clearly lacks many features that FastRPC supports, so is it sufficient to converge to FastRPC? What if onboard sensors support is added to fastRPC? I think there is no need to replicate efforts in this manner.
As mentioned earlier, Hexagon RPC is specifically designed to support onboard sensors and should continue to be used for that purpose. FastRPC, on the other hand, is intended for offloading tasks to DSP. Each project has its own distinct purpose, and we should respect and maintain that.

[quic-bkumar]

Also, for the sake of mentioning it here. @laklimov reported an issue on SM8250: quic/fastrpc#146. Current FastRPC recipe has been tested on SM2850, so it is a regression.

This issue will be resolved in the upcoming release. Additionally, we will implement CI to prevent any regressions/failures.

[lumag]

I run a test on the RB3 (not Gen2) board, qualcomm/fastrpc#167 . So... No, it is not ready for the switch. I am converting this to a draft until RB3 / RB5 boards work without any significant issues.

[lumag]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

You can find a README in the test folder that will provide you with the information.

I've tried this on my X13s. Running the tests with older implementation fails because it can not find libapps_std_skel.so and libapps_mem_skel.so, bt at least it is able to create used PD. Running the test with your implementation fails:

hap_example function FAILED
Please look at the mini-dm logs or the adb logcat logs for DSP output
Error occurred with selector 7: 104
openat(AT_FDCWD, "/dev/fastrpc-cdsp-secure", O_RDONLY|O_NONBLOCK) = 5
openat(AT_FDCWD, "/usr/lib/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = 6
openat(AT_FDCWD, "/dev/fastrpc-adsp-secure", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
ERROR 0x68: Unable to create FastRPC session on domain 3

Note, I'm running the fastrpc_test with -d 3 -U 1, so the fact that it looks for fastrpc-adsp is really surprising.

Same issue as quic/fastrpc#145, @quic-ekangupt is already looking into this. falling back to adsp is a legacy code, quic/fastrpc#164 for the fix.

So.... the test doesn't work :-(
Also, the tests depend on the particular version of the fastrpc, so I can not run them to compare legacy fastrpc vs new fastrpc behaviour.

The tests were validated on the targets supported by meta-qcom. We will certainly enable them for other targets as well.

Could you please post somewhere a list of machines, kernel versions (from linus or linus-next), FastRPC commit ids and test results? The meta-qcom layer supports a lot of machines going back to APQ8064 generation, I doubt that you've validated all of them (e.g. because not all of them actually support FastRPC).

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

Let's agree to disagree. Should we concentrate on refining the fastRPC library, which already offers a complete solution, or should we implement extensive changes to Hexagon RPC to support all existing applications? I believe the first option is more practical.

I see two distinct issues: the libadsprpcd library and the daemons. I think the daemons should be able to be used interchangeably. Currently FastRPC ecosystem doesn't provide open-source support for onboard sensors, while HexagonRPC clearly does it. So, we need to converge with that project in order to be able to provide support for both usecases.

Hexagon RPC clearly lacks many features that FastRPC supports, so is it sufficient to converge to FastRPC? What if onboard sensors support is added to fastRPC? I think there is no need to replicate efforts in this manner. As mentioned earlier, Hexagon RPC is specifically designed to support onboard sensors and should continue to be used for that purpose. FastRPC, on the other hand, is intended for offloading tasks to DSP. Each project has its own distinct purpose, and we should respect and maintain that.

What should be our proposal if the users want to have both sensors and DSP offloading?

[quic-bkumar]

• Please follow the standard format for commit messages. None of the commits uses recipes-foo in the commit subject.
  Ack.
• This version of FastRPC has had issues with the older platforms. Has it been tested on db410c? db820c?
  We have conducted testing on all the latest platforms available, including QLI and recent mobile platforms. For older platforms, please create issues in the FastRPC project with detailed failure information. We will ensure support for any failures encountered on these older platforms. Additionally, we are collaborating with Linaro to test older platforms with the expected use cases.

Please fix your quotations, it's impossible to understand, where is the quoted text and where is your answer.
No, 'please open issues' is not a way to go. Please verify that it actually works, before submitting it. Those devices must be a part of your test / CI setup.

The FastRPC library is an open-source project, which means there are numerous potential use cases that we may not be able to test or verify on all targets. This is precisely why we rely on our users to test the library in their specific use cases/scenarios and report any issues they encounter. While we have thoroughly tested all targets and use cases that we support (will be documented as part of Release notes), we welcome and encourage the community to identify and report any issues they find. Moreover, we are happy to accept and integrate any fixes provided by the users. Therefore, there is no need for our team to test every possible target or use case available in public.

Then could you please provide a reasonable way for e.g. me to test FastRPC on those targets. In other words, a way to build the sample app to be executed on the target without going through the trobles of QPM, SDK, etc. I am using Linux+arm64 laptop and I'm not sure how well this configuration is supported. Please provide a comprehensive testsuite that can be used to test kernel uAPI (in the manner of IGT). There is none available, as far as I remember. We have discussed all of this previously, it has been pointed out that this kind of things is usually a requirement for DMA-BUF drivers.

Hexagon SDK is a mandatory tool for Hexagon development and is publicly available for Windows and Linux. Support for ARM64 is planned and will be available soon. We have added a few test cases to validate both the kernel and user space. These tests can be included in automation to streamline the process.

So... How can I run the tests? I defeinitely do not want to have an SDK on the build server. Nor can I run QPM on our CI runners. See below for the additional details.

You can find a README in the test folder that will provide you with the information.

I've tried this on my X13s. Running the tests with older implementation fails because it can not find libapps_std_skel.so and libapps_mem_skel.so, bt at least it is able to create used PD. Running the test with your implementation fails:

hap_example function FAILED
Please look at the mini-dm logs or the adb logcat logs for DSP output
Error occurred with selector 7: 104
openat(AT_FDCWD, "/dev/fastrpc-cdsp-secure", O_RDONLY|O_NONBLOCK) = 5
openat(AT_FDCWD, "/usr/lib/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/fastrpc_shell_unsigned_3", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/vendor/dsp/cdsp/fastrpc_shell_unsigned_3", O_RDONLY) = 6
openat(AT_FDCWD, "/dev/fastrpc-adsp-secure", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/fastrpc-adsp", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
ERROR 0x68: Unable to create FastRPC session on domain 3

Note, I'm running the fastrpc_test with -d 3 -U 1, so the fact that it looks for fastrpc-adsp is really surprising.

Same issue as quic/fastrpc#145, @quic-ekangupt is already looking into this. falling back to adsp is a legacy code, quic/fastrpc#164 for the fix.

So.... the test doesn't work :-(
Also, the tests depend on the particular version of the fastrpc, so I can not run them to compare legacy fastrpc vs new fastrpc behaviour.

The tests were validated on the targets supported by meta-qcom. We will certainly enable them for other targets as well.

Could you please post somewhere a list of machines, kernel versions (from linus or linus-next), FastRPC commit ids and test results? The meta-qcom layer supports a lot of machines going back to APQ8064 generation, I doubt that you've validated all of them (e.g. because not all of them actually support FastRPC).

@quic-ekangupt , pls help out here.

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

Let's agree to disagree. Should we concentrate on refining the fastRPC library, which already offers a complete solution, or should we implement extensive changes to Hexagon RPC to support all existing applications? I believe the first option is more practical.

I see two distinct issues: the libadsprpcd library and the daemons. I think the daemons should be able to be used interchangeably. Currently FastRPC ecosystem doesn't provide open-source support for onboard sensors, while HexagonRPC clearly does it. So, we need to converge with that project in order to be able to provide support for both usecases.

Hexagon RPC clearly lacks many features that FastRPC supports, so is it sufficient to converge to FastRPC? What if onboard sensors support is added to fastRPC? I think there is no need to replicate efforts in this manner. As mentioned earlier, Hexagon RPC is specifically designed to support onboard sensors and should continue to be used for that purpose. FastRPC, on the other hand, is intended for offloading tasks to DSP. Each project has its own distinct purpose, and we should respect and maintain that.

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

[lumag]

[I'm sorry, I edited your comment by mistake, it should be now reverted back to the state it was]

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

Let's agree to disagree. Should we concentrate on refining the fastRPC library, which already offers a complete solution, or should we implement extensive changes to Hexagon RPC to support all existing applications? I believe the first option is more practical.

I see two distinct issues: the libadsprpcd library and the daemons. I think the daemons should be able to be used interchangeably. Currently FastRPC ecosystem doesn't provide open-source support for onboard sensors, while HexagonRPC clearly does it. So, we need to converge with that project in order to be able to provide support for both usecases.

Hexagon RPC clearly lacks many features that FastRPC supports, so is it sufficient to converge to FastRPC? What if onboard sensors support is added to fastRPC? I think there is no need to replicate efforts in this manner. As mentioned earlier, Hexagon RPC is specifically designed to support onboard sensors and should continue to be used for that purpose. FastRPC, on the other hand, is intended for offloading tasks to DSP. Each project has its own distinct purpose, and we should respect and maintain that.

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

I'm thinking from the distro point of view. Can both daemons be used at the same time?

[quic-bkumar]

[I'm sorry, I edited your comment by mistake, it should be now reverted back to the state it was]

I have asked to stop playing NIH and to consider working with hexagonrpc / libssc as a clean implementation where it is easy to implement features, it is easy to implement testsuit, etc. I don't think anything changed

There's no bias here. HexagonRPC delivers a clean implementation, primarily focused for sensor-specific use cases. Given that focus, the test suite implementation likely doesn't require additional tools. However, when adapted for NSP use cases, it will need all the tools required by fastRPC. Both projects serve distinct purposes, so mutual respect should be maintained as they each contribute in their own way.

Is anybody from Qualcomm contributing to that project? What is our alternative for implementing sensors access? Also with linux-msm/hexagonrpc#10 in place, the HexagonRPC will get FastRPC support. It would be nice if somebody from your team reviews that.

The FastRPC library is constructed using a distinct infrastructure provided by the Hexagon SDK, specifically utilizing the stub and skel method. Many market-available applications like AI Hub by Qualcomm are developed based on this infrastructure. Hexagon RPC is designed to eliminate the need for the Hexagon SDK, which raises the point of how to support these existing market-available applications on Hexagon RPC.

I'd say, that utilizing SDK or not is an orthogonal question. We should be able to run apps no matter how they were built.

Let's agree to disagree. Should we concentrate on refining the fastRPC library, which already offers a complete solution, or should we implement extensive changes to Hexagon RPC to support all existing applications? I believe the first option is more practical.

I see two distinct issues: the libadsprpcd library and the daemons. I think the daemons should be able to be used interchangeably. Currently FastRPC ecosystem doesn't provide open-source support for onboard sensors, while HexagonRPC clearly does it. So, we need to converge with that project in order to be able to provide support for both usecases.

Hexagon RPC clearly lacks many features that FastRPC supports, so is it sufficient to converge to FastRPC? What if onboard sensors support is added to fastRPC? I think there is no need to replicate efforts in this manner. As mentioned earlier, Hexagon RPC is specifically designed to support onboard sensors and should continue to be used for that purpose. FastRPC, on the other hand, is intended for offloading tasks to DSP. Each project has its own distinct purpose, and we should respect and maintain that.

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

I'm thinking from the distro point of view. Can both daemons be used at the same time?

The Sensors PD on DSP supports connections from multiple HLOS processes. Although only one default daemon can be active at a time, we can plan to enable this functionality using hexagonRPC. Before proceeding, I suggest renaming the project to sensorsRPC to make it clearer for everyone. what do you think?

[lumag]

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

I'm thinking from the distro point of view. Can both daemons be used at the same time?

The Sensors PD on DSP supports connections from multiple HLOS processes. Although only one default daemon can be active at a time, we can plan to enable this functionality using hexagonRPC. Before proceeding, I suggest renaming the project to sensorsRPC to make it clearer for everyone. what do you think?

No, I think current name is good enough. The daemon is not limited to the Sensors and once linux-msm/hexagonrpc#10 lands, it should be once step closer to be able to provide support for other workloads.

[quic-bkumar]

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

I'm thinking from the distro point of view. Can both daemons be used at the same time?

The Sensors PD on DSP supports connections from multiple HLOS processes. Although only one default daemon can be active at a time, we can plan to enable this functionality using hexagonRPC. Before proceeding, I suggest renaming the project to sensorsRPC to make it clearer for everyone. what do you think?

No, I think current name is good enough. The daemon is not limited to the Sensors and once linux-msm/hexagonrpc#10 lands, it should be once step closer to be able to provide support for other workloads.

To reiterate, I have no objections to using hexagonRPC for sensor use cases, as this was the primary goal of the project, and it should remain focused on sensors. Attempting to duplicate the functionality of an existing open-source software like fastRPC with hexagonRPC would be pointless. If this is not clear, there is no further need for discussion.

[Srinivas-Kandagatla]

@quic-ekangupt @quic-bkumar One of the key thing to migrate from codelinaro to this fastrpc version is by making sure it works on all the upstream platforms that are already tested with codelinaro fastrpc. AFAIU, current state of the library is that it is either not tested on those platforms or it does not work on all of those platforms. Do you have the test coverage results for these platforms, starting from DB410c, DB820c, R1, RB2, RB3, RB5, X13s, QCS405, sm8250, sm8450, sm8550, sm8650, sm8750?

[lumag]

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

I'm thinking from the distro point of view. Can both daemons be used at the same time?

The Sensors PD on DSP supports connections from multiple HLOS processes. Although only one default daemon can be active at a time, we can plan to enable this functionality using hexagonRPC. Before proceeding, I suggest renaming the project to sensorsRPC to make it clearer for everyone. what do you think?

No, I think current name is good enough. The daemon is not limited to the Sensors and once linux-msm/hexagonrpc#10 lands, it should be once step closer to be able to provide support for other workloads.

To reiterate, I have no objections to using hexagonRPC for sensor use cases, as this was the primary goal of the project, and it should remain focused on sensors. Attempting to duplicate the functionality of an existing open-source software like fastRPC with hexagonRPC would be pointless. If this is not clear, there is no further need for discussion.

Thanks, but I'd not agree here. What should we be proposing to the customers, which need both sensors and DSP offloading? Yes, we had such questions beforehand.

[Srinivas-Kandagatla]

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

I'm thinking from the distro point of view. Can both daemons be used at the same time?

The Sensors PD on DSP supports connections from multiple HLOS processes. Although only one default daemon can be active at a time, we can plan to enable this functionality using hexagonRPC. Before proceeding, I suggest renaming the project to sensorsRPC to make it clearer for everyone. what do you think?

No, I think current name is good enough. The daemon is not limited to the Sensors and once linux-msm/hexagonrpc#10 lands, it should be once step closer to be able to provide support for other workloads.

To reiterate, I have no objections to using hexagonRPC for sensor use cases, as this was the primary goal of the project, and it should remain focused on sensors. Attempting to duplicate the functionality of an existing open-source software like fastRPC with hexagonRPC would be pointless. If this is not clear, there is no further need for discussion.

Thanks, but I'd not agree here. What should we be proposing to the customers, which need both sensors and DSP offloading? Yes, we had such questions beforehand.

TBH, fastrpc library is supposed to cater for Sensors, audio offloading and compute, if you are saying that gihub version of fastrpc library is not providing the same sensor level functionality as hexagonRPC, then we have a problem. I have not tried it my self, but if its broken, then this is another thing that should be fixed before we migrate. I dont see a point in having fastrpc lib for sensor and another one for compute..
@lumag Is it correct to say that test platforms for sensors are mostly mobiles on postmarket OS?

[quic-bkumar]

@quic-ekangupt @quic-bkumar One of the key thing to migrate from codelinaro to this fastrpc version is by making sure it works on all the upstream platforms that are already tested with codelinaro fastrpc. AFAIU, current state of the library is that it is either not tested on those platforms or it does not work on all of those platforms. Do you have the test coverage results for these platforms, starting from DB410c, DB820c, R1, RB2, RB3, RB5, X13s, QCS405, sm8250, sm8450, sm8550, sm8650, sm8750?

What should be our proposal if the users want to have both sensors and DSP offloading?

I have observed that the audience for sensors differs from that of NSP offloading. If necessary, I would certainly recommend using both tools.

I'm thinking from the distro point of view. Can both daemons be used at the same time?

The Sensors PD on DSP supports connections from multiple HLOS processes. Although only one default daemon can be active at a time, we can plan to enable this functionality using hexagonRPC. Before proceeding, I suggest renaming the project to sensorsRPC to make it clearer for everyone. what do you think?

No, I think current name is good enough. The daemon is not limited to the Sensors and once linux-msm/hexagonrpc#10 lands, it should be once step closer to be able to provide support for other workloads.

To reiterate, I have no objections to using hexagonRPC for sensor use cases, as this was the primary goal of the project, and it should remain focused on sensors. Attempting to duplicate the functionality of an existing open-source software like fastRPC with hexagonRPC would be pointless. If this is not clear, there is no further need for discussion.

Thanks, but I'd not agree here. What should we be proposing to the customers, which need both sensors and DSP offloading? Yes, we had such questions beforehand.

TBH, fastrpc library is supposed to cater for Sensors, audio offloading and compute, if you are saying that gihub version of fastrpc library is not providing the same sensor level functionality as hexagonRPC, then we have a problem. I have not tried it my self, but if its broken, then this is another thing that should be fixed before we migrate. I dont see a point in having fastrpc lib for sensor and another one for compute.. @lumag Is it correct to say that test platforms for sensors are mostly mobiles on postmarket OS?

The FastRPC library supports sensors, audio, and NSP, with no differences regarding sensors.

[quic-bkumar]

@quic-ekangupt @quic-bkumar One of the key thing to migrate from codelinaro to this fastrpc version is by making sure it works on all the upstream platforms that are already tested with codelinaro fastrpc. AFAIU, current state of the library is that it is either not tested on those platforms or it does not work on all of those platforms. Do you have the test coverage results for these platforms, starting from DB410c, DB820c, R1, RB2, RB3, RB5, X13s, QCS405, sm8250, sm8450, sm8550, sm8650, sm8750?

Our current focus is on the platforms enabled on meta-qcom. We have identified an issue with the RB3 platform, for which we have created an issue and are in the process of fixing it. @quic-ekangupt will be adding the test details to the fastRPC project. We will expand it to include all the platforms mentioned above.

[lumag]

@quic-ekangupt @quic-bkumar One of the key thing to migrate from codelinaro to this fastrpc version is by making sure it works on all the upstream platforms that are already tested with codelinaro fastrpc. AFAIU, current state of the library is that it is either not tested on those platforms or it does not work on all of those platforms. Do you have the test coverage results for these platforms, starting from DB410c, DB820c, R1, RB2, RB3, RB5, X13s, QCS405, sm8250, sm8450, sm8550, sm8650, sm8750?

Our current focus is on the platforms enabled on meta-qcom. We have identified an issue with the RB3 platform, for which we have created an issue and are in the process of fixing it. @quic-ekangupt will be adding the test details to the fastRPC project. We will expand it to include all the platforms mentioned above.

meta-qcom supports almost all mentioned platforms (well, maybe except QCS405 and SM8750).

[quic-ekangupt]

@quic-ekangupt @quic-bkumar One of the key thing to migrate from codelinaro to this fastrpc version is by making sure it works on all the upstream platforms that are already tested with codelinaro fastrpc. AFAIU, current state of the library is that it is either not tested on those platforms or it does not work on all of those platforms. Do you have the test coverage results for these platforms, starting from DB410c, DB820c, R1, RB2, RB3, RB5, X13s, QCS405, sm8250, sm8450, sm8550, sm8650, sm8750?

Our current focus is on the platforms enabled on meta-qcom. We have identified an issue with the RB3 platform, for which we have created an issue and are in the process of fixing it. @quic-ekangupt will be adding the test details to the fastRPC project. We will expand it to include all the platforms mentioned above.

meta-qcom supports almost all mentioned platforms (well, maybe except QCS405 and SM8750).

I'm able to test meta-qcom on qcs6490 with the steps mentioned in README. I was trying to do the same for RB2 board. Here, I don't see any dedicated machine conf for qrb4210, so I'm assuming that I need to go with the generic "qcom-armv8a" machine. With this, I see that the prog_firehose_ddr.elf, rawprogram and patch files are not generated which is flashed as per the doc(https://github.com/qualcomm-linux/meta-qcom?tab=readme-ov-file#flash-images).

Are the steps to boot the board(RB2) with qcom-armv8a any different which is not yet documented?

[lumag]

I'm able to test meta-qcom on qcs6490 with the steps mentioned in README. I was trying to do the same for RB2 board. Here, I don't see any dedicated machine conf for qrb4210, so I'm assuming that I need to go with the generic "qcom-armv8a" machine. With this, I see that the prog_firehose_ddr.elf, rawprogram and patch files are not generated which is flashed as per the doc(https://github.com/qualcomm-linux/meta-qcom?tab=readme-ov-file#flash-images).

Are the steps to boot the board(RB2) with qcom-armv8a any different which is not yet documented?

• Flash Linaro rescue image
• Boot the board, it boots into the fastboot mode
• Use fastboot to flash rootfs and the kernel

[quic-ekangupt]

I'm able to test meta-qcom on qcs6490 with the steps mentioned in README. I was trying to do the same for RB2 board. Here, I don't see any dedicated machine conf for qrb4210, so I'm assuming that I need to go with the generic "qcom-armv8a" machine. With this, I see that the prog_firehose_ddr.elf, rawprogram and patch files are not generated which is flashed as per the doc(https://github.com/qualcomm-linux/meta-qcom?tab=readme-ov-file#flash-images).
Are the steps to boot the board(RB2) with qcom-armv8a any different which is not yet documented?

• Flash Linaro rescue image
• Boot the board, it boots into the fastboot mode
• Use fastboot to flash rootfs and the kernel

Thanks! Able to boot-up RB2 board with this.

I have 1 more question, to transfer any artifacts, I generally use scp. However, I am unable to see the IP address even after connecting via Ethernet (the same observation with RB3Gen2 also). Is there an alternative method to push the files? Or should all the files, including test binaries and libraries, be included in the package itself?

[lumag]

I'm able to test meta-qcom on qcs6490 with the steps mentioned in README. I was trying to do the same for RB2 board. Here, I don't see any dedicated machine conf for qrb4210, so I'm assuming that I need to go with the generic "qcom-armv8a" machine. With this, I see that the prog_firehose_ddr.elf, rawprogram and patch files are not generated which is flashed as per the doc(https://github.com/qualcomm-linux/meta-qcom?tab=readme-ov-file#flash-images).
Are the steps to boot the board(RB2) with qcom-armv8a any different which is not yet documented?

• Flash Linaro rescue image
• Boot the board, it boots into the fastboot mode
• Use fastboot to flash rootfs and the kernel

Thanks! Able to boot-up RB2 board with this.

I have 1 more question, to transfer any artifacts, I generally use scp. However, I am unable to see the IP address even after connecting via Ethernet (the same observation with RB3Gen2 also). Is there an alternative method to push the files? Or should all the files, including test binaries and libraries, be included in the package itself?

First of all, could you please post outout of ip command on the device? Which image are you flashing to the board?

Second, OE has a built-in mechanism for package tests, it is called ptest. Inherit the class and provide corresponding functions / integration in order to support ptest for fastrpc.

[quic-ekangupt]

I'm able to test meta-qcom on qcs6490 with the steps mentioned in README. I was trying to do the same for RB2 board. Here, I don't see any dedicated machine conf for qrb4210, so I'm assuming that I need to go with the generic "qcom-armv8a" machine. With this, I see that the prog_firehose_ddr.elf, rawprogram and patch files are not generated which is flashed as per the doc(https://github.com/qualcomm-linux/meta-qcom?tab=readme-ov-file#flash-images).
Are the steps to boot the board(RB2) with qcom-armv8a any different which is not yet documented?

• Flash Linaro rescue image
• Boot the board, it boots into the fastboot mode
• Use fastboot to flash rootfs and the kernel

Thanks! Able to boot-up RB2 board with this.
I have 1 more question, to transfer any artifacts, I generally use scp. However, I am unable to see the IP address even after connecting via Ethernet (the same observation with RB3Gen2 also). Is there an alternative method to push the files? Or should all the files, including test binaries and libraries, be included in the package itself?

First of all, could you please post outout of ip command on the device? Which image are you flashing to the board?

Second, OE has a built-in mechanism for package tests, it is called ptest. Inherit the class and provide corresponding functions / integration in order to support ptest for fastrpc.

root@qcom-armv8a:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: sit0@NONE: mtu 1480 qdisc noop qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
3: can0: mtu 16 qdisc noop qlen 10
link/[280]
4: wlx3e13bda1d88f: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 3e:13:bd:a1:d8:8f brd ff:ff:ff:ff:ff:ff

First, I flashed linaro rescue image and then flashed boot img and rootfs from my local meta-qcom(+ fastrpc switch changes).

Thanks for the info on 'ptest'. I'll look into this.

[lumag]

First of all, could you please post outout of ip command on the device? Which image are you flashing to the board?
Second, OE has a built-in mechanism for package tests, it is called ptest. Inherit the class and provide corresponding functions / integration in order to support ptest for fastrpc.

root@qcom-armv8a:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: sit0@NONE: mtu 1480 qdisc noop qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 3: can0: mtu 16 qdisc noop qlen 10 link/[280] 4: wlx3e13bda1d88f: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 3e:13:bd:a1:d8:8f brd ff:ff:ff:ff:ff:ff

So, obviously, there is no ethernet card. RB2 board has USB ethernet onboard, so you have to disconnect USB-C switch and turn the USB part of the DIP-switch to get Ethernet.

[quic-ekangupt]

First of all, could you please post outout of ip command on the device? Which image are you flashing to the board?
Second, OE has a built-in mechanism for package tests, it is called ptest. Inherit the class and provide corresponding functions / integration in order to support ptest for fastrpc.

root@qcom-armv8a:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: sit0@NONE: mtu 1480 qdisc noop qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 3: can0: mtu 16 qdisc noop qlen 10 link/[280] 4: wlx3e13bda1d88f: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 3e:13:bd:a1:d8:8f brd ff:ff:ff:ff:ff:ff

So, obviously, there is no ethernet card. RB2 board has USB ethernet onboard, so you have to disconnect USB-C switch and turn the USB part of the DIP-switch to get Ethernet.

Thanks, I'll try this.