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>
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>
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>
PR #37938 aligns many linker symbols name like rom/rodata_regions ...,
but ae350 soc linker script doesn't update for that. Migrate all linker
symbols name to PR #37938 changes.
Signed-off-by: Jim Shu <cwshu@andestech.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>
This initial support of L2C driver only contains cache enable and HW
capability checking. Cache management operation isn't supported yet
in this driver.
Signed-off-by: Jim Shu <cwshu@andestech.com>
Andes V5 PMA can let SW programmably configure memory attribute of
physical memory region. This commit enable CONFIG_NOCACHE_MEMORY of
Andes V5 CPUs based on the PMA. Use PMA region 0 to set whole nocache
section as uncached memory.
Signed-off-by: Jim Shu <cwshu@andestech.com>
Support custom RISC-V CSR context switch for Andes V5 CPUs.
Both AndeStar V5 DSP and PowerBrake features have it's own CSR to be
saved for thread and ISR context, so adding these CSRs into the RISC-V
SOC context management framework (CONFIG_RISCV_SOC_CONTEXT_SAVE).
Signed-off-by: Jim Shu <cwshu@andestech.com>
Add andes_v5 SoC series and andes_ae350 SoC. It includes
soc initialization code, linker script, and custom CSR encoding.
Signed-off-by: Jim Shu <cwshu@andestech.com>
This is the initial version of a Zephyr CMake linker file for the arm
architecture.
This file defines memory regions, groups, linker sections and symbols
for the arm architecture.
It also sources the common common-ram.cmake, common-rom.cmake,
debug-sections,cmake, and thread-local-storage.cmake.
It configure sections for SoC families using zephyr_linker_sources()
functions:
- nxp_imx
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
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>
Cleanup and preparation commit for linker script generator.
Zephyr linker scripts provides start and end symbols for each section,
and sometimes even size and LMA start symbols.
Generally, start and end symbols uses the following pattern, as:
Section name: foo
Section start symbol: __foo_start
Section end symbol: __foo_end
However, this pattern is not followed consistently.
To allow for linker script generation and ensure consistent naming of
symbols then the following pattern is introduced consistently to allow
for cleaner linker script generation.
Section name: foo
Section start symbol: __foo_start
Section end symbol: __foo_end
Section size symbol: __foo_size
Section LMA start symbol: __foo_load_start
This commit aligns the symbols for _data_ram/rom to other symbols and in
such a way they follow consistent pattern which allows for linker script
and scatter file generation.
The symbols are named according to the section name they describe.
Section name is `data`
A new group named data_region is introduced which instead spans all the
input and output sections that was previously covered by
__data_ram_start, __data_ram_end, and __data_rom_start.
The following symbols are aligned in this commit:
- __data_ram_start -> __data_region_start
- __data_ram_end -> __data_region_end
- __data_rom_start -> __data_region_load_start
The following new symbols are introduced so that the data section is
aligned with other sections:
- __data_end
- __data_start
value identical to __data_region_start but describes start of
the section.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
We add support of mpu v6 therefore it is needed to have a board to
validate that feature. This commit add a new HS nsim simulator
which supports mpu v6.
Signed-off-by: Yuguo Zou <yuguo.zou@synopsys.com>
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>
Define soc_interrupt_init as a weak symbol in the common RISC-V
privileged instruction set SoC support.
This allows overriding soc_interrupt_init for SoCs which are not fully
compliant with the RISC-V privileged specification.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Define __soc_handle_irq as a weak symbol in the common RISC-V privileged
instruction set SoC support.
This allows overriding __soc_handle_irq for SoCs which are not fully
compliant with the RISC-V privileged specification.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Follow up on commit bfd45e5b8c
("drivers: remove Kconfig option CONFIG_UART_CONSOLE_ON_DEV_NAME")
Remove Kconfig options
CONFIG_BT_UART_ON_DEV_NAME and CONFIG_BT_MONITOR_ON_DEV_NAME
since all UART drivers are converted to devicetree and we can just use
DEVICE_DT_GET(DT_CHOSEN(zephyr_bt_uart)) and
DEVICE_DT_GET(DT_CHOSEN(zephyr_bt_mon_uart)).
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Microchip MEC172x series I2C driver implementing controller
and target modes. The driver implemenents its own I2C port
pin control functions and does not depended upon pinmux. Future
updates will make use of PINCTRL when that subystem is finalized.
Signed-off-by: Scott Worley <scott.worley@microchip.com>
Add Kconfig options that allow users to select the way the APPROTECT
mechanism is handled in the SystemInit() function.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
