I think my original idea with this default MPU setup was that the top
bits of the (fast) SRAM region might be useful for host DMA that
needed better latencies than the (extremely slow) system DRAM
mappings. So it should be left uncached for safety.
But unfortunately the author[1] of the SOF heap integration for this
platform decided to size the heap dynamically to use most of the SRAM
block (the vectors and a few other bits live at the bottom, but most
of .text is in DRAM).
Needless to say, an uncached heap is sort of a performance disaster.
It worked OK for default copy-only topologies but fell over the moment
we turned on nontrivial processing.
[1] Um... Hi. Yeah, that's me too.
Signed-off-by: Andy Ross <andyross@google.com>
Recent Python interpreters have started tossing bus errors from this
12-byte string search (the loader is looking for the winstream
descriptor in the live firmware image). My guess is that there's a
SIMD optimization that's been added that's trying to do e.g. a 16 byte
load, and something in the fabric is kicking that out. Note that this
is 100% a software change: the same hardware with one version of the
host environment works, and an update breaks it.
But really I have no idea what's happening here, the memory region in
question is documented as system DRAM, the same bus regular process
memory is on (it's just not kernel-utilized memory). All I know is
that the bus error is introduced with a Python upgrade from 3.8.20 to
3.11.10.
Regardless, it's no great hardship to do the search on 64 bit chunks.
Signed-off-by: Andy Ross <andyross@google.com>
`CONFIG_LEGACY_MULTI_LEVEL_TABLE_GENERATION` had been deprecated since
#66877 for 2 releases, interrupt controller drivers should have been
updated to use the new `IRQ_PARENT_ENTRY_DEFINE()` macro. Remove it.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
For the same reason that this script can't zero the SRAM region (it
spontaneously reboots my 8186 device) we can't scan the SRAM for the
winstream header. It's never there anyway, it lives in .rodata.
This is likely a hardware bug, but as it's an older platform and this
is test code it's probably best to just keep it as a workaround.
Signed-off-by: Andy Ross <andyross@google.com>
Enable a winstream console via the new "STATIC" platform API, and add
code to the loader script to read it (largely cribbed with
modifications from the same feature in cavstool.py, we have nowhere to
share code like this, alas).
The older logging feature is still present as an "oldlog" mode to the
script. We can leave it for a bit as a failsafe (e.g. for debugging
issues with winstream) and remove it later.
Signed-off-by: Andy Ross <andyross@google.com>
These devices have non-standard cache lines (128 bytes), and were
inheriting an incorrect setting for this kconfig.
Also clean up some related feature kconfigs which were being ignored
and not set =y.
Signed-off-by: Andy Ross <andyross@google.com>
This is a pre-existing (but rarely used) Zephyr linker tag. Support
it instead of reinventing something similar.
Signed-off-by: Andy Ross <andyross@google.com>
The Linux SOF driver owns this space, but puts buffers here which the
DSP is expected to read and write. Give it a space in the default MPU
mapping.
Note that this assumes that the DMA region is numerically above the
linkable DRAM region in the address space. That's true for existing
devices, but likely to be broken in the future.
Signed-off-by: Andy Ross <andyross@google.com>
The SOF source code is confusing. On some hardware these devices have
distinct IRQs assigned, and on others they seem to share an ISR for
all. Leave the existing assignments in place for SOF-compatibility,
but union all the devices into a single ISR path that will poll each
(there are only two). This will work in all configurations, and we
can figure out the proper architecture at leisure.
Signed-off-by: Andy Ross <andyross@google.com>
SOF needs this information for rimage to work, it contains data needed
by the kernel loader and not firmware per se. Note that contra other
SOF platforms, this leaves the data in the live firmware image so it
can be inspected at runtime. That's not needed by core SOF code, but
is handy for debugging. And these devices have a ton of DRAM space
available.
Signed-off-by: Andy Ross <andyross@google.com>
The MT8196 device has a newer interrupt controller that acts like the
legacy ones once initialized (see intc_mtk_adsp.c). But it has some
(only slightly) more complicated routing control that must be
initialized on reset, as the default is "don't deliver any interrupts
at all". Previous versions of the device integration worked becuase
they relied on a SOF binary to be loaded at boot, but obviously that
doesn't work for a Zephyr-based SOF firmware image.
Signed-off-by: Andy Ross <andyross@google.com>
This driver forgot to enable its interrupt, but has been working
becuase Zephyr apps were always run in a context where the interrupt
controller had been initialized by a SOF binary at boot.
Signed-off-by: Andy Ross <andyross@google.com>
This got missed. Set it correctly for hygiene, though very few things
use it. There is a spot in SOF where it's helpful to have a number for
"fasted cpu clock rate" and this is the best candidate.
Signed-off-by: Andy Ross <andyross@google.com>
I thought I was being clever letting the linker place the entry point
arbitrarily (since the hardware can set it to any value).
But it turns out that the upstream Linux SOF loader code is hard-wired
to start the DSP only at the first byte of SRAM, always, no matter
what entry point is listed in the rimage file. So until/unless this
is fixed, we need to add a trampoline at the start of SRAM (and
frustratingly that needs to be 1024 bytes long becuase of the
alignment requirements of the vector table that follows it, sigh...)
Signed-off-by: Andy Ross <andyross@google.com>
This is mostly a cut/paste copy of similar code in intel_adsp and imx,
which sadly can't be shared given the way the design works. Also
includes a bonus, slightly-passive-aggressive description of why that
is.
Signed-off-by: Andy Ross <andyross@google.com>
These devices have an architecturally fixed 13 MHz clock device. But
thankfully you can put a default into a DTS binding so we don't have
to repeat it for all of them.
Signed-off-by: Andy Ross <andyross@google.com>
Add Zephyr support for the Audio DSP on the MT8196 SOC. This is a
very similar device to previous designs. Most of this patch is just
DTS.
The biggest delta is the more complicated second level interrupt
controller, though it is still able to be represented using some
vaguely clever DTS config over the older intc_mtk_adsp driver.
Also the memory layout is slightly different, requiring a little
indirection to set the initial boot stack address and log output
buffer. And the timer "irq_ack" register bits moved.
Signed-off-by: Andy Ross <andyross@google.com>
New platform has different mappings. Auto-detect rather than parse
dts or similar, as this is is really just a simple format for testing.
Signed-off-by: Andy Ross <andyross@google.com>
The early boot function got renamed to a pseudo-standard "z_prep_c",
but this isn't an actual API and doesn't have a prototype in the
headers anywhere, so the compiler started whining about an undeclared
function.
Signed-off-by: Andy Ross <andyross@google.com>
These are very similar devices to mt8195, minimal changes needed
beyond boilerplate configuration.
In the process, this reworks the board/soc layout to be HWMv2
compliant, with "adsp" becoming a CPU cluster beneath the SOC. So the
name of the boards to west become e.g. "mt8195/mt8195/adsp" (which can
be shortened to "mt8195//adsp" if desired).
Note that the cpuclk driver is not yet ported, it works only with 8195
(the clocking/power architecture seems similar between the parts, but
the graph of wells and clocks is different and historically these have
been three separate drivers in SOF). The biggest changes are in the
image/loader scripts, which needed some rework for cross-device
portability.
Signed-off-by: Andy Ross <andyross@google.com>
