Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for AMD ACP_6_0 ADSP #79796

Merged
merged 4 commits into from
Nov 19, 2024
Merged

Conversation

DINESHKUMARK1
Copy link
Contributor

@DINESHKUMARK1 DINESHKUMARK1 commented Oct 14, 2024

https://builds.zephyrproject.io/zephyr/pr/79796/docs/boards/amd/acp_6_0_adsp/doc/index.html

Add support for ACP_6_0 to build Sound Open Firmware with Zephyr OS on DSP.
The build target is acp_6_0. It has one Xtensa HiFi5 core, RAM & Storage: 1.75 MB HP SRAM / 512 KB IRAM/DRAM

Audio Interfaces:
1 x SP (I2S, PCM),
1 x BT (I2S, PCM),
1 x HS(I2S, PCM),
DMIC as audio interfaces.
Please check each commit message.

With these commits I have a successful build.
I obtain the zephyr.ri image which boots the DSP and loads the topology.

snd_sof_amd_acp_6_0 0000:03:00.5: booting DSP firmware
snd_sof_amd_acp_6_0 0000:03:00.5: Firmware info: version 2:11:99-29faa
snd_sof_amd_acp_6_0 0000:03:00.5: Firmware: ABI 3:29:1 Kernel ABI 3:23:0

sof@target:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 2: sofacp_6_0dsp [sof-acp_6_0-dsp], device 0: I2SHS () []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: sofacp_6_0dsp [sof-acp_6_0-dsp], device 1: I2SHS_VIRTUAL () []
Subdevices: 1/1
Subdevice #0: subdevice #0

@DINESHKUMARK1
Copy link
Contributor Author

Due to the local repository being deleted, I was unable to reopen the original PR (79534 ). Therefore, I have raised a new PR for this issue

@dcpleung
Copy link
Member

Could you squash all the "update" commits to the ones originally introduced those files?

@DINESHKUMARK1
Copy link
Contributor Author

Could you squash all the "update" commits to the ones originally introduced those files?

The changes will be updated to the original commit once the CI test failure is resolved.

@DINESHKUMARK1
Copy link
Contributor Author

Could you squash all the "update" commits to the ones originally introduced those files?

The changes will be updated to the original commit once the CI test failure is resolved.

Consolidate all updates into original commits.

@DINESHKUMARK1
Copy link
Contributor Author

Hi there! Could you please provide an update on the status of this PR?

@dcpleung
Copy link
Member

Could you rearrange the commit so the SoC commit goes before the board one? It would help with git bisect. If there is a board config with a non-existant SoC config, twister would probably not be very happy about it.

Also, since there is a BSD license mixed in the files, you will need to go through the approval process.

@kartben
Copy link
Collaborator

kartben commented Oct 29, 2024

@DINESHKUMARK1 if the PR is not actually ready to be reviewed it might be better for you to mark it as draft. Otherwise reviewers (myself included) never know when you're actually expecting them to look at the PR to actually approve it
Also, I would really encourage you to test your documentation changes locally as it looks like doc tweaks might be one of the reasons why you're pushing new edits
See https://docs.zephyrproject.org/latest/contribute/documentation/generation.html

@DINESHKUMARK1
Copy link
Contributor Author

+1 for docs

It seems the documentation could use some additional information. Otherwise, the current details should be sufficient for the end user.

@kartben
Copy link
Collaborator

kartben commented Oct 29, 2024

@DINESHKUMARK1 if the PR is not actually ready to be reviewed it might be better for you to mark it as draft. Otherwise reviewers (myself included) never know when you're actually expecting them to look at the PR to actually approve it Also, I would really encourage you to test your documentation changes locally as it looks like doc tweaks might be one of the reasons why you're pushing new edits See docs.zephyrproject.org/latest/contribute/documentation/generation.html

@DINESHKUMARK1 again, can you please test your changes locally, or put the PR back to draft mode so that we know it's not ready to be reviewed? Thanks!

@DINESHKUMARK1
Copy link
Contributor Author

DINESHKUMARK1 commented Oct 29, 2024

@DINESHKUMARK1 if the PR is not actually ready to be reviewed it might be better for you to mark it as draft. Otherwise reviewers (myself included) never know when you're actually expecting them to look at the PR to actually approve it Also, I would really encourage you to test your documentation changes locally as it looks like doc tweaks might be one of the reasons why you're pushing new edits See docs.zephyrproject.org/latest/contribute/documentation/generation.html

@DINESHKUMARK1 again, can you please test your changes locally, or put the PR back to draft mode so that we know it's not ready to be reviewed? Thanks!

This is the final edit and is ready for review. Additional information can be added in future PRs as we have few more commits to submit. I think, the current documentation should be sufficient for this PR.

@DINESHKUMARK1
Copy link
Contributor Author

DINESHKUMARK1 commented Nov 4, 2024

