Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

[Utkarsh Rai]

On Mon, May 18, 2020 at 8:38 PM Gedare Bloom  wrote:

> On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> >
> > On Sat, May 16, 2020 at 9:16 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Sat, May 16, 2020 at 10:14 AM Gedare Bloom  wrote:
> >>>
> >>> Utkarsh,
> >>>
> >>> What do you mean by "This would although mean that we would have page
> tables of  1MB."
> >>>
> >>> Check that you use plain text when inlining a reply, or at least that
> you broke the reply format.
> >>>
> >>> Gedare
> >>>
> >>> On Fri, May 15, 2020, 6:04 PM Utkarsh Rai 
> wrote:
> 
> 
> 
>  On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >
> > Hello Utkarsh Rai,
> >
> > On 13/05/2020 14:30, Utkarsh Rai wrote:
> > > Hello,
> > > My GSoC project,  providing thread stack protection support, has
> to be
> > > a user-configurable feature.
> > > My question is,  what would be the best way to implement this, my
> idea
> > > was to model it based on the existing system configuration
> > > ,
> but
> > > Dr. Gedare pointed out that configuration is undergoing heavy
> changes
> > > and may look completely different in future releases. Kindly
> advise me
> > > as to what would be the best way to proceed.
> > before we start with an implementation. It would be good to define
> what
> > a thread stack protection support is supposed to do.
> 
> 
>  The thread stack protection mechanism will protect against stack
> overflow errors and will completely isolate the thread stacks from each
> other. Sharing of thread stack will be possible only when the user makes
> explicit calls to do so. More details about this can be found in this
> thread.
> >
> > Then there should
> > be a concept for systems with a Memory Protection Unit (MPU) and a
> > concept for systems with a Memory Management Unit (MMU). MMUs may
> > provide normal 4KiB Pages, large Pages (for example 1MiB) or
> something
> > more flexible. We should identify BSPs which should have support for
> > this. For each BSP should be a concept. Then we should think about
> how a
> > user can configure this feature.
> >
> > For memory protection will have a 1:1 VA-PA address translation that
> means a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping
> will ensure we will have to do lesser page table walks.This would although
> mean that we would have page tables of  1MB. I will be first providing the
> support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I
> have a working example I will move on to provide the support for RISC-V.
> which has MPU support.
> >>
> >>
> >> I think Sebastian is asking exactly what I did. What are the processor
> (specific CPU) requirements to support thread stack protection?
> >
> >
> > For thread stack protection the processor should have the option of
> paging along with appropriate 'access bits' setting. Both RISC-V and
> ARMv7-A (the ones that I will be focusing on my project) have the option of
> defining pages of 4KiB size with appropriate access bits.
> >
> >>
> >>
> >> For example, to be effective, I imagine a 1MB granularity might be
> sufficient to protect code versus data/bss. But it is likely insufficient
> to protect thread stacks.
> >>
> >> Similarly, a processor with a limited number of "protection areas"
> would be unsuitable as a basis for implementing thread stack protection.
> Here I am thinking of the PowerPC with a handful of TLB registers. You
> would have to turn on paging.
> >
> >
> > I agree, most of the processors have protection regions between 8 to 16
> and in some cases as less as 4. For stack protection paging with each page
> of size 4KiB, as it is applicable for processors with mpu or mmu and is
> optimal, in the sense that we would have appropriate number and size of
> pages for thread stacks, is the best option.
> >
>
> We should have a clear understanding of the design requirements
> brefore we can make such a statement about "optimal" and "best".
>
> The proposal has some good ideas in it, but I think the project has
> some implied expectations or assumptions, on both your side and from
> mentors/stakeholders. Here are some ideas that should start to hint at
> requirements. Maybe you can propose some design requirements. I'm not
> too good at writing requirements myself, but here goes:
> 1. Memory protection is optional. The default is no memory protection.
> 2. The basic protection isolates the text, rodata, and rwdata from
> each other. There is no notion of task-specific protection domains,
> and tasks should not incur any additional overhead due to this
> protection.
> 3. The advanced protection strongly isolates all tasks' stacks.
> Sharing is done explicitly via POSIX/RTEMS APIs, and the heap and
> executive (kernel/RTEMS) memory are glob

