- 20 Nov, 2024 39 commits
-
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
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"
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
Remove this commit after the Kestrel HDL is updated and verified
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Kevin ORourke authored
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>
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Fin Maaß authored
add phy for litex liteeth ethernet. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
-
Fin Maaß authored
add a mdio driver for litex liteeth. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
-
Fin Maaß authored
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>
-
Fin Maaß authored
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>
-
Fin Maaß authored
For more consistency, rename the liteeth driver to litex. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
-
Fin Maaß authored
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>
-
Raptor Engineering Development Team authored
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.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
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.
-
Raptor Engineering Development Team authored
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.
-
Raptor Engineering Development Team authored
The existing RX ready call did not conform to the Zephyr specifications, as it would not always return ready when the RX buffer contained data. Both the TX and RX ready calls did not conform as they would return ready / complete even if their associated intterupts were turned off. Implement missing TX complete call.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
An 8 bit data type was used to read and write the 32 bit interrupt status / control register in the LiteX IRQ handler, with predictable results. Use a 32 bit data type to read and write 32 bit control registers.
-
Raptor Engineering Development Team authored
CONFIG_ASSERT was incorrectly set at the board level from early bringup operations. Deselect this option to match other boards, and allow the application to determine if assertions are needed or not.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
This allows the network interface to be configured by the target application prior to being brought online.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
Without this fix, the encoder will crash, scribble on other process memory, randomly fail, and otherwise behave in a completely useless manner if JSON_TOK_FLOAT is used anywhere in the struct to be encoded.
-
Raptor Engineering Development Team authored
Zephyr relies on a single return code to signal the HTTP server regarding application state. As a result, a callback can only signal one of chunk data transmission, EOF, or error status, not a combination of the three. For GET requests, Zephyr correctly calls the callback again after receiving a chunk data transfer return code, and will continue to do so until it receives error or EOF. This logic was not implemented for POST requests, leading to the application not being able to clean up at the end of a data transmission sequence.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
Technically, due to PLL resolution, the frequency is actually 59.6153846154MHz. This difference will cause rapid clock drift, so use the more precise value in the critical timing control values.
-
- 19 Nov, 2024 1 commit
-
-
Raptor Engineering Development Team authored
-