Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 19:10, Peter Dufault wrote: On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER wrote: On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- Thanks for taking this on. Instead of a strict priority for the goals, we might consider a limited set of different priorities that require judgment to make good trade-offs. In this case, I would suggest the following as somewhat equivalent goals, and the sets in priority order: 1. Real-time Impacts + Maintainability Loss 2. Transparency Loss + Modularity Loss + Code/RAM Size Increase 3. Performance Loss I wrote each goal now as a "minimize" objective. I think it is not possible to establish strict priorities on these objectives. Good engineering requires understanding and making good tradeoffs. I believe that #1 addresses the highest requirements we place on RTEMS and the libbsd philosophy. #2 leaves us with the burden of discussing and debating when tradeoffs are made. It may be better in some cases to increase code size by increasing modularity, but in other cases it may be better to reduce transparency to reduce code size. Gedare I'm presenting my concerns without doing appropriate research. This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible). Yes, I want my cake, and eat it too. "It would be great" if it is clear what small memory platforms lose when going with "LWIP" vs "libbsd", and how easy to switch between the stacks given a supported driver
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-26 10:26, Christian MAUDERER wrote: On 2023-01-25 19:10, Peter Dufault wrote: On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER wrote: On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- Thanks for taking this on. Instead of a strict priority for the goals, we might consider a limited set of different priorities that require judgment to make good trade-offs. In this case, I would suggest the following as somewhat equivalent goals, and the sets in priority order: 1. Real-time Impacts + Maintainability Loss 2. Transparency Loss + Modularity Loss + Code/RAM Size Increase 3. Performance Loss I wrote each goal now as a "minimize" objective. I think it is not possible to establish strict priorities on these objectives. Good engineering requires understanding and making good tradeoffs. I believe that #1 addresses the highest requirements we place on RTEMS and the libbsd philosophy. #2 leaves us with the burden of discussing and debating when tradeoffs are made. It may be better in some cases to increase code size by increasing modularity, but in other cases it may be better to reduce transparency to reduce code size. Gedare I'm presenting my concerns without doing appropriate research. This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible). Yes, I want my cake, and eat it too. "It would be great" if it is clear what small memory platforms lose when going with "LWIP" vs "libbsd", and how
[PATCH 1/2] cpukit/dev/can: Resolve warnings in 64bit builds
This resolves various gcc warnings in AArch64 LP64 builds of the CAN
framework.
---
cpukit/dev/can/can.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
index 2e6d5df65b..9f3fe0db98 100644
--- a/cpukit/dev/can/can.c
+++ b/cpukit/dev/can/can.c
@@ -34,6 +34,7 @@
* POSSIBILITY OF SUCH DAMAGE.
*/
+#include
#include
#include
@@ -57,13 +58,13 @@
real_can_interrupt_lock_release(bus); \
} while (0);
-static ssize_t
+static int
can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
static ssize_t
can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
static ssize_t
can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
-static ssize_t
+static int
can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
static int can_xmit(struct can_bus *bus);
@@ -179,7 +180,7 @@ static int try_sem(struct can_bus *bus)
return ret;
}
-static ssize_t
+static int
can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode)
{
CAN_DEBUG("can_bus_open\n");
@@ -210,7 +211,8 @@ static ssize_t can_bus_read(rtems_libio_t *iop, void
*buffer, size_t count)
len = CAN_MSG_LEN(&bus->can_rx_msg);
if (count < len) {
-CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct can_msg) =
%u\n",
+CAN_DEBUG("can_bus_read: buffer size is small min "
+ "sizeof(struct can_msg) = %" PRIuPTR "\n",
sizeof(struct can_msg));
return -RTEMS_INVALID_SIZE;
}
@@ -314,8 +316,8 @@ can_bus_write(rtems_libio_t *iop, const void *buffer,
size_t count)
CAN_DEBUG_TX("can_bus_write: can_msg_size = %u\n", msg_size);
if (msg_size > sizeof(struct can_msg)) {
-CAN_ERR("can_bus_write:"
- "can message len error msg_size = %u struct can_msg = %u\n",
+CAN_ERR("can_bus_write: can message "
+"len error msg_size = %u struct can_msg = %" PRIxPTR "\n",
msg_size, sizeof(struct can_msg));
return -RTEMS_INVALID_SIZE;
}
@@ -363,7 +365,7 @@ release_lock_and_return:
return ret;
}
-static ssize_t
+static int
can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer)
{
can_bus *bus = IMFS_generic_get_context_by_iop(iop);
--
2.30.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] bsps/nand: Update Xilinx NAND driver
This resovles gcc warnings by updating to the latest Xilinx NAND
controller driver.
---
bsps/include/dev/nand/xnandpsu.h | 4 +++-
bsps/include/dev/nand/xnandpsu_bbm.h | 2 +-
bsps/include/dev/nand/xnandpsu_hw.h | 2 +-
bsps/include/dev/nand/xnandpsu_onfi.h | 2 +-
bsps/shared/dev/nand/VERSION | 22 +-
bsps/shared/dev/nand/xnandpsu.c | 14 --
bsps/shared/dev/nand/xnandpsu_bbm.c | 2 +-
bsps/shared/dev/nand/xnandpsu_onfi.c | 2 +-
8 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/bsps/include/dev/nand/xnandpsu.h b/bsps/include/dev/nand/xnandpsu.h
index 3625299fb2..a93a74eb85 100644
--- a/bsps/include/dev/nand/xnandpsu.h
+++ b/bsps/include/dev/nand/xnandpsu.h
@@ -7,7 +7,7 @@
/**
*
* @file xnandpsu.h
-* @addtogroup nandpsu_v1_10
+* @addtogroup Overview
* @{
* @details
*
@@ -152,6 +152,8 @@
* 1.10 akm10/20/21Fix gcc warnings.
* 1.10 akm12/21/21Validate input parameters before use.
* 1.10 akm01/05/22Remove assert checks form static and internal APIs.
+* 1.11 akm03/31/22Fix unused parameter warning.
+* 1.11 akm03/31/22Fix misleading-indentation warning.
*
*
*
diff --git a/bsps/include/dev/nand/xnandpsu_bbm.h
b/bsps/include/dev/nand/xnandpsu_bbm.h
index 4d4fafffa3..b6b39dc990 100644
--- a/bsps/include/dev/nand/xnandpsu_bbm.h
+++ b/bsps/include/dev/nand/xnandpsu_bbm.h
@@ -7,7 +7,7 @@
/**
*
* @file xnandpsu_bbm.h
-* @addtogroup nandpsu_v1_10
+* @addtogroup Overview
* @{
*
* This file implements the Bad Block Management(BBM) functionality. This is
diff --git a/bsps/include/dev/nand/xnandpsu_hw.h
b/bsps/include/dev/nand/xnandpsu_hw.h
index 47e6c8fddc..e3a648b136 100644
--- a/bsps/include/dev/nand/xnandpsu_hw.h
+++ b/bsps/include/dev/nand/xnandpsu_hw.h
@@ -7,7 +7,7 @@
/**
*
* @file xnandpsu_hw.h
-* @addtogroup nandpsu_v1_10
+* @addtogroup Overview
* @{
*
* This file contains identifiers and low-level macros/functions for the Arasan
diff --git a/bsps/include/dev/nand/xnandpsu_onfi.h
b/bsps/include/dev/nand/xnandpsu_onfi.h
index 7523ff48ea..97ea3c404e 100644
--- a/bsps/include/dev/nand/xnandpsu_onfi.h
+++ b/bsps/include/dev/nand/xnandpsu_onfi.h
@@ -7,7 +7,7 @@
/**
*
* @file xnandpsu_onfi.h
-* @addtogroup nandpsu_v1_10
+* @addtogroup Overview
* @{
*
* This file defines all the ONFI 3.1 specific commands and values.
diff --git a/bsps/shared/dev/nand/VERSION b/bsps/shared/dev/nand/VERSION
index c0afe6e031..5e4eb00fe9 100644
--- a/bsps/shared/dev/nand/VERSION
+++ b/bsps/shared/dev/nand/VERSION
@@ -5,16 +5,20 @@ Import from:
https://github.com/Xilinx/embeddedsw.git
-commit 8a89579489c88ea5acd23d7d439ac928659c26cf
-Author: msreeram
-AuthorDate: Wed Apr 6 23:24:38 2022 -0600
+commit 5330a64c8efd14f0eef09befdbb8d3d738c33ec2
+Refs:
+Author: Nicole Baze
+AuthorDate: Mon Oct 3 13:27:19 2022 -0700
Commit: Siva Addepalli
-CommitDate: Fri Apr 8 16:47:15 2022 +0530
+CommitDate: Fri Oct 7 10:26:16 2022 +0530
-update license file for EmbeddedSW 2022.1 release
+xilpm: versal: server: Fix bug in AIE2 zeroization
-Update license file for EmbeddedSW 2022.1 release
+There is a bug in AIE2 zeriozation function when polling for memory
+zeroization complete. Currently the entire memory register is being
+checked against zero but instead we need to check the bits specific
+to the memory tiles. This patch updates the zeroization check by
+adding a mask so that only the desired bits are checked for zero.
-Signed-off-by: Manikanta Sreeram
-
-Acked-by : Meena Paleti
+Signed-off-by: Nicole Baze
+Acked-by: Jesus De Haro
diff --git a/bsps/shared/dev/nand/xnandpsu.c b/bsps/shared/dev/nand/xnandpsu.c
index a2e2235906..89451d19f8 100644
--- a/bsps/shared/dev/nand/xnandpsu.c
+++ b/bsps/shared/dev/nand/xnandpsu.c
@@ -7,7 +7,7 @@
/**
*
* @file xnandpsu.c
-* @addtogroup nandpsu_v1_10
+* @addtogroup Overview
* @{
*
* This file contains the implementation of the interface functions for
@@ -88,6 +88,8 @@
* 1.10 akm10/20/21Fix gcc warnings.
* 1.10 akm12/21/21Validate input parameters before use.
* 1.10 akm01/05/22Remove assert checks form static and internal APIs.
+* 1.11 akm03/31/22Fix unused parameter warning.
+* 1.11 akm03/31/22Fix misleading-indentation warning.
*
*
*
@@ -175,7 +177,7 @@ static s32 XNandPsu_ProgramPage(XNandPsu *InstancePtr, u32
Target, u32 Page,
static s32 XNandPsu_ReadPage(XNandPsu *InstancePtr, u32 Target, u32 Page,
u32 Col, u8 *Buf);
-static s32 XNandPsu_CheckOnDie(XNandPsu *InstancePtr, OnfiParamPage *Param);
+static s32 XNandPsu_CheckOnDie(XNandPsu *InstancePtr);
static void XNandPsu_SetEccAddrSize(XNandPsu *InstancePtr);
@@ -380,7 +382,7 @@ static s32 XNandPsu_FlashInit(XNandPsu *InstancePtr)
XNandPsu_InitTimingMode(InstancePtr, &Param[Index]);
Re: CAN Framework Docs for RTEMS-DOCS
Hi All, This is a reminder for the CAN framework docs written with .uml diagrams. Regards Prashanth S On Fri, 25 Nov 2022 at 20:07, Prashanth S wrote: > Hi All, > > This is a review request for CAN Framework docs. > > I pasted the link to gitlab, as the patch size exceeds the mailing list > limit. > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/869438a9da4a31a69f8d2718d5789d76fe209929 > > Regards > Prashanth S > > On Mon, 14 Nov 2022 at 20:03, Prashanth S > wrote: > >> Hi All, >> >> I have pasted the link to CAN framework docs for rtems-docs. As the patch >> size exceeds the mailing list, so pasted the link to GitLab. >> >> >> https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/01bd99dd8228128fdb5189e65ffa198312012d34 >> >> Regards >> Prashanth S >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
