Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

2022-10-25 Thread Sebastian Huber 

On 24/10/2022 21:27, Joel Sherrill wrote:

I'm not sure how often the GNU tools mirrors are updated for RTEMS
at GitHub but it would be appreciated if the frequency could be increased.
It seems to add a day to any tool update that requires using a git hash 
since

the mirroring takes a while after the commit.


Currently, it is updated once per day. What would be your desired update 
interval?


In general, our current approach is quite a hack. We should do things 
more event driven. For example, if you want to update the RSB, then you 
create a pull request. This pull request starts a CI script which 
updates the mirrors and builds the RSB on a selected set of platforms. 
If everything is all right, the pull request can be merged.


--
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: [libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS

2022-10-25 Thread Sebastian Huber 

On 21/10/2022 16:16, Sebastian Huber wrote:

On 21/10/2022 16:07, Joel Sherrill wrote:
On Thu, Oct 20, 2022 at 7:30 PM Chris Johns > wrote:


    On 20/10/2022 7:01 pm, Sebastian Huber wrote:
 > On 29/08/2022 10:27, Sebastian Huber wrote:
 >> Hello Chris,
 >>
 >> On 25/07/2022 08:12, Sebastian Huber wrote:
 >>> On 11/07/2022 15:04, Sebastian Huber wrote:
  On 24/06/2022 08:33, Sebastian Huber wrote:
 > This patch set removes the FreeBSD file descriptors.  The VFS
    is no longer
 > used
 > if only the USB, SD/MMC, network, PCI, and NVMe support is
    used by the
 > application.  This change significantly reduce the memory
    usage of LibBSD for
 > these applications.  Using the media01 test case for the
    arm/lpc32xx BSP as a
 > benchmark, the heap usage dropped from 14.3MiB to 10.2MiB. 
    The "_BSD

 > bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD
    bufspacedaemon-" tasks are
 > no longer present in media01.  The code size is reduced by
    about 8KiB.  The
 > data size is reduced by about 30KiB.  The throughput with a
    simple FTP test
 > increased by about 1%.


Only the decrease in heap size is significant enough to discuss. The 
others are noise

when considered in light of the source transparency we aimed for.

https://freebsdfoundation.org/wp-content/uploads/2016/08/FreeBSD-and-RTEMS-Unix-in-a-Real-Time-Operating-System.pdf
 


This guideline which is intended to increase compatibility and lower 
long-term

maintenance is at odds with this set of patches.


It would be really nice if you could review the patch set in detail 
before you write something like this. Did you ever update a FreeBSD 
baseline in one of the libbsd branches? It is also a nice exercise to 
step through for example sendto() from the file descriptor until you get 
the socket object.


I will definitely not ship the FreeBSD file descriptors to our 
customers. As I said before, the current state prevents an update of the 
FreeBSD baseline from my side. Since you are so concerned about the 
long-term maintenance, what are your plans for a FreeBSD baseline update 
of the 6-freebsd-12 branch? The last update was:


commit 46b3858b27d78e14a220f8d251fd7ab28a5244f4
Author: Sebastian Huber 
Date:   Mon Feb 10 15:34:55 2020 +0100

Update to FreeBSD stable/12 2020-02-10

Git mirror commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.

This is now more than two years ago and there are a couple of security 
fixes available in the FreeBSD 12 release branch which we do not provide 
in libbsd.


--
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: rtems-libbsd support RISC-V or not

2022-10-25 Thread Hesham Almatary 
I tested building a RISC-V BSP (rv64imafdc_medany) for QEMU today.
Things build out the box. I also tried to run the tests and got the
following results:

Passed:31
Failed: 4
User Input:21
Expected Fail:  0
Indeterminate:  0
Benchmark:  0
Timeout:0
Test too long:  0
Invalid:0
Wrong Version:  0
Wrong Build:0
Wrong Tools:0
Wrong Header:   0
-
Total: 56
Failures:
 commands01.exe
 lagg01.exe
 ping01.exe
 vlan01.exe
User Input:
 arphole.exe
 dhcpcd02.exe
 dhcpcd01.exe
 ftpd01.exe
 foobarserver.exe
 evdev01.exe
 foobarclient.exe
 ipsec01.exe
 mcast01.exe
 nfs01.exe
 netshell01.exe
 media01.exe
 ppp01.exe
 pf02.exe
 telnetd01.exe
 termios.exe
 usbkbd01.exe
 usb01.exe
 usbserial01.exe
 usbmouse01.exe
 zerocopy01.exe
Average test time: 0:00:01.029167
Testing time : 0:00:57.633379

Supporting/adding a virtio-net device should be straightforward.



On Mon, 17 Oct 2022 at 14:05, Joel Sherrill  wrote:
>
>
>
> On Mon, Oct 17, 2022, 2:19 AM Sebastian Huber 
>  wrote:
>>
>> Hello Padmarao,
>>
>> I am not sure if rtems-libbsd was used on riscv before, however, adding
>> the architecture support wouldn't be difficult.
>
>
> I agree with Sebastian that I don't think riscv has been used before but 
> FreeBSD supports it. The driver added for Microblaze was added to support a 
> secure voting machine which is using CHERI and riscv.
>


> Shouldn't be a huge deal especially if the driver is already in FreeBSD.
>
>>
>> --
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH RSB v1] Update mipstx39 gdb version to pick up fix to make simulator work

