These macros (LPSRAM_MASK, SRAM_BANK_SIZE, HOST_PAGE_SIZE) never
change, and are always used in just one file.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The HP SRAM block address and size is specified in four different ways
(devicetree, "SRAM_*", "HP_SRAM_*" and "L2_SRAM_*" macros). Unify,
moving the C definition (which just fetches it from dts) to a single
header and out of the platform layer.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was an abstraction layer without a purpose. All existing
platforms have the same (LXn core) layout. When we need to split this
out in the future, the right thing will be to use the values already
provided by the platform core-isa.h and not duplicate them anyway.
Think of this as a first step to an incoming rework of the Zephyr
Xtensa interrupt entry generation, which is long overdue.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The generic bootloader code used a per-device "platform.h" file
imported from SOF. These turn out to have very little actual content.
Move them to the core directory in a single header for now, pending
some rework to place the settings in devicetree.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The linker script (and a little bit of SOF) still has support for an
older mechanism for bootstrapping secondary cores by copying code into
lp-sram from a "manifest" emitted by the linker. This actually never
worked in Zephyr, and we've implemented a different scheme that uses a
small runtime-copied trampoline instead.
Remove.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Each platform was defining its own shim.h header, with slightly
variant field definitions, for a register block that is almost
completely compatible between versions. This is made worse by the
fact that these represent an API imported fairly early from SOF, the
upstream version of which has since diverged.
Move the existing shim struct into a header ("cavs-shim.h") of its
own, remove a bunch of unused symbols, fill in definitions for some
registers that were left out, correct naming to match the hardware
docs in a few places, make sure all hardware dependencies are source
from devicetree only, and modify existing usage to use the new API
exclusively.
Interestingly this leaves the older shim.h header in place, as it
turns out to contain definitions for a bunch of things that were never
part of the shim register block. Those will be unified in separate
patches.
Finally: note that the existing IPM_CAVS_IDC driver (soon to be
removed from all the intel_adsp soc's) is still using the old API, so
redeclare the minimal subset that it needs for the benefit of the
platforms in transition.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Reorganize the initialization code to cleanly separate the platforms
and clarify which code is common. The #if'ery was sort of a mess.
This is in preparation for an incoming patch that unifies the shim
register definitions across platform variants.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Misc cleanup, no non-trivial logic changes.
Swap in new ("rsr <reg>, REGISTER_NAME") syntax for Xtensa SR's in
place of inconsistent usage of the older one ("rsr.REGISTER_NAME
<reg>").
Remove the legacy handling of !KERNEL_COHERENCE cases for allocating
the cpu start record. That has long been a requirement of
multiprocessor code on this platform.
Remove the synchronous testing of the "alive" flag in
arch_start_cpu(). Nothign about that API is intended to be
synchronous, and in fact the Zephyr SMP layer is already doing the
same trick.
Remove some vestigial dead code at the end of z_mp_entry(). It was
apparently intended to handle the case where a CPU function returned,
but that's not legal anyway. And it was only enabled in the case
where there was only one CPU anyway, which was an impossible situation
(you can't evercall arch_start_cpu() successfully on a system with
only one core, for obvious reasons -- the only core is already
running!). Replace with an assertion.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The cAVS bootloader code (for... somewhat silly reasons) doesn't build
via the same paths as regular Zephyr object files, so it wasn't
getting the _ASMLANGUAGE define. That meant that Zephyr headers
defining BIT() were using syntax incompatible with some assemblers
(specifically the Cadence xcc assembly; current gas versions were
fine).
Not 100% sure this is the best spot to put this, but the root fix is
to get the bootloader building into the same link as the rest of
Zephyr anyway.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
- refactors cache initialization functions by moving it from
soc.c and placing it in soc_cache.c
- moves SPIRAM's bss zeroing before SPIRAM initialization
Signed-off-by: Glauber Maroto Ferreira <glauber.ferreira@espressif.com>
Applying similar changes to cavs_v20 as in commit
8bc4539cec:
Older binutils, like the (nine-year-old!) 2.23 version that powers
many Cadence XCC toolchains, happen not to support the "~" operator to
perform bitwise negation. And they generate an absolutely hilarious
series of inscrutable error messages when they try to tell you this
fairly simple fact.
Just fold it into the constant.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This reverts commit 3cc14b2c2b.
Revert this due to the same reason as commit
a29b66bbf5:
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.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The mismatch between the slot number and the sequence ("id") made me
suspect a bug for too long. Fix one related comment and add two more. No
code change.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This joins all clock control handling to same source
by using hal clock functions. It also brings ESP32C3
clock support.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
When built with XCC for Apollolake, Zephyr fails to boot with the
default multi-core option enabled. Invalidate cache before reading
the firmware image to fix that.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Add support for i.MX8MP target.
This has a 1 Xtensa HiFi4 core, with 64 KB TCM,
256KB OCRAM, 8MB SDRAM and 1 SAI as audio interface.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Replaces the prefixes of gpio_matrix_in and gpio_matrix_out
to unify those function calls on all supported socs.
Signed-off-by: Glauber Maroto Ferreira <glauber.ferreira@espressif.com>
Older binutils, like the (nine-year-old!) 2.23 version that powers
many Cadence XCC toolchains, happen not to support the "~" operator to
perform bitwise negation. And they generate an absolutely hilarious
series of inscrutable error messages when they try to tell you this
fairly simple fact.
Just fold it into the constant.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This feature got written twice for two different purposes (to inform
the SOF app of which CPUs are running, and to predicate the delivery
of IPIs to the cores ready to receive the interrupt). Use only one.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On pre-2.5 cAVS, the initial IDC interrupt to start the other core is
handled by software in the firmware ROM. That means that it has to be
unmasked for the mechanism to work (with 2.5, the interrupt is handled
by hardware regardless of what the masking state in the interrupt
controller is).
Similarly, the Xtensa Region Protection Option entries have already
been set by ROM code when we arrive in enable_l1_cache(), so we can
skip that part on older machines. Also removed because trying to
rewrite those entries was causing inexplicable hangs on cAVS 1.5,
plausibly because the region had active cache lines.
(This patch is separate for easier review in a long evolving PR.
Technically it represents a bisection problem as the "New IDC Driver"
patch before this was a regression. Seems like a safe enough thing to
handle if you land on this.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
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>
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>
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>
