Add a new example utility that maps a physical MMIO address range using
/dev/mem and mmap, reads 32-bit register values, and dumps a
user-specified number of bytes in hexadecimal format.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
Replace devm_ioremap_wc() with memremap(MEMREMAP_WB) for no-map
reserved-memory regions that have struct page backing.
Using ioremap_wc() on a region backed by struct pages violates
ARM64 memory aliasing rules by creating conflicting cached and
write-combining mappings of the same physical pages. This can
cause SIGBUS faults in unrelated userspace processes.
Add a devm cleanup action to call memunmap() on the mapped
region when the device is released.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
Add missing no-map property to ramoops region to prevent Linux
from managing it as regular memory.
Reserve gap regions adjacent to ioremap_wc-mapped M4 memory to
avoid ARM64 cache aliasing issues caused by Linux allocating
pages next to these regions.
Also reserve a gap between r5f-dma-memory and TF-A region to
prevent potential memory conflicts.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
This commit adds sysfs support for ksz9477 register acccess in
userspace. Although access is possible through the use of regmap it
showed to be uncomfortable to work with whole register dumps and also
or security reasons write access is prohibited by deault.
Do a 16-bit read access:
echo 16 0x040C > ksz_read
A 32-bit wirte access:
echo 32 0x0120 0x0115 > ksz_write
Results will be logged in the kernel buffer.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
Two mailbox messages are added to facilitate handshake between the
remote processors to ensure graceful stop of the remote processors.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The remote core has to be able to query the DM for the next system mode
in the suspend path. To support this, ti_sci.c has to send the
prepare_sleep command before the suspend message is sent to the remote
core. This patch moves the suspend to suspend_late to be executed after
ti_sci's suspend call.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Introduce suspend/resume handling to m4 remoteproc driver. The driver
registers for pm notifications. And on SUSPEND_PREPARE event a i
RP_MBOX_SUSPEND_SYSTEM mailbox message is sent to the remote core.
a) If the remote core does n't respond to the SUSPEND message, the
driver sets a device on constraint and returns.
b) If the remote core responds with 'RP_MBOX_SUSPEND_ACK', the driver
initiates a stop of the remote core and returns from the suspend
handler.
c) On the other hand, if the remote core responds with
RP_MBOX_SUSPEND_AUTO or RP_MBOX_SUSPEND_CANCEL, the driver simply
returns.
On the Resume path, driver queries DM to determine the state of the
remote core and if it is Off, turns on the remote core.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Upon a stop request, K3-M4 remote proc driver sends a RP_MBOX_SHUTDOWN
mailbox message to the remote R5 core.
The remote core is expected to:
- relinquish all the resources acquired through Device Manager (DM)
- disable its interrupts
- send back a mailbox acknowledgment RP_MBOX_SHUDOWN_ACK
- enter WFI state.
Meanwhile, the K3-M4 remote proc driver does:
- wait for the RP_MBOX_SHUTDOWN_ACK from the remote core
- wait for the remote proc to enter WFI state
- reset the remote core through device manager
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
This driver is actually an external kernel module that was imported
into the kernel tree.
You can find the original driver of Boban Loïc at
https://github.com/2pecshy/eeprom-ST25DV-linux-driver.git
Changes done by Fa. WAGO:
- refactor the probe and detect functions to align with
modern Linux kernel best practices:
- Switch to Managed Resources: Replaced standard kmalloc/kzalloc with
devm_kmalloc/devm_kzalloc for all data structures and buffers.
This simplifies the probe function and eliminates the need for
most memory-related goto labels and manual kfree calls.
- Automatic Device Management: Integrated devm_add_action_or_reset
to handle the automatic unregistering of the dummy I2C client,
ensuring safer resource release during error paths and removal.
- Modernized Logging: Replaced generic pr_warn/pr_info calls with
device-specific dev_err, dev_info, and dev_dbg for better
traceability in systems with multiple I2C devices.
- Improved String Handling: Replaced the deprecated strlcpy with
the safer strscpy in the detection phase.
- Enhanced Status Reporting: Added detailed dev_info upon successful
probe, including the specific chip model name and detected memory
capacity.
- Coding Style Fixes: Standardized indentation, removed unnecessary
braces for single-statement blocks, and structured area-specific
initializations to improve readability and maintainability.
The driver was tested and seems to be working fine.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
Enable CONFIG_BLK_DEV_INITRD to allow booting an external initramfs
passed by the bootloader via the Android boot image format.
Without this option the kernel ignores any ramdisk provided through
ATAGs or the devicetree linux,initrd-start/end properties and hangs
indefinitely at:
Waiting for root device /dev/ram0...
Signed-off-by: Sergej Wiebe <sergej.wiebe@wago.com>
The LED on the PFC400 interaction board was incorrectly named 'eb'.
Rename all occurrences (node names, labels, and multicolor group) to the
correct name 'em'.
Signed-off-by: Andrej Unrau <andrej.unrau@wago.com>
The init_workqueue_head() call during usage leads to hanging ioctl()
calls in userspace. There is no need to re-init the workqueue, so remove
it.
Signed-off-by: Tobias Biehl <tobias.biehl@wago.com>
This patch enables high-speed Octal-STR (8s-8s-8s) operation at 200MHz
for the Everspin EM008LX MRAM series.
To maintain reliable boot-up, the device is identified at a safe
frequency. Upon successful JEDEC ID verification, the driver escalates
the clock frequency to 200MHz and synchronizes the dummy cycles.
Key Improvements:
- Added frequency escalation in params->setup() hook to 200MHz.
- Implemented Octal register access (0x85/0x81) for configuration.
- Synchronized dummy cycles to 20, as required for 200MHz operation.
- Validated with Cadence OSPI controller using a 400MHz reference clock
and a read-capture delay of 3-5 cycles.
The resulting configuration achieves the maximum specified throughput
of the Everspin MRAM while maintaining data integrity.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
Everspin Octal-STR MRAMs (like EM008LXO) stay in Octal mode after a
warm reboot if the hardware reset pin is not toggled (e.g., when
connected to nPORZ-MCU). This causes the subsequent JEDEC ID read
to fail, as the controller restarts in Single-SPI mode while the
device still expects Octal-STR commands.
This patch introduces spi_nor_everspin_reboot_fix(), which is called
within spi_nor_hw_reset() as a fallback if no dedicated reset GPIO
is defined in the Device Tree.
The fix sends a "blind" Software Reset sequence (0x66 -> 0x99) using
8-8-8 protocol. If the device is in Octal-STR mode, it will recover to
Single-SPI. If it is already in Single-SPI mode, the 8-lane command is
ignored by the device, making this a safe recovery path for warm
reboots.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
Refactor the Everspin MRAM initialization sequence to support transition
into Octal STR (8s-0-8s) mode.
The following changes are implemented:
- Add everspin_mram_software_reset() to ensure the device is in a known
state (Single-SPI) before configuration.
- Update register addresses and opcodes to align with the datasheet and
legacy driver requirements (e.g., using 0x81 for WRAR).
- Refactor everspin_mram_write_reg() to use SNOR_PROTO_1_1_1 for initial
configuration and ensure Write Enable (WREN) is issued.
- Implement Octal STR mode activation by configuring CFR1V (Dummy Cycles)
and CFR0V (Mode).
- Add verification steps by reading the Status Register and ID in
SNOR_PROTO_8_8_8 mode with appropriate dummy cycles.
This ensures the MRAM is correctly detected and switched to high-speed
octal operation during the probe phase.
Signed-off-by: Heinrich Toews <ht@twx-software.de>
Move the reset GPIO pin for the KSZ9477 Ethernet switch from main_gpio1
pin 10 to mcu_gpio0 pin 11 to match the actual hardware configuration.
This change:
- Removes the reset pin definition from main_pmx0 pinctrl group
- Adds a new mcu_pmx0 pinctrl group for the MCU GPIO configuration
- Updates the ksz9477 device node to reference both pinctrl groups
- Changes reset-gpios from main_gpio1 10 to mcu_gpio0 11
Signed-off-by: Oleg Karfich <oleg.karfich@wago.com>
Heinrich Toews