@DINESHKUMARK1 if the PR is not actually ready to be reviewed it might be better for you to mark it as draft. Otherwise reviewers (myself included) never know when you're actually expecting them to look at the PR to actually approve it Also, I would really encourage you to test your documentation changes locally as it looks like doc tweaks might be one of the reasons why you're pushing new edits See docs.zephyrproject.org/latest/contribute/documentation/generation.html

@DINESHKUMARK1 again, can you please test your changes locally, or put the PR back to draft mode so that we know it's not ready to be reviewed? Thanks!

This is the final edit and is ready for review. Additional information can be added in future PRs as we have few more commits to submit. I think, the current documentation should be sufficient for this PR.

Acknowledging PR review request, PR ready for review. Let me know if any additional information is needed.

dcpleung
dcpleung previously approved these changes Nov 4, 2024
@DINESHKUMARK1
Copy link
Contributor Author

could the reviewers help with the review to progress further with next steps.

Copy link
Collaborator

@kartben kartben left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could the reviewers help with the review to progress further with next steps.

I made a comment a couple weeks ago about the documentation being on the light side, and it is now even lighter, so please try to improve it a bit, I left some comments. Also, please look at making sure the board can be used with Zephyr SDK and is tested/testable in CI
Thanks

boards/amd/acp_6_0_adsp/doc/index.rst Show resolved Hide resolved
Comment on lines 60 to 61
For debugging purposes, use xt-gdb. For xcc debugging,
please contact the AMD developers’ debug tools team or utilize Cadence debugging tools.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"please contact the AMD developers’ debug tools team" is not necessarily appropriate for the documentation of an upstream open source project IMO. Please consider dropping this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't just mark items as resolved. It's up to the original reviewer to check if the comment has been correctly addressed
If you really want to close it (e.g. if request has been applied verbatim) then please add a comment explaining what you did

Comment on lines 22 to 34
System requirements
*******************

Xtensa Toolchain
----------------
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to imply that the Xtensa toolchain is a requirement which I don't think is the case judging by the text that follows.

Suggested change
System requirements
*******************
Xtensa Toolchain
----------------
System requirements
*******************
Xtensa Toolchain (optional)
---------------------------

That being said, it does not seem possible to build with the Zephyr SDK - maybe SOF module needs updating?? https://github.com/zephyrproject-rtos/sof/tree/zephyr/src/platform
(really not familiar with this so it might be something else)

...
In file included from /Users/kartben/zephyrproject/zephyr/include/zephyr/arch/xtensa/arch.h:29,
                 from /Users/kartben/zephyrproject/zephyr/include/zephyr/arch/cpu.h:27,
                 from /Users/kartben/zephyrproject/zephyr/include/zephyr/kernel_includes.h:36,
                 from /Users/kartben/zephyrproject/zephyr/include/zephyr/kernel.h:17,
                 from /Users/kartben/zephyrproject/zephyr/include/zephyr/pm/device.h:11,
                 from /Users/kartben/zephyrproject/zephyr/kernel/include/kernel_offsets.h:7,
                 from /Users/kartben/zephyrproject/zephyr/arch/xtensa/core/offsets/offsets.c:7:
/Users/kartben/zephyrproject/modules/hal/xtensa/include/xtensa/config/core.h:51:10: fatal error: xtensa/config/core-matmap.h: No such file or directory
   51 | #include <xtensa/config/core-matmap.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zephyrproject-rtos/hal_xtensa#33 this PR might update SOF modules.

Comment on lines 63 to 77
Supported Features
==================

The following hardware features are supported:

+-----------+------------+-------------------------------------+
| Interface | Controller | Driver/Component |
+===========+============+=====================================+
| I2S | on-chip | interrupt controller |
+-----------+------------+-------------------------------------+

System Clock
------------

This board configuration uses a system clock frequency of @ 200 - 800MHz.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as mentioned before, please try to follow the board template... This should come earlier, as a subsection of the Hardware heading.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This hasn't been addressed. Please check board template and other boards documentation. Also please note how comment being made usually clearly indicate which Line range they apply to -- here, for example, it's not just the system clock section I was referring to... (and as you can see this is a very good example of why one should mark conversations as resolved themselves :))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently Zephyr is being enabled on AMD reference/proprietary boards. So, we couldn't add more data as part of boards documentation. We don't have any generic boards or evaluation boards to provide more information currently. We will plan to add more information as and when possible for everyone's usage. We have just done the basic enablement of Zephyr, still we have many changes to add, so we will plan to update the documentation

+-----------+------------+-------------------------------------+
| Interface | Controller | Driver/Component |
+===========+============+=====================================+
| I2S | on-chip | interrupt controller |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure what you mean here? Is I2S actually supported? and why "interrupt controller"?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you also need an acp_6_0_adsp.yml file so that the board is tested in CI (which would also allow to catch the apparent issue of it not currently working with the Zephyr SDK)

@henrikbrixandersen
Copy link
Member

could the reviewers help with the review to progress further with next steps.