[rtems/rsb]: Adding PTP support to RSB [GSoC 2020]

[Mritunjay Sharma]

Hello everyone,

Starting this thread to discuss and give a detail of my progress in
relation to
my GSoC 2020 project "BSP Buildset for EPICS".

It is to tell that I have worked on adding ptp2 support as suggested by
mentors
The implementation that I found could work was ptp2 daemon and so worked
with
it.

I added these files:
rsb/rtems/config/net/ptpd-2.3-1.cfg
rsb/rtems/config/net/ptpd.bset
rsb/source-builder/config/ptpd-2.1.cfg

I am attaching the .diff file and the bug that I have encountered in the
respective txt file and will like the help of mentors in trying to help me
fix it.

I will also be uploading the files on my GitHub repo as well which can be
accessed from here:
https://github.com/mritunjaysharma394/rtems-source-builder

Thanks,
Mritunjay
RTEMS Tools Project - Source Builder Error Report
 Build: error: building ptpd-2.3.1-sparc-rtems5-1
 Command Line: ../source-builder/sb-set-builder --log=log_sis_net_snmp 
--prefix=/home/mritunjay/development/rtems/5 
--with-tools=/home/mritunjay/development/rtems/5 --host=sparc-rtems5 
--with-rtems-bsp=erc32 net/ptpd
 Python: 2.7.17 (default, Apr 15 2020, 17:20:14) [GCC 7.5.0]
 
git://git.rtems.org/rtems-source-builder.git/origin/96cdedce58e32f07c174966676e8b7e8c6620634
 Linux mritunjay-XPS-15-9570 5.3.0-51-generic #44~18.04.2-Ubuntu SMP Thu Apr 23 
