date:20230130

Re: Question w.r.t. crash inside select call from libbsd.

2023-01-30 Thread Sebastian Huber




On 30.01.23 23:33, Karel Gardas wrote:


I'm debugging crash inside the select call from libbsd library. The code 
comes from few days old RTEMS and few days old libbsd trees. My naive 
configuration for the RTEMS is below.


The crash backtrace is:

_CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640) at ../../../cpukit/score/cpu/arm/cpu.c:203

203   while ( true ) {
(gdb) where
#0  _CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640)

     at ../../../cpukit/score/cpu/arm/cpu.c:203
#1  0x080fb9b4 in _Terminate 
(the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,

     the_error=604203640) at ../../../cpukit/score/src/interr.c:58
#2  0x08104e56 in rtems_fatal (fatal_code=,
     fatal_source=RTEMS_FATAL_SOURCE_EXCEPTION) at 
../../../cpukit/include/rtems/fatal.h:160

#3  _ARM_Exception_default (frame=)
     at ../../../cpukit/score/cpu/arm/arm-exception-default.c:37
#4  
#5  _bsd_uma_zalloc_arg (zone=0x9, udata=udata@entry=0x0, 
flags=flags@entry=2)

     at ../../freebsd/sys/vm/uma_core.c:2624
#6  0x0807c180 in uma_zalloc (flags=2, zone=)
     at ../../freebsd/sys/vm/uma.h:356
#7  0x080b51b8 in rtems_bsd_thread_create (thread=0xd0003048 
<_RTEMS_tasks_Objects>,

     wait=) at ../../rtemsbsd/rtems/rtems-kernel-thread.c:93
#8  0x080b5250 in rtems_bsd_get_curthread (wait=0)
     at ../../rtemsbsd/rtems/rtems-kernel-thread.c:116
#9  0x0807e59a in select (nfds=1, readfds=readfds@entry=0xd000da30,
     writefds=writefds@entry=0xd000da38, errorfds=errorfds@entry=0x0,
     _bsd_timeout=_bsd_timeout@entry=0x0) at 
../../freebsd/sys/kern/sys_generic.c:1170



When I put breakpoint here and there I found strange fact that zone = 
0x0 in frame #5 and not 0x9:


Breakpoint 1, _bsd_uma_zalloc_arg (zone=0x0, udata=udata@entry=0x0, 
flags=flags@entry=2) at ../../freebsd/sys/vm/uma_core.c:2562

2562    {
(gdb) next
2680    bucket_free(zone, bucket, udata);
(gdb) next
2622    critical_enter();
(gdb) next
196   cpu_self->thread_dispatch_disable_level = disable_level + 1;
(gdb) next
2622    critical_enter();
(gdb) next
2624    cache = >uz_cpu[cpu];
(gdb) next
_ARMV7M_Exception_default () at 
../../../cpukit/score/cpu/arm/armv7m-exception-default.c:51

51    __asm__ volatile (
(gdb)


so with zone being NULL the crash is expected here. However I'm still 
curious if this is libbsd issue or my issue with naive configuration?


Did you use select() before libbsd is initialized? Do you have more than 
64 file descriptors? In this case the fd set type is too small and you 
have a stack overflow. Which branch of libbsd do you use? Maybe try out 
the other branch as well.




The platform is STM32H757i-eval board, the linking is using flash_sdram 
configuration. The board provides 16MB of SDRAM so hopefully this should 
be enough even for libbsd... The board configuration is more or less 
default except disabling of MPU alignment. If I don't do this, my 
testing app (quickjs) would not fit 2MB of CPU flash. When MPU alignment 
is disabled, I'm on 1.4MB of flash consumption (before disabling 2.3MB)


From the 16MiB you already waste 4MiB for unused features if you use 
the latest 6-freebsd-12 branch of 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: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

2023-01-30 Thread Kinsey Moore

Sorry, I'll make sure to avoid this going forward.

Kinsey

On Mon, Jan 30, 2023 at 5:41 PM Chris Johns  wrote:

> On 31/1/2023 10:23 am, Kinsey Moore wrote:
> > On 1/30/2023 5:13 PM, Chris Johns wrote:
> >> Can the subject please be:
> >>
> >> dtc: Add patch to build for cygwin builds
> >>
> >> ?
> >
> > Unfortunately, Joel pushed this and a tools hash bump along with the
> other two
> > patches, so that would require rewriting history.
>
> That is a shame. We should limit references to tickets to the body of a
> commit
> message and not the subject line. I needed to inspect the ticket to
> determine
> what the change was about.
>
> 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: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

2023-01-30 Thread Chris Johns

On 31/1/2023 10:23 am, Kinsey Moore wrote:
> On 1/30/2023 5:13 PM, Chris Johns wrote:
>> Can the subject please be:
>>
>> dtc: Add patch to build for cygwin builds
>>
>> ?
> 
> Unfortunately, Joel pushed this and a tools hash bump along with the other two
> patches, so that would require rewriting history.

That is a shame. We should limit references to tickets to the body of a commit
message and not the subject line. I needed to inspect the ticket to determine
what the change was about.

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

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

2023-01-30 Thread Kinsey Moore


On 1/30/2023 5:13 PM, Chris Johns wrote:

Can the subject please be:

dtc: Add patch to build for cygwin builds

?


Unfortunately, Joel pushed this and a tools hash bump along with the 
other two patches, so that would require rewriting history.


Kinsey

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

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

2023-01-30 Thread Chris Johns

Can the subject please be:

dtc: Add patch to build for cygwin builds

?

Chris

On 31/1/2023 4:30 am, Kinsey Moore wrote:
> This patch resolves a build error with dtc on cygwin until upstream
> adopts a fix.
> ---
>  bare/config/devel/dtc-1.6.1-1.cfg | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/bare/config/devel/dtc-1.6.1-1.cfg 
> b/bare/config/devel/dtc-1.6.1-1.cfg
> index 54aed09..acf2cd8 100644
> --- a/bare/config/devel/dtc-1.6.1-1.cfg
> +++ b/bare/config/devel/dtc-1.6.1-1.cfg
> @@ -12,6 +12,9 @@
>  
>  %hash sha256 dtc-%{dtc_version}.tar.gz 
> 38a6257f2c23cb9dfa1781ac4ad122d8358e1a22d33b2da0eb492c190644a376
>  
> +%patch add dtc 
> https://devel.rtems.org/raw-attachment/ticket/4783/0001-checks.c-Ensure-argument-is-an-integer-v2.patch
> +%hash sha256 0001-checks.c-Ensure-argument-is-an-integer-v2.patch 
> dd83c10326188732ac26c1fd8dce70b796a7dde204b31c67cf4d04f29ed4dfef
> +
>  #
>  # The DTC build instructions. We use 1.x.x Release 1.
>  #
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] devel/gnu-default-tools: Use correct include path

2023-01-30 Thread Chris Johns

OK

Thanks
Chris

On 31/1/2023 9:55 am, Kinsey Moore wrote:
> Include paths must use the full file name with extension. This was
> causing errors because it couldn't resolve the include.
> ---
>  bare/config/devel/gnu-default-tools.bset | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bare/config/devel/gnu-default-tools.bset 
> b/bare/config/devel/gnu-default-tools.bset
> index cb253f4..2290788 100644
> --- a/bare/config/devel/gnu-default-tools.bset
> +++ b/bare/config/devel/gnu-default-tools.bset
> @@ -11,7 +11,7 @@
>  # available
>  #
>  %define _internal_gsed_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> -%include textproc/gsed-internal
> +%include textproc/gsed-internal.bset
>  
>  #
>  # Build gdb first to raise the Python install error as early as
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] Update hashes for github-sourced tarballs

2023-01-30 Thread Chris Johns

OK

Thanks
Chris