We are currently in feature freeze for Zephyr v4.0.0, so most developers are focusing on testing, bug fixes, documentation updates etc. at the moment. I am sure reviews will be ticking in once v4.0.0 is released.

Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I missed this when it came by the first time. Notes and nitpicks, nothing particularly fatal.

* dispatcher will handle exactly one flagged interrupt, in numerical
* order (low bits first) and will return a mask of that bit that can
* then be cleared by the calling code. Unrecognized bits for the
* level will invoke an error handler.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please investigate CONFIG_XTENSA_GEN_HANDLERS=y. A few legacy platforms still have these hand-generated files because they were editted, but we now run the generator script against the platform core-isa.h at build time.


#ifndef __COMMON_ADSP_CACHE_H__
#define __COMMON_ADSP_CACHE_H__
#include <xtensa/hal.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What tries to include this? Seems weird for a platform-level header to be empty, and in particular for it to act only to include non-Zephyr APIs.


static inline uint32_t io_reg_read(uint32_t reg)
{
return sys_read32(reg);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a vestigial SOF compatibility shim? Nothing in the Zephyr tree should be using these calls. Grepping around I think you got this via cut paste from imx? Really this doesn't belong here, move this to the SOF platform layer.

#define MEM_RESET_TEXT_SIZE 0x400
#define MEM_RESET_LIT_SIZE 0x8
#define XCHAL_RESET_VECTOR_PADDR_IRAM 0x7F000000
#define XCHAL_WINDOW_VECTORS_PADDR_IRAM 0x7F000400
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Standard complaint: memory layout and register addresses really want to live in device tree and not be hard-coded in a big header. I understand that's not the way it works in SOF upstream, so some amount of friction is inevitable with early work on new platforms. But really this isn't the right way to do things.


if SOC_ACP_6_0
config DCACHE_LINE_SIZE
default 128
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style: lines under a "config" should be indented with a single tab.

arch: xtensa
toolchain:
- zephyr
- xcc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, pretty much every other SOF platform is moving towards xt-clang at this point. The last Cadence toolchain version that supports xcc is now over three years old.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The acp_6_0 includes support for xcc, and for upcoming boards, we could migrate to xt-clang.

CONFIG_OUTPUT_SYMBOLS=y
CONFIG_MULTI_LEVEL_INTERRUPTS=n
CONFIG_2ND_LEVEL_INTERRUPTS=n
CONFIG_BUILD_OUTPUT_BIN=n
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one should be forced off at the arch layer, no? If you're getting a zephyr.bin (which is mostly only meaningful on cortex-M) there's a bug somewhere we should fix. It's not supposed to be something every board needs to turn off.

CONFIG_MULTI_LEVEL_INTERRUPTS=n
CONFIG_2ND_LEVEL_INTERRUPTS=n
CONFIG_BUILD_OUTPUT_BIN=n
CONFIG_CLEANUP_INTERMEDIATE_FILES=y
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one should come out. The intermediate files are actually useful for a lot of things. This setting exists for e.g. CI applications that need to have hundreds or thousands of build trees in cloud filesystems with limited storage. Generic builds should use the defaults, it's not something the board layer is supposed to care about.

Add myself and basavaraj as codeowners for ACP_6_0 related files
for SOF with Zephyr OS.

Signed-off-by: DineshKumar Kalva <[email protected]>
Add support for signing acp_6_0 SOF with Zephyr images with rimage.

Signed-off-by: DineshKumar Kalva <[email protected]>
Add a common part for AMD board ACP_6_0_ADSP.

Add support for ACP_6_0_ADSP BOARD,
which represents ACP_6_0 soc.

This has a 1 Xtensa HiFi5 core, with 200-800MHz
1.75 MB HP SRAM / 512 KB IRAM/DRAM,
1 x SP (I2S, PCM), 1 x BT (I2S, PCM), 1 x HS(I2S, PCM), DMIC as
audio interfaces.

Signed-off-by: DineshKumar Kalva <[email protected]>
Create a acp_6_0_adsp board support for
the Audio DSP on ACP soc.

Signed-off-by: DineshKumar Kalva <[email protected]>
boards/amd/acp_6_0_adsp/doc/index.rst Show resolved Hide resolved
arch: xtensa
toolchain:
- zephyr
- xcc
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The acp_6_0 includes support for xcc, and for upcoming boards, we could migrate to xt-clang.

boards/amd/acp_6_0_adsp/doc/index.rst Show resolved Hide resolved
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We’re generating zephyr.ri instead of zephyr.bin, so CONFIG_BUILD_OUTPUT_BIN is unset. This configuration is no longer necessary

Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm out of complaints

@nashif nashif merged commit 749192a into zephyrproject-rtos:main Nov 19, 2024
35 checks passed
Copy link

Hi @DINESHKUMARK1!
Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a fantastic achievement, and we're thrilled to have you as part of our community!

To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge.

Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: West West utility area: Xtensa Xtensa Architecture platform: Xilinx Xilinx
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants