Re: BSP Builder Results :(

[junkes]

Hallo Joel,
unfortunately, even with waf, it still does not work as it should.

Example MVME2500 (qoriq_e500)

#install rsb and rtems powerpc tools
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb/rtems
../source-builder/sb-set-builder 
--prefix=/home/junkes/MVME2500_testing/rtems/6 6/rtems-powerpc

cd ../..

#RTEMS development
export RTEMS_VERSION=6
export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
export RTEMS_ROOT=/home/junkes/MVME2500_testing/rtems/${RTEMS_VERSION}
export PATH=${RTEMS_ROOT}/bin:${PATH}

# building kernel
git clone git://git.rtems.org/rtems.git kernel
cd kernel
# build and install bsp
./waf bsp_defaults --rtems-bsps=powerpc/qoriq_e500 > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|CLOCK_DRIVER_USE_FAST_IDLE = True|CLOCK_DRIVER_USE_FAST_IDLE = 
False|" \

-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME2500_testing/rtems/6
./waf
./waf install

#create bootable image file
cd ..
mkimage.py -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe hello.img


junkes@Krikkit:~/MVME2500_testing$ ls -l hello.img
-rw-rw-r-- 1 junkes junkes 2990848 Feb 25 17:50 hello.img

#boot file on HW (MVME2500)

MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 12 ms (1005.9 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: 
#

#
#
#
10.6 MiB/s
done
Bytes transferred = 2990848 (2da300 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 16:50:29 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2990784 Bytes = 2.9 MiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... Error: Bad gzipped data
GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to 
recover


U-Boot 2013.01 (Aug 23 2016 - 12:17:55)

CPU0: P2020E, Version: 2.1, (0x80ea0021)
Core: E500, Version: 5.1, (0x80211051)
Clock Configuration:
CPU0:1200 MHz, CPU1:1200 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz
L1: D-cache 32 kB enabled
...

With mkimage no compression:

mkimage.py -A ppc -O linux -T kernel -C none -a 0x4000 -e 0x4000 -n 
RTEMS -d kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe 
hello.img

Image Name: RTEMS
Created: Thu Feb 25 18:10:00 2021
Image Type: none
Data Size: 2990784
Load Address: 0x4000
Entry Point: 0x4000

Now the well known behavior -> hangs, must be HW-reset

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: 
#

#
#
#
10.3 MiB/s
done
Bytes transferred = 2990848 (2da300 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 17:10:00 UTC
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 2990784 Bytes = 2.9 MiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Loading Kernel Image ... OK
OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

-> no more output ... frozen target 

On 2021-02-25 14:45, Joel Sherrill wrote:


Hi

Just passing along that the need to switch the BSP builder to waf is 
becoming more obvious in the BSP Builder results


https://lists.rtems.org/pipermail/build/2021-February/026054.html

467 of 1615 configurations now fail to build.

-joel
___
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: BSP Builder Results :(

[junkes]

I have now done the whole thing again the "old way"

(master, checkout 5
./bootstrap -c && ./rtems-bootstrap
cd ..
mkdir -p build/b-qoriq_e500
cd build/b-qoriq_e500
../../kernel/configure --prefix=/home/junkes/MVME2500_testing/rtems/5 
--target=powerpc-rtems5 --enable-rtemsbsp=qoriq_e500 --enable-posix 
--enable-c++ --disable-networking --enable-tests

make -j17 all
make install
)

with RTEMS 5 and have come to the same result (frozen CPU).

Then instead of using mkimage.pl I used my standard way:

powerpc-rtems5-objcopy -O binary 
b-qoriq_e500/powerpc-rtems5/c/qoriq_e500/testsuites/samples/hello.exe 
hello.bin

mv hello.img hello_mkimage.img
gzip -9 -f -c hello.bin > hello.bin.gz
mkimage -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
hello.bin.tgz hello.img


(mkimage from the ubuntu distro:
junkes@Krikkit:~/MVME2500_testing$ mkimage -V
mkimage version 2020.10+dfsg-1ubuntu0~20.04.2
)
Et voila:

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: #
5.7 MiB/s
done
Bytes transferred = 59818 (e9aa hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 19:38:30 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 59754 Bytes = 58.4 KiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

*** BEGIN OF TEST HELLO WORLD ***
*** TEST VERSION: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

Hello World

*** END OF TEST HELLO WORLD ***

*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

executing thread ID: 0x08a010001
executing thread name: UI1

U-Boot 2013.01 (Aug 23 2016 - 12:17:55)

CPU0: P2020E, Version: 2.1, (0x80ea0021)
Core: E500, Version: 5.1, (0x80211051)
Clock Configuration:
CPU0:1200 MHz, CPU1:1200 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz
L1: D-cache 32 kB enabled

Now, I will repeat the Installation of RTEMS6 again and try the ubuntu 
mkimage


Heinz

On 2021-02-25 18:23, Joel Sherrill wrote:

On Thu, Feb 25, 2021 at 11:15 AM junkes  
wrote:



Hallo Joel,
unfortunately, even with waf, it still does not work as it should.


Building and not working is slightly better but still bad. :(

The bsp-builder doesn't run any tests. I do run automated test runs on 
a
number  of BSPs and have had to login to the server and kill qemu's 
that

get stuck and run forever. I haven't tracked down which BSP is hanging
yet though.

Example MVME2500 (qoriq_e500)

#install rsb and rtems powerpc tools
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb/rtems
../source-builder/sb-set-builder 
--prefix=/home/junkes/MVME2500_testing/rtems/6 6/rtems-powerpc

cd ../..

#RTEMS development
export RTEMS_VERSION=6
export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
export RTEMS_ROOT=/home/junkes/MVME2500_testing/rtems/${RTEMS_VERSION}
export PATH=${RTEMS_ROOT}/bin:${PATH}

# building kernel
git clone git://git.rtems.org/rtems.git [1] kernel
cd kernel
# build and install bsp
./waf bsp_defaults --rtems-bsps=powerpc/qoriq_e500 > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|CLOCK_DRIVER_USE_FAST_IDLE = True|CLOCK_DRIVER_USE_FAST_IDLE = 
False|" \

-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME2500_testing/rtems/6
./waf
./waf install

#create bootable image file
cd ..
mkimage.py -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe hello.img


junkes@Krikkit:~/MVME2500_testing$ ls -l hello.img
-rw-rw-r-- 1 junkes junkes 2990848 Feb 25 17:50 hello.img

#boot file on HW (MVME2500)

MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 12 ms (1005.9 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: 
#

#
#
#
10.6 MiB/s
done
Bytes transferred = 2990848 (2da300 he

Re: BSP Builder Results :(

[junkes]

With RTEMS6, frozen CPU even with the ubuntu mkimage:

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: ##
6.2 MiB/s
done
Bytes transferred = 77800 (12fe8 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 20:30:19 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 77736 Bytes = 75.9 KiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

> no more output ...

On 2021-02-25 20:52, junkes wrote:


I have now done the whole thing again the "old way"

(master, checkout 5
./bootstrap -c && ./rtems-bootstrap
cd ..
mkdir -p build/b-qoriq_e500
cd build/b-qoriq_e500
../../kernel/configure --prefix=/home/junkes/MVME2500_testing/rtems/5 
--target=powerpc-rtems5 --enable-rtemsbsp=qoriq_e500 --enable-posix 
--enable-c++ --disable-networking --enable-tests

make -j17 all
make install
)

with RTEMS 5 and have come to the same result (frozen CPU).

Then instead of using mkimage.pl I used my standard way:

powerpc-rtems5-objcopy -O binary 
b-qoriq_e500/powerpc-rtems5/c/qoriq_e500/testsuites/samples/hello.exe 
hello.bin

mv hello.img hello_mkimage.img
gzip -9 -f -c hello.bin > hello.bin.gz
mkimage -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
hello.bin.tgz hello.img


(mkimage from the ubuntu distro:
junkes@Krikkit:~/MVME2500_testing$ mkimage -V
mkimage version 2020.10+dfsg-1ubuntu0~20.04.2
)
Et voila:

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: #
5.7 MiB/s
done
Bytes transferred = 59818 (e9aa hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 19:38:30 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 59754 Bytes = 58.4 KiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

*** BEGIN OF TEST HELLO WORLD ***
*** TEST VERSION: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

Hello World

*** END OF TEST HELLO WORLD ***

*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

executing thread ID: 0x08a010001
executing thread name: UI1

U-Boot 2013.01 (Aug 23 2016 - 12:17:55)

CPU0: P2020E, Version: 2.1, (0x80ea0021)
Core: E500, Version: 5.1, (0x80211051)
Clock Configuration:
CPU0:1200 MHz, CPU1:1200 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz
L1: D-cache 32 kB enabled

Now, I will repeat the Installation of RTEMS6 again and try the ubuntu 
mkimage


Heinz

On 2021-02-25 18:23, Joel Sherrill wrote:

On Thu, Feb 25, 2021 at 11:15 AM junkes  
wrote:


Hallo Joel,
unfortunately, even with waf, it still does not work as it should.

Building and not working is slightly better but still bad. :(

The bsp-builder doesn't run any tests. I do run automated test runs on 
a
number  of BSPs and have had to login to the server and kill qemu's 
that

get stuck and run forever. I haven't tracked down which BSP is hanging
yet though.

Example MVME2500 (qoriq_e500)

#install rsb and rtems powerpc tools
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb/rtems
../source-builder/sb-set-builder 
--prefix=/home/junkes/MVME2500_testing/rtems/6 6/rtems-powerpc

cd ../..

#RTEMS development
export RTEMS_VERSION=6
export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
export RTEMS_ROOT=/home/junkes/MVME2500_testing/rtems/${RTEMS_VERSION}
export PATH=${RTEMS_ROOT}/bin:${PATH}

# building kernel
git clone git://git.rtems.org/rtems.git [1] kernel
cd kernel
# build and install bsp
./waf bsp_defaults --rtems-bsps=powerpc/qoriq_e500 > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|CLOCK_DRIVER_USE_FAST_IDLE = True|CLOCK_DRIVER_USE_FAST_IDLE = 
False|" \

-e "s|BUILD_TESTS = Fal

Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[junkes]

Dear Vijay,
thank you very much for your effort to bring some order here ;-)

I am currently trying to get EPICS to work on RTEMS6 as well.

I already failed with the legacy stack because configuration variables 
like

RTEMS_HAS_NETWORK are not set with the waf-builder.

That's why I quite happily jumped on your legacy-net-extra
(For the beatnik CPU on which I can test directly on the hardware).

Unfortunately, it doesn't quite work yet:

git clone https://github.com/RTEMS/rtems-source-builder.git rsb

cd rsb
cd rtems
../source-builder/sb-set-builder 
--prefix=/home/junkes/MVME6100_testing/rtems/6 6/rtems-powerpc

cd ../..

#RTEMS development
export RTEMS_VERSION=6
export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
export RTEMS_ROOT=/home/junkes/MVME6100_testing/rtems/${RTEMS_VERSION}
export PATH=${RTEMS_ROOT}/bin:${PATH}

# building kernel
#git clone git://git.rtems.org/rtems.git kernel
git clone git://git.rtems.org/vijay/rtems.git kernel
cd kernel

# build and install bsp
# 1. Test with waf
#-e "s|RTEMS_NETWORKING = False|RTEMS_NETWORKING = True|" \
./waf bsp_defaults --rtems-bsps=powerpc/beatnik > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6
./waf
./waf install

cd ..

# building extra legacy net
git clone git://git.rtems.org/vijay/rtems-net-legacy.git legacyNet
cd legacyNet
git submodule init
git submodule update

./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6

Setting top to : /home/junkes/MVME6100_testing/legacyNet
Setting out to : /home/junkes/MVME6100_testing/legacyNet/build
RTEMS Version : 6
Architectures : powerpc-rtems6
Board Support Package (BSP) : powerpc-rtems6-beatnik
Show commands : no
Long commands : no
Checking for program 'powerpc-rtems6-gcc' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-gcc
Checking for program 'powerpc-rtems6-g++' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-g++
Checking for program 'powerpc-rtems6-gcc' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-gcc
Checking for program 'powerpc-rtems6-ld' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-ld
Checking for program 'powerpc-rtems6-ar' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-ar
Checking for program 'powerpc-rtems6-nm' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-nm
Checking for program 'powerpc-rtems6-objdump' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-objdump
Checking for program 'powerpc-rtems6-objcopy' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-objcopy
Checking for program 'powerpc-rtems6-readelf' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-readelf
Checking for program 'powerpc-rtems6-strip' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-strip
Checking for program 'powerpc-rtems6-ranlib' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-ranlib
Checking for program 'rtems-ld' : 
/home/junkes/MVME6100_testing/rtems/6/bin/rtems-ld
Checking for program 'rtems-tld' : 
/home/junkes/MVME6100_testing/rtems/6/bin/rtems-tld
Checking for program 'rtems-syms' : 
/home/junkes/MVME6100_testing/rtems/6/bin/rtems-syms
Checking for program 'rtems-bin2c' : 
/home/junkes/MVME6100_testing/rtems/6/bin/rtems-bin2c

Checking for program 'tar' : /usr/bin/tar
Checking for program 'gcc, cc' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-gcc
Checking for program 'ar' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-ar
Checking for program 'g++, c++' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-g++
Checking for program 'ar' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-ar
Checking for program 'gas, gcc' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-gcc
Checking for program 'ar' : 
/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-ar

Checking for c flags '-MMD' : yes
Checking for cxx flags '-MMD' : yes
Compiler version (powerpc-rtems6-gcc) : 10.2.1 20210205 (RTEMS 6, RSB 
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)

Checking for a valid RTEMS BSP installation : yes
Checking for RTEMS_DEBUG : no
Checking for RTEMS_MULTIPROCESSING : no
Checking for RTEMS_NEWLIB : yes
Checking for RTEMS_POSIX_API : yes
Checking for RTEMS_SMP : no
Checking for RTEMS_NETWORKING : no
'configure' finished successfully (0.840s)

./waf build --rtems-archs=powerpc --rtems-bsps=beatnik

Waf: Entering directory 
`/home/junkes/MVME6100_testing/legacyNet/build/powerpc-rtems6-beatnik'

[ 1/229] Compiling bsps/powerpc/beatnik/net/porting/if_xxx_rtems.c
[ 2/229] Compiling b

Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[junkes]

In file included from 
../../bsps/powerpc/beatnik/net/porting/if_xxx_rtems.c:1:
../../bsps/powerpc/beatnik/net/porting/rtemscompat.h:164:2: error: 
#error rtemscompat_defs.h must define either NET_CHIP_LE or 
NET_CHIP_BE
164 | #error rtemscompat_defs.h must define either NET_CHIP_LE or 
NET_CHIP_BE


Hopefully this is fixed by adding the include directory or something
similar.

Vijay should speak up on his desired solution.

Heinz, how did the code find this when it was built in the tree? Did it 
have

a -I for this source directory?

--joel

8:04:57 runner 
['/home/junkes/MVME6100_testing/rtems/6/bin/powerpc-rtems6-gcc', 
'-mcpu=7400', 
'-I/home/junkes/MVME6100_testing/rtems/6/powerpc-rtems6/beatnik/lib/include', 
'-MMD', '-I.', '-I../..', '-Iinclude', '-I../../include', 
'-I../rtems/6', '-I../../../rtems/6', '-Itestsuites/include', 
'-I../../testsuites/include', '-I../rtems/6/include', 
'-I../../../rtems/6/include', '-Ibsps/include', 
'-I../../bsps/include', '-I../rtems/6/powerpc-rtems6/beatnik/lib', 
'-I../../../rtems/6/powerpc-rtems6/beatnik/lib', 
'-I../rtems/6/powerpc-rtems6/beatnik/lib/include', 
'-I../../../rtems/6/powerpc-rtems6/beatnik/lib/include', 
'-Ibsps/include/libchip', '-I../../bsps/include/libchip', 
'-Ibsps/powerpc/beatnik/net/porting', 
'-I../../bsps/powerpc/beatnik/net/porting', '../../net/radix.c', '-c', 
'-o/home/junkes/MVME6100_testing/legacyNet/build/powerpc-rtems6-beatnik/net/radix.c.2.o']


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

Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[junkes]

Hi Vijay,
I tried it again:

# building kernel
#git clone git://git.rtems.org/rtems.git kernel
git clone git://git.rtems.org/vijay/rtems.git kernel
cd kernel
git checkout devel-no-libnet

# build and install bsp
# 1. Test with waf
#-e "s|RTEMS_NETWORKING = False|RTEMS_NETWORKING = True|" \
./waf bsp_defaults --rtems-bsps=powerpc/beatnik > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6
./waf
./waf install

cd ..

# building extra legacy net
git clone git://git.rtems.org/vijay/rtems-net-legacy.git legacyNet
cd legacyNet
git submodule init
git submodule update

./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6

./waf build --rtems-archs=powerpc --rtems-bsps=beatnik


Much better, but still a missing file?

[125/235] Compiling libc/res_mkquery.c
[126/235] Compiling libc/inet_lnaof.c
[127/235] Compiling librpc/src/xdr/xdr_array.c
../../telnetd/check_passwd.c:70:10: fatal error: rtems/telnetd.h: No 
such file or directory

   70 | #include 
  |  ^
compilation terminated.

../../telnetd/telnetd.c:57:10: fatal error: rtems/telnetd.h: No such 
file or directory

   57 | #include 
  |  ^
compilation terminated.

Waf: Leaving directory 
`/home/junkes/MVME6100_testing/legacyNet/build/powerpc-rtems6-beatnik'

Build failed
 -> task in 'network_objects' failed with exit status 1 (run with -v to 
display more information)
 -> task in 'network_objects' failed with exit status 1 (run with -v to 
display more information)


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

Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[junkes]

MSR 0x2003032
Exit from bspstart
unable to find the universe in pci config space
Tundra Tsi148 PCI-VME bridge detected at 0x8110, IRQ 84
Tsi148 Outbound Ports:
Port  VME-Addr   Size   PCI-Adrs   Mode:
0:0x2000 0x0e00 0x9000 A32, SUP, D32, SCT
1:0x 0x00ff 0x9f00 A24, SUP, D32, SCT
2:0x 0x0001 0x9fff A16, SUP, D32, SCT
7:0x 0x0100 0x9e00 CSR, SUP, D32, SCT
Tsi148 Inbound Ports:
Port  VME-Addr   Size   PCI-Adrs   Mode:
0:0x9000 0x1fe0 0x A32, PGM, DAT, SUP, USR, MBLT, 
BLT

vmeTsi148 IRQ manager: looking for registers on VME...
Trying to find CSR on VME...
vmeTsi148 - IRQ manager using VME CSR to flush FIFO


*** BEGIN OF TEST LOOPBACK ***
*** TEST VERSION: 6.0.0.4fa5e77ba3a00f8ac61251b6c049c98102583d57
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.2.1 20210205 (RTEMS 6, RSB 
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)

"Network" initializing!
"Network" initialized!
Try running client with no server present.
Should fail with `connection refused'.
Connect to server.
Can't connect to server: Connection refused
Client closing connection.

Start server.

Try running client with server present.
Connect to server.
Can't connect to server: Connection refused
Client closing connection.
Client task terminating.
Create socket.
Bind socket.

Try running two clients.
Connect to server.
Connect to server.
ACCEPTED:2130706433
ACCEPTED:2130706433
Write 22-byte message to server.
Write 22-byte message to server.
Read 43 from server: Server received 22 (Hi there, server (2).)
Read 43 from server: Server received 22 (Hi there, server (3).)
Client closing connection.
Client task terminating.
Worker task terminating.
Client closing connection.
Client task terminating.
Worker task terminating.

Try running three clients.
Connect to server.
Connect to server.
Connect to server.
ACCEPTED:2130706433
ACCEPTED:2130706433
ACCEPTED:2130706433
Write 22-byte message to server.
Write 22-byte message to server.
Write 22-byte message to server.
Read 43 from server: Server received 22 (Hi there, server (4).)
Read 43 from server: Server received 22 (Hi there, server (5).)
Read 43 from server: Server received 22 (Hi there, server (6).)
Client closing connection.
Client task terminating.
Worker task terminating.
Client closing connection.
Client task terminating.
Worker task terminating.
Client closing connection.
Client task terminating.
Worker task terminating.

*** END OF TEST LOOPBACK ***

fatal source: RTEMS_FATAL_SOURCE_EXIT
bsp_fatal_extension(): RTEMS terminated -- no way back to MotLoad so I 
reset the card

Printing a stack trace for your convenience :-)

0x00224388--> 0x00224388--> 0x00334484--> 0x00311900--> 0x00310528
0x00289968--> 0x00348388--> 0x00013652--> 0x00325192--> 0x00325016



Copyright(C)2008-2009,Emerson Network Power-Embedded Computing,Inc.

Danke!
Heinz





On 2021-03-03 21:03, Vijay Kumar Banerjee wrote:
On Wed, Mar 3, 2021 at 12:37 PM junkes  
wrote:


Hi Vijay,
I tried it again:


Hi Heinz,

I'm really sorry that the build crashed again. I missed the telnetd.h
file probably because it was somewhere in my build prefix from one of
the rtems builds. I have pushed a fix on the rtems repo and the
rtems-net-legacy repo. This time I was more thorough and used a new
prefix location, I believe it won't break this time.

Thank you for helping with the testing. I really appreciate it.


Best regards,
Vijay


# building kernel
#git clone git://git.rtems.org/rtems.git kernel
git clone git://git.rtems.org/vijay/rtems.git kernel
cd kernel
git checkout devel-no-libnet

# build and install bsp
# 1. Test with waf
#-e "s|RTEMS_NETWORKING = False|RTEMS_NETWORKING = True|" \
./waf bsp_defaults --rtems-bsps=powerpc/beatnik > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6
./waf
./waf install

cd ..

# building extra legacy net
git clone git://git.rtems.org/vijay/rtems-net-legacy.git legacyNet
cd legacyNet
git submodule init
git submodule update

./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6

./waf build --rtems-archs=powerpc --rtems-bsps=beatnik


Much better, but still a missing file?

[125/235] Compiling libc/res_mkquery.c
[126/235] Compiling libc/inet_lnaof.c
[127/235] Compiling librpc/src/xdr/xdr_array.c
../../telnetd/check_passwd.c:70:10: fatal error: rtems/telnetd.h: No
such file or directory
70 | #include 
   |  ^
compilation terminated.

../../telnetd/telnetd.c:57:10: fatal error: rtems/telnetd.h: No such
file or directory
57 | #include 
   |  ^
compilation terminated.

Waf: Leaving directory
`/home/junkes/MVME6100_testing/legacyNet/build/powerpc-rte

Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[junkes]

Hallo Vijay,

the next question ;-) I am trying to build EPICS.

with the external legacy stack there are some files missing:

rtems/rtems_bsdnet.h
librtemsNfs.h
rtems/telnetd.h

with RTEMS5 (with networking) one can find e.g. rtems_bsdnet.h here:

./kernel/cpukit/libnetworking/rtems/rtems_bsdnet.h
./rtems/5/powerpc-rtems5/beatnik/lib/include/rtems/rtems_bsdnet.h

Heinz

On 2021-03-03 23:17, Vijay Kumar Banerjee wrote:

Hi Heinz,

Thanks for the hardware tests. It's great to see the tests running
successfully on hardware!

Best regards,
Vijay

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

qoriq_e500 U-Boot Support in RTEMS

[junkes]

to use qoriq_e500 with legacy stack, I tried to define HAS_UBOOT to get 
tcsec-interfaces to work with RTEMS-5.

There is no u-boot-config.h in the qoriq_e500 bsp files.
This file is required by bsp/u-boot.h
Danke, Heinz
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems6 master build tests for erc32 fail : undefined reference to `_Timespec_Is_non_negative'

[junkes]

Making all-am in fstests
make[5]: Entering directory 
'/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/testsuites/fstests'
sparc-rtems6-gcc  -mcpu=cypress -O2 -g -ffunction-sections 
-fdata-sections -Wall -Wmissing-prototypes 
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs 
-B./../../lib/libbsp/sparc/erc32 
-B/home/junkes/VE/kernel/bsps/sparc/erc32/start -specs bsp_specs -qrtems 
-L./../../cpukit -L/home/junkes/VE/kernel/bsps/sparc/shared/start 
-Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections 
-o fsimfsconfig01.exe fsimfsconfig01/fsimfsconfig01-init.o 
./../../lib/libbsp/sparc/erc32/librtemsbsp.a 
./../../cpukit/librtemscpu.a ./../../cpukit/librtemstest.a
/home/junkes/VE/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld: 
./../../cpukit/librtemscpu.a(utimensat.o): in function 
`rtems_filesystem_utime_update':
/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/cpukit/../../../../../../kernel/c/src/../../cpukit/libcsupport/src/utimensat.c:153: 
undefined reference to `_Timespec_Is_non_negative'
/home/junkes/VE/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld: 
/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/cpukit/../../../../../../kernel/c/src/../../cpukit/libcsupport/src/utimensat.c:157: 
undefined reference to `_Timespec_Is_non_negative'

collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:1905: fsimfsconfig01.exe] Error 1
make[5]: Leaving directory 
'/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/testsuites/fstests'

make[4]: *** [Makefile:663: fstests] Error 2
make[4]: Leaving directory 
'/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/testsuites'

make[3]: *** [Makefile:1342: testsuites] Error 2
make[3]: Leaving directory 
'/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32'

make[2]: *** [Makefile:822: all-recursive] Error 1
make[2]: Leaving directory 
'/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32'

make[1]: *** [Makefile:289: all-recursive] Error 1
make[1]: Leaving directory 
'/home/junkes/VE/build/b-erc32/sparc-rtems6/c'

make: *** [Makefile:410: all-recursive] Error 1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[junkes]

On 2020-06-04 16:22, Gedare Bloom wrote:

On Thu, Jun 4, 2020 at 7:58 AM Mritunjay Sharma
 wrote:




On Thu, Jun 4, 2020 at 10:39 AM Chris Johns  wrote:


On 4/6/20 2:31 pm, Gedare Bloom wrote:
> On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
>  wrote:
>>
>> Hello everyone,
>>
>> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
>> with a little modification in ptp cfg file.
>>
>> The netinet is no longer a problem here but another problem has come as 
follows:
>>
>> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':

Is this from sourceforge?



Earlier I used from debian, today I tried with Sourceforge, but same 
error still :(



How does the ptpd-2.3.1 source code relate to the github repo
https://github.com/ptpd/ptpd ?

I have been referencing the github repo.



Yes, that's the repo that we are working with.

Mritunjay



>> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH' 
undeclared (first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>  ^~~
>> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID' undeclared 
(first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>   ^
>
> These are from BSD. This probably needs to be compiled with libbsd
> somehow? or picking up its header files...

In the github version this code is conditional on sys/cpuset.h being 
present.




Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
definitions though. Probably either:
1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
would mean adding cpuset_setaffinity support in rtems, I guess.
2. Figure out how to disable the conditional code using the
cpuset_setaffinity function.



Chris


I changed the reference now to the github.
wget https://github.com/ptpd/ptpd/archive/master.zip

But using autoreconf just every second call works???

h1@earth lall]$ cd ptpd-master/
[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory build-aux
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
  If this token and others are legitimate, please use 
m4_pattern_allow.

  See the Autoconf documentation.
autoreconf: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf failed with 
exit status: 1

[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:29: installing 'build-aux/compile'
configure.ac:17: installing 'build-aux/install-sh'
configure.ac:17: installing 'build-aux/missing'
src/Makefile.am: installing 'build-aux/depcomp'
autoreconf: Leaving directory `.'
[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
  If this token and others are legitimate, please use 
m4_pattern_allow.

  See the Autoconf documentation.
autoreconf: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf failed with 
exit status: 1

[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
autoreconf: Leaving directory `.'
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[junkes]

Hallo Mritunjay, 


You can't just take the github ptpd sources and make them work in RTEMS.
You have to make some configuration
and sources changes before you can build the with the rsb. 


Some things like the sys/cpuset.h seems not to be fully compatible yet
and so the configure simply makes
"wrong" decisions. E.g. defines HAVE_SYS_CPUSET_H = 1 as sys/cpuset.h
exists.I played a little bit with it and reset
the definition in ptpd-master/src/ptpd.h  (quick and dirty) and could
reduce the error messages because there is a query for
this variable in the code (src/dep/sys.c): 

in ptpd.h after the include of the created configs : 


...
#ifdef HAVE_CONFIG_H
# include 
#endif /* HAVE_CONFIG_H */ 


#undef HAVE_NTP_GETTIME
#undef HAVE_SYS_CPUSET_H 


#ifdef linux
... 

in src/dep/sys.c  


...
#ifdef HAVE_SYS_CPUSET_H
   
   
  cpuset_t mask;   
   
  
  CPU_ZERO(&mask); 
   
  
  if(cpu >= 0) {   
   
  
  CPU_SET(cpu,&mask);  
   
  
  } else { 
   
  
  int i;   
   
  
  for(i = 0;  i < CPU_SETSIZE; i++) {  
   
  
  CPU_SET(i, &mask);   
   
  
  }
   
  
  }
   
  
  return(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
   
  
-1, sizeof(mask), &mask)); 
   
  
#endif /* HAVE_SYS_CPUSET_H */   

In src/dep/constants_dep.h  one can find: 

* platform dependent */ 


#if !defined(linux) && !defined(__NetBSD__) && !defined(__FreeBSD__) &&
\
!defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun) &&
!defined(__QNXNTO__)
#error PTPD hasn't been ported to this OS - should be possible \
if it's POSIX compatible, if you succeed, report it to
ptpd-de...@sourceforge.net
#endif 

here I added "&& !defined(__rtems__)  


and here:
... 
   

#if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__APPLE__) ||

defined(__OpenBSD__) || defined(__sun) || defined(__QNXNTO__) ||
defined(__rtems__)  
# include  
   
   
# include 
   
   
#ifdef HAVE_SYS_SOCKIO_H
   
   
#include  
   
   
#endif /* HAVE_SYS_SOCKIO_H */  
   
   
# include 
   
   
# include 
   
   
# 

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[junkes]

rm-rtems5-1/build-cxc/src'

CC   ntpd-server.o 
CC   ntpd-util.o 
CCLD ntpd 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
ntpd-ntp_dns.o: in function `ntp_dns': 
/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src/../../openntpd-6.2p3/src/ntp_dns.c:59:
undefined reference to `setpriority' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
ntpd-ntpd.o: in function `main': 
/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src/../../openntpd-6.2p3/src/ntpd.c:243:
undefined reference to `setpriority' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:

/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/b
uild-cxc/src/../../openntpd-6.2p3/src/ntpd.c:251: undefined reference to
`daemon' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:

/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/b
uild-cxc/src/../../openntpd-6.2p3/src/ntpd.c:330: undefined reference to
`daemon' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
ntpd-ntpd.o: in function `dispatch_imsg': 
/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src/../../openntpd-6.2p3/src/ntpd.c:435:
undefined reference to `daemon' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
ntpd-ntpd.o: in function `ntpd_adjtime': 
/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src/../../openntpd-6.2p3/src/ntpd.c:487:

undefined reference to `update_time_sy
nc_status' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
ntpd-ntpd.o: in function `ntpd_adjfreq': 
/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src/../../openntpd-6.2p3/src/ntpd.c:498:
undefined reference to `adjfreq' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:

/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/b
uild-cxc/src/../../openntpd-6.2p3/src/ntpd.c:522: undefined reference to
`adjfreq' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
ntpd-ntpd.o: in function `ntpd_settime': 
/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src/../../openntpd-6.2p3/src/ntpd.c:542:
undefined reference to `settimeofday' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
ntpd-ntpd.o: in function `readfreq': 
/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src/../../openntpd-6.2p3/src/ntpd.c:565:
undefined reference to `adjfreq' 
/home/h1/GSOC/RTEMS/5.0.0-m2003/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:

/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/b
uild-cxc/src/../../openntpd-6.2p3/src/ntpd.c:574: undefined reference to
`adjfreq' 
collect2: error: ld returned 1 exit status 
Makefile:476: recipe for target 'ntpd' failed 
make[1]: *** [ntpd] Error 1 
make[1]: Leaving directory

'/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src'

Makefile:401: recipe for target 'all-recursive' failed 
make: *** [all-recursive] Error 1 


This is where I am now. From now on, it's gonna be exciting. Now it's
all about anchoring the daemon process in RTEMS. 
But that is nice work now. I still have to do it. 


But I wanted to show you this step-by-step so you can get over the first
hurdles. 
I hope this helps you and it was not too long. 
Heinz


On 2020-06-06 01:31, Mritunjay Sharma wrote:

Thank you so much Heinz for such a detailed response.  
It really helped me a lot. 
As advised by you and Heinz, I changed the source to https://github.com/mritunjaysharma394/ptpd/archive/master.zip 
with suggested changes. However, I have encountered few bugs again related to autoreconf.  
It looks somewhat like this:  


+ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac [1]: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac [1]: tracing
autoreconf: configure.ac [1]: creating directory build-aux
autoreconf: configure.ac [1]: not using Libtool
autoreconf: running: /home/mritunjay/development/rtems/5/bin/autoconf
configure.ac:28 [2]: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /home/mritunjay/development/rtems/5/bin/autoconf f

Re: Command line for Qemu and libbsd for pc386

[junkes]

On 2020-06-24 19:22, Joel Sherrill wrote:

Hi 

Does someone have a qemu command line handy for running libbsd network applications on Qemu? 

I have lots of notes and old examples but can't seem to trip the right combination today. 

Thanks. 

--joel 
___

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


To boot epics I was setting up DHCP, ntp and nfs on my development host,
run this script: 

[h1@earth utilities (master *+)]$ more setUpNetworkForQemu.py 
## @brief This Python file uses the following encoding: utf-8 
#  Documentation for this module. 
# 
#  More details. 

## Documentation for a function. 
# 
import netifaces 
import subprocess 
import dns.resolver 
import subprocess 
from string import Template 

brNet = '10.1.0.0' 
brNetMask = '255.255.255.0' 
brLeaseRange = '10.1.0.100 10.1.0.120' 
br0Ip = '10.1.0.1' 

ethNet = '10.0.0.0' 
ethNetMask = '255.255.255.0' 
ethLeaseRange = '10.0.0.100 10.0.0.120' 
eth0Ip = '10.0.0.1' 

def setupAndStartDhcpd(): 
dhcpdConfStr = ('\n' + 
 'default-lease-time 600;\n' + 
 'max-lease-time 7200;\n' + 
 'option ntp-servers $ntpIp;\n' + 
 'option rtems-cmdline code 129=string;\n' + 
 'option rtems-cmdline "Ich DIch doch auch";\n' + 
 'filename "RtemsForever";\n' + 
 'option domain-name "rtems";\n' + 
 '\n' + 
 'subnet ' + brNet + ' netmask ' + brNetMask + ' {\n' + 
 'range ' + brLeaseRange + ';\n' + 
 'option routers ' + br0Ip + ';\n' + 
 'option domain-name-servers $dnsIp;\n' + 
 '}\n' + 
 'subnet ' + ethNet + ' netmask ' + ethNetMask + ' {\n' + 
 'range ' + ethLeaseRange + ';\n' + 
 'option routers ' + eth0Ip + ';\n' + 
 'option domain-name-servers $dnsIp;\n' + 
 '}\n' ) 

# stop dhcp-server 
subprocess.run(['/bin/systemctl', 'stop', 'isc-dhcp-server.service']) 

dnsResolver = dns.resolver.Resolver() 
print("will setup dhcpd with dhcp-server at : ",
dnsResolver.nameservers[0]) 
s = Template(dhcpdConfStr) 
txtToFile = s.substitute(dnsIp = dnsResolver.nameservers[0], ntpIp =
'10.1.0.1') 
with open('/etc/dhcp/dhcpd.conf', 'w') as f: 
  print(txtToFile, file=f) 
  f.close() 

s = 'INTERFACESv4="br0"' 
with open('/etc/default/isc-dhcp-server', 'w') as f: 
  print(s, file=f) 
  f.close() 

# start dhcp-server 
subprocess.run(['/bin/systemctl', 'start', 'isc-dhcp-server.service']) 

def main(): 
print("\nWill setup qemu network\n") 

#setup a bridge 
subprocess.run(['/sbin/brctl', 'addbr', 'br0']) 
subprocess.run(['/sbin/ifconfig', 'br0', br0Ip, 'netmask', brNetMask,
'up']) 
subprocess.run(['/usr/bin/tunctl', '-t', 'tap0']) 
subprocess.run(['/usr/bin/tunctl', '-t', 'tap1']) 
subprocess.run(['/sbin/brctl', 'addif', 'br0', 'tap0', 'tap1']) 
subprocess.run(['/sbin/ifconfig', 'tap0']) 
subprocess.run(['/sbin/ifconfig', 'tap1']) 

# check for default gateway and interface used 
gws = netifaces.gateways() 
defaultGw = gws['default'][netifaces.AF_INET] 
gwAddress = defaultGw[0] 
gwInterface = defaultGw[1] 
print ("Default gateway : ", gwAddress, " on interface : ",
gwInterface) 
if 'wlan' in gwInterface : 
  print("Wlan interface used!? (", gwInterface, ")\n") 
  print("dummy eth mit ip_forwarding must be put in place") 
  #bridging wlan0 to eth0 
  s = '1' 
  with open('/proc/sys/net/ipv4/ip_forward', 'w') as f: 
print(s, file=f) 
f.close() 
  subprocess.run(['/sbin/iptables', '-t', 'nat', '-A', 'POSTROUTING', 
  '-o', 'wlan0', '-j', 'MASQUERADE']) 
  subprocess.run(['/sbin/brctl', 'addif', 'br0', 'eth0']) 
  subprocess.run(['ifconfig', 'eth0', eth0Ip, 'netmask', ethNetMask,
'up']) 

setupAndStartDhcpd() 
subprocess.run(['/sbin/ifconfig', 'tap0', 'up']) 
print("ready for qemu") 


main()

and then start a exe file with 

[h1@earth QtC-epics-base (7.0 *)]$ more startQemu  
#!/bin/bash 
echo Script name: $0 
if [ $# -ne 1 ]; 
then echo "Please name the exe file" 
exit 2 
fi 
#-net nic -net tap,ifname=tap1,script=no \ 
#-net nic,model=cadence_gem -net tap,ifname=tap1,script=no \ 
# -s -no-reboot 
sudo qemu-system-aarch64 -s -no-reboot \ 
-net nic,model=cadence_gem -net tap,ifname=tap0,script=no \ 
-serial null -serial mon:stdio -nographic -M xilinx-zynq-a9 -m 256M \ 
-kernel bin/RTEMS-xilinx_zynq_a9_qemu/$1


HTH, Heinz___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5 RC1 Available

[junkes]

Hello, Chris,
thank you very much for this first release candidate. I have 
successfully

installed it on a Mac with Catalina (10.15.5) for a BeagleboneBlack.
I was also able to create EPICS 7 with it and run it on the board.
This is really a great job you have done.

Heinz



On 2020-06-26 08:16, Chris Johns wrote:

Hello,

RTEMS 5 RC1 is available for testing. You can find the release at:

 https://ftp.rtems.org/pub/rtems/releases/5/rc/5.1.0-rc1

Please report your successes or problems here. You can also raise a
ticket if you prefer. Please select the 5.1 milestone.

Thanks
Chris
___
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: [GSoC 2020] : BSP Buildset for EPICS (next steps)

[junkes]

Hello Mritunjay, 


I have now finished an EPICS variant that works with libbsd so far. DHCP
and NFS work. NTP I added a primitive reader. This is sufficient for
testing. 

You can find the development here:  

https://gitlab.fhi.mpg.de/junkes/epics-base.git 


It's not perfect yet. The adaptation to the legacy stack and the
processing of the environment variables from the flash (u-boot etc.) is
still missing. 

[h1@earth QtC-epics-base (7.0 *+)]$ ./startQemu softIoc 
Script name: ./startQemu 
qemu-system-aarch64: warning: nic cadence_gem.1 has no peer 
WARNING: OS Clock time was read before being set. 
Using 1990-01-02 00:00:00.00 UTC 

initConsole --- Info --- 
stdin: fileno: 0, ttyname: /dev/ttyS1 
stdout: fileno: 1, ttyname: /dev/ttyS1 
stderr: fileno: 2, ttyname: /dev/ttyS1 
tcsetattr failed: I/O error 
time set to : 04/14/14 07:30:06.55589 UTC 
Startup. 
epicsThreadSetPriority called by non epics thread 


* RTEMS Version: rtems-5.0.0-m2003 (ARM/ARMv4/xilinx_zynq_a9_qemu)
* 

* Initializing network (dhcp) * 
nexus0:  
zy7_slcr0:  on nexus0 
cgem0:  on nexus0 
miibus0:  on cgem0 
e1000phy0:  PHY 0 on miibus0 
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT-FDX, 1000baseT-FDX-master, auto 
e1000phy1:  PHY 23 on miibus0 
e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT-FDX, 1000baseT-FDX-master, auto 
info: cgem0: Ethernet address: 52:54:00:12:34:56 
info: lo0: link state changed to UP 

 Wait for DHCP done ... 
dhcpcd: unknown option -- pv4only 
info: version 6.2.1 starting 
cgem0: cgem_mediachange: could not set ref clk0 to 2500. 
info: cgem0: link state changed to UP 
dhcpcd: unknown option -- pv4only 
debug: cgem0: executing `ioc boot' PREINIT 

* Primary Network interface : cgem0 * 
debug: cgem0: executing `ioc boot' CARRIER 

* Primary Network interface : cgem0 * 
info: DUID 00:01:00:01:1a:de:4a:fe:52:54:00:12:34:56 
info: cgem0: IAID 00:12:34:56 
info: cgem0: soliciting an IPv6 router 
debug: cgem0: delaying Router Solicitation for LL address 
debug: cgem0: using ClientID
00:46:48:49:20:74:65:73:74:20:63:6c:69:65:6e:74 
info: cgem0: soliciting a DHCP lease 
debug: cgem0: sending DISCOVER (xid 0x86686938), next in %0.1f seconds 
info: cgem0: carrier lost 
debug: cgem0: executing `ioc boot' NOCARRIER 

* Primary Network interface : cgem0 * 
info: cgem0: carrier acquired 
dhcpcd: unknown option -- pv4only 
debug: cgem0: executing `ioc boot' CARRIER 

* Primary Network interface : cgem0 * 
info: cgem0: IAID 00:12:34:56 
info: cgem0: soliciting an IPv6 router 
debug: cgem0: delaying Router Solicitation for LL address 
debug: cgem0: using ClientID
00:46:48:49:20:74:65:73:74:20:63:6c:69:65:6e:74 
info: cgem0: soliciting a DHCP lease 
debug: cgem0: sending DISCOVER (xid 0x441a0d89), next in %0.1f seconds 
debug: cgem0: wrong xid 0x86686938 (expecting 0x441a0d89) from 10.1.0.1 
debug: cgem0: sending DISCOVER (xid 0x441a0d89), next in %0.1f seconds 
info: cgem0: offered 10.1.0.104 from 10.1.0.1 
debug: cgem0: sending REQUEST (xid 0x441a0d89), next in %0.1f seconds 
debug: cgem0: acknowledged 10.1.0.104 from 10.1.0.1 
debug: cgem0: checking for 10.1.0.104 
debug: cgem0: sending ARP probe (1 of 3), next in %0.1f seconds 
debug: cgem0: sending ARP probe (2 of 3), next in %0.1f seconds 

 Wait for DHCP done ... 
debug: cgem0: sending ARP probe (3 of 3), next in %0.1f seconds 
info: cgem0: leased 10.1.0.104 for 6000 seconds 
debug: cgem0: renew in 3000 seconds, rebind in 5250 seconds 
debug: cgem0: adding IP address 10.1.0.104/24 
info: cgem0: adding host route to 10.1.0.104 via 127.0.0.1 
err: cgem0: ipv4_addroute: File exists 
info: cgem0: adding route to 10.1.0.0/24 
err: cgem0: ipv4_addroute: File exists 
info: cgem0: adding default route via 10.1.0.1 
debug: cgem0: writing lease `/var/db/dhcpcd-cgem0.lease' 
debug: cgem0: executing `ioc boot' BOUND 

* Primary Network interface : cgem0 * 
Interface TGP bounded 
rtems_bsdnet_bootp_server_name : 1001.1001@10.1.0.1:/Volumes/Epics 
rtems_bsdnet_bootp_boot_file_name :
/Volumes/Epics/myExample/bin/RTEMS-xilinx_zynq_a9_qemu/myExample.boot 
rtems_bsdnet_bootp_cmdline :
/Volumes/Epics/myExample/iocBoot/iocmyExample/st.cmd 
debug: cgem0: sending ARP announce (1 of 2), next in 2.0 seconds 
-- IFCONFIG - 
cgem0: flags=8843 metric 0 mtu
1500 
  options=80008 
  ether 52:54:00:12:34:56 
  inet6 fe80::5054:ff:fe12:3456%cgem0 prefixlen 64 scopeid 0x1 
  inet 10.1.0.104 netmask 0xff00 broadcast 10.1.0.255 
  nd6 options=21 
  media: Ethernet autoselect (100baseTX ) 
  status: active 
lo0: flags=8049 metric 0 mtu 16384 
  options=680003 
  inet 127.0.0.1 netmask 0xff00 
  inet6 ::1 prefixlen 128 
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
  nd6 options=21 
  groups: lo 
-- NETSTAT -- 
Rout

Feature request libbsd, dhcpcd adding a dhcp option

[junkes]

To get the most out of epics with libbsd, I would like to see an option 
added to dhcpcd.

option 129 rtems_cmdline.

diff --git a/dhcpcd/dhcpcd-definitions.conf 
b/dhcpcd/dhcpcd-definitions.conf

index 84260861..cb7d4306 100644
--- a/dhcpcd/dhcpcd-definitions.conf
+++ b/dhcpcd/dhcpcd-definitions.conf
@@ -160,6 +160,10 @@ encap 8byte
provisioning_timer

 define 124 binhex  vivco
 define 125 embed   vivso
 embed  uint32  enterprise_number
+
+# RTEMS
+define 129 string  rtems_cmdline
+
 # Vendor options are shared between DHCP/DHCPv6
 # Their code is matched to the enterprise number defined above
 # see the end of this file for an example
diff --git a/dhcpcd/dhcpcd-embedded.c b/dhcpcd/dhcpcd-embedded.c
index 068a8dfd..b857eaba 100644
--- a/dhcpcd/dhcpcd-embedded.c
+++ b/dhcpcd/dhcpcd-embedded.c
@@ -154,6 +154,7 @@ const char *dhcpcd_embedded_conf[] = {
 "define 124 binhex vivco",
 "define 125 embed vivso",
 "embed uint32 enterprise_number",
+"define 129 string rtems_cmdline",
 "define 212 rfc5969 sixrd",
 "define6 1 binhex client_id",
 "define6 2 binhex server_id",

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

Re: Using libbsd dhcpcd options

[junkes]

Hallo Peter,
I do not know if this is best practice but I run the following code:

static void
default_network_dhcpcd(void)
{
static const char default_cfg[] = "clientid test client\n";
rtems_status_code sc;
int fd;
int rv;
ssize_t n;
struct stat statbuf;

if (ENOENT == stat("/etc/dhcpcd.conf", &statbuf)) {
fd = open("/etc/dhcpcd.conf", O_CREAT | O_WRONLY,
  S_IRWXU | S_IRWXG | S_IRWXO);
assert(fd >= 0);

n = write(fd, default_cfg, sizeof(default_cfg) - 1);
assert(n == (ssize_t) sizeof(default_cfg) - 1);

static const char fhi_cfg[] =
"nodhcp6\n"
"ipv4only\n"
"option ntp_servers\n"
"option rtems_cmdline\n"
"option tftp_server_name\n"
"option bootfile_name\n"
"define 129 string rtems_cmdline\n"
"timeout 0";

n = write(fd, fhi_cfg, sizeof(fhi_cfg) - 1);
assert(n == (ssize_t) sizeof(fhi_cfg) - 1);

rv = close(fd);
assert(rv == 0);
}

sc = rtems_dhcpcd_start(NULL);
assert(sc == RTEMS_SUCCESSFUL);
}

Heinz

On 2021-08-19 12:16, Peter Dufault wrote:

I'd like to use the DHCP option 17 (Root Path) to get a mount point
for NFS from the DHCP server.

I'm starting dhcp with "rtems_dhcpcd_start(NULL)" so it's starting
with only the argv array of {"dhcpcd", NULL }.

I *think* I need to start it with a customized rtems_dhcpcd_config
that would maybe include a "--option" argument, and retrieve it in a
run hook (I'm using the run hook already to wait for an IP address to
be assigned).  The FreeBSD "--option" documentation is:

-o, --option "option"
Request the DHCP "option" variable for use in
"/usr/local/libexec/dhcpcd-run-hooks".

which would be an argv of {"dhcpcd", "--option", "17", NULL }.

Or is best practice to do something with "rtems-bsd-rc-conf-net.c"?

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering




___
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: Interest in Virtual RTEMS Workshop

[Heinz Junkes]

Hello, Joel,
I am currently organizing a virtual meeting for the EPICS community:
https://indico.fhi-berlin.mpg.de/e/epics2020

This takes place in 2 weeks. If this works well, I would be happy to offer our 
platform (and our experience) for an RTEMS workshop.
But the contributions would have to come from the RTEMS community ;-)
Viele Grüße
Heinz

> On 2. Oct 2020, at 22:02, Joel Sherrill  wrote:
> 
> Hi
> 
> In the past, we have internally discussed an RTEMS Workshop but always got 
> hung up on the basic logistics. There had to be a host site which usually 
> means cost. Although OAR now has access to a facility that could host about 
> 40-50. Travel required to all be in a central location would be burdensome 
> based on time and cost. Remember the core developers are spread across three 
> continents. 
> 
> The pandemic has made it clear that virtual meetings, conferences, birthday 
> parties, etc. are possible. Based on ideas from other open source projects, I 
> am curious if there would be interest in having a virtual workshop.
> 
> One thought is that given the time zones, it might be nice to do it as a TBD 
> number of 2-3 hour sessions which vary in time across 2-3 days. That should 
> let different people participate. One open source project did a 24 hour event 
> which spanned the world. I do not want to do that. :)
> 
> I think recording the presentations beforehand and making them available 
> afterwards would be ideal. I have seen formal setups where questions are 
> restricted to the end of the presentation but like the idea of the presenter 
> able to chat while their presentation is going. 
> 
> In my perfect world, most presentations would be from people using RTEMS, 
> although I expect core developer presentations would add depth to what they 
> are working on and the goals. 
> 
> Is there interest? Would you be willing to present? participate? Advice?
> 
> Thanks.
> 
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Interest in Virtual RTEMS Workshop

[Heinz Junkes]

We are using BlueJeans Events for our workshop/meeting. 

FHI, Heinz Junkes

> On 4. Oct 2020, at 21:15, Joel Sherrill  wrote:
> 
> 
> 
> 
>> On Sun, Oct 4, 2020, 12:49 PM Heinz Junkes  wrote:
>> Hello, Joel,
>> I am currently organizing a virtual meeting for the EPICS community:
>> https://indico.fhi-berlin.mpg.de/e/epics2020
>> 
>> This takes place in 2 weeks. If this works well, I would be happy to offer 
>> our platform (and our experience) for an RTEMS workshop.
>> But the contributions would have to come from the RTEMS community ;-)
> 
> 
> Thanks! Google meet is likely ok. OAR's WebEx account can host up to 100 
> participants. Zoom may even be an option.
> 
> 
> I am kind of hoping to have presentations from the EPICS and CFS communities. 
> Maybe a GSoC project session. And some from core developers on what they are 
> doing. So don't think we don't want to hear about your work even if it is a 
> repeat from the EPICS workshop. :)
> 
> 
>> Viele Grüße
>> Heinz
>> 
>> > On 2. Oct 2020, at 22:02, Joel Sherrill  wrote:
>> > 
>> > Hi
>> > 
>> > In the past, we have internally discussed an RTEMS Workshop but always got 
>> > hung up on the basic logistics. There had to be a host site which usually 
>> > means cost. Although OAR now has access to a facility that could host 
>> > about 40-50. Travel required to all be in a central location would be 
>> > burdensome based on time and cost. Remember the core developers are spread 
>> > across three continents. 
>> > 
>> > The pandemic has made it clear that virtual meetings, conferences, 
>> > birthday parties, etc. are possible. Based on ideas from other open source 
>> > projects, I am curious if there would be interest in having a virtual 
>> > workshop.
>> > 
>> > One thought is that given the time zones, it might be nice to do it as a 
>> > TBD number of 2-3 hour sessions which vary in time across 2-3 days. That 
>> > should let different people participate. One open source project did a 24 
>> > hour event which spanned the world. I do not want to do that. :)
>> > 
>> > I think recording the presentations beforehand and making them available 
>> > afterwards would be ideal. I have seen formal setups where questions are 
>> > restricted to the end of the presentation but like the idea of the 
>> > presenter able to chat while their presentation is going. 
>> > 
>> > In my perfect world, most presentations would be from people using RTEMS, 
>> > although I expect core developer presentations would add depth to what 
>> > they are working on and the goals. 
>> > 
>> > Is there interest? Would you be willing to present? participate? Advice?
>> > 
>> > Thanks.
>> > 
>> > --joel
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> 


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LibBSD PowerPC motorola_shared BSP PCI Support

[Heinz Junkes]

Good morning Chris,
i will now try out libbsd on a MVME6100 (beatnik).
Is the mentioned patch in git? Or do I have to prepare something special?
Thanks Heinz

> On 21. Oct 2020, at 02:44, Chris Johns  wrote:
> 
> On 21/10/20 2:52 am, Sebastian Huber wrote:
>> On 20/10/2020 03:52, chr...@rtems.org wrote:
>> 
>>> Tested on a MVME2700 (mvme2307) BSP:
>>> 
>>> nexus0: 
>>> pcib0 pcibus 0 on motherboard
>>> pci0:  on pcib0
>>> pci0:  at device 0.0 (no driver attached)
>>> pci0:  at device 11.0 (no driver attached)
>>> pci0:  at device 11.1 (no driver attached)
>>> pci0:  at device 12.0 (no driver attached)
>>> pci0:  at device 13.0 (no driver attached)
>>> pci0:  at device 14.0 (no driver attached)
>> Does this mean that the legacy x86 PCI bus driver works on this PowerPC 
>> board?
>> Are there no big-endian vs. little-endian issues?
> 
> It seems there are no issues with the limited testing I have performed. I have
> not done extensive testing but the if_dc.c (tulip driver) does probe the bus 
> and
> the correct device/vendor id is returned. The fact there currently is no 
> support
> for the 21140 on the MVMEW2700 in the driver is different issue and not 
> related
> to this patch.
> 
> I had a detailed look at the few calls that are being made and everything 
> seems
> to work as expected. There is a lot of hardware in the PCI bridges on these
> boards to handle endian mapping. The same hardware set up is being used as 
> 4.10
> and legacy stack combination and that works.
> 
> I suspect there may be changes needed in relation to resource allocations but 
> I
> thought those can be in follow up patches.
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LibBSD PowerPC motorola_shared BSP PCI Support

[Heinz Junkes]

I am currently trying git rtems6.

../source-builder/sb-set-builder --prefix=$HOME/.rtems --log 
powerpc_beatnik.log --no-clean --target=powerpc-rtems6  
--with-rtems-bsp=beatnik 6/rtems-powerpc 6/rtems-kernel

works …

Unfortunately It fails here:

../source-builder/sb-set-builder --prefix=$HOME/.rtems --log libbsd.log 
--no-clean --target=powerpc-rtems6 --with-rtems-bsp=beatnik 
--host=powerpc-rtems6 6/rtems-libbsd

...
[1562/1948] Compiling freebsd/sbin/nvmecontrol/ns.c
In file included from 
/home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/cstdlib:75,
 from 
/home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/stdlib.h:36,
 from ../../freebsd/sys/sys/libkern.h:216,
 from ../../freebsd/sys/sys/systm.h:543,
 from ../../freebsd/sys/sys/mbuf.h:42,
 from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
/home/ad/.rtems/powerpc-rtems6/include/stdlib.h:309:6: error: conflicting 
declaration of C function 'void qsort_r(void*, size_t, size_t, int (*)(const 
void*, const void*, void*
), void*)'
  309 | void qsort_r (void *__base, size_t __nmemb, size_t __size, int 
(*_compar)(const void *, const void *, void *), void *__thunk);
  |  ^~~
In file included from ../../freebsd/sys/sys/systm.h:543,
 from ../../freebsd/sys/sys/mbuf.h:42,
 from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
../../freebsd/sys/sys/libkern.h:211:7: note: previous declaration 'void 
qsort_r(void*, size_t, size_t, void*, int (*)(void*, const void*, const void*))'
  211 | void  qsort_r(void *base, size_t nmemb, size_t size, void *thunk,
  |   ^~~

Waf: Leaving directory 
`/home/ad/RTEMS_DEV/rtems-source-builder/rtems/build/rtems-libbsd-d964a6703c705cc92fd053bcefc08bb3b6baa0e2-powerpc-rtems6-1/rtems-libbsd-d964a6703c705cc9
2fd053bcefc08bb3b6baa0e2/build/powerpc-rtems6-beatnik-default'
Build failed
 -> task in 'bsd' failed with exit status 1 (run with -v to display more 
information)
shell cmd failed: /bin/sh -ex  
/home/ad/RTEMS_DEV/rtems-source-builder/rtems/build/rtems-libbsd-d964a6703c705cc92fd053bcefc08bb3b6baa0e2-powerpc-rtems6-1/do-build
error: building 
rtems-libbsd-d964a6703c705cc92fd053bcefc08bb3b6baa0e2-powerpc-rtems6-1


Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 27. Oct 2020, at 05:06, Chris Johns  wrote:
> 
> On 26/10/20 7:32 pm, Heinz Junkes wrote:
>> Good morning Chris,
>> i will now try out libbsd on a MVME6100 (beatnik).
>> Is the mentioned patch in git? 
> 
> The PCI patch is in rtems-libbsd.git on the master and 6-freebsd-12 branches.
> 
>> Or do I have to prepare something special?
> 
> Yes I think you may need to patch libbsd for the beatnik bvoard. I have not
> looked at that board and the net drivers it needs. The current list is we have
> in libbsd is:
> 
> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h?h=6-freebsd-12
> 
> The BSP support is handled here:
> 
> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h?h=6-freebsd-12
> 
> The define is based on the header guard for the BSP:
> 
> https://git.rtems.org/rtems/tree/bsps/powerpc/beatnik/include/bsp.h#n25
> 
> I hope this helps.
> 
> Chris



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LibBSD PowerPC motorola_shared BSP PCI Support

[Heinz Junkes]

Thanks, I got further and the first start doesn't look that bad ;-)


Welcome to RTEMS rtems-6.0.0 (PowerPC/Generic (classic FPU)/beatnik)
CPU: MPC7457
Board Type: MVME6100-0163 (S/N E173D27)
Bus Clock Freq:   1 Hz
CPU Clock Freq:  126654 Hz
Memory:   536870912 bytes
-
Now BSP_mem_size = 0x1fe0
Configuration.work_space_size = 2033620
Page table setup finished; will activate it NOW...
Going to start PCI buses scanning and initialization
Number of PCI buses found is : 3
MSR 0x2003032
Exit from bspstart
unable to find the universe in pci config space
Tundra Tsi148 PCI-VME bridge detected at 0x8110, IRQ 84
Tsi148 Outbound Ports:
Port  VME-Addr   Size   PCI-Adrs   Mode:
0:0x2000 0x0e00 0x9000 A32, SUP, D32, SCT
1:0x 0x00ff 0x9f00 A24, SUP, D32, SCT
2:0x 0x0001 0x9fff A16, SUP, D32, SCT
7:0x 0x0100 0x9e00 CSR, SUP, D32, SCT
Tsi148 Inbound Ports:
Port  VME-Addr   Size   PCI-Adrs   Mode:
0:0x9000 0x1fe0 0x A32, PGM, DAT, SUP, USR, MBLT, BLT
vmeTsi148 IRQ manager: looking for registers on VME...
Trying to find CSR on VME...
vmeTsi148 - IRQ manager using VME CSR to flush FIFO
Registering /dev/console as minor 0 (==/dev/ttyS0)
fatal source: RTEMS_FATAL_SOURCE_EXCEPTION
exception vector 4 (0x4)
  next PC or address of fault = 0xfffc
  saved MSR = 0x42003032
  context = task, ISR nest level = 0
  thread dispatch disable level = 1
  R0  = 0x00088c0c R1  = 0x006e91d0 R2  = 0x004da928 R3  = 0x001f
  R4  = 0x R5  = 0x R6  = 0x5f997dec R7  = 0x
  R8  = 0x0004 R9  = 0x R10 = 0x005835dc R11 = 0x5f997dec
  R12 = 0x005c R13 = 0x00693b40 R14 = 0x R15 = 0x
  R16 = 0x0020 R17 = 0x0068c460 R18 = 0x0068c48c R19 = 0x
  R20 = 0x R21 = 0x R22 = 0x R23 = 0x
  R24 = 0x R25 = 0x R26 = 0x R27 = 0x
  R28 = 0x R29 = 0x0068c330 R30 = 0x0020 R31 = 0x0009
  CR  = 0x82200424
  CTR = 0x
  XER = 0x2000
  LR  = 0x00088c0c
  DAR = 0x
  executing thread ID = 0x09010001, name = IDLE
Stack Trace:
  IP: 0xfffc, LR: 0x00088c0c
--^ 0x00088b24--^ 0x003f1030--^ 0x310c
bsp_fatal_extension(): RTEMS terminated -- no way back to MotLoad so I reset 
the card
Printing a stack trace for your convenience :-)

0x04158380--> 0x04158380--> 0x00547920--> 0x00548556--> 0x04170612
0x04140740--> 0x00560140--> 0x00559908--> 0x04132912--> 0x00012556


Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 27. Oct 2020, at 18:41, Sebastian Huber 
>  wrote:
> 
> 
> On 27/10/2020 15:41, Joel Sherrill wrote:
>> 
>> 
>> On Tue, Oct 27, 2020 at 9:23 AM Heinz Junkes > <mailto:jun...@fhi-berlin.mpg.de>> wrote:
>> 
>>I am currently trying git rtems6.
>> 
>>../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
>>powerpc_beatnik.log --no-clean --target=powerpc-rtems6
>>--with-rtems-bsp=beatnik 6/rtems-powerpc 6/rtems-kernel
>> 
>>works …
>> 
>>Unfortunately It fails here:
>> 
>>../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
>>libbsd.log --no-clean --target=powerpc-rtems6
>>--with-rtems-bsp=beatnik --host=powerpc-rtems6 6/rtems-libbsd
>> 
>>...
>>[1562/1948] Compiling freebsd/sbin/nvmecontrol/ns.c
>>In file included from
>>/home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/cstdlib:75,
>> from
>>/home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/stdlib.h:36,
>> from ../../freebsd/sys/sys/libkern.h:216,
>> from ../../freebsd/sys/sys/systm.h:543,
>> from ../../freebsd/sys/sys/mbuf.h:42,
>> from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
>>/home/ad/.rtems/powerpc-rtems6/include/stdlib.h:309:6: error:
>>conflicting declaration of C function 'void qsort_r(void*, size_t,
>>size_t, int (*)(const void*, const void*, void*
>>), void*)'
>>  309 | void qsort_r (void *__base, size_t __nmemb, size_t __size,
>>int (*_compar)(const void *, const void *, void *), void *__thunk);
>>  |  ^~~
>>In file included from ../../freebsd/sys/sys/systm.h:543,
>> from ../../freebsd/sys/sys/mbuf.h:42,
>> from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
>>../../freebsd/sys/sys/libkern.h:211:7: note: previous declaration
>>'void qsort_r(void*, size_t, size_t, void*, int (*)(void*, const
>>void*, const void*))'
>>  211 | void  qsort_r

Re: LibBSD PowerPC motorola_shared BSP PCI Support

[Heinz Junkes]

I can now run the test programs of libbsd. But on the MVME6100
no network interfaces gets found.

MVME6100> netShut
/-
config addr is 0xf1000cf8
config data is 0xf1000cfc
Welcome to RTEMS rtems-6.0.0 (PowerPC/Generic (classic FPU)/beatnik)
CPU: MPC7457
Board Type: MVME6100-0163 (S/N E173D27)
Bus Clock Freq:   1 Hz
CPU Clock Freq:  126654 Hz
Memory:   536870912 bytes
-
Now BSP_mem_size = 0x1fe0
Configuration.work_space_size = ed620
Page table setup finished; will activate it NOW...
Going to start PCI buses scanning and initialization
Number of PCI buses found is : 3
MSR 0x2003032
Exit from bspstart
unable to find the universe in pci config space
Tundra Tsi148 PCI-VME bridge detected at 0x8110, IRQ 84
Tsi148 Outbound Ports:
Port  VME-Addr   Size   PCI-Adrs   Mode:
0:0x2000 0x0e00 0x9000 A32, SUP, D32, SCT
1:0x 0x00ff 0x9f00 A24, SUP, D32, SCT
2:0x 0x0001 0x9fff A16, SUP, D32, SCT
7:0x 0x0100 0x9e00 CSR, SUP, D32, SCT
Tsi148 Inbound Ports:
Port  VME-Addr   Size   PCI-Adrs   Mode:
0:0x9000 0x1fe0 0x A32, PGM, DAT, SUP, USR, MBLT, BLT
vmeTsi148 IRQ manager: looking for registers on VME...
Trying to find CSR on VME...
vmeTsi148 - IRQ manager using VME CSR to flush FIFO
Registering /dev/console as minor 0 (==/dev/ttyS0)


*** BEGIN OF TEST LIBBSD DHCPCD 1 ***
*** TEST VERSION: 6.0.0.5f4fd63a0c2b4b0657b64abdcfa70c47bee21c52
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.2.1 20201026 (RTEMS 6, RSB 
5f4fd63a0c2b4b0657b64abdcfa70c47bee21c52, Newlib 17b7dfc)

RTEMS Shell on /dev/console. Use 'help' to list commands.
SHLL [/] # xus0: 
[zone: unpcb] kern.ipc.maxsockets limit reached
info: lo0: link state changed to UP
info: version 6.2.1 starting
err: no valid interfaces found
warning: no interfaces have a carrier

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 27. Oct 2020, at 18:41, Sebastian Huber 
>  wrote:
> 
> 
> On 27/10/2020 15:41, Joel Sherrill wrote:
>> 
>> 
>> On Tue, Oct 27, 2020 at 9:23 AM Heinz Junkes > <mailto:jun...@fhi-berlin.mpg.de>> wrote:
>> 
>>I am currently trying git rtems6.
>> 
>>../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
>>powerpc_beatnik.log --no-clean --target=powerpc-rtems6
>>--with-rtems-bsp=beatnik 6/rtems-powerpc 6/rtems-kernel
>> 
>>works …
>> 
>>Unfortunately It fails here:
>> 
>>../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
>>libbsd.log --no-clean --target=powerpc-rtems6
>>--with-rtems-bsp=beatnik --host=powerpc-rtems6 6/rtems-libbsd
>> 
>>...
>>[1562/1948] Compiling freebsd/sbin/nvmecontrol/ns.c
>>In file included from
>>/home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/cstdlib:75,
>> from
>>/home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/stdlib.h:36,
>> from ../../freebsd/sys/sys/libkern.h:216,
>> from ../../freebsd/sys/sys/systm.h:543,
>> from ../../freebsd/sys/sys/mbuf.h:42,
>> from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
>>/home/ad/.rtems/powerpc-rtems6/include/stdlib.h:309:6: error:
>>conflicting declaration of C function 'void qsort_r(void*, size_t,
>>size_t, int (*)(const void*, const void*, void*
>>), void*)'
>>  309 | void qsort_r (void *__base, size_t __nmemb, size_t __size,
>>int (*_compar)(const void *, const void *, void *), void *__thunk);
>>  |  ^~~
>>In file included from ../../freebsd/sys/sys/systm.h:543,
>> from ../../freebsd/sys/sys/mbuf.h:42,
>> from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
>>../../freebsd/sys/sys/libkern.h:211:7: note: previous declaration
>>'void qsort_r(void*, size_t, size_t, void*, int (*)(void*, const
>>void*, const void*))'
>>  211 | void  qsort_r(void *base, size_t nmemb, size_t size, void
>>*thunk,
>>  |   ^~~
>> 
>>Waf: Leaving directory
>>
>> `/home/ad/RTEMS_DEV/rtems-source-builder/rtems/build/rtems-libbsd-d964a6703c705cc92fd053bcefc08bb3b6baa0e2-powerpc-rtems6-1/rtems-libbsd-d964a6703c705cc9
>>2fd053bcefc08bb3b6baa0e2/build/powerpc-rtems6-beatnik-default'
>>Build failed
>> -> task in 'bsd' failed with exit status 1 (run with -v to
>>display more information)
>>shell cmd failed: /bin/sh -ex
>>
>> /hom

Re: LibBSD PowerPC motorola_shared BSP PCI Support

[Heinz Junkes]

I have now changed to a more modern board: MVME2500
And built rtems6 and libbsd for qoriq_e500.


Unfortunately the board hangs when loading the image:

MVME2500=> setenv tfile dhcpcd02_6
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 32 ms (377 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'dhcpcd02_6.img'.
Load address: 0x1000
Loading: #
 
 10.3 MiB/s
done
Bytes transferred = 1709285 (1a14e5 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
   Image Name:   dhcpcd02
   Created:  2020-10-29  12:38:52 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1709221 Bytes = 1.6 MiB
   Load Address: 4000
   Entry Point:  4000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
   Booting using the fdt blob at 0x2000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 03ff9000, end 03fff04a ... OK

Hangs ...



With RTEMS5 in spring it looked like this:


MVME2500=> setenv tfile dhcpcd02
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 32 ms (377 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'dhcpcd02.img'.
Load address: 0x1000
Loading: #
 ###
 10 MiB/s
done
Bytes transferred = 1455058 (1633d2 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
   Image Name:   dhcpcd02
   Created:  2020-02-17  13:51:47 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1454994 Bytes = 1.4 MiB
   Load Address: 4000
   Entry Point:  4000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
   Booting using the fdt blob at 0x2000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 03ff9000, end 03fff04a ... OK
*** LIBBSD DHCPCD 2 TEST ***
nexus0: 

RTEMS Shell on /dev/console. Useo 'help' to list commands.
SHLL [/] # bus0:  on nexus0
simplebus0:  on ofwbus0
simplebus1:  mem 0xffe05000-0xffe05fff irq 3 
on ofwbus0
tsec0:  mem 0x24000-0x24fff irq 
13,14,18 on simplebus0
miibus0:  on tsec0
ukphy0:  PHY 1 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
info: tsec0: Ethernet address: ec:9e:cd:19:3c:61
tsec1:  mem 0x25000-0x25fff irq 
19,20,24 on simplebus0
miibus1:  on tsec1
ukphy1:  PHY 7 on miibus1
ukphy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
info: tsec1: Ethernet address: ec:9e:cd:19:3c:62
tsec2:  mem 0x26000-0x26fff irq 
15,16,17 on simplebus0
miibus2:  on tsec2
ukphy2:  PHY 3 on miibus2
ukphy2:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
info: tsec2: Ethernet address: ec:9e:cd:19:3c:63
[zone: unpcb] kern.ipc.maxsockets limit reached
info: lo0: link state changed to UP
info: version 6.2.1 starting
info: tsec0: link state changed to DOWN
info: tsec1: link state changed to DOWN
info: tsec2: link state changed to DOWN
warning: no interfaces have a carrier
info: tsec0: waiting for carrier
info: tsec1: waiting for carrier
info: tsec2: waiting for carrier
W���to UP
info: tsec0: carrier acquired
info: DUID 00:01:00:01:e9:6d:a1:84:ec:9e:cd:19:3c:61
info: tsec0: IAID cd:19:3c:61
info: tsec1: link state changed to UP
...




Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 29. Oct 2020, at 12:07, Heinz Junkes  wrote:
> 
> I can now run the test programs of libbsd. But on the MVME6100
> no network interfaces gets found.
> 
> MVME6100> netShut
> /-
> config addr is 0xf1000cf8
> config data is 0xf1000cfc
> Welcome to RTEMS rtems-6.0.0 (PowerPC/Generic (classic FPU)/beatnik)
> CPU: MPC7457
> Board Type: MVME6100-0163 (S/N E173D27)
> Bus Clock Freq:   1 Hz
> CPU Clock Freq:  126654 Hz
> Memory:   536870912 bytes
> -
> Now BSP_mem_size = 0x1fe0
> Configuration.work_space_size = ed620
> Page table setup finished; will activate it NOW...
> Going to start PCI buses scanning and initialization
> Number of PCI buses found is : 3
> MSR 0x2003032
> Exit from bspstart
> unable to find the universe in pci config space
> Tundra Tsi148 PCI-VME bridge detected at 0x8110, IRQ 84
> Tsi148 Outbound Ports:
> Port  VME-Addr   Si

Re: LibBSD PowerPC motorola_shared BSP PCI Support

[Heinz Junkes]

Hello, Joel,

You are right, for the MVME6100 the configuration in libbsd is still missing. 
There is also missing the
old NIC. Chris has already sent me information about it. I'll try to do that 
next week.
But I have to put two MVME6100s into production by the end of the month. If I 
can't do that with libbsd, I 
will use the CPUs with RTEMS5 and the legacy stack. This has worked so far with 
PCI/VME.

The QorIQ based MVME2500 worked with the pre-RTEMS5. Sebastian had made it work 
with libbsd.
PCI/VMEbus was still missing.

Support is important to me because I also have some very modern boards with the 
Qoriq CPU in the pipeline.
For example IFC_1420 from IOxOS 
(https://www.ioxos.ch/wp-content/uploads/2018/02/IFC_1420_SDS_A0.pdf). This
is a CPU for MTCA.4 which is used in modern accelerator systems.

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 30. Oct 2020, at 03:31, Joel Sherrill  wrote:
> 
> 
> 
> On Thu, Oct 29, 2020, 6:07 AM Heinz Junkes  wrote:
> I can now run the test programs of libbsd. But on the MVME6100
> no network interfaces gets found.
> 
> MVME6100> netShut
> /-
> config addr is 0xf1000cf8
> config data is 0xf1000cfc
> Welcome to RTEMS rtems-6.0.0 (PowerPC/Generic (classic FPU)/beatnik)
> CPU: MPC7457
> Board Type: MVME6100-0163 (S/N E173D27)
> Bus Clock Freq:   1 Hz
> CPU Clock Freq:  126654 Hz
> Memory:   536870912 bytes
> -
> Now BSP_mem_size = 0x1fe0
> Configuration.work_space_size = ed620
> Page table setup finished; will activate it NOW...
> Going to start PCI buses scanning and initialization
> Number of PCI buses found is : 3
> MSR 0x2003032
> Exit from bspstart
> unable to find the universe in pci config space
> Tundra Tsi148 PCI-VME bridge detected at 0x8110, IRQ 84
> Tsi148 Outbound Ports:
> Port  VME-Addr   Size   PCI-Adrs   Mode:
> 0:0x2000 0x0e00 0x9000 A32, SUP, D32, SCT
> 1:0x 0x00ff 0x9f00 A24, SUP, D32, SCT
> 2:0x 0x0001 0x9fff A16, SUP, D32, SCT
> 7:0x 0x0100 0x9e00 CSR, SUP, D32, SCT
> Tsi148 Inbound Ports:
> Port  VME-Addr   Size   PCI-Adrs   Mode:
> 0:0x9000 0x1fe0 0x A32, PGM, DAT, SUP, USR, MBLT, BLT
> vmeTsi148 IRQ manager: looking for registers on VME...
> Trying to find CSR on VME...
> vmeTsi148 - IRQ manager using VME CSR to flush FIFO
> Registering /dev/console as minor 0 (==/dev/ttyS0)
> 
> 
> *** BEGIN OF TEST LIBBSD DHCPCD 1 ***
> *** TEST VERSION: 6.0.0.5f4fd63a0c2b4b0657b64abdcfa70c47bee21c52
> *** TEST STATE: EXPECTED_PASS
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 10.2.1 20201026 (RTEMS 6, RSB 
> 5f4fd63a0c2b4b0657b64abdcfa70c47bee21c52, Newlib 17b7dfc)
> 
> RTEMS Shell on /dev/console. Use 'help' to list commands.
> SHLL [/] # xus0: 
> [zone: unpcb] kern.ipc.maxsockets limit reached
> info: lo0: link state changed to UP
> info: version 6.2.1 starting
> err: no valid interfaces found
> warning: no interfaces have a carrier
> 
> Afaik the mvme6100 does not have a configuration in libbsd. My recollection 
> (which could be wrong) is that there isn't a libbsd driver in the tree for 
> the NIC.
> 
> There was a table in Chris' EPICS slides about which bsps we thought needed 
> attention with notes on the drivers.
> 
> And the mvme2500 wasn't on the list. I think we may need an alias or some 
> documentation on this BSP. 
> 
> Viele Grüße
> Heinz Junkes
> --
> Experience directly varies with equipment ruined.
> 
> 
> 
> > On 27. Oct 2020, at 18:41, Sebastian Huber 
> >  wrote:
> > 
> > 
> > On 27/10/2020 15:41, Joel Sherrill wrote:
> >> 
> >> 
> >> On Tue, Oct 27, 2020 at 9:23 AM Heinz Junkes  >> <mailto:jun...@fhi-berlin.mpg.de>> wrote:
> >> 
> >>I am currently trying git rtems6.
> >> 
> >>../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
> >>powerpc_beatnik.log --no-clean --target=powerpc-rtems6
> >>--with-rtems-bsp=beatnik 6/rtems-powerpc 6/rtems-kernel
> >> 
> >>works …
> >> 
> >>Unfortunately It fails here:
> >> 
> >>../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
> >>libbsd.log --no-clean --target=powerpc-rtems6
> >>--with-rtems-bsp=beatnik --host=powerpc-rtems6 6/rtems-libbsd
> >> 
> >>...
> >>[1562/1948] Compiling freebsd/sbin/nvmecontrol/ns.c
> >>In file included from
> >>/home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/

Re: LibBSD PowerPC motorola_shared BSP PCI Support

[Heinz Junkes]

Hello, Chris,
unfortunately it is not quite so simple. The Beatnik board uses 
for the Ethernet the Marvell Discovery II MV64360 (GT64360)
and there two of the three built-in Ethernet controllers. 

Till Straumann has written a driver for it called "mve" and unfortunately it 
is not available in freebsd. Probably too rare or I did not search properly. 

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 27. Oct 2020, at 05:06, Chris Johns  wrote:
> 
> On 26/10/20 7:32 pm, Heinz Junkes wrote:
>> Good morning Chris,
>> i will now try out libbsd on a MVME6100 (beatnik).
>> Is the mentioned patch in git? 
> 
> The PCI patch is in rtems-libbsd.git on the master and 6-freebsd-12 branches.
> 
>> Or do I have to prepare something special?
> 
> Yes I think you may need to patch libbsd for the beatnik bvoard. I have not
> looked at that board and the net drivers it needs. The current list is we have
> in libbsd is:
> 
> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h?h=6-freebsd-12
> 
> The BSP support is handled here:
> 
> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h?h=6-freebsd-12
> 
> The define is based on the header guard for the BSP:
> 
> https://git.rtems.org/rtems/tree/bsps/powerpc/beatnik/include/bsp.h#n25
> 
> I hope this helps.
> 
> Chris



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Question about the definition of _XOPEN_SOURCE

[Heinz Junkes]

Please excuse me if this question has already been answered. But unfortunately 
I have not been able to find a clear statement.

Why is RTEMS _XOPEN_SOURCE not set with a value when building a BSP with 
--enable-posix?

in the rtems-libbsd you can find a definition in some places.
z.B. in dhcpd/configure -D_XOPEN_SOURCE=700 and
in glibc-bugs.h #define _XOPEN_SOURCE 500
…

That seems a little unstructured to me. I'm sure there's an explanation why 
this is so complicated. But which value is the correct one e.g. for PowerPC and 
RTEMS 5.1?

Danke Heinz

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

Re: Question about the definition of _XOPEN_SOURCE

[Heinz Junkes]

Hi Sebastian,
_XOPEN_SOURCE is not set anywhere in the RTEMS header files etc..
Heinz

> On 3. Jan 2021, at 11:04, Sebastian Huber 
>  wrote:
> 
> Hello Heinz,
> 
> On 01/01/2021 18:46, Heinz Junkes wrote:
>> Please excuse me if this question has already been answered. But 
>> unfortunately I have not been able to find a clear statement.
>> 
>> Why is RTEMS _XOPEN_SOURCE not set with a value when building a BSP with 
>> --enable-posix?
>> 
>> in the rtems-libbsd you can find a definition in some places.
>> z.B. in dhcpd/configure -D_XOPEN_SOURCE=700 and
>> in glibc-bugs.h #define _XOPEN_SOURCE 500
>> …
>> 
>> That seems a little unstructured to me. I'm sure there's an explanation why 
>> this is so complicated. But which value is the correct one e.g. for PowerPC 
>> and RTEMS 5.1?
> 
> the so called feature test macros should be defined by the application:
> 
> https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
> 
> https://man7.org/linux/man-pages/man7/feature_test_macros.7.html
> 
> Which function is not defined in your setup?
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> 



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How do we know what priority of the Init task is?

[Heinz Junkes]

I would have a similar question ;-)

What is the priority of the POSIX_Init - Task (as Posix-Prio)?
Danke Heinz

> On 23. Feb 2021, at 06:43, Richi Dubey  wrote:
> 
> Hi,
> 
> Just confirming, The initial priority is 1, and when converted to 
> _RTEMS_Priority_To_core, it becomes 2 (because of the append indicator added 
> by default map priority). Right?
> 
> On Tue, Nov 17, 2020 at 11:19 PM Richi Dubey  wrote:
> Awesome, thanks! 
> 
> On Tue, Nov 17, 2020 at 9:53 PM Joel Sherrill  wrote:
> 
> 
> On Tue, Nov 17, 2020, 9:50 AM Richi Dubey  wrote:
> Hi,
> 
> Sometimes the priority of the Init task is not mentioned in the source code 
> of the test suites of the headers files included in it (ex. see tm24). Can 
> someone please let me know how we can understand what the priority of the 
> Init task is? Is there a constant value for Init's priority when it's not 
> explicitly mentioned?
> 
> Yes. It defaults to 1. This is defaulted in one of the confdef subfiles now 
> and documented in the configuring a system chapter if the Classic API Guide 
> 
> Thanks,
> Richi.
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How do we know what priority of the Init task is?

[Heinz Junkes]

what I have just never understood

POSIX  Prio 2 ist LOW Priority
RTEMS Prio 1 is HIGH Priority

Heinz


> On 23. Feb 2021, at 09:17, Sebastian Huber 
>  wrote:
> 
> On 23/02/2021 08:36, Heinz Junkes wrote:
> 
>> I would have a similar question ;-)
>> 
>> What is the priority of the POSIX_Init - Task (as Posix-Prio)?
> There is no option to configure the priority of the POSIX initialization 
> thread, so the default priority of 2 is used, see 
> _POSIX_Threads_Default_attributes.
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> 



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How do we know what priority of the Init task is?

[Heinz Junkes]

Thank you for the detailed explanation. I may have asked my question 
incorrectly.

If I choose POSIX_Init for RTEMS the Init process has a very low priority and 
if I use 
the normal (RTEMS) Init a very high priority. This does not fit in my opinion.

Shouldn't the POSIX_Init - process have the prio 98 or so?

Heinz

> On 23. Feb 2021, at 15:17, Joel Sherrill  wrote:
> 
> 
> 
> On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes  wrote:
> what I have just never understood
> 
> POSIX  Prio 2 ist LOW Priority
> RTEMS Prio 1 is HIGH Priority
> 
> In general, RTOS threading APIs tended to use 1 as a high priority. The RTEMS 
> Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those 
> all follow 1 is high priority model.
> 
> POSIX calls for the opposite range. Not sure why. Interestingly, I had a 
> discussion 
> with the main kernel person for another RTOS about this in a standards 
> meeting 
> and he noted that although every implementation of POSIX threads we both knew
> about does use low number as low priority, it is not as explicit in the POSIX 
> standard
> as one would think. We have just all read the same text that way since POSIX 
> is 
> careful to say raises or lowers priority and the implication we all saw is 
> that the 
> numbers follow that languge. But at this point, the priorities run this way 
> for no
> other reason than history and compatibility. For all I know, it may even be 
> baked 
> into the POSIX Compliance Test Suite. Any program with hard-coded numbers
> certainly has it baked in.
> 
> While I am beating this topic mercilessly, let me point out that POSIX only 
> calls
> for a minimum of 32 priority levels. Portable programs cannot assume more.
> And the default attribute set for all POSIX threading and synchronization 
> objects is implementation defined. Portable programs should always explicitly
> set all attributes for pthreads, mutexes, etc. 
> 
> The RTOS choice probably reflects using a bitmap to represent if a thread
> is present on the FIFO for each priority. This would make a bit index map
> directly to priority in most cases. This design dates back to at least VMS
> where you have 32 priority levels because you could scan 32 bits in a
> single instruction. This was carried forward into Windows NT. 
> 
> THe diversity of choices reminded me of this quote from Andrew Tanenbaum:
> 
> "The nice thing about standards is that there are so many of them to choose 
> from."
> 
> In the end different people had an arbitrary decision and picked different 
> answers. Ada task priority is another set of choices. :)
> 
> --joel
> 
> 
> Heinz
> 
> 
> > On 23. Feb 2021, at 09:17, Sebastian Huber 
> >  wrote:
> > 
> > On 23/02/2021 08:36, Heinz Junkes wrote:
> > 
> >> I would have a similar question ;-)
> >> 
> >> What is the priority of the POSIX_Init - Task (as Posix-Prio)?
> > There is no option to configure the priority of the POSIX initialization 
> > thread, so the default priority of 2 is used, see 
> > _POSIX_Threads_Default_attributes.
> > 
> > -- 
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> > 
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[Heinz Junkes]

Hallo Vijay,
I still have to ask a question ;-)

When building EPICS, we distinguish legacy stack or libbsd with the help of
the target.cfg file. (e.g. powerpc-rtems6/beatnik/make/target.cfg).

Earlier in it was 
RTEMS_HAS_NETWORKING = yes (for legacy stack) and no (for new bsd stack).

Now  this flag will no be set with the waf build in your extra net-legacy repo.

How should we now find out if the target was built with legacyStack or with 
libbsd?

Danke Heinz


> On 3. Mar 2021, at 21:03, Vijay Kumar Banerjee  wrote:
> 
> On Wed, Mar 3, 2021 at 12:37 PM junkes  wrote:
>> 
>> Hi Vijay,
>> I tried it again:
>> 
> Hi Heinz,
> 
> I'm really sorry that the build crashed again. I missed the telnetd.h
> file probably because it was somewhere in my build prefix from one of
> the rtems builds. I have pushed a fix on the rtems repo and the
> rtems-net-legacy repo. This time I was more thorough and used a new
> prefix location, I believe it won't break this time.
> 
> Thank you for helping with the testing. I really appreciate it.
> 
> 
> Best regards,
> Vijay
> 
>> # building kernel
>> #git clone git://git.rtems.org/rtems.git kernel
>> git clone git://git.rtems.org/vijay/rtems.git kernel
>> cd kernel
>> git checkout devel-no-libnet
>> 
>> # build and install bsp
>> # 1. Test with waf
>> #-e "s|RTEMS_NETWORKING = False|RTEMS_NETWORKING = True|" \
>> ./waf bsp_defaults --rtems-bsps=powerpc/beatnik > config.ini
>> sed -i \
>> -e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
>> -e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
>> config.ini
>> ./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6
>> ./waf
>> ./waf install
>> 
>> cd ..
>> 
>> # building extra legacy net
>> git clone git://git.rtems.org/vijay/rtems-net-legacy.git legacyNet
>> cd legacyNet
>> git submodule init
>> git submodule update
>> 
>> ./waf configure --prefix=/home/junkes/MVME6100_testing/rtems/6
>> 
>> ./waf build --rtems-archs=powerpc --rtems-bsps=beatnik
>> 
>> 
>> Much better, but still a missing file?
>> 
>> [125/235] Compiling libc/res_mkquery.c
>> [126/235] Compiling libc/inet_lnaof.c
>> [127/235] Compiling librpc/src/xdr/xdr_array.c
>> ../../telnetd/check_passwd.c:70:10: fatal error: rtems/telnetd.h: No
>> such file or directory
>>70 | #include 
>>   |  ^
>> compilation terminated.
>> 
>> ../../telnetd/telnetd.c:57:10: fatal error: rtems/telnetd.h: No such
>> file or directory
>>57 | #include 
>>   |  ^
>> compilation terminated.
>> 
>> Waf: Leaving directory
>> `/home/junkes/MVME6100_testing/legacyNet/build/powerpc-rtems6-beatnik'
>> Build failed
>>  -> task in 'network_objects' failed with exit status 1 (run with -v to
>> display more information)
>>  -> task in 'network_objects' failed with exit status 1 (run with -v to
>> display more information)
>> 
>> Heinz



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[Heinz Junkes]

I have installed the legacy package but the files are not there.
I guess they were just forgotten in the legacy package.
Heinz


> On 4. Mar 2021, at 14:52, Joel Sherrill  wrote:
> 
> Did you install the legacy package? If you installed it in the same place
> as the RTEMS 5 BSP, I would expect it to be there. This SHOULD be
> equivalent to prior split.



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Can no longer find the _edata symbol in the linkcmd's for qoriq_e500

[Heinz Junkes]

Is there an equivalent to _edata (I still use it for beatnik)?

Danke Heinz



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems6 master build tests for erc32 fail : undefined reference to `_Timespec_Is_non_negative'

[Heinz Junkes]

Thanks, the patch from Ryan helped.

With the waf-builder it works very well. 
This  semester I have a course Real Time Systems and in Germany the courses
are all virtual (students are at home). This means that students cannot
use our preconfigured lab computers and have to install the RTEMS on
their private devices. And now you can find on the Internet unfortunately
many (partly old) how to install RTEMS and I have tried to understand the
problems the students have.

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 21. Jun 2021, at 22:18, Joel Sherrill  wrote:
> 
> The autoconf build system is on life support and fading fast but 
> this one was fixable and a patch was pushed. I tested with 
> sparc/leon3 and Ryan provided a patch. Try again please.
> 
> There are only a couple of issues remaining before the autoconf
> build system is removed from the master so it is time to figure
> out the waf build system if you haven't already. :)
> 
> --joel
> 
> On Mon, Jun 21, 2021 at 10:24 AM junkes  wrote:
> Making all-am in fstests
> make[5]: Entering directory 
> '/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/testsuites/fstests'
> sparc-rtems6-gcc  -mcpu=cypress -O2 -g -ffunction-sections 
> -fdata-sections -Wall -Wmissing-prototypes 
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs 
> -B./../../lib/libbsp/sparc/erc32 
> -B/home/junkes/VE/kernel/bsps/sparc/erc32/start -specs bsp_specs -qrtems 
> -L./../../cpukit -L/home/junkes/VE/kernel/bsps/sparc/shared/start 
> -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections 
> -o fsimfsconfig01.exe fsimfsconfig01/fsimfsconfig01-init.o 
> ./../../lib/libbsp/sparc/erc32/librtemsbsp.a 
> ./../../cpukit/librtemscpu.a ./../../cpukit/librtemstest.a
> /home/junkes/VE/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
>  
> ./../../cpukit/librtemscpu.a(utimensat.o): in function 
> `rtems_filesystem_utime_update':
> /home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/cpukit/../../../../../../kernel/c/src/../../cpukit/libcsupport/src/utimensat.c:153:
>  
> undefined reference to `_Timespec_Is_non_negative'
> /home/junkes/VE/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
>  
> /home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/cpukit/../../../../../../kernel/c/src/../../cpukit/libcsupport/src/utimensat.c:157:
>  
> undefined reference to `_Timespec_Is_non_negative'
> collect2: error: ld returned 1 exit status
> make[5]: *** [Makefile:1905: fsimfsconfig01.exe] Error 1
> make[5]: Leaving directory 
> '/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/testsuites/fstests'
> make[4]: *** [Makefile:663: fstests] Error 2
> make[4]: Leaving directory 
> '/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32/testsuites'
> make[3]: *** [Makefile:1342: testsuites] Error 2
> make[3]: Leaving directory 
> '/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32'
> make[2]: *** [Makefile:822: all-recursive] Error 1
> make[2]: Leaving directory 
> '/home/junkes/VE/build/b-erc32/sparc-rtems6/c/erc32'
> make[1]: *** [Makefile:289: all-recursive] Error 1
> make[1]: Leaving directory 
> '/home/junkes/VE/build/b-erc32/sparc-rtems6/c'
> make: *** [Makefile:410: all-recursive] Error 1
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Introduction of Priority_node structure (priority.h)

[Heinz Junkes]

The Priority_node structure was committed to the 4.10 branch of RTEMS in 
December
2017 (78b867e26d score: replace current and real priority with priority node).

Do I have a possibility to know at  compile time (in our case  EPICS) if it is 
present or not. 

Background:
We had received the following bug report:

> On 1/16/19 2:51 PM, Michael Westfall via Tech-talk wrote:
>> When compiling base R3.14.12.7 for RTEMS 4.10.2, I get the following error:
>> 
>> /gem_swdev1/targetOS/RTEMS/rtems-4.10/bin/powerpc-rtems4.10-gcc --pipe 
>> -B/gem_swdev1/targetOS/RTEMS/rtems-4.10/powerpc-rtems4.10/beatnik/lib/ 
>> -specs bsp_specs -qrtems   -fasm -c   -mcpu=7400 -D__ppc_generic 
>>   -DUNIX  -O2 -g -g   -Wall   -DMY_DO_BOOTP=NULL -DHAVE_MOTLOAD 
>> -DRTEMS_NETWORK_CONFIG_MBUF_SPACE=2048 
>> -DRTEMS_NETWORK_CONFIG_CLUSTER_SPACE=5120 -MMD -I. -I../O.Common -I. 
>> -I../../../src/libCom/osi/os/RTEMS -I../../../src/libCom/osi/os/posix 
>> -I../../../src/libCom/osi/os/default -I.. -I../../../src/libCom/bucketLib 
>> -I../../../src/libCom/ring -I../../../src/libCom/calc 
>> -I../../../src/libCom/cvtFast -I../../../src/libCom/cppStd 
>> -I../../../src/libCom/cxxTemplates -I../../../src/libCom/dbmf 
>> -I../../../src/libCom/ellLib -I../../../src/libCom/env 
>> -I../../../src/libCom/error -I../../../src/libCom/fdmgr 
>> -I../../../src/libCom/freeList -I../../../src/libCom/gpHash 
>> -I../../../src/libCom/iocsh -I../../../src/libCom/logClient 
>> -I../../../src/libCom/macLib -I../../../src/libCom/misc 
>> -I../../../src/libCom/osi -I../../../src/libCom/taskwd 
>> -I../../../src/libCom/timer -I../../../src/libCom/tsDefs 
>> -I/gem_swdev1/epics/R3.14.12.7/base/include/os/RTEMS 
>> -I/gem_swdev1/epics/R3.14.12.7/base/include 
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c 
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c: In function 
>> 'showInternalTaskInfo':
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c:617: error: 'Thread_Control' 
>> has no member named 'real_priority'
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' 
>> has no member named 'current_priority'
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' 
>> has no member named 'real_priority'
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c:625: error: 'Thread_Control' 
>> has no member named 'current_priority'
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' 
>> has no member named 'real_priority'
>> ../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' 
>> has no member named 'current_priority'
>> make[3]: *** [osdThread.o] Error 1
>> make[3]: Leaving directory 
>> `/gem_swdev1/epics/R3.14.12.7/epics-base-R3.14.12.7/src/libCom/O.RTEMS-beatnik'
>> make[2]: *** [install.RTEMS-beatnik] Error 2
>> make[2]: Leaving directory 
>> `/gem_swdev1/epics/R3.14.12.7/epics-base-R3.14.12.7/src/libCom'
>> make[1]: *** [libCom.install] Error 2
>> make[1]: Leaving directory 
>> `/gem_swdev1/epics/R3.14.12.7/epics-base-R3.14.12.7/src'
>> make: *** [src.install] Error 2

I fixed it with this patch:
> diff --git a/modules/libcom/src/osi/os/RTEMS/osdThread.c 
> b/modules/libcom/src/osi/os/RTEMS/osdThread.c
> index 769e958..2db1ca5 100644
> --- a/modules/libcom/src/osi/os/RTEMS/osdThread.c
> +++ b/modules/libcom/src/osi/os/RTEMS/osdThread.c
> @@ -640,17 +640,17 @@ showInternalTaskInfo (rtems_id tid)
>   * that priority should be displayed, not the value truncated to
>   * the EPICS range.
>   */
> -epicsPri = 199-thread.real_priority;
> +epicsPri = 199-thread.Priority_node.real_priority;
>  if (epicsPri < 0)
>  fprintf(epicsGetStdout(),"   <0");
>  else if (epicsPri > 99)
>  fprintf(epicsGetStdout(),"  >99");
>  else
>  fprintf(epicsGetStdout()," %4d", epicsPri);
> -if (thread.current_priority == thread.real_priority)
> -fprintf(epicsGetStdout(),"%4d", (int)thread.current_priority);
> +if (thread.Priority_node.current_priority == 
> thread.Priority_node.real_priority)
> +fprintf(epicsGetStdout(),"%4d", 
> (int)thread.Priority_node.current_priority);
>  else
> -fprintf(epicsGetStdout(),"%4d/%-3d", (int)thread.real_priority, 
> (int)thread.current_priority);
> +fprintf(epicsGetStdout(),"%4d/%-3d", 
> (int)thread.Priority_node.real_priority, 
> (int)thread.Priority_node.current_priority);
>  showBitmap (bitbuf, thread.current_state, taskState);
>  fprintf(epicsGetStdout(),"%8.8s", bitbuf);
>  if (thread.current_state & (STATES_WAITING_FOR_SEMAPHORE |
> 

But now it turned out that there was also a 4.10.2  variant in which the 
priority_node structure did not yet exist:

Andrew Johnson wrote 
| finally took a proper look at this bug report.

The APS has been using RTEMS 4.10.2 since 2013 (4.10.2 was tagged on
2011-12-13, I built it in December 2012) and our headers do *not* have
this change, which was committed to the 4.10 branch of RTEMS

Re: [PATCH] posix: Get real priority in pthread_getattr_np()

[Heinz Junkes]

Thanks for the good ideas.
I have now replaced the accesses to the internal thread structure 
(real_priority, current_priority) with API - calls. 
One of the calls is from the pthread-library and therefore needs --enable-posix 
when creating the BSP.
Calls used
pthread_getschedparam
rtems_task_set_priority

Heinz


> On 12. May 2020, at 07:28, Sebastian Huber 
>  wrote:
> 
> This is in line with pthread_setschedparam() and
> pthread_getschedparam().
> 
> Update #2514.
> ---
> cpukit/posix/src/pthreadgetattrnp.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/cpukit/posix/src/pthreadgetattrnp.c 
> b/cpukit/posix/src/pthreadgetattrnp.c
> index a449ad48eb..eae29d1de7 100644
> --- a/cpukit/posix/src/pthreadgetattrnp.c
> +++ b/cpukit/posix/src/pthreadgetattrnp.c
> @@ -40,6 +40,7 @@ int pthread_getattr_np(
>   ISR_lock_Context  lock_context;
>   Thread_CPU_budget_algorithms  budget_algorithm;
>   const Scheduler_Control  *scheduler;
> +  Priority_Control  priority;
>   bool  ok;
> 
>   if ( attr == NULL ) {
> @@ -66,15 +67,12 @@ int pthread_getattr_np(
>   }
> 
>   scheduler = _Thread_Scheduler_get_home( the_thread );
> -  attr->schedparam.sched_priority = _POSIX_Priority_From_core(
> -scheduler,
> -_Thread_Get_priority( the_thread )
> -  );
>   _POSIX_Threads_Get_sched_param_sporadic(
> the_thread,
> scheduler,
> &attr->schedparam
>   );
> +  priority = the_thread->Real_priority.priority;
> 
>   if ( _Thread_Is_joinable( the_thread ) ) {
> attr->detachstate = PTHREAD_CREATE_JOINABLE;
> @@ -97,6 +95,10 @@ int pthread_getattr_np(
>   attr->is_initialized = true;
>   attr->contentionscope = PTHREAD_SCOPE_PROCESS;
>   attr->cputime_clock_allowed = 1;
> +  attr->schedparam.sched_priority = _POSIX_Priority_From_core(
> +scheduler,
> +priority
> +  );
>   attr->schedpolicy =
> _POSIX_Thread_Translate_to_sched_policy( budget_algorithm );
> 
> -- 
> 2.26.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[Heinz Junkes]

I can't find configure in the zip-file (master.zip) which you are loading..
ptpd-master still needs to be reconfigured (autoreconf -vi)
This reconfigure is missing in the cfg file.

It only works the second time and therefore cannot really be used at the 
moment. 
Unfortunately I don't know why it only works every second time.

So you have to do the reconfigure by hand once (2 times) and then save the 
result as tgz 
and load it every time you run the build.

You should also compare the %source with the right so that you do not get 
confused.

Heinz

E.g.
in rtems-source-builder/rtems

 cd sources/
unzip master.zip
cd ptpd-master/
autoreconf -vi -> fails
autoreconf -vi -> ok
cd ..
tar cvzf master.tgz ptpd-master
mv master.tgz $HOME
echo $HOME -> /home/h1
cd ..
vi ../source-builder/config/ptpd-2-1.cfg -> add the new source
sha512sum /home/h1/master.tgz
vi ../source-builder/config/ptpd-2-1.cfg -> add the hash line
../source-builder/sb-set-builder --log log.ptpd.txt 
--with-rtems-bsp=xilinx_zynq_a9_qemu --host=arm-rtems5 --prefix 
/home/h1/GSOC/RTEMS/5.0.0-m2003 net/ptpd

tail -200 rsb-report-ptpd-master-arm-rtems5-1.txt -> now on a real error ;-)

the ptpd-2-1.cfg

#
# PTPD 2.x.x Version 1.
#
# This configuration file configure's, make's and install's PTPD.
#

%if %{release} == %{nil}
%define release 1
%endif

Name:  ptpd-%{ptpd_version}-%{_host}-%{release}
Summary:   PTPD is Precision Time Protocol Daemon.
Version:   %{ptpd_version}
Release:   %{release}
URL:   http://ptpd.sourceforge.net/

#
# PTPD Source
#
#%source set ptpd https://github.com/mritunjaysharma394/ptpd/archive/master.zip
%source set ptpd file:///home/h1/master.tgz
%hash sha512 master.tgz 
9809119ddac8e98ba871f52a74230d3fc29f87ae7ffd7ece1550f196a13e83a71aaffb3ae94e6c7f334e06d612a6913d2fb070c4db05813b9aaccaa04ca91249


#
# Prepare the source code.
#
%prep
 build_top=$(pwd)

 source_dir_ptpd="ptpd-%{ptpd_version}"
…


> On 13. Jun 2020, at 23:37, Mritunjay Sharma  
> wrote:
> 
> First of all Heinz, I would like to thank you for such a wonderful guide 
> which really helped me fix a lot of errors. 
> After following your advice, I made certain changes to make PTPd work, 
> few errors came again but I managed to remove them with the use of Google. 
> 
> However, the recent most error has caught me in a fix and I am still trying 
> to figure it out where I went wrong. 
> 
> https://github.com/mritunjaysharma394/rtems-source-builder/tree/master/source-builder
> https://github.com/ptpd/ptpd/compare/master...mritunjaysharma394:master
> 
> The above two links will tell what changes I have made and the error that I 
> am receiving now is: 
> "configure: WARNING: unrecognized options: --disable-shared
> configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
> "../ptpd-master"/build-aux
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1"
> 
> 
> I have attached the trace log file and error report. 
> I tried to google and made few more changes in ptpd Makefile.am but it didn't 
> help.
> 
> It will be very kind of you all to help me figure out on how to tackle this 
> bug.
> 
> Thanks
> Mritunjay
> 
> On Sun, Jun 7, 2020 at 10:19 AM junkes  wrote:
> This is an unusually long text for the mailing list. I tried to write a kind 
> of tutorial using an example for a GSOC student. I'm looking forward to the 
> comments from the pros and can write it down completely. 
> 
> Hello, Mritunjay
> 
> if I understood it correctly, one idea of the rtems source builder is to make 
> existing 
> software packages usable for RTEMS. Most existing software packages do not 
> work without 
> changes in the RTEMS environment. You have already noticed this with ptpd ;-) 
> 
> The most common auto-tools and configure have trouble making the correct 
> assumptions for the rtems environment. Here you have to intervene. This can 
> be done with the builder-cfg files. 
> 
> This is a bit of hard work and you have to approach it with small steps. 
> You also have to use not so clean tricks in different places. When you have 
> achieved the integration you can/must then try to optimize it so that it 
> becomes 
> generally valid. 
> 
> That's my policy. Maybe the others here in the maillist have more ideas, also 
> for me. 
> 
> I have now tried to implement what I mean using a similar example (openntp). 
> Unfortunately, I haven't finished yet, but I hope to clear a few hurdles for 
> you. 
> 
> I was doing some digging around and I came across this: 
> https://github.com/openntpd-portable/openntpd-portable 
> 
> Here I was then confronted 

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[Heinz Junkes]

If you want to get ahead, just make a version that already has a configure, then
you can save yourself the trouble with autoconf. I'd put that in the back.
Heinz 


> On 15. Jun 2020, at 20:46, Mritunjay Sharma  
> wrote:
> 
> Hello everyone, 
> 
> The latest update is that by changing a couple of things in 
> source-builder/config/ptpd-2-1.cfg which are:
> 
> "%source setup ptpd -q -n ptpd-%{ptpd_version}
> %patch setup ptpd -p1
> 
> +automake --add-missing 
> +autoreconf --install --force 
> cd ${build_top}
> 
> %build"
> 
> GitHub Link: 
> https://github.com/RTEMS/rtems-source-builder/commit/413ea684f1e8672f921ce80abbc59f1e352acbc2
> 
> The earlier configure: error: cannot find install-sh, install.sh, or shtool 
> in build-aux "../ptpd-master"/build-aux has gone
> but another error has come as follows:
> 
> "configure.ac:28: installing './compile'
> configure.ac:16: installing './install-sh'
> configure.ac:16: installing './missing'
> configure.ac:13: error: required file 'config.h.in' not found
> src/Makefile.am: installing './depcomp'
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1"
> 
> What can be the reason for this? Should I create another tar of this and set 
> it as the source?
> The trace and report are attached. The tutorial by Heinz has again helped me 
> a lot! 
> Thank you for that again!
> 
> Thanks,
> Mritunjay
> 
> 
> On Sun, Jun 14, 2020 at 3:07 AM Mritunjay Sharma 
>  wrote:
> First of all Heinz, I would like to thank you for such a wonderful guide 
> which really helped me fix a lot of errors. 
> After following your advice, I made certain changes to make PTPd work, 
> few errors came again but I managed to remove them with the use of Google. 
> 
> However, the recent most error has caught me in a fix and I am still trying 
> to figure it out where I went wrong. 
> 
> https://github.com/mritunjaysharma394/rtems-source-builder/tree/master/source-builder
> https://github.com/ptpd/ptpd/compare/master...mritunjaysharma394:master
> 
> The above two links will tell what changes I have made and the error that I 
> am receiving now is: 
> "configure: WARNING: unrecognized options: --disable-shared
> configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
> "../ptpd-master"/build-aux
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1"
> 
> 
> I have attached the trace log file and error report. 
> I tried to google and made few more changes in ptpd Makefile.am but it didn't 
> help.
> 
> It will be very kind of you all to help me figure out on how to tackle this 
> bug.
> 
> Thanks
> Mritunjay
> 
> On Sun, Jun 7, 2020 at 10:19 AM junkes  wrote:
> This is an unusually long text for the mailing list. I tried to write a kind 
> of tutorial using an example for a GSOC student. I'm looking forward to the 
> comments from the pros and can write it down completely. 
> 
> Hello, Mritunjay
> 
> if I understood it correctly, one idea of the rtems source builder is to make 
> existing 
> software packages usable for RTEMS. Most existing software packages do not 
> work without 
> changes in the RTEMS environment. You have already noticed this with ptpd ;-) 
> 
> The most common auto-tools and configure have trouble making the correct 
> assumptions for the rtems environment. Here you have to intervene. This can 
> be done with the builder-cfg files. 
> 
> This is a bit of hard work and you have to approach it with small steps. 
> You also have to use not so clean tricks in different places. When you have 
> achieved the integration you can/must then try to optimize it so that it 
> becomes 
> generally valid. 
> 
> That's my policy. Maybe the others here in the maillist have more ideas, also 
> for me. 
> 
> I have now tried to implement what I mean using a similar example (openntp). 
> Unfortunately, I haven't finished yet, but I hope to clear a few hurdles for 
> you. 
> 
> I was doing some digging around and I came across this: 
> https://github.com/openntpd-portable/openntpd-portable 
> 
> Here I was then confronted with the same problems as you with autoreconf etc. 
> Here it 
> didn't work, just run autoreconf twice and generate a tar-file for 
> installation like 
> I did with the ptpd from github. 
> Then I found this: 
> https://artfiles.org/openbsd/OpenNTPD/openntp

Re: Multicast in Libbsd

[Heinz Junkes]

I can agree with Cedric.

I use rtems5 with rtems-libbsd. I initialize the network interfaces of my 
target via dhcpcd 
and the interfaces are automatically multicast capable.

This works without creating a route:

 if (setsockopt(conf->udp, IPPROTO_IP, IP_ADD_MEMBERSHIP,
(char *) &mreq, sizeof(mreq))!=0) {
struct sockaddr_in temp;
char name[40];
...

Heinz


> On 19. Jun 2020, at 17:53, Cedric Berger  wrote:
> 
> On 18.06.20 22:47, Joel Sherrill wrote:
> 
>> Hi
>> 
>> I have an example FACE application I am trying to port to RTEMS.  This is a 
>> multi-question email:
>> 
>> First, it fails with EADDRNOTAVAIL on this call:
>> 
>>  // Subscribe to multicast group
>>   struct ip_mreq mreq;
>>   rc = inet_pton(AF_INET, multicastGroup_m, 
>> &mreq.imr_multiaddr.s_addr);
>>   mreq.imr_interface.s_addr = htonl(INADDR_ANY);
>>   rc = setsockopt(
>> new_socket, 
>> IPPROTO_IP, 
>> IP_ADD_MEMBERSHIP, 
>> &mreq, 
>> sizeof(mreq)
>>   );
>> 
>> I assume that is because there is no multicast route. On Linux, you have to 
>> do an ifconfig and route to have a multicast route, but I haven't been able 
>> to find a multicast setup example for FreeBSD. The Linux commands are:
>> 
>> ifconfig lo multicast
>> route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
> This:
> 
> https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6
> 
> Compiles and run without any special configuration on FreeBSD 12.1
> 
> The handbook claims that "Multicast applications do not require any special 
> configuration in order to run on FreeBSD"
> 
> https://www.freebsd.org/doc/handbook/network-routing.html
> 
> Following is the routing table on a FreeBSD jail with no special 224 route 
> needed.
> 
> Cédric
> 
> # netstat -nr
> Routing tables
> 
> Internet:
> DestinationGatewayFlags Netif Expire
> default172.18.12.1UGSepair25b
> 127.0.0.1  link#1 UH  lo0
> 172.18.12.0/24 link#3 U  epair25b
> 172.18.12.25   link#3 UHS lo0
> 
> Internet6:
> Destination   Gateway   Flags 
> Netif Expire
> ::/96 ::1   UGRS
> lo0
> ::1   link#1UH  
> lo0
> :::0.0.0.0/96 ::1   UGRS
> lo0
> fe80::/10 ::1   UGRS
> lo0
> fe80::%lo0/64 link#1U   
> lo0
> fe80::1%lo0   link#1UHS 
> lo0
> ff02::/16 ::1   UGRS
> lo0
> 
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: Release snapshot 5.0.0-m2006-2 available

[Heinz Junkes]

I forgot to send it to rtems-devel...


> Begin forwarded message:
> 
> From: junkes 
> Subject: Re: Release snapshot 5.0.0-m2006-2 available
> Date: 21. June 2020 at 13:53:35 CEST
> To: Chris Johns 
> 
> Hello Chris,
> thanks for the release snapshot. It all looks very good already.
> I have tried it for xilinx_zynq_a9_qemu.
> configuration:
> $ ../../rtems/configure \
>> --prefix=$HOME/development/rtems/5 \
>> --enable-maintainer-mode \
>> --enable-posix \
>> --enable-cxx \
>> --target=arm-rtems5 \
>> --enable-rtemsbsp=xilinx_zynq_a9_qemu \
>> --enable-tests
> 
> rtems-test --rtems-bsp=xilinx_zynq_a9_qemu 
> --rtems-tools=$HOME/development/rtems/5 .
> 
> returns the following errors:
> 
> RTEMS Testing - Tester, 5.0.not_released
> Command Line: /Users/junkes/development/rtems/5/bin/rtems-test 
> --rtems-bsp=xilinx_zynq_a9_qemu 
> --rtems-tools=/Users/junkes/development/rtems/5 .
> Host: Darwin h.fritz.box 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 
> 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64
> Python: 3.7.3 (default, Apr 24 2020, 18:51:23) [Clang 11.0.3 
> (clang-1103.0.32.62)]
> Host: Darwin-19.5.0-x86_64-i386-64bit (Darwin h.fritz.box 19.5.0 Darwin 
> Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; 
> root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 i386)
> [  1/599] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: dhrystone.exe
> [  3/599] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: whetstone.exe
> [  2/599] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: linpack.exe
> ...
> [125/599] p:115 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: rbheap01.exe
> [129/599] p:119 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: sha.exe
> [126/599] p:118 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: record01.exe
> Result: failed Time: 0:00:01.007355 record01.exe
> =>  run: qemu-system-arm -no-reboot -nographic -net none -serial null -serial 
> mon:stdio -M xilinx-zynq-a9 -m 256M -kernel 
> ./arm-rtems5/c/xilinx_zynq_a9_qemu/testsuites/libtests/record01.exe
> ] qemu-system-arm: warning: nic cadence_gem.0 has no peer
> ] qemu-system-arm: warning: nic cadence_gem.1 has no peer
> ]
> ]
> =>  test start: RECORD 1
> ] *** BEGIN OF TEST RECORD 1 ***
> ] *** TEST VERSION: 5.0.0-m2006-2
> ] *** TEST STATE: EXPECTED_PASS
> ] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> ] *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5.0.0-m2006-2, Newlib 7947581)
> ] ../../../../../../../rtems/c/src/../../testsuites/libtests/record01/init.c: 
> 633 hs == HEADER_LAST || items[0].event == hs_to_ev(hs)
> ]
> ] *** FATAL ***
> ] fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> ] fatal code: 0 (0x)
> ] RTEMS version: 5.0.0-m2006-2
> ] RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5.0.0-m2006-2, Newlib 7947581)
> ] executing thread ID: 0x08a010001
> ] executing thread name: UI1
> ]
> [127/599] p:118 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: record02.exe
> [130/599] p:120 f:1   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: shell01.exe
> [131/599] p:120 f:1   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: sparsedisk01.exe
> ...
> [168/599] p:155 f:1   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx11.exe
> [169/599] p:156 f:1   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx12.exe
> [170/599] p:157 f:1   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx13.exe
> [171/599] p:157 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx14.exe
> [173/599] p:160 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx16.exe
> [172/599] p:160 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx15.exe
> [174/599] p:160 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxaio01.exe
> [176/599] p:163 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxaio03.exe
> [175/599] p:163 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxaio02.exe
> [177/599] p:163 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxalarm01.exe
> [179/599] p:166 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxautoinit02.exe
> [178/599] p:166 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxaut

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

[Heinz Junkes]

Hello, Mritunjay,

why not use the RTEMS Resource builder for 4.10 ?
Heinz


> On 1. Jul 2020, at 20:03, Mritunjay Sharma  
> wrote:
> 
> Hi Gedare, 
> 
> Thank you so much, since I had the experience of RSB toolchain till now, 
> I forgot to build the RTEMS compiler toolchain.
> 
> Today's update is also this that I spent the day figuring out how
> to build it manually and got some really amazing blogs
> which have helped me (though they were a bit difficult to find because most 
> pages have been
> relocated).
> Sharing the resources which I have used today and that are helping me build 
> RTEMS compiler toolchain for 4.10.
> 
> http://heshamelmatary.blogspot.com/2014/06/howto-build-rtems-tool-chain-for.html
> https://docs.rtems.org/releases/4.5.0/rtemsdoc-4.5.0/share/rtemsdoc/html/started/started00040.html
> https://ftp.rtems.org/pub/rtems/releases/4.10/tools/
> 
> I am now applying patches for gdb, gcc, binutils and most
> probably hope that the build will be successful. 
> 
> As suggested by Heinz, I am improving the blog as well and will post the 
> updated and better
> version of blog by Friday. 
> 
> Thanks,
> Mritunjay
> 
> On Wed, Jul 1, 2020 at 9:25 AM Gedare Bloom  wrote:
> On Tue, Jun 30, 2020 at 9:42 PM Mritunjay Sharma
>  wrote:
> >
> > Hi Gedare,
> >
> > Thank you for the quick response, I tried using --target=i386-rtems4.10, 
> > which again
> > gave me the same error.
> >
> Did you build an RTEMS compiler toolchain for 4.10? and install it to
> a prefix in your $PATH?
> 
> > "checking for RTEMS_CPU_MODEL... i386_fp
> > checking for RTEMS_BSP_FAMILY... pc386
> > checking for CPU_CFLAGS... (cached) -mtune=i386
> > checking for CFLAGS_OPTIMIZE_V... (cached) -O2 -g
> > checking for style of include used by make... GNU
> > checking for i386-rtems4.10-gcc... no
> > configure: error: no acceptable cc found in $PATH
> > Makefile:712: recipe for target 'pc386' failed
> > make[2]: *** [pc386] Error 1
> > make[2]: Leaving directory 
> > '/home/mritunjay/development/rtems-4.10.2/pc-386/i386-rtems4.10/c'
> > Makefile:257: recipe for target 'all-recursive' failed
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory 
> > '/home/mritunjay/development/rtems-4.10.2/pc-386/i386-rtems4.10/c'
> > Makefile:275: recipe for target 'all-recursive' failed
> > make: *** [all-recursive] Error 1"
> >
> > Mritunjay
> >
> > On Wed, Jul 1, 2020 at 3:48 AM Gedare Bloom  wrote:
> >>
> >>  Use --target=i386-rtems4.10 instead of  --target=i386-rtems
> >>
> >> Does this work with 4.10.3/4.10 HEAD?
> >>
> >> On Tue, Jun 30, 2020 at 3:54 PM Mritunjay Sharma
> >>  wrote:
> >> >
> >> > Hello everyone,
> >> >
> >> > I followed the documentation here 
> >> > https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/pdf/started.pdf
> >> >  and
> >> > started building RTEMS (4.10.2) for target architecture: i386 and BSP: 
> >> > pc386. The configure seemed to be fine
> >> > after entering the following command:
> >> > "../configure --target=i386-rtems --disable-posix --enable-cxx 
> >> > --enable-rtemsbsp=pc386 --enable-tests=samples 
> >> > --prefix=/home/development/rtems-4.10.2"
> >> >
> >> > However, the make failed with the following error: checking for 
> >> > i386-rtems-gcc... no
> >> > "configure: error: no acceptable cc found in $PATH
> >> > Makefile:712: recipe for target 'pc386' failed
> >> > make[2]: *** [pc386] Error 1
> >> > make[2]: Leaving directory 
> >> > '/home/mritunjay/development/rtems-4.10.2/pc386/i386-rtems/c'
> >> > Makefile:257: recipe for target 'all-recursive' failed
> >> > make[1]: *** [all-recursive] Error 1
> >> > make[1]: Leaving directory 
> >> > '/home/mritunjay/development/rtems-4.10.2/pc386/i386-rtems/c'
> >> > Makefile:275: recipe for target 'all-recursive' failed
> >> > make: *** [all-recursive] Error 1"
> >> >
> >> > I checked that gcc is already installed in /usr/bin/gcc.
> >> > So I am not able to figure out what exactly is causing the error.
> >> > Please help to figure out what is causing this and how it can be 
> >> > resolved.
> >> > I have attached the config log as well.
> >> >
> >> >

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

[Heinz Junkes]

Hello, Mritunjay,
that's good news. Don't you want to try to develop a rsb-set for exactly this 
combination of RTEMS4.10 and EPICS7? 
Then it should be no problem to do it with RTEMS5 in the same way.
Did you also run the tests on Epics and also tried the pc386-qemu?
Greetings Heinz 

> On 3. Jul 2020, at 23:56, Mritunjay Sharma  
> wrote:
> 
> [UPDATE]: After using --enable-posix, the 'make' in epics-base worked 
> successfully.
> With all of yours support, there are no errors. Everything seems to be in 
> order.
> 
> Heinz, as you suggested, now I have built EPICS with RTEMS 4.10 for pc-386 
> and as advised that after this
> we can take care of RTEMS5 (or 6?) and libbsd as I have learnt now how to 
> build EPICS and I think we can develop 
> a first rsb-set for it. 
> 
> Please advise on what to begin with next. 
> 
> Thanks
> Mritunjay



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Heinz Junkes]

Thank you, this is exactly where I was unsure.
@Chris: Can you give a recommendation here?
Danke Heinz
--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
--

> On 5. Jul 2020, at 16:20, Gedare Bloom  wrote:
> 
> On Sat, Jul 4, 2020 at 1:18 PM Mritunjay Sharma
>  wrote:
>> 
>> 
>> 
>> On Sun, Jul 5, 2020 at 12:28 AM Heinz Junkes  
>> wrote:
>>> 
>>> Hello, Mritunjay,
>>> that's good news. Don't you want to try to develop a rsb-set for exactly 
>>> this combination of RTEMS4.10 and EPICS7?
>> 
>> 
>> Sure, I am ready to do this and then do it with RTEMS5 in the same way. 
>> Please tell how to begin or some existing similar
>> work that can guide me how to proceed further in relation to rsb-set for  
>> RTEMS4.10 and EPICS7.
>> 
> 
> I don't know if this is best. RSB didn't exist in 4.10. I haven't
> looked to see how well the rtems-source-builder/4.10 would support a
> package build. It should be discussed with Chris probably. A couple of
> packages were added in the 4.11 branch.



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Heinz Junkes]

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