On 31/1/2023 9:40 am, Kinsey Moore wrote:
> Github has changed the way it generates on-the-fly tarball requests
> which has changed the hashes of the resulting tarballs. This adjusts the
> affected tarball hashes as a stop-gap until a more permanent solution
> can be devised.
> ---
>  bare/config/devel/capstone-4.0.1-1.cfg| 2 +-
>  bare/config/devel/gcc-12-newlib-head.cfg  | 4 ++--
>  bare/config/devel/qemu-couverture-git-1.cfg   | 2 +-
>  bare/config/devel/spike-1.1.0.cfg | 2 +-
>  bare/config/devel/swig-4.0.1.cfg  | 2 +-
>  rtems/config/graphics/microwindows-0.93-dev-1.cfg | 2 +-
>  rtems/config/net-mgmt/net-snmp-5.7.2.1-1.cfg  | 2 +-
>  rtems/config/tools/rtems-binutils-2.36.cfg| 2 +-
>  rtems/config/tools/rtems-binutils-head.cfg| 2 +-
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 2 +-
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gdb-head.cfg | 2 +-
>  source-builder/config/capstone-1-1.cfg| 2 +-
>  15 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/bare/config/devel/capstone-4.0.1-1.cfg 
> b/bare/config/devel/capstone-4.0.1-1.cfg
> index 9f3627c..3a7c6bc 100644
> --- a/bare/config/devel/capstone-4.0.1-1.cfg
> +++ b/bare/config/devel/capstone-4.0.1-1.cfg
> @@ -19,7 +19,7 @@
>  # Set source from github.
>  #
>  %source set capstone --rsb-file=capstone-%{capstone_version}.tar.gz 
> https://github.com/aquynh/capstone/archive/%{capstone_version}.tar.gz
> -%hash sha512 capstone-%{capstone_version}.tar.gz 
> 43c52024065b41b45eff9423341db3f3d5163fa7aa01b360faa30437786740c8f2c34c36faa04dced5308e09d8bd78df3bad0ab9c06f98612169edb176f83c36
> +%hash sha512 capstone-%{capstone_version}.tar.gz 
> 296c90fcca96117b710472fb55881cb932f4f1d45e847647c2357bfa15bf36fd7f4584db5ffdabf85703d9840e65085ba76f387e6a8e0af941a344dcf95c
>  
>  #
>  # The build instructions.
> diff --git a/bare/config/devel/gcc-12-newlib-head.cfg 
> b/bare/config/devel/gcc-12-newlib-head.cfg
> index ce168ea..d50553d 100644
> --- a/bare/config/devel/gcc-12-newlib-head.cfg
> +++ b/bare/config/devel/gcc-12-newlib-head.cfg
> @@ -5,7 +5,7 @@
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
> -%hash sha512 %{gcc_expand_name}.tar.gz 
> f9eb91029c31ed2ca3c4ce2066d99352f63f55120aaad295b58621786fe76228d182a4421292fa95007ac6b6529a589795fe3e794ac77b0b86f9cf9286125e36
> +%hash sha512 %{gcc_expand_name}.tar.gz 
> 2f78955344634e3d13a34ae8e724a61761dbc71a88e41916192e6c9d01508014ded06e32a9b640d203b6a8e989ec5410bda32d0469f4b3fe5bf20ae63ad9de21
>  
>  %patch add gcc -p1 
> https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch
>  %hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch 
> 413f14374856f8bfd2bb94a56f1860fff8fe9a936f33c96fdf6a5a0c5a30e2cf7d05026d0338e8b30015a93d80169a602397076b947c8292ac5b5cdc2237ec4e
> @@ -31,7 +31,7 @@
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> -%hash sha512 newlib-%{newlib_version}.tar.gz 
> 0e142b06b855b78729c3319e31cf5c15b48cea1f90e001ae1e2d61793c496374065c5658e835e6277ae0739af22ea397feb2c1bc2509a6a80ee6c03818efbf55
> +%hash sha512 newlib-%{newlib_version}.tar.gz 
> 051496b686c0acaf1e5fb4f63155aa35357bbe71017f827d6e4113138fec964b083f29c880c3ced9db6e09dc6b3b5bc11ea7d9e9e2987ce015ac2784c2905082
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/bare/config/devel/qemu-couverture-git-1.cfg 
> b/bare/config/devel/qemu-couverture-git-1.cfg
> index bb9b7a6..c6fbe1f 100644
> --- a/bare/config/devel/qemu-couverture-git-1.cfg
> +++ b/bare/config/devel/qemu-couverture-git-1.cfg
> @@ -29,7 +29,7 @@
>  # Set Couverture-Qemu source from github.
>  #
>  %source set qemu --rsb-file=qemu-couverture-%{qemu_version}.tar.gz 
> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
> -%hash sha512 qemu-couverture-%{qemu_version}.tar.gz 
> 4b1877f1e8a10508b161a2b65f8e862e2ffa5bfc36cb458cdcad4e8a71a384bbb28e7fb50555008b023691b8187d252870586b1435e31989d059692f53ad6e1c
> +%hash sha512 qemu-couverture-%{qemu_version}.tar.gz 
> e26959cb55ae0c565c299ec38fe86b7bf85bdb246bfc99f0fcd22e1baaebaa05e96a46b3781443678fb63de8e4b3b7b0abc30d717eda6eef216a53fcabab47c0
>  
>  #
>  # The Qemu build instructions. We use 4.x.x Release 1.
> diff --git a/bare/config/devel/spike-1.1.0.cfg 
> b/bare/config/devel/spike-1.1.0.cfg
> index 73cf3c2..5a8cae0 100644
> ---

[PATCH rtems-source-builder] devel/gnu-default-tools: Use correct include path

2023-01-30 Thread Kinsey Moore

Include paths must use the full file name with extension. This was
causing errors because it couldn't resolve the include.
---
 bare/config/devel/gnu-default-tools.bset | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bare/config/devel/gnu-default-tools.bset 
b/bare/config/devel/gnu-default-tools.bset
index cb253f4..2290788 100644
--- a/bare/config/devel/gnu-default-tools.bset
+++ b/bare/config/devel/gnu-default-tools.bset
@@ -11,7 +11,7 @@
 # available
 #
 %define _internal_gsed_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
-%include textproc/gsed-internal
+%include textproc/gsed-internal.bset
 
 #
 # Build gdb first to raise the Python install error as early as
-- 
2.30.2

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

[PATCH rtems-source-builder] Update hashes for github-sourced tarballs

2023-01-30 Thread Kinsey Moore

Github has changed the way it generates on-the-fly tarball requests
which has changed the hashes of the resulting tarballs. This adjusts the
affected tarball hashes as a stop-gap until a more permanent solution
can be devised.
---
 bare/config/devel/capstone-4.0.1-1.cfg| 2 +-
 bare/config/devel/gcc-12-newlib-head.cfg  | 4 ++--
 bare/config/devel/qemu-couverture-git-1.cfg   | 2 +-
 bare/config/devel/spike-1.1.0.cfg | 2 +-
 bare/config/devel/swig-4.0.1.cfg  | 2 +-
 rtems/config/graphics/microwindows-0.93-dev-1.cfg | 2 +-
 rtems/config/net-mgmt/net-snmp-5.7.2.1-1.cfg  | 2 +-
 rtems/config/tools/rtems-binutils-2.36.cfg| 2 +-
 rtems/config/tools/rtems-binutils-head.cfg| 2 +-
 rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 2 +-
 rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gdb-head.cfg | 2 +-
 source-builder/config/capstone-1-1.cfg| 2 +-
 15 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/bare/config/devel/capstone-4.0.1-1.cfg 
b/bare/config/devel/capstone-4.0.1-1.cfg
index 9f3627c..3a7c6bc 100644
--- a/bare/config/devel/capstone-4.0.1-1.cfg
+++ b/bare/config/devel/capstone-4.0.1-1.cfg
@@ -19,7 +19,7 @@
 # Set source from github.
 #
 %source set capstone --rsb-file=capstone-%{capstone_version}.tar.gz 
https://github.com/aquynh/capstone/archive/%{capstone_version}.tar.gz
-%hash sha512 capstone-%{capstone_version}.tar.gz 
43c52024065b41b45eff9423341db3f3d5163fa7aa01b360faa30437786740c8f2c34c36faa04dced5308e09d8bd78df3bad0ab9c06f98612169edb176f83c36
+%hash sha512 capstone-%{capstone_version}.tar.gz 
296c90fcca96117b710472fb55881cb932f4f1d45e847647c2357bfa15bf36fd7f4584db5ffdabf85703d9840e65085ba76f387e6a8e0af941a344dcf95c
 
 #
 # The build instructions.
