Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-08 Thread Niteesh G. S. 
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, Sebastian Huber wrote:
> > > On 08/07/2020 08:10, Niteesh G. S. wrote:
> > >
> > >> On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber
> > >>  > 
> > >>  > >> wrote:
> > >>
> > >> Hello,
> > >>
> > >> the problem is that the new build system doesn't export
> > optimization
> > >> flags such as -Wl,--gc-sections. The libbsd build should
> > enable this
> > >> linker option unconditionally.
> > >>
> > >>
> > >> Thank you. I got it fixed (temporarily) by modifying rtems.py.
> > >>
> > >> conf.env.CFLAGS= cflags['cflags'] + ['-ffunction-sections'] +
> > >> ['-fdata-sections']
> > > This instructs the compiler to add data elements and functions into
> > > separate sections. This is necessary so that the linker can carry
> out
> > > the garbage collection.
> >
> > There is an unused function in libbsd that can't link because a
> function
> > it calls isn't there. Till now the two flags had been provided by the
> > BSP. It seems that now they are not provided anymore.
> >
> > The problematic function is m_unmappedtouio in uipc_mbuf.c. It tries
> to
> > use PHYS_TO_VM_PAGE which isn't defined in libbsd. I think we should
> > just remove m_unmappedtouio (with #ifndef __rtems__) on the longer
> term.
> > But not having the -ffunction-sections and -fdata-sections most
> likely
> > makes our binary bigger and maybe leads to other similar bugs.
> Therefore
> > I suggested to add the CFLAGS first.
> >
> > >>
> > >> As per Christian suggestions, I tried exporting CFLAGS with these
> GCC
> > >> flags and then calling ./waf configure but they didn't work.
> > > You have to add -Wl,--gc-sections to the linker flags.
> >
> > As far as I know Niteesh used that one too. I think for that one
> LDFLAGS
> > worked as a workarround.
> >
> >
> > Yes, I did try exporting LDFLAGS too but they also didn't work out.
> > I tried the following:
> > 1) export LDFLAGS="-Wl,--gc-sections"
> > 2) ./waf configure --prefix=$RTEMS/6 --rtems-version=6
> > --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini
> > I also tried running
> > 1) LDFLAGS="-Wl,--gc-sections" ./waf configure --prefix=$RTEMS/6
> > --rtems-version=6 --rtems-bsps=arm/beagleboneblack
> > --buildset=buildset/minimal.ini
> > Both of them didn't work out.
>
> Have the flags been ignored and not used or did that not fix the
> problem? I would assume the second. You should see the difference if you
> call "./waf -v" and take a look at one of the linker calls to generate
> the test applications.
>

Yes, it is the second case. The linker flags are being used but it doesn't
fix the problem.
I used the following commands to ensure this.
1) export LDFLAGS="-Wl,--gc-sections"
2) ./waf configure --prefix=$RTEMS/6 --rtems-version=6
--rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini
3) ./waf -j1 -v
On using the above commands I get the following output
['/home/niteesh/development/rtems/6/bin/arm-rtems6-gcc', '-qrtems',
'-B/home/niteesh/development/rtems/6/arm-rtems6/beagleboneblack/lib',
'-mcpu=cortex-a8', '-MMD', 'testsuite/arphole/test_main.c.45.o',
'-o/home/niteesh/development/rtems/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/arphole.exe',
'-Wl,-Bstatic', '-L.', '-lbsd', '-Wl,-Bdynamic', '-lbsd', '-lm', '-lz',
'-lrtemstest',* '-Wl,--gc-sections'*]

I then tried unsetting the LDFLAGS
1) unset LDFLAGS
2) ./waf configure --prefix=$RTEMS/6 --rtems-version=6
--rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini
3) ./waf -j1 -v
Using the above commands give the following output
['/home/niteesh/development/rtems/6/bin/arm-rtems6-gcc', '-qrtems',
'-B/home/niteesh/development/rtems/6/arm-rtems6/beagleboneblack/lib',
'-mcpu=cortex-a8', '-MMD', 'testsuite/arphole/test_main.c.45.o',
'-o/home/niteesh/development/rtems/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/arphole.exe',
'-Wl,-Bstatic', '-L.', '-lbsd', '-Wl,-Bdynamic', '-lbsd', '-lm', '-lz',
'-lrtemstest']

If this help,
With the LDFLAGS set already, ./waf configure doesn't mention that is
already defined
but when the CFLAGS are set, for eg: export CFLAGS="-ffunction-sections"
./waf configure mentions that CFLAGS is already been set

Pasting the ./waf configure output
//
Setting top to   :
/home/niteesh/development/rtems/rtems-libbsd

Setting out to   :
/home/niteesh/development/rtems/rtems-libbsd/build

Environme

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-08 Thread Sebastian Huber 

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 configured with the following options:
1) ./waf bsp_defaults --rtems-bsps=arm/beagleboneblack > config.ini
2) Enabled posix since libBSD complained about it during configuration.
3) ./waf configure --prefix=$HOME/development/rtems/6
4) ./waf -j32


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':
/home/EB/sebastian_h/src/rtems/build/arm/beagleboneblack/../../../bsps/arm/beagle/i2c/bbb-i2c.c:202: 
undefined reference to `__wrap_puts'

collect2: error: ld returned 1 exit status

This error is related to this change:

https://git.rtems.org/sebh/rtems.git/commit/?h=build&id=9e3a23e4dde96fca2fc5855995527e10a4a119cb

I guess I made this during the work to get rid of the bsp_specs. The 
problem is that we have a cyclic reference: librtemstest depends on 
librtemscpu which depends on librtemstest (via the wrapped output 
functions). The librtemscpu and librtemsbsp are implicitly given at the 
end via the -qrtems flag. I reverted the change since it seems to work 
without it. Afterwards, I was able to install the BSP.



5) ./waf install

RTEMS-libBSD was configured with the following options:
1) ./waf configure --prefix=$HOME/development/rtems/6 
--rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini 
--rtems-version=6

2) ./waf -j16
I have attached the error log file.


I got a different error:

[1163/1163] Linking build/arm-rtems6-beagleboneblack-minimal/zerocopy01.exe
/opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: 
testsuite/zerocopy01/test_main.c.96.o: in function `.LANCHOR0':
/home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../rtemsbsd/include/machine/rtems-bsd-config.h:238: 
undefined reference to `_bsd_ip6_mroutemodule_sys_init'


I fixed this with this commit:

https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12&id=26866d2c1f2432b25b5db71995bce2035187c715

Which branch do you use for libbsd?

It seems the master branch. Here I get also your error:

[1084/1184] Linking build/arm-rtems6-beagleboneblack-minimal/condvar01.exe
/opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: 
./libbsd.a(uipc_mbuf.c.16.o): in function `m_unmappedtouio':
/home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1813: 
undefined reference to `PHYS_TO_VM_PAGE'
/opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: 
/home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1814: 
undefined reference to `uiomove_fromphys'


Could you please use the 5-freebsd-12 branch with the default build set. 
This is what I use normally.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-08 Thread Christian Mauderer 
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 branch
>> HEAD: e4c193ddc163d6adb1b003254af9cc6b5d174a6f
>>
>> RTEMS was configured with the following options:
>> 1) ./waf bsp_defaults --rtems-bsps=arm/beagleboneblack > config.ini
>> 2) Enabled posix since libBSD complained about it during configuration.
>> 3) ./waf configure --prefix=$HOME/development/rtems/6
>> 4) ./waf -j32
> 
> 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':
> /home/EB/sebastian_h/src/rtems/build/arm/beagleboneblack/../../../bsps/arm/beagle/i2c/bbb-i2c.c:202:
> undefined reference to `__wrap_puts'
> collect2: error: ld returned 1 exit status
> 

That's another problem: There is a puts in the bbb-i2c that maybe should
be a printk instead. Haven't found the time yet to post a patch. I'll
send one in a few minutes.

> This error is related to this change:
> 
> https://git.rtems.org/sebh/rtems.git/commit/?h=build&id=9e3a23e4dde96fca2fc5855995527e10a4a119cb
> 
> 
> I guess I made this during the work to get rid of the bsp_specs. The
> problem is that we have a cyclic reference: librtemstest depends on
> librtemscpu which depends on librtemstest (via the wrapped output
> functions). The librtemscpu and librtemsbsp are implicitly given at the
> end via the -qrtems flag. I reverted the change since it seems to work
> without it. Afterwards, I was able to install the BSP.
> 
>> 5) ./waf install
>>
>> RTEMS-libBSD was configured with the following options:
>> 1) ./waf configure --prefix=$HOME/development/rtems/6
>> --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini
>> --rtems-version=6
>> 2) ./waf -j16
>> I have attached the error log file.
> 
> I got a different error:
> 
> [1163/1163] Linking build/arm-rtems6-beagleboneblack-minimal/zerocopy01.exe
> /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld:
> testsuite/zerocopy01/test_main.c.96.o: in function `.LANCHOR0':
> /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../rtemsbsd/include/machine/rtems-bsd-config.h:238:
> undefined reference to `_bsd_ip6_mroutemodule_sys_init'
> 
> I fixed this with this commit:
> 
> https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12&id=26866d2c1f2432b25b5db71995bce2035187c715
> 
> 
> Which branch do you use for libbsd?
> 
> It seems the master branch. Here I get also your error:
> 
> [1084/1184] Linking build/arm-rtems6-beagleboneblack-minimal/condvar01.exe
> /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld:
> ./libbsd.a(uipc_mbuf.c.16.o): in function `m_unmappedtouio':
> /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1813:
> undefined reference to `PHYS_TO_VM_PAGE'
> /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld:
> /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1814:
> undefined reference to `uiomove_fromphys'
> 
> Could you please use the 5-freebsd-12 branch with the default build set.
> This is what I use normally.
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-08 Thread Sebastian Huber 

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':
/home/EB/sebastian_h/src/rtems/build/arm/beagleboneblack/../../../bsps/arm/beagle/i2c/bbb-i2c.c:202:
undefined reference to `__wrap_puts'
collect2: error: ld returned 1 exit status


That's another problem: There is a puts in the bbb-i2c that maybe should
be a printk instead. Haven't found the time yet to post a patch. I'll
send one in a few minutes.

I would remove the debug output.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-07-08 Thread Christian Mauderer 
---
 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 int am335x_i2c_reset( bbb_i2c_bus *bus )
   }
 
   if ( timeout <= 0 ) {
-puts( "ERROR: Timeout in soft-reset\n" );
+debug_print( "ERROR: Timeout in soft-reset\n" );
 return ETIMEDOUT;
   }
 
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-08 Thread Niteesh G. S. 
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
> >
> > The new build system is pulled from Sebastian's branch
> > HEAD: e4c193ddc163d6adb1b003254af9cc6b5d174a6f
> >
> > RTEMS was configured with the following options:
> > 1) ./waf bsp_defaults --rtems-bsps=arm/beagleboneblack > config.ini
> > 2) Enabled posix since libBSD complained about it during configuration.
> > 3) ./waf configure --prefix=$HOME/development/rtems/6
> > 4) ./waf -j32
>
> 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':
> /home/EB/sebastian_h/src/rtems/build/arm/beagleboneblack/../../../bsps/arm/beagle/i2c/bbb-i2c.c:202:
>
> undefined reference to `__wrap_puts'
> collect2: error: ld returned 1 exit status
>

