Give documentation build up to 30 minutes to finish. This should improve
the user experience when Sphinx hangs due to broken references, a
problem that needs some investigation.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Fill in received bytes in USBIP_RET_SUBMIT packet
Currently this field is unconditionally set to 0 and therefore not
filled in conveniently. This may mislead the USB host which is correctly
acknowledged that the transaction was sucessful but it cannot check the
actual received bytes.
Test application:
```python
import usb
data = (0xFF, 0xFF)
print("Opening loopback device")
device = usb.core.find(idVendor=0x2FE3, idProduct=0x0009)
print("Writing test data", data)
written = device.write(0x1, data)
print("Written", written, "bytes")
```
Before:
```
$ ./test_loopback.py
Opening loopback device
Writing test data (255, 255)
Written 0 bytes
```
After:
```
$ ./test_loopback.py
Opening loopback device
Writing test data (255, 255)
Written 2 bytes
```
Signed-off-by: Raúl Sánchez Siles <rsanchezs@k-lagan.com>
Use the `STRUCT_SECTION_ITERABLE` helper macro when declaring buffer
pools instead of manually doing the same thing.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update the macro prototype to explicitly require the length of the
desired user data. Update all in-tree usage of this macro.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update the macro prototype to explicitly require the length of the
desired user data. Update all in-tree usage of this macro.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update the macro prototype to explicitly require the length of the
desired user data. Update all in-tree usage of this macro.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Transition the `user_data` field in `struct net_buf` to be a flexible
array member instead of a hardcoded array. Compile-time asserts are
introduced at the location of the intermediate struct usage to ensure
that the assumptions utilised in runtime code hold true.
The primary assumptions are that the two `user_data` fields exist at the
same memory offset, and that the instantiated struct size can be
determined from the generic struct size and the length of the user data.
`net_buf_id` and `pool_get_uninit` must now use manual address
calculations as the `__bufs` type is no longer the actual size of the
instantiated variable.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Store the `user_data` array size on both the pool and net_buf structs.
This will enable length validation once `user_data` fields are not
globally the same size. The new variables fit inside existing padding,
and therefore do not increase the size of either structure.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Replace the statically defined net_buf with the standard mechanism of
allocating the buffer from a pool. This introduces a minor memory
overhead, but has the benefit of ensuring that standard net_buf calls
will work correctly.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Zephyr device that is not a GATT Client, should ignore indication.
An Android device may send an indication even if Zephyr
device does not support GATT Client role. In that case, the sent
error response was improperly matched to subsequent GATT request
of the Android device which caused issues.
Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
Use DT_INST_ENUM_IDX_OR and always default to full-speed
if CONFIG_USB_DC_HAS_HS_SUPPORT is not set or maximum-speed
property is not defined.
Remove low-speed setting since device stack does not support it.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
In the current USB device support, the sizes of bulk endpoint
are mostly configure through Kconfig and do not care if a device
is high-speed capable. The information if a USB device controller
supports high-speed comes from devicetree. Add a Kconfig option to
map this information and configure bulk endpoint sizes
accordingly.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Add function to check if a property of a node
is equal to a passed string.
The motivation is that in current USB device support
the sizes of bulk endpoints are configured in Kconfig.
The information if a USB device controller supports
high-speed comes from devicetree. This information must be
mapped in controller driver Kconfig and corresponding options
in USB device stack configured must be adjusted.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
uart_fifo_read() can return negative values in case
it is not implemented or CONFIG_UART_INTERRUPT_DRIVEN
is not enabled. Both cases can not actually happen in the
case of CDC ACM UART, check it anyway in case behavior
of the UART API changes unnoticed.
Align the code in RX path code of both camples and
enable TX interrupt only if data was received successfully.
Fixes: #39835Fixes: #39824Fixes: #39809
Coverity-CID: 240667
Coverity-CID: 240679
Coverity-CID: 240697
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Define a custom IEEE802154 based L2. The user can then use those symbols
to implement their own 802.15.4 based L2, based on those symbols, w/o a
need to modify the Zephyr tree.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Some 802.15.4 L2 implementations expect that FCS length is included in
the overall packet length while others not. Allow to configure this
behavior, based on the selected upper layer.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Introduce a common config for all 802.15.4 based L2 implementations.
This way, any custom 15.4 L2 implementation will be able to
automatically enable use 15.4 driver, w/o a need to modify the actual
Kconfig.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The IDC driver was written for Tiger Lake era devices, but works fine
on the earlier hardware too. Make it selectable; if you don't
configure IPM_CAVS_IDC, then you get the new driver.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was an attempt in the old code to express this as a formal
protocol with a proper field definitions, etc... But in fact no such
protocol really exists. This scheme is only used in one place to send
one specific message to code fixed in ROM on legacy devices that only
knows how to recognize this specific value. And 2.5 and later
hardware are moving away from it anyway.
Just express it directly, and explain in comments.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The CAVS_IDC_IPM driver happens to be used only on non-2.5 hardware,
but it's best to be clear in the conditional compilation when we're
talking about hardware-dependencies and when we mean software
configuration. This was mixed up in a few spots.
Also fix a warning that creeps in on non-default drivers choices about
an undeclared ipm function.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
While the linker scripts for these platforms had diverged in form, the
behavior remained compatible. Link all cAVS devices with the same
linker script included from the common directory (it's a verbatim copy
of the cavs_v25 script).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
While technically this file can change for any instantiation of Xtensa
hardware, in practice all these devices have identical interrupts
setups. These files were duplicates, so there's no value in keeping
them in per-sub-soc directories. (Really we should wire it up so that
the generator gets run automatically with the build, but that will
need to wait for a rework of interrupt entry).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
All the in-use contents of these files have now been moved to the
intel_adsp core, and they are configured via devicetree and kconfig.
Remove the legacy headers.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These two register blocks are defined in the platform layers, but
never change (except on 1.5 where they don't exist). I don't want to
write a full devicetree interface for them as I can't find good docs
currently. They are used only at system initialization, so move the
definitions to the single file where they're used. In the longer term
we will want to move at least the GPDMA setup into a driver anyway.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These registers were hardwired in the platform layer. Move to
devicetree, via a struct interface that looks like the pre-existing
shim layer.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These values (used to arrange the bootloader within IMR memory) are
mostly computed or fixed to values that don't chagne between
platforms. Only the manifest address and the location of the data
section change. Put those in kconfig, move the rest to the global
header.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The bootloader code on this SOC has its own cmake rules, which means
it doesn't get the Zephyr-specific magic from the toolchain layer and
the code needs to handle fixups manually. (Specifically: we have a
xcc_missing_defs.h header to provide gcc symbols that xcc doesn't
have, and assembly needs to be built with _ASMLANGUAGE so headers
don't include C syntax.)
Long term the right solution here is to build the bootloader as part
of the Zephyr binary.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The locations of the memory windows within the reserved SRAM region
was being construted via a bunch of magic numbers referencing
(potentially historical?) SOF usage of those areas. But Zephyr only
ever touches two of these windows, and only cares about the sizes and
offsets. The complexity was hurting and not helping (especially since
there was no attempt made to unify these values with the ones that are
actually live in the SOF tree).
Replace with kconfig variables that simply specify the offset. Only
one platform has a nonstandard layout anyway. That allows SOF to move
things around in a clean way if it wants. Ideally we should be
presenting a proper API for managing this region, though.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Same as for the HP-SRAM memory region. It's already exposed in
devicetree, so take the per-platform values out (including some dead
code on 2.5) and put them in a global header.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The platform layer (except cAVS 1.5, which computed it via alternate
means as an offset on other stuff) was specifying the entry point as
an explicit address needlessly. In fact the linker scripts already
are written to place the entry point at the first address of linkable
RAM, which is already available as the RAM_BASE symbol.
Unify.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These registers are identical on all platforms, the only difference
being that cAVS 1.5 places them at a different address.
Create a devicetree node to track the register block, and replace the
platform header code with a global API defined once (it works like the
pre-existing shim struct).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is a diverged definition for SRAM_REG_FW_END, which exists to
prevent the Zephyr window initialization from changing values that
were already set by the ROM or bootloader (though this is incomplete,
as we're not ensuring the memory is actually the same space except by
convention; we also don't have any Zephyr-side visibility as to the
content of this struct).
That was silly; the only thing worse than one magic number is four
magic numbers in different files. Write a formula that works for all
the platforms and put it in the C file where it's used.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was a divergent set of definitions for a "RAM" region for the
benefit of memory layout in the platform headers. In fact there was
only one platform dependence (cAVS 1.5 has 32k instead of 64k
reserved). Put that into kconfig in a single place, and add a warning
that this is a trap region with hidden dependencies in both Zephyr and
SOF. Good enough until we clean this up and make everything visible
to the linker.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There are multiple "fake" (not part of image) sections needless linked
to explicit addresses right now. This should be cleaned up, but in
the meantime let's at least put their definitions all in one place so
they aren't cut/pasted into every platform.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
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>
This feature is in tree and used by the SOF app, but we don't have a
local test for it. Add one, including a case to track regressions in
a known failure mode (where the second CPU wouldn't get its IDC
interrupts set up correctly if spawned at runtime).
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>
Anas Nashif
Gerard Marull-Paretas
Raúl Sánchez Siles
Jordan Yates
Marek Pieta
Johann Fischer
HaiLong Yang
HaiLong Yang
Robert Lubos
Andy Ross