Add a generic host command handler framework that allows users to
declare new host command handlers with the HOST_COMMAND_HANDLER macro
at build time. The framework will handle incoming messages from the
host command peripheral device and forwards the incoming data to the
appropriate host command handler, which is looked up by id.
The framework will also send the response from the handler back to the
host command peripheral device. The device handles sending the data on
the physical bus.
This type of host command communication is typically done on an embedded
controller for a notebook or computer. The host would be the main
application processor (aka AP, CPU, SoC).
Signed-off-by: Jett Rink <jettrink@google.com>
The host command peripheral device API abstracts how an embedded
controller sends and receives data from a host on a bus. Each bus like
eSPI, SPI, or I2C would implement their own host command peripheral
device. Each hardware device would then handle the necessary hardware
access to send and receive data over that bus.
The chosen host command peripheral device will be used by the host
command handler framework to send and receive host data correctly.
Signed-off-by: Jett Rink <jettrink@google.com>
@ulfalizer hasn't been active for several months, remove him and add
@mbolivar-nordic. We can add @ulfalizer back if he comes back to the
project.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
At present this test uses an EEPROM emulator. Reuse the same test to
also use the real Atmel AT2x driver and an AT24 emulator, via the I2C
emulation controller.
EEPROM reads and writes for eeprom1 go through the AT2x driver, which
converts them to I2C transactions, which are passed through to the
AT24 emulator for processing. This approach makes more use of 'real'
code, in this case the Atmel AT2x driver.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an emulation controller which routes I2C traffic to attached
emulators depending on the I2C address selected. This allows drivers
for I2C peripherals to be tested on systems that don't have that
peripheral attached, with the emulator handling the I2C traffic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Create a header file and implementation for emulators. Set up a linker
list so that emulators can be found and initialised at start-up.
Emulators are used to emulate hardware devices, to support testing of
various subsystems. For example, it is possible to write an emulator
for an I2C compass such that it appears on the I2C bus and can be used
just like a real hardware device.
Emulators often implement special features for testing. For example a
compass may support returning bogus data if the I2C bus speed is too
high, or may return invalid measurements if calibration has not yet
been completed. This allows for testing that high-level code can
handle these situations correctly. Test coverage can therefore
approach 100% if all failure conditions are emulated.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Signed-off-by: Simon Glass <sjg@chromium.org>
The FaZe board can be found in the Seagate FireCuda Gaming SSD devices.
A NVMe SSD and two chips are embedded: an ASMedia ASM2364 USB-to-PCIe
bridge controller and a NXP LPC11U67 MCU. The former is handling the USB
type-C to SSD I/Os while the latter is dedicated to the LED effects. The
two chips are connected together through I2C and GPIOs.
This Zephyr port is running on the LPC11U67 MCU.
Here is a list of the devices connected to the LPC11U67 on a FaZe board:
- ASMedia ASM2364 USB-to-PCIe bridge (I2C master on port O)
- 6 RGB LEDs connected connected to a TI LP5030 LED controller
(I2C device on port 1)
- 1 white LED (SSD activity blinking)
Signed-off-by: Maxime Bittan <maxime.bittan@seagate.com>
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
This adds a very primitive coredump mechanism under subsys/debug
where during fatal error, register and memory content can be
dumped to coredump backend. One such backend utilizing log
module for output is included. Once the coredump log is converted
to a binary file, it can be used with the ELF output file as
inputs to an overly simplified implementation of a GDB server.
This GDB server can be attached via the target remote command of
GDB and will be serving register and memory content. This allows
using GDB to examine stack and memory where the fatal error
occurred.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Sort entries alphabetically and cleanup top level menu for each
subsystem. Move stats subsystem Kconfig from debug into its own Kconfig.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add pin controller support for Nuvoton NPCX series
Add pin-mux controller support for Nuvoton NPCX series.
This CL includes:
1. Add pin controller device tree declarations and introduce alt-cells
to select pads' functionality.
2. Add npcx7-alts-map.dtsi since the mapping between IO and controller
is irregular and vary in each chip series.
3. Add nuvoton,npcx-pinctrl-def.yaml and its declarations to change all
pads' functionality to GPIO by default.
4. Pinmux controller driver implementation.
Signed-off-by: Mulin Chao <MLChao@nuvoton.com>
Add clock controller support for Nuvoton NPCX series. This CL includes:
1. Add clock controller device tree declarations.
2. Introduce clock-cells in yaml file clock tree to get module's source
clock and turn off/on the its clock
3. Clock controller driver implementation.
Signed-off-by: Mulin Chao <MLChao@nuvoton.com>
Initial support for Nuvoton NPCX7M6FB SoC of NPCX series which is a chip
family of embedded controllers (EC) and targeted for a wide range of
portable applications. We implemented the SoC skeleton in
soc/arm/nuvoton_npcx since there're many chip families in Nuvoton and
aim to different markets such as PC, General MCU, and Audio. The
architectures and hardware modules are different between them. Hence, we
suggest using the company name plus with chip series for better
understanding.
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Add myself (@cbsiddharth) as code owner for subsys/mgmt/osdp/,
samples/sybsys/mgmt/osdp/ and includes/mgmt/osdp.h.
Signed-off-by: Siddharth Chandrasekaran <siddharth@embedjournal.com>
Zephyr introduced subsys/mgmt folder for MCU management. Move UpdateHub
sample to its correspondent folder at sample/subsys/mgmt folder.
Signed-off-by: Gerson Fernando Budke <gerson.budke@ossystems.com.br>
Zephyr introduced subsys/mgmt folder for MCU management. Move UpdateHub
to this newly and dedicated space.
Signed-off-by: Gerson Fernando Budke <gerson.budke@ossystems.com.br>
In order to be able to add more entries under 'subsys/mgmt', move the
current contents of it, which relate exclusively to MCUMgr, to its own
folder.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This patch adds a pinmux driver allowing to configure the IOCON (I/O
control) registers found on the LPC11U6x MCUs.
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
Add @abrodkin to the list of CODEOWNERS for ARC code (ARCH,
BOARDS, DTS) instead of @vonhust.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Add an entry in CODEOWNERS for auto-assigning reviewers
in MAINTAINERS.yml and get_maintainer.py files.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Add PL330 dma driver support, this driver
- supports 32 bit memory to memory operation
- supports 36 bit memory to memory operation
under a config flag DMA_64BIT
- supports secure channel
Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
The esp_8266 shield was added without owner on #24710. Add myself as
an owner of esp_8266 shield files.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
The Atmel RF2xx module shield is a generic solution to enable any Atmel
AT86RF2xx IEEE 802.15.4 transceiver. This module enables IEEE 802.15.4
RF2xx Zephyr driver.
The Atmel RF2xx module shield enables any board with an Atmel Xplained,
Xplained-Pro, Arduino or MikroBus expansion header to connect to
networks operation with IEEE 802.15.4, OpenThread or any other stack
based on this media type.
The Atmel RF2xx module is configured to allow interoperate with other
medias like Ethernet. User need configure network stack properlly.
Fixes#26259.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Add Nuvoton numicro series UART support, currently supports
only poll mode.
UART0 clock and pincontrol are directly configured, will be
replace when clock and gpio support is added.
Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>
Add initial support for nuvoton numicro m48x SoC series, basic
init and uart functionality are covered with gpio and clock
directly relies on HAL.
Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>
This runs the Timer/Counter for Control in 'normal' PWM mode. The
number of channels and counter width depends on the device and is
imported from DeviceTree.
Signed-off-by: Michael Hope <mlhx@google.com>
- Support PLL for Higher Frequencies 80,160,240 MHz
- Support XTAL Frequencies 26MHz, 40MHz
- Clock Driver can't be disabled, because all of the other drivers
will depend on it to get their operating Frequency based on chosen
clock source (XTAL/PLL).
- Add needed references to BBPLL i2c bus ROM functions.
- Add `rtc` node to Device Tree.
- Since All Peripherals Frequency is depending on CPU_CLK Source,
`clock-source` property added to CPU node
Signed-off-by: Mohamed ElShahawi <ExtremeGTX@hotmail.com>
Add setup to utilize buildkite for CI purposes:
1. .buildkite/hooks/pre-command:
* Handles getting git checkout setup against upstream repo
* Setup some west module cache (dirs, clean out files & locks)
* init dir for ccache
2. .buildkite/hooks/post-command:
* Report disk usage (meant for possible debugging)
3. .buildkite/pipeline.yml [uses to determine what to do]:
* setup zephyr env vars
* set which docker container to use
(export some local disk caches for git, west modules, and ccache)
* uses plug to general build annotation on failure (junit-annotate)
4. .buildkite/run.sh [ buildkite wrapper to invoke scripts/ci/run.sh ]
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