14:27:18 UTC 2020 x86_64
Tail of the build log:
script: 21: SB_CFLAGS="${SB_BUILD_CFLAGS} "
script: 22: SB_CXXFLAGS="${SB_BUILD_CXXFLAGS} "
script: 23: SB_ARCH="sparc"
script: 24: SB_OS="linux"
script: 25: export SB_SOURCE_DIR SB_BUILD_DIR SB_ARCH SB_OS
script: 26: export SB_HOST_CPPFLAGS SB_HOST_CFLAGS SB_HOST_CXXFLAGS 
SB_HOST_LDFLAGS SB_HOST_LIBS
script: 27: export SB_BUILD_CFLAGS SB_BUILD_CXXFLAGS SB_BUILD_LDFLAGS 
SB_BUILD_LIBS
script: 28: export SB_CFLAGS SB_CXXFLAGS
script: 29: # Documentation
script: 30: SB_DOC_DIR="/home/mritunjay/development/rtems/5/share/doc"
script: 31: export SB_DOC_DIR
script: 32: # Packages
script: 33: SB_PACKAGE_NAME="ptpd-2.3.1-sparc-rtems5-1"
script: 34: SB_PACKAGE_BUILDNAME="ptpd-2.3.1-sparc-rtems5-1"
script: 35: SB_PACKAGE_VERSION="2.3.1"
script: 36: SB_PACKAGE_RELEASE="1"
script: 37: export SB_PACKAGE_NAME SB_PACKAGE_VERSION SB_PACKAGE_RELEASE
script: 38: # Build directories
script: 39: export SB_PREFIX
script: 40: 
SB_BUILD_DIR="/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1"
script: 41: 
SB_BUILD_ROOT="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/ptpd-2.3.1-sparc-rtems5-1-1000"
script: 42: 
SB_BUILD_ROOT_BINDIR="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/ptpd-2.3.1-sparc-rtems5-1-1000/${SB_PREFIX_CLEAN}/bin"
script: 43: export SB_BUILD_ROOT SB_BUILD_DIR SB_BUILD_ROOT_BINDIR
script: 44: 
SB_BUILD_CXC_DIR="/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1-cxc"
script: 45: 
SB_BUILD_CXC_ROOT="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/ptpd-2.3.1-sparc-rtems5-1-1000-cxc"
script: 46: 
SB_BUILD_CXC_ROOT_BINDIR="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/ptpd-2.3.1-sparc-rtems5-1-1000-cxc/${SB_PREFIX_CLEAN}/bin"
script: 47: export SB_BUILD_CXC_ROOT SB_BUILD_CXC_DIR SB_BUILD_CXC_ROOT_BINDIR
script: 48: 
SB_TMPROOT="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000/net/ptpd"
script: 49: 
SB_TMPPREFIX="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000/net/ptpd/${SB_PREFIX_CLEAN}"
script: 50: 
SB_TMPBINDIR="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000/net/ptpd/${SB_PREFIX_CLEAN}/bin"
script: 51: export SB_TMPROOT SB_TMPPREFIX SB_TMPBINDIR
script: 52: 
SB_TMPCXCROOT="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000/net/ptpd"
script: 53: 
SB_TMPCXCPREFIX="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000-cxc/net/ptpd/${SB_PREFIX_CLEAN}"
script: 54: 
SB_TMPCXCBINDIR="/home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000-cxc/net/ptpd/${SB_PREFIX_CLEAN}/bin"
script: 55: export SB_TMPCXCROOT SB_TMPCXCPREFIX SB_TMPCXCBINDIR
script: 56: # Extra path support
script: 57: SB_EXTRAPATH="/home/mritunjay/development/rtems/rsb/source-builder"
script: 58: # The compiler flags
script: 59: 
script: 60: 
script: 61: export CFLAGS_FOR_TARGET
script: 62: export CXXFLAGS_FOR_TARGET
script: 63: # Set up the path. Put the CXC path first.
script: 64: if test -n "${SB_TMPBINDIR}" ; then
script: 65:  PATH="${SB_TMPBINDIR}:$PATH"
script: 66: fi
script: 67: if test -n "${SB_TMPCXCBINDIR}" ; then
script: 68:  PATH="${SB_TMPCXCBINDIR}:$PATH"
script: 69: fi
script: 70: if test -n "${SB_EXTRAPATH}" ; then
script: 71:  PATH="${SB_EXTRAPATH}:$PATH"
script: 72: fi
script: 73: PATH="/home/mritunjay/development/rtems/5/bin:$PATH"
script: 74: 
script: 75: export PATH
script: 76: # Default environment set up.
script: 77: LANG=C
script: 78: export LANG
script: 79: unset DISPLAY || :
script: 80: umask 022
script: 81: cd 
"/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1"
script: 82: echo "=> ptpd-2.3.1-sparc-rtems5-1: CLEAN"
scr

Re: Adding fenv support for ARM

[Eshan Dhawan]

Hello
I have encountered a new error
the error is coming from libm/fenv
link to GitHub repository:
https://github.com/eshandhawan51/newlib-cygwin/tree/add_fenv_support

