Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On Wed, Jul 8, 2020 at 12:11 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > On 08/07/2020 08:35, Niteesh G. S. wrote: > > On Wed, Jul 8, 2020 at 11:52 AM Christian Mauderer > > > > wrote: > > > > On 08/07/2020 08:13, Sebas

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On 29/06/2020 21:39, Niteesh G. S. wrote: Hello, I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build system but failed. I get errors when compiling RTEMS-libBSD The new build system is pulled from Sebastian's branch HEAD: e4c193ddc163d6adb1b003254af9cc6b5d174a6f RTEMS was

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On 08/07/2020 10:29, Sebastian Huber wrote: > On 29/06/2020 21:39, Niteesh G. S. wrote: > >> Hello, >> >> I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build >> system >> but failed. I get errors when compiling RTEMS-libBSD >> >> The new build system is pulled from Sebastian's b

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On 08/07/2020 10:47, Christian Mauderer wrote: This didn't work for me. I got: [1391/1410] Linking build/arm/beagleboneblack/testsuites/samples/iostream.exe /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: ./librtemsbsp.a(bbb-i2c.c.1.o): in function `am335x_i2c_reset': /hom

[PATCH] bsps/beagle: Remove some debug output from I2C.

--- bsps/arm/beagle/i2c/bbb-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/arm/beagle/i2c/bbb-i2c.c b/bsps/arm/beagle/i2c/bbb-i2c.c index 664684b02f..b2a7cf814d 100644 --- a/bsps/arm/beagle/i2c/bbb-i2c.c +++ b/bsps/arm/beagle/i2c/bbb-i2c.c @@ -199,7 +199,7 @@ static

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On Wed, Jul 8, 2020 at 2:00 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 29/06/2020 21:39, Niteesh G. S. wrote: > > > Hello, > > > > I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build > > system > > but failed. I get errors when compiling RTEMS-libBSD >

[PATCH] build: Ensure mandatory compiler/linker flags

--- waf_libbsd.py | 9 + 1 file changed, 9 insertions(+) diff --git a/waf_libbsd.py b/waf_libbsd.py index a817e574..bfe23845 100644 --- a/waf_libbsd.py +++ b/waf_libbsd.py @@ -55,6 +55,11 @@ if windows: else: host_shell = '' +def _add_flags_if_not_present(current_flags, addional_f

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On 08/07/2020 11:11, Niteesh G. S. wrote: Could you please use the 5-freebsd-12 branch with the default build set. This is what I use normally. I was able to build libbsd on 5-freebsd-12 branch with the default build set though using minimal build set doesn't work. I have attached

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On Wed, Jul 8, 2020 at 2:48 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 08/07/2020 11:11, Niteesh G. S. wrote: > > > Could you please use the 5-freebsd-12 branch with the default > > build set. > > This is what I use normally. > > > > > > I was able to build li

[PATCH] nfsclient: Next attempt to fix 64-bit targets

In serporidok use the same structures used to hand over to the XDR encode/decode routines. We must not mix packed and unpacked structures. Close #4024. --- rtemsbsd/nfsclient/nfs.c | 94 +--- 1 file changed, 29 insertions(+), 65 deletions(-) diff --git a/rtem

Re: [PATCH] build: Ensure mandatory compiler/linker flags

Are these flags needed for all BSPs? If so why add to here ... https://git.rtems.org/rtems/tree/c/src/bsp.pc.in Chris On 8/7/20 7:17 pm, Sebastian Huber wrote: > --- > waf_libbsd.py | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/waf_libbsd.py b/waf_libbsd.py > index a817e574

Re: [PATCH] build: Ensure mandatory compiler/linker flags

On 08/07/2020 13:34, Chris Johns wrote: Are these flags needed for all BSPs? Yes, these flags are needed to build and use libbsd. If so why add to here ... https://git.rtems.org/rtems/tree/c/src/bsp.pc.in These are optimization flags. I thought the consensus was to export only ABI relevant f

Converting stack address to shared-memory object name

Hello, For my GSoC project, I have to provide high-level APIs for sharing isolated stacks. The POSIX compliant high-level way of sharing stacks can be to create a shared memory object of the stack to be shared through shm_open and then mmap that to the address space of the current stack. My doubt i

Re: Converting stack address to shared-memory object name

On 08/07/2020 14:43, Utkarsh Rai wrote: Hello, For my GSoC project, I have to provide high-level APIs for sharing isolated stacks. The POSIX compliant high-level way of sharing stacks can be to create a shared memory object of the stack to be shared through shm_open and then mmap that to the

Re: Converting stack address to shared-memory object name

On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber wrote: > > On 08/07/2020 14:43, Utkarsh Rai wrote: > > > Hello, > > For my GSoC project, I have to provide high-level APIs for sharing > > isolated stacks. > > The POSIX compliant high-level way of sharing stacks can be to create > > a shared memory o

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

[UPDATE]: I tried to build the EPICS 7 with RTEMS 5 for pc386 with Heinz's https://github.com/hjunkes/epicsBaseOwnPlayground while switching to Branch "7". The previous errors are gone but I am facing the following error: "../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file or

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

[Another Update]: I just commented the part of the codes that were causing the errors just as an experiment and ultimately got the following errors: ```86-rtems5/bin/ld: cannot find -lbsd collect2: error: ld returned 1 exit status /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/

GSoC 2020: Implemented FreeBSD structures in RTEMS

Hello, As part of my GSoC project: Beagle BSP: Add FDT based initialization I had to import a few drivers from libBSD to RTEMS this eventually led to importing their dependencies and other simple drivers. While porting these drivers we saw a huge amount of code being duplicated or I must say a pa

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

On Wed, Jul 8, 2020 at 12:33 PM Mritunjay Sharma wrote: > > [UPDATE]: I tried to build the EPICS 7 with RTEMS 5 for pc386 with Heinz's > https://github.com/hjunkes/epicsBaseOwnPlayground > while switching to Branch "7". The previous errors are gone but I am facing > the following error: > > "../

Re: Converting stack address to shared-memory object name

On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom wrote: > On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber > wrote: > > > > On 08/07/2020 14:43, Utkarsh Rai wrote: > > > > > Hello, > > > For my GSoC project, I have to provide high-level APIs for sharing > > > isolated stacks. > > > The POSIX compliant

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

Sorry for the long delay. Yes, this Epics version still uses the rtems-libbsd. The bsp must be built with --enable-network. I'm trying to create an Epics version over the weekend that recognizes from the configuration which libbsd version should be used. Viele Grüße Heinz Junkes -- Experience