GitLab

Without this change, the flash shell is nearly useless as all three devices are
identified as "flash@0".  In practice, this means only flash2 can be accessed.

This change causes a warning to be emitted during DT compilation:
Warning (spi_bus_reg): /soc/spi@c3004200/flash@2: SPI bus unit address format error, expected "0"

Remove this commit after the Kestrel HDL is updated and verified

With CONFIG_NET_CONTEXT_NET_PKT_POOL enabled, it is possible to trigger a mutex
race condition and deadlock between net_context_get() and net_context_put() by
rapidly requesting pages pages from the built-in HTTP Web server.  It is
believed that every request has an extremely low, but non-zero, chance of
causing the deadlock, and that issuing many requests in rapid succession simply
raises the probability of seeing a system deadlock within hours or days vs.
months or years.

Explanation:

In thread A, net_context_get() locks the 'contexts_lock' semaphore, eventually
reaching k_mutex_init() on a specific context within the context array
'contexts'.

In thread B, net_context_put() does not use the 'contexts_lock' semaphore,
instead relying purely on the mutex lock()/unlock() functions for the active
context.

Thread A assumes that since it holds the semapore that it can reallocate and
reinitialize any context structure within the context pool, including its mutex.
If thread B has cleared NET_CONTEXT_IN_USE but is preemptively switched for
thread A before completing mutex unlock, thread A may proceed by calling
k_mutex_init() on the still-used mutex required by thread B.

Once the mutex has been reinitialized underneath the swapped out
k_mutex_unlock() function, there is now a non-zero chance that the mutex data
structures are in an invalid state (owner == NULL, lock_count > 0) due to
k_mutex_unlock() writing stale data back to the mutex as soon as thread B is
swapped back in.  If this occurs, the system will eventually deadlock due to
the context mutex not being able to be either locked or unlocked by any
functions within the network stack; all attempts to lock the mutex will
inevitably hang.

Resolution:

Add the missing semaphore calls around the net_context_put() critical section.

While the OpenPOWER compliant CPU used in Kestrel systems is capable of byte
mode access to memory mapped peripherals, the LiteX watchdog logic has no
concept of byte mode access to word length registers.  As a result, in 32-bit
CSR mode, a read-modify-write cycle is needed to avoid inadvertently clearing
the upper bits of the watchdog configuration register.

The Modbus protocol object types are either single-bit or 16-bit word.
Other types are not defined in the specification. Types such as float
are typically mapped to two 16-bit registers. Current implementaiton
does not maps correctly to the 16-bit word addresses. On the client
side, the implementation must take into account that the number of
requested registers (Quantity of Registers) is double that of a "float"
register.  The server side should not treat "Quantity of Registers" and
"Byte count" differently for addresses reserved for floating values,
only in the user callback the two 16-bit registers are mapped to a float
value but still aligned to 16-bit register addresses.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>

The XICS interrupt source count is defined in the XICS interrupt controller
Kconfig file, and does not need to be redefined at the SoC level

The code in shell_ops.c that calls telnet_write will assert if it
returns non-zero. For a telnet shell it's normal that the
network might disconnect unexepectedly, so that should not
trigger an assert.

Fixes #67637

Link: https://github.com/zephyrproject-rtos/zephyr/issues/67637

Signed-off-by: Kevin ORourke <kevin.orourke@ferroamp.se>

add phy for litex liteeth ethernet.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

add a mdio driver for litex liteeth.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

Rename it from litex,eth to litex,liteeth
to reflect the new name of the driver.

Zero got removed from the litex
ethernet compatible, as it now supports
multiple instances.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

be able to use multiple instances of the
litex ethernet (liteeth) driver.

add support for vlan.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

For more consistency, rename the liteeth driver to litex.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

the dts binding of the ethernet-phy has the option
"no-reset" and the according driver already has the
right logic to make use of it, but unfortunately
the connection between them was missing.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

This fixes a subtle error causing a random off-by-one situation throughought
the Zephyr codebase.  If XER is not saved, the following sequence is possible,
though unlikely:

subf r30, r31, r30	carry=0
sradi r30, r30, 3	carry=0
<INTERRUPT / CONTEXT SWITCH>
addze r30, r30		carry=<random>

This pattern is used heavily inside the heap allocator, and if carry is flipped
an off by one error will occur in the chunk addressing, leading to heap
corruption and an application crash.

During the TX-->RX switch on a RS485 bus, noise may be induced into
the RX line of the UART, causing reception of phantom characters.

Flush the UART RX buffer immediately after switching bus direction
to avoid processing this line noise as valid data.

Under adverse conditions, for example with long line lengths and long response
delays from the MODBUS slave, line noise can prematurely start the response
reception process.  This line noise is almost always 0xff or 0x00, and will
cause the transaction to time out.

The MODBUS specification states the first byte of the response (slave ID)
can never be less than 1 or greater than 247, likely to combat this problem.
Ensure that this condition is met before firing the response RX task.