diff --git a/bare/config/devel/gcc-12-newlib-head.cfg 
b/bare/config/devel/gcc-12-newlib-head.cfg
index ce168ea..d50553d 100644
--- a/bare/config/devel/gcc-12-newlib-head.cfg
+++ b/bare/config/devel/gcc-12-newlib-head.cfg
@@ -5,7 +5,7 @@
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
-%hash sha512 %{gcc_expand_name}.tar.gz 
f9eb91029c31ed2ca3c4ce2066d99352f63f55120aaad295b58621786fe76228d182a4421292fa95007ac6b6529a589795fe3e794ac77b0b86f9cf9286125e36
+%hash sha512 %{gcc_expand_name}.tar.gz 
2f78955344634e3d13a34ae8e724a61761dbc71a88e41916192e6c9d01508014ded06e32a9b640d203b6a8e989ec5410bda32d0469f4b3fe5bf20ae63ad9de21
 
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch
 %hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch 
413f14374856f8bfd2bb94a56f1860fff8fe9a936f33c96fdf6a5a0c5a30e2cf7d05026d0338e8b30015a93d80169a602397076b947c8292ac5b5cdc2237ec4e
@@ -31,7 +31,7 @@
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
-%hash sha512 newlib-%{newlib_version}.tar.gz 
0e142b06b855b78729c3319e31cf5c15b48cea1f90e001ae1e2d61793c496374065c5658e835e6277ae0739af22ea397feb2c1bc2509a6a80ee6c03818efbf55
+%hash sha512 newlib-%{newlib_version}.tar.gz 
051496b686c0acaf1e5fb4f63155aa35357bbe71017f827d6e4113138fec964b083f29c880c3ced9db6e09dc6b3b5bc11ea7d9e9e2987ce015ac2784c2905082
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/bare/config/devel/qemu-couverture-git-1.cfg 
b/bare/config/devel/qemu-couverture-git-1.cfg
index bb9b7a6..c6fbe1f 100644
--- a/bare/config/devel/qemu-couverture-git-1.cfg
+++ b/bare/config/devel/qemu-couverture-git-1.cfg
@@ -29,7 +29,7 @@
 # Set Couverture-Qemu source from github.
 #
 %source set qemu --rsb-file=qemu-couverture-%{qemu_version}.tar.gz 
https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
-%hash sha512 qemu-couverture-%{qemu_version}.tar.gz 
4b1877f1e8a10508b161a2b65f8e862e2ffa5bfc36cb458cdcad4e8a71a384bbb28e7fb50555008b023691b8187d252870586b1435e31989d059692f53ad6e1c
+%hash sha512 qemu-couverture-%{qemu_version}.tar.gz 
e26959cb55ae0c565c299ec38fe86b7bf85bdb246bfc99f0fcd22e1baaebaa05e96a46b3781443678fb63de8e4b3b7b0abc30d717eda6eef216a53fcabab47c0
 
 #
 # The Qemu build instructions. We use 4.x.x Release 1.
diff --git a/bare/config/devel/spike-1.1.0.cfg 
b/bare/config/devel/spike-1.1.0.cfg
index 73cf3c2..5a8cae0 100644
--- a/bare/config/devel/spike-1.1.0.cfg
+++ b/bare/config/devel/spike-1.1.0.cfg
@@ -10,7 +10,7 @@
 
 %define spike_version 530af85d83781a3dae31a4ace84a573ec255fefa
 
-%hash sha512 spike-%{spike_version}.tar.gz

Question w.r.t. crash inside select call from libbsd.

2023-01-30 Thread Karel Gardas




 Hello,

I'm debugging crash inside the select call from libbsd library. The code 
comes from few days old RTEMS and few days old libbsd trees. My naive 
configuration for the RTEMS is below.


The crash backtrace is:

_CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640) at ../../../cpukit/score/cpu/arm/cpu.c:203

203   while ( true ) {
(gdb) where
#0  _CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640)

at ../../../cpukit/score/cpu/arm/cpu.c:203
#1  0x080fb9b4 in _Terminate 
(the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,

the_error=604203640) at ../../../cpukit/score/src/interr.c:58
#2  0x08104e56 in rtems_fatal (fatal_code=,
fatal_source=RTEMS_FATAL_SOURCE_EXCEPTION) at 
../../../cpukit/include/rtems/fatal.h:160

#3  _ARM_Exception_default (frame=)
at ../../../cpukit/score/cpu/arm/arm-exception-default.c:37
#4  
#5  _bsd_uma_zalloc_arg (zone=0x9, udata=udata@entry=0x0, 
flags=flags@entry=2)

at ../../freebsd/sys/vm/uma_core.c:2624
#6  0x0807c180 in uma_zalloc (flags=2, zone=)
at ../../freebsd/sys/vm/uma.h:356
#7  0x080b51b8 in rtems_bsd_thread_create (thread=0xd0003048 
<_RTEMS_tasks_Objects>,

wait=) at ../../rtemsbsd/rtems/rtems-kernel-thread.c:93
#8  0x080b5250 in rtems_bsd_get_curthread (wait=0)
at ../../rtemsbsd/rtems/rtems-kernel-thread.c:116
#9  0x0807e59a in select (nfds=1, readfds=readfds@entry=0xd000da30,
writefds=writefds@entry=0xd000da38, errorfds=errorfds@entry=0x0,
_bsd_timeout=_bsd_timeout@entry=0x0) at 
../../freebsd/sys/kern/sys_generic.c:1170



When I put breakpoint here and there I found strange fact that zone = 
0x0 in frame #5 and not 0x9:


Breakpoint 1, _bsd_uma_zalloc_arg (zone=0x0, udata=udata@entry=0x0, 
flags=flags@entry=2) at ../../freebsd/sys/vm/uma_core.c:2562