> 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
>>> >>  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?
>>> >> >
>>> >>
>>> >> Yes.
>>> >
>>> >
>>> > +1
>>> >
>>> > And by 5, we definitely mean the 5 branch for all rtems repo and the 
>>> > similarly named one for libbsd.
>>> 
>>> Excellent point. We want to add support for easy build (and eventually
>>> test) of EPICS+RTEMS starting with 5.1 and moving forward, which means
>>> also doing it for RTEMS 6, Mritunjay.
>>> 
>> Sounds good, I have begun building it hand by today for RTEMS 5 branch and 
>> later on continue the 
>> same for RTEMS6
>> 
>> Thank you so much Gedare and Joel. 
>> Mritunjay 
>>> >>
>>> >>
>>> >> > Please suggest for the future steps.
>>> >> >
>>> >> > Thanks
>>> >> > Mritunjay
>>> >> >
>>> >> > On Mon, Jul 6, 2020 at 5:38 AM Joel Sherrill  wrote:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Sun, Jul 5, 2020, 6:12 PM Chris Johns  wrote:
>>> >> >>>
>>> >> >>> On 6/7/20 12:47 am, Heinz Junkes wrote:
>>> >> >>> > Thank you, this is exactly where I was unsure.
>>> >> >>> > @Chris: Can you give a recommendation here?
>>> >> >>> > Danke Heinz
>>> >> >>> > ---

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

[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/

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

[Heinz Junkes]

It's not my experience.

I made my first attempts with RTEMS5 for a beatnik-board (MVME6100).
For this I created the BSP like this:

 cd build/b-beatnik
../../rtems/configure --enable-maintainer-mode --prefix=$HOME/RTEMS/rtems-5 
--target=powerpc-rtems5 --enable-rtemsbsp="beatnik" --enable-posix --enable-cxx 
--enable-networking

Through "--enable-networking" I was able to use the "old" rtems-bsdnet. With 
NTP, NFS etc. .

At the moment I am in the process of using the "new" netbsd. For this I am no 
longer allowed to specify "--enable-networking" when building the bsp. That's 
what it says
in the documentation and it works. The old NFS also works with it, it just 
lacks NTP (or PTP). And what I still miss very much is the support for the RTC 
and above all
the libpci to access the vmebus.
So I played a little with xilinx-zynq and beaglebone. Now I make the rtems_init 
at EPICS dependent on
xilinx_zynq_zedboard/make/bsp.cfg:HAS_NETWORKING = no (new bsdlib)
beatnik/make/bsp.cfg:HAS_NETWORKING = yes (old rtemsbsd code)

Gruss Heinz




> On 11. Jul 2020, at 00:14, Joel Sherrill  wrote:
> 
> Wading in late but I thought I saw something that was contradictory:
> 
> Build BSP with --enable-networking
> Code needs rtems-libbsd
> 
> If the code needs rtems-libbsd, then you MUST build fill with 
> --disable-networking.
> 
> If EPICS code needs rtems-libbsd, that limits the number of BSPs that can be 
> used but you need to always use libbsd.
> 
> --joel

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

Re: [GSoC 2020]: Weekly thread update

[Heinz Junkes]

Hello, Mritunjay,

I'm afraid I've lost track of the situation. I am also still on holiday in 
Norway for 2 weeks and 
I don't always have perfect internet access.
Where can I find your blog. I only found something from June 9th. What is the 
current location of the blog?

I'm afraid you've made a mess of things here.

In the "official" epics repo, you can read

https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/RTEMS/rtems_init.c
 :

…

#include 
#include 
#include 
#include 
#include 
…
Here the definition of the legacy stack will be included

#include 



Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 15. Jul 2020, at 05:57, Mritunjay Sharma  
> wrote:
> 
> 
> 
> On Wed, Jul 15, 2020 at 5:33 AM Chris Johns  wrote:
> On 15/7/20 4:30 am, Mritunjay Sharma wrote:
> > Hello everyone,
> > 
> > Pardon my mistake for that long thread. From now on the daily updates will 
> > be
> > given on a thread that will end every week. 
> 
> Thank you :)
> 
> > 1) I studied about https://github.com/RTEMS/rtems-libbsd
> > 2) Tried to fix the error that I reported yesterday: 
> > 
> > ```
> 
> Why cut the compile command line used to build this file out of the message? 
> The
> compiler command is important because it lets us see what paths are being used
> and I think there may be a problem with them.
> 
> > ../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file or 
> > directory
> >  #include 
> >   ^
> 
> I cannot duplicate this because I am not sure what the sequence of commands 
> are
> you used to get to here. I am sorry if I missed it in a previous post.
> 
> The error indicates a set up issue. It normally means the networking software
> (rtems-libbsd) has not been installed into a prefix path EPICS looks in.
> 
> I am posting the entire command set further ahead in the email which will 
> make things
> easier to understand.  
> 



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC 2020]: Weekly thread update

[Heinz Junkes]

Mritunjay,
can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
Dated 25.9. 2019

From Heinz

> On 17.07.2020, at 20:23, Mritunjay Sharma  
> wrote:
> 
> 
> 
>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes  
>> wrote:
>> You are right. I was not aware of that the dhcpcd stuff is already included 
>> into the source of the epicsPlayground repo. Will have a look into it. 
>> Heinz
>> 
>> FHI, Heinz Junkes
> 
> Thank you so much, Heinz! It will be kind of you to advice for now to how to 
> proceed ahead like whether we have to either 
> use and build the old legacy stack using `--enable-networking` or the libbsd 
> stack? 
> Also, should I start writing the recipe for RSB based on the existing notes 
> of how the process went for building 
> EPICS7 for RTEMS5 for pc-386? 
> 
> Also, I have written another blog on what I learnt recently (using mutt). 
> Here's the link: 
> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
> 
> I also learnt about Networking Drivers from 
> https://docs.rtems.org/branches/master/bsp-howto/networking.html. 
> 
> 
> Thanks,
> Mritunjay. 
> 
> 
>> 
>>> On 15. Jul 2020, at 22:05, Mritunjay Sharma  
>>> wrote:
>>> 
>>> 
>>> Apologies as I mistakenly sent this as a private mail. 
>>> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending this 
>>> again on what 
>>> I responded.
>>> 
>>>> On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma 
>>>>  wrote:
>>>> 
>>>> 
>>>>> On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes  
>>>>> wrote:
>>>>> Hello, Mritunjay,
>>>>> 
>>>>> I'm afraid I've lost track of the situation. I am also still on holiday 
>>>>> in Norway for 2 weeks and 
>>>>> I don't always have perfect internet access.
>>>> 
>>>  
>>> This:->
>>>  
>>>> I am extremely sorry to disturb you on a holiday. I will try to bring back 
>>>> to you where we currently are: 
>>>> As advised by you I already have Built EPICS 7 with RTEMS 4.10 and tested 
>>>> it as well. 
>>>> I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise that I 
>>>> forgot to update the thread that the suggestion 
>>>> presented by Gedare to change to  `#include ` from existing 
>>>> `#include ` helped me 
>>>> fixed the error mentioned in the start of the thread 
>>>> ("../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file 
>>>> or directory
>>>>  #include ").
>>>> 
>>>> I used the 'make' command again then inside `epics-base` (Downloaded from 
>>>> your GitHub's playground) and then got the 
>>>> following error:
>>>> 
>>>> `../posix/rtems_init.c:39:10: fatal error: rtems/dhcpcd.h: No such file or 
>>>> directory
>>>>  #include 
>>>> `
>>>> I discussed this with Gedare on the IRC channel and we concluded that it 
>>>> is there because we have to either 
>>>> use and build the old legacy stack using `--enable-networking` or the 
>>>> libbsd stack. 
>>>> 
>>>> I would like your advice on what should work here and how to approach 
>>>> doing each of these builds? 
>>>> Also, I again apologise that I am disturbing you on a holiday. Please 
>>>> enjoy and take care! 
>>>> 
>>>> Thanks
>>>> Mritunjay 
>>>>  
>>>>> Where can I find your blog. I only found something from June 9th. What is 
>>>>> the current location of the blog?
>>> 
>>> This:-> 
>>>> I have made another blog which as of now deals with building BSPs and I 
>>>> have to update the draft of another one 
>>>> which will further demonstrate on how to Build EPICS. 
>>>> The link to the blog is:  
>>>> https://medium.com/@mritunjaysharma394/installing-rtems-ecosystem-and-building-your-first-bsp-993d1cf38902
>>>>> 
>>>>> I'm afraid you've made a mess of things here.
>>>> 
>>> This:- 
>>>> I am sorry if I have and I accept that I am a beginner but am really 
>>>> enjoying the learning I am making this summer. 
>>>> Thank you so much for the support everyone in helping me grow and learn. 
>>>

Re: [GSoC 2020]: Weekly thread update

[Heinz Junkes]

It uses the legacy-stack. 
When I am back I will adapt rtems_init to use libbsd. 
You should proceed to write rsb recipes.
Heinz

FHI, Heinz Junkes

> On 19. Jul 2020, at 16:03, Mritunjay Sharma  
> wrote:
> 
> 
> 
> 
>> On Sun, Jul 19, 2020 at 4:28 AM Gedare Bloom  wrote:
>> On Sat, Jul 18, 2020 at 2:02 PM Mritunjay Sharma
>>  wrote:
>> >
>> > [UPDATE]: Thank you so much Heinz, with commit 
>> > `3afec267ab08568ea454789e562450b00feea5c0`v
>> > I was able to successfully built EPICS7 with RTEMS5 for pc-386 and pc-386 
>> > qemu both.
>> >
>> 
>> Great. Is this with --enable-networking?
> 
> Yes.  
>> 
>> Is libbsd still not yet working?
> 
> Not sure. Can you tell me the way it can be checked here?  
>> 
>> > As advised, should I begin writing RSB recipe now for RTEMS5?
>> > What can be the next steps?
>> >
>> 
>> I think so. You might try to write some simple script first for
>> yourself, to help think through the logic of automation.
> 
> Sure, I will be starting a new thread for the next week and I will post it 
> there. 
>> 
>> > Please advise and also guide on what will be the best way to begin with 
>> > writing RSB recipe?
>> >
>> 
>> Now that you know how to build by hand, you want to document what you
>> need to do and then you can try to script it. I'm not really sure, but
>> I guess it would be a new kind of "rtems-package" to build, since it
>> is done after rtems is successfully installed? We'll eventually want
>> this to be a vertically integrated package with the RTEMS
>> configuration combined with EPICS for some BSPs that are known to
>> work. Get started, and ask questions as you go.
>> 
>> work from doco at https://docs.rtems.org/branches/master/user/rsb/index.html
>> and submit changes as needed to improve it
> 
> Thank you so much, Gedare. I will work and update on a new thread soon.  
>> 
>> > Thanks
>> > Mritunjay
>> >
>> > On Sat, Jul 18, 2020 at 10:48 PM Mritunjay Sharma 
>> >  wrote:
>> >>
>> >>
>> >> Thank you so much, I am trying and reverting soon.
>> >>
>> >> On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes  
>> >> wrote:
>> >>>
>> >>> Mritunjay,
>> >>> can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
>> >>> Dated 25.9. 2019
>> >>>
>> >>> From Heinz
>> >>>
>> >>> On 17.07.2020, at 20:23, Mritunjay Sharma  
>> >>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes  
>> >>> wrote:
>> >>>>
>> >>>> You are right. I was not aware of that the dhcpcd stuff is already 
>> >>>> included into the source of the epicsPlayground repo. Will have a look 
>> >>>> into it.
>> >>>> Heinz
>> >>>>
>> >>>> FHI, Heinz Junkes
>> >>>
>> >>>
>> >>> Thank you so much, Heinz! It will be kind of you to advice for now to 
>> >>> how to proceed ahead like whether we have to either
>> >>> use and build the old legacy stack using `--enable-networking` or the 
>> >>> libbsd stack?
>> >>> Also, should I start writing the recipe for RSB based on the existing 
>> >>> notes of how the process went for building
>> >>> EPICS7 for RTEMS5 for pc-386?
>> >>>
>> >>> Also, I have written another blog on what I learnt recently (using 
>> >>> mutt). Here's the link:
>> >>> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
>> >>>
>> >>> I also learnt about Networking Drivers from 
>> >>> https://docs.rtems.org/branches/master/bsp-howto/networking.html.
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Mritunjay.
>> >>>
>> >>>
>> >>>>
>> >>>> On 15. Jul 2020, at 22:05, Mritunjay Sharma 
>> >>>>  wrote:
>> >>>>
>> >>>> 
>> >>>> Apologies as I mistakenly sent this as a private mail.
>> >>>> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending 
>> >>>> this again on what
>> &

Re: [GSoC 2020]: Doubts related to testing for EPICS7+RTEMS5 (pc386) built using recipe.

[Heinz Junkes]

I will be back online next weekend. Just a short note:
Mritunjay, please have a look on github epics-base in the directory ci-scripts 
Here you should find automated tests etc. used by the epics development team.

Heinz

> On 30.07.2020, at 01:33, Chris Johns  wrote:
> 
>> On 30/7/20 9:11 am, Mritunjay Sharma wrote:
>> Hello all!
>> 
>> I tried to work on the testing part and here's what I did as per my 
>> understanding:
>> 
>> I went inside the epics built by RSB recipe and ran "make runtests". 
>> It gave results somewhat like this: 
>> 
>> "Base.t  ok  
>> Breaktable.t .. ok  
>> DBD.t . ok
>> Device.t .. ok
>> Driver.t .. ok  
>> Function.t  ok  
>> Menu.t  ok
>> Recfield.t  ok
>> Recordtype.t .. ok
>> Registrar.t ... ok  
>> Variable.t  ok  
>> All tests successful.
>> Files=11, Tests=293,  1 wallclock secs ( 0.05 usr  0.00 sys +  0.40 cusr  
>> 0.06
>> csys =  0.51 CPU)
>> Result: PASS"
> 
> What is EPICS running to test the executables? Do they expect a suitable QEMU 
> in
> the $PATH? In other words what are the dependencies EPICS required to run 
> these
> tests?
> 
>> I also downloaded rtems-testing directory
> 
> Could you please explain what this means? For me this could mean many things 
> and
> I suspect they are not the same as you. Please be provide the needed detail 
> for
> me or anyone to understand this statement, that is the URL, git command or
> whatever that makes sense. For example there is the personal repo of Joel's,
> something EPICS has, the rtems-test command, or you may have found a tar file
> somewhere.
> 
> Please provide the command line you entered and if there is an error the
> relevant pieces of the output.
> 
>> and tried to run simulator
>> using the tutorial here: 
>> https://devel.rtems.org/wiki/Developer/Simulators/QEMU
> 
> This page was updated over 2 years ago and as is the problem with wiki, the
> pages can age. I have added a suitable warning to that page. My advice is to
> consult the User Manual before the wiki.
> 
>> However, I was encountered with this error when I entered: 
>> ```./sim-scripts/pc386 -i
>> ~/development/rtems/kernels-5/pc-386/i386-rtems5/c/pc386/testsuites/samples/hello.exe```
>> 
>> Error: ```qemu-system-i386: Initialization of device ide-hd failed: Block 
>> node
>> is read-only```.
> 
> The User manual has a section titled "Testing". I suggest you refer to that.
> 
>> It is very much possible that I am following a wrong approach for testing. 
>> I really look forward to you all to help me out with it and
>> also share some resources which can help me guide on what exactly I have 
>> to proceed with ahead. 
> 
> I hope this help. Please let me know how you go.
> 
> Chris

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

legacy stack or libbsd

[Heinz Junkes]

I'm trying to figure out when compiling a third party software (EPICS),
whether the RTEMS for a target bsp was created with the legacy stack or 
uses the libbsd stack.

Unfortunately I have found some different definitions:

in target.cfg : RTEMS_HAS_NETWORKING
in bsp.cfg : HAS_NETWORKING
in header files #if defined(RTEMS_NETWORKING)

Which one should I take best?

I tend to RTEMS_HAS_NETWORKING in target.cfg ;-)

Danke Heinz

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: legacy stack or libbsd

[Heinz Junkes]

Because the libbsd stack does not support some things yet (e.g. ntp) I have to 
call different 
functions at rtems_init in EPICS. Therefore, when building EPICS for a target, 
I need
to know which stack the target was built with. 

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 4. Aug 2020, at 15:44, Joel Sherrill  wrote:
> 
> 
> 
> On Tue, Aug 4, 2020 at 8:10 AM Heinz Junkes  wrote:
> I'm trying to figure out when compiling a third party software (EPICS),
> whether the RTEMS for a target bsp was created with the legacy stack or 
> uses the libbsd stack.
> 
> Unfortunately I have found some different definitions:
> 
> in target.cfg : RTEMS_HAS_NETWORKING
> in bsp.cfg : HAS_NETWORKING
> in header files #if defined(RTEMS_NETWORKING)
> 
> Which one should I take best?
> 
> I tend to RTEMS_HAS_NETWORKING in target.cfg ;-)
> 
> rtems/score/cpuopts.h defines it in the installed headers. but
> I think either bsp.cfg or target.cfg would be trustworthy. target.cfg
> has more info in it.
> 
> This doesn't help you know before building which network stacks
> a BSP supports though.
> 
> --joel
>  
> 
> Danke Heinz___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Name of the primary network interface, how to find in bsp header files?

[Heinz Junkes]

Can I get the name of the primary network interface from the header files of a 
target-bsp?

Danke
Heinz



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Name of the primary network interface, how to find in bsp header files?

[Heinz Junkes]

Danke,

it works great with the libbsd-stack.

That is then also definitely the way to go. I just remembered in the legacy 
stack that the network driver name
was set in some BSPs. But this was probably not continuous. And with the new 
ones, it is no longer possible. 
Heinz


> On 7. Aug 2020, at 14:17, Sebastian Huber 
>  wrote:
> 
> On 07/08/2020 13:39, Heinz Junkes wrote:
> 
>> Can I get the name of the primary network interface from the header files of 
>> a target-bsp?
> 
> Some BSPs have an RTEMS_BSP_NETWORK_DRIVER_NAME define.
> 
> With libbsd you can try something like this:
> 
> char ifnamebuf[IF_NAMESIZE];
> char *ifname;
> 
> 
> ifname = if_indextoname(1, &ifnamebuf[0]);
> assert(ifname != NULL);
> 



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Name of the primary network interface, how to find in bsp header files?

[Heinz Junkes]

Hallo Chris,
I think there's been a misunderstanding.
I have implemented the following in the EPICS rtems_init.c :

...
sc = rtems_bsd_initialize();
assert (sc == RTEMS_SUCCESSFUL)
/* Let the callout timer allocate its resources */
sc = rtems_task_wake_after(2);
assert (sc == RTEMS_SUCCESSFUL)

rtems_bsd_ifconfig_lo0();

/* lookup primary network interface */
char ifnamebuf[IF_NAMESIZE];
char *prim_ifname;
prim_ifname = if_indextoname(1, &ifnamebuf[0]);
assert(prim_ifname != NULL);
…

Heinz


> On 8. Aug 2020, at 03:50, Chris Johns  wrote:
> 
> On 8/8/20 5:12 am, Heinz Junkes wrote:
>> 
>> it works great with the libbsd-stack.
> 
> I do not think it is a good idea rely on the RTEMS_BSP_NETWORK_DRIVER_NAME
> setting in libbsd. I have not questioned it before now as it has been used
> internally in the tests but exporting it as an interface is something else. It
> works for a specific case of target but it does not for others, for example 
> the
> Xilinx Zynq has 2 MACs (cgem0, cgem1), a PC has a wide range of interfaces.
> 
>> That is then also definitely the way to go.
> 
> How would cgem1 on a Zynq be specified if RTEMS_BSP_NETWORK_DRIVER_NAME is
> cgem0? Also there is nothing stopping me changing 
> RTEMS_BSP_NETWORK_DRIVER_NAME
> to cgem1 so how does that get handled?
> 
> After 25 years doing this I have learnt to be careful about what we export and
> depend on.
> 
>> I just remembered in the legacy stack that the network driver name
>> was set in some BSPs. But this was probably not continuous. And with the new 
>> ones, it is no longer possible.
> 
> As a default it may be OK however it would be nice or important to allow this 
> to
> be changed.
> 
> How does an EPICS build for Linux on a PC deal with this given there is a 
> large
> number of possible interface names?
> 
> Chris



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

[Heinz Junkes]

Hallo Mritunjay,
everything looks pretty good. I'm commenting on the text. I also send this mail
to two EPICS experts (Andrew Johnson and Michael Davidsaver). Maybe they also 
have some ideas.


> 
> Current Status: 
> 
> 1) Successfully built EPICS7 with RTEMS5 by hand for pc-386
> 2) Worked for RSB recipe. 
>In its due process, I Wrote:  
> i) rsb/rtems/config/epics/epics-7-1.cfg 
> ii)rsb/rtems/config/epics/epics-base.bset 
> iii)rsb/source-builder/config/epics-7-1.cfg
> 3) Added Patch for RTEMS-pc-386 support which made the above recipe work 
> successfully. 
> 4) Therefore, Successully built EPICS7 with RTEMS5 by using RSB recipe as 
> well for pc-386 as of now. 
> 5) Sent 4 Patches for review of the same. 
> 
> What problems are in the next steps?
> 
> 1) How to make it work across different architectures?
> 2) Exisiting EPICS works on the old legacy network stack.
> 3) I am not using EPICS upstream branch. It is being built
> by Heinz's epics playground. 
> 4) Doubts in how to start with testing. 
> 
> My Resarch work for the Problem no: 1
> 
> I have gone through the EPICS developer guide from here
> exhaustively in the past couple of day and here are few interesting things
> that I found which can help: 
> 
> 1) "The main ingredients of the build system are:
> • A set of configuration files and tools provided in the EPICS base/configure 
> directory
> • A corresponding set of configuration files in the /configure directory 
> of a non-base  directory
> structure to be built. The makeBaseApp.pl and makeBaseExt.pl scripts create 
> these configuration files. Many of
> these files just include a file of the same name from the base/configure 
> directory.
> • Makefiles in each directory of the  directory structure to be built
> • User created configuration files in build created $(INSTALL_LOCATION)/cfg 
> directories.
> "
> 
> Remarks: Now since it is also mentioned in the guide that "makeBaseApp.pl 
> creates directories and then copies template files into the newly created 
> directories 
> while expanding macros in the template files. EPICS base provides two sets of 
> template files: simple and example."
> Can we think of using makeBaseApp.pl to that end? Making the user allow 
> to change the configurations from the terminal? 

I don't think that makeBaseApp.pl will help you. This is intended to build an 
example IOC. It takes the settings from the above mentioned configuration files.

You "only" need to specify the location of the RTEMS installation in 
configure/os/CONFIG_SITE.Common.RTEMS.
RTEMS_VERSION =
RTEMS_BASE =

Then you have to define the target in configure/CONFIG_SITE:
...
# Which target architectures to cross-compile for.
#  Definitions in configure/os/CONFIG_SITE..Common
#  may override this setting.
CROSS_COMPILER_TARGET_ARCHS=
…
e.g. “CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu"

And for each target there must be a file in configure/os:
e.g. CONFIG_Common.RTEMS-xilinx_zynq_a9_qemu
If it is not provided by EPICS, the RSB should install it there (adapted to the 
target to be used by epics make).

> 
> 2) "The startup directory in EPICS base contains a perl script, 
> EpicsHostArch.pl, which can be used to define
> EPICS_HOST_ARCH. This script can be invoked with a command line parameter 
> defining the alternate compiler (e.g.
> if invoking EpicsHostArch.pl yields solaris-sparc, then invoking 
> EpicsHostArch.pl gnu will yield
> solaris-sparc-gnu).
> The startup directory also contains scripts to help users set the path and 
> other environment variables”
This has nothing to do with 2)

There's no need to adjust anything here. The EPICS make recognizes the 
architecture on which it is started.

> Remarks: As EPICS_HOST_ARCH, can we do something similar for 
> CROSS_COMPILER_TARGET_ARCHS?
> 
> 3) ") The following is a summary of targets that can be specified for gnumake:
> • 
> • 
> • .
> • 
> • .
> • .
> • ..
> where:
>  is an architecture such as solaris-sparc, vxWorks-68040, win32-x86, 
> etc.
>  is help, clean, realclean, distclean, inc, install, build, rebuild, 
> buildInstall, realuninstall, or uninstall"
> 
> Remarks: Now similar to the above stated, can we work for Cross Compiler 
> target Architecture? 
> 

But this does not refer to 3) ?

3) You have to take "my" repo at the moment, because the adaptations to RTEMS5 
are not yet included in the official epics-base. This is a hen-and-egg problem 
because RTEMS is only now in the release phase, so my changes have not been 
implemented yet. 

2) I'm just about to figure out in the Epics Makefiles whether the target was 
built with the legacy-stack or libbsd-stack. It's working already.
Now I also have to adjust the rtems_init.c accordingly. Here I have to clean up 
a little bit. But I hope to have this finished by the middle of the week. 

> These were the little doubts that originated from the research work I did. 
> I will like the opinion of mentors that what can be the optimal way now to 
> appro

Re: Name of the primary network interface, how to find in bsp header files?

[Heinz Junkes]

Hello, Chris,

with libbsd I also realized this with the concept you suggested (still beta 
development):

...
sc = rtems_bsd_initialize();
assert(sc == RTEMS_SUCCESSFUL);

/* Let the callout timer allocate its resources */
sc = rtems_task_wake_after(2);
assert(sc == RTEMS_SUCCESSFUL);

rtems_bsd_ifconfig_lo0();

//  lookup available network interfaces
char ifnamebuf[IF_NAMESIZE];
char *ifname;
// get primary network interface
ifname = if_indextoname(1, &ifnamebuf[0]);
assert(ifname != NULL);
printf("\n* Primary Network interface : %s *\n", ifname);

default_network_dhcpcd();

// implement DHCP hook  ... and wait for acknowledge
dhcpDone = epicsEventMustCreate(epicsEventEmpty);
rtems_dhcpcd_add_hook(&dhcpcd_hook);

// wait for dhcp done ... should be if SYNCDHCP is used
epicsEventWaitStatus stat;
int counter = 10;
do {
printf("\n  Wait for DHCP done ...\n");
stat = epicsEventWaitWithTimeout(dhcpDone, 5.0);
} while ((stat == epicsEventWaitTimeout) && (--counter > 0));
if (stat == epicsEventOK)
epicsEventDestroy(dhcpDone);
else
printf("\n  dhcpDone Event Unknown state %d\n", stat);
…

static void
default_network_dhcpcd(void)
{
static const char default_cfg[] = "clientid FHI test client\n";
rtems_status_code sc;
int fd;
int rv;
ssize_t n;
fd = open("/etc/dhcpcd.conf", O_CREAT | O_WRONLY,
S_IRWXU | S_IRWXG | S_IRWXO);
assert(fd >= 0);

n = write(fd, default_cfg, sizeof(default_cfg) - 1);
assert(n == (ssize_t) sizeof(default_cfg) - 1);


static const char fhi_cfg[] = "nodhcp6\nipv4only\noption ntp_servers\noption 
rtems_cmdline\n";

n = write(fd, fhi_cfg, sizeof(fhi_cfg) - 1);
assert(n == (ssize_t) sizeof(fhi_cfg) - 1);

rv = close(fd);
assert(rv == 0);

sc = rtems_dhcpcd_start(NULL);
assert(sc == RTEMS_SUCCESSFUL);
}

static void
dhcpcd_hook_handler(rtems_dhcpcd_hook *hook, char *const *env)
{
int bound = 0;
char iName[16];
char *name;
char *value;

(void)hook;

while (*env != NULL) {
name = strtok(*env,"=");
value = strtok(NULL,"=");
printf("all out ---> %s = %s\n", name, value);
if (!strncmp(name, "interface", 9) && !strcmp(value,  
NET_CFG_INTERFACE_0))
 strncpy(iName, value, 16);
if (!strncmp(name, "reason", 6) && !strncmp(value, "BOUND", 5)){
  printf ("Interface %s bounded\n", iName);
  bound = 1;
}
if (bound) {
  // as there is no ntp-support in rtems-libbsd, we call our 
own client
  if(!strncmp(name, "new_ntp_servers", 15))
strcpy(rtemsInit_NTP_server_ip,value);
  if(!strncmp(name, "new_host_name", 13))
sethostname (value, strlen (value));
  if(!strncmp(name, "new_tftp_server_name", 20)){
printf(" new_tftp_server_name : %s\n", value);
strncpy(rtems_bsdnet_bootp_server_name,value, 
sizeof(bootp_server_name_init));
  }

  printf("---> %s = %s\n", name, value);
}
++env;
}
if (bound)
  epicsEventSignal(dhcpDone);
}

static rtems_dhcpcd_hook dhcpcd_hook = {
.name = "ioc boot",
.handler = dhcpcd_hook_handler
};

But the biggest problem here is that on the test-CI-system (travis, appveyor, 
etc.) a dhcp-server, 
ntp-server, nfs-server and complex routing structures for e.g. qemu must be 
provided. 
There it is easier to use environment variables.

Many greetings
Heinz 


> On 9. Aug 2020, at 02:44, Chris Johns  wrote:
> 
>> nging configuration. And likely only one NIC.
> 
> Agreed and it works for a testsuite to some extent. Network tests are hard
> because you need a very controlled network set up to make then work.
> 
>> It was used in the network demos for the legacy stack so if we want to
>> eliminate it completely, it would be good to find a recommended way to
>> look up the interface name and put it into the legacy configuration
>> tables.
>> 
>> https://git.rtems.org/network-demos/tree  
>> 
>> Yes... I know we all want to see it removed and everyone move to
>> libbsd. But I don't think that is realistic to expect. The more realistic
>> solution is to move it to its own build tree and freeze it. It is there
>> and we encourage people to use libbsd. But it does offer a solution
>> for older target boards. The old stack is also all that is supported by
>> many EPICS boards. Outside of EPICS users, even the SPARC BSPs 
>> haven't been converted yet.
> 
> Yes we should move it out of the main tree and have it becomes an available
> optional package. It can be maintained by those with an active interest in it.
> 
> It has some bugs ... we found one last year with the arp cache and Windows. 
> The
> solution was a hack to set the 

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

[Heinz Junkes]

I think you should not make a patch for these two changes but a 
simple replacement with e.g. sed.

like

sed -i ’s/^RTEMS_BASE/RTEMS_BASE = 
\/home\/mritunjay\/development\/rtems/\$\(RTEMS_VERSION\)-arm\/g’ 
configure/os/CONFIG_SITE.Common.RTEMS

oder so ;-)


Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 12. Aug 2020, at 02:13, Mritunjay Sharma  
> wrote:
> 
> Hello Heinz and everyone!
> 
> Thank you so much for this update. I started to work first by building EPICS 
> by hand
> for "xilinx_zynq_a9_qemu". Till the time, you gave 
> https://gitlab.fhi.mpg.de/junkes/epics-base.git, 
> I had to struggle with lot of errors which cloning into this repo solved.  
> 
> So I started by building "xilinx_zynq_a9_qemu" BSP for RTEMS5 using my own 
> blog with only difference being 
> that  I used '--disable-networking' to use libbsd. 
> 
> After that, I used this blog https://rmeena840.github.io/Fourth-Post/ of a 
> GSoC 19 Student to build and install rtems-libbsd
> for  "xilinx_zynq_a9_qemu".
> 
> Everything worked perfectly fine till now. Now I entered the 'epics-base' 
> directory and made
> the changes in configure/os/CONFIG_SITE.Common.RTEMS as: 
> 
> # FHI:
> RTEMS_SERIES = 5
> RTEMS_VERSION = 5
> RTEMS_BASE = /home/mritunjay/development/rtems/$(RTEMS_VERSION)-arm
> 
> Also made the change in configure/CONFIG_SITE:
> 
> CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu
> 
> After this I used 'make' command and it worked fine. 
> 
> So, I can say that there were just two changes which I had to make then the 
> previous one. 
> 
> The successful build by hand enabled me to work on the RSB recipe. 
> 
> I worked on them and it can be found here 
> https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support-zynq.
> 
> The patch I am applying can be found here: 
> https://raw.githubusercontent.com/mritunjaysharma394/epics-mritunjay/master/patches/0001-Added-support-for-RTEMS-xilinx_zynq_a9_qemu.patch
> 
> However, the problem I am facing is that while building the recipe using:
> ```.../source-builder/sb-builder --log=log_epics epics-7-1```, 
> the build is failing because it seems that Patch setup in configure file is 
> not getting applied there. I followed the same steps as done for pc
> but this time the patch is not getting applied. 
> 
> It will be really helpful if you can guide where did I went wrong thist time. 
> 
> I am attaching the log and report file for reference. 
> 
> Thanks
> Mritunjay
> 
> 
> 
> 
> On Mon, Aug 10, 2020 at 8:56 PM junkes  wrote:
> Hello Mritunjay,
> 
> I have now finished an EPICS variant that works with libbsd so far. DHCP and 
> NFS work. NTP I added a primitive reader. This is sufficient for testing.
> 
> You can find the development here: 
> 
> https://gitlab.fhi.mpg.de/junkes/epics-base.git
> 
> It's not perfect yet. The adaptation to the legacy stack and the processing 
> of the environment variables from the flash (u-boot etc.) is still missing.
> 
> [h1@earth QtC-epics-base (7.0 *+)]$ ./startQemu softIoc 
> Script name: ./startQemu 
> qemu-system-aarch64: warning: nic cadence_gem.1 has no peer 
> WARNING: OS Clock time was read before being set. 
> Using 1990-01-02 00:00:00.00 UTC 
> 
> initConsole --- Info --- 
> stdin: fileno: 0, ttyname: /dev/ttyS1 
> stdout: fileno: 1, ttyname: /dev/ttyS1 
> stderr: fileno: 2, ttyname: /dev/ttyS1 
> tcsetattr failed: I/O error 
> time set to : 04/14/14 07:30:06.55589 UTC 
> Startup. 
> epicsThreadSetPriority called by non epics thread 
> 
> * RTEMS Version: rtems-5.0.0-m2003 (ARM/ARMv4/xilinx_zynq_a9_qemu) * 
> 
> * Initializing network (dhcp) * 
> nexus0:  
> zy7_slcr0:  on nexus0 
> cgem0:  on nexus0 
> miibus0:  on cgem0 
> e1000phy0:  PHY 0 on miibus0 
> e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, 1000baseT-FDX-master, auto 
> e1000phy1:  PHY 23 on miibus0 
> e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, 1000baseT-FDX-master, auto 
> info: cgem0: Ethernet address: 52:54:00:12:34:56 
> info: lo0: link state changed to UP 
> 
>  Wait for DHCP done ... 
> dhcpcd: unknown option -- pv4only 
> info: version 6.2.1 starting 
> cgem0: cgem_mediachange: could not set ref clk0 to 2500. 
> info: cgem0: link state changed to UP 
> dhcpcd: unknown option -- pv4only 
> debug: cgem0: executing `ioc boot' PREINIT 
> 
> * Primary Network interface : cgem0 * 
> debug: cgem0: executing `ioc boot' CARRIER 
> 
> * Primary Networ

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Heinz Junkes]

Hi Mritunjay,

To define the architecture you can create a file “CONFIG_SITE.local” in 
“configure”.
Look at the comment at the end of the file "CONFIG_SITE":

"
...
# Overrides for the settings above may appear in a CONFIG_SITE.local file
-include $(CONFIG)/CONFIG_SITE.local.
“

Heinz

> On 16. Aug 2020, at 12:16, Mritunjay Sharma  
> wrote:
> 
> 
> 
> On Sun, Aug 16, 2020 at 1:12 PM Chris Johns  wrote:
> On 16/8/20 8:29 am, Mritunjay Sharma wrote:
> > On Sun, Aug 16, 2020 at 12:15 AM Gedare Bloom  > > wrote:
> > 
> > Hi Mritunjay, Chris:
> > 
> > For the RSB, since it is user-facing, we need to be sure to minimize
> > its dependencies on the user environment and platform. So this pycli
> > can only be used if it is distributed standard with Python 2 and
> > Python 3.
> > 
> > Would someone be able to apply this patch and use it to build epics?
> > No, because (1) they won't have pycli available, and (2) they don't
> > have a path /home/mritunjay
> > 
> > 
> > I think what you are saying is absolutely right. It will be really a great 
> > help
> > if Chris can guide on what next can be done. 
> 
> See below.
> 
> > As far as 'pycli' is concerned, I have made a couple of minor tweaks. Gave 
> > it a
> > better name 'sedpy' and made it public on GitHub. 
> > 
> > Please find the link to the
> > project here: https://github.com/mritunjaysharma394/sedpy
> 
> Thanks but I currently do not see a need for this tool.
> 
> > I will appreciate if mentors can have a look and try this and see if it in 
> > any
> > way can be modified
> > to be used with RSB or else we will go with what is suggested. 
> 
> Please put the RSB to one side. I will let you know when we can return to it.
> 
> I believe patching config files in EPCIS from the RSB is fragile. EPICS should
> be free to change any of these files without needing to considering the effect
> it has on the RSB. Just because we can peek inside does not means we are free 
> to
> exploit what we see.
> 
> What happens if you define the needed variables on the make command line? For
> example:
> 
>  gmake RTEMS_BASE=$HOME/development/rtems/5 RTEMS_VERSION=5.1-rc2
> 
> These variables are just normal make ones and so they can be overridden from 
> the
> command line.
> 
> Please investigate this and see what happens?
> 
> Hi Chris,
> I investigated and used:
> 
>  `make RTEMS_BASE=$HOME/development/rtems/5-arm RTEMS_VERSION=5`
> 
> This worked perfectly fine and the build was successful. Thank you so much 
> for telling this. It makes it so
> easy. What can we do next? This surely removes the requirement of `sed` or 
> the tool I built to make command line changes.
> 
> Thanks
> Mritunjay
> 
> 
> Chris



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Heinz Junkes]

Hallo Mritunjay,

this was an improvement in the EPICS configuration to include the tool/path 
definitions
from the RTEMS BSP directory:

configure/os/CONFIG.Common.RTEMS:
...
#---
# Pick up the RTEMS tool/path definitions from the RTEMS BSP directory.
include $(RTEMS_BASE)/$(GNU_TARGET)/$(RTEMS_BSP)/Makefile.inc
include $(RTEMS_CUSTOM)
include $(CONFIG.CC)

#---
# RTEMS cross-development tools
CC = $(RTEMS_TOOLS)/bin/$(CC_FOR_TARGET) $(GCCSPECS) -fasm
CCC = $(RTEMS_TOOLS)/bin/$(CXX)
CPP = $(RTEMS_TOOLS)/bin/$(CC_FOR_TARGET) -x c -E
AR = $(RTEMS_TOOLS)/bin/$(AR_FOR_TARGET)
LD = $(RTEMS_TOOLS)/bin/$(LD_FOR_TARGET) -r
…

The assumption was that Makefile.inc is present in every BSP.
If it cannot be found in the pc-386 BSP, should the BSP be adapted?


Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 19. Aug 2020, at 07:09, Mritunjay Sharma  
> wrote:
> 
> Hi everyone, 
> 
> Before I begin my queries [ mainly regarding epics upstream], let me give a 
> few updates. 
> 
> As per the suggestion of Gedare, I started building by hand the pc-386 and 
> xilinx_zynq_a9_qemu using
> the terminal configured make command. 
> 
> What I did initially as an experiment is that, in 
> configure/os/CONFIG_SITE.Common.RTEMS: 
> 
> I made 
> RTEMS_VERSION = 
> RTEMS_BASE = 
> 
> That is both were left blank.
> 
> Similarly, I did it for configure/CONFIG_SITE:
> CROSS_COMPILER_TARGET_ARCHS=
> 
> After this, I started building EPICS for xilinx_zynq_a9_qemu from the 
> 'epics-base' downloaded from this source of Heinz 
> [https://gitlab.fhi.mpg.de/junkes/epics-base]
> 
> The command I used was:
> 
> ` make RTEMS_BASE=$HOME/development/rtems/5-arm RTEMS_VERSION=5 
> CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu`
> 
> The Build was successful for xilinx_zynq_a9_qemu.
> 
> However, if I used the same `epics-base` and tried to build it for pc-386 
> using the command:
> 
> `make RTEMS_BASE=$HOME/development/rtems/5 RTEMS_VERSION=5 
> BUILD_ARCHS=RTEMS-pc386`
> 
> The Build failed and I got this error:
> 
> `make -C ./configure install 
> make[1]: Entering directory 
> '/home/mritunjay/development/EPICS/epics-base/configure'
> make -C O.RTEMS-pc386 -f ../Makefile TOP=../.. \
> T_A=RTEMS-pc386 install
> make[2]: Entering directory 
> '/home/mritunjay/development/EPICS/epics-base/configure/O.RTEMS-pc386'
> ../../configure/os/CONFIG.Common.RTEMS:36: 
> /home/mritunjay/development/rtems/5//pc386/Makefile.inc: No such file or 
> directory
> make[2]: *** No rule to make target 
> '/home/mritunjay/development/rtems/5//pc386/Makefile.inc'.  Stop.
> make[2]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/configure/O.RTEMS-pc386'
> make[1]: *** [../configure/RULES_ARCHS:58: install.RTEMS-pc386] Error 2
> make[1]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/configure'
> make: *** [configure/RULES_DIRS:84: configure.install] Error 2
> `
> This made me try another `epics-base` of Heinz that he earlier suggested 
> which is: 
> https://github.com/hjunkes/epicsBaseOwnPlayground/tree/3afec267ab08568ea454789e562450b00feea5c0
> 
> Running the same `make RTEMS_BASE=$HOME/development/rtems/5 RTEMS_VERSION=5 
> BUILD_ARCHS=RTEMS-pc386`
> the command worked here and EPICS for pc-386 was successfully built. 
> 
> Therefore, we need to make changes in the epics code base so that we can have 
> one common epics-base which works for both. 
> 
> This was the update. I am modifying the RSB recipes and soon will update 
> regarding the build related to it. 
> 
> Now, I am commenting on the queries further below. 
> 
> 
> On Wed, Aug 19, 2020 at 9:45 AM Gedare Bloom  wrote:
> On Tue, Aug 18, 2020 at 7:13 PM Heinz Junkes  wrote:
> >
> > Hi Mritunjay,
> >
> > To define the architecture you can create a file “CONFIG_SITE.local” in 
> > “configure”.
> > Look at the comment at the end of the file "CONFIG_SITE":
> >
> Do I have to just write `CROSS_COMPILER_TARGET_ARCHS=` in CONFIG_SITE.local 
> file? 
> Please if you can tell more about what changes it can bring for us? 
> > "
> > ...
> > # Overrides for the settings above may appear in a CONFIG_SITE.local file
> > -include $(CONFIG)/CONFIG_SITE.local.
> > “
> >
> 
> Can we generate/inject the file/variables directly from scripts?
> 
> I also have the same question. 
> 
> Thanks
> Mritunjay Sharma
>  
> 
> > Heinz
> >
> > > On 16. Aug 2020, at 12:16, Mritunjay Sharma 
> > >

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Heinz Junkes]

Hallo Mritunjay,

that sounds good. But shouldn't the dependencies for the RTEMS basic 
installation
be taken into account. Maybe I don't understand the purpose of the 
source-builder.
But I thought that the necessary rtems-modules (compiler for architecture, 
libbsd, etc.) are checked
and if something is missing, they are installed? And when do the tests (epics: 
make runtests and qemu)
come into play? 
Gruss Heinz


