With this, it is possible to use GPIOs as CS pins in the LPSPI. To avoid
additional complexity, the GPIOs will have the same limitations as the
native (hardware) CS pins.
The GPIO CS feature adds a number of extra code when starting SPI
transfers on this controller. Therefore it is possible to disable the
additional code by just setting the IMXRT_LPSPI_MAX_CS option to 0. In
that case only native CS pins are supported.
At the moment, this feature is only enabled on i.MXRT1166 by default
because it is not tested on i.MXRT1050. But it should work there too.
Device trees allow mixing different kinds of GPIOs in one property. For
that it is usefull to only provide a pointer to an arbitrary location in
the property and initialize a GPIO from that.
This imports the TTC hardware definitions for the triple timer counters
on various Xilinx platforms. This was imported as specified in the
VERSION file in this commit.
The xnandpsu driver conditionally tries to wrap page index to NAND chip
size causing an off-by-one error where the first page of the second chip
is not wrapped correctly. This removes the conditional so that page
index is always wrapped.
On configurations where multiple NAND chips are in use, the erasure
loop in XNandPsu_Erase() can reset the loop counter variable once it
gets to blocks in the second chip causing an infinite loop overwriting
parts of the first chip. This change ensures that the loop counter is
not accidentally reset.
Prefer use of XNandPsu_Erase instead of XNandPsu_EraseBlock since the
XNandPsu driver does not expose the primitives necessary to ensure
device readiness after the operation is complete.
This fixes some issues in the Xilinx support code that are critical to
support the Cortex-R5F cores present in my Xilinx SoCs. The imported
Cortex-R5 xil_cache.c matches the existing information in
bsps/shared/xil/VERSION.
Merge the timecounter and CPU counter support for the leon3 BSP family.
Remove now unused functions from the CPU counter support of the erc32
and leon3 BSPs.
Update #4954.
Share the timecounter instance between the clock and the CPU counter.
This greatly simplifies the clock driver since we have to do the device
selection only in one place, the CPU counter support.
Update #4954.
Using the auto reload counter which generates the clock ticks for the
timecounter or CPU counter is quite difficult and only works in
uniprocessor configurations.
Update #4954.
Force use of addresses that would be translated by TTBR1 to cause a
translation fault. RTEMS on AArch64 does not use TTBR1 and so attempted
translation of that address range could cause unexpected behavior in the
form of other exception types since TTBR1 is never set.
Ensure that a single locking session is carried over OOB writes
including the OOB read that is sometimes required. This removes the
possibility of another write occurring between the read and write that
would make the write incorrect.
When a buffer is modified by both hardware components such as DMA and by
software components, the buffer cache state must be kept in sync so that
data is not accidentally thrown away during future invalidations.
When polling hardware registers in high performance situations, don't
rely on usleep or other standard sleep functions since they will
necessarily rely on kernel ticks to be woken up. This can easily cause
an immense reduction in throughput.
The internal JFFS2 locking does not guarantee that delayed writes will
not step on other reads and writes to the device. This adds locking to
prevent that in the JFFS2 NAND interworking layer.
The changes here ensure correct cache maintenance around DMA operations.
One cache flush was missing and two cache invalidations occurred before
the corresponding read that would make them necessary.
Fixes the following Coverity warning:
** CID 1539495: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/bsps/shared/dev/rtc/mcp7940m.c: 317 in mcp7940m_set_time()
Basically coverity warns that (buf[...] & 0x7) can't be bigger than 7.
Just remove the unnecessary comparison.
The MCP7940M is a I2C RTC chip. The new driver uses the dev/i2c API to
support the RTC. It is written with the intention, that the driver can
be adapted to other RTCs with a similar register layout by just
replacing the initialization function.
Part of the new HAL requires float_t type definition. For that it includes
math.h header file which unfortunately brings a lot of math functions in.
One of them, 'log' conflicts with FreeBSD log function defined in systm.h
Provided hack is really just a crude work around this issue. Never thought
that Motorola 68881 would help me even in 21st century.
