Re: [PATCH rtems-libbsd] rtemsbsd/libio: Handle invalid descriptors
OK
Thanks
Chris
On 20/9/2023 7:18 am, Kinsey Moore wrote:
> The documentation for this function suggests that it can handle invalid
> descriptors safely. This change allows negative descriptors to be
> handled without a crash.
> ---
> rtemsbsd/include/machine/rtems-bsd-libio.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/rtemsbsd/include/machine/rtems-bsd-libio.h
> b/rtemsbsd/include/machine/rtems-bsd-libio.h
> index e662a9ec..8cc67ae3 100644
> --- a/rtemsbsd/include/machine/rtems-bsd-libio.h
> +++ b/rtemsbsd/include/machine/rtems-bsd-libio.h
> @@ -228,7 +228,7 @@ rtems_bsd_libio_iop_hold(int fd, rtems_libio_t **iopp)
> rtems_libio_t *iop = NULL;
> unsigned int flags = 0;
> int ffd = -1;
> - if (fd < rtems_libio_number_iops) {
> + if (fd >= 0 && fd < rtems_libio_number_iops) {
> iop = rtems_libio_iop(fd);
> flags = rtems_libio_iop_hold(iop);
> if ((flags & LIBIO_FLAGS_OPEN) != 0) {
> @@ -249,7 +249,9 @@ rtems_bsd_libio_iop_hold(int fd, rtems_libio_t **iopp)
> if (RTEMS_BSD_DESCRIP_TRACE)
> flags = iop->flags;
> } else {
> - *iopp = NULL;
> + if (iopp != NULL) {
> + *iopp = NULL;
> + }
> }
> if (RTEMS_BSD_DESCRIP_TRACE)
> printf("bsd: iop: hold: fd=%d ffd=%d refs=%d iop=%p by %p\n",
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 0/1] Branch note
Note that this patch only applies to the 6-freebsd-12 branch because the code it affects does not exist in the master branch. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd] rtemsbsd/libio: Handle invalid descriptors
The documentation for this function suggests that it can handle invalid
descriptors safely. This change allows negative descriptors to be
handled without a crash.
---
rtemsbsd/include/machine/rtems-bsd-libio.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/rtemsbsd/include/machine/rtems-bsd-libio.h
b/rtemsbsd/include/machine/rtems-bsd-libio.h
index e662a9ec..8cc67ae3 100644
--- a/rtemsbsd/include/machine/rtems-bsd-libio.h
+++ b/rtemsbsd/include/machine/rtems-bsd-libio.h
@@ -228,7 +228,7 @@ rtems_bsd_libio_iop_hold(int fd, rtems_libio_t **iopp)
rtems_libio_t *iop = NULL;
unsigned int flags = 0;
int ffd = -1;
- if (fd < rtems_libio_number_iops) {
+ if (fd >= 0 && fd < rtems_libio_number_iops) {
iop = rtems_libio_iop(fd);
flags = rtems_libio_iop_hold(iop);
if ((flags & LIBIO_FLAGS_OPEN) != 0) {
@@ -249,7 +249,9 @@ rtems_bsd_libio_iop_hold(int fd, rtems_libio_t **iopp)
if (RTEMS_BSD_DESCRIP_TRACE)
flags = iop->flags;
} else {
- *iopp = NULL;
+ if (iopp != NULL) {
+ *iopp = NULL;
+ }
}
if (RTEMS_BSD_DESCRIP_TRACE)
printf("bsd: iop: hold: fd=%d ffd=%d refs=%d iop=%p by %p\n",
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] bsps/xnandpsu: Ensure buffer cache sync
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.
---
bsps/shared/dev/nand/xnandpsu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/bsps/shared/dev/nand/xnandpsu.c b/bsps/shared/dev/nand/xnandpsu.c
index 9e9f8959cf..e140364ce8 100644
--- a/bsps/shared/dev/nand/xnandpsu.c
+++ b/bsps/shared/dev/nand/xnandpsu.c
@@ -1619,6 +1619,12 @@ s32 XNandPsu_Read(XNandPsu *InstancePtr, u64 Offset, u64
Length, u8 *DestBuf)
}
if (PartialBytes > 0U) {
(void)Xil_MemCpy(DestBufPtr, BufPtr + Col, NumBytes);
+#ifdef __rtems__
+ /* The destination buffer is touched by hardware,
synchronize */
+ if (InstancePtr->Config.IsCacheCoherent == 0) {
+ Xil_DCacheFlushRange((INTPTR)(void
*)DestBufPtr, NumBytes);
+ }
+#endif
}
DestBufPtr += NumBytes;
OffsetVar += NumBytes;
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] bsps/xnandpsu: Don't rely on usleep for polling
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.
---
bsps/shared/dev/nand/xnandpsu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/bsps/shared/dev/nand/xnandpsu.c b/bsps/shared/dev/nand/xnandpsu.c
index 85e6ba8532..9e9f8959cf 100644
--- a/bsps/shared/dev/nand/xnandpsu.c
+++ b/bsps/shared/dev/nand/xnandpsu.c
@@ -814,6 +814,21 @@ void XNandPsu_DisableEccMode(XNandPsu *InstancePtr)
InstancePtr->EccMode = XNANDPSU_NONE;
}
+#ifdef __rtems__
+#include
+static void udelay( void )
+{
+ uint64_t time = rtems_clock_get_uptime_nanoseconds() + 1000;
+ while (1) {
+ uint64_t newtime = rtems_clock_get_uptime_nanoseconds();
+ if (newtime > time) {
+ break;
+ }
+ }
+}
+#define usleep(x) udelay()
+#endif
+
/*/
/**
*
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/3] cpukit/jffs2: Avoid delayed work lock inversion
On Mon, Sep 11, 2023 at 11:00 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Kinsey, > > since this patch fixes a bug, there should be a ticket. There should be > also a test case which demonstrates the problem and shows that the patch > fixes the issue. > > I'll open an issue and see what I can do about creating a test case for JFFS2 that reproduces this issue. > > > How do you ensure that nobody calls jffs2_queue_delayed_work() with a > node present on this temporary chain? > This is handled by the off_chain checks along with the locking. If the node is already in a chain, then delayed work is already pending and will be handled upon expiration so additional attempts to queue the node can be ignored. See below for off_chain issues. > > The existing code seems to have more issues. Firstly, it uses the > protected chain methods. I'll swap the protected calls to unprotected for those surrounded by locking. > Secondly, is uses > rtems_chain_is_node_off_chain() with nobody setting a node off chain > after use. > I was developing under RTEMS_DEBUG which does set the node off chain upon extraction. I'll get this fixed for the non-RTEMS_DEBUG case. Thanks for taking a look at this. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Xilinx MPSoC, CAN, CAN-FD
On Tue, Sep 19, 2023 at 7:25 AM emanuel stiebler wrote: > Anybody using CAN on the xilinx MPSoC? Does CON-FD work too? > Hi Emanuel, Those drivers haven't been ported in from the embeddedsw repository yet since I haven't had a need for them. If you want to try porting them into RTEMS, the framework for them is already in place and used by the QSPI and static memory controller (NAND) drivers so it shouldn't be all that complicated. If you decide you want to attempt this, please also be aware of the recent HAL discussion on this list. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Xilinx MPSoC, CAN, CAN-FD
Anybody using CAN on the xilinx MPSoC? Does CON-FD work too? Thanks, Emanuel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
