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>
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>
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>
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>
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>
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>