2022-10-25 Thread Joel Sherrill 
Closes #4689.
---
 rtems/config/6/rtems-mips.bset| 2 +-
 rtems/config/tools/rtems-gdb-head.cfg | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/rtems/config/6/rtems-mips.bset b/rtems/config/6/rtems-mips.bset
index 48771f3..370e5ea 100644
--- a/rtems/config/6/rtems-mips.bset
+++ b/rtems/config/6/rtems-mips.bset
@@ -3,4 +3,4 @@
 %define gdb-sim-options --enable-sim-hardware
 %define win32-gdb-disable-sim
 %include 6/rtems-default.bset
-tools/rtems-mipstx39-gdb-11.2
+tools/rtems-mipstx39-gdb-head
diff --git a/rtems/config/tools/rtems-gdb-head.cfg 
b/rtems/config/tools/rtems-gdb-head.cfg
index 967b5e6..258e3e1 100644
--- a/rtems/config/tools/rtems-gdb-head.cfg
+++ b/rtems/config/tools/rtems-gdb-head.cfg
@@ -1,11 +1,11 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gdb_version ce6c3d2
+%define gdb_version c6d2040
 %define gdb_external 1
 %define gdb_expand_name sourceware-mirror-binutils-gdb-%{gdb_version}
 %source set gdb --rsb-file=%{gdb_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{gdb_version}
 %hash sha512 %{gdb_expand_name}.tar.gz \
-  
drh71JaHy/tbyPXOVBWIETRMQOhwXuQT+wsYt8m5iCXJoNnkd+h56XopTCtvHNlc7spQUTgGbxcDhO97T5vEEg==
+  
KNcy2DdJhDaT7NhkR3dl2Ju42EhY7dn7DrV10xDiCLQbD2+1FA4Up8crLV2vM8cJ5RpntKp1fa+BgUTjR/RlMA==
 
 %include %{_configdir}/gdb-8-1.cfg
-- 
2.24.4

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

Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

2022-10-25 Thread Joel Sherrill 
On Tue, Oct 25, 2022 at 2:41 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 24/10/2022 21:27, Joel Sherrill wrote:
> > I'm not sure how often the GNU tools mirrors are updated for RTEMS
> > at GitHub but it would be appreciated if the frequency could be
> increased.
> > It seems to add a day to any tool update that requires using a git hash
> > since
> > the mirroring takes a while after the commit.
>
> Currently, it is updated once per day. What would be your desired update
> interval?
>

Maybe 3 times a day but one which hits between noon and 2pm Central would
help a lot. Right now, it is at midnight here which always forces an RSB
update
to happen a day after a patch is committed.

>
> In general, our current approach is quite a hack. We should do things
> more event driven. For example, if you want to update the RSB, then you
> create a pull request. This pull request starts a CI script which
> updates the mirrors and builds the RSB on a selected set of platforms.
> If everything is all right, the pull request can be merged.
>

Just getting to the point where a pull request triggered an update would
be useful. Assuming a pull request with no content would be ok.

--joel

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

[PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

2022-10-25 Thread heshamelmatary 
From: Hesham Almatary 

The BSP is capable of initialising the hardware being the first software
that takes control on hardware reset (after the bootrom). For instance,
using on QEMU's  virt platforms, RTEMS runs as a bios without BBL.
Similarily, RTEMS can also be run on harware/FPGA and loaded using
GDB; the bootrom (or a GDB script) should just set the a0/a1 registers
with the boot HART ID and DTB address respectively.
---
 user/bsps/bsps-riscv.rst | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 48e7ee7..224506d 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -43,9 +43,7 @@ This BSP offers 15 variants:
 Each variant corresponds to a GCC multilib.  A particular variant reflects an
 ISA with ABI and code model choice.
 
-The basic hardware initialization is not performed by the BSP.  A boot loader
-with device tree support must be used to start the BSP, e.g. BBL.  The BSP must
-be started im machine mode.
+The BSP must be started im machine mode.
 
 The reference platform for this BSP is the Qemu `virt` machine.
 
-- 
2.25.1

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

[PATCH 2/2] bsp/riscv: Add a section about running on QEMU

2022-10-25 Thread heshamelmatary 
From: Hesham Almatary 

---
 user/bsps/bsps-riscv.rst | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 224506d..db7fd95 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -141,6 +141,21 @@ They are initialized according to the device tree.  The 
console driver does not
 configure the pins or peripheral clocks.  The console device is selected
 according to the device tree "/chosen/stdout-path" property value.
 
+QEMU
+
+
+All of the BSP variants that start with rv can be run on QEMU's virt machine.
+For instance, to run the ``rv64imafdc_medany`` BSP with the following
+"config.ini" file:
+
+.. code-block:: none
+[riscv/rv64imafdc_medany]
+
+Run the following QEMU command:
+
+.. code-block:: shell
+$ qemu-system-riscv64 -M virt -nographic -bios $RTEMS_EXE
+
 Microchip PolarFire SoC
 ---
 
-- 
2.25.1

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

RE: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

2022-10-25 Thread Alan Cudmore 
I agree – I am working on a riscv BSP variant (Sipeed MAIX Bit with K210 CPU) where the RTEMS image can be flashed directly to the board and boots without a bootloader.I was also wondering if the statement “Each variant corresponds to a GCC multilib” is still accurate as BSP variants such as the FE310Arty and Microchip Polarfire are added?Thanks,AlanFrom: heshamelmat...@gmail.comSent: Tuesday, October 25, 2022 1:48 PMTo: devel@rtems.orgSubject: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader From: Hesham Almatary  The BSP is capable of initialising the hardware being the first softwarethat takes control on hardware reset (after the bootrom). For instance,using on QEMU's  virt platforms, RTEMS runs as a bios without BBL.Similarily, RTEMS can also be run on harware/FPGA and loaded usingGDB; the bootrom (or a GDB script) should just set the a0/a1 registerswith the boot HART ID and DTB address respectively.--- user/bsps/bsps-riscv.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rstindex 48e7ee7..224506d 100644--- a/user/bsps/bsps-riscv.rst+++ b/user/bsps/bsps-riscv.rst@@ -43,9 +43,7 @@ This BSP offers 15 variants: Each variant corresponds to a GCC multilib.  A particular variant reflects an ISA with ABI and code model choice. -The basic hardware initialization is not performed by the BSP.  A boot loader-with device tree support must be used to start the BSP, e.g. BBL.  The BSP must-be started im machine mode.+The BSP must be started im machine mode.  The reference platform for this BSP is the Qemu `virt` machine. -- 2.25.1 ___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

2022-10-25 Thread Sebastian Huber 

On 25/10/2022 19:46, Joel Sherrill wrote:
On Tue, Oct 25, 2022 at 2:41 AM Sebastian Huber 
> wrote:


On 24/10/2022 21:27, Joel Sherrill wrote:
 > I'm not sure how often the GNU tools mirrors are updated for RTEMS
 > at GitHub but it would be appreciated if the frequency could be
increased.
 > It seems to add a day to any tool update that requires using a
git hash
 > since
 > the mirroring takes a while after the commit.

Currently, it is updated once per day. What would be your desired
update
interval?


Maybe 3 times a day but one which hits between noon and 2pm Central would
help a lot. Right now, it is at midnight here which always forces an RSB 
update

to happen a day after a patch is committed.


I changed it to run at 4:00, 12:00, and 20:00 CET.

--
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: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

2022-10-25 Thread Hesham Almatary 
On Tue, 25 Oct 2022 at 18:59, Alan Cudmore  wrote:
>
> I agree – I am working on a riscv BSP variant (Sipeed MAIX Bit with K210 CPU) 
> where the RTEMS image can be flashed directly to the board and boots without 
> a bootloader.
>
> I was also wondering if the statement “Each variant corresponds to a GCC 
> multilib” is still accurate as BSP variants such as the FE310Arty and 
> Microchip Polarfire are added?
>
I agree. It only applies to rv* BSPs. We should fix that.

> Thanks,
>
> Alan
>
> From: heshamelmat...@gmail.com
> Sent: Tuesday, October 25, 2022 1:48 PM
> To: devel@rtems.org
> Subject: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance 
> on a boot loader
>
>
>
> From: Hesham Almatary 
>
>
>
> The BSP is capable of initialising the hardware being the first software
>
> that takes control on hardware reset (after the bootrom). For instance,
>
> using on QEMU's  virt platforms, RTEMS runs as a bios without BBL.
>
> Similarily, RTEMS can also be run on harware/FPGA and loaded using
>
> GDB; the bootrom (or a GDB script) should just set the a0/a1 registers
>
> with the boot HART ID and DTB address respectively.
>
> ---
>
> user/bsps/bsps-riscv.rst | 4 +---
>
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>
>
> diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
>
> index 48e7ee7..224506d 100644
>
> --- a/user/bsps/bsps-riscv.rst
>
> +++ b/user/bsps/bsps-riscv.rst
>
> @@ -43,9 +43,7 @@ This BSP offers 15 variants:
>
> Each variant corresponds to a GCC multilib.  A particular variant reflects an
>
> ISA with ABI and code model choice.
>
> -The basic hardware initialization is not performed by the BSP.  A boot loader
>
> -with device tree support must be used to start the BSP, e.g. BBL.  The BSP 
> must
>
> -be started im machine mode.
>
> +The BSP must be started im machine mode.
>
>  The reference platform for this BSP is the Qemu `virt` machine.
>
> --
>
> 2.25.1
>
>
>
> ___
>
> devel mailing list
>
> devel@rtems.org
>
> http://lists.rtems.org/mailman/listinfo/devel
>
>



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

[PATCH v2 0/1] BSP include directory option update

2022-10-25 Thread Kinsey Moore 
The previous version of this patch only updated the genearted
packageconfig (.pc) file. This version updates the Makefile as well. Any
consumers of these two files will incorporate the change transparently.


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

[PATCH v2] spec/pkgconfig: Allow builds to override headers

2022-10-25 Thread Kinsey Moore 
This allows any builds targeting an installed RTEMS BSP to override
headers in the installed BSP reliably, including headers previously
installed by that or other builds. This includes applications, network
stacks, libraries, and any other builds.
---
 spec/build/bsps/makecustom.yml | 2 +-
 spec/build/bsps/pkgconfig.yml  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/spec/build/bsps/makecustom.yml b/spec/build/bsps/makecustom.yml
index 139629b597..9f5f2f2e59 100644
--- a/spec/build/bsps/makecustom.yml
+++ b/spec/build/bsps/makecustom.yml
@@ -2,7 +2,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 build-type: config-file
 content: |
   include $$(RTEMS_ROOT)/make/custom/default.cfg
-  CPU_DEFINES = -I$$(exec_prefix)/$$(RTEMS_BSP)/lib/include
+  CPU_DEFINES = -isystem$$(exec_prefix)/$$(RTEMS_BSP)/lib/include
   CPU_CFLAGS = ${ABI_FLAGS}
   CFLAGS_OPTIMIZE_V = ${OPTIMIZATION_FLAGS}
   LDFLAGS = -B$$(exec_prefix)/$$(RTEMS_BSP)/lib ${PKGCONFIG_LDFLAGS}
diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
index a9462fcc95..8a3c3677a4 100644
--- a/spec/build/bsps/pkgconfig.yml
+++ b/spec/build/bsps/pkgconfig.yml
@@ -22,7 +22,7 @@ content: |
   Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
   Version: ${RTEMS_VERSION}
   Description: RTEMS BSP ${ARCH}/${BSP_NAME}
-  Cflags: $${ABI_FLAGS} -I$${includedir}
+  Cflags: $${ABI_FLAGS} -isystem$${includedir}
   Ldflags: -B$${libdir} ${PKGCONFIG_LDFLAGS}
   Libs: -B$${libdir} ${PKGCONFIG_LDFLAGS}
 copyrights:
-- 
2.30.2

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

Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

2022-10-25 Thread Chris Johns 
On 26/10/2022 4:46 am, Joel Sherrill wrote:
> In general, our current approach is quite a hack. We should do things
> more event driven. For example, if you want to update the RSB, then you
> create a pull request. This pull request starts a CI script which
> updates the mirrors and builds the RSB on a selected set of platforms.
> If everything is all right, the pull request can be merged.
> 
> Just getting to the point where a pull request triggered an update would
> be useful. Assuming a pull request with no content would be ok.

I feel starting to have pull requests will only result in changes being posted
there by users who see pull requests as active. It is reasonable for a user to
think this. Who will then field those and merge them?

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