I also got this error when I first tried out the new build system.
Christian suggested to comment it out temporarily.


> This error is related to this change:
>
>
> https://git.rtems.org/sebh/rtems.git/commit/?h=build&id=9e3a23e4dde96fca2fc5855995527e10a4a119cb
>
> I guess I made this during the work to get rid of the bsp_specs. The
> problem is that we have a cyclic reference: librtemstest depends on
> librtemscpu which depends on librtemstest (via the wrapped output
> functions). The librtemscpu and librtemsbsp are implicitly given at the
> end via the -qrtems flag. I reverted the change since it seems to work
> without it. Afterwards, I was able to install the BSP.
>
> > 5) ./waf install
> >
> > RTEMS-libBSD was configured with the following options:
> > 1) ./waf configure --prefix=$HOME/development/rtems/6
> > --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini
> > --rtems-version=6
> > 2) ./waf -j16
> > I have attached the error log file.
>
> I got a different error:
>
> [1163/1163] Linking build/arm-rtems6-beagleboneblack-minimal/zerocopy01.exe
> /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld:
> testsuite/zerocopy01/test_main.c.96.o: in function `.LANCHOR0':
> /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../rtemsbsd/include/machine/rtems-bsd-config.h:238:
>
> undefined reference to `_bsd_ip6_mroutemodule_sys_init'
>
> I fixed this with this commit:
>
>
> https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12&id=26866d2c1f2432b25b5db71995bce2035187c715
>
> Which branch do you use for libbsd?
>

I use the master branch: 6da0dda3255e2a49365aee6904fe00d4f2ca9d68


> It seems the master branch. Here I get also your error:
>
> [1084/1184] Linking build/arm-rtems6-beagleboneblack-minimal/condvar01.exe
> /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld:
> ./libbsd.a(uipc_mbuf.c.16.o): in function `m_unmappedtouio':
> /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1813:
>
> undefined reference to `PHYS_TO_VM_PAGE'
> /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld:
> /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1814:
>
> undefined reference to `uiomove_fromphys'
>
> 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 the output
file.
Dependency 
/home/niteesh/development/rtems/rtems-libbsd/freebsd/sys/sys/_eventhandler.h for
{task 139787987585736: c musb_otg.c -> musb_otg.c.16.o} is missing: 
check the task declaration and the build order!
Waf: Leaving directory 
`/home/niteesh/development/rtems/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal'
Build failed
Traceback (most recent call last):
  File 
"/home/niteesh/development/rtems/rtems-libbsd/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Node.py",
 line 463, in get_bld_sig
ret=cache[self]
KeyError: 
/home/niteesh/development/rtems/rtems-libbsd/freebsd/sys/sys/_eventhandler.h

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/home/niteesh/development/rtems/rtems-libbsd/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Runner.py",
 line 255, in task_status
return tsk.runnable_status()
  File 
"/home/niteesh/development/rtems/rtems-libbsd/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py",
 line 372, in runnable_status
new_sig=self.signature()
  File 
"/home/niteesh/development/rtems/rtems-libbsd/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py",
 line 357, in signature
self.sig_i

[PATCH] build: Ensure mandatory compiler/linker flags

2020-07-08 Thread Sebastian Huber 
---
 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_flags):
+for flag in addional_flags:
+if flag not in current_flags:
+current_flags.append(flag)
+
 #
 # The waf builder for libbsd.
 #
@@ -168,6 +173,10 @@ class Builder(builder.ModuleManager):
   mandatory = False)
 else:
 bld.fatal('invalid config test: %s' % (configTest))
+section_flags = ["-fdata-sections", "-ffunction-sections"]
+_add_flags_if_not_present(conf.env.CFLAGS, section_flags)
+_add_flags_if_not_present(conf.env.CXXFLAGS, section_flags)
+_add_flags_if_not_present(conf.env.LINKFLAGS, 
["-Wl,--gc-sections"])
 
 
 def build(self, bld):
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-08 Thread Sebastian Huber 

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 the 
output file.


Did you delete the build tree before you changed the build set?

This patch should fix the build issues on the master branch with the new 
build system:


https://lists.rtems.org/pipermail/devel/2020-July/060530.html

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-08 Thread Niteesh G. S. 
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 libbsd on 5-freebsd-12 branch with the default
> > build set
> > though using minimal build set doesn't work. I have attached the
> > output file.
>
> Did you delete the build tree before you changed the build set?
>

It works after deleting the build tree. May I please know why ./waf clean
doesn't work.

This patch should fix the build issues on the master branch with the new
> build system:
>
> https://lists.rtems.org/pipermail/devel/2020-July/060530.html

Thank you for the patch. I applied it locally and it works.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-07-08 Thread Sebastian Huber 
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/rtemsbsd/nfsclient/nfs.c b/rtemsbsd/nfsclient/nfs.c
index d6f43305..fa5409c9 100644
--- a/rtemsbsd/nfsclient/nfs.c
+++ b/rtemsbsd/nfsclient/nfs.c
@@ -397,84 +397,48 @@ DirInfo   dip;
 
 /* Macro for accessing serporid fields
  */
-#define SERP_ARGS(node) ((node)->serporid.serporid_u.serporid.arg_u)
-#define SERP_ATTR(node) ((node)->serporid.serporid_u.serporid.attributes)
-#define SERP_FILE(node) ((node)->serporid.serporid_u.serporid.file)
-
-/*
- * FIXME: The use of the serporid structure with several embedded unions to
- * split up the specific NFS request/response structures is quite a hack.  It
- * breaks on 64-bit targets due to the presence of pointer members which affect
- * the overall alignment.  Use a packed serporidok structure to hopefully fix
- * this issue.
- */
+#define SERP_ARGS(node) ((node)->serporid.serporid)
+#define SERP_ATTR(node) ((node)->serporid.serporid.attributes)
+#define SERP_FILE(node) ((node)->serporid.serporid.file)
 
 typedef struct serporidok {
fattr   attributes;
-   nfs_fh  file;
union   {
-   struct {
-   filenamename;
-   }   diroparg;
-   struct {
-   sattr   attributes;
-   }   sattrarg;
-   struct {
-   uint32_toffset;
-   uint32_tcount;
-   uint32_ttotalcount;
-   }   readarg;
-   struct {
-   uint32_tbeginoffset;
-   uint32_toffset;
-   uint32_ttotalcount;
-   struct {
-   uint32_t data_len;
-   char* data_val;
-   }   data;
-   }   writearg;
-   struct {
-   filenamename;
-   sattr   attributes;
-   }   createarg;
-   struct {
-   filenamename;
-   diropargs   to;
-   }   renamearg;
-   struct {
-   diropargs   to;
-   }   linkarg;
-   struct {
-   filenamename;
-   nfspath to;
-   sattr   attributes;
-   }   symlinkarg;
-   struct {
-   nfscookie   cookie;
-   uint32_tcount;
-   }   readdirarg;
-   }   arg_u;
-} RTEMS_PACKED serporidok;
+   nfs_fh  file;
+   diropargs   diroparg;
+   sattrargs   sattrarg;
+   readargsreadarg;
+   writeargs   writearg;
+   createargs  createarg;
+   renameargs  renamearg;
+   linkargslinkarg;
+   symlinkargs symlinkarg;
+   readdirargs readdirarg;
+   };
+} serporidok;
 
+/*
+ * The nfsstat is an enum, so has an integer alignment.  The serporid contains
+ * pointers, so has at least a pointer alignment.  The packed attribute ensures
+ * that there is no gap between the status and serporid members on 64-bit
+ * targets.
+ */
 typedef struct serporid {
nfsstat status;
-   union   {
-   serporidok  serporid;
-   }   serporid_u;
-} serporid;
+   serporidok  serporid;
+} RTEMS_PACKED serporid;
 
 /* an XDR routine to encode/decode the inverted diropres
  * into an nfsnodestat;
  *
- * NOTE: this routine only acts on
+ * NOTE: this routine only acts on:
  *   - 'serporid.status'
  *   - 'serporid.file'
  *   - 'serporid.attributes'
- * and leaves the 'arg_u' alone.
  *
  * The idea is that a 'diropres' is read into 'serporid'
  * which can then be used as an argument to subsequent
- * NFS-RPCs (after filling in the node's arg_u).
+ * NFS-RPCs (after filling in the

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

2020-07-08 Thread Chris Johns 
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..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_flags):
> +for flag in addional_flags:
> +if flag not in current_flags:
> +current_flags.append(flag)
> +
>  #
>  # The waf builder for libbsd.
>  #
> @@ -168,6 +173,10 @@ class Builder(builder.ModuleManager):
>mandatory = False)
>  else:
>  bld.fatal('invalid config test: %s' % (configTest))
> +section_flags = ["-fdata-sections", "-ffunction-sections"]
> +_add_flags_if_not_present(conf.env.CFLAGS, section_flags)
> +_add_flags_if_not_present(conf.env.CXXFLAGS, section_flags)
> +_add_flags_if_not_present(conf.env.LINKFLAGS, 
> ["-Wl,--gc-sections"])
>  
>  
>  def build(self, bld):
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-07-08 Thread Sebastian Huber 

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 flags in the new build system.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Converting stack address to shared-memory object name

2020-07-08 Thread Utkarsh Rai 
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 is,
shm_open() takes the path-name of the shared memory object. Since this is a
high-level API, how does the user 'convert' the stack address to a shared
memory object name?

Dr.Gedare mentioned that one way to deal with naming would be something
like Mr.Sebastian has been doing with specifications. From what I could
gather, it is a hierarchical way of representing objects(Though, I am not
very sure if  I understand this accurately). How can something like this be
implemented for naming stack-addresses?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Converting stack address to shared-memory object name

2020-07-08 Thread Sebastian Huber 

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 address space of the current stack. My doubt is, 
shm_open() takes the path-name of the shared memory object. Since this 
is a high-level API, how does the user 'convert' the stack address to 
a shared memory object name?
Do we need any POSIX compatibility for this? What would you do in a 
POSIX environment? You first get some memory, then hand it over to 
shm_open() to get a file descriptor, then use the file descriptor in 
mmap(), then use this for pthread_attr_setstack() and whatever?


Dr.Gedare mentioned that one way to deal with naming would be 
something like Mr.Sebastian has been doing with specifications. From 
what I could gather, it is a hierarchical way of representing 
objects(Though, I am not very sure if  I understand this accurately). 
How can something like this be implemented for naming stack-addresses?

I am not sure if the specification of RTEMS is helpful in this context.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Converting stack address to shared-memory object name

2020-07-08 Thread Gedare Bloom 
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 object of the stack to be shared through shm_open and
> > then mmap that to the address space of the current stack. My doubt is,
> > shm_open() takes the path-name of the shared memory object. Since this
> > is a high-level API, how does the user 'convert' the stack address to
> > a shared memory object name?
> Do we need any POSIX compatibility for this? What would you do in a
> POSIX environment? You first get some memory, then hand it over to
> shm_open() to get a file descriptor, then use the file descriptor in
> mmap(), then use this for pthread_attr_setstack() and whatever?

Yes, but the way to name objects is not set by posix.

We need to provide our own way of translating an address into a name.

> >
> > Dr.Gedare mentioned that one way to deal with naming would be
> > something like Mr.Sebastian has been doing with specifications. From
> > what I could gather, it is a hierarchical way of representing
> > objects(Though, I am not very sure if  I understand this accurately).
> > How can something like this be implemented for naming stack-addresses?
> I am not sure if the specification of RTEMS is helpful in this context.

I should have provided a little bit more guidance. I was thinking out
loud in yesterday's IRC meeting. My thought was more along the lines
of looking at how UIDs/naming should be done, and that specs had to
solve a naming problem. However the static nature of specs is not a
great fit to this problem.

Actually, what is a good model would be something like /proc or
Linux's sysfs. An IMFS filesystem that exports task information could
be used to name memory regions. (It could eventually supplant
task-based statistics reporting too.)

Another idea I had though, which seems to have been lost in the
shuffle, is to look at how the object names work in RTEMS and see if
we can add some fixed relationships, e.g., task_name # stack.

I think we should start by just treating the entire task stack as a
single named object; either it is all shared, or none of it is shared.
This will be easier to implement and also more widely supported by
simpler MPU/MMU hardware. Later on, we can consider extending the
namespace with 'offsets' /taskfs/IDLE/stack/0A28
could be a location at byte A28 offset from the start of the stack of
the IDLE task.

Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-07-08 Thread Mritunjay Sharma 
[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
directory
 #include 
  ^
compilation terminated.
/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_BUILD:234:
recipe for target 'rtems_init.o' failed
make[4]: *** [rtems_init.o] Error 1
make[4]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS/O.RTEMS-pc386'
/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_ARCHS:58:
recipe for target 'install.RTEMS-pc386' failed
make[3]: *** [install.RTEMS-pc386] Error 2
make[3]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS'
/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_DIRS:84:
recipe for target 'RTEMS.install' failed
make[2]: *** [RTEMS.install] Error 2
make[2]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom'
../configure/RULES_DIRS:84: recipe for target 'libcom.install' failed
make[1]: *** [libcom.install] Error 2
make[1]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules'
configure/RULES_DIRS:84: recipe for target 'modules.install' failed
make: *** [modules.install] Error 2"

Today's update is that I tried to fix the above error however I still have
not been able to clear it.
If anyone has idea, please do tell what can be done.

Thanks
Mritunjay

On Wed, Jul 8, 2020 at 1:12 AM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

>
>
> --
> *From:* Heinz Junkes 
> *Sent:* Wednesday, July 8, 2020 1:05 AM
> *To:* Mritunjay Sharma
> *Cc:* Gedare Bloom; Joel Sherrill; Chris Johns; RTEMS Devel
> *Subject:* Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
>
> I’m away from my keyboard. If you use the epics Adaption to rtems from my
> github “playground?” and bsp’s with —enable-networks should compile.
> Heinz
>
> FHI, Heinz Junkes
>
> Thank you Heinz, I was doing the same. I went to your GitHub and am
> experimenting with "playground" right now.
>
> Thanks,
> Mritunjay
>
> On 7. Jul 2020, at 18:14, Mritunjay Sharma 
> wrote:
>
> 
> [UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu.
> Everything worked fine while building the pc-386 with  RTEMS5.
>
> After this when I entered epics-base and made the following change:
>
> epics-base/os/CONFIG_SITE.Common.RTEMS
> RTEMS_VERSION = 5
> RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
>
> As an experiment, I ran the make and as expected got the following error
>
> Error:
>
> ```...de/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include
> -c ../rtems_init.c
> ../rtems_init.c:21:10: fatal error: sys/termios.h: No such file or
> directory
>  #include 
>   ^~~
> compilation terminated.
> ../../../../configure/RULES_BUILD:240: recipe for target 'rtems_init.o'
> failed
> make[4]: *** [rtems_init.o] Error 1
> make[4]: Leaving directory
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS/O.RTEMS-pc386'
> ../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386'
> failed
> make[3]: *** [install.RTEMS-pc386] Error 2
> make[3]: Leaving directory
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS'
> ../../configure/RULES_DIRS:85: recipe for target 'RTEMS.install' failed
> make[2]: *** [RTEMS.install] Error 2
> make[2]: Leaving directory
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom'
> ../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
> make[1]: *** [libcom.install] Error 2
> make[1]: Leaving directory
> '/home/mritunjay/development/EPICS/epics-base/modules'
> configure/RULES_DIRS:85: recipe for target 'modules.install' failed
> make: *** [modules.install] Error 2
> ```
>
> I am trying to figure out the error and making the changes in code to
> debug it.
> However, I will appreciate if Heinz and everyone else can help me a
> little, if they have an
> idea of this error.
>
> Thanks
> Mritunjay
>
> On Tue, Jul 7, 2020 at 7:30 PM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jul 7, 2020 at 5:33 AM Gedare Bloom  wrote:
>>
>>> On Mon, Jul 6, 2020 at 5:49 PM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Jul 6, 2020, 6:14 PM Gedare Bloom  wrote:
>>> >>
>>> >> On Mon, Jul 6, 2020 at 10:12 AM Mritunjay Sharma
>>> >>  wrote:
>>> >> >
>>> >> > Hello everyone,
>>> >> >
>>> >> > Thank you, Heinz, Gedare, Chris and Joel for your advice.
>>> >> > If there are issues in making a buildset for 4.10
>>> >> > then should I build EPICS with RTEMS 5 by hand first and note
>>> >> > down the process and then proceed to make the buildset for it?
>>> >> >
>>>

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

2020-07-08 Thread Mritunjay Sharma 
[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/RULES_BUILD:206:
recipe for target 'libComTestHarness' failed
make[4]: *** [libComTestHarness] Error 1
make[4]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/test/O.RTEMS-pc386'
/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_ARCHS:58:
recipe for target 'install.RTEMS-pc386' failed
make[3]: *** [install.RTEMS-pc386] Error 2
make[3]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/test'
/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_DIRS:84:
recipe for target 'test.install' failed
make[2]: *** [test.install] Error 2
make[2]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom'
../configure/RULES_DIRS:84: recipe for target 'libcom.install' failed
make[1]: *** [libcom.install] Error 2
make[1]: Leaving directory
'/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules'
configure/RULES_DIRS:84: recipe for target 'modules.install' failed
make: *** [modules.install] Error 2```


This is what change i did:

```diff --git a/modules/libcom/RTEMS/posix/rtems_config.c
b/modules/libcom/RTEMS/posix/rtems_config.c
index b02c94a6b..ce1390cdc 100644
--- a/modules/libcom/RTEMS/posix/rtems_config.c
+++ b/modules/libcom/RTEMS/posix/rtems_config.c
@@ -89,7 +89,7 @@ extern void *POSIX_Init(void *argument);

 //#define RTEMS_BSD_CONFIG_SERVICE_TELNETD

-#include 
+//#include 

 #define RTEMS_PCI_CONFIG_LIB
 #define CONFIGURE_PCI_LIB PCI_LIB_AUTO
diff --git a/modules/libcom/RTEMS/posix/rtems_init.c
b/modules/libcom/RTEMS/posix/rtems_init.c
index efd0b4518..90faccf78 100644
--- a/modules/libcom/RTEMS/posix/rtems_init.c
+++ b/modules/libcom/RTEMS/posix/rtems_init.c
@@ -35,8 +35,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+//#include 
+//#include 
 #include 
 #include 
 ```
Hope it can help with debugging errors.
Thanks,
Mritunjay

On Thu, Jul 9, 2020 at 12:03 AM Mritunjay Sharma <
mritunjaysharma...@gmail.com> 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:
>
> "../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file
> or directory
>  #include 
>   ^
> compilation terminated.
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_BUILD:234:
> recipe for target 'rtems_init.o' failed
> make[4]: *** [rtems_init.o] Error 1
> make[4]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS/O.RTEMS-pc386'
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_ARCHS:58:
> recipe for target 'install.RTEMS-pc386' failed
> make[3]: *** [install.RTEMS-pc386] Error 2
> make[3]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS'
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_DIRS:84:
> recipe for target 'RTEMS.install' failed
> make[2]: *** [RTEMS.install] Error 2
> make[2]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom'
> ../configure/RULES_DIRS:84: recipe for target 'libcom.install' failed
> make[1]: *** [libcom.install] Error 2
> make[1]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules'
> configure/RULES_DIRS:84: recipe for target 'modules.install' failed
> make: *** [modules.install] Error 2"
>
> Today's update is that I tried to fix the above error however I still have
> not been able to clear it.
> If anyone has idea, please do tell what can be done.
>
> Thanks
> Mritunjay
>
> On Wed, Jul 8, 2020 at 1:12 AM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
>
>>
>>
>> --
>> *From:* Heinz Junkes 
>> *Sent:* Wednesday, July 8, 2020 1:05 AM
>> *To:* Mritunjay Sharma
>> *Cc:* Gedare Bloom; Joel Sherrill; Chris Johns; RTEMS Devel
>> *Subject:* Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
>>
>> I’m away from my keyboard. If you use the epics Adaption to rtems from my
>> github “playground?” and bsp’s with —enable-networks should compile.
>> Heinz
>>
>> FHI, Heinz Junkes
>>
>> Thank you Heinz, I was doing the same. I went to your GitHub and am
>> experimenting with "playground" right now.
>>
>> Thanks,
>> Mritunjay
>>
>> On 7. Jul 2020, at 18:14, Mritunjay Sharma 
>> wrote:
>>
>> 
>> [UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu.
>> Everything worked fine while building the pc-386 with  RTEMS5.
>>
>> After this wh

GSoC 2020: Implemented FreeBSD structures in RTEMS

2020-07-08 Thread Niteesh G. S. 
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
pattern being followed. So we decided to implement a few structures related
to FreeBSD into RTEMS which will help in reducing the porting work required.

I have also written about this in my blog. I have compared the work needed
to
port with and without these structures implemented.
Please have a look:
https://gs-niteesh.github.io/#making-freebsd-import-easy-in-rtems-june-17-2020

https://github.com/gs-niteesh/rtems/commit/2790c1e3e7eb209bb3c17909ab6e5b469cdeb4b0
Please have a look at the above commit.

The functions implemented are a simpler version of the one implemented in
libBSD
and are no replacement for them.

Thanks,
Niteesh.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-07-08 Thread Gedare Bloom 
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:
>
> "../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file or 
> directory
>  #include 
>   ^

This error indicates it is looking for an installed rtems-libbsd. My
guess is you need to build/install the rtems-libbsd to get this
playground to work.

> compilation terminated.
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_BUILD:234:
>  recipe for target 'rtems_init.o' failed
> make[4]: *** [rtems_init.o] Error 1
> make[4]: Leaving directory 
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS/O.RTEMS-pc386'
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_ARCHS:58:
>  recipe for target 'install.RTEMS-pc386' failed
> make[3]: *** [install.RTEMS-pc386] Error 2
> make[3]: Leaving directory 
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS'
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_DIRS:84:
>  recipe for target 'RTEMS.install' failed
> make[2]: *** [RTEMS.install] Error 2
> make[2]: Leaving directory 
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom'
> ../configure/RULES_DIRS:84: recipe for target 'libcom.install' failed
> make[1]: *** [libcom.install] Error 2
> make[1]: Leaving directory 
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules'
> configure/RULES_DIRS:84: recipe for target 'modules.install' failed
> make: *** [modules.install] Error 2"
>
> Today's update is that I tried to fix the above error however I still have 
> not been able to clear it.
> If anyone has idea, please do tell what can be done.
>
> Thanks
> Mritunjay
>
> On Wed, Jul 8, 2020 at 1:12 AM Mritunjay Sharma 
>  wrote:
>>
>>
>>
>> 
>> From: Heinz Junkes 
>> Sent: Wednesday, July 8, 2020 1:05 AM
>> To: Mritunjay Sharma
>> Cc: Gedare Bloom; Joel Sherrill; Chris Johns; RTEMS Devel
>> Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
>>
>> I’m away from my keyboard. If you use the epics Adaption to rtems from my 
>> github “playground?” and bsp’s with —enable-networks should compile.
>> Heinz
>>
>> FHI, Heinz Junkes
>>
>> Thank you Heinz, I was doing the same. I went to your GitHub and am 
>> experimenting with "playground" right now.
>>
>> Thanks,
>> Mritunjay
>>
>> On 7. Jul 2020, at 18:14, Mritunjay Sharma  
>> wrote:
>>
>> 
>> [UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu.
>> Everything worked fine while building the pc-386 with  RTEMS5.
>>
>> After this when I entered epics-base and made the following change:
>>
>> epics-base/os/CONFIG_SITE.Common.RTEMS
>> RTEMS_VERSION = 5
>> RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
>>
>> As an experiment, I ran the make and as expected got the following error
>>
>> Error:
>>
>> ```...de/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include   
>>   -c ../rtems_init.c
>> ../rtems_init.c:21:10: fatal error: sys/termios.h: No such file or directory
>>  #include 
>>   ^~~
>> compilation terminated.
>> ../../../../configure/RULES_BUILD:240: recipe for target 'rtems_init.o' 
>> failed
>> make[4]: *** [rtems_init.o] Error 1
>> make[4]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS/O.RTEMS-pc386'
>> ../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386' 
>> failed
>> make[3]: *** [install.RTEMS-pc386] Error 2
>> make[3]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS'
>> ../../configure/RULES_DIRS:85: recipe for target 'RTEMS.install' failed
>> make[2]: *** [RTEMS.install] Error 2
>> make[2]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epics-base/modules/libcom'
>> ../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
>> make[1]: *** [libcom.install] Error 2
>> make[1]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epics-base/modules'
>> configure/RULES_DIRS:85: recipe for target 'modules.install' failed
>> make: *** [modules.install] Error 2
>> ```
>>
>> I am trying to figure out the error and making the changes in code to debug 
>> it.
>> However, I will appreciate if Heinz and everyone else can help me a little, 
>> if they have an
>> idea of this error.
>>
>> Thanks
>> Mritunjay
>>
>> On Tue, Jul 7, 2020 at 7:30 PM Mritunjay Sharma 
>>  wrote:
>>>
>>>
>>>
>>> On Tue, Jul 7, 2020 at 5:33 AM Gedare Bloom  wrote:

 On Mon, Jul 6, 2020 at 5:49 PM Joel Sherrill  wrote:
 >
 >
 >
 > On Mon, Jul 6, 2020, 6:14 PM Gedare Bloom  wrote:
 >>
 >> On Mon, Jul 6, 2020 at 10:12 AM Mritunjay Sharma
>>

Re: Converting stack address to shared-memory object name

2020-07-08 Thread Utkarsh Rai 
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 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 is,
> > > shm_open() takes the path-name of the shared memory object. Since this
> > > is a high-level API, how does the user 'convert' the stack address to
> > > a shared memory object name?
> > Do we need any POSIX compatibility for this? What would you do in a
> > POSIX environment? You first get some memory, then hand it over to
> > shm_open() to get a file descriptor, then use the file descriptor in
> > mmap(), then use this for pthread_attr_setstack() and whatever?
>
> Yes, but the way to name objects is not set by posix.
>
> We need to provide our own way of translating an address into a name.
>
> > >
> > > Dr.Gedare mentioned that one way to deal with naming would be
> > > something like Mr.Sebastian has been doing with specifications. From
> > > what I could gather, it is a hierarchical way of representing
> > > objects(Though, I am not very sure if  I understand this accurately).
> > > How can something like this be implemented for naming stack-addresses?
> > I am not sure if the specification of RTEMS is helpful in this context.
>
> I should have provided a little bit more guidance. I was thinking out
> loud in yesterday's IRC meeting. My thought was more along the lines
> of looking at how UIDs/naming should be done, and that specs had to
> solve a naming problem. However the static nature of specs is not a
> great fit to this problem.
>
> Actually, what is a good model would be something like /proc or
> Linux's sysfs. An IMFS filesystem that exports task information could
> be used to name memory regions. (It could eventually supplant
> task-based statistics reporting too.)
>
> Another idea I had though, which seems to have been lost in the
> shuffle, is to look at how the object names work in RTEMS and see if
> we can add some fixed relationships, e.g., task_name # stack.
>
> I think we should start by just treating the entire task stack as a
> single named object; either it is all shared, or none of it is shared.
> This will be easier to implement and also more widely supported by
> simpler MPU/MMU hardware. Later on, we can consider extending the
> namespace with 'offsets' /taskfs/IDLE/stack/0A28
> could be a location at byte A28 offset from the start of the stack of
> the IDLE task.
>
>
I have a few questions -

> Users would get the stack address of the stack they want to share
through pthread_attr_getstack(). Now, when they get the address they want
to share, they would pass the appropriate name of this memory-region. What
we have to provide is a mechanism to 'convert' this address to an
appropriate name. Is this the accepted way or the other way round, i.e. the
user passes a name as per a specified convention, and that name is
'converted' to a specific address?

> When you say "treating the entire task stack as a single named object"
does it mean that we assign a single name, say "task_stack" to the complete
stack address space? In that case, how do we deal we the presence of
multiple tasks that are allocated from the same pool of task stack? I
understand that on a simpler MPU/MMU hardware it would make sense to
specify names for each memory section (.txt- "text", .bss - "bss" etc.) but
in this case,  where we are sharing only selected thread-stacks, I suppose
we will have to have a way to handle 'offsets' right from the start?


> Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-07-08 Thread Heinz Junkes 
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 directly varies with equipment ruined.



> On 8. Jul 2020, at 21:44, Gedare Bloom  wrote:
> 
> 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:
>> 
>> "../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file or 
>> directory
>> #include 
>>  ^
> 
> This error indicates it is looking for an installed rtems-libbsd. My
> guess is you need to build/install the rtems-libbsd to get this
> playground to work.
> 
>> compilation terminated.
>> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_BUILD:234:
>>  recipe for target 'rtems_init.o' failed
>> make[4]: *** [rtems_init.o] Error 1
>> make[4]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS/O.RTEMS-pc386'
>> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_ARCHS:58:
>>  recipe for target 'install.RTEMS-pc386' failed
>> make[3]: *** [install.RTEMS-pc386] Error 2
>> make[3]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom/RTEMS'
>> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/RULES_DIRS:84:
>>  recipe for target 'RTEMS.install' failed
>> make[2]: *** [RTEMS.install] Error 2
>> make[2]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/libcom'
>> ../configure/RULES_DIRS:84: recipe for target 'libcom.install' failed
>> make[1]: *** [libcom.install] Error 2
>> make[1]: Leaving directory 
>> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules'
>> configure/RULES_DIRS:84: recipe for target 'modules.install' failed
>> make: *** [modules.install] Error 2"
>> 
>> Today's update is that I tried to fix the above error however I still have 
>> not been able to clear it.
>> If anyone has idea, please do tell what can be done.
>> 
>> Thanks
>> Mritunjay
>> 
>> On Wed, Jul 8, 2020 at 1:12 AM Mritunjay Sharma 
>>  wrote:
>>> 
>>> 
>>> 
>>> 
>>> From: Heinz Junkes 
>>> Sent: Wednesday, July 8, 2020 1:05 AM
>>> To: Mritunjay Sharma
>>> Cc: Gedare Bloom; Joel Sherrill; Chris Johns; RTEMS Devel
>>> Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
>>> 
>>> I’m away from my keyboard. If you use the epics Adaption to rtems from my 
>>> github “playground?” and bsp’s with —enable-networks should compile.
>>> Heinz
>>> 
>>> FHI, Heinz Junkes
>>> 
>>> Thank you Heinz, I was doing the same. I went to your GitHub and am 
>>> experimenting with "playground" right now.
>>> 
>>> Thanks,
>>> Mritunjay
>>> 
>>> On 7. Jul 2020, at 18:14, Mritunjay Sharma  
>>> wrote:
>>> 
>>> 
>>> [UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu.
>>> Everything worked fine while building the pc-386 with  RTEMS5.
>>> 
>>> After this when I entered epics-base and made the following change:
>>> 
>>> epics-base/os/CONFIG_SITE.Common.RTEMS
>>> RTEMS_VERSION = 5
>>> RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
>>> 
>>> As an experiment, I ran the make and as expected got the following error
>>> 
>>> Error:
>>> 
>>> ```...de/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include  
>>>-c ../rtems_init.c
>>> ../rtems_init.c:21:10: fatal error: sys/termios.h: No such file or directory
>>> #include 
>>>  ^~~
>>> compilation terminated.
>>> ../../../../configure/RULES_BUILD:240: recipe for target 'rtems_init.o' 
>>> failed
>>> make[4]: *** [rtems_init.o] Error 1
>>> make[4]: Leaving directory 
>>> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS/O.RTEMS-pc386'
>>> ../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386' 
>>> failed
>>> make[3]: *** [install.RTEMS-pc386] Error 2
>>> make[3]: Leaving directory 
>>> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS'
>>> ../../configure/RULES_DIRS:85: recipe for target 'RTEMS.install' failed
>>> make[2]: *** [RTEMS.install] Error 2
>>> make[2]: Leaving directory 
>>> '/home/mritunjay/development/EPICS/epics-base/modules/libcom'
>>> ../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
>>> make[1]: *** [libcom.install] Error 2
>>> make[1]: Leaving directory 
>>> '/home/mritunjay/development/EPICS/epics-base/modules'
>>> configure/RULES_DIRS:85: recipe for target 'modules.install' failed
>>> make: *** [modules.install] Error 2
>>> ```
>>> 
>>> I am trying to figure out the error and