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

Intel: ADSP: move HPSRAM mask into assembly #78057

Merged
merged 1 commit into from
Sep 9, 2024

Conversation

lyakh
Copy link
Collaborator

@lyakh lyakh commented Sep 5, 2024

Assembly in power_down() in power_down.S already defines data and code to be locked in cache when powering down SRAM. Instead of adding another such location in power.c, move the hpsram_mask[] array into power_down.S. This fixes hard to debug failures when shutting down the ADSP.

Yes, thesofproject/sof#9268 raises its ugly head again: https://sof-ci.01.org/sofpr/PR9430/build7664/devicetest/index.html We are no wiser about real reasons, but this is yet another attempt at a more robust fix

Assembly in power_down() in power_down.S already defines data and
code to be locked in cache when powering down SRAM. Instead of adding
another such location in power.c, move the hpsram_mask[] array into
power_down.S.  This fixes hard to debug failures when shutting down
the ADSP.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
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.

FWIW: I still bet that if you whiteboxed a rig to enumerate all the dcache indexes and check how many of them can be pinned, we'd discover that something in the boot ROM or elsewhere has left a line pinned accidentally, preventing more pinning at that index, and we're just hitting that by bad luck in the linker.

Would be non-trivial assembly to write, and tedious to debug as the only feedback is a panic, but not "hard" hopefully.

@lyakh
Copy link
Collaborator Author

lyakh commented Sep 5, 2024

FWIW: I still bet that if you whiteboxed a rig to enumerate all the dcache indexes and check how many of them can be pinned, we'd discover that something in the boot ROM or elsewhere has left a line pinned accidentally, preventing more pinning at that index, and we're just hitting that by bad luck in the linker.

Would be non-trivial assembly to write, and tedious to debug as the only feedback is a panic, but not "hard" hopefully.

@andyross I tried some version of that and didn't identify any addresses where locking cache lines would fail. Maybe my attempt wasn't correct, but at least I did try.

@nashif nashif merged commit be041b1 into zephyrproject-rtos:main Sep 9, 2024
26 checks passed
@lyakh lyakh deleted the hpsram branch September 10, 2024 05:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: Intel ADSP Intel Audio platforms
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants