Re: build of libbsd for powerpc fails with error: redefinition of 'eieio'

Hello Peter, On 16/07/2019 19:58, Peter Dufault wrote: I have a build failure with the MVME5500 “beatnik” BSP. Therefore I tried to build the “psim” BSP and have the same failure: the FreeBSD PowerPC “cpufunc.h” and the RTEMS PowerPC “io.h” headers both define static inline "eioeio()"

Re: [PATCH v2] Add mmap

On 16/07/2019 21:47, Vijay Kumar Banerjee wrote: + rv = mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); + assert(rv != MAP_FAILED); + Please change this to: assert(rv == 0); Please add assertions for the flags (PROT*, MAP*) to your mmap handler. -- Sebastian Huber,

Re: Build failed for RTEMS Source Builder

On 16/7/19 10:31 am, Himanshu Sekhar Nayak wrote: > Any idea how to change the path so that RTEMS Source buildeer instead of > looking > at /usr/bin should look at /bin ? The base definition is here .. https://git.rtems.org/rtems-source-builder/tree/source-builder/defaults.mc#n181 but I would

Re: [PATCH] Add mmap

On 17/7/19 12:29 am, Vijay Kumar Banerjee wrote: > --- > freebsd/sys/kern/kern_conf.c | 8 > freebsd/sys/sys/conf.h | 2 +- > rtemsbsd/include/machine/vm.h | 2 ++ > rtemsbsd/sys/fs/devfs/devfs_devs.c | 10 ++ > 4 files changed, 17 insertions(+), 5

[PATCH v2] Add mmap

--- freebsd/sys/kern/kern_conf.c | 8 freebsd/sys/sys/conf.h | 2 +- rtemsbsd/include/machine/vm.h | 2 ++ rtemsbsd/sys/fs/devfs/devfs_devs.c | 10 ++ testsuite/cdev01/test_cdev.c | 17 - testsuite/cdev01/test_cdev01.h | 3 ++-

build of libbsd for powerpc fails with error: redefinition of 'eieio'

I have a build failure with the MVME5500 “beatnik” BSP. Therefore I tried to build the “psim” BSP and have the same failure: the FreeBSD PowerPC “cpufunc.h” and the RTEMS PowerPC “io.h” headers both define static inline "eioeio()" functions. - RTEMS, libbsd, RSB and the build tools are

[PATCH] Add mmap in libbsd

Hello, The following patch adds d_mmap_t to the cdevsw through a wrapper devfs_imfs_mmap to connect the RTEMS mmap to the respective driver mmap in the libbsd drivers. This patch DOES NOT have a devfs test included and hence is NOT mergeable as of now. This is a preview patch and the

[PATCH] Add mmap

--- freebsd/sys/kern/kern_conf.c | 8 freebsd/sys/sys/conf.h | 2 +- rtemsbsd/include/machine/vm.h | 2 ++ rtemsbsd/sys/fs/devfs/devfs_devs.c | 10 ++ 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/freebsd/sys/kern/kern_conf.c

Re: GSoC Linux UIO driver for PRU

On 16/07/2019 15:35, Vijay Kumar Banerjee wrote: > > > > On Tue, Jul 16, 2019 at 6:57 PM Nils Hölscher > wrote: > > Thanks I have been able to resolve this. > > But I have run into another issue. > RTEMS port of the character device switch table doesn't

Re: GSoC Linux UIO driver for PRU

On Tue, Jul 16, 2019 at 6:57 PM Nils Hölscher wrote: > Thanks I have been able to resolve this. > > But I have run into another issue. > RTEMS port of the character device switch table doesn't support a .d_mmap > entry. > >

Re: GSoC Linux UIO driver for PRU

Thanks I have been able to resolve this. But I have run into another issue. RTEMS port of the character device switch table doesn't support a .d_mmap entry. https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/sys/conf.h#L199 And I am not certain how

Re: Sources for fenv (ARM, PPC, x86, SPARC and RISC5)

Let's give preference to FreeBSD sources. Notes below. On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta wrote: > Hello, > I have found sources for fenv. > > 1.1) - ARM FreeBSD Source: > - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h > -

Re: GSoC Linux UIO driver for PRU

On Tue, Jul 16, 2019, 6:34 AM Nils Hölscher wrote: > Hi, > > I am currently porting the pruss driver functions, that I want to add in: > rtems_filesystem_file_handlers_r pruss_irq_handler. > But when I add my functions like this: > .open_h = ti_pruss_irq_open > I receive the following

Re: GSoC Linux UIO driver for PRU

Hi, I am currently porting the pruss driver functions, that I want to add in: rtems_filesystem_file_handlers_r pruss_irq_handler. But when I add my functions like this: .open_h = ti_pruss_irq_open I receive the following compiler warnings: ../../pruss.c:156:13: warning: initialization from

Re: GSoC Project | Basic Support for Trace Compass

> > Very good, please change now the format of the event header to the one > used by LTTNG: > > struct event_header_compact { > enum : uint5_t { compact = 0 ... 30, extended = 31 } id; > variant { > struct { > uint27_clock_monotonic_t

Re: GSoC Project | Basic Support for Trace Compass

On 16/07/2019 10:41, Ravindra Kumar Meena wrote: Yes, the values are there, but babeltrace cannot deduce the clock source. In the LTTNG it displays it like this: [17:50:44.093076317] (+0.02071) Okay. The timestamp_begin and timestamp_end member in packet.context are for the

Re: GSoC Project | Basic Support for Trace Compass

> > Yes, the values are there, but babeltrace cannot deduce the clock > source. In the LTTNG it displays it like this: > > [17:50:44.093076317] (+0.02071) > Okay. The timestamp_begin and timestamp_end member in packet.context are for the whole recording process. The timestamp_begin means

Re: GSoC Project | Basic Support for Trace Compass

On 16/07/2019 10:04, Ravindra Kumar Meena wrote: The clock definitions for the timestamps are not right. I loaded the trace with Trace Compass and it shows always the same timestamp. For example in 102-tracing-wget-critical-path/wget-first-call I get this: babeltrace

Re: GSoC Project | Basic Support for Trace Compass

> > The clock definitions for the timestamps are not right. I loaded the > trace with Trace Compass and it shows always the same timestamp. For > example in > > 102-tracing-wget-critical-path/wget-first-call > > I get this: > > babeltrace . | grep sched | head > [17:50:44.093074246] (+?.?)