> On 23. Aug 2020, at 00:08, Mritunjay Sharma  
> wrote:
> 
> [Good news and Update]: 
> 
> Thank you so much Chris! Your advice to search for macros using --trace 
> solved the problem of hard coding!
> It took two complete days to figure out this beautiful thing but it is every 
> worth it. 
> 
> Now the user has to just enter the below command and it will make things 
> work: 
> 
> `../source-builder/sb-builder --with-rtems-bsp="xilinx_zynq_a9_qemu" 
> --log=log_epics epics-7-1  --trace --prefix=$HOME/development/rtems/5-arm`
> 
> Note: prefix will depend on the user. 
> 
> What made this possible? Your suggestion and the changes in code mentioned 
> below:
> 
> ```diff --git a/rtems/config/epics/epics-7-1.cfg 
> b/rtems/config/epics/epics-7-1.cfg
> index aeb39a9..4b20f82 100644
> --- a/rtems/config/epics/epics-7-1.cfg
> +++ b/rtems/config/epics/epics-7-1.cfg
> @@ -6,6 +6,8 @@
>   %define release 1
>  %endif
>  
> +%include %{_configdir}/rtems-bsp.cfg
> +
>  #
>  # EPICS Version
>  #
> diff --git a/source-builder/config/epics-7-1.cfg 
> b/source-builder/config/epics-7-1.cfg
> index a9581a2..a47aecb 100644
> --- a/source-builder/config/epics-7-1.cfg
> +++ b/source-builder/config/epics-7-1.cfg
> @@ -40,7 +40,10 @@ URL:  https://epics.mpg.de/
>  
>%{build_build_flags}
>  
> -  %{__make} PREFIX=%{_prefix} RTEMS_BASE=$HOME/development/rtems/5-arm 
> RTEMS_VERSION=5 CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu
> +  #
> +  # Using macros to dynamically path to RTEMS_BASE and RTEMS_VERSION using 
> --with-rtems-bsp
> +  #
> +  %{__make} PREFIX=%{_prefix} RTEMS_BASE=%{_exec_prefix} 
> RTEMS_VERSION=%{rtems_version}
>  
>cd ${build_top}
>  
> @@ -50,6 +53,5 @@ URL:  https://epics.mpg.de/
>rm -rf $SB_BUILD_ROOT
>  
>cd ${source_dir_epics}
> -  %{__make} DESTDIR=$SB_BUILD_ROOT PREFIX=%{_prefix} 
> RTEMS_BASE=$HOME/development/rtems/5-arm RTEMS_VERSION=5 
> CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu
> -
> +  %{__make} DESTDIR=$SB_BUILD_ROOT PREFIX=%{_prefix} 
> RTEMS_BASE=%{_exec_prefix} RTEMS_VERSION=%{rtems_version}
>cd ${build_top}
> ```
> 
> These couple of changes made this build successful using RSB recipe. The only 
> problem remains 
> is that a warning of 'no hash found' is coming, even though I have added it. 
> 
> The above changes can be found pushed here: 
> https://github.com/RTEMS/rtems-source-builder/commit/a505877157f63f6ae17906276b3ffcb699ed1297
> 
> Please do give feedback and suggest improvements so that the recipe can 
> become mergeable. 
> 
> Thanks
> Mritunjay Sharma
> 
> 
> 
> 
> 
> 
> 
> On Thu, Aug 20, 2020 at 8:51 AM Chris Johns  wrote:
> On 20/8/20 8:09 am, Mritunjay Sharma wrote:
> > [UPDATE]: Finally modified the RSB recipes to make them work with make 
> > utility
> > and EPICS was built successfully.
> 
> Great you have had some success but there is a lot more work before it is 
> usable.
> 
> > iff --git a/source-builder/config/epics-7-1.cfg 
> > b/source-builder/config/epics-7-1.cfg
> > index f51c6582..a9581a2e 100644
> > --- a/source-builder/config/epics-7-1.cfg
> > +++ b/source-builder/config/epics-7-1.cfg
> > @@ -21,7 +21,6 @@ URL:  https://epics.mpg.de/
> >  #
> >  %source set epics --rsb-file=epics-base-%{epics_version}.tar.gz 
> > https://gitlab.fhi.mpg.de/junkes/epics-base/-/archive/%{epics_version}/epics-base-%{epics_version}.tar.gz
> >  
> > -
> >  #
> >  # Prepare the source code.
> >  #
> > @@ -31,20 +30,9 @@ URL: https://epics.mpg.de/
> >source_dir_epics="epics-base-%{epics_version}"
> >  
> >%source setup epics -q -n epics-base-%{epics_version}
> > -#
> > -# Changing the RTEMS Version in 
> > epics-base/configure/os/CONFIG_SITE.Common.RTEMS
> > -#
> > -sed -i 's/RTEMS_VERSION = .*/RTEMS_VERSION = 5/g' 
> > configure/os/CONFIG_SITE.Common.RTEMS
> > -
> > -#
> > -# Changing the RTEMS Base in 
> > epics-base/configure/os/CONFIG_SITE.Common.RTEMS
> > -#
> > -sed -i "s/^RTEMS_BASE .*/RTEMS_BASE = 
> > \/home\/mritunjay\/development\/rtems\/\$\(RTEMS_VERSION\)\-a

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Heinz Junkes]

Thanks Chris for the explanation. It all makes sense.

I stumbled over the following point:

I tested the rc-2 and followed the Quick Guide to Building.
“
To build the tools for the ARM architecture:

../source-builder/sb-set-builder \
  --prefix=$HOME/development/rtems/5.1-rc2 \
  5/rtems-arm

To build the tools, kernel and all packages for the Beagleboneblack:

../source-builder/sb-set-builder \
  --prefix=$HOME/development/rtems/5.1-rc2 \
  5/bsps/beagleboneblack
“

After that I tried to build EPICS and ran into the error of a missing header 
file.
“librtemsNFS.h could not be found”
This header file is in rtems-libbsd which I then had to reinstall and build for 
the target.

Then I thought about whether a recipe could/should consider this dependency.

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 24. Aug 2020, at 01:59, Chris Johns  wrote:
> 
> On 24/8/20 12:38 am, Heinz Junkes wrote:
>> But shouldn't the dependencies for the RTEMS basic installation
>> be taken into account. 
> 
> Dependences are normally checked by the application, package or tool being
> built. In the case of EPICS it should check for a suitable RTEMS, libbsd etc 
> and
> configure itself. Given the high quality of the EPICS software I have assumed 
> it
> does this. The RSB can perform some checks but these are limited and specific.
> If we need to we can add something.
> 
> The RSB builds something based on a recipe someone creates. You can collect 
> one
> or more of these recipes as a set of things to build. You can collect sets of
> things to build as a further set creating a vertical stack of software. A
> vertical stack is one of those classic software stack pictures with the 
> hardware
> at the bottom, then the drivers and OS, networking, protocols, middle-ware and
> an application at the top.
> 
> The RSB is a tool in the RTEMS eco-system that can build a vertical stack for 
> a
> BSP, for example a beagleboneblack or zedboard or you can break down a 
> vertical
> stack to manage and customise any of the steps for your specific needs.
> 
> Customising the steps lets a project, company, who ever create a build set 
> that
> targets a specific configuration for a selected board or sets of boards. A
> company, a large organisation or EPICS can also do this. We call it 
> deployment.
> 
> As an open source project we learnt a hard lesson that supporting deployment 
> is
> a whole project in itself. Deploy is really important but it became a
> distraction from our core focus, the OS and the kernel, consuming more and 
> more
> of our resources. As a result we have focused on tools that help users do 
> this.
> We also welcome commercial support services to do this for users.
> 
>> Maybe I don't understand the purpose of the source-builder.
> 
> This could be due to it's role not being explained clearly. I hope this post 
> helps.
> 
>> But I thought that the necessary rtems-modules (compiler for architecture, 
>> libbsd, etc.) are checked and if something is missing, they are installed?
> 
> The depends on the how the vertical stack is put together. The EPICS build set
> should concentrate on EPICS. Now Mritunjay has included the RSB's
> `rtems-bsp.cfg` BSP configuration file some checks will be made. Once we have
> EPICS building as a package we can move to discuss if it becomes part of the
> default package set the BSPs build set's build:
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/6/rtems-packages.bset
> 
> The packages are pull in on the last line of of a BSP build set:
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/bsps/xilinx_zynq_zedboard.bset
> 
> Integration like this has and still is a long term goal Joel and I have. We
> would like EPICS to sit here with NASA's core flight executive so the bar is 
> as
> low as possible to have these important software packages build ready to run.
> 
>> And when do the tests (epics: make runtests and qemu) come into play? 
> 
> This is something we will need to address. The RSB cleans a build environment
> once it completes a build. The model is unpack source, patch, configure, 
> build,
> install, and then clean. In the case of the RTEMS kernel the test executables
> are optionally installed so a user can run them:
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-common.cfg#n255
> 
> How is EPICS used in real systems? Is the production executable built by EPICS
> from the EPICS source tree? Is it a set of libraries that get installed and an
> application links in these libraries?
> 
> Chris



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Heinz Junkes]

Hallo Chris,

yes it works as described. The header file (librtemsNfs.h) is also there.
I must have done something wrong the day before yesterday. Unfortunately
I can't reproduce it anymore. Sorry for the "false alarm”.

I no longer use librtemNfs.h when using the libbsd stack.
It is no longer necessary there.
For mounting I already use “mount_and_marget_target_path(). This call is ok? 

If I still need it for the legacy stack I can't try it at the moment. 
I will try it next week. But I guess that I don't need it at all anymore with 
RTEMS5.
It seems to be a RTEMS 4 remnant.

Viele Grüße
Heinz 

> On 25. Aug 2020, at 04:07, Chris Johns  wrote:
> 
>> 
>> After that I tried to build EPICS and ran into the error of a missing header 
>> file.
>> “librtemsNFS.h could not be found”
>> This header file is in rtems-libbsd which I then had to reinstall and build 
>> for the target.
> 
> I could not find `librtemsNFS.h` but I found `librtemsNfs.h`? ...
> 
> $ find . -name librtems\*.h
> ./cpukit/libnetworking/librtemsNfs.h
> 
>> 
>> Then I thought about whether a recipe could/should consider this dependency.
>> 
> 
> The header should be there. I am more concerned about the contents of the that
> header ... hmm.
> 
> What calls does EPICS use from this file? I suggest it gets reviewed. The
> problem RTEMS has long term with the interface in `librtemsNfs.h` is it being
> bespoke to the NFS implementation and we may not be able to maintain it in the
> future, for example upgrading NFS to NFSv4.
> 
> In systems I work on for clients I encourage scripting of some form be used.
> Commands hide the implementation details and this lets us (RTEMS) better
> maintain compatibility. The scripting can be plain text files or `joel` 
> scripts
> or command sequences in another configuration format, for example YAML. You 
> can
> directly call shell commands.
> 
> To mount a remote disk use:
> 
>  mkdir /foobar
>  mount -t nfs foo:/bar /foobar
> 
> Chris



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Adding EPICS7 Package to RSB

[Heinz Junkes]

Dear Mritunjay,


> On 26. Aug 2020, at 23:34, Mritunjay Sharma  
> wrote:
> 
> > +Name:  epics-base-%{epics_version}-%{_host}-%{release}
> > +Summary:   EPICS v%{epics_version} for target %{_target} on host %{_host}
> > +Version:   %{epics_version}
> > +Release:   %{release}
> > +URL: https://epics.mpg.de/
> This doesn't look like the right url.
> 
> I cross-checked and it seems to be working. 


The link should be 
https://epics-controls.org/ 
please.


> 
> > +
> > +#
> > +# Source
> > +#
> > +%source set epics-base 
> > https://gitlab.fhi.mpg.de/junkes/epics-base/-/archive/%{epics_version}/epics-base-%{epics_version}.tar.gz
> ditto
> 
> where do official EPICS releases go?
> 
> I think we need Heinz intervention in this and I am ready to help him get it 
> done.
> We have to use this repo for the time being.

Yes, please leave it like this temporarily. I am working on the integration 
into the official release and then
the link will change something like this:

git clone //https://github.com/epics-base/epics-base.git

or possibly then also set to a fix release, like:
https://github.com/epics-base/epics-base/releases/tag/R7.0.4.1

Heinz

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

x86 c++ exception handling

[Heinz Junkes]

Here is a mail I received from a colleague.

It concerns thereby an "old" problem which seemed already solved?

FYI. I can run the unit tests, but I'm seeing a couple of hangs.
The first I'm looking at is epicsTimeTest which seems to be
related to c++ exception handling.  I recall that there were
problems with x86 exception handling, but I also recall hearing
that this was fixed.

...
> * Starting EPICS application *
> 1..212
> ok  1 - epicsTime_gmtime() for EPICS epoch
> ok  2 - nanosecond overflow throws
... hangs ...

Attaching debugger shows:

> Program received signal SIGINT, Interrupt.
> libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at 
> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
> 44  ../../../../gcc-7.5.0/libatomic/fop_n.c: No such file or directory.
> (gdb) bt
> #0  libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at 
> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
> #1  0x003b07fc in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x757730)
>at 
> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:49
> #2  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x757730)
>at 
> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:82
> #3  __gnu_cxx::__eh_atomic_dec (__count=0x757730) at 
> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_atomics.h:72
> #4  __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT, exc=0x757770)
>at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_throw.cc:46
> #5  0x003ad9cb in _Unwind_DeleteException (exc=0x757770) at 
> ../../../../gcc-7.5.0/libgcc/unwind.inc:271
> #6  0x003af8d0 in __cxxabiv1::__cxa_end_catch () at 
> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_catch.cc:125
> #7  0x001012fd in epicsTimeTest () at ../epicsTimeTest.cpp:116
> (gdb)

Viele Grüße
Heinz



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Successfully built EPICS 7 with RTEMS 5 for mvme6100

[Heinz Junkes]

Hello, Mritunjay,

I will contact you tomorrow during the day (European time).  We have here 
institute closings because of Corona Virus etc..  

It's great that you've come this far. I can also provide you with an MVME6100 
remotely so you can get a feeling for target development. 
Yes, I have also started development of libbsd and the MVME2500. More on this 
tomorrow.

But the first, important step in this proposal would be to get EPICS7 running 
with RTEMS5 on e.g. qemu, ideally on i386?
I think I had some problems with the psim in the past. Unfortunately I don't 
know exactly what it is anymore. 
More tomorrow.

Many greetings and stay healthy,
Heinz
--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
--

> On 18. Mar 2020, at 19:56, Mritunjay Sharma  
> wrote:
> 
> Thank you so much for the feedback. I will research more on the targets that 
> can run with the simulator and would like to tell you that looking at 
> https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0, I feel that 
> @Heinz Junkes is already working on libbsd for RTEMS-MVME2500 and I would 
> like to hear more from him to get some clarity on what can be done. Being a 
> beginner, it's really a great welcome to the world of cross-compiler 
> development and testing. :) Thank you for always helping me out! 
> 
> On Wed, Mar 18, 2020 at 11:51 PM Gedare Bloom  wrote:
> On Wed, Mar 18, 2020 at 11:40 AM Mritunjay Sharma
>  wrote:
> >
> > Hi everyone,
> >
> > As a part of working on ticket #3835 (BSP Buildset for EPICS), this is to 
> > inform the community that after a lot of research, help from RTEMS and 
> > EPICS community and 
> > https://epics.mpg.de/index.php?n=Software.EPICSRTEMS?userlang=en, I was 
> > able to build EPICS 7 for RTEMS 5 for mvme6100 (powerpc-rtems5).
> > After this, my development environment is almost completely set up with 
> > RTEMS, rtems-source-builder and epics7 (taken from 
> > https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0 ). While going 
> > through the entire process, I learnt about the changes to be made in 
> > epics7/configure/os/CONFIG_STATUS.Common.RTEMS and also encountered few 
> > errors while the 'make' process, however, it got fixed by commenting line 
> > 325 to 329 in 
> > '/home/mritunjay/development/rtems/5/powerpc-rtems5/beatnik/lib/include/rtems/confdefs/libio.h':
> > //  #ifdef CONFIGURE_FILESYSTEM_ENTRY_DEVFS
> > //CONFIGURE_FILESYSTEM_ENTRY_DEVFS,
> > //  #endif
> > I would like to know more on why this behaviour occurred. Is it a bug? Or 
> > something else?
> >
> Include some of this detail in your proposal. I don't have time at the
> moment to delve into details.
> 
> Next step would be to identify a target you can build EPICS7+RTEMS5
> with simulator support. This one is challenging since AFAIK there
> haven't been any successes in that regards. Find out what are the
> blockers and maybe you can work on those.
> 
> > I wanted to test it but I am facing issues in connecting with tftp server 
> > when I run 'scp bin/RTEMS-beatnik/libComTestHarness.boot 
> > root@epics:/var/lib/tftp'
> > The following error was encountered:
> > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> > information available (required by /usr/bin/ssh)
> > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> > information available (required by /usr/bin/ssh)
> > ssh: Could not resolve hostname epics: Name or service not known
> > lost connection
> > I was wondering what can be the reason behind this, please help me fix this.
> >
> Test it how -- do you have a powerpc MVME6100 board?
> 
> I'm guessing whoever gave you that scp command line has a board with a
> local /etc/hosts entry for 'epics' pointing to some local IP address
> they connect to their board over.
> 
> Welcome to the world of cross-compiler development and testing. :)
> https://docs.rtems.org/branches/master/user/hosts/index.html#development-host
> 
> > Also, what are the next steps? I am working on the GSoC proposal currently 
> > and since the current ticket #3835 is a shorter project, I have to add 
> > certain similar sub-tasks within the GSoC timeline as suggested by @Gedare 
> > Bloom :
> > "* compile CFS by hand, create an RSB "recipe" to bui

Re: Successfully built EPICS 7 with RTEMS 5 for mvme6100

[Heinz Junkes]

> On 18. Mar 2020, at 22:17, Joel Sherrill  wrote:
> 
> We have had good experiences with RTEMS+libbsd with the Qemu ARM Zynq. 
> We have been able to telnet to the RTEMS target from Linux and use the RTEMS
> NFS client to mount Linux files plus dynamic loading works. Personally I 
> would 
> start with that since the goal is EPICS not fixing a BSP. :)

This is a very good proposal, which I fully support.

> 
> My second would be Qemu i386 pc386 but I don't know the status of libbsd on 
> pc386 at the moment. This should work the same as the Zynq qemu but I 
> personally don't know. Heinz.. do you have recent experience on it?

Not really good ones, unfortunately. We should try that when there is still 
time.

I will put together the things I have done for libbsd and EPICS/Rtems.

Heinz



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Where can I get the kernel sources?

[Heinz Junkes]

I think I slept through the latest development. Sorry about that.

