Fix various bugs with the new IDC layer that show up in edge cases
where code relies on correct timing of IPIs (unsurprisingly there is a
lot of code that recovers anyway even if the IPI doesn't arrive
promptly). Leaving this as a separate patch because the prior code in
the PR has already been reviewed and it "mostly" worked:
The unmasking of the L2 interrupt bit (remember there are three layers
of masking of the IDC interrupt) was always operating on CPU0 at CPU
startup because the code had been copied blindly. Unmask the CPU
we're actually launching. It turns out cAVS 2.x re-masks this on CPU
launch automatically.
The global init code to unmask all these interrupts at startup had the
same bug, even though it turned out to be needless (the initialization
state has it unmasked until it turns it back off). Do it right
anyway. Similarly add code to clear out existing interrupt latch
state by ACKing all IDC interrupts at startup. Seems needless, but
behavior isn't documented so let's be safe.
Flag CPU0 as always "active" for the purposes of IPIs. Forgot to do
this earlier, oops.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The alignment on .bss was coming out wrong. The ". = ALIGN(4096);"
statement was being ignored, somewhat inexplicably. This resulted in
the bss symbols being assigned corret-seeming, non-overlapping
addresses. But it overlapped the page-sized padding at the end of
.data.
As it turns out, the rimage format (not the linker or Zephyr) requires
page-sized sections to copy, and the bootloader code does that copy by
writing to the CACHED mapping of the memory (.bss is, like .data,
uncached/coherent by default). So at runtime the CPU was running in a
context where the cache was populated with "booby trap" data at the
start of .bss. True .bss access would hit the memory uncached and see
the "correct" value, but at arbitrary times during execution lines
would be flushed out of L1 cache on top of it.
Oops. This was found by accident, actually, as routine changes to the
linker script to correctly support the case where KERNEL_COHERENCE=n
(i.e. put everything in the cached mapping and nothing in uncached)
suddenly hit rimage failures because of the overlap.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
New docs for cavs_v25 describe building a Linux kernel for a
Chromebook and need to talk about these kconfigs.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a SOC API to allow for application control over deep idle power
states. Note that the hardware idle entry happens out of the WAITI
instruction, so the application has to be responsibile for ensuring
the CPU to be halted actually reaches idle deterministically. Lots of
warnings in the docs to this effect.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is a hardware startup state where power gating can be "enabled"
even though the core is actually launchable via an IDC interrupt (in
fact that's the hardware default). In that state, the CPU will launch
correctly but then unexpectedly shut itself off then it enters the
idle thread.
Don't rely on initialization state, always set the power and clock
gating bits (to disable gating) immediately before CPU launch.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a struct-based interrupt masking API to match the existing shim
and IDC register interfaces. The existing interrupt controller code
isn't using it yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A simple WAITI isn't sufficient in all cases. The cAVS 2.5 hardware
uses WAITI as the entry state for per-core power gating, which is very
difficult to debug. Provide a fallback that simply spins in the idle
loop waiting for interrupts to provide a stable system while this
feature stabilizes.
Also, the SOF code for those platforms references a known bug with the
Xtensa LX6 core IP (or at least some versions), and will prefix the
WAIT instruction with 128 NOP.N's followed by an ISYNC and EXTW. This
bug hasn't been seen under Zephyr yet, and details are sketchy. But
the code is simply enough to import and works correctly.
Place both workaround under new kconfig variables and select them both
(even though they're actually mutually exclusive -- if you select both
CPU_IDLE_SPIN overrides) for cavs_v25.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On CPU startup, When we reach the cache flush code in arch_switch(),
the outgoing thread is a dummy. The behavior of the existing code was
to leave the existing value in the SR unchanged (probably NULL at
startup). Then the context switch would walk from that address up to
the top of the outgoing stack, flushing everything in between. That's
wrong, because the outgoing stack is a real pointer (generally the
interrupt stack of the current CPU), and we're flushing everything in
memory underneath it.
This also reverts commit 29abc8adc0 ("xtensa: fix booting secondary
cores on the dummy thread"), which appears to have been an early
attempt to address this issue. It worked (modulo all the extra and
potentially incorrect flushing) on cavs v1.5/1.8 because of the way
the entry code worked there. But on 2.5 we now hit the first context
switch in a case where those extra lines are in address space already
marked unwritable by the CPU, so the flush explodes.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On cAVS 2.5, there is an inherent race with the IDC interrupt. It's
used for routine IPIs during OS operation, but also for launching a
power-gated core. Recent changes moved the unmasking of the IDC
interrupt earlier, which made it possible for early OS scheduler
behavior (e.g. adding the main thread to the run queue) to
accidentally launch the other cores into LP-SRAM that had not been
initialized.
Instead of treating this with initialization ordering, keep and
maintain a list of active CPUs and check them at runtime to be sure we
never try to IPI a CPU that isn't running yet. We're going to need
this feature when we add live core offlining anyway.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Use the built-in IDC handling and not IPM (which is limited to two
CPUs). Declare two cpus for now, Zephyr tests are having problems
with more at the moment (that isn't a CI configuration, so we may have
work to do).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The original interface for the intra-DSP communication hardware on
these devices was buried inside a Zephyr IPM implementation.
Unfortunately IPM is a two-endpoint point-to-point communication
layer, it can't represent the idea of devices with more than 2 cores.
And our usage (to push a no-argument/no-response scheduler IPI) was
sort of an abuse of that metaphor anyway.
Add a new IDC interface at the SOC layer, borrowing the C struct
convention already used for the DSP shim registers.
Augment with extensive documentation, extracted via a ton of
experimentation on cAVS 2.5 hardware.
Note that this leaves the previous driver in place for the cavs_v15
and intel_s1000 devices. In principle they should use it too (the
hardware registers are identical), but this hasn't been validated yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Earlier platforms were relying on the system ROM to have done this
correctly, but with CAVS 2.5 we launch the CPU into our own code
directly. So we need to do those steps manually. And there's also a
new one on this hardware, which has software power control over the
cache SRAM.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Hardware defaults for the secondary CPUs have the S32C1I instruction
set to be atomic only with respect to the local L1 cache, which is
basically useless on a multiprocessor platform. The CPU0 boot path
sets this manually, so we need to duplicate that here.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On MP cores that don't come through the core entry point
(e.g. TGL/v2.5) we reach C code with hardware defaults for the RPO/TLB
settings. Set these up correctly on entry.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This hardware works a little differently. The cores will start up
immediately on receipt of an IDC interrupt (they don't need the host
to be involved), but they don't have a ROM. They start executing at
the start of the LP-SRAM block always. Copy over a tiny trampoline
for them that jumps to the existing multiprocessor startup path.
Also set the PS WOE bit to enable register windows in the startup
path. This isn't the hardware default, and where the ROM would do
that for us before here we need to make sure it's on.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This reverts commit ee7773fb46.
Unfortunately this mechanism doesn't seem to actually work on the SDK
linker. The emitted sections, when passed a symbol name as the "start
address" just appear wherever the "." variable was pointing (in this
case, into the cached region). That breaks the kernel coherence
layer, obviously.
Revert for now, which will regress the XCC build fix pending a proper
root cause.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This aligns the SoC initialization with the one in SOF,
especially the manipulation of clock control and power control
registers. These registers are not entirely the same across
CAVS versions, so we need to deal with them according to
which version we are building for. This also consolidates
the macros for these registers to the one provided by SOF
(soc/shim.h) to avoid duplication. Another note is that
the usage of clock gating bit was not correct. In SOF,
clock gating of SoC cores should be allowed but the old code
in Zephyr prevented clock gating, which has the potential to
prevent the whole DSP from going into low power mode.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The wall clock timer is not (per documentation) part of the
"timestamping" register set on the DSP. And its counter and
comparator registers work fine always. But if the DSP isn't set as
the "owner" of the timestamp hardware, wall clock interrupts never
arrive.
Also grab the PLL ownership too, because SOF already does anyway.
While we don't have a dynamic clock driver yet, we will surely want
one soon and will needt this.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These windows control host visibility of the trace output buffer. The
buffer itself is writable memory always, but until we get to the
register init the host can't see them. Since they contain
printk/logging output, they REALLY need to be initialized earlier than
anything else.
Also remove a rogue memset of the trace buffer. That buffer is
already being initialized in a lazy-evaluated way by the trace output
code, and blowing it away here has the effect of forgetting anything
earlier code was trying to log!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The default development environment for this target is in fact a
consumer Chromebook available to anyone. So it deserves public
documentation.
Note that this spends considerably more time explaining the details of
how to configure a chromebook as a Zephyr development platform than it
does the process for building and running Zephyr (which is really very
conventional). Chromebooks, which allow user-signed audio firmware,
are a great boon to SOF development. But they were never intended as
developer devices themselves.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a loader script variant for Tiger Lake (cAVS 2.5) devices, which
have very slightly different loading behavior from older 1.5 DSPs.
This is added as a "-v25.py" script, and the original has been renamed
to cavs-fw-v15.py. Note that there is no good reason except schedule
pressure that these are not the same script, I just wasn't able to
make a single script work compatibly in the time available.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add support for the extended manifest blocks that recent versions of
rimage are including as a prefix on the firmware blob.
Also include some PCI runtime PM tricks to reliably enable the DSP
device on kernels that have turned off the DSP device automatically
(e.g. systems that have PM enabled by default but where the SOF driver
is not loaded -- chromebooks work this way, potentially other
distros).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Zephyr Bluetooth Mesh move adv send cb to buf destructor
callback, There are two net_buf_pool define, one to adv.c
and ore to friend.c, we are missing destructor in friend.c.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Two checks reported wrong value if the value was invalid.
CIS parameter check would always fail on correct values
due to missing negation of valid_chan_qos.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Fix two typos in documentation, one in a sample's comment, and one in a
sample's console message. Found while learning Zephyr and exploring the
sources.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Adds flash partitions and chosen nodes to the mimxrt1024_evk device tree
to support mcuboot on the internal QSPI flash.
Also adds missing zephyr,itcm chosen node.
Also enables FlexSPI flash driver XIP mode support on this board to
support mcuboot.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@prevas.dk>
add correct binding, fix size to 32MBit, add erase and write
block size to support mcuboot and rename to reflect the actual
flash model.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@prevas.dk>
the config symbol was missing for some reason even though
the soc does have a flexspi peripheral like most other socs
in the family.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@prevas.dk>
For each compiler, also set a CMAKE_GCOV var referencing the appropriate
gcov tool.
Tested with gcc and host-gcc on the ChromeOS codebase.
Signed-off-by: Jeremy Bettis <jbettis@chromium.org>
Problem:
In some cases, as described in: https://github.com/zephyrproject-rtos/zephyr/issues/36948
shell backend sends characters to output before serial device
is ready for it. It results in observing additional characters
inserted on the shell input after device boot.
Solution:
Added waiting on DTR signal before sending anything to the output.
Fixes: #36948
Signed-off-by: Kamil Kasperczyk <kamil.kasperczyk@nordicsemi.no>
When Public Key field is set to RFU value then we should send
Provisioning Fail with Invalid Format error.
Signed-off-by: Michał Narajowski <michal.narajowski@codecoup.pl>
Counter was not reset between various tests which may hide the fact
that number of preemptions is less than expected.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Stress test that was validating thread safeness was configured to use
higher sys tick rate and targeting qemu_x86 platform. However, it was
also build for other platforms and was failing. Fixing it by extracting
stress tests to separate configuration that is run only on qemu_x86.
Modified the test to fail when number of preemptions is less than
expected only on qemu_x86.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Fix MPU fault due to incorrect EV_COUNT, `conn_change`
signal was not accounted for in the array used by k_poll.
Relates to commit 7854088116 ("Bluetooth: ISO: Fixes
missing handling of broadcast ISO TX").
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Remove the locally MSI/MSI-X capabilities ID define and use the
newly introduced one from the PCI Code and ID Assignment
Specification Revision 1.11 document header.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Add defines for all the PCI and PCIe capabilities from the PCI Code
and ID Assignment Specification Revision 1.11 document.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Extend the PCIe API to find Extended Capabilities in the PCI Express
Extended Capabilities located in Configuration Space at offsets 256
or greater.
Note: the Root Complex Register Block is not supported
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Improve the disconnect handling in the sample, and
avoid creating a new cig for each connection.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Instead of disconnecting ISO channels on ACL,
we put them in a non-connected state, and wait for
the ISO disconnect events.
This ensure that the controller has free'd the
ISO channels when the iso disconnect callbacks
are received. It will thus be possible to e.g.
terminate the CIG on the ISO disconnect callback.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
When an ISO channel is disconnect on the central, it is
not deallocated, but merely disconnected. This is because,
as per the HCI spec, the CIS handle lives on in the CIG.
Instead of unref'ing the bt_conn to 0, we simply put the
channel and connection in the disconnected state.
This also fixes a few missing returns for
terminating a CIG.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The disconnect handling of ACL connects in the sample was done
incorrect, and caused a call to bt_conn_unref with a NULL
pointer.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
There might be a sign extension when a long is promoted to
int_value_type and the former type is smaller than the later.
This produces the wrong output if the specified format is unsigned.
Let's avoid this problem by handling signed and unsigned cases
explicitly. When the type already matches int_value_type then the
compiler is smart enough to recognize the redundancy and removes
unneeded duplications automatically, meaning that the code will stay
small when code size matters.
A similar issue also existed in the restricted %llu case.
The fix is the same as above.
Those fixes exposed wrong results in the printk.c test with %llx
so fix that as well.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Function parameters can be checked without MQTT instance lock being
held. Additionally if NULL parameter would be passed (which this check
tries to handle), then function would return without releasing lock.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Sending of > 2k buffers leads to split socket writes.
Current implementation is not checking for full buffer size.
ztls_sendmsg_ctx proceeds to next iov on sucessful write.
Solution: Add loop into ztls_sendmsg_ctx to process whole buffer
before proceeding to next iov.
Signed-off-by: Pavlo Hamov <pasha.gamov@gmail.com>
Apply a similar fix for cavs_v20 as was done for other cavs platforms in
commit ee7773fb46 ("soc: intel_adsp: fix linker script for XCC").
Without this fix, cavs_v20 build with fail with 0.13.0 Zephyr SDK.
Fixes: 74cc8bee7c ("xtensa: cavs_v20: use uncached addresses to support SMP")
BugLink: https://github.com/thesofproject/sof/issues/4703
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
