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>
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>
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>
System heap buffer was moved from dram0_0_seg to dram0_1_seg.
This commit fixes system heap buffer placement.
Signed-off-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
SMP support on cAVS is implemented by using uncached addresses for all
writable data sections except for stack, i.e. for .data, .bss and
some other specialised ones. So far that has been implemented for
cAVS 1.5/1.8. This patch does the same for cAVS 2.0.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
For IMX, for timer interrupt, the interrupt handler
was not the correct one executed and that’s because
the handlers were not at the expected address.
For IMX the size constraint of the interrupt vector
table entry is 0x1C bytes of code, less than usual.
I've added a small indirection to bypass this size
constraint and moved the default handlers to the end
of vector table, renaming them to
_Level\LVL\()VectorHelper.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Add a common part for all i.MX boards.
Add support for i.MX8, which represents i.MX8QM.
This has a 1 Xtensa HiFi4 core, with 64 KB TCM,
448 KB OCRAM, 8MB SDRAM and 1 ESAI, 1 SAI as
audio interfaces.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Cleanup and preparation commit for linker script generator.
Zephyr linker scripts provides start and end symbols for each larger
areas in the linker script.
The symbols _image_text_start and _image_text_end sometimes includes
linker/kobject-text.ld. This mean there must be both the regular
__text_start and __text_end symbols for the pure text section, as well
as <group>_start and <group>_end symbols.
The symbols describing the text region which covers more than just the
text section itself will thus be changed to:
_image_text_start -> __text_region_start
_image_text_end -> __text_region_end
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Cleanup and preparation commit for linker script generator.
Zephyr linker scripts provides start and end symbols for each larger
areas in the linker script.
The symbols _image_rom_start and _image_rom_end corresponds to the group
ROMABLE_REGION defined in the ld linker scripts.
The symbols _image_rodata_start and _image_rodata_end is not placed as
independent group but covers common-rom.ld, thread-local-storage.ld,
kobject-rom.ld and snippets-rodata.ld.
This commit align those names and prepares for generation of groups in
linker scripts.
The symbols describing the ROMABLE_REGION will be renamed to:
_image_rom_start -> __rom_region_start
_image_rom_end -> __rom_region_end
The rodata will also use the group symbol notation as:
_image_rodata_start -> __rodata_region_start
_image_rodata_end -> __rodata_region_end
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Move the IDT_LIST memory region to the location recommended by
`intlist.ld`. The documentation specifies that this region should not
overlap other regions, and there is no guarantee that the area after the
`SRAM` region is not used. The end of the address space is much less
likely to be a valid RAM address.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Creating static libraries for drivers moves some symbols out of IRAM.
This change fixes it.
Signed-off-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
Creating static libraries for drivers moves some symbols out of IRAM.
This change fixes it.
Signed-off-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
log and libc optimization default config are soc related
and should be moved out from board context.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
This migrates all the current iterable section usages to the external
API, dropping the "Z_" prefix:
Z_ITERABLE_SECTION_ROM
Z_ITERABLE_SECTION_ROM_GC_ALLOWED
Z_ITERABLE_SECTION_RAM
Z_ITERABLE_SECTION_RAM_GC_ALLOWED
Z_STRUCT_SECTION_ITERABLE
Z_STRUCT_SECTION_ITERABLE_ALTERNATE
Z_STRUCT_SECTION_FOREACH
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Max SPI chunk len was missing from the
implementation, causing SPI to hang up in some
conditions.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
bt_conn_cb section was added into common-rom.ld and
as current ESP has limited segment section number, it
needs to be moved out from there.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
XCC's linker cannot properly process our linker script with
regard to cached/uncached memory regions as the linker cannot
correctly calculate addresses using boolean operations.
Fix this by doing address pointer arithmetic manually to
move between cached and uncached memory regions.
The addresses of symbols were compared via nm and they are
the same before and after this change.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
XCC's own xt-objcopy does not recognize the "--dump-section"
command. So simply copy the objecy file into binary so it can
be included in the final bootloader binary.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This moves the inclusion of sys/util.h inside the #if block to
avoid this being included when going through XCC's assembler.
With the old behavior, a bunch of std*.h get pulled in resulted
in build failure as keywords such as "typedef" are not supposed
to be in assembly files according to XCC assembler.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
hal_espressif repository was updated from esp-idf v4.2
to esp-idf v4.3 to allow latest Espressif chips integration.
As a consequence, it added a few changes in drivers
and peripherals. To maintain bisectability, changes in this
PR cannot be split. Here are some details:
wifi: update linker script by adding libphy and new attributes.
spi: update some APIs and fixed missing wait_idle check
west.yml: esp32: update hal to new version
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
This fixes missing PPP iterable and adds all
common-rom.ld iterables.
ESP32 and esptool does not support more then 16 segments, which
blocks including common iterables section as is.
This partially reverts commit ad0bf94f77
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Align cavs25 with cavs15/18 and add memory segment for uncached mapping
of the SRAM to linker script. Assign sections to uncached and cached
segments as done in cavs15/18.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
When we link in crtbegin.o for C++ exception support we end up pulling
in the .tm_clone_table section. We need to update the linker scripts
to handle this. soc/xtensa/sample_controller/linker.ld was already
updated, this fixes the others.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Fixes part of: #32448
This commit updates the CMake CMAKE_CXX_LINK_EXECUTABLE to include
crtbegin.o and crtend.o at the right locations when linking with gcc.
It also updates linker scripts to ensure proper location of the
exception header frame sections.
This ensure proper handling of exceptions for those architectures
- x86
- xtensa
- riscv32
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Z_ITERABLE_SECTION_ROM symbols were empty, meaning
that those symbols were not taking place in the linker script.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Add the missing .cached section on cAVS 2.0 and 2.5 to fix
compiler warnings.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
PLATFORM_RESET_MHE_AT_BOOT and
PLATFORM_DISABLE_L2CACHE_AT_BOOT have to be defined on cAVS 1.8
too, without them secondary cores cannot be used.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
uncache_to_cache(), cache_to_uncache() and is_uncached() macros
are currently unused in Zephyr, besides the former two are
dangerous because they add and subtract an offset instead of
masking and unmasking a bit, which can lead to wrong addresses
if applied repeatedly. Remove these macros for now, we can
re-add them later if needed in their fixed versions.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Currently only cAVS 1.5 Kconfig selects ARCH_HAS_COHERENCE,
which is wrong. cAVS 1.8, 2.0 and 2.5 have to select it too.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