Make file log:
eshan@EDs-pc:~/development/newlib/c-arm-rtems5-newlib$ make -k
make[1]: Entering directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib'
make[2]: Entering directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/etc'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/etc'
Checking multilib configuration for newlib...
make[2]: Entering directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CCASFLAGS=-g -O2"
"CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2"
"INSTALL=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2"
"LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo
--split-size=500 --split-size=500 " "PICFLAG="
"PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest"
"RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/share/info"
"libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/arm-rtems5"
"top_toollibdir=/usr/local/arm-rtems5/lib" "AR=arm-rtems5-ar"
"AS=arm-rtems5-as" "CC=arm-rtems5-gcc
-B/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/
-isystem
/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/targ-include
-isystem /home/eshan/development/newlib/newlib-cygwin/newlib/libc/include
" "LD=arm-rtems5-ld" "LIBCFLAGS=-g -O2" "NM=arm-rtems5-nm" "PICFLAG="
"RANLIB=arm-rtems5-ranlib" "DESTDIR=" all-recursive
make[3]: Entering directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CCASFLAGS=-g -O2"
"CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2"
"INSTALL=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2"
"LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo
--split-size=500 --split-size=500  " "PICFLAG="
"PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest"
"RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/share/info"
"libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/arm-rtems5"
"top_toollibdir=/usr/local/arm-rtems5/lib" "AR=arm-rtems5-ar"
"AS=arm-rtems5-as" "CC=arm-rtems5-gcc
-B/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/
-isystem
/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/targ-include
-isystem /home/eshan/development/newlib/newlib-cygwin/newlib/libc/include
" "LD=arm-rtems5-ld" "LIBCFLAGS=-g -O2" "NM=arm-rtems5-nm" "PICFLAG="
"RANLIB=arm-rtems5-ranlib" "DESTDIR=" DO=all multi-do # make
make[4]: Entering directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib'
if [ -z "thumb vfp/hard thumb/armv6-m thumb/armv7-a thumb/armv7-r
thumb/cortex-m3 thumb/cortex-m4 thumb/armv7-a/neon/hard
thumb/armv7-r/vfpv3-d16/hard thumb/cortex-m4/fpv4-sp-d16/hard
thumb/cortex-m7/fpv5-d16/hard eb/thumb/armv7-r
eb/thumb/armv7-r/vfpv3-d16/hard" ]; then \
  true; \
else \
  rootpre=`${PWDCMD-pwd}`/; export rootpre; \
  srcrootpre=`cd ../../../newlib-cygwin/newlib; ${PWDCMD-pwd}`/; export
srcrootpre; \
  lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
  compiler="arm-rtems5-gcc
-B/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/
-isystem
/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/targ-include
-isystem /home/eshan/development/newlib/newlib-cygwin/newlib/libc/include
"; \
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
  true; \
else \
  if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g
-O2" "CCASFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g
-O2" "INSTALL=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2"
"LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo
--split-size=500 --split-size=500   " "PICFLAG="
"PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest"
"RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/share/info"
"libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/arm-rtems5"
"top_toollibdir=/usr/local/arm-rtems5/lib" "AR=arm-rtems5-ar"
"AS=arm-rtems5-as" "CC=arm-rtems5-gcc
-B/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/
-isystem
/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/newlib/targ-include
-isystem /home/eshan/development/newlib/newlib-cygwin/newlib/libc/include
" "LD=arm-rtems5-ld" "LIBCFLAGS=-g -O2" "NM=arm-rtems5-nm" "PICFLAG="
"RANLIB=arm-rtems5-ranlib" "DESTDIR=" \
CFLAGS="-g -O2 ${flags}" \
CCASFLAGS="-g -O2 ${flags}" \
FCFLAGS=" ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
pref

Re: [rtems/rsb]: Adding PTP support to RSB [GSoC 2020]

[Mritunjay Sharma]

On Tue, May 19, 2020 at 10:09 PM Vijay Kumar Banerjee 
wrote:

> On Tue, May 19, 2020 at 7:42 PM Mritunjay Sharma
>  wrote:
> >
> > Hello everyone,
> >
> > Starting this thread to discuss and give a detail of my progress in
> relation to
> > my GSoC 2020 project "BSP Buildset for EPICS".
> >
> > It is to tell that I have worked on adding ptp2 support as suggested by
> mentors
> > The implementation that I found could work was ptp2 daemon and so worked
> with
> > it.
> >
> > I added these files:
> > rsb/rtems/config/net/ptpd-2.3-1.cfg
> > rsb/rtems/config/net/ptpd.bset
> > rsb/source-builder/config/ptpd-2.1.cfg
> >
> > I am attaching the .diff file and the bug that I have encountered in the
> > respective txt file and will like the help of mentors in trying to help
> me
> > fix it.
> >
> Hi Mritrynjay,
>
> The error your are facing is here:
> ```
> checking whether the C compiler works... no
> configure: error: in
>
> `/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc':
> configure: error: C compiler cannot create executables
> ```
> Looks like it's not able to find the CC properly. If I remember
> correctly, you had a similar problem before. Do you remember how you
> fixed that or what was missing?
>
> Thank you so much for the help, Vijay. However, the thing that was working
last time is not
helping me this time. I am attaching the config.log as well. Hope it will
help with debugging.

>
> Also, there's another warning in the log:
>
> configure: WARNING: unrecognized options: --disable-embedded-perl,
> --without-openssl
>
> You can just remove these options from the cfg file.
>

Thank you so much, I have removed them now and will update on the GitHub as
well.

- Mritunjay

>
> Best regards,
> Vijay
>
> > I will also be uploading the files on my GitHub repo as well which can
> be accessed from here:
> > https://github.com/mritunjaysharma394/rtems-source-builder
> >
> > Thanks,
> > Mritunjay
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by ptpd configure 2.3.1, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ../ptpd-2.3.1/configure --host=sparc-rtems5 --prefix=/home/mritunjay/development/rtems/5 --bindir=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32/bin --exec_prefix=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32 --includedir=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32/lib/include --libdir=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32/lib --libexecdir=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32/libexec --mandir=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32/share/man --infodir=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32/share/info --datadir=/home/mritunjay/development/rtems/5/sparc-rtems5/erc32/share --disable-shared --without-openssl --disable-statistics --enable-slave-only --disable-posix-timers --with-max-unicast-destinations=[16...2048] --enable-experimental-options

## - ##
## Platform. ##
## - ##

hostname = mritunjay-XPS-15-9570
uname -m = x86_64
uname -r = 5.3.0-51-generic
uname -s = Linux
uname -v = #44~18.04.2-Ubuntu SMP Thu Apr 23 14:27:18 UTC 2020

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/mritunjay/development/rtems/5/bin
PATH: /home/mritunjay/development/rtems/rsb/source-builder
PATH: /home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000-cxc/net/ptpd/home/mritunjay/development/rtems/5/bin
PATH: /home/mritunjay/development/rtems/rsb/rtems/build/tmp/sb-1000/net/ptpd/home/mritunjay/development/rtems/5/bin
PATH: /home/mritunjay/.local/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /usr/local/games
PATH: /snap/bin


## --- ##
## Core tests. ##
## --- ##

configure:2627: checking for a BSD-compatible install
configure:2695: result: /usr/bin/install -c
configure:2706: checking whether build environment is sane
configure:2761: result: yes
configure:2820: checking for sparc-rtems5-strip
configure:2836: found /home/mritunjay/development/rtems/5/bin/sparc-rtems5-strip
configure:2847: result: sparc-rtems5-strip
configure:2912: checking for a thread-safe mkdir -p
configure:2951: result: /bin/mkdir -p
configure:2958: checking for gawk
configure:2988: result: no
configure:2958: checking for mawk
configure:2974: found /usr/bin/mawk
configure:2985: result: mawk
configure:2996: checking whether make sets $(MAKE)
configure:3018: result: yes
configure:3047: checking whe

Re: [rtems/rsb]: Adding PTP support to RSB [GSoC 2020]

[Vijay Kumar Banerjee]

On Wed, May 20, 2020 at 12:52 AM Mritunjay Sharma
 wrote:
>
>
>
> On Tue, May 19, 2020 at 10:09 PM Vijay Kumar Banerjee  wrote:
>>
>> On Tue, May 19, 2020 at 7:42 PM Mritunjay Sharma
>>  wrote:
>> >
>> > Hello everyone,
>> >
>> > Starting this thread to discuss and give a detail of my progress in 
>> > relation to
>> > my GSoC 2020 project "BSP Buildset for EPICS".
>> >
>> > It is to tell that I have worked on adding ptp2 support as suggested by 
>> > mentors
>> > The implementation that I found could work was ptp2 daemon and so worked 
>> > with
>> > it.
>> >
>> > I added these files:
>> > rsb/rtems/config/net/ptpd-2.3-1.cfg
>> > rsb/rtems/config/net/ptpd.bset
>> > rsb/source-builder/config/ptpd-2.1.cfg
>> >
>> > I am attaching the .diff file and the bug that I have encountered in the
>> > respective txt file and will like the help of mentors in trying to help me
>> > fix it.
>> >
>> Hi Mritrynjay,
>>
>> The error your are facing is here:
>> ```
>> checking whether the C compiler works... no
>> configure: error: in
>> `/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc':
>> configure: error: C compiler cannot create executables
>> ```
>> Looks like it's not able to find the CC properly. If I remember
>> correctly, you had a similar problem before. Do you remember how you
>> fixed that or what was missing?
>>
> Thank you so much for the help, Vijay. However, the thing that was working 
> last time is not
> helping me this time. I am attaching the config.log as well. Hope it will 
> help with debugging.

Thanks for the log files. From a quick look, there is one obvious
error, the linker can't find libbsd most probably because it is not
there. So, you need to remove the -lbsd option from ptpd-2-1.cfg file
LIBS value. Another thing to be noted is that there are a few errors
due to failed version checking of the sparc-rtems5-gcc, this can
probably ignored for now if removing the -lbsd option fixes your
issue.

>>
>>
>> Also, there's another warning in the log:
>>
>> configure: WARNING: unrecognized options: --disable-embedded-perl,
>> --without-openssl
>>
>> You can just remove these options from the cfg file.
>
>
> Thank you so much, I have removed them now and will update on the GitHub as 
> well.
>
> - Mritunjay
>>
>>
>> Best regards,
>> Vijay
>>
>> > I will also be uploading the files on my GitHub repo as well which can be 
>> > accessed from here:
>> > https://github.com/mritunjaysharma394/rtems-source-builder
>> >
>> > Thanks,
>> > Mritunjay
>> >
>> >
>> > ___
>> > 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: [rtems/rsb]: Adding PTP support to RSB [GSoC 2020]

[Vijay Kumar Banerjee]

On Wed, May 20, 2020 at 1:27 AM Mritunjay Sharma
 wrote:
>
>> Thanks for the log files. From a quick look, there is one obvious
>> error, the linker can't find libbsd most probably because it is not
>> there. So, you need to remove the -lbsd option from ptpd-2-1.cfg file
>> LIBS value. Another thing to be noted is that there are a few errors
>> due to failed version checking of the sparc-rtems5-gcc, this can
>> probably ignored for now if removing the -lbsd option fixes your
>> issue.
>>
> Thank you so much! Removing the lbsd from cfg file resloved the earlier
> compiler issue but now another error is coming up and it is somewhat like 
> this:
>  "Makefile:502: recipe for target 'all-recursive' failed
> make[1]: Leaving directory 
> '/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc'
> make[1]: *** [all-recursive] Error 1
> Makefile:412: recipe for target 'all' failed
> make: *** [all] Error 2
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/do-build
> error: building ptpd-2.3.1-sparc-rtems5-1"
>

The error is generally at the end of the log file. In this case, it is:
```

In file included from ../../ptpd-2.3.1/src/arith.c:53:0:
../../ptpd-2.3.1/src/ptpd.h:93:10: fatal error: netinet/ip.h: No such
file or directory
 #include 
  ^~
compilation terminated.
```
This header file isn't there in the include directory. Is netinet a
dependency fo ptpd? If so, you'll have to find the package that
provides netinet, and add that to rsb in a similar manner as in ptpd,
then you'll have to add it in the ptpd.bset .

> Attaching the log file as well.
> - Mritunjay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems/rsb]: Adding PTP support to RSB [GSoC 2020]