I wanted to integrate a pull request from Till 
(https://github.com/RTEMS/rtems/pull/41)
into rtems6. But unfortunately I can no longer find the sources.

$: git clone git://git.rtems.org/rtems.git kernel
$: cd kernel
$: ls c
ACKNOWLEDGEMENTS

I am used to this:

$: git checkout 5
Switched to branch '5'
Your branch is up to date with 'origin/5’.
$: ls c
acinclude.m4  ACKNOWLEDGEMENTS  configure.ac  Makefile.am  src

I also saw this ticket (https://devel.rtems.org/ticket/4046):
Bootstrapping is going away with the new build system and until then the 
command in rtems.git should be used.

Unfortunately, I'm not getting anywhere with it.
How must/should I proceed?

Danke, Heinz
--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
--

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

Re: Where can I get the kernel sources?

[Heinz Junkes]

Danke Sebastian,

I have been able to place the drivers from Till in rtems-libbsd without much 
effort.
I can boot the MVME6100 with the mv653xx: 
...
mve0 on nexus0
miibus0:  on mve0
ukphy0:  PHY 0 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
info: mve0: Ethernet address: ec:9e:cd:1a:12:3f
info: lo0: link state changed to UP
…

Can/should I create a pull request so that this can be transferred to the 
master?

rtems-libbsd$ git status
On branch 6-freebsd-12
Your branch is up to date with 'origin/6-freebsd-12'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

new file:   rtemsbsd/include/bsp/mv643xx_eth.h
new file:   rtemsbsd/sys/dev/mve/mv643xx_nexus.c
new file:   rtemsbsd/sys/powerpc/drivers/net/if_mve/mv643xx_eth.c

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   libbsd.py
modified:   rtemsbsd/include/bsp/nexus-devices.h

Heinz


> On 3. Feb 2022, at 08:05, Sebastian Huber 
>  wrote:
> 
> Hello Heinz,
> 
> On 03/02/2022 06:57, Heinz Junkes wrote:
>> I think I slept through the latest development. Sorry about that.
>> I wanted to integrate a pull request from Till 
>> (https://github.com/RTEMS/rtems/pull/41)
>> into rtems6. But unfortunately I can no longer find the sources.
>> $: git clone git://git.rtems.org/rtems.git kernel
>> $: cd kernel
>> $: ls c
>> ACKNOWLEDGEMENTS
>> I am used to this:
>> $: git checkout 5
>> Switched to branch '5'
>> Your branch is up to date with 'origin/5’.
>> $: ls c
>> acinclude.m4  ACKNOWLEDGEMENTS  configure.ac  Makefile.am  src
>> I also saw this ticket (https://devel.rtems.org/ticket/4046):
>> Bootstrapping is going away with the new build system and until then the 
>> command in rtems.git should be used.
>> Unfortunately, I'm not getting anywhere with it.
>> How must/should I proceed?
> 
> the BSP sources are in "bsps" since RTEMS 5. In "c" is mostly the old build 
> system in RTEMS 5 which was removed in RTEMS 6.
> 
> I tried to rebase the pull request to RTEMS 6 (master), however, then I 
> noticed that the old network stack and all the network interface drivers are 
> not longer included in the RTEMS sources. The old network stack is now in a 
> separate repository:
> 
> https://git.rtems.org/rtems-net-legacy/
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

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

i2c initialization MVME3100

[Heinz Junkes]

in bsps/powerpc/mvme3100/start/bspstart.c I can find

RTEMS_SYSINIT_ITEM{
  mvme3100_i2c_initialize,
  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
  RTEMS_SYSINIT_ORDER_MIDDLE
);

mvme3100_i2c_initialize calls BSP_i2c_initialize

This can be found in bsps/powerpc/mvme3100/i2c/i2c_init.c
This function calls rtems_libi2c_initialize() from cpukit/libi2c/libi2c.c

and here rtems_io_register_driver gets called:

sc = rtems_io_register_driver (0, &rtems_libi2c_io_ops, &rtems_libi2c_major);

But in cpukit/sapi/src/ioregisterdriver.c

in rtems_io_register_driver () the call of the associated init routine gets 
postponed to
a later stage because _IO_All_drivers_initializes is not true in this early of 
bspstart.
so
} else {
  /* The driver will be initialized together with all other drivers
   * in a later stage by _IO_Initialize_all_drivers();
   */
  return RTEMS_SUCCESSFUL;
}

Now in 
bsps/powerpc/mvme3100/i2c/i2c_init.c

the following calls e.g.
 busno=rtems_libi2c_register_bus(
 BSP_I2C_BUS0_NAME,
…
must fail?

I hope I have analysed this correctly. I may be wrong, but the output of the 
mvme3100 looks like this:

Registering mpc8540 i2c bus driver :No such file or directory
Registering /dev/console as minor 0 (==/dev/ttyS0)
ds1375_probe (open): No such file or directory

This happens during initialization in EPICS. The test suite programmes do not 
produce this output.

In the test programmes, however, the initialisation probably fails because the 
MAXIMUM_DRIVER is default 4.
e.g. TEST I2C 1

libi2c: Claiming driver slot failed (rtems status code 10)
Initializing I2C library failed

Danke Heinz


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

Re: i2c initialization MVME3100

[Heinz Junkes]

I'll answer my question myself ;-)

I changed

> RTEMS_SYSINIT_ITEM{
>  mvme3100_i2c_initialize,
>  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
>  RTEMS_SYSINIT_ORDER_MIDDLE
> );

to

RTEMS_SYSINIT_ITEM{
   mvme3100_i2c_initialize,
   RTEMS_SYSINIT_BSP_DRVMGR_LEVEL_2,
   RTEMS_SYSINIT_ORDER_MIDDLE
);

Heinz

> On 7. Feb 2022, at 14:42, Heinz Junkes  wrote:
> 
> in bsps/powerpc/mvme3100/start/bspstart.c I can find
> 
> RTEMS_SYSINIT_ITEM{
>  mvme3100_i2c_initialize,
>  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
>  RTEMS_SYSINIT_ORDER_MIDDLE
> );
> 
> mvme3100_i2c_initialize calls BSP_i2c_initialize
> 
> This can be found in bsps/powerpc/mvme3100/i2c/i2c_init.c
> This function calls rtems_libi2c_initialize() from cpukit/libi2c/libi2c.c
> 
> and here rtems_io_register_driver gets called:
> 
> sc = rtems_io_register_driver (0, &rtems_libi2c_io_ops, &rtems_libi2c_major);
> 
> But in cpukit/sapi/src/ioregisterdriver.c
> 
> in rtems_io_register_driver () the call of the associated init routine gets 
> postponed to
> a later stage because _IO_All_drivers_initializes is not true in this early 
> of bspstart.
> so
> } else {
>  /* The driver will be initialized together with all other drivers
>   * in a later stage by _IO_Initialize_all_drivers();
>   */
>  return RTEMS_SUCCESSFUL;
> }
> 
> Now in 
> bsps/powerpc/mvme3100/i2c/i2c_init.c
> 
> the following calls e.g.
> busno=rtems_libi2c_register_bus(
> BSP_I2C_BUS0_NAME,
> …
> must fail?
> 
> I hope I have analysed this correctly. I may be wrong, but the output of the 
> mvme3100 looks like this:
> 
> Registering mpc8540 i2c bus driver :No such file or directory
> Registering /dev/console as minor 0 (==/dev/ttyS0)
> ds1375_probe (open): No such file or directory
> 
> This happens during initialization in EPICS. The test suite programmes do not 
> produce this output.
> 
> In the test programmes, however, the initialisation probably fails because 
> the MAXIMUM_DRIVER is default 4.
> e.g. TEST I2C 1
> 
> libi2c: Claiming driver slot failed (rtems status code 10)
> Initializing I2C library failed
> 
> Danke Heinz
> 
> 
> ___
> 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

config, _IO_Initialize_all_drivers

[Heinz Junkes]

I'm still trying to get the booting and registering and initialising of the i2c 
devices on the MVME3100 to work properly.

In confdefs/iodrivers.h the driver address table is built up and then 
_IO_Initialize_all_drivers() is called without registering the individual 
devices first.

If I now enter in already before in bspstart.c

RTEMS_SYSINIT_ITEM(
  mvme3100_i2c_initialize,
  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
  RTEMS_SYSINIT_ORDER_MIDDLE
);

a device (register it and e.g. got the major number 0) this is ignored by the 
IO_Initialize_all_drivers().

Shouldn't initialisation be preceded by registration ( 
rtems_io_register_driver() )?

Heinz

rtems_driver_address_table
_IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
  #ifdef CONFIGURE_BSP_PREREQUISITE_DRIVERS
CONFIGURE_BSP_PREREQUISITE_DRIVERS,
  #endif
  #ifdef CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS
CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
CONSOLE_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER
RTC_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER
WATCHDOG_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
DEVNULL_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
DEVZERO_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER
IDE_CONTROLLER_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
ATA_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
FRAME_BUFFER_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_EXTRA_DRIVERS
CONFIGURE_APPLICATION_EXTRA_DRIVERS,
  #endif
  #if defined(CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER) \
|| ( !defined(CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_EXTRA_DRIVERS) )
NULL_DRIVER_TABLE_ENTRY
  #endif
};

const size_t _IO_Number_of_drivers =
  RTEMS_ARRAY_SIZE( _IO_Driver_address_table );

RTEMS_SYSINIT_ITEM(
  _IO_Initialize_all_drivers,
  RTEMS_SYSINIT_DEVICE_DRIVERS,
  RTEMS_SYSINIT_ORDER_MIDDLE
);



--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
--

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

Re: config, _IO_Initialize_all_drivers

[Heinz Junkes]

> On 18. Feb 2022, at 17:47, Joel Sherrill  wrote:
> 
> 
> "Normally" the driver initialization entry registers names.

Unfortunately, I cannot confirm that. I don't see any registrations 
(rtems_io_register_driver()) of the drivers.

Only rtems_io_initialize() major 0 - > (in my case) 39 is called.

Heinz

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

Re: [PATCH] spec/build/bsps: Fix blank variables

[Heinz Junkes]

Thanks for that. I've been struggling with this for a while ;-)

But there is this comment in the file:
“
#
# BSP specific settings. To be included in application Makefiles
#
# This support will be removed from RTEMS. Please consider other
# ways to build applications.
#
“
I thought this was no longer maintained and the "correct" way is now pkg-config?
Or am I wrong here?

Danke Heinz



> On 9. Mar 2022, at 22:02, Ryan Long  wrote:
> 
> Several variables in the installed Makefile.inc, target.cfg, and bsp.cfg
> had values that were not being initialized to yes or no as they should
> be. Reordering the files and adding an initialization using yesno() to
> RTEMS_HAS_NETWORKING fixed this issue.
> ---
> spec/build/bsps/grpmake.yml | 8 
> spec/build/bsps/optmake.yml | 1 +
> 2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/spec/build/bsps/grpmake.yml b/spec/build/bsps/grpmake.yml
> index 0998efc..f4a21f2 100644
> --- a/spec/build/bsps/grpmake.yml
> +++ b/spec/build/bsps/grpmake.yml
> @@ -30,15 +30,15 @@ install:
> ldflags: []
> links:
> - role: build-dependency
> -  uid: makebsp
> -- role: build-dependency
>   uid: makecustom
> - role: build-dependency
> +  uid: optmake
> +- role: build-dependency
> +  uid: makebsp
> +- role: build-dependency
>   uid: makeinc
> - role: build-dependency
>   uid: maketarget
> -- role: build-dependency
> -  uid: optmake
> type: build
> use-after: []
> use-before: []
> diff --git a/spec/build/bsps/optmake.yml b/spec/build/bsps/optmake.yml
> index 28e9660..bea2c90 100644
> --- a/spec/build/bsps/optmake.yml
> +++ b/spec/build/bsps/optmake.yml
> @@ -7,6 +7,7 @@ actions:
> return "no"
> conf.env["RTEMS_HAS_MULTIPROCESSING"] = yesno(conf, 
> "RTEMS_MULTIPROCESSING")
> conf.env["RTEMS_HAS_POSIX_API"] = yesno(conf, "RTEMS_POSIX_API")
> +conf.env["RTEMS_HAS_NETWORKING"] = yesno(conf, "RTEMS_NETWORKING")
> build-type: option
> copyrights:
> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -- 
> 1.8.3.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

Re: [PATCH 11/40] bsps/include/libchip/disp_hcms29xx.h: Manual file header clean up

[Heinz Junkes]

0:17: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  780 |   &softc_ptr->disp_param.task_id);
  | ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:783:36: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  783 | rc = rtems_task_start(softc_ptr->disp_param.task_id,
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c: In function 
'disp_hcms29xx_dev_open':
../../../bsps/shared/dev/display/disp_hcms29xx.c:813:12: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  813 |   softc_ptr->disp_param.dev_buf_cnt = 0;
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c: In function 
'disp_hcms29xx_dev_write':
../../../bsps/shared/dev/display/disp_hcms29xx.c:846:20: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  846 | if (((softc_ptr->disp_param.dev_buf_cnt > 0)
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:850:15: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  850 |  ||( softc_ptr->disp_param.dev_buf_cnt >=
  |   ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:851:28: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  851 |  (int) sizeof(softc_ptr->disp_param.dev_buffer) - 1)) {
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:852:16: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  852 |   
softc_ptr->disp_param.dev_buffer[softc_ptr->disp_param.dev_buf_cnt] = '\0';
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:852:49: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  852 |   
softc_ptr->disp_param.dev_buffer[softc_ptr->disp_param.dev_buf_cnt] = '\0';
  | ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:856:47: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  856 |   disp_hcms29xx_update(softc_ptr,softc_ptr->disp_param.dev_buffer);
  |   ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:857:16: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  857 |   softc_ptr->disp_param.dev_buf_cnt = 0;
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:864:16: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  864 |   
softc_ptr->disp_param.dev_buffer[softc_ptr->disp_param.dev_buf_cnt++] =
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:864:49: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  864 |   
softc_ptr->disp_param.dev_buffer[softc_ptr->disp_param.dev_buf_cnt++] =
  | ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c: At top level:
../../../bsps/shared/dev/display/disp_hcms29xx.c:913:3: error: extra brace 
group at end of initializer
  913 |   { /* our private fields */
  |   ^
../../../bsps/shared/dev/display/disp_hcms29xx.c:913:3: note: (near 
initialization for 'disp_hcms29xx_drv_tbl')
../../../bsps/shared/dev/display/disp_hcms29xx.c:915:5: error: extra brace 
group at end of initializer
  915 | { 0 },
  | ^
../../../bsps/shared/dev/display/disp_hcms29xx.c:915:5: note: (near 
initialization for 'disp_hcms29xx_drv_tbl')
../../../bsps/shared/dev/display/disp_hcms29xx.c:917:5: error: extra brace 
group at end of initializer
  917 | { 0 },
  | ^
../../../bsps/shared/dev/display/disp_hcms29xx.c:917:5: note: (near 
initialization for 'disp_hcms29xx_drv_tbl')
../../../bsps/shared/dev/display/disp_hcms29xx.c:918:5: error: extra brace 
group at end of initializer
  918 | { 0 },
  | ^
../../../bsps/shared/dev/display/disp_hcms29xx.c:918:5: note: (near 
initialization for 'disp_hcms29xx_drv_tbl')
../../../bsps/shared/dev/display/disp_hcms29xx.c:913:3: warning: excess 
elements in struct initializer
  913 |   { /* our private fields */
  |   ^
../../../bsps/shared/dev/display/disp_hcms29xx.c:913:3: note: (near 
initialization for 'disp_hcms29xx_drv_tbl')

Waf: Leaving directory 
`/home/rtems/RTEMS_MASTER_08_03_22/kernel/build/powerpc/beatnik'
Build failed

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 7. Mar 2022, at 14:23, Christian Mauderer 
>  wrote:
> 
> From: Joel Sherrill 
> 
> Updates #4625.
> ---
> bsps/include/libchip/disp_hcms29xx.h | 32 +++-
> 1 file changed, 13 insertions(+), 19 deletions(-)
> 
> diff --git a/bsps/include/libchip/disp_hcms29xx.h 
> b/bsps/include/libchip/disp_hcms29xx.h
> index 84b74b6910..bcaf25f46e 100644
> --- a/bsps/include/libchip/disp_hcms29xx.h
> +++ b/bsps/include/libchip/disp_hcms29xx.h
> @@ -1,22 +1,16 @@
> -/*===*\
> -| Project: display driver for HCMS29xx|
> -+-+
> -| File: disp_hcms29xx.h   |
> -+-+
> -|Copyright (c) 2008   |
> -|Embedded Brains GmbH |
> -|Obere Lagerstr. 30   |
> -|D-82178 Puchheim |
> -|Germany  |
> -|rt...@embedded-brains.de |
> -+-+
> -| The license and distribution terms for this file may be |
> -| found in the file LICENSE in this distribution or at|
> -| http://www.rtems.org/license/LICENSE.   |
> -+-+
> -| this file declares the SPI based driver for a HCMS29xx 4 digit  |
> -| alphanumeric LED display|
> -\*===*/
> +/*
> + * Display driver for HCMS29xx
> + *
> + * This file declares the SPI based driver for a HCMS29xx 4 digit
> + * alphanumeric LED display
> + */
> +
> +/*
> + * Copyright (c) 2008 embedded brains GmbH. All rights reserved.
> + *
> + * The license and distribution terms for this file may be
> + * found in the file LICENSE in this distribution or at
> + * http://www.rtems.org/license/LICENSE.
> 
> #ifndef _DISP_HCMS29XX_H
> #define _DISP_HCMS29XX_H
> -- 
> 2.34.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

Re: [PATCH 11/40] bsps/include/libchip/disp_hcms29xx.h: Manual file header clean up

[Heinz Junkes]

Only the comment end ( */ ) is missing
in bsps/include/libchip/disp_hcms29xx.h
at line 14.

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 10. Mar 2022, at 14:39, Heinz Junkes  wrote:
> 
> I get this at the moment when compiling the kernel:
> 
> ...
> [  48/4243] Compiling 
> bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
> [  49/4243] Compiling bsps/shared/irq/irq-shell.c
> [  50/4243] Compiling bsps/shared/irq/irq-info.c
> In file included from ../../../bsps/shared/dev/display/disp_hcms29xx.c:24:
> ../../../bsps/include/libchip/disp_hcms29xx.h:26:40: warning: "/*" within 
> comment [-Wcomment]
>   26 | rtems_device_minor_number minor;   /* minor device number  
>   */
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

nfsclient rtems6 rtems-libbsd

[Heinz Junkes]

Hello,

I am trying the nfs-client with rtems6 and rtems-libbsd.
(on BSP “beatnik”)

I have not analyzed everything yet.
I just wanted to ask if, and how, someone has already managed it?

When I call mount_and_make_target_path().

rval = mount_and_make_target_path(dev, mntpoint,
  RTEMS_FILESYSTEM_TYPE_NFS, RTEMS_FILESYSTEM_READ_WRITE,
  mount_options);

and take as mount_options "nfsv2" comes this:

Mount 141.14.131.192:/Volume on /Volume
nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv2)
nfs: mount: [tcp] 141.14.131.192:/Volume: RPCPROG_NFS: RPC: Port mapper failure 
- RPC: Server can't decode arguments

as mount_options "nfs3" comes that:

Mount 141.14.131.192:/Volume on /Volume
nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv3)
nfs: mount: [tcp] 141.14.131.192:/Volume: RPCPROG_NFS: RPC: Port mapper failure 
- RPC: Server can't decode arguments
mount: 5: I/O error

as mount_options "nfsv4,minorversion=1" comes that:

Mount 141.14.131.192:/Volume on /Volume
nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv4,minorversion=1)
nfs: mount args: 8
  16 addr=10 02 08 01 8d 0e 83 c0 00 00 00 00 00 00 00 00
   0 nfsv4
   8 dirpath=/Volume
   4 fstype=nfs
   7 fspath=Volume
  23 hostname=141.14.131.192:/Volume
   0 rw
   2 minorversion=1
nfs: mount: (2) No such file or directory
mount: 2: No such file or directory

Is it generally the case that the nfs cannot mount a subdir with the 
rtems-libbsd?
i.e.
Mount 141.14.131.192:/Volumes/Epics on /Volumes/Epics

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



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

Re: nfsclient rtems6 rtems-libbsd

[Heinz Junkes]

In the case of the option "nfsv4,minorversion=1" I get an 

error 2 (No such file or directory) from

error = kernel_mount(args->ma, MNT_VERIFIED);

in file ./rtemsbsd/fs/nfsclient/nfs.c


Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 16. Mar 2022, at 16:00, Heinz Junkes  wrote:
> 
> Hello,
> 
> I am trying the nfs-client with rtems6 and rtems-libbsd.
> (on BSP “beatnik”)
> 
> I have not analyzed everything yet.
> I just wanted to ask if, and how, someone has already managed it?
> 
> When I call mount_and_make_target_path().
> 
>rval = mount_and_make_target_path(dev, mntpoint,
>  RTEMS_FILESYSTEM_TYPE_NFS, RTEMS_FILESYSTEM_READ_WRITE,
>  mount_options);
> 
> and take as mount_options "nfsv2" comes this:
> 
> Mount 141.14.131.192:/Volume on /Volume
> nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv2)
> nfs: mount: [tcp] 141.14.131.192:/Volume: RPCPROG_NFS: RPC: Port mapper 
> failure - RPC: Server can't decode arguments
> 
> as mount_options "nfs3" comes that:
> 
> Mount 141.14.131.192:/Volume on /Volume
> nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv3)
> nfs: mount: [tcp] 141.14.131.192:/Volume: RPCPROG_NFS: RPC: Port mapper 
> failure - RPC: Server can't decode arguments
> mount: 5: I/O error
> 
> as mount_options "nfsv4,minorversion=1" comes that:
> 
> Mount 141.14.131.192:/Volume on /Volume
> nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv4,minorversion=1)
> nfs: mount args: 8
>  16 addr=10 02 08 01 8d 0e 83 c0 00 00 00 00 00 00 00 00
>   0 nfsv4
>   8 dirpath=/Volume
>   4 fstype=nfs
>   7 fspath=Volume
>  23 hostname=141.14.131.192:/Volume
>   0 rw
>   2 minorversion=1
> nfs: mount: (2) No such file or directory
> mount: 2: No such file or directory
> 
> Is it generally the case that the nfs cannot mount a subdir with the 
> rtems-libbsd?
> i.e.
> Mount 141.14.131.192:/Volumes/Epics on /Volumes/Epics
> 
> Viele Grüße
> Heinz Junkes
> --
> Experience directly varies with equipment ruined.
> 
> 
> 
> ___
> 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

arm (bsp=xilinx_zynq_a9_qemu ) task in 'testsuites/fstests/fsdosfsname01.exe' failed

[Heinz Junkes]

Waf: Leaving directory 
`/home/rtems/ARM_TST/kernel/build/arm/xilinx_zynq_a9_qemu'
Build failed
 -> task in 'testsuites/fstests/fsdosfsname01.exe' failed with exit status 1 
(run with -v to display more information)

[1714/4241] Linking 
build/arm/xilinx_zynq_a9_qemu/testsuites/fstests/mimfs_fspermission.exe
[1715/4241] Linking 
build/arm/xilinx_zynq_a9_qemu/testsuites/fstests/mdosfs_fsrdwr.exe
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/lib/thumb/armv7-a+simd/hard/libc.a(libc_a-ucsconv.o):
 in function `ucs_based_conversion_open':
/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:66:
 undefined reference to `_iconv_to_ucs_ces'
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:66:
 undefined reference to `_iconv_to_ucs_ces'
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:78:
 undefined reference to `_iconv_from_ucs_ces'
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:78:
 undefined reference to `_iconv_from_ucs_ces'
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:77:
 undefined reference to `_iconv_from_ucs_ces'
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:77:
 undefined reference to `_iconv_from_ucs_ces'
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:78:
 undefined reference to `_iconv_from_ucs_ces'
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
 
/home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/lib/thumb/armv7-a+simd/hard/libc.a(libc_a-ucsconv.o):/home/rtems/ARM_TST/rsb/rtems/build/arm-rtems6-gcc-0f001dd-newlib-d88cbd0-x86_64-linux-gnu-1/build/arm-rtems6/thumb/armv7-a+simd/hard/newlib/../../../../../../gnu-mirror-gcc-0f001dd/newlib/libc/iconv/lib/ucsconv.c:78:
 more undefined references to `_iconv_from_ucs_ces' follow
collect2: error: ld returned 1 exit status

Gruss Heinz


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

Re: arm (bsp=xilinx_zynq_a9_qemu ) task in 'testsuites/fstests/fsdosfsname01.exe' failed

[Heinz Junkes]

Thank you, now I get this :

RTEMS Source Builder - Set Builder, 6 (53cb27c0f520)
Build Set: 6/rtems-arm
…
cleaning: gmp-6.1.0-x86_64-linux-gnu-1
reporting: devel/gmp-6.1.0.cfg -> gmp-6.1.0-x86_64-linux-gnu-1.txt
reporting: devel/gmp-6.1.0.cfg -> gmp-6.1.0-x86_64-linux-gnu-1.xml
config: tools/rtems-gdb-11.2.cfg
error: config error: gdb-common-1.cfg:99: "gdb: python: header file not found: 
python3.7/Python.h, please install"
Build FAILED
Build Set: Time 0:00:37.886220
Build FAILED

I had to install python-dev on my unix-box:

apt install python3-dev

Then everything worked out.

Danke, Heinz


> On 22. Mar 2022, at 21:30, Sebastian Huber 
>  wrote:
> 
> Hello Heinz,
> 
> On 19/03/2022 16:54, Heinz Junkes wrote:
>> Waf: Leaving directory 
>> `/home/rtems/ARM_TST/kernel/build/arm/xilinx_zynq_a9_qemu'
>> Build failed
>>  -> task in 'testsuites/fstests/fsdosfsname01.exe' failed with exit status 1 
>> (run with -v to display more information)
>> [1714/4241] Linking 
>> build/arm/xilinx_zynq_a9_qemu/testsuites/fstests/mimfs_fspermission.exe
>> [1715/4241] Linking 
>> build/arm/xilinx_zynq_a9_qemu/testsuites/fstests/mdosfs_fsrdwr.exe
>> /home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld:
>>  
>> /home/rtems/ARM_WORK/rtems/6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/lib/thumb/armv7-a+simd/hard/libc.a(libc_a-ucsconv.o):
>>  in function `ucs_based_conversion_open':
> 
> this should be fixed in the latest RSB. The update of the Newlib build system 
> should be complete now.
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

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

Typo in rtems-libbsd/rtems_waf/rtems.py?

[Heinz Junkes]

Hi,

It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.

rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' + 
rtems_version)
if not os.path.exists(os.path.join(rtems_share_rtems_version)):
ctx.fatal('RTEMS path is not valid, "%s" not found.' % 
(rtems_share_rtems_version))

I think that "+ rtems_version" does not belong there?

git clone https://github.com/RTEMS/rtems-libbsd.git
cd rtems-libbsd/
git checkout 6-freebsd-12
git submodule init
git submodule update rtems_waf

./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik 
--buildset=buildset/default.ini

leads to : 

# project  configured on Tue Jan 17 17:46:09 2023 by
# waf 2.0.19 (abi 20, python 20710f0 on linux2)
# using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6 
--rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
#

Setting top to
/home/rtems/MVME6100_6_INST/rtems-libbsd

Setting out to
/home/rtems/MVME6100_6_INST/rtems-libbsd/build
from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid, 
"/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.


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

Re: Typo in rtems-libbsd/rtems_waf/rtems.py?

[Heinz Junkes]

Sorry, I just saw my install script threw an error:

rtems@rtems-dev:~/MVME6100_6_INST/kernel$ ./waf bsp_defaults 
--rtems-bsps=powerpc/beatnik > config.ini
No function 'bsp_defaults' defined in /home/rtems/MVME6100_6_INST/kernel/wscript

Heinz


> On 17. Jan 2023, at 21:08, Chris Johns  wrote:
> 
> On 18/1/2023 6:16 am, Frank Kühndel wrote:
>> have you installed RTEMS (not only the tools) in `${RTEMS_ROOT}` before
>> configuring libbsd? If I am not mistaken, installing RTEMS creates the
>> `share/rtems6` directory.
> 
> This is correct and it is a simple and fast key to see if a kernel of a 
> specific
> version has been installed.
> 
>> On 1/17/23 18:11, Heinz Junkes wrote:
>>> Hi,
>>> 
>>> It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
>>> 
>>> rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
>>> rtems_version)
>>> if not os.path.exists(os.path.join(rtems_share_rtems_version)):
>>>  ctx.fatal('RTEMS path is not valid, "%s" not found.' %
>>> (rtems_share_rtems_version))
>>> 
>>> I think that "+ rtems_version" does not belong there?
>>> 
>>> git clonehttps://github.com/RTEMS/rtems-libbsd.git
>>> cd rtems-libbsd/
>>> git checkout 6-freebsd-12
>>> git submodule init
>>> git submodule update rtems_waf
>>> 
>>> ./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
>>> --buildset=buildset/default.ini
> 
> As Frank points put the kernel needs to be installed before this command is 
> run.
> 
> Chris
> 
>>> 
>>> leads to :
>>> 
>>> # project  configured on Tue Jan 17 17:46:09 2023 by
>>> # waf 2.0.19 (abi 20, python 20710f0 on linux2)
>>> # using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
>>> --rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
>>> #
>>> 
>>> Setting top to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd
>>> 
>>> Setting out to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd/build
>>> from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
>>> "/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
>>> 
>>> 
>>> Heinz
>> 

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

Re: Typo in rtems-libbsd/rtems_waf/rtems.py?

[Heinz Junkes]

ok with
 ./waf bspdefaults --rtems-bsps=powerpc/beatnik … it works 

I had ./waf bsp_defaults :-(


rtems@rtems-dev:~/MVME6100_6_RUN/rtems/6/share$ ls -l
total 36
drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:09 doc
drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:42 gcc-12.2.1
drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:44 gdb
drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 iconv_data
drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 info
drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:13 locale
drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:42 man
drwxr-xr-x 9 rtems rtems 4096 Jan 17 17:44 rtems
drwxr-xr-x 3 rtems rtems 4096 Jan 17 21:15 rtems6

Danke, Heinz

> On 17. Jan 2023, at 21:08, Chris Johns  wrote:
> 
> On 18/1/2023 6:16 am, Frank Kühndel wrote:
>> have you installed RTEMS (not only the tools) in `${RTEMS_ROOT}` before
>> configuring libbsd? If I am not mistaken, installing RTEMS creates the
>> `share/rtems6` directory.
> 
> This is correct and it is a simple and fast key to see if a kernel of a 
> specific
> version has been installed.
> 
>> On 1/17/23 18:11, Heinz Junkes wrote:
>>> Hi,
>>> 
>>> It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
>>> 
>>> rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
>>> rtems_version)
>>> if not os.path.exists(os.path.join(rtems_share_rtems_version)):
>>>  ctx.fatal('RTEMS path is not valid, "%s" not found.' %
>>> (rtems_share_rtems_version))
>>> 
>>> I think that "+ rtems_version" does not belong there?
>>> 
>>> git clonehttps://github.com/RTEMS/rtems-libbsd.git
>>> cd rtems-libbsd/
>>> git checkout 6-freebsd-12
>>> git submodule init
>>> git submodule update rtems_waf
>>> 
>>> ./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
>>> --buildset=buildset/default.ini
> 
> As Frank points put the kernel needs to be installed before this command is 
> run.
> 
> Chris
> 
>>> 
>>> leads to :
>>> 
>>> # project  configured on Tue Jan 17 17:46:09 2023 by
>>> # waf 2.0.19 (abi 20, python 20710f0 on linux2)
>>> # using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
>>> --rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
>>> #
>>> 
>>> Setting top to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd
>>> 
>>> Setting out to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd/build
>>> from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
>>> "/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
>>> 
>>> 
>>> Heinz
>> 

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

Re: Typo in rtems-libbsd/rtems_waf/rtems.py?

[Heinz Junkes]

^
../../freebsd/sys/sys/systm.h:600:39: note: in definition of macro 'msleep'
  _sleep((chan), &(mtx)->lock_object, (pri), (wmesg),  \
   ^~~

In file included from ../../freebsd/sys/fs/nfs/nfsport.h:47:0,
 from ../../freebsd/sys/fs/nfsclient/nfs_clstate.c:86:
../../freebsd/sys/fs/nfsclient/nfs_clstate.c: In function 'nfscl_cancelreqs':
../../freebsd/sys/fs/nfsclient/nfs_clstate.c:5033:22: error: 'PVFS' undeclared 
(first use in this function); did you mean 'PVM'?
   tsleep(&non_event, PVFS, "ndscls", hz);
  ^
../../freebsd/sys/sys/systm.h:625:24: note: in definition of macro 'tsleep'
  _sleep((chan), NULL, (pri), (wmesg), tick_sbt * (timo),  \
^~~
../../freebsd/sys/fs/nfsclient/nfs_clstate.c:5033:22: note: each undeclared 
identifier is reported only once for each function it appears in
   tsleep(&non_event, PVFS, "ndscls", hz);
  ^
../../freebsd/sys/sys/systm.h:625:24: note: in definition of macro 'tsleep'
  _sleep((chan), NULL, (pri), (wmesg), tick_sbt * (timo),  \
^~~

In file included from ../../freebsd/sys/fs/nfs/nfsport.h:47:0,
 from ../../freebsd/sys/fs/nfsclient/nfs_clrpcops.c:52:
../../freebsd/sys/fs/nfsclient/nfs_clrpcops.c: In function 'nfscl_doiods':
../../freebsd/sys/fs/nfsclient/nfs_clrpcops.c:5840:26: error: 'PVFS' undeclared 
(first use in this function); did you mean 'PVM'?
  tsleep(&tdrpc->tsk, PVFS, "clrpcio",
  ^
../../freebsd/sys/sys/systm.h:625:24: note: in definition of macro 'tsleep'
  _sleep((chan), NULL, (pri), (wmesg), tick_sbt * (timo),  \
^~~
../../freebsd/sys/fs/nfsclient/nfs_clrpcops.c:5840:26: note: each undeclared 
identifier is reported only once for each function it appears in
  tsleep(&tdrpc->tsk, PVFS, "clrpcio",
  ^
../../freebsd/sys/sys/systm.h:625:24: note: in definition of macro 'tsleep'
  _sleep((chan), NULL, (pri), (wmesg), tick_sbt * (timo),  \
^~~

Waf: Leaving directory 
`/home/rtems/MVME6100_5_LIBBSD_INST/rtems-libbsd/build/powerpc-rtems5-beatnik-default'
Build failed
 -> task in 'objs01' failed with exit status 1 (run with -v to display more 
information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more 
information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more 
information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more 
information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more 
information)


Heinz

> On 18. Jan 2023, at 08:03, Sebastian Huber 
>  wrote:
> 
> On 17.01.23 21:13, Heinz Junkes wrote:
>> rtems@rtems-dev:~/MVME6100_6_INST/kernel$ ./waf bsp_defaults 
>> --rtems-bsps=powerpc/beatnik > config.ini
> 
> If you just want to build a BSP with default values, you should simply use:
> 
> [powerpc/beatnik]
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

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

Re: Building RTEMS 6 toolchain on a Mac

[Heinz Junkes]

I'm going to slip into the thread here.

I could successfully build rtems6 for arm on the M1 Mac yesterday evening.

git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb
cd rtems
../source-builder/sb-set-builder --jobs=4 --prefix=${RTEMS_ROOT} 
${RTEMS_VERSION}/rtems-arm


One problem I encountered was the building of the qemu (devel/qemu) on the Mac 
(Monterey, 12.3.1 ):

RTEMS Source Builder - Set Builder, 6 (49e3dac17765)
 Command Line: ../source-builder/sb-set-builder --jobs=4 
--prefix=/Users/heinz/VE/ARM_WORK/rtems/6 devel/qemu
 Python: 3.8.5 (default, Sep  4 2020, 02:22:02) [Clang 10.0.0 ]
Build Set: devel/qemu
Build Set: devel/autotools-internal.bset
config: devel/autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-apple-darwin21.4.0-1
….
/bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/cc -O2 -pipe 
-fbracket-depth=1024 
-I/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/include
  -g -O2  -no-undefined  -liconv ../intl/libintl.la -liconv  -Wl,-framework 
-Wl,CoreFoundation  -lunistring  -Wl,-framework -Wl,CoreFoundation -release 
0.18.3  -lcroco-0.6 
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
 -lglib-2.0 
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
 -lintl -liconv -lc 
-R/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
 
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
 -lglib-2.0 
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
 -lintl -liconv -lc 
-R/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
 -lxml2 -liconv -liconv -liconv -lncurses 
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
 -o libgettextlib.la -rpath /Users/heinz/VE/ARM_WORK/rtems/6/lib copy-acl.lo 
set-acl.lo allocator.lo areadlink.lo argmatch.lo gl_array_list.lo backupfile.lo 
addext.lo basename.lo binary-io.lo c-ctype.lo c-strcasecmp.lo c-strncasecmp.lo 
c-strcasestr.lo c-strstr.lo careadlinkat.lo classpath.lo clean-temp.lo 
cloexec.lo closeout.lo concat-filename.lo copy-file.lo csharpcomp.lo 
csharpexec.lo error-progname.lo execute.lo exitfail.lo fatal-signal.lo 
fd-hook.lo fd-ostream.lo fd-safer-flag.lo dup-safer-flag.lo file-ostream.lo 
findprog.lo fstrcmp.lo full-write.lo fwriteerror.lo gcd.lo  hash.lo 
html-ostream.lo html-styled-ostream.lo  javacomp.lo javaexec.lo javaversion.lo 
gl_linkedhash_list.lo gl_list.lo localcharset.lo localename.lo glthread/lock.lo 
malloca.lo mbchar.lo mbiter.lo mbslen.lo mbsstr.lo mbswidth.lo mbuiter.lo 
ostream.lo pipe-filter-ii.lo pipe-filter-aux.lo pipe2.lo pipe2-safer.lo 
progname.lo propername.lo acl-errno-valid.lo file-has-acl.lo qcopy-acl.lo 
qset-acl.lo quotearg.lo safe-read.lo safe-write.lo sh-quote.lo sig-handler.lo 
spawn-pipe.lo striconv.lo striconveh.lo striconveha.lo strnlen1.lo 
styled-ostream.lo tempname.lo term-ostream.lo term-styled-ostream.lo  
glthread/threadlib.lo glthread/tls.lo tmpdir.lo trim.lo  unilbrk/lbrktables.lo  
 unilbrk/ulc-common.lo   unistd.lo dup-safer.lo fd-safer.lo pipe-safer.lo   
   wait-process.lo wctype-h.lo xmalloc.lo xstrdup.lo xconcat-filename.lo 
xerror.lo gl_xlist.lo xmalloca.lo xreadlink.lo xsetenv.lo xsize.lo xstriconv.lo 
xstriconveh.lo xvasprintf.lo xasprintf.lo acl_entries.lo asnprintf.lo 
canonicalize-lgpl.lo error.lo fnmatch.lo getopt.lo getopt1.lo lstat.lo 
obstack.lo open.lo printf-args.lo printf-parse.lo rawmemchr.lo readlink.lo 
secure_getenv.lo stat.lo strchrnul.lo strerror.lo strerror-override.lo 
strstr.lo vasnprintf.lo wcwidth.lo
libtool: link: warning: library 
`/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib/libglib-2.0.la'
 was moved.
grep: /Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la: No such file or directory
/usr/local/bin/gsed: can't read 
/Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la: No such file or directory
libtool: link: `/Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la' is not a valid 
libtool archive
make[4]: *** [libgettextlib.la] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
shell cmd failed: /bin/sh -ex  
/Users/heinz/VE/rsb/rtems/build/gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1/do-build
error: building gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1
  See error report: rsb-report-gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1.txt
Build Set: Time 0:04:14.522148

Gruss Heinz



--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun.

Re: Building RTEMS 6 toolchain on a Mac

[Heinz Junkes]

Hello Sebastian,
unfortunately I could not build rtems7 on the Mac (as I can for rtems6):

Cloning into 'rsb'...
RTEMS Source Builder - Set Builder, 6 (376bf3247498)
Build Set: 7/rtems-arm
config: devel/dtc-1.6.1-1.cfg
package: dtc-1.6.1-x86_64-apple-darwin21.4.0-1
Creating source directory: sources
download: https://www.kernel.org/pub/software/utils/dtc/dtc-1.6.1.tar.gz -> 
sources/dtc-1.6.1.tar.gz
 redirect: 
https://mirrors.edge.kernel.org/pub/software/utils/dtc/dtc-1.6.1.tar.gz
^Mdownloading: sources/dtc-1.6.1.tar.gz - 0.0 bytes of 199.0kB (0%) 
^Mdownloading: sources/dtc-1.6.1.tar.gz - 199.0kB of 199.0kB (100%)
^Mbuilding: dtc-1.6.1-x86_64-apple-darwin21.4.0-1
sizes: dtc-1.6.1-x86_64-apple-darwin21.4.0-1: 4.504MB (installed: 814.811KB)
cleaning: dtc-1.6.1-x86_64-apple-darwin21.4.0-1
reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-x86_64-apple-darwin21.4.0-1.txt
reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-x86_64-apple-darwin21.4.0-1.xml
config: devel/expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-apple-darwin21.4.0-1
download: 
https://github.com/libexpat/libexpat/releases/download/R_2_1_0/expat-2.1.0.tar.gz
 -> sources/expat-2.1.0.tar.gz
…
ownloading: sources/gmp-6.2.1.tar.bz2 - 1.8MB of 2.4MB (74%) ^Mdownloading: 
sources/gmp-6.2.
1.tar.bz2 - 2.0MB of 2.4MB (84%) ^Mdownloading: sources/gmp-6.2.1.tar.bz2 - 
2.2MB of 2.4MB (
95%) ^Mdownloading: sources/gmp-6.2.1.tar.bz2 - 2.4MB of 2.4MB (100%)
^Mbuilding: arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1
error: building 
arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1
Build FAILED
  See error report: 
rsb-report-arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4
.0-1.txt
error: building 
arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1
Build Set: Time 0:12:11.609355
Build FAILED

…

libtool: compile:  /usr/bin/cc -O2 -pipe -fbracket-depth=1024 
-I/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/7/rtems-arm/Users/heinz/VE/ARM_WORK/rtems/7/include
 -DHAVE_CONFIG_H -I. -I../../../gnu-mirror-gcc-b6e3390/gmp/mpn -I.. 
-D__GMP_WITHIN_GMP -I../../../gnu-mirror-gcc-b6e3390/gmp -DOPERATION_gcd_22 
-DNO_ASM -g -O2 -c gcd_22.c -o gcd_22.o
gcd_22.c:128:10: error: implicit declaration of function 'mpn_gcd_11' is 
invalid in C99 [-Werror,-Wimplicit-function-declaration]
  g.d0 = mpn_gcd_11 ((u0 << 1) + 1, (v0 << 1) + 1);
 ^
1 error generated.
make[4]: *** [gcd_22.lo] Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-gmp] Error 2
make: *** [all] Error 2
shell cmd failed: /bin/sh -ex  
/Users/heinz/VE/rsb/rtems/build/arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1/do-build
error: building 
arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1(base)

Gruss Heinz


> On 22. Apr 2022, at 14:06, Sebastian Huber 
>  wrote:
> 
> On 22/04/2022 08:55, Sebastian Huber wrote:
>>> Could GCC be upgraded to 11.2 or 12.0 which should be available very soon? 
>>> are the patches still needed?
>> It is still undecided which GCC version will be used for RTEMS 6. GCC 10 
>> will reach its end of life with the next release this year. GCC 12 would be 
>> brand new. We didn't use GCC 11 so far. I tend to use GCC 12.
> 
> I checked in some updates for the RSB. Could you please check if you can 
> build the RTEMS 7 tool chain which is based on GCC 12:
> 
> ../source-builder/sb-set-builder 7/rtems-arm
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

rtems_rpc_task_init, where?

[Heinz Junkes]

Hallo,

with the new network stack, rtems_rpc_task_init no longer exists.

What must/could be called/initialized instead?

Danke, Heinz


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

Re: Building RTEMS 6 toolchain on a Mac

[Heinz Junkes]

Hallo Sebastian,
maybe too late, but this is the result of RTEMS 7 rsb on my Mac:

 Command Line: ../source-builder/sb-set-builder --jobs=4 
--prefix=/Users/heinz/VE/ARM_WORK/rtems/7 7/rtems-arm
 Python: 3.8.5 (default, Sep  4 2020, 02:22:02) [Clang 10.0.0 ]
 
https://github.com/RTEMS/rtems-source-builder.git/origin/a53d2c94322ed4fe261ba0c99bfb66a6cbd1def1
...

  CXXunittests/tui-selftests.o
In file included from 
../../sourceware-mirror-binutils-gdb-36b1241/gdb/unittests/string_view-selftests.c:34:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/fstream:579:17:
 warning: The symbol ::fdopen refers to the system function. Use gnulib::fdopen 
instead. [-Wuser-defined-warnings]
  __file_ = fdopen(__fd, __mdstr);
^
../gnulib/import/stdio.h:826:1: note: from 'diagnose_if' attribute on 'fdopen':
_GL_CXXALIASWARN (fdopen);
^
../gnulib/import/stdio.h:461:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~
../gnulib/import/stdio.h:463:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~
../gnulib/import/stdio.h:468:5: note: expanded from macro '_GL_CXXALIASWARN_2'
_GL_WARN_ON_USE (func, \
^~~~
../gnulib/import/stdio.h:632:19: note: expanded from macro '_GL_WARN_ON_USE'
  __attribute__ ((__diagnose_if__ (1, message, "warning")))
  ^~
  CXXunittests/ui-file-selftests.o
  CXXunittests/unique_xmalloc_ptr_char.o
  CXXunittests/unpack-selftests.o
1 warning generated.
  CXXunittests/utils-selftests.o
  CXXunittests/vec-utils-selftests.o
  CXXunittests/xml-utils-selftests.o
  CXXuser-regs.o
  CXXutils.o
  CXXvalarith.o
  CXXvalops.o
  CXXvalprint.o
  CXXvalue.o
  CXXvarobj.o
  GENstamp-version
  GENxml-builtin.c
  CXXxml-support.o
  CXXxml-syscall.o
  CXXxml-tdesc.o
  GENinit.c
  CXXgdb.o
  CXXaarch32-tdep.o
  CXXada-exp.o
  CXXada-lang.o
  CXXada-tasks.o
  CXXada-typeprint.o
  CXXada-valprint.o
  CXXada-varobj.o
  CXXaddrmap.o
  CXXagent.o
  CXXalloc.o
  CXXannotate.o
  CXXarch-utils.o
  CXXarch/aarch32.o
  CXXarch/arm-get-next-pcs.o
  CXXarch/arm.o
  CXXarm-none-tdep.o
  CXXarm-pikeos-tdep.o
  CXXarm-tdep.o
  CXXasync-event.o
  CXXauto-load.o
  CXXauxv.o
  CXXax-gdb.o
  CXXax-general.o
  CXXbcache.o
  CXXbfd-target.o
  CXXblock.o
  CXXblockframe.o
  CXXbreak-catch-exec.o
  CXXbreak-catch-fork.o
  CXXbreak-catch-sig.o
  CXXbreak-catch-syscall.o
  CXXbreak-catch-throw.o
  CXXbreakpoint.o
  CXXbt-utils.o
  CXXbtrace.o
  CXXbuild-id.o
  CXXbuildsym-legacy.o
  CXXbuildsym.o
  CXXc-exp.o
  CXXc-lang.o
  CXXc-typeprint.o
  CXXc-valprint.o
  CXXc-varobj.o
  CXXcharset.o
  CXXcli-out.o
  CXXcli/cli-cmds.o
  CXXcli/cli-decode.o
  CXXcli/cli-dump.o
  CXXcli/cli-interp.o
  CXXcli/cli-logging.o
  CXXcli/cli-option.o
  CXXcli/cli-script.o
  CXXcli/cli-setshow.o
  CXXcli/cli-style.o
  CXXcli/cli-utils.o
  CXXcoff-pe-read.o
  CXXcoffread.o
  CXXcompile/compile-c-support.o
  CXXcompile/compile-c-symbols.o
  CXXcompile/compile-c-types.o
  CXXcompile/compile-cplus-symbols.o
  CXXcompile/compile-cplus-types.o
  CXXcompile/compile-loc2c.o
  CXXcompile/compile-object-load.o
  CXXcompile/compile-object-run.o
  CXXcompile/compile.o
  CXXcomplaints.o
  CXXcompleter.o
  CXXcopying.o
  CXXcorefile.o
  CXXcorelow.o
  CXXcp-abi.o
  CXXcp-name-parser.o
  CXXcp-namespace.o
  CXXcp-support.o
  CXXcp-valprint.o
  CXXctfread.o
  CXXd-exp.o
  CXXf-exp.o
  CXXm2-exp.o
  CXXgo-exp.o
In file included from 
../../sourceware-mirror-binutils-gdb-36b1241/gdb/m2-exp.y:42:
In file included from 
../../sourceware-mirror-binutils-gdb-36b1241/gdb/language.h:26:
In file included from 
../../sourceware-mirror-binutils-gdb-36b1241/gdb/symtab.h:39:
../../sourceware-mirror-binutils-gdb-36b1241/gdb/split-name.h:34:3: error: 
expected identifier
  DOT,
  ^
m2-exp.c:163:13: note: expanded from macro 'DOT'
#define DOT 302
^
In file included from 
../../sourceware-mirror-binutils-gdb-36b1241/gdb/m2-exp.y:42:
In file included from 
../../sourceware-mirror-binutils-gdb-36b1241/gdb/language.h:26:
../../sourceware-mirror-binutils-gdb-36b1241/gdb/symtab.h:306:23: error: 
expected unqualified-id
style = split_style::DOT;
 ^
m2-exp.c:163:13: note: expanded from macro 'DOT'
#define DOT 302
^
2 errors generated.
make[2]: *** [m2-exp.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]

Re: [PATCH] tests: Add header for RTEMS test printer

[Heinz Junkes]

Leads to problems compiling legacy-stack:


Waf: Entering directory 
`/home/rtems/MVME6100_6_legacy_INST/rsb/rtems/build/rtems-net-legacy-3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2-powerpc-rtems-1/rtems-net-legacy-3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2/build/powerpc-rtems6-beatnik'
[1/1] Compiling include/machine/rtems-net-legacy.h.in
[  2/223] Compiling bsps/powerpc/beatnik/net/porting/if_xxx_rtems.c
[  3/223] Compiling bsps/powerpc/beatnik/net/if_em/if_em_rtems.c
[  4/223] Compiling bsps/powerpc/beatnik/net/if_em/if_em.c
[  5/223] Compiling bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
[  6/223] Compiling bsps/powerpc/beatnik/net/if_gfe/if_gfe_rtems.c
[  7/223] Compiling bsps/powerpc/beatnik/net/if_em/if_em_hw.c
[  8/223] Compiling bsps/powerpc/beatnik/net/support/early_link_status.c
[  9/223] Compiling bsps/powerpc/beatnik/net/if_gfe/if_gfe.c
[ 10/223] Compiling bsps/powerpc/beatnik/net/support/bsp_attach.c
[ 11/223] Compiling librpc/src/xdr/xdr_reference.c
[ 12/223] Compiling netinet/if_ether.c
[ 13/223] Compiling rtems/rtems_syscall.c
[ 14/223] Compiling rtems/rtems_dhcp.c
[ 15/223] Compiling librpc/src/xdr/xdr_rec.c
[ 16/223] Compiling librpc/src/xdr/xdr_mem.c
[ 17/223] Compiling net/slcompress.c
[ 18/223] Compiling librpc/src/xdr/xdr_float.c
[ 19/223] Compiling net/rtsock.c
[ 20/223] Compiling net/route.c
[ 21/223] Compiling libtest/testrun.c
[ 22/223] Compiling libc/res_stubs.c
[ 23/223] Compiling bsps/shared/net/if_dc.c
[ 24/223] Compiling libc/res_mkquery.c
[ 25/223] Compiling librpc/src/rpc/bindresvport.c
[ 26/223] Compiling libc/gethostbyht.c
[ 27/223] Compiling net/if_ethersubr.c
[ 28/223] Compiling librpc/src/rpc/pmap_prot.c
[ 29/223] Compiling librpc/src/rpc/pmap_prot2.c
[ 30/223] Compiling net/if.c
[ 31/223] Compiling librpc/src/rpc/pmap_rmt.c
[ 32/223] Compiling librpc/src/rpc/rpc_callmsg.c
[ 33/223] Compiling rtems/rtems_showmbuf.c
[ 34/223] Compiling librpc/src/rpc/pmap_getport.c
[ 35/223] Compiling rtems/rtems_showroute.c
[ 36/223] Compiling bsps/shared/net/sonic.c
[ 37/223] Compiling librpc/src/rpc/pmap_clnt.c
[ 38/223] Compiling rtems/rtems-kernel-program.c
[ 39/223] Compiling rtems/rtems_showipstat.c
[ 40/223] Compiling libtest/testwrappers.c
[ 41/223] Compiling libtest/testbusy.c
[ 42/223] Compiling librpc/src/rpc/getrpcport.c
[ 43/223] Compiling libc/res_update.c
[ 44/223] Compiling libc/send.c
[ 45/223] Compiling librpc/src/rpc/clnt_tcp.c
[ 46/223] Compiling bsps/shared/net/i82586.c
[ 47/223] Compiling libc/res_mkupdate.c
../../libtest/testwrappers.c: In function '__wrap_printf':
../../libtest/testwrappers.c:24:3: error: unknown type name 'va_list'
   24 |   va_list ap;
  |   ^~~
../../libtest/testwrappers.c:14:1: note: 'va_list' is defined in header 
''; did you forget to '#include '?
   13 | #include 
  +++ |+#include 
   14 |
../../libtest/testwrappers.c:28:6: error: 'rtems_test_printer' undeclared 
(first use in this function); did you mean 'rtems_test_run'?
   28 | &rtems_test_printer,
  |  ^~
  |  rtems_test_run
../../libtest/testwrappers.c:28:6: note: each undeclared identifier is reported 
only once for each function it appears in

Waf: Leaving directory 
`/home/rtems/MVME6100_6_legacy_INST/rsb/rtems/build/rtems-net-legacy-3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2-powerpc-rtems-1/rtems-net-legacy-3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2/build/powerpc-rtems6-beatnik'
Build failed
 -> task in 'netobjs' failed with exit status 1 (run with -v to display more 
information)
shell cmd failed: /bin/sh -ex  
/home/rtems/MVME6100_6_legacy_INST/rsb/rtems/build/rtems-net-legacy-3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2-powerpc-rtems-1/do-build
error: building 
rtems-net-legacy-3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2-powerpc-rtems-1

> On 25. Sep 2023, at 08:40, Chris Johns  wrote:
>
> Looks good
>
> Thanks
> Chris
>
> On 22/9/2023 10:40 pm, Sebastian Huber wrote:
>> The  header file is required for every RTEMS test
>> program.  Move the RTEMS test printer support to a dedicated header file
>> .  This removes an unnecessary dependency to the
>> RTEMS printer support in .
>>
>> Tests using the RTEMS Testing Framework no longer depend on the
>> .
>> ---
>> cpukit/include/rtems/test-info.h  | 18 +
>> cpukit/include/rtems/test-printer.h   | 69 +++
>> cpukit/libtest/testbeginend.c |  1 +
>> cpukit/libtest/testwrappers.c |  2 +-
>> spec/build/cpukit/librtemstest.yml|  1 +
>> testsuites/benchmarks/linpack/linpack-pc.c|  2 +-
>> testsuites/benchmarks/whetstone/whetstone.c   |  2 +-
>> testsuites/fstests/tftpfs/init.c  |  1 +
>> testsuites/libtests/dl01/dl01-o1.c|  2 +-
>> testsuites/libtests/dl02/dl02-o1.c|  2 +-
>> testsuites/libtests/dl02/dl02-o2.c|  2 +-
>> testsuites/libtests/dl05/dl05-o5.cc   |  2 +-
>> testsuites/libtests/dl06/dl06-o1.c|  2 +-
>> testsuites/libtests/dl06/dl06-o2.c

Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13

[Heinz Junkes]

HI,
I can follow Cedric's reasoning. Even if I was the initiator of this discussion.

I use RTEMS in my lectures/exercises, among other things, and have always been 
able to give the students
freedom which laptops with which OS they wanted to use. And there are many of 
them with used
older laptops. Intel Macs, for example.

But you can also use a VM with Linux on all these systems.

It might then be okay to communicate openly that there will be no more support 
for Macs in the future.
Best regards
Heinz

> On 8. Dec 2023, at 14:19, Cedric Berger  wrote:
>
> Oh, so this is an mac intel issue then.
> I'm gonna make the suggestion do just remove support for Intel Macs for RTEMS 
> 6.0.
> I mean, what is the number of developpers who:
> 1) Will release a product based on RTEMS 6 (out in 2024 hopefully)
> 2) Have enough money to buy an Intel MacBook
> 3) Do not have enough money to upgrade 4 years later, especially with the 3x 
> compile speed improvements the M1/2/3 brings?
> My guess is zero. And there is always the possiblity to use a free Ubuntu MV 
> on these obsolete macs.
> I know the senior RTEMS developpers are very very busy, so I (selfishly) 
> would prefer if they use their time for something more productive :)
> Here at Precidata for example, we've put our product developpement with RTEMS 
> on hold for the past 5 months, because of bug #4923 (STM32h7 FPU corrupted on 
> return from IRQ).
> So may I humbly suggest to forget obsolete developpement platforms and focus 
> energy on new targets?
> Thanks for your answers and all your work.
> Cedric
>



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems-6.1-rc2 on Mac OSX Ventura 13.6.1 (Intel Core i5)

[Heinz Junkes]

Hi,

I tried to build rc2 on OS-X (Ventura Intel) for powerpc and I get the 
following error:

RTEMS Tools Project - Source Builder Error Report
 Build: error: building 
powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-x86_64-apple-darwin22.6.0-1
 Command Line: ../source-builder/sb-set-builder 
--prefix=/Volumes/RTEMS_DEV/RTEMS6_RC2/6.1-rc2 6/rtems-powerpc
 Python: 3.9.12 (main, Apr  5 2022, 01:53:17) [Clang 12.0.0 ]
 RSB: not a valid repo
 Darwin h.rz-berlin.mpg.de 22.6.0 Darwin Kernel Version 22.6.0: Wed Oct  4 
21:25:26 PDT 2023; root:xnu-8796.141.3.701.17~4/RELEASE_X86_64 x86_64
Tail of the build log:
Adding multilib support to Makefile in ../../../../../../gcc-13.2.0/libgcc
with_multisubdir=me6500/m64/vrsave
make[2]: Entering directory 
`/Volumes/RTEMS_DEV/RTEMS6_RC2/rtems-source-builder-6.1-rc2/rtems/build/powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-x86_64-apple-darwin22.6.0-1/build/powerpc-rtems6/libgcc'
# If this is the top-level multilib, build all the other
ln -s ../../../gcc-13.2.0/libgcc/enable-execute-stack-empty.c 
enable-execute-stack.c
ln -s ../../../gcc-13.2.0/libgcc/unwind-generic.h unwind.h
ln -s ../../../gcc-13.2.0/libgcc/config/no-unwind.h md-unwind-support.h
ln -s ../../../gcc-13.2.0/libgcc/config/rs6000/sfp-machine.h sfp-machine.h
# multilibs.
...
/Volumes/RTEMS_DEV/RTEMS6_RC2/rtems-source-builder-6.1-rc2/rtems/build/powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-x86_64-apple-darwin22.6.0-1/build/./gcc/xgcc
 
-B/Volumes/RTEMS_DEV/RTEMS6_RC2/rtems-source-builder-6.1-rc2/rtems/build/powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-x86_64-apple-darwin22.6.0-1/build/./gcc/
 -nostdinc 
-B/Volumes/RTEMS_DEV/RTEMS6_RC2/rtems-source-builder-6.1-rc2/rtems/build/powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-x86_64-apple-darwin22.6.0-1/build/powerpc-rtems6/newlib/
 -isystem 
/Volumes/RTEMS_DEV/RTEMS6_RC2/rtems-source-builder-6.1-rc2/rtems/build/powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-x86_64-apple-darwin22.6.0-1/build/powerpc-rtems6/newlib/targ-include
 -isystem 
/Volumes/RTEMS_DEV/RTEMS6_RC2/rtems-source-builder-6.1-rc2/rtems/build/powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-x86_64-apple-darwin22.6.0-1/gcc-13.2.0/newlib/libc/include
 -B/Volumes/RTEMS_DEV/RTEMS6_RC2/6.1-rc2/powerpc-rtems6/bin/ 
-B/Volumes/RTEMS_DEV/RTEMS6_RC2/6.1-rc2/powerpc-rtems6/lib/ -isystem 
/Volumes/RTEMS_DEV/RTEMS6_RC2/6.1-rc2/powerpc-rtems6/include -isystem 
/Volumes/RTEMS_DEV/RTEMS6_RC2/6.1-rc2/powerpc-rtems6/sys-include-g -O2 -O2 
-I../../../gcc-13.2.0/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector 
-Dinhibit_libc  -I. -I. -I../.././gcc -I../../../gcc-13.2.0/libgcc 
-I../../../gcc-13.2.0/libgcc/. -I../../../gcc-13.2.0/libgcc/../gcc 
-I../../../gcc-13.2.0/libgcc/../include  -DHAVE_CC_TLS   -o _gcov_merge_add.o 
-MT _gcov_merge_add.o -MD -MP -MF _gcov_merge_add.dep -DL_gcov_merge_add -c 
../../../gcc-13.2.0/libgcc/libgcov-merge.c
../../../gcc-13.2.0/libgcc/emutls.c: In function '__emutls_get_address':
../../../gcc-13.2.0/libgcc/emutls.c:172:13: warning: implicit declaration of 
function 'calloc' [-Wimplicit-function-declaration]
  172 |   arr = calloc (size + 1, sizeof (void *));
  | ^~
../../../gcc-13.2.0/libgcc/emutls.c:32:1: note: include '' or provide 
a declaration of 'calloc'
   31 | #include "gthr.h"
  +++ |+#include 
   32 |
../../../gcc-13.2.0/libgcc/emutls.c:172:13: warning: incompatible implicit 
declaration of built-in function 'calloc' [-Wbuiltin-declaration-mismatch]
  172 |   arr = calloc (size + 1, sizeof (void *));
  | ^~
../../../gcc-13.2.0/libgcc/emutls.c:172:13: note: include '' or 
provide a declaration of 'calloc'
../../../gcc-13.2.0/libgcc/emutls.c:184:13: warning: implicit declaration of 
function 'realloc' [-Wimplicit-function-declaration]
  184 |   arr = realloc (arr, (size + 1) * sizeof (void *));
  | ^~~
../../../gcc-13.2.0/libgcc/emutls.c:184:13: note: include '' or 
provide a declaration of 'realloc'
../../../gcc-13.2.0/libgcc/emutls.c:184:13: warning: incompatible implicit 
declaration of built-in function 'realloc' [-Wbuiltin-declaration-mismatch]
../../../gcc-13.2.0/libgcc/emutls.c:184:13: note: include '' or 
provide a declaration of ‘realloc'

…

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

rtems-6.1-rc2 on Mac OSX Sonoma 14.4 (Apple M2) failed

[Heinz Junkes]

Hi,

I am trying to install rc2 on sonoma 14.4 (Apple M2) and unfortunately get

error: config error: gdb-common-1.cfg:146: "gdb: python: library file not 
found: libpython3.11.*, please install”

It looks like the error described in ticket #4631.

Heinz


(base) junkes@Zarquon rtems % ../source-builder/sb-set-builder 
--prefix=/Volumes/Epics/6_1_RC2/6.1-rc2 6/rtems-powerpc
RTEMS Source Builder - Set Builder, 6.1-rc2
Build Set: 6/rtems-powerpc
Build Set: tools/rtems-default-tools.bset
config: devel/dtc-1.6.1-1.cfg
package: dtc-1.6.1-arm64-apple-darwin23.4.0-1
building: dtc-1.6.1-arm64-apple-darwin23.4.0-1
sizes: dtc-1.6.1-arm64-apple-darwin23.4.0-1: 3.057MB (installed: 704.209KB)
cleaning: dtc-1.6.1-arm64-apple-darwin23.4.0-1
reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-arm64-apple-darwin23.4.0-1.txt
reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-arm64-apple-darwin23.4.0-1.xml
config: devel/expat-2.5.0-1.cfg
package: expat-2.5.0-arm64-apple-darwin23.4.0-1
download: 
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/expat-2.5.0.tar.gz
 -> sources/expat-2.5.0.tar.gz
downloading: sources/expat-2.5.0.tar.gz - 702.4kB of 702.4kB (100%)  building: 
expat-2.5.0-arm64-apple-darwin23.4.0-1
sizes: expat-2.5.0-arm64-apple-darwin23.4.0-1: 7.704MB (installed: 905.753KB)
cleaning: expat-2.5.0-arm64-apple-darwin23.4.0-1
reporting: devel/expat-2.5.0-1.cfg -> expat-2.5.0-arm64-apple-darwin23.4.0-1.txt
reporting: devel/expat-2.5.0-1.cfg -> expat-2.5.0-arm64-apple-darwin23.4.0-1.xml
config: devel/gmp-6.3.0.cfg
package: gmp-6.3.0-arm64-apple-darwin23.4.0-1
download: 
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/gmp-6.3.0.tar.bz2 
-> sources/gmp-6.3.0.tar.bz2
downloading: sources/gmp-6.3.0.tar.bz2 - 2.5MB of 2.5MB (100%)building: 
gmp-6.3.0-arm64-apple-darwin23.4.0-1
sizes: gmp-6.3.0-arm64-apple-darwin23.4.0-1: 22.973MB (installed: 1.402MB)
cleaning: gmp-6.3.0-arm64-apple-darwin23.4.0-1
reporting: devel/gmp-6.3.0.cfg -> gmp-6.3.0-arm64-apple-darwin23.4.0-1.txt
reporting: devel/gmp-6.3.0.cfg -> gmp-6.3.0-arm64-apple-darwin23.4.0-1.xml
Build Set: textproc/gsed-internal.bset
config: textproc/gsed.cfg
package: gsed-4.9-arm64-apple-darwin23.4.0-1
download: 
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/sed-4.9.tar.gz -> 
sources/sed-4.9.tar.gz
downloading: sources/sed-4.9.tar.gz - 2.2MB of 2.2MB (100%)building: 
gsed-4.9-arm64-apple-darwin23.4.0-1
sizes: gsed-4.9-arm64-apple-darwin23.4.0-1: 19.157MB (installed: 0.000B)
cleaning: gsed-4.9-arm64-apple-darwin23.4.0-1
cleaning: gsed-4.9-arm64-apple-darwin23.4.0-1
Build Set: Time 0:00:37.403237
Build Set: print/texinfo-internal.bset
config: print/texinfo.cfg
package: texinfo-7.0.3-arm64-apple-darwin23.4.0-1
download: 
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/texinfo-7.0.3.tar.gz
 -> sources/texinfo-7.0.3.tar.gz
download: 
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/texinfo-7.0.3.tar.gz:
 error: HTTP Error 404: Not Found
download: https://ftp.gnu.org/gnu/texinfo/texinfo-7.0.3.tar.gz -> 
sources/texinfo-7.0.3.tar.gz
downloading: sources/texinfo-7.0.3.tar.gz - 10.3MB of 10.3MB (100%)   building: 
texinfo-7.0.3-arm64-apple-darwin23.4.0-1
sizes: texinfo-7.0.3-arm64-apple-darwin23.4.0-1: 88.975MB (installed: 0.000B)
cleaning: texinfo-7.0.3-arm64-apple-darwin23.4.0-1
cleaning: texinfo-7.0.3-arm64-apple-darwin23.4.0-1
Build Set: Time 0:00:39.965456
config: tools/rtems-gdb-13.2.cfg
error: config error: gdb-common-1.cfg:146: "gdb: python: library file not 
found: libpython3.11.*, please install"
Build FAILED
Build Set: Time 0:02:10.561549
error: config error: gdb-common-1.cfg:146: "gdb: python: library file not 
found: libpython3.11.*, please install"
Build Set: Time 0:02:10.563376
Build FAILED

--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: https://zoom.fhi.berlin/junkes
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
--



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-6.1-rc2 on Mac OSX Sonoma 14.4 (Apple M2) failed -> fixed

[Heinz Junkes]

Hi
After updating Xcode and OSX to Sonoma 14.4 the Python libs 'disappeared’ ?
Upgrade/update python on homebrew and brew link python3 fixed it.
Heinz

> On 11. Mar 2024, at 16:27, Heinz Junkes  wrote:
>
> Hi,
>
> I am trying to install rc2 on sonoma 14.4 (Apple M2) and unfortunately get
>
> error: config error: gdb-common-1.cfg:146: "gdb: python: library file not 
> found: libpython3.11.*, please install”
>
> It looks like the error described in ticket #4631.
>
> Heinz
>
>
> (base) junkes@Zarquon rtems % ../source-builder/sb-set-builder 
> --prefix=/Volumes/Epics/6_1_RC2/6.1-rc2 6/rtems-powerpc
> RTEMS Source Builder - Set Builder, 6.1-rc2
> Build Set: 6/rtems-powerpc
> Build Set: tools/rtems-default-tools.bset
> config: devel/dtc-1.6.1-1.cfg
> package: dtc-1.6.1-arm64-apple-darwin23.4.0-1
> building: dtc-1.6.1-arm64-apple-darwin23.4.0-1
> sizes: dtc-1.6.1-arm64-apple-darwin23.4.0-1: 3.057MB (installed: 704.209KB)
> cleaning: dtc-1.6.1-arm64-apple-darwin23.4.0-1
> reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-arm64-apple-darwin23.4.0-1.txt
> reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-arm64-apple-darwin23.4.0-1.xml
> config: devel/expat-2.5.0-1.cfg
> package: expat-2.5.0-arm64-apple-darwin23.4.0-1
> download: 
> https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/expat-2.5.0.tar.gz
>  -> sources/expat-2.5.0.tar.gz
> downloading: sources/expat-2.5.0.tar.gz - 702.4kB of 702.4kB (100%)  
> building: expat-2.5.0-arm64-apple-darwin23.4.0-1
> sizes: expat-2.5.0-arm64-apple-darwin23.4.0-1: 7.704MB (installed: 905.753KB)
> cleaning: expat-2.5.0-arm64-apple-darwin23.4.0-1
> reporting: devel/expat-2.5.0-1.cfg -> 
> expat-2.5.0-arm64-apple-darwin23.4.0-1.txt
> reporting: devel/expat-2.5.0-1.cfg -> 
> expat-2.5.0-arm64-apple-darwin23.4.0-1.xml
> config: devel/gmp-6.3.0.cfg
> package: gmp-6.3.0-arm64-apple-darwin23.4.0-1
> download: 
> https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/gmp-6.3.0.tar.bz2
>  -> sources/gmp-6.3.0.tar.bz2
> downloading: sources/gmp-6.3.0.tar.bz2 - 2.5MB of 2.5MB (100%)building: 
> gmp-6.3.0-arm64-apple-darwin23.4.0-1
> sizes: gmp-6.3.0-arm64-apple-darwin23.4.0-1: 22.973MB (installed: 1.402MB)
> cleaning: gmp-6.3.0-arm64-apple-darwin23.4.0-1
> reporting: devel/gmp-6.3.0.cfg -> gmp-6.3.0-arm64-apple-darwin23.4.0-1.txt
> reporting: devel/gmp-6.3.0.cfg -> gmp-6.3.0-arm64-apple-darwin23.4.0-1.xml
> Build Set: textproc/gsed-internal.bset
> config: textproc/gsed.cfg
> package: gsed-4.9-arm64-apple-darwin23.4.0-1
> download: 
> https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/sed-4.9.tar.gz 
> -> sources/sed-4.9.tar.gz
> downloading: sources/sed-4.9.tar.gz - 2.2MB of 2.2MB (100%)building: 
> gsed-4.9-arm64-apple-darwin23.4.0-1
> sizes: gsed-4.9-arm64-apple-darwin23.4.0-1: 19.157MB (installed: 0.000B)
> cleaning: gsed-4.9-arm64-apple-darwin23.4.0-1
> cleaning: gsed-4.9-arm64-apple-darwin23.4.0-1
> Build Set: Time 0:00:37.403237
> Build Set: print/texinfo-internal.bset
> config: print/texinfo.cfg
> package: texinfo-7.0.3-arm64-apple-darwin23.4.0-1
> download: 
> https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/texinfo-7.0.3.tar.gz
>  -> sources/texinfo-7.0.3.tar.gz
> download: 
> https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc2/sources/texinfo-7.0.3.tar.gz:
>  error: HTTP Error 404: Not Found
> download: https://ftp.gnu.org/gnu/texinfo/texinfo-7.0.3.tar.gz -> 
> sources/texinfo-7.0.3.tar.gz
> downloading: sources/texinfo-7.0.3.tar.gz - 10.3MB of 10.3MB (100%)   
> building: texinfo-7.0.3-arm64-apple-darwin23.4.0-1
> sizes: texinfo-7.0.3-arm64-apple-darwin23.4.0-1: 88.975MB (installed: 0.000B)
> cleaning: texinfo-7.0.3-arm64-apple-darwin23.4.0-1
> cleaning: texinfo-7.0.3-arm64-apple-darwin23.4.0-1
> Build Set: Time 0:00:39.965456
> config: tools/rtems-gdb-13.2.cfg
> error: config error: gdb-common-1.cfg:146: "gdb: python: library file not 
> found: libpython3.11.*, please install"
> Build FAILED
> Build Set: Time 0:02:10.561549
> error: config error: gdb-common-1.cfg:146: "gdb: python: library file not 
> found: libpython3.11.*, please install"
> Build Set: Time 0:02:10.563376
> Build FAILED
>
> --
> Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
> Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
> Faradayweg 4-6| VC: https://zoom.fhi.berlin/junkes
> D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
> --
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel




smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-6.1-rc2 on Mac OSX Sonoma 14.4 (Apple M2) failed -> fixed

[Heinz Junkes]

Hello Chris,

thanks for your mail. I have now installed the python as you described.

The source-builder process runs quite well.

Unfortunately, the gcc-13.2.0-newlib for powerpc cannot be built:

(py3.12) junkes@zarquon rtems % cat 
rsb-report-powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-arm64-apple-darwin23.4.0-1.txt
RTEMS Tools Project - Source Builder Error Report
 Build: error: building 
powerpc-rtems6-gcc-13.2.0-newlib-3cacedb-arm64-apple-darwin23.4.0-1
 Command Line: ../source-builder/sb-set-builder 
--prefix=/Volumes/Epics/6_1_RC2/6.1-rc2 6/rtems-powerpc
 Python: 3.12.2 (v3.12.2:6abddd9f6a, Feb  6 2024, 17:02:06) [Clang 13.0.0 
(clang-1300.0.29.30)]
 RSB: not a valid repo
 Darwin zarquon.rz-berlin.mpg.de 23.4.0 Darwin Kernel Version 23.4.0: Wed Feb 
21 21:45:49 PST 2024; root:xnu-10063.101.15~2/RELEASE_ARM64_T6020 arm64
Tail of the build log:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/vector:321:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_integral.h:32:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/locale:202:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:797:5:
 error: expected expression
return std::use_facet >(__loc).is(ctype_base::space, __c);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:798:2:
 error: expected ';' at end of declaration
}
 ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:803:21:
 error: too many arguments provided to function-like macro invocation
isprint(_CharT __c, const locale& __loc)
^
../../gcc-13.2.0/gcc/../include/safe-ctype.h:136:9: note: macro 'isprint' 
defined here
#define isprint(c) do_not_use_isprint_with_safe_ctype
^
In file included from ../../gcc-13.2.0/gcc/cp/module.cc:212:
In file included from ../../gcc-13.2.0/gcc/system.h:233:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/vector:321:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_integral.h:32:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/locale:202:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:803:1:
 error: declaration conflicts with target of using declaration already in scope
isprint(_CharT __c, const locale& __loc)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_ctype.h:255:1:
 note: target of using declaration
isprint(int _c)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cctype:119:9:
 note: using declaration
using ::isprint _LIBCPP_USING_IF_EXISTS;
^
In file included from ../../gcc-13.2.0/gcc/cp/module.cc:212:
In file included from ../../gcc-13.2.0/gcc/system.h:233:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/vector:321:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_integral.h:32:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/locale:202:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:805:5:
 error: expected expression
return std::use_facet >(__loc).is(ctype_base::print, __c);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:806:2:
 error: expected ';' at end of declaration
}
 ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/M

Certificate of the documentation page expired yesterday

[Heinz Junkes]

Common Name (CN)
docs.rtems.org
Organisation (O)

Organisational Unit (OU)

Issued By
Common Name (CN)
R3
Organisation (O)
Let's Encrypt
Organisational Unit (OU)

Validity Period
Issued On
Friday, 12 January 2024 at 20:02:57
Expires On
Thursday, 11 April 2024 at 21:02:56
SHA-256 Fingerprints
Certificate
9f6e41915a88f37a44627f92e459202504780eeab66109bfb4af1aa0f808ccc7
Public key
8f203f1219335bee3b05d2a42e0e670e551cf7f69159463415a099580d8305fb

Heinz


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

[Heinz Junkes]

Hi,
unfortunately I cannot activate the cgem0 network interface with RTEMS 6 
(libbsd 6-freebsd-12)
on a xilinx_zynq_zybo_z7 board :

cgem0: flagsˆ43 metric 0 mtu 1500
d   options€008
e   ether 92:c2:88:7d:f4:79
inet6 fe80::90c2:88ff:fe7d:f479%cgem0 prefixlen 64 scopeid 0x1
b   inet 141.14.128.72 netmask 0xf000 broadcast 141.14.143.255
u   nd6 options!
ifconfig: cgem0: ngo media types?: cgem0: sending ARP announce (1 of 2), next 
in 2.0 seconds


These messages appear during startup :

* Initializing network (libbsd, dhcpcd) *
nexus0: 
cgem0:  on nexus0
miibus0:  on cgem0
info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
arasan_sdhci1:  on nexus0
arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 50MHz 
as default.
arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, setting 
BROKEN_TIMEOUT quirk.
arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
arasan_sdhci0:  on nexus0
arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 50MHz 
as default.
arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, setting 
BROKEN_TIMEOUT quirk.
mmc0:  on arasan_sdhci0
zy7_slcr0:  on nexus0
mmcsd0: 16GB  (read-only) at 
mmc0 50.0MHz/4bit/65535-block

I have already found a suitable entry here, but unfortunately I don't know how 
it 'fits' my problem:
https://lists.rtems.org/pipermail/users/2023-July/068855.html


Danke Heinz

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

[Heinz Junkes]

This is the output of NFS01 Test:

*** BEGIN OF TEST LIBBSD NFS 1 ***
*** TEST VERSION: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
*** TEST STATE: USER_INPUT
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 13.3.0 20240521 (RTEMS 6, RSB 
4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
nexus0: 
cgem0:  on nexus0
miibus0:  on cgem0
info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
arasan_sdhci1:  on nexus0
arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 50MHz 
as default.
arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, setting 
BROKEN_TIMEOUT quirk.
arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
arasan_sdhci0:  on nexus0
arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 50MHz 
as default.
arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, setting 
BROKEN_TIMEOUT quirk.
mmc0:  on arasan_sdhci0
zy7_slcr0:  on nexus0
mmcsd0: 16GB  (read-only) at 
mmc0 50.0MHz/4bit/65535-block
info: lo0: link state changed to UP
add host 141.14.128.128: gateway cgem0
add net default: gateway 141.14.128.128
error: cgem0: no active link
assertion "seconds < 10" failed: file 
"../../testsuite/include/rtems/bsd/test/default-network-init.h", line 193, 
function: default_wait_for_link_up

*** FATAL ***
fatal source: 7 (RTEMS_FATAL_SOURCE_ASSERT)
fatal code: 3443784 (0x00348c48)
RTEMS version: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
RTEMS tools: 13.3.0 20240521 (RTEMS 6, RSB 
4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
executing thread ID: 0x0a010001
executing thread name: UI1

Heinz

> On 13. Aug 2024, at 16:40, Heinz Junkes  wrote:
>
> Hi,
> unfortunately I cannot activate the cgem0 network interface with RTEMS 6 
> (libbsd 6-freebsd-12)
> on a xilinx_zynq_zybo_z7 board :
>
> cgem0: flagsˆ43 metric 0 mtu 1500
> d   options€008
> e   ether 92:c2:88:7d:f4:79
>inet6 fe80::90c2:88ff:fe7d:f479%cgem0 prefixlen 64 scopeid 0x1
> b   inet 141.14.128.72 netmask 0xf000 broadcast 141.14.143.255
> u   nd6 options!
> ifconfig: cgem0: ngo media types?: cgem0: sending ARP announce (1 of 2), next 
> in 2.0 seconds
>
>
> These messages appear during startup :
>
> * Initializing network (libbsd, dhcpcd) *
> nexus0: 
> cgem0:  on nexus0
> miibus0:  on cgem0
> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> arasan_sdhci1:  on nexus0
> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> arasan_sdhci0:  on nexus0
> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> mmc0:  on arasan_sdhci0
> zy7_slcr0:  on nexus0
> mmcsd0: 16GB  (read-only) at 
> mmc0 50.0MHz/4bit/65535-block
>
> I have already found a suitable entry here, but unfortunately I don't know 
> how it 'fits' my problem:
> https://lists.rtems.org/pipermail/users/2023-July/068855.html
>
>
> Danke Heinz___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel




smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

[Heinz Junkes]

I have a Rev.D board and it has a different Realtek PHY with different 
connections to MIO Bank.
RTL8211F instead of RTL8211E
I have to find out where this is defined/used in the rtems-libbsd.
Heinz


> On 13. Aug 2024, at 17:16, Heinz Junkes  wrote:
>
> This is the output of NFS01 Test:
>
> *** BEGIN OF TEST LIBBSD NFS 1 ***
> *** TEST VERSION: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> *** TEST STATE: USER_INPUT
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 13.3.0 20240521 (RTEMS 6, RSB 
> 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> nexus0: 
> cgem0:  on nexus0
> miibus0:  on cgem0
> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> arasan_sdhci1:  on nexus0
> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> arasan_sdhci0:  on nexus0
> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> mmc0:  on arasan_sdhci0
> zy7_slcr0:  on nexus0
> mmcsd0: 16GB  (read-only) at 
> mmc0 50.0MHz/4bit/65535-block
> info: lo0: link state changed to UP
> add host 141.14.128.128: gateway cgem0
> add net default: gateway 141.14.128.128
> error: cgem0: no active link
> assertion "seconds < 10" failed: file 
> "../../testsuite/include/rtems/bsd/test/default-network-init.h", line 193, 
> function: default_wait_for_link_up
>
> *** FATAL ***
> fatal source: 7 (RTEMS_FATAL_SOURCE_ASSERT)
> fatal code: 3443784 (0x00348c48)
> RTEMS version: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> RTEMS tools: 13.3.0 20240521 (RTEMS 6, RSB 
> 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> executing thread ID: 0x0a010001
> executing thread name: UI1
>
> Heinz
>
>> On 13. Aug 2024, at 16:40, Heinz Junkes  wrote:
>>
>> Hi,
>> unfortunately I cannot activate the cgem0 network interface with RTEMS 6 
>> (libbsd 6-freebsd-12)
>> on a xilinx_zynq_zybo_z7 board :
>>
>> cgem0: flagsˆ43 metric 0 mtu 1500
>> d   options€008
>> e   ether 92:c2:88:7d:f4:79
>>   inet6 fe80::90c2:88ff:fe7d:f479%cgem0 prefixlen 64 scopeid 0x1
>> b   inet 141.14.128.72 netmask 0xf000 broadcast 141.14.143.255
>> u   nd6 options!
>> ifconfig: cgem0: ngo media types?: cgem0: sending ARP announce (1 of 2), 
>> next in 2.0 seconds
>>
>>
>> These messages appear during startup :
>>
>> * Initializing network (libbsd, dhcpcd) *
>> nexus0: 
>> cgem0:  on nexus0
>> miibus0:  on cgem0
>> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
>> arasan_sdhci1:  on nexus0
>> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
>> 50MHz as default.
>> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
>> setting BROKEN_TIMEOUT quirk.
>> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
>> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
>> arasan_sdhci0:  on nexus0
>> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
>> 50MHz as default.
>> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
>> setting BROKEN_TIMEOUT quirk.
>> mmc0:  on arasan_sdhci0
>> zy7_slcr0:  on nexus0
>> mmcsd0: 16GB  (read-only) at 
>> mmc0 50.0MHz/4bit/65535-block
>>
>> I have already found a suitable entry here, but unfortunately I don't know 
>> how it 'fits' my problem:
>> https://lists.rtems.org/pipermail/users/2023-July/068855.html
>>
>>
>> Danke Heinz___
>> 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




smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel