On cAVS 1.8 (specifically) there seems to be a propagation delay on
the IPC registers. Hitting the TDA register to signal DONE too soon
after clearing the interrupt via TDR can cause the interrupt to be
dropped. Merely polling for it to read back correctly isn't
sufficient, we need an actual sleep here.
(The behavior that a message won't send while an existing message is
in progress is actually a hardware feature that is new with 1.8. My
guess is it's a little glitchy in its first version.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On cAVS before 2.5, core power was controlled by the host. Add a
command to the cavstool.py script to allow us to do that under test
command so we can exercise multiprocessor startup/shutdown outside of
SOF.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Remove the soc_relaunch_cpu() API. There's now nothing that this does
that isn't already done by the kernel's own z_smp_start_cpu() API. We
don't need a SOC-level API for this anymore.
Rename soc_halt_cpu() to soc_adsp_halt_cpu() to clarify the domain,
simplify by removing the synchronization (there's nothing to
synchronize!). Also move its declaration and docs into the soc.h
header.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Things had gotten a little tangled in there so let's do some cleanup.
Remove the distressingly-special-purpose z_reinit_idle_thread() hook
(which existed to support secondary core bringup when
SMP_BOOT_DELAY=y), and just fold that into a generic z_init_cpu(),
which we can call in obvious and symmetric ways from main
initialization, z_smp_init(), and z_smp_start_cpu() (the now-official
programmatic hook for starting cpus).
Remove the "#if CONFIG_MP_NUM_CPUS > 1" exclusions. These weren't
saving any code size and were propagating themselves into platform
layers trying to avoid build failures.
There are some "special" APIs added for SOF which need to go away in
favor of the newer/generic z_smp_start_cpu(). Collect them in one
place and put them under a "#ifdef CONFIG_SOF" to prevent them from
being used in Zephyr apps.
Move some function declarations that didn't have homes into
<kernel/thread.h>.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
As Zephyr begins to absorb drivers for these platforms that had
previously been managed by the SOF app, there's a need for a rapid
board-specific smoke test to use during development.
This starts with the smp_boot_delay test (itself a unit test for a
SOF-derived feature) and adds a host IPC case (that needs to match
code in cavstool.py on the other side of the PCI bus!).
It will grow more features over time as needed.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This is a slightly higher level Zephyr device that manages the host
IPC device for applications. There's an interface to make synchronous
and asynchronous calls, to receive commands via (interrupt context)
callbacks and emit async "done" notifications after processing is
complete. It should work for pretty much any application
architecture.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a new board to support Intel Tiger Lake H PCH variant of cAVS2.5.
Move common Kconfig options for cavs25 to soc level. No need to
replicate these for every board.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The Xtensa implementation of arch_irq_offload() required that the user
select the correct interrupt manually, and would race with itself if
invoked from separate CPUs (it was saved here by the main
irq_offload() function which has a semaphore to serialize access).
Use the new gen_zsr.py script to automatically detect the highest
available software interrupt, and keep a per-CPU set of
callback/parameter pointers.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We are enabling logging in the SoC, this should be an application
decision, not a hardware decision.
Additionally, we are disabling logging defaults for testing, which
results in some tests failing on those platforms due to missing messages
in the test output.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Failures to boot are not exclusive to the cavstool.py, they can happen
with the kernel driver and --log-only too. For such a situation this
commit adds a useful delay and these two log lines (before the mmap
crashes eventually):
INFO:cavs-fw:Waiting for firmware handoff, FW_STATUS = 0x81000012
WARNING:cavs-fw:Load failed? FW_STATUS = 0x1006701
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Intel's adsp needs to set, at a minimum, a clocking bit before the driver
can initialize the designware dma controller. In many ways it is the
designware dmac IP but with additional registers and functionality added
on top of it. So the code structure here follows how the hardware
appears to be designed, layered on top of the designware driver.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Modified Xtensa soc intel_adsp to use nul when building on Windows host
and /dev/null when on Linux.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Audio users want logging too. This restores feature parity since the
older scripts were removed in commit
cd5302fa00 ("boards/intel_adsp_cavs15: Remove ancient tooling")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Don't "crash" when passing no argument at all.
Log exceptions, adding for instance the second line:
ERROR:cavs-fw:Could not map device in sysfs; run as root?
ERROR:cavs-fw:[Errno 13] Permission denied: \
'/sys/bus/pci/devices/0000:00:0e.0/power/control'
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Add an cavs-ipc-regs.h header for the SOC with definitions for the IPC
mechanism used for host communication.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is a hardware bug with stream reset, it won't stop the stream.
I thought it was limited to just the early versions, but it turns out
that 2.5 has it too in some variants. Which is frustrating, because
the TGL chromebook I have doesn't like the START clear. But all
systems work with an extra delay between them, so do that.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This platform was stale for a long time and got a little left behind.
Basic OS stuff was working but secondary core bringup didn't. It has
a slightly different set of choices from the "weird hardware
quirks" menu:
+ Like cAVS 1.5, it boots from a ROM that needs a short delay after
power-up before it can receive the startup IDC.
+ But, like 2.5 and unlike 1.5, it doesn't start running until the
PWRCTL bit for the core gets set by DSP software (1.5 gets launched
by the host). So the delay needed to move down a bit.
+ It wants that PWRCTL bit to be set last, after CLKCTL enables the
clock. (Which makes sense I guess: EE classes always tell you hold
circuits in reset while an initial clock propagates). Not sure why
it was in the reverse order originally; this way works for
everything.
+ The ROM likes to scribble on the interrupt controller and mask its
own IDC interrupts after we've already set it up. They have to be
unmasked. We had code to do this already, thinking it was a
workaround for legecy SOF code (that we never actually located).
Now I'm thinking it was this behavior all along being detected by
SOF's more extensive hardware CI. Take out the test and do it
always, it's like nine instructions.
+ The host/loader-side behavior is a mix of 1.5 and 2.5. It won't
actually start the secondary cores under host command, but it does
need to see bits set for them in ADSPCS for the DSP-initiated
power-up to work (2.5 would just ignore all but core 0's bits).
+ Also, like 1.5, it needs the host DMA stream to be explicitly
stopped (and not just reset) or else further loads will be unstable.
Note that the loader changes now require more logic than just "1.5 or
not", so the platform detection has been enhanced to fully categorize
the device based on PCI ID (not quite: we don't have any 2.0 platform
hardware, so I left that alone for now).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There's desire for a "log only" mode like the older adsplog script
had. Add a few other quality of life command line options too. And
catch the most obvious user errors to print a message instead of a
stack dump.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This is based closely on the older cavsload.sh script, but updated to
keep up with interesting new twister behavior, with a cleaner
interface for CI integration that doesn't require editing the file,
somewhat better internal documentation, and with a more focused eye on
use as a twister tool specifically.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing scripting for these platforms has gotten a little stale.
The loader had bifurcated into a v15 and v25 variant, both of which
lived in the cavs15 board directory. Building off Shao Ming's
excellent (if somewhat surprisingly committed) rework to unify
unchanged parts of the scripts, let's finish the job.
This adds a "cavstool.py" script with the following advantages:
+ It's just one script for everything, with a single unified load
process that works reliably on both 1.5 and 1.8+ hardware.
+ It runs on all cAVS platforms (with a compatible kernel, those
requirements haven't changed)
+ It automatically emitts logging synchronously after loading,
eliminating the race between adsplog.py and cavs-fw.py where you
could see logging from a previous test run.
+ It automatically detects and unloads a linux kernel module managing
the same device (even if SOF has renamed the module again, heh).
+ Timings have been tuned up in general, it's about 2 seconds faster
to get to first log output now.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This sets CONFIG_KERNEL_VM_SIZE to define the size of virtual
memory region which can be used by the TLB driver. The size is
derived from the actual SOF code where they say the TLB register
space is of size 0x1000. There are 2048 TLB entries (for 2 bytes
per entry), which translates to 8MB of virtual memory space with
4KB pages.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The newer sys_winstream utility is considerably simpler and much
faster for the reader. Use that instead.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It's not uncommon to have Zephyr running in environments where it
shares a memory bus with a foreign/non-Zephyr system (both the older
Intel Quark and cAVS audio DSP systems share this property). In those
circumstances, it would be nice to have a utility that allows an
arbitrary-sized chunk of that memory to be used as a unidirectional
buffered byte stream without requiring complicated driver support.
sys_winstream is one such abstraction.
This code is lockless, it makes no synchronization demands of the OS
or hardware beyond memory ordering[1]. It implements a simple
file/socket-style read/write API. It produces small code and is high
performance (e.g. a read or write on Xtensa is about 60 cycles plus
one per byte copied). It's bidirectional, with no internal Zephyr
dependencies (allowing it to be easily ported to the foreign system).
And it's quite a bit simpler (especially for the reader) than the
older cAVS trace protocol it's designed to replace.
[1] Which means that right now it won't work reliably on arm64 until
we add a memory barrier framework to Zephyr! See notes in the code;
the locations for the barriers are present, but there's no utility to
call.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is no need to call soc_mp_init() if CONFIG_MP_NUM_CPUS
indicates only 1 CPU is being used. This also fixes an undefined
reference to soc_mp_init() since mp_cavs.c is not compiled
unless the build is targeting more than 1 CPU.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This is trick (mapping RAM twice so you can use alternate Region
Protection Option addresses to control cacheability) is something any
Xtensa hardware designer might productively choose to do. And as it
works really well, we should encourage that by making this a generic
architecture feature for Zephyr.
Now everything works by setting two kconfig values at the soc level
defining the cached and uncached regions. As long as these are
correct, you can then use the new arch_xtensa_un/cached_ptr() APIs to
convert between them and a ARCH_XTENSA_SET_RPO_TLB() macro that
provides much smaller initialization code (in C!) than the HAL
assembly macros. The conversion routines have been generalized to
support conversion between any two regions.
Note that full KERNEL_COHERENCE still requires support from the
platform linker script, that can't be made generic given the way
Zephyr does linkage.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Continue the previous work, moving the cAVS hardware dependencies into
a separate file, leaving soc_mp.c with only OS-generic details to
track.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Clean up soc_mp.c a bit. Put all cAVS register use in functions
dedicated to hardware details (e.g. "soc_start_core()"), leave the
Zephyr OS tracking (e.g. the CPU start record, the active cores array,
etc...) in generic code.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This got broken during the cpu_init unification pass. I appear to
have copied that zero out of code that initialized Zephyr on a
uniprocessor config somewhere. But what it means is that any use of
the S32C1I instruction to store to any memory type will trap an
exception! And even when CONFIG_MP_NUM_CPUS==1, we will emit code to
do that in the atomics layer when SMP=y.
That configuration ("SMP" with 1 cpu) is actually exercised by some
tests, including important ones like timer_api. These got broken.
Fix.
Really it's never correct to have anything but 1:1:1 ("external RCW
transaction") on these CPUs. All Intel cAVS processors have hardware
atomics support. We owe it to all the code we'll run to make sure it
works as documented and doesn't explode.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When running under a simulator, it's difficult to extract output from
the window (it's difficult with hardware too!). Add "SIMCALL" output
to stderr (it's literally just 3 extra instructions) as an optional
feature so this subsystem itself can be debugged without herculean
effort.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Reword the symbols to make it clear what they mean ("INIT_LPSRAM"
instead of "RESET_MHE_AT_BOOT") and use them correctly instead of
SOC_SERIES_* kconfigs.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We don't define a MemoryException handler, nor is one appropriate for
this hardware as it stands. And the empty section keeps causing
linker warnings we have to work around. Remove.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Single-core instantiations of this hardware and single-core builds of
firmware still exist, so we should support that without needless
bloat.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The MP startup code had a hardcoded INTLEVEL field of 5 in the initial
value of PS. That's needless, INTLEVEL is a full 4 bit field even if
the number of hardware interrupt levels is lower (and in fact 0xf is
the documented hardware reset state). Set that instead, so that this
code will work with any XEA2 hardware. This also matches the similar
code path in boot startup.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Most of soc.c is actually interrupt handling glue for the intc_cavs
driver. Give it its own file so that SOC initialization and bringup
can live separately.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
XCHAL_HAVE_ICACHE_DYN_ENABLE is not set for any Intel cAVS
hardware, so MEMCTL configuration is not done properly leaving
icache disabled. This can be seen as ~10X slowness when running
code on non-primary cores. Fix the issue by using XCHAL_USE_MEMCTL
to check for MEMCTL usage.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The CAVS linker scripts in Zephyr and "plain" (XTOS) SOF seem to share
the same origin and they mostly duplicate each other so they naturally
keep diverging from each other. This commit catches up with the SOF
commit ef43899c580f (thesofproject/sof/pull/2996) which added
the *(.trace_ctx) sections as part of the runtime log filtering
implementation (feature request thesofproject/sof/issues/2172)
Paraphrasing that commit, the goal is to create at link time a C-like
array by regrouping scattered trace contexts so they can be iterated on.
Together with some other changes in SOF, these 3 additional lines are
enough change in Zephyr to fix SOF bug thesofproject/sof/issues/5032
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The fix for xcc build failures yesterday forgot to preserve the
squashing of stderr from the objcopy steps. As mentioned in the
comments, there are deliberate empty sections in this link that
binutils warns about, but which are actually required, Cadence has
some vector sections in their standard exception table that don't get
populated and rimage has non-code sections that may be left empty for
non-audio-driver applications like tests.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Recent linker changes got ahead of the toolchain and started using
features not available in the binutils 2.23-based Xtensa toolchain.
Specifically:
+ The section arguments to objcopy don't accept wildcards.
+ It's not legal to have an ALLOC section emitted to a region outside
a declared MEMORY space. So various non-mapped sections populated
by C structs have to be put somewhere with an explicit address.
+ The older linker won't automatically create an empty section just
because you assigned to ".", so the Zephyr tests that lack a
.fw_metadata section get rejected by rimage. The fix here is a
little clumsy: copy the section out of zephyr.elf into a
(potentially-zero-length) temporary file, then add it back to
main.mod as a final step.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The module copy was clearing BSS sections from the module list, but we
already clear the full memory space immediately after SRAM power-up so
that's needless, just like the legacy reset vector bss clear that got
removed earlier. (Yes: that means that this code used to be writing
zeros to .bss three times!)
Similarly, put a symmetric clear on the LP-SRAM bank for safety (it's
not currently used by Zephyr but we do start it up). And move the
cache flush to the end of initialization immediately before OS
handoff.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Both soc.h and adsp/cache.h were very small headers, there's no good
reason to have a separate header just for two one-line inlines.
Merge.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This is some SOF code that got imported into Zephyr. But it's not a
Zephyr API and Zephyr doesn't use it. Unfortunately, the Zephyr
definition is now the one actually used at runtime in SOF, so we can't
remove it.
Put a guard around the definition so nothing else uses it until we get
it moved back home.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Dead code. Unused in Zephyr. Seems like SOF is picking this up from
its own headers via reading CONFIG_MP_NUM_CPUS correctly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Syntax beautification and general simplification pass:
+ Remove some spurious padding around the _data_end symbol. That's a
Zephyr symbol and should reflect the actual end of the data section in
bytes.
+ Squash a warning that crept in where the linker doesn't like
changing cache mapping and padding at one time, clarify in docs.
+ Use the pre-existing-but-heretofore-unknown-to-me Zephyr
debug-sections.ld include file instead of putting all the DWARF
sections in by hand.
+ Move the .xt* sections to explicit zero addresses, since that's what
debug-sections.ld does for its output and if I don't they'll end up
with funny values.
+ Use Zephyr brace-on-same-line style consistently
+ Remove cargo-cult noop patterns like ALIGN(4) and ABSOLUTE(.) (none
of these sections get furthur relocated!)
+ Clean up the SEGSTART_* API so that it doesn't need to have
CONFIG_KERNEL_COHERENCE guards.
+ Remove a few unused/legacy symbol exports ("end", "__stack") so as
not to pollute the namespace.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This header is now included in only one place, and just contains a
handful of very-bootloader-specific platform tunables that will never
be exported elsewhere. Move that code into the C file. Longer term
we should configure the memory controllers with devicetree as much as
practical, but there's no reason to keep this header around.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