[Chris Johns]

On 20/5/20 5:57 am, Mritunjay Sharma wrote:
On Wed, May 20, 2020 at 1:15 AM Vijay Kumar Banerjee > wrote:


On Wed, May 20, 2020 at 12:52 AM Mritunjay Sharma
mailto:mritunjaysharma...@gmail.com>>
wrote:
 >
 >
 >
 > On Tue, May 19, 2020 at 10:09 PM Vijay Kumar Banerjee
mailto:vi...@rtems.org>> wrote:
 >>
 >> On Tue, May 19, 2020 at 7:42 PM Mritunjay Sharma
 >> mailto:mritunjaysharma...@gmail.com>> wrote:
 >> >
 >> > Hello everyone,
 >> >
 >> > Starting this thread to discuss and give a detail of my
progress in relation to
 >> > my GSoC 2020 project "BSP Buildset for EPICS".
 >> >
 >> > It is to tell that I have worked on adding ptp2 support as
suggested by mentors
 >> > The implementation that I found could work was ptp2 daemon and
so worked with
 >> > it.
 >> >
 >> > I added these files:
 >> > rsb/rtems/config/net/ptpd-2.3-1.cfg
 >> > rsb/rtems/config/net/ptpd.bset
 >> > rsb/source-builder/config/ptpd-2.1.cfg
 >> >
 >> > I am attaching the .diff file and the bug that I have