2562{
(gdb) next
2680bucket_free(zone, bucket, udata);
(gdb) next
2622critical_enter();
(gdb) next
196   cpu_self->thread_dispatch_disable_level = disable_level + 1;
(gdb) next
2622critical_enter();
(gdb) next
2624cache = >uz_cpu[cpu];
(gdb) next
_ARMV7M_Exception_default () at 
../../../cpukit/score/cpu/arm/armv7m-exception-default.c:51

51__asm__ volatile (
(gdb)


so with zone being NULL the crash is expected here. However I'm still 
curious if this is libbsd issue or my issue with naive configuration?


The platform is STM32H757i-eval board, the linking is using flash_sdram 
configuration. The board provides 16MB of SDRAM so hopefully this should 
be enough even for libbsd... The board configuration is more or less 
default except disabling of MPU alignment. If I don't do this, my 
testing app (quickjs) would not fit 2MB of CPU flash. When MPU alignment 
is disabled, I'm on 1.4MB of flash consumption (before disabling 2.3MB)


Any ideas how to debug this more are highly appreciated!

Thanks!
Karel



/*
 * Configure LibBSD.
 */

#define RTEMS_BSD_CONFIG_NET_PF_UNIX
#define RTEMS_BSD_CONFIG_NET_IF_BRIDGE
#define RTEMS_BSD_CONFIG_NET_IF_LAGG
#define RTEMS_BSD_CONFIG_NET_IF_VLAN
#define RTEMS_BSD_CONFIG_BSP_CONFIG
#define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
#define RTEMS_BSD_CONFIG_INIT

#include 

/*
 * Configure RTEMS.
 */

/* This is enough to get a basic main() up. */
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_UNIFIED_WORK_AREAS
#define CONFIGURE_STACK_CHECKER_ENABLED

/* on smaller architectures lower the number or resources */
#define CONFIGURE_UNLIMITED_OBJECTS
#define CONFIGURE_MAXIMUM_USER_EXTENSIONS 8
#define CONFIGURE_MAXIMUM_DRIVERS 16
#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32

/* Include basic device drivers needed to call delays */
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK

#define CONFIGURE_MAXIMUM_PROCESSORS CPU_MAXIMUM_PROCESSORS

/* #define CONFIGURE_DISABLE_BSP_SETTINGS*/

#define CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION

#define CONFIGURE_MINIMUM_TASK_STACK_SIZE ( CPU_STACK_MINIMUM_SIZE * 4 )

#define CONFIGURE_INIT

#include 

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

Re: [RSB 5] Remove aarch64 and microblaze from RSB on 5 branch

2023-01-30 Thread Chris Johns

OK to push

Thanks
Chris

On 31/1/2023 1:44 am, Joel Sherrill wrote:
> Closes #4555.
> ---
>  rtems/config/5/rtems-aarch64.bset| 4 
>  rtems/config/5/rtems-all.bset| 2 --
>  rtems/config/5/rtems-microblaze.bset | 3 ---
>  rtems/config/5/rtems-tier-4.bset | 1 -
>  4 files changed, 10 deletions(-)
>  delete mode 100644 rtems/config/5/rtems-aarch64.bset
>  delete mode 100644 rtems/config/5/rtems-microblaze.bset
> 
> diff --git a/rtems/config/5/rtems-aarch64.bset 
> b/rtems/config/5/rtems-aarch64.bset
> deleted file mode 100644
> index f38aff3..000
> --- a/rtems/config/5/rtems-aarch64.bset
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -%define release 1
> -%define rtems_arch aarch64
> -%define with_libgomp
> -%include 5/rtems-default.bset
> diff --git a/rtems/config/5/rtems-all.bset b/rtems/config/5/rtems-all.bset
> index 00ccfae..81076e4 100644
> --- a/rtems/config/5/rtems-all.bset
> +++ b/rtems/config/5/rtems-all.bset
> @@ -1,11 +1,9 @@
> -5/rtems-aarch64
>  5/rtems-arm
>  5/rtems-bfin
>  5/rtems-epiphany
>  5/rtems-i386
>  5/rtems-lm32
>  5/rtems-m68k
> -5/rtems-microblaze
>  5/rtems-mips
>  5/rtems-moxie
>  5/rtems-nios2
> diff --git a/rtems/config/5/rtems-microblaze.bset 
> b/rtems/config/5/rtems-microblaze.bset
> deleted file mode 100644
> index e5c23af..000
> --- a/rtems/config/5/rtems-microblaze.bset
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -%define release 1
> -%define rtems_arch microblaze
> -%include 5/rtems-default.bset
> diff --git a/rtems/config/5/rtems-tier-4.bset 
> b/rtems/config/5/rtems-tier-4.bset
> index 24d392d..042f2a0 100644
> --- a/rtems/config/5/rtems-tier-4.bset
> +++ b/rtems/config/5/rtems-tier-4.bset
> @@ -5,6 +5,5 @@
>  # anyone working on adding a BSP.
>  #
>  5/rtems-epiphany
> -5/rtems-microblaze
>  5/rtems-riscv
>  5/rtems-x86_64
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

2023-01-30 Thread Kinsey Moore

This patch resolves a build error with dtc on cygwin until upstream
adopts a fix.
---
 bare/config/devel/dtc-1.6.1-1.cfg | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bare/config/devel/dtc-1.6.1-1.cfg 
b/bare/config/devel/dtc-1.6.1-1.cfg
index 54aed09..acf2cd8 100644
--- a/bare/config/devel/dtc-1.6.1-1.cfg
+++ b/bare/config/devel/dtc-1.6.1-1.cfg
@@ -12,6 +12,9 @@
 
 %hash sha256 dtc-%{dtc_version}.tar.gz 
38a6257f2c23cb9dfa1781ac4ad122d8358e1a22d33b2da0eb492c190644a376
 
+%patch add dtc 
https://devel.rtems.org/raw-attachment/ticket/4783/0001-checks.c-Ensure-argument-is-an-integer-v2.patch
+%hash sha256 0001-checks.c-Ensure-argument-is-an-integer-v2.patch 
dd83c10326188732ac26c1fd8dce70b796a7dde204b31c67cf4d04f29ed4dfef
+
 #
 # The DTC build instructions. We use 1.x.x Release 1.
 #
-- 
2.30.2

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

Re: [RSB 5] Remove aarch64 and microblaze from RSB on 5 branch

2023-01-30 Thread Gedare Bloom

ok

On Mon, Jan 30, 2023 at 7:44 AM Joel Sherrill  wrote:
>
> Closes #4555.
> ---
>  rtems/config/5/rtems-aarch64.bset| 4 
>  rtems/config/5/rtems-all.bset| 2 --
>  rtems/config/5/rtems-microblaze.bset | 3 ---
>  rtems/config/5/rtems-tier-4.bset | 1 -
>  4 files changed, 10 deletions(-)
>  delete mode 100644 rtems/config/5/rtems-aarch64.bset
>  delete mode 100644 rtems/config/5/rtems-microblaze.bset
>
> diff --git a/rtems/config/5/rtems-aarch64.bset 
> b/rtems/config/5/rtems-aarch64.bset
> deleted file mode 100644
> index f38aff3..000
> --- a/rtems/config/5/rtems-aarch64.bset
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -%define release 1
> -%define rtems_arch aarch64
> -%define with_libgomp
> -%include 5/rtems-default.bset
> diff --git a/rtems/config/5/rtems-all.bset b/rtems/config/5/rtems-all.bset
> index 00ccfae..81076e4 100644
> --- a/rtems/config/5/rtems-all.bset
> +++ b/rtems/config/5/rtems-all.bset
> @@ -1,11 +1,9 @@
> -5/rtems-aarch64
>  5/rtems-arm
>  5/rtems-bfin
>  5/rtems-epiphany
>  5/rtems-i386
>  5/rtems-lm32
>  5/rtems-m68k
> -5/rtems-microblaze
>  5/rtems-mips
>  5/rtems-moxie
>  5/rtems-nios2
> diff --git a/rtems/config/5/rtems-microblaze.bset 
> b/rtems/config/5/rtems-microblaze.bset
> deleted file mode 100644
> index e5c23af..000
> --- a/rtems/config/5/rtems-microblaze.bset
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -%define release 1
> -%define rtems_arch microblaze
> -%include 5/rtems-default.bset
> diff --git a/rtems/config/5/rtems-tier-4.bset 
> b/rtems/config/5/rtems-tier-4.bset
> index 24d392d..042f2a0 100644
> --- a/rtems/config/5/rtems-tier-4.bset
> +++ b/rtems/config/5/rtems-tier-4.bset
> @@ -5,6 +5,5 @@
>  # anyone working on adding a BSP.
>  #
>  5/rtems-epiphany
> -5/rtems-microblaze
>  5/rtems-riscv
>  5/rtems-x86_64
> --
> 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 rtems-docs] eng: Add rules for attribution

2023-01-30 Thread Gedare Bloom

On Mon, Jan 30, 2023 at 8:33 AM Sebastian Huber
 wrote:
>
>
>
> On 30.01.23 16:11, Gedare Bloom wrote:
> > Ping. I think we have now some patches and process to use
> > "Sponsored-By: ..." in commit messages. I can't find the guidance in
> > the docs.
>
> These are commits from third-party sources, for example FreeBSD.
>

OK, thanks. And I think just some of the commits from Karel.

I would revive this to see if we can make a resolution.

In academic publishing it is quite common to have something like
"Acknowledgement of Funding Source" -- This is not ambiguous what it
means to "support" or whatever. However it is in academic publishing
an obligation usually to report funding sources (for ethical
considerations).

If the resolution is to prohibit acknowledgements of non-technical
contributions (funding), we should document it.

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

Re: [PATCH 1/3] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

2023-01-30 Thread Karel Gardas


On 1/30/23 16:13, Gedare Bloom wrote:

On Fri, Jan 27, 2023 at 11:41 AM Karel Gardas  wrote:


Sponsored-By:   Precidata
---

No issue with the patch, but I think it is awkward to have this
"Sponsored-By" in an import patch.


Was also thinking about that. Whole work was sponsored including import 
of this code, but code obviously was not.


I'll remove that remark indeed.

Thanks!
Karel

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

Re: [PATCH rtems-docs] eng: Add rules for attribution

2023-01-30 Thread Sebastian Huber




On 30.01.23 16:11, Gedare Bloom wrote:

Ping. I think we have now some patches and process to use
"Sponsored-By: ..." in commit messages. I can't find the guidance in
the docs.


These are commits from third-party sources, for example 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

Re: [PATCH 2/2] bsps/nand: Update Xilinx NAND driver

2023-01-30 Thread Gedare Bloom

ok to these two

On Thu, Jan 26, 2023 at 11:31 AM Kinsey Moore  wrote:
>
> This resovles gcc warnings by updating to the latest Xilinx NAND
> controller driver.
> ---
>  bsps/include/dev/nand/xnandpsu.h  |  4 +++-
>  bsps/include/dev/nand/xnandpsu_bbm.h  |  2 +-
>  bsps/include/dev/nand/xnandpsu_hw.h   |  2 +-
>  bsps/include/dev/nand/xnandpsu_onfi.h |  2 +-
>  bsps/shared/dev/nand/VERSION  | 22 +-
>  bsps/shared/dev/nand/xnandpsu.c   | 14 --
>  bsps/shared/dev/nand/xnandpsu_bbm.c   |  2 +-
>  bsps/shared/dev/nand/xnandpsu_onfi.c  |  2 +-
>  8 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/bsps/include/dev/nand/xnandpsu.h 
> b/bsps/include/dev/nand/xnandpsu.h
> index 3625299fb2..a93a74eb85 100644
> --- a/bsps/include/dev/nand/xnandpsu.h
> +++ b/bsps/include/dev/nand/xnandpsu.h
> @@ -7,7 +7,7 @@
>  /**
>  *
>  * @file xnandpsu.h
> -* @addtogroup nandpsu_v1_10
> +* @addtogroup Overview
>  * @{
>  * @details
>  *
> @@ -152,6 +152,8 @@
>  * 1.10  akm10/20/21Fix gcc warnings.
>  * 1.10  akm12/21/21Validate input parameters before use.
>  * 1.10  akm01/05/22Remove assert checks form static and internal 
> APIs.
> +* 1.11  akm03/31/22Fix unused parameter warning.
> +* 1.11  akm03/31/22Fix misleading-indentation warning.
>  *
>  * 
>  *
> diff --git a/bsps/include/dev/nand/xnandpsu_bbm.h 
> b/bsps/include/dev/nand/xnandpsu_bbm.h
> index 4d4fafffa3..b6b39dc990 100644
> --- a/bsps/include/dev/nand/xnandpsu_bbm.h
> +++ b/bsps/include/dev/nand/xnandpsu_bbm.h
> @@ -7,7 +7,7 @@
>  /**
>  *
>  * @file xnandpsu_bbm.h
> -* @addtogroup nandpsu_v1_10
> +* @addtogroup Overview
>  * @{
>  *
>  * This file implements the Bad Block Management(BBM) functionality. This is
> diff --git a/bsps/include/dev/nand/xnandpsu_hw.h 
> b/bsps/include/dev/nand/xnandpsu_hw.h
> index 47e6c8fddc..e3a648b136 100644
> --- a/bsps/include/dev/nand/xnandpsu_hw.h
> +++ b/bsps/include/dev/nand/xnandpsu_hw.h
> @@ -7,7 +7,7 @@
>  /**
>  *
>  * @file xnandpsu_hw.h
> -* @addtogroup nandpsu_v1_10
> +* @addtogroup Overview
>  * @{
>  *
>  * This file contains identifiers and low-level macros/functions for the 
> Arasan
> diff --git a/bsps/include/dev/nand/xnandpsu_onfi.h 
> b/bsps/include/dev/nand/xnandpsu_onfi.h
> index 7523ff48ea..97ea3c404e 100644
> --- a/bsps/include/dev/nand/xnandpsu_onfi.h
> +++ b/bsps/include/dev/nand/xnandpsu_onfi.h
> @@ -7,7 +7,7 @@
>  /**
>  *
>  * @file xnandpsu_onfi.h
> -* @addtogroup nandpsu_v1_10
> +* @addtogroup Overview
>  * @{
>  *
>  * This file defines all the ONFI 3.1 specific commands and values.
> diff --git a/bsps/shared/dev/nand/VERSION b/bsps/shared/dev/nand/VERSION
> index c0afe6e031..5e4eb00fe9 100644
> --- a/bsps/shared/dev/nand/VERSION
> +++ b/bsps/shared/dev/nand/VERSION
> @@ -5,16 +5,20 @@ Import from:
>
>  https://github.com/Xilinx/embeddedsw.git
>
> -commit 8a89579489c88ea5acd23d7d439ac928659c26cf
> -Author: msreeram 
> -AuthorDate: Wed Apr 6 23:24:38 2022 -0600
> +commit 5330a64c8efd14f0eef09befdbb8d3d738c33ec2
> +Refs: 
> +Author: Nicole Baze 
> +AuthorDate: Mon Oct 3 13:27:19 2022 -0700
>  Commit: Siva Addepalli 
> -CommitDate: Fri Apr 8 16:47:15 2022 +0530
> +CommitDate: Fri Oct 7 10:26:16 2022 +0530
>
> -update license file for EmbeddedSW 2022.1 release
> +xilpm: versal: server: Fix bug in AIE2 zeroization
>
> -Update license file for EmbeddedSW 2022.1 release
> +There is a bug in AIE2 zeriozation function when polling for memory
> +zeroization complete. Currently the entire memory register is being
> +checked against zero but instead we need to check the bits specific
> +to the memory tiles. This patch updates the zeroization check by
> +adding a mask so that only the desired bits are checked for zero.
>
> -Signed-off-by: Manikanta Sreeram 
> -
> -Acked-by : Meena Paleti 
> +Signed-off-by: Nicole Baze 
> +Acked-by: Jesus De Haro 
> diff --git a/bsps/shared/dev/nand/xnandpsu.c b/bsps/shared/dev/nand/xnandpsu.c
> index a2e2235906..89451d19f8 100644
> --- a/bsps/shared/dev/nand/xnandpsu.c
> +++ b/bsps/shared/dev/nand/xnandpsu.c
> @@ -7,7 +7,7 @@
>  /**
>  *
>  * @file xnandpsu.c
> -* @addtogroup nandpsu_v1_10
> +* @addtogroup Overview
>  * @{
>  *
>  * This file contains the implementation of the interface functions for
> @@ -88,6 +88,8 @@
>  * 1.10  akm10/20/21Fix gcc warnings.
>  * 1.10  akm12/21/21Validate input parameters before use.
>  * 1.10  akm01/05/22Remove assert checks form static and internal 
> APIs.
> +* 1.11  akm03/31/22Fix unused parameter warning.
> +* 1.11  akm03/31/22Fix misleading-indentation warning.
>  *
>  * 
>  *
> @@ -175,7 +177,7 @@ static s32 XNandPsu_ProgramPage(XNandPsu *InstancePtr, 
> u32 Target, u32 Page,
>  static s32 XNandPsu_ReadPage(XNandPsu *InstancePtr, u32 Target, u32 Page,
> u32 Col, u8 *Buf);
>
> -static

Re: [PATCH 3/3] bsps/stm32h7: allow config and usage of QSPI memory on stm32h757i-eval BSP

2023-01-30 Thread Gedare Bloom

This looks ok to me, just need to address the import patches

On Fri, Jan 27, 2023 at 11:42 AM Karel Gardas  wrote:
>
> The QSPI memory is initialized and used only when the BSP configure file
> sets QSPI memory size to non-zero value. Currently QSPI is run in memory
> mapped mode which allows future RTEMS binary linkage and upload into QSPI
> memory.
>
> Sponsored-By:   Precidata
> ---
>  .../stm/stm32h757i-eval/stm32h7-bspstarthooks.c | 17 +
>  bsps/arm/stm32h7/include/bsp.h  |  1 +
>  .../bsps/arm/stm32h7/bspstm32h757i-eval.yml |  5 -
>  spec/build/bsps/arm/stm32h7/optmemquadspisz.yml |  5 +
>  4 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git 
> a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c 
> b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
> index 8d34e357ee..1bb81e3b60 100644
> --- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
> +++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
> @@ -36,6 +36,22 @@
>
>  #include 
>
> +#include 
> +static BSP_QSPI_Init_t QSPinit;
> +
> +void stm32h7_init_qspi(void)
> +{
> +#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
> +/* let's initialize Quad SPI memory here for memory mapped mode */
> +/* due to usage of static QSPinit variable please call this function
> +   after bsp_start_clear_bss call since otherwise you would hit 
> uninitialized
> +   variable memory while accessing it and in addition the call to 
> bsp_start_clear_bss
> +   would wipe the variable content later after its initialization here. 
> */
> +BSP_QSPI_Init(0, );
> +BSP_QSPI_EnableMemoryMappedMode(0);
> +#endif
> +}
> +
>  void bsp_start_hook_0(void)
>  {
>if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
> @@ -75,4 +91,5 @@ void bsp_start_hook_1(void)
>SCB_InvalidateICache();
>  #endif
>bsp_start_clear_bss();
> +  stm32h7_init_qspi();
>  }
> diff --git a/bsps/arm/stm32h7/include/bsp.h b/bsps/arm/stm32h7/include/bsp.h
> index 08311bf51e..cd4d25c069 100644
> --- a/bsps/arm/stm32h7/include/bsp.h
> +++ b/bsps/arm/stm32h7/include/bsp.h
> @@ -62,6 +62,7 @@ void stm32h7_init_power(void);
>  void stm32h7_init_oscillator(void);
>  void stm32h7_init_clocks(void);
>  void stm32h7_init_peripheral_clocks(void);
> +void stm32h7_init_qspi(void);
>
>  /** @} */
>
> diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml 
> b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
> index 5d7ee1348d..7516e55a3f 100644
> --- a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
> +++ b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
> @@ -8,7 +8,8 @@ copyrights:
>  cppflags: []
>  enabled-by: true
>  family: stm32h7
> -includes: []
> +includes:
> +- bsps/arm/stm32h7/boards/stm/stm32h757i-eval
>  install: []
>  links:
>  - role: build-dependency
> @@ -16,6 +17,8 @@ links:
>  - role: build-dependency
>uid: tststm32h757i-eval
>  source:
> +- bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
> +- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
>  - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
>  - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-clk.c
>  - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-osc.c
> diff --git a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml 
> b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
> index 82c48c7683..f4e39d979b 100644
> --- a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
> +++ b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
> @@ -2,10 +2,15 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
>  - get-integer: null
>  - env-assign: null
> +- define-unquoted: null
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>  default:
> +- enabled-by:
> +  - arm/stm32h757i-eval
> +  - arm/stm32h757i-eval-m4
> +  value: 0x0800
>  - enabled-by: true
>value: 0x
>  description: |
> --
> 2.25.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 1/3] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

