Allows enabling the Clock Recovery System (CRS) for HSI48 to achieve
the expected accuracy for USB transfers. Uses USB SOF packet by default.
Signed-off-by: Tomáš Juřena <jurenatomas@gmail.com>
This commit adds sections to the virtio docs with the currently
supported transfer methods, drivers and samples
Signed-off-by: Jakub Michalski <jmichalski@antmicro.com>
This commit adds virtiofs sample that presents use of this filesystem
Signed-off-by: Jakub Michalski <jmichalski@antmicro.com>
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
This commit implements zephyr filesystem operations for virtiofs
Signed-off-by: Jakub Michalski <jmichalski@antmicro.com>
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
This commit adds virtiofs functions implementing fuse operations required
to enable zephyr filesystem support
Signed-off-by: Jakub Michalski <jmichalski@antmicro.com>
A simple sample showing how an interrupt (or thread) could produce data
a thread (potentially a user mode thread) could then consume.
Some great suggestions added thanks to Luis Ubieda
<luisf@croxel.com> to show multishot in use which avoids extra
syscalls in the tight processing loop of the consumer.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The Zperf sample application was chosen to demonstrate basic network
functionality and high-performance use cases. This application serves
as a reference for users who wish to enable other network sample
applications.
In addition to the essential configurations for the Intel i226 Ethernet
controller, stack-specific configurations were added to ensure stability
under heavy network loads. These configurations include adjustments to
buffer sizes, interrupt handling, and DMA descriptor management.
Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
Foxville LM (0x125B) i226 variant and Intel Alder Lake platform was
used for developing and stabilizing the i226 Ethernet device driver.
However, users can reuse the provided device tree models as a reference
when enabling the support for other i226 variants and platforms.
This device-tree model include essential configurations for the i226
Ethernet controller, such as PCIe settings, interrupt mappings, Phy
MDIO, and DMA descriptor configurations.
Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
The Intel i226 Ethernet Controller is a PCIe Gen 2 one-lane modular
endpoint device that integrates a GbE Media Access Control (MAC) and
Physical Layer (PHY) port. This driver provides support for MAC and
DMA-specific initialization and runtime TX/RX operations.
Key features:
- MSI-X interrupts for TX/RX DMA channels.
- Multiple TX/RX DMA channel support with exclusive bottom-half.
- Implements a circular descriptor ring architechture with
producer-consumer semantics for high performance pkt processing.
- Full duplex support for 10/100/1000 Mbps.
- Half duplex support for 10/100 Mbps.
- Auto-negotiation for 10/100/1000 Mbps.
- MTU customization for flexible packet sizes.
- MAC address filtering based on:
- Random MAC generation.
- Local-mac-address mentioned in device tree.
- EEPROM pre-programmed mac address.
- Setting mac address via net shell.
- Support for multiple Ethernet interface instances.
Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
Signed-off-by: Ling Pei Lee <pei.lee.ling@intel.com>
Intel i226 MAC supports MDIO C22 and MDIO C45. Standard PHY registers
are accessible through MDIO C22, whereas PMAPMD and PCS are accssible
through MDIO C45.
Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
The Ethernet device model consists of multiple subsystem components, such
as MDIO, PHY, MAC and PTP_CLOCK. These components are mapped into a single
PCIe BAR location with same base address.
This platform driver retrieves the MMIO mapping details and provides a
framework to share it with all the child subsystem components. This
approach avoid the duplicate remapping, ensures efficient re-use of
MMIO mappings across related devices.
Example device tree structure for first ethernet instance:
parent0: parent0 {
compatible = "intel,eth-plat";
interrupt-parent = <&intc>;
vendor-id = <0x8086>;
device-id = <0xXXXX>;
igc0: igc0 {
compatible = "intel,igc-mac";
/*
* MAC specific properties.
*/
status = "okay";
};
mdio0: mdio0 {
compatible = "intel,igc-mdio";
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
compatible = "ethernet-phy";
/*
* PHY specific properties.
*/
reg = <0x0>;
};
};
};
This framework is modular and re-usable for other PCIe based Ethernet
devices. It can also be extended to support additional platform specific
information shared across child nodes.
Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
This reverts commit fd88386a9f, it breaks
uart support on ITE platforms when PM is enabled but PM_RUNTIME is not,
possibly others as well.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This is a follow-up of commit 9a9ae6ffdb,
specifically for the nRF54LM20 DK, which was not included in the
previous commit.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Move handling of write-to-clear status and stop detect to the
beginning of the ISR for PIO mode to reduce unnecessary clock
stretching and improve responsiveness during transfers.
This patch also separates status clearing for shared FIFO mode,
ensuring it is done at the appropriate point after data handling
completes, maintaining correct transfer behavior.
Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
According to the datasheet the flash erase timing is
typically 2ms, and max 10ms.
H503: DS14053 Rev 4: section 5.3.10, table 45, t_erase_max=10ms
H562/H563: DS14258 Rev 6: section 5.3.11, table 51, t_erase_max=10ms
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
The ISO C function time() is not specified to set the global
errno variable, so remove that in case there are side-effects.
Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
- migration guide entry for renaming zephyr,gpio-stepper to
zephyr,h-bridge-stepper
- rename zephyr,gpio-stepper to zephyr,h-bridge-stepper in stepper.rst
Signed-off-by: Jilay Pandya <jilay.pandya@outlook.com>
To reduce the SEMC clock to a usable speed we had to divide down
the output clock of System PLL2 PFD1. To do this I had to override
the hardcoded defaults. This commit adds the flexibility to
override them in your board files.
Signed-off-by: Bas van Loon <bas@arch-embedded.com>
Errata ERR050396 causes data corruption if writes happen to TCM memory
so work around it by not marking AXI transaction cacheable. Workaround
taken from NXP SDK example.
Signed-off-by: Bas van Loon <bas@arch-embedded.com>
When preparing LLEXT ELF sections only invalidate instruction cache
of executable sections. Also skip the step on platforms, managing
cache at the application level.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
When a board contains two identical flash memories configured in
parallel dual-flash mode, the actual sector size is twice the sector
size of a single flash memory. So, assuming 4-KiB sectors for each flash
memory, any erase operation must be 8-KiB aligned.
This commit updates the start offset and sector size in the spi_flash
sample to be properly aligned when a dual-flash configuration is used.
At the moment, this is only supported for STM32-based boards and QSPI
flash memories.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
When dual-flash mode is enabled, any erase operation is executed on both
flash memories in parallel. This means from the flash driver's point of
view, the size of a given sector/block is twice the size of a
sector/block on a single flash memory.
For example, assuming 4-KiB sectors for each flash memory, if the flash
driver is asked to erase at address 0x0000, the erase size must be a
multiple of 8 KiB since each sector erase operation will cause a 4-KiB
sector to erased in each flash memory.
Before this commit, the doubled erase size was only considered in
'setup_pages_layout'. Now, the actual sizes of the erase operations are
properly set in the flash driver's data and are used everywhere in the
driver.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
When dual-flash mode is enabled, even bytes are written to the first
flash memory and odd bytes to the second flash memory. This means, from
the flash driver's point of view, the size of a flash page is twice the
size of a single flash memory's page.
So if each flash memory has 256-byte pages, 512 bytes should be used as
page size by the flash driver. Using 256 bytes was working fine but is
suboptimal.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
When dual-flash mode is enabled, two identical flash memories are
connected to the QUADSPI peripheral, each having its own set of
registers. This means that when reading or writing a flash register,
this has to be made for both flash memories.
For example, when reading a status register (1 byte), the QUADSPI
peripheral must be configured to read two bytes of data, which
correspond respectively to the value of the register in the first and
second flash memory. Same thing when writing.
Before this commit, when dual-flash mode was enabled, only the register
of the first flash memory was considered, which means the second flash
memory could be incorrectly configured and that any write/erase
operation could be considered as completed too early, if the operation
takes more time to complete for the second flash memory.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
The 'qspi_read_status_register' routine implements the reading of a
flash memory's status register. This routine is used anytime reading a
status register is needed, except in 'qspi_wait_until_ready'. This
commit moves the read routine to be able to use it in
'qspi_wait_until_ready'. The 'qspi_write_status_register' is also moved
to keep it close to the read routine.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
In multiple places, "#if DT_PROP(DT_NODELABEL(quadspi), dual_flash) &&
defined(QUADSPI_CR_DFM)" was used to guard sections specific to
the dual-flash feature. This is quite long and "#ifdef
STM32_QSPI_DOUBLE_FLASH" is now used instead.
Note the presence of QUADSPI_CR_DFM is no more checked. This is not
considered as an issue since when QUADSPI_CR_DFM is not available, the
QSPI hardware doesn't support dual-flash mode so this mode must not be
enabled in the devicetree. With that change, enabling dual-flash mode
when not available causes a compile-time error.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
Apparently the simple python HTTPS server the sample is interfacing,
cannot handle parallel TLS sessions (just one at a time), hence
establishing both IPv4/6 connections before sending request doesn't work
well, half of the requests are dropped. Therefore, modify the sample a
little to run only one TLS (or TCP if no TLS is used) connection at a
time.
Additionally, add a log in case HTTP client request fails, as it could
easily be overlooked if something went wrong.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Python HTTPS server counterpart for the sample now seems to enforce
ECDHE key exchange, so enable it in the sample.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
No more users of lxml in the tree so drop the 3rd party dependency (it
might still be pulled in by other projects, ex. gcovr).
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Remove an old workaround requiring lxml to be present as junitparser was
not working with xml.etree.ElementTree until version 3.0.0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Using the third party lxml library for the very simple parsing task this
script performs in unnecessary, so switch to Python's built-in
HTMLParser.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Add support for disabling autonegotiation to the cfg_link callback, as
with the phy_mii driver.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
The driver previously could enter an infinite loop if the PHY software
reset failed to complete, which could happen due to hardware reset
issues or MDIO bus problems. Add a timeout of 1000 iterations so we
report an error in this scenario rather than causing a lockup.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
For GPIOs driving active-low signals, such as the VSC8541's reset pin,
they are supposed to be declared as active low in the device tree, and
set to 1 to assert and 0 to clear. Change the driver as such so that it
does not leave the PHY stuck in reset when so configured.
Also changed all in-tree board DTS files for this PHY to properly
declare the reset GPIO as active low.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
The internal register read/write functions used uint32_t for the values
even though the registers are only 16 bits wide, resulting in a bunch of
casting. Change the internal functions to use uint16_t and wrap them for
the external read/write API which uses uint32_t.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