encountered in the
 >> > respective txt file and will like the help of mentors in
trying to help me
 >> > fix it.


I am seeing in the RSB log this ...

+ pwd
+ 
build_top=/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1

+ test x86_64-linux-gnu != sparc-rtems5
+ test -z  -o sparc-rtems5 ==
/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/do-build: 
102: test: sparc-rtems5: unexpected operator


Is there a shell script error here?

It is not clear to me why this error did not stop the build?

Please add --trace to the RSB command line. It does create lots of 
output but it does help debug these things.



 >> >
 >> Hi Mritrynjay,
 >>
 >> The error your are facing is here:
 >> ```
 >> checking whether the C compiler works... no
 >> configure: error: in
 >>

`/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc':
 >> configure: error: C compiler cannot create executables
 >> ```
 >> Looks like it's not able to find the CC properly. If I remember
 >> correctly, you had a similar problem before. Do you remember how you
 >> fixed that or what was missing?
 >>
 > Thank you so much for the help, Vijay. However, the thing that
was working last time is not
 > helping me this time. I am attaching the config.log as well. Hope
it will help with debugging.

Thanks for the log files. From a quick look, there is one obvious
error, the linker can't find libbsd most probably because it is not
there. So, you need to remove the -lbsd option from ptpd-2-1.cfg file
LIBS value. Another thing to be noted is that there are a few errors
due to failed version checking of the sparc-rtems5-gcc, this can
probably ignored for now if removing the -lbsd option fixes your
issue.

Thank you so much! Removing the lbsd from cfg file resloved the earlier
compiler issue but now another error is coming up and it is somewhat 
like this:

  "Makefile:502: recipe for target 'all-recursive' failed
make[1]: Leaving directory 
'/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc'


This looks like a Canadian Cross compile and this does not seem right. 
It may be related to the shell script error above.


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

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

[Hesham Almatary]

On Tue, 19 May 2020 at 14:00, Utkarsh Rai  wrote:
>
>
>
> On Mon, May 18, 2020 at 8:38 PM Gedare Bloom  wrote:
>>
>> On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai  wrote:
>> >
>> >
>> >
>> >
>> > On Sat, May 16, 2020 at 9:16 PM Joel Sherrill  wrote:
>> >>
>> >>
>> >>
>> >> On Sat, May 16, 2020 at 10:14 AM Gedare Bloom  wrote:
>> >>>
>> >>> Utkarsh,
>> >>>
>> >>> What do you mean by "This would although mean that we would have page 
>> >>> tables of  1MB."
>> >>>
>> >>> Check that you use plain text when inlining a reply, or at least that 
>> >>> you broke the reply format.
>> >>>
>> >>> Gedare
>> >>>
>> >>> On Fri, May 15, 2020, 6:04 PM Utkarsh Rai  
>> >>> wrote:
>> 
>> 
>> 
>>  On Thu, May 14, 2020 at 10:23 AM Sebastian Huber 
>>   wrote:
>> >
>> > Hello Utkarsh Rai,
>> >
>> > On 13/05/2020 14:30, Utkarsh Rai wrote:
>> > > Hello,
>> > > My GSoC project,  providing thread stack protection support, has to 
>> > > be
>> > > a user-configurable feature.
>> > > My question is,  what would be the best way to implement this, my 
>> > > idea
>> > > was to model it based on the existing system configuration
>> > > , 
>> > > but
>> > > Dr. Gedare pointed out that configuration is undergoing heavy changes
>> > > and may look completely different in future releases. Kindly advise 
>> > > me
>> > > as to what would be the best way to proceed.
>> > before we start with an implementation. It would be good to define what
>> > a thread stack protection support is supposed to do.
>> 
>> 
>>  The thread stack protection mechanism will protect against stack 
>>  overflow errors and will completely isolate the thread stacks from each 
>>  other. Sharing of thread stack will be possible only when the user 
>>  makes explicit calls to do so. More details about this can be found in 
>>  this thread.
>> >
>> > Then there should
>> > be a concept for systems with a Memory Protection Unit (MPU) and a
>> > concept for systems with a Memory Management Unit (MMU). MMUs may
>> > provide normal 4KiB Pages, large Pages (for example 1MiB) or something
>> > more flexible. We should identify BSPs which should have support for
>> > this. For each BSP should be a concept. Then we should think about how 
>> > a
>> > user can configure this feature.
>> >
>> > For memory protection will have a 1:1 VA-PA address translation that 
>> > means a 4KiB page size will be set for both the MPU and MMU, a 1:1 
>> > mapping will ensure we will have to do lesser page table walks.This 
>> > would although mean that we would have page tables of  1MB. I will be 
>> > first providing the support for Armv7 based BSPs (RPi , BBB, etc. have 
>> > MMU support) then when I have a working example I will move on to 
>> > provide the support for RISC-V. which has MPU support.
>> >>
>> >>
>> >> I think Sebastian is asking exactly what I did. What are the processor 
>> >> (specific CPU) requirements to support thread stack protection?
>> >
>> >
>> > For thread stack protection the processor should have the option of paging 
>> > along with appropriate 'access bits' setting. Both RISC-V and ARMv7-A (the 
>> > ones that I will be focusing on my project) have the option of defining 
>> > pages of 4KiB size with appropriate access bits.
>> >
>> >>
>> >>
>> >> For example, to be effective, I imagine a 1MB granularity might be 
>> >> sufficient to protect code versus data/bss. But it is likely insufficient 
>> >> to protect thread stacks.
>> >>
>> >> Similarly, a processor with a limited number of "protection areas" would 
>> >> be unsuitable as a basis for implementing thread stack protection. Here I 
>> >> am thinking of the PowerPC with a handful of TLB registers. You would 
>> >> have to turn on paging.
>> >
>> >
>> > I agree, most of the processors have protection regions between 8 to 16 
>> > and in some cases as less as 4. For stack protection paging with each page 
>> > of size 4KiB, as it is applicable for processors with mpu or mmu and is 
>> > optimal, in the sense that we would have appropriate number and size of 
>> > pages for thread stacks, is the best option.
>> >
>>
>> We should have a clear understanding of the design requirements
>> brefore we can make such a statement about "optimal" and "best".
>>
>> The proposal has some good ideas in it, but I think the project has
>> some implied expectations or assumptions, on both your side and from
>> mentors/stakeholders. Here are some ideas that should start to hint at
>> requirements. Maybe you can propose some design requirements. I'm not
>> too good at writing requirements myself, but here goes:
>> 1. Memory protection is optional. The default is no memory protection.
>> 2. The basic protection isolates the text, rodata, and rwdata from
>> each other. There is