2023-01-30 Thread Gedare Bloom

On Fri, Jan 27, 2023 at 11:41 AM Karel Gardas  wrote:
>
> Sponsored-By:   Precidata
> ---
No issue with the patch, but I think it is awkward to have this
"Sponsored-By" in an import patch.

>  .../stm/Components/mt25tl01g/mt25tl01g.c  | 1046 +
>  .../stm/Components/mt25tl01g/mt25tl01g.h  |  362 ++
>  .../stm/Components/mt25tl01g/mt25tl01g_conf.h |   68 ++
>  3 files changed, 1476 insertions(+)
>  create mode 100644 
> bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
>  create mode 100644 
> bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.h
>  create mode 100644 
> bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g_conf.h
>
> diff --git a/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c 
> b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
> new file mode 100644
> index 00..740cdbbd27
> --- /dev/null
> +++ b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
> @@ -0,0 +1,1046 @@
> +/* SPDX-License-Identifier: BSD-3-Clause */
> +/**
> +  
> **
> +  * @fileMT25TL01G.c
> +  * @author  MCD Application Team
> +  * @brief   This file provides the MT25TL01G QSPI driver.
> +  
> **
> +  * @attention
> +  *
> +  *  Copyright (c) 2016 STMicroelectronics.
> +  * All rights reserved.
> +  *
> +  * This software component is licensed by ST under BSD 3-Clause license,
> +  * the "License"; You may not use this file except in compliance with the
> +  * License. You may obtain a copy of the License at:
> +  *opensource.org/licenses/BSD-3-Clause
> +  *
> +  
> **
> +  */
> +/* Includes 
> --*/
> +#include "mt25tl01g.h"
> +/** @addtogroup BSP
> +  * @{
> +  */
> +
> +/** @addtogroup Components
> +  * @{
> +  */
> +
> +/** @addtogroup MT25TL01G
> +  * @brief This file provides a set of functions needed to drive the
> +  * MT25TL01G QSPI memory.
> +  * @{
> +  */
> +/** @defgroup MT25TL01G_Exported_Functions MT25TL01G Exported Functions
> +  * @{
> +  */
> +
> +/**
> +  * @brief  Return the configuration of the QSPI memory.
> +  * @param  pInfo pointer on the configuration structure
> +  * @retval QSPI memory status
> +  */
> +int32_t MT25TL01G_GetFlashInfo(MT25TL01G_Info_t *pInfo)
> +{
> +  pInfo->FlashSize  = MT25TL01G_FLASH_SIZE;
> +  pInfo->EraseSectorSize= (2 * MT25TL01G_SUBSECTOR_SIZE);
> +  pInfo->ProgPageSize   = MT25TL01G_PAGE_SIZE;
> +  pInfo->EraseSectorsNumber = (MT25TL01G_FLASH_SIZE/pInfo->EraseSectorSize);
> +  pInfo->ProgPagesNumber= (MT25TL01G_FLASH_SIZE/pInfo->ProgPageSize);
> +  return MT25TL01G_OK;
> +}
> +
> +/**
> +  * @brief  This function set the QSPI memory in 4-byte address mode
> +  *  SPI/QPI; 1-0-1/4-0-4
> +  * @param  Ctx Component object pointer
> +  * @param  Mode Interface mode
> +  * @retval QSPI memory status
> +  */
> +int32_t MT25TL01G_Enter4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
> MT25TL01G_Interface_t Mode)
> +{
> +  QSPI_CommandTypeDef s_command;
> +
> +  /* Initialize the command */
> +  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
> QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
> +  s_command.Instruction   = MT25TL01G_ENTER_4_BYTE_ADDR_MODE_CMD;
> +  s_command.AddressMode   = QSPI_ADDRESS_NONE;
> +  s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
> +  s_command.DataMode  = QSPI_DATA_NONE;
> +  s_command.DummyCycles   = 0;
> +  s_command.DdrMode   = QSPI_DDR_MODE_DISABLE;
> +  s_command.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
> +  s_command.SIOOMode  = QSPI_SIOO_INST_EVERY_CMD;
> +
> +  /*write enable */
> +  if( MT25TL01G_WriteEnable(Ctx,Mode)!=MT25TL01G_OK)
> +  {
> +return MT25TL01G_ERROR_COMMAND;
> +  }
> +  /* Send the command */
> +  if (HAL_QSPI_Command(Ctx, _command, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != 
> HAL_OK)
> +  {
> +return MT25TL01G_ERROR_COMMAND;
> +  }
> +
> +  /* Configure automatic polling mode to wait the memory is ready */
> +  else if(MT25TL01G_AutoPollingMemReady(Ctx,Mode)!=MT25TL01G_OK)
> +  {
> +return MT25TL01G_ERROR_COMMAND;
> +  }
> +
> +  return MT25TL01G_OK;
> +}
> +
> +/**
> +  * @brief  Flash exit 4 Byte address mode. Effect 3/4 address byte commands 
> only.
> +  * SPI/QPI; 1-0-0/4-0-0
> +  * @param  Ctx Component object pointer
> +  * @param  Mode Interface mode
> +  * @retval QSPI memory status
> +  */
> +int32_t MT25TL01G_Exit4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
> MT25TL01G_Interface_t Mode)
> +{
> +  QSPI_CommandTypeDef s_command;
> +
> +  /* Initialize the command */
> +  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
> QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
> +

Re: [PATCH rtems-docs] eng: Add rules for attribution

2023-01-30 Thread Gedare Bloom

On Fri, Oct 1, 2021 at 6:11 PM Chris Johns  wrote:
>
> On 30/9/21 4:55 pm, Christian MAUDERER wrote:
> > Am 30.09.21 um 02:23 schrieb Chris Johns:
> >> On 29/9/21 6:38 pm, Christian MAUDERER wrote:
> >>> Am 29.09.21 um 02:40 schrieb Chris Johns:
>  On 28/9/21 11:11 pm, Christian MAUDERER wrote:
> > Hello Joel,
> >
> > Am 28.09.21 um 14:48 schrieb Joel Sherrill:
> >>
> >>
> >> On Tue, Sep 28, 2021, 1:40 AM Christian MAUDERER
> >>  >> > wrote:
> >>
> >>   Hello Joel,
> >>
> >>   Am 28.09.21 um 01:12 schrieb Joel Sherrill:
> >>> The Microblaze port is interesting for attribution. I did 
> >> initial
> >>   work
> >>> on it. Hesham added to that and got Hello on a board. Alex is
> >>   close to
> >>> submitting the port in a nice state.
> >>>
> >>> This is almost seven years across three developers.. The 
> >> original
> >>   work
> >>> predates source code reorganisation. Alex deleted the autoconf
> >>   support
> >>> and created waf. Hesham and I agreed to convert to BSD-2.
> >>>
> >>> When submitted, we decided it was best for Alex to submit a 
> >> Joel
> >>   patch,
> >>> then Hesham, then Alex to finish it off. This keeps git blame
> >>   working.
> >>>
> >>> Not quite the same topic but related to credit due.
> >>
> >>   But maybe an important extension. Should we replace "sponsored" 
> >> with
> >>   "sponsored or supported"? That would allow to mention anyone who 
> >> helps
> >>   in any way, regardless whether it's financial, with information, 
> >> with
> >>   hobby time or with whatever else.
> >>
> >>
> >> I usually use the word sponsored. Support implies commercial 
> >> activities the
> >> way I/we tend to use it.
> >>
> >
> > Seems that I picked the wrong word then. Maybe you can help me finding 
> > the
> > correct term:
> >
> > The one case is clear: Someone pays that someone else develops for 
> > example a
> > driver. I think for that "sponsored" is a good term.
> >
> > Another similar case could be the following: You get help with writing a
> > driver
> > for example with information or some other form of help that doesn't 
> > result
> > in a
> > copyright for that person or company. It doesn't involve money or some 
> > other
> > form of payment (T-shirts, pizza, ...) so it's not really sponsoring. 
> > Despite
> > that it might would be nice to mention them if they want to be 
> > mentioned. I
> > think the right location would be the same place like the one we just 
> > discuss
> > for sponsoring. What would be a good term for that?
> 
>  I think we should take baby steps with this.
> >>>
> >>> OK. I'll concentrate only on the case where some work is really sponsored 
> >>> with
> >>> money. I think a lot of work on RTEMS falls in that category. Most of the 
> >>> times
> >>> the sponsors don't want to appear with a name but in my case that caused 
> >>> this
> >>> discussion they do.
> >>
> >> I appreciate the customer may want this however my role is to ensure the 
> >> process
> >> makes sense for the whole community. I am still not sure.
> >>
> >
> > I fully agree that you should discuss it from a community point of view 
> > here. I
> > can't take that role in this discussion.
> >
> >> It will be your customer's decision to have the changes merged and for the 
> >> repo
> >> to absorb them and maintain them. They always have the right to hold on to 
> >> the
> >> changes and maintain them if they do not agree with the outcome of this 
> >> process.
> >>
> >
> > Of course.
> >
>  I have some reservation on where
>  this could go and the long term effects. If too widely spread and 
>  embedded in
>  the source it could be difficult to remove or change if we find an issue 
>  in
>  doing this.
> 
> >>>
> >>> Understood.
> >>>
>  In a private chat on the subject Gedare suggested a "Supporters" file? 
>  This
>  could list those who have provided support and wish to be listed. I am 
>  avoiding
>  sponsorship and other words here on purpose for now. I have no idea what 
>  works
>  legally around the world.
> >>>
> >>> To be honest: If sponsored work is a legal problem, we have that with or 
> >>> without
> >>> a note in the files. It's only more visible with a note in the files. I 
> >>> don't
> >>> think that a legal problem would be avoidable just by not mentioning it.
> >>
> >> That is not the legal aspect I have in mind. There exists constraints about
> >> payments for work done in relation to tax law and this varies around the 
> >> world.
> >> A

Re: [PATCH rtems] grlib: Fix snprintf() overflow warnings from gcc 12

2023-01-30 Thread Gedare Bloom

This is OK. Not ideal, but consistent with the current code at least.

The commit message is a bit wrong since it also fixes sprintf() messages.

We should probably replace the sprintf with snprintf especially where
there is a string being used (prefix). The prefix is usually (always?)
32 byte array, so it shouldn't ever be a problem (the compiler will
again complain).

