[PATCH rtems-libbsd/6-freebsd-12 2/3] syscall/open: Reference the path info directory vnode
From: Chris Johns
The kernel open call requires a path so to open a file we need to
set the current directory to the parent vnode. If the open mode is
create the path info vnode is the directory to perform the open
create in. Using the parent node creates the file in wrong path.
Updates #4723
---
rtemsbsd/rtems/rtems-bsd-syscall-api.c | 24 ++---
testsuite/nfs01/test_main.c| 75 --
2 files changed, 64 insertions(+), 35 deletions(-)
diff --git a/rtemsbsd/rtems/rtems-bsd-syscall-api.c
b/rtemsbsd/rtems/rtems-bsd-syscall-api.c
index 76fc8ad7..cfceb768 100644
--- a/rtemsbsd/rtems/rtems-bsd-syscall-api.c
+++ b/rtemsbsd/rtems/rtems-bsd-syscall-api.c
@@ -931,9 +931,18 @@ rtems_bsd_sysgen_open_node(
} else {
rtems_filesystem_location_info_t *rootloc =
>pathinfo.mt_entry->mt_fs_root->location;
+ /*
+* We need the parent directory so open can find the
+* the entry. If we are creating the file the pathinfo
+* vnode entry is the directory to create open the
+* file in.
+*/
cdir = rtems_bsd_libio_loc_to_vnode_dir(>pathinfo);
+ if (cdir == NULL || creat) {
+ cdir = rtems_bsd_libio_loc_to_vnode(>pathinfo);
+ }
if (fdp->fd_cdir == NULL) {
- cdir = rtems_bsd_libio_loc_to_vnode(rootloc);
+ cdir = rtems_bsd_libio_loc_to_vnode_dir(rootloc);
} else if (rtems_bsd_libio_loc_to_vnode(>pathinfo) ==
rtems_bsd_libio_loc_to_vnode(rootloc)) {
/*
@@ -958,11 +967,14 @@ rtems_bsd_sysgen_open_node(
FILEDESC_XUNLOCK(fdp);
if (RTEMS_BSD_SYSCALL_TRACE) {
- printf("bsd: sys: open: path=%s opath=%s vn=%p cwd=%p"
- " flags=%08x mode=%08x isdir=%s\n",
- path, opath,
- creat ? NULL : rtems_bsd_libio_loc_to_vnode(>pathinfo),
- fdp->fd_cdir, oflag, mode, isdir ? "yes" : "no");
+ struct vnode* _vn =
rtems_bsd_libio_loc_to_vnode(>pathinfo);
+ struct vnode* _dvn =
rtems_bsd_libio_loc_to_vnode_dir(>pathinfo);
+ printf("bsd: sys: open: path=%s opath=%s vn=%p (%c) dvn=%p (%c)
cwd=%p"
+ " flags=%08x mode=%o isdir=%s\n",
+ path, opath,
+ _vn, creat ? 'c' : _vn ? (_vn->v_type == VDIR ? 'd' :
'r') : 'n',
+ _dvn, _dvn ? (_dvn->v_type == VDIR ? 'd' : 'r') : 'n',
+ fdp->fd_cdir, oflag, mode, isdir ? "yes" : "no");
}
VREF(fdp->fd_cdir);
diff --git a/testsuite/nfs01/test_main.c b/testsuite/nfs01/test_main.c
index cfa163e1..4ef82b44 100644
--- a/testsuite/nfs01/test_main.c
+++ b/testsuite/nfs01/test_main.c
@@ -46,7 +46,6 @@
#include
#include
-#include
#include
@@ -58,6 +57,14 @@
static const char *test_top = "test-nfs01";
+#define rtems_test_assert(__exp) \
+ do { \
+if (!(__exp)) { \
+ printf( "%s: %d %s\n", __FILE__, __LINE__, #__exp ); \
+ assert(1 == 0); \
+} \
+ } while (0)
+
#define rtems_test_errno_assert(__exp) \
do { \
if (!(__exp)) { \
@@ -328,10 +335,46 @@ test_path_eval(const char *base, int depth)
test_cleanup(base);
}
+static void
+test_path_file_copy(const char *base, int depth)
+{
+ char path[MAXPATHLEN];
+ struct stat sb;
+ FILE* f;
+ int l;
+
+ printf("test path eval\n");
+
+ test_setup(base);
+
+ memset(path, 0, sizeof(path));
+
+ for (l = 1; l <= depth; ++l) {
+ char* p = path + strlen(path);
+ if (l > 1) {
+ *p++ = '/';
+ }
+ snprintf(p, sizeof(path), "%d", l);
+ printf("test: nfs: mkdir: %s\n", path);
+ rtems_test_errno_assert(mkdir(path, 0777) == 0);
+ }
+
+ strlcat(path, "/test-file.txt", sizeof(path));
+ printf("Create file %s\n", path);
+ rtems_test_errno_assert((f = fopen(path, "w")) != NULL);
+ rtems_test_errno_assert(fprintf(f, "The contents of %s\nNFS test\n",
path) > 0);
+ rtems_test_errno_assert(fclose(f) == 0);
+ printf("Checking %s has been copied\n", path);
+ rtems_test_errno_assert(stat(path, ) == 0);
+
+ test_cleanup(base);
+}
+
static void
test_nfs(const char *base)
{
test_path_eval(base, 5);
+ test_path_file_copy(base, 3);
#if NFS_TREE_WALK
test_printer_data pd;
memset(, 0, sizeof(pd));
@@ -339,30 +382,6 @@ test_nfs(const char *base)
#endif
}
-static void
-telnet_shell(char *name, void *arg)
-{
- rtems_shell_env_t env;
-
- rtems_shell_dup_current_env();
-
- env.devname = name;
- env.taskname = "TLNT";
- env.login_check = NULL;
- env.forever =
[PATCH rtems-libbsd/6-freebsd-12 1/3] freenbsd/vfs: VFS attributes need to have the same size mode_t variable
From: Chris Johns
If the size in the attributes struct does not match the mode_t the
VNOVAL checks fail because sie of the values are not the same.
Updates #4723
---
freebsd/sys/sys/vnode.h | 4
1 file changed, 4 insertions(+)
diff --git a/freebsd/sys/sys/vnode.h b/freebsd/sys/sys/vnode.h
index d297c931..ddb9ac30 100644
--- a/freebsd/sys/sys/vnode.h
+++ b/freebsd/sys/sys/vnode.h
@@ -266,8 +266,12 @@ struct xvnode {
*/
struct vattr {
enum vtype va_type;/* vnode type (for create) */
+#ifndef __rtems__
u_short va_mode;/* files access mode and type */
u_short va_padding0;
+#else /* __rtems__ */
+ mode_t va_mode;/* files access mode and type */
+#endif /* __rtems__ */
uid_t va_uid; /* owner user id */
gid_t va_gid; /* owner group id */
nlink_t va_nlink; /* number of references to file */
--
2.37.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd/6-freebsd-12 3/3] freebsd/vfs: Pass in the td's cred to the VFS calls
From: Chris Johns Closes #4723 --- rtemsbsd/rtems/rtems-kernel-vfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rtemsbsd/rtems/rtems-kernel-vfs.c b/rtemsbsd/rtems/rtems-kernel-vfs.c index 2f4d009b..0817df81 100644 --- a/rtemsbsd/rtems/rtems-kernel-vfs.c +++ b/rtemsbsd/rtems/rtems-kernel-vfs.c @@ -490,7 +490,7 @@ rtems_bsd_vfs_fchmod(const rtems_filesystem_location_info_t *loc, mode_t mode) } return rtems_bsd_error_to_status_and_errno(ENOMEM); } - error = setfmode(td, NULL, vp, mode); + error = setfmode(td, td->td_ucred, vp, mode); return rtems_bsd_error_to_status_and_errno(error); } @@ -511,7 +511,7 @@ rtems_bsd_vfs_chown( } return rtems_bsd_error_to_status_and_errno(ENOMEM); } - error = setfown(td, NULL, vp, owner, group); + error = setfown(td, td->td_ucred, vp, owner, group); return rtems_bsd_error_to_status_and_errno(error); } -- 2.37.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building leon3 prom image for testing on renode
Hi Mazaya, On Tue, Jul 18, 2023 at 8:35 PM Muhammad Sulthan Mazaya < msulthanmaz...@gmail.com> wrote: > Hi Alan, > > > Also, as you mentioned, the renode Zephyr example runs directly from RAM > without a prom image. Is it that the RTEMS LEON3 BSP relies on > initialization done by the boot prom (GRMON or MKPROM2 based boot code)? > > Do you or anyone on the devel mailing list know where/how can I check > which kind of initialization rtems leon3 bsp rely on? Sorry, I am fairly > new to this > > The prom image source code is pretty simple, but it would take a little bit of time (for me at least) to decode since it is in SPARC assembly language: The code: https://github.com/TUT-ASI/leon3-grlib-gpl-mirror/blob/master/software/leon3/prom.S And the prom.h header they use for the renode prom image: https://github.com/antmicro/renode-rtems-leon3/blob/main/prom.h Essentially, it is setting up the processor including the stack pointer, and minimal configuration (AMBA Plug and play?). The idea would be to translate what the prom.S assembly program is doing into a set of .resc statements to program configuration registers and set up anything that RTEMS may need to run. It may be a subset of everything that the assembly code does - It may come down to just one or two statements. I'm not being specific with the steps, because I'm not sure myself.. I would have to take some time to figure out exactly what it's doing. Here is an example for the K210 where some of the peripheral registers are programmed in the renode resc script: https://github.com/renode/renode/blob/master/scripts/single-node/kendryte_k210.resc#L10 Replacing the prom with resc statements is one way to solve the problem - by understanding the assembly and the memory mapped registers that are being programmed. The other way to solve the problem is by figuring out the way to supply the prom.bin file to users that need to run RTEMS/LEON3 binaries on renode. One is an embedded programming problem and the other is an automation problem. I think both are valid solutions. Regards, Alan > Thank you, > Mazaya > > On Tue, Jul 18, 2023 at 11:27 PM Alan Cudmore > wrote: > >> Hi Mazaya, >> I wonder if it is possible to initialize the processor to the state where >> it can run the RTEMS image in RAM without using the prom image? The >> processor initialization would have to go in the resc script before the >> image is loaded and started. >> Also, as you mentioned, the renode Zephyr example runs directly from RAM >> without a prom image. Is it that the RTEMS LEON3 BSP relies on >> initialization done by the boot prom (GRMON or MKPROM2 based boot code)? >> >> https://github.com/renode/renode/blob/master/scripts/single-node/leon3_zephyr.resc >> >> I guess it ends up being a trade off of tooling vs. trying to program the >> necessary initialization in the resc script. >> >> Regards, >> Alan >> >> On Tue, Jul 18, 2023 at 2:46 AM Muhammad Sulthan Mazaya < >> msulthanmaz...@gmail.com> wrote: >> >>> Hi, >>> >>> I was trying to implement renode for testing leon3 using rtems-test. I >>> noticed that from the example they provide >>> https://github.com/antmicro/renode-rtems-leon3/blob/main/leon3_rtems.resc, >>> it seems like the renode simulator needs the prom image of leon3 to do so. >>> I don't think an additional build step before testing a particular bsp is >>> something supported by the build config of rtems-tools + my mentors >>> also said it shouldn't be on the rtems-tools. Is it okay to have RSB build >>> that for us as part of the BSP? >>> >>> Thank you, >>> Mazaya >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RSB] rtems-net-legacy: Update net and waf versions
Thanks. Pushed.
On Wed, Jul 19, 2023 at 8:44 PM Chris Johns wrote:
>
> Looks good.
>
> Thanks
> Chris
>
> On 20/7/2023 11:17 am, Vijay Kumar Banerjee wrote:
> > ---
> > rtems/config/tools/rtems-net-legacy-6.cfg | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
> > b/rtems/config/tools/rtems-net-legacy-6.cfg
> > index 9193a58..559ec01 100644
> > --- a/rtems/config/tools/rtems-net-legacy-6.cfg
> > +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> > @@ -3,10 +3,10 @@
> > #
> >
> > # branch: main
> > -%define rtems_net_version ba35f73d2ddc82d2b9a7b728dc63552be2274968
> > +%define rtems_net_version 3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2
> > %hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
> > -
> > EljXAoCCIpFgncarsSR9V/WczB3VO9+VqTsJfrkvOCpwCuO8SWY6GTM46DnvyKBUrmkv0Rk+0TBdOifuYaMMug==
> > -%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
> > +
> > ANUrgSU3YRAnbEM/9wL5R4LrRCcyDYZz9KbRhTxnNYvUPjrfNgO+bM1qEYtJI6qUxvlKZYkVIkeOKxsAtjj1/A==
> > +%define rtems_waf_version 68654b4f995382765605dc16917baad4bdbf7f7c
> > %hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
> > -
> > gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
> > +
> > NAuyFxjfSiQd6VfYZl4fJClywPrLF2fN+GjXHjq3ddceqaBrSeHZ+XpYpU3XTnk2qKICsUSTLV+CskDuWdwqvQ==
> > %include tools/rtems-net-legacy-common.cfg
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RSB] rtems-net-legacy: Update net and waf versions
Looks good.
Thanks
Chris
On 20/7/2023 11:17 am, Vijay Kumar Banerjee wrote:
> ---
> rtems/config/tools/rtems-net-legacy-6.cfg | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
> b/rtems/config/tools/rtems-net-legacy-6.cfg
> index 9193a58..559ec01 100644
> --- a/rtems/config/tools/rtems-net-legacy-6.cfg
> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> @@ -3,10 +3,10 @@
> #
>
> # branch: main
> -%define rtems_net_version ba35f73d2ddc82d2b9a7b728dc63552be2274968
> +%define rtems_net_version 3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2
> %hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
> -
> EljXAoCCIpFgncarsSR9V/WczB3VO9+VqTsJfrkvOCpwCuO8SWY6GTM46DnvyKBUrmkv0Rk+0TBdOifuYaMMug==
> -%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
> +
> ANUrgSU3YRAnbEM/9wL5R4LrRCcyDYZz9KbRhTxnNYvUPjrfNgO+bM1qEYtJI6qUxvlKZYkVIkeOKxsAtjj1/A==
> +%define rtems_waf_version 68654b4f995382765605dc16917baad4bdbf7f7c
> %hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
> -
> gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
> +
> NAuyFxjfSiQd6VfYZl4fJClywPrLF2fN+GjXHjq3ddceqaBrSeHZ+XpYpU3XTnk2qKICsUSTLV+CskDuWdwqvQ==
> %include tools/rtems-net-legacy-common.cfg
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5
On Wed, Jul 19, 2023 at 7:56 PM Vijay Kumar Banerjee wrote: > > On Wed, Jul 19, 2023 at 7:50 PM Chris Johns wrote: > > > > On 20/7/2023 10:18 am, Vijay Kumar Banerjee wrote: > > > On Wed, Jul 19, 2023 at 6:39 PM Chris Johns wrote: > > >> > > >> Excellent. > > >> > > >> Could you please update the hash in the RSB for the net legacy package? > > >> Updating net legacy version and waf version: https://lists.rtems.org/pipermail/devel/2023-July/075839.html > > > Thanks for mentioning it! While trying to build from RSB, I realized > > > two important changes I need from rtems build: > > > 1. Removing networking check, put a patch for it just now: > > > https://lists.rtems.org/pipermail/devel/2023-July/075830.html > > > > I saw that. > > > > > 2. Building the ping and telnetd02 requires posix. For this, should be > > > conditionally build these two tests only when RTEMS_POSIX_API is true? > > > > Which part of POSIX is needed? I ask because I think the POSIX option is > > only > > controlling signals and maybe something else, > Signals only, yes. > > > I cannot remember what the list > > is. What happens if you remove the check? > > ``` > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > ./libnetworking.a(main_ping.c.3.o): in function `main_ping': > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:684: > undefined reference to `alarm' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:987: > undefined reference to `sigaction' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1000: > undefined reference to `sigaction' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > ./libnetworking.a(main_ping.c.3.o): in function `g_finish': > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1620: > undefined reference to `signal' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1621: > undefined reference to `signal' > collect2: error: ld returned 1 exit status > > ``` > > > > > > > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH RSB] rtems-net-legacy: Update net and waf versions
---
rtems/config/tools/rtems-net-legacy-6.cfg | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
b/rtems/config/tools/rtems-net-legacy-6.cfg
index 9193a58..559ec01 100644
--- a/rtems/config/tools/rtems-net-legacy-6.cfg
+++ b/rtems/config/tools/rtems-net-legacy-6.cfg
@@ -3,10 +3,10 @@
#
# branch: main
-%define rtems_net_version ba35f73d2ddc82d2b9a7b728dc63552be2274968
+%define rtems_net_version 3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2
%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
-
EljXAoCCIpFgncarsSR9V/WczB3VO9+VqTsJfrkvOCpwCuO8SWY6GTM46DnvyKBUrmkv0Rk+0TBdOifuYaMMug==
-%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
+
ANUrgSU3YRAnbEM/9wL5R4LrRCcyDYZz9KbRhTxnNYvUPjrfNgO+bM1qEYtJI6qUxvlKZYkVIkeOKxsAtjj1/A==
+%define rtems_waf_version 68654b4f995382765605dc16917baad4bdbf7f7c
%hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
-
gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
+
NAuyFxjfSiQd6VfYZl4fJClywPrLF2fN+GjXHjq3ddceqaBrSeHZ+XpYpU3XTnk2qKICsUSTLV+CskDuWdwqvQ==
%include tools/rtems-net-legacy-common.cfg
--
2.34.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] powerpc/beatnik: Remove RTEMS_NETWORKING check from bsp.h
Pushed. Thanks! On Wed, Jul 19, 2023 at 7:51 PM Chris Johns wrote: > > Looks good. > > Thanks > Chris > > On 20/7/2023 10:15 am, Vijay Kumar Banerjee wrote: > > --- > > bsps/powerpc/beatnik/include/bsp.h | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/bsps/powerpc/beatnik/include/bsp.h > > b/bsps/powerpc/beatnik/include/bsp.h > > index 477f03345d..a70bb3997f 100644 > > --- a/bsps/powerpc/beatnik/include/bsp.h > > +++ b/bsps/powerpc/beatnik/include/bsp.h > > @@ -173,12 +173,10 @@ extern void BSP_motload_pci_fixup(void); > > int BSP_i2c_initialize(void); > > > > /* Networking; */ > > -#if defined(RTEMS_NETWORKING) > > #include > > int rtems_em_attach(struct rtems_bsdnet_ifconfig *, int); > > int rtems_dec21140_driver_attach(struct rtems_bsdnet_ifconfig *, int); > > int rtems_dc_driver_attach(struct rtems_bsdnet_ifconfig *, int); > > -#endif > > > > /* NOT FOR PUBLIC USE BELOW HERE */ > > #define BSP_PCI_HOSE0_MEM_BASE0x8000 /* must be aligned to size */ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 3/3] mvme3100: Initialize libi2c at device driver order
To use the libi2c, application needs to be configured with
#define CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER
---
bsps/powerpc/mvme3100/i2c/i2c_init.c | 11 ++-
bsps/powerpc/mvme3100/start/bspstart.c | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/bsps/powerpc/mvme3100/i2c/i2c_init.c
b/bsps/powerpc/mvme3100/i2c/i2c_init.c
index 9e242baf20..7e6fb50020 100644
--- a/bsps/powerpc/mvme3100/i2c/i2c_init.c
+++ b/bsps/powerpc/mvme3100/i2c/i2c_init.c
@@ -86,13 +86,14 @@ BSP_i2c_initialize(void)
{
int busno, succ = 0;
- /* Initialize the library */
- if ( rtems_libi2c_initialize() ) {
- safe_printf("Initializing I2C library failed\n");
- return -1;
- }
+ /* Library initialize by io module */
/* Register our bus driver */
+if (!rtems_libi2c_is_initialized){
+safe_printf("LIBI2C NOT INITIALIZED\n");
+return -1;
+}
+
if ( (busno=rtems_libi2c_register_bus(
BSP_I2C_BUS0_NAME,
BSP_I2C_BUS_DESCRIPTOR) ) < 0 ) {
diff --git a/bsps/powerpc/mvme3100/start/bspstart.c
b/bsps/powerpc/mvme3100/start/bspstart.c
index f27304c144..97faefed35 100644
--- a/bsps/powerpc/mvme3100/start/bspstart.c
+++ b/bsps/powerpc/mvme3100/start/bspstart.c
@@ -436,7 +436,7 @@ static void mvme3100_i2c_initialize(void)
RTEMS_SYSINIT_ITEM(
mvme3100_i2c_initialize,
- RTEMS_SYSINIT_BSP_PRE_DRIVERS,
+ RTEMS_SYSINIT_DEVICE_DRIVERS,
RTEMS_SYSINIT_ORDER_MIDDLE
);
--
2.34.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 2/3] confdefs: Add configure macro for libi2c
Add CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER define
---
cpukit/include/rtems/confdefs/iodrivers.h | 8
1 file changed, 8 insertions(+)
diff --git a/cpukit/include/rtems/confdefs/iodrivers.h
b/cpukit/include/rtems/confdefs/iodrivers.h
index 16d64fbb98..cf5530fe2b 100644
--- a/cpukit/include/rtems/confdefs/iodrivers.h
+++ b/cpukit/include/rtems/confdefs/iodrivers.h
@@ -60,6 +60,7 @@
defined(CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER) || \
defined(CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER) || \
defined(CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER) || \
+ defined(CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER) || \
defined(CONFIGURE_APPLICATION_EXTRA_DRIVERS)
#define _CONFIGURE_HAS_IO_DRIVERS
#endif
@@ -112,6 +113,10 @@
#include
#endif
+#ifdef CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER
+ #include
+#endif
+
#ifndef CONFIGURE_MAXIMUM_DRIVERS
#define CONFIGURE_MAXIMUM_DRIVERS
#endif
@@ -157,6 +162,9 @@ _IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
#ifdef CONFIGURE_APPLICATION_EXTRA_DRIVERS
CONFIGURE_APPLICATION_EXTRA_DRIVERS,
#endif
+ #ifdef CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER
+RTEMS_LIBI2C_DRIVER_TABLE_ENTRY,
+ #endif
#if defined(CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER) || \
!defined(_CONFIGURE_HAS_IO_DRIVERS)
NULL_DRIVER_TABLE_ENTRY
--
2.34.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 1/3] libi2c: Use rtems thread api
Replace custom mutex handling with rtems thread api
---
cpukit/include/rtems/libi2c.h | 2 +
cpukit/libi2c/libi2c.c| 114 +++---
2 files changed, 37 insertions(+), 79 deletions(-)
diff --git a/cpukit/include/rtems/libi2c.h b/cpukit/include/rtems/libi2c.h
index 7b86ab5f99..b8a4a5e5d9 100644
--- a/cpukit/include/rtems/libi2c.h
+++ b/cpukit/include/rtems/libi2c.h
@@ -119,6 +119,8 @@ rtems_i2c_ioctl (
extern const rtems_driver_address_table rtems_libi2c_io_ops;
+extern bool rtems_libi2c_is_initialized;
+
/* Unfortunately, if you want to add this driver to
* a RTEMS configuration table then you need all the
* members explicitly :-( (Device_driver_table should
diff --git a/cpukit/libi2c/libi2c.c b/cpukit/libi2c/libi2c.c
index 027c4859c1..53f17d878e 100644
--- a/cpukit/libi2c/libi2c.c
+++ b/cpukit/libi2c/libi2c.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
@@ -103,35 +104,22 @@
rtems_device_major_number rtems_libi2c_major;
-static bool is_initialized = false;
+bool rtems_libi2c_is_initialized = false;
static struct i2cbus
{
rtems_libi2c_bus_t *bush;
- volatile rtems_id mutex; /* lock this across start -> stop */
+ rtems_mutex mutex; /* lock this across start -> stop */
volatile bool started;
char *name;
-} busses[MAX_NO_BUSSES] = { { NULL, RTEMS_ID_NONE, false, NULL } };
+} busses[MAX_NO_BUSSES] = { { NULL, {}, false, NULL } };
static struct
{
rtems_libi2c_drv_t *drv;
} drvs[MAX_NO_DRIVERS] = { { NULL } };
-static rtems_id libmutex = RTEMS_ID_NONE;
-
-#define LOCK(m)assert(!rtems_semaphore_obtain((m), RTEMS_WAIT,
RTEMS_NO_TIMEOUT))
-#define UNLOCK(m) rtems_semaphore_release((m))
-
-#define LIBLOCK() LOCK(libmutex)
-#define LIBUNLOCK()UNLOCK(libmutex)
-
-#define MUTEX_ATTS \
- ( RTEMS_PRIORITY \
-| RTEMS_BINARY_SEMAPHORE \
-|RTEMS_INHERIT_PRIORITY\
-|RTEMS_NO_PRIORITY_CEILING \
-|RTEMS_LOCAL )
+static rtems_mutex libmutex;
/* During early stages of life, stdio is not available */
@@ -148,21 +136,6 @@ va_list ap;
va_end(ap);
}
-static rtems_status_code
-mutexCreate (rtems_name nm, rtems_id *pm)
-{
- rtems_status_code sc;
-
- if (RTEMS_SUCCESSFUL !=
- (sc = rtems_semaphore_create (nm, 1, MUTEX_ATTS, 0, pm))) {
- if ( _System_state_Is_up( _System_state_Get() ) )
- rtems_error (sc, DRVNM "Unable to create mutex\n");
- else
- printk (DRVNM "Unable to create mutex (status code %i)\n", sc);
- }
- return sc;
-}
-
/* Lock a bus avoiding to have a mutex, which is mostly
* unused, hanging around all the time. We just create
* and delete it on the fly...
@@ -174,37 +147,27 @@ static void
lock_bus (int busno)
{
struct i2cbus *bus = [busno];
+ char name[5];
- if (bus->mutex == RTEMS_ID_NONE) {
-/*
- * Nobody is holding the bus mutex - it's not there. Create it on the fly.
- */
-LIBLOCK ();
-if (bus->mutex == RTEMS_ID_NONE) {
- rtems_id m = RTEMS_ID_NONE;
- rtems_status_code sc = mutexCreate (
-rtems_build_name ('i', '2', 'c', '0' + busno),
-
- );
- if (sc != RTEMS_SUCCESSFUL) {
-LIBUNLOCK ();
-rtems_panic (DRVNM "Unable to create bus lock");
-return;
- }
- bus->mutex = m;
-}
-LIBUNLOCK ();
- }
+ rtems_mutex_lock();
+
+ snprintf(name, 5, "I2C%d", busno);
+
+ rtems_mutex_init(>mutex, name);
+
+ rtems_mutex_unlock();
/* Now lock this bus */
- LOCK (bus->mutex);
+
+ rtems_mutex_lock(>mutex);
}
static void
unlock_bus (int busno)
{
struct i2cbus *bus = [busno];
- UNLOCK (bus->mutex);
+
+ rtems_mutex_unlock(>mutex);
}
/* Note that 'arg' is always passed in as NULL */
@@ -212,21 +175,16 @@ rtems_status_code
rtems_i2c_init (rtems_device_major_number major, rtems_device_minor_number
minor,
void *arg)
{
- rtems_status_code rval;
/* No busses or drivers can be registered at this point;
* avoid the macro aborting with an error
DECL_CHECKED_DRV (drv, busno, minor)
*/
- rval = mutexCreate (rtems_build_name ('l', 'I', '2', 'C'), );
+ rtems_mutex_init(, "LIBI2C");
+ rtems_libi2c_is_initialized = true;
+ rtems_libi2c_major = major;
+ return 0;
- if ( RTEMS_SUCCESSFUL == rval ) {
- is_initialized = true;
- rtems_libi2c_major = major;
- } else {
- libmutex = RTEMS_ID_NONE;
- }
- return rval;
}
rtems_status_code
@@ -350,7 +308,7 @@ rtems_libi2c_initialize (void)
{
rtems_status_code sc;
- if (is_initialized) {
+ if (rtems_libi2c_is_initialized) {
/*
* already called before? then skip this step
*/
@@ -361,18 +319,15 @@ rtems_libi2c_initialize (void)
* the return code of the 'init' operation, so we cannot
* rely on return code since it may seem OK even if the driver 'init;
* op failed.
- * Let 'init' handle
Re: [PATCH rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5
On Wed, Jul 19, 2023 at 7:50 PM Chris Johns wrote: > > On 20/7/2023 10:18 am, Vijay Kumar Banerjee wrote: > > On Wed, Jul 19, 2023 at 6:39 PM Chris Johns wrote: > >> > >> Excellent. > >> > >> Could you please update the hash in the RSB for the net legacy package? > >> > > Thanks for mentioning it! While trying to build from RSB, I realized > > two important changes I need from rtems build: > > 1. Removing networking check, put a patch for it just now: > > https://lists.rtems.org/pipermail/devel/2023-July/075830.html > > I saw that. > > > 2. Building the ping and telnetd02 requires posix. For this, should be > > conditionally build these two tests only when RTEMS_POSIX_API is true? > > Which part of POSIX is needed? I ask because I think the POSIX option is only > controlling signals and maybe something else, Signals only, yes. > I cannot remember what the list > is. What happens if you remove the check? ``` /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: ./libnetworking.a(main_ping.c.3.o): in function `main_ping': /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:684: undefined reference to `alarm' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:987: undefined reference to `sigaction' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1000: undefined reference to `sigaction' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: ./libnetworking.a(main_ping.c.3.o): in function `g_finish': /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1620: undefined reference to `signal' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1621: undefined reference to `signal' collect2: error: ld returned 1 exit status ``` > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] powerpc/beatnik: Remove RTEMS_NETWORKING check from bsp.h
Looks good. Thanks Chris On 20/7/2023 10:15 am, Vijay Kumar Banerjee wrote: > --- > bsps/powerpc/beatnik/include/bsp.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/bsps/powerpc/beatnik/include/bsp.h > b/bsps/powerpc/beatnik/include/bsp.h > index 477f03345d..a70bb3997f 100644 > --- a/bsps/powerpc/beatnik/include/bsp.h > +++ b/bsps/powerpc/beatnik/include/bsp.h > @@ -173,12 +173,10 @@ extern void BSP_motload_pci_fixup(void); > int BSP_i2c_initialize(void); > > /* Networking; */ > -#if defined(RTEMS_NETWORKING) > #include > int rtems_em_attach(struct rtems_bsdnet_ifconfig *, int); > int rtems_dec21140_driver_attach(struct rtems_bsdnet_ifconfig *, int); > int rtems_dc_driver_attach(struct rtems_bsdnet_ifconfig *, int); > -#endif > > /* NOT FOR PUBLIC USE BELOW HERE */ > #define BSP_PCI_HOSE0_MEM_BASE0x8000 /* must be aligned to size */ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5
On 20/7/2023 10:18 am, Vijay Kumar Banerjee wrote: > On Wed, Jul 19, 2023 at 6:39 PM Chris Johns wrote: >> >> Excellent. >> >> Could you please update the hash in the RSB for the net legacy package? >> > Thanks for mentioning it! While trying to build from RSB, I realized > two important changes I need from rtems build: > 1. Removing networking check, put a patch for it just now: > https://lists.rtems.org/pipermail/devel/2023-July/075830.html I saw that. > 2. Building the ping and telnetd02 requires posix. For this, should be > conditionally build these two tests only when RTEMS_POSIX_API is true? Which part of POSIX is needed? I ask because I think the POSIX option is only controlling signals and maybe something else, I cannot remember what the list is. What happens if you remove the check? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems] powerpc/beatnik: Remove RTEMS_NETWORKING check from bsp.h
--- bsps/powerpc/beatnik/include/bsp.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/bsps/powerpc/beatnik/include/bsp.h b/bsps/powerpc/beatnik/include/bsp.h index 477f03345d..a70bb3997f 100644 --- a/bsps/powerpc/beatnik/include/bsp.h +++ b/bsps/powerpc/beatnik/include/bsp.h @@ -173,12 +173,10 @@ extern void BSP_motload_pci_fixup(void); int BSP_i2c_initialize(void); /* Networking; */ -#if defined(RTEMS_NETWORKING) #include int rtems_em_attach(struct rtems_bsdnet_ifconfig *, int); int rtems_dec21140_driver_attach(struct rtems_bsdnet_ifconfig *, int); int rtems_dc_driver_attach(struct rtems_bsdnet_ifconfig *, int); -#endif /* NOT FOR PUBLIC USE BELOW HERE */ #define BSP_PCI_HOSE0_MEM_BASE0x8000 /* must be aligned to size */ -- 2.34.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Regulator Delete
Hi Starting another thread so we can focus on this without all the code in the way. Chris' concern was that deleting the regulator includes deleting the delivery thread and that could cause the delivery function to leave resources like mutexes in an unknown state. He asked about a coordinated shutdown/delete. In thinking about this, I realized that you cannot delete a partition while buffers it has given to a user are outstanding. It returns RTEMS_RESOURCE_IN_USE. This means the rtems_partition_delete() call will fail in Chris' scenario because 1+ buffers would still be outstanding. My thought is to not allow the user to delete a regulator instance unless all buffers are released (e.g. in the pool). The buffers are logically in one of four states: in the unused pool, held by Source, pending delivery, or in the process of being delivered. The application will have to perform some coordination to ensure all buffers are back in the pool. The source needs to quit producing and all messages pending delivery need to either be delivered or flushed. I'm proposing the following: + cannot delete unless all buffers are in the unused pool (e.g. none "obtained") - none need to be released + add method to flush messages pending delivery + add info method with number of buffers outstanding (e.g obtained but not released) - later maybe add more statistics. The application would have to coordinate the clearing of the regulator by: (1) stopping the Source from obtaining buffers and sending to the regulator (2) flush the pending undelivered message OR wait for them to be delivered (3) wait for there to be no outstanding messages Then it could be deleted. I considered adding a way to have the regulator stop accepting input and stop delivering but that does not address the issue of getting the buffers back which the Source may have. When the current message being delivered finishes, the buffer will be released. Ultimately, the application has to stop producing input and clear the "work queue" somehow. I think I have defined a fairly straightforward way to do that. How does this sound? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Repository edit
On 19.07.23 04:30, Gedare Bloom wrote: I had a local copy of the two commits that were dropped during the rewinding. I have pushed them back. We are back to the state prior to the accidental push. Hashes all look good. Thanks for handling this. Thanks, looks good. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