On Fri, Jan 27, 2023 at 4:56 PM Joel Sherrill  wrote:
>
> Updates #4662.
> ---
>  bsps/include/grlib/gpiolib.h   | 2 +-
>  bsps/shared/grlib/1553/b1553brm.c  | 2 +-
>  bsps/shared/grlib/1553/b1553rt.c   | 2 +-
>  bsps/shared/grlib/analog/gradcdac.c| 2 +-
>  bsps/shared/grlib/can/grcan_internal.h | 2 +-
>  bsps/shared/grlib/can/occan.c  | 2 +-
>  bsps/shared/grlib/gpio/grgpio.c| 4 ++--
>  bsps/shared/grlib/i2c/i2cmst.c | 2 +-
>  bsps/shared/grlib/pwm/grpwm.c  | 2 +-
>  bsps/shared/grlib/spi/spictrl.c| 2 +-
>  bsps/shared/grlib/spw/grspw.c  | 2 +-
>  bsps/shared/grlib/tmtc/grtc.c  | 2 +-
>  bsps/shared/grlib/tmtc/grtm.c  | 2 +-
>  bsps/shared/grlib/uart/apbuart_cons.c  | 2 +-
>  14 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/bsps/include/grlib/gpiolib.h b/bsps/include/grlib/gpiolib.h
> index 61f6fc9..c0f865f 100644
> --- a/bsps/include/grlib/gpiolib.h
> +++ b/bsps/include/grlib/gpiolib.h
> @@ -78,7 +78,7 @@ extern int gpiolib_irq_register(void *handle, void *func, 
> void *arg);
>  /*** Driver Interface ***/
>
>  struct gpiolib_info {
> -   chardevName[64];
> +   chardevName[80];
>  };
>
>  struct gpiolib_drv_ops {
> diff --git a/bsps/shared/grlib/1553/b1553brm.c 
> b/bsps/shared/grlib/1553/b1553brm.c
> index ee5f9fb..7e0b992 100644
> --- a/bsps/shared/grlib/1553/b1553brm.c
> +++ b/bsps/shared/grlib/1553/b1553brm.c
> @@ -119,7 +119,7 @@ struct irq_log_list {
>  typedef struct {
>
> struct drvmgr_dev *dev; /* Driver manager device */
> -   char devName[32]; /* Device Name */
> +   char devName[52]; /* Device Name */
> struct brm_reg *regs;
>
> unsigned int memarea_base;
> diff --git a/bsps/shared/grlib/1553/b1553rt.c 
> b/bsps/shared/grlib/1553/b1553rt.c
> index 43bbeaa..7a4e2535 100644
> --- a/bsps/shared/grlib/1553/b1553rt.c
> +++ b/bsps/shared/grlib/1553/b1553rt.c
> @@ -87,7 +87,7 @@ static rtems_driver_address_table b1553rt_driver = 
> RT_DRIVER_TABLE_ENTRY;
>  typedef struct {
>
>  struct drvmgr_dev *dev; /* Driver manager device */
> -char devName[32]; /* Device Name */
> +char devName[52];   /* Device Name */
>
>  struct rt_reg *regs;
>  unsigned int ctrl_copy; /* Local copy of config register */
> diff --git a/bsps/shared/grlib/analog/gradcdac.c 
> b/bsps/shared/grlib/analog/gradcdac.c
> index 3b1afa8..09f8760 100644
> --- a/bsps/shared/grlib/analog/gradcdac.c
> +++ b/bsps/shared/grlib/analog/gradcdac.c
> @@ -53,7 +53,7 @@
>  struct gradcdac_priv {
> struct gradcdac_regs *regs; /* Must be first */
> struct drvmgr_dev *dev;
> -   char devName[48];
> +   char devName[54];   /* Must be at least 48 per names */
>
> unsigned int freq;
> int irqno;
> diff --git a/bsps/shared/grlib/can/grcan_internal.h 
> b/bsps/shared/grlib/can/grcan_internal.h
> index 16aabba..d27476a 100644
> --- a/bsps/shared/grlib/can/grcan_internal.h
> +++ b/bsps/shared/grlib/can/grcan_internal.h
> @@ -56,7 +56,7 @@ struct grcan_config {
>
>  struct grcan_priv {
> struct drvmgr_dev *dev; /* Driver manager device */
> -   char devName[32];   /* Device Name */
> +   char devName[52];   /* Device Name */
> unsigned int baseaddr, ram_base;
> struct grcan_regs *regs;
> int irq;
> diff --git a/bsps/shared/grlib/can/occan.c b/bsps/shared/grlib/can/occan.c
> index 51ffd07..a6b37ec 100644
> --- a/bsps/shared/grlib/can/occan.c
> +++ b/bsps/shared/grlib/can/occan.c
> @@ -226,7 +226,7 @@ typedef struct {
>
>  typedef struct {
> struct drvmgr_dev *dev;
> -   char devName[32];
> +   char devName[52];
> SPIN_DECLARE(devlock);
>
> /* hardware shortcuts */
> diff --git a/bsps/shared/grlib/gpio/grgpio.c b/bsps/shared/grlib/gpio/grgpio.c
> index d579432..711293d 100644
> --- a/bsps/shared/grlib/gpio/grgpio.c
> +++ b/bsps/shared/grlib/gpio/grgpio.c
> @@ -379,12 +379,12 @@ static int grgpio_gpiolib_get_info(void *handle, struct 
> gpiolib_info *pinfo)
> /* Failed to get prefix, make sure of a unique FS name
>  * by using the driver minor.
>  */
> -   snprintf(pinfo->devName, 64, "/dev/grgpio%d/%d", 
> dev->minor_drv, portnr);
> +   snprintf(pinfo->devName, 80, "/dev/grgpio%d/%d", 
> dev->minor_drv, portnr);
> } else {
> /* Got special prefix, this means we have a bus prefix
>  * And we should use our "bus minor"
>  */
> -

[RSB 5] Remove aarch64 and microblaze from RSB on 5 branch

2023-01-30 Thread Joel Sherrill

Closes #4555.
---
 rtems/config/5/rtems-aarch64.bset| 4 
 rtems/config/5/rtems-all.bset| 2 --
 rtems/config/5/rtems-microblaze.bset | 3 ---
 rtems/config/5/rtems-tier-4.bset | 1 -
 4 files changed, 10 deletions(-)
 delete mode 100644 rtems/config/5/rtems-aarch64.bset
 delete mode 100644 rtems/config/5/rtems-microblaze.bset

diff --git a/rtems/config/5/rtems-aarch64.bset 
b/rtems/config/5/rtems-aarch64.bset
deleted file mode 100644
index f38aff3..000
--- a/rtems/config/5/rtems-aarch64.bset
+++ /dev/null
@@ -1,4 +0,0 @@
-%define release 1
-%define rtems_arch aarch64
-%define with_libgomp
-%include 5/rtems-default.bset
diff --git a/rtems/config/5/rtems-all.bset b/rtems/config/5/rtems-all.bset
index 00ccfae..81076e4 100644
--- a/rtems/config/5/rtems-all.bset
+++ b/rtems/config/5/rtems-all.bset
@@ -1,11 +1,9 @@
-5/rtems-aarch64
 5/rtems-arm
 5/rtems-bfin
 5/rtems-epiphany
 5/rtems-i386
 5/rtems-lm32
 5/rtems-m68k
-5/rtems-microblaze
 5/rtems-mips
 5/rtems-moxie
 5/rtems-nios2
diff --git a/rtems/config/5/rtems-microblaze.bset 
b/rtems/config/5/rtems-microblaze.bset
deleted file mode 100644
index e5c23af..000
--- a/rtems/config/5/rtems-microblaze.bset
+++ /dev/null
@@ -1,3 +0,0 @@
-%define release 1
-%define rtems_arch microblaze
-%include 5/rtems-default.bset
diff --git a/rtems/config/5/rtems-tier-4.bset b/rtems/config/5/rtems-tier-4.bset
index 24d392d..042f2a0 100644
--- a/rtems/config/5/rtems-tier-4.bset
+++ b/rtems/config/5/rtems-tier-4.bset
@@ -5,6 +5,5 @@
 # anyone working on adding a BSP.
 #
 5/rtems-epiphany
-5/rtems-microblaze
 5/rtems-riscv
 5/rtems-x86_64
-- 
1.8.3.1

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

RTEMS Filesystem check

2023-01-30 Thread Cedric Berger


Hello,

I'm looking at the filesystem options for RTEMS (on top of a 4GB eMMC 
chip), but I need something that behaves properly in case of a sudden 
power loss.


I probably missed something, but:

Regarding RFS, I found this: 
https://lists.rtems.org/pipermail/users/2013-December/060969.html


is there anything more recent info?

What the status of the FAT32 filesystem? does it survive a power loss? 
is there a fsck that needs to run?


Thanks,

Cedric


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

GitLab and BuildBot

2023-01-30 Thread Christian MAUDERER


Hello,

recently the following tickets were added (beneath a few more related ones):

https://devel.rtems.org/ticket/4790 - Setup Gitlab instance
https://devel.rtems.org/ticket/4791 - Update BuildBot

It's great that a patch review system and a CI/CD that builds every 
patch for RTEMS starts to get within reach. Thanks a lot to all involved 
in that for the efforts.


I reviewed earlier discussions related to CI/CD. From my point of view 
there are mainly two points that are missing in the tickets:


First: From my point of view, we should make it simple for new users to 
register. Adding authentication using well-known services can help with 
that. GitLab supports (for example):

  - GitHub: https://docs.gitlab.com/ee/integration/github.html
  - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html
  - Google: https://docs.gitlab.com/ee/integration/google.html
  - ...
I think it would be good to select the most common ones (at least the 
three mentioned above) and add them as a goal to the ticket or a new 
one. What do you think?


Second: It's still a bit unclear for me how the CI/CD with BuildBot will 
work. Will it be possible for anyone to help improve the CI/CD? An 
example to make it clear what I want to know: Let's assume an 
unprivileged developer has a patch set that allows building device tree 
files using the RTEMS build system, but the patches require a new tool 
like dtc. Let's further assume that the idea has been discussed and 
everyone agrees that it is a good idea (currently not yet the case for 
dtc). Problem is: The patches trigger a CI error because the new tool is 
missing and therefore can't be merged yet. How can the developer suggest 
a fix so that the patches can be accepted faster without having to wait 
for one specific maintainer to have enough time for adapting the CI config?


Best regards

Christian
--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.maude...@embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 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: Question w.r.t. crash inside select call from libbsd.

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

Re: [PATCH rtems-source-builder] devel/gnu-default-tools: Use correct include path

Re: [PATCH rtems-source-builder] Update hashes for github-sourced tarballs

[PATCH rtems-source-builder] devel/gnu-default-tools: Use correct include path

[PATCH rtems-source-builder] Update hashes for github-sourced tarballs

Question w.r.t. crash inside select call from libbsd.

Re: [RSB 5] Remove aarch64 and microblaze from RSB on 5 branch

[PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

Re: [RSB 5] Remove aarch64 and microblaze from RSB on 5 branch

Re: [PATCH rtems-docs] eng: Add rules for attribution

Re: [PATCH 1/3] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

Re: [PATCH rtems-docs] eng: Add rules for attribution

Re: [PATCH 2/2] bsps/nand: Update Xilinx NAND driver

Re: [PATCH 3/3] bsps/stm32h7: allow config and usage of QSPI memory on stm32h757i-eval BSP

Re: [PATCH 1/3] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

Re: [PATCH rtems-docs] eng: Add rules for attribution

Re: [PATCH rtems] grlib: Fix snprintf() overflow warnings from gcc 12

[RSB 5] Remove aarch64 and microblaze from RSB on 5 branch

RTEMS Filesystem check

GitLab and BuildBot

24 matches

Site Navigation

Mail list logo

Footer information