Re: Heavy SysInit Dependency

[Chris Johns]

> On 19 May 2021, at 5:28 pm, Sebastian Huber 
>  wrote:
> 
> I am not sure how the dependency chain can be fixed with the current struct 
> _reent approach of Newlib. A modern approach would be to replace this 
> structure with individual thread-local objects. This would be technically 
> feasible, however, a lot of work.

Do you mean the _reent structure is expanded out into separate TLS elements?

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

Re: question about posix timer expiration

[Chris Johns]

> On 18 May 2021, at 10:02 pm, gabriel.moy...@dlr.de wrote:
> 
> 
> From further investigation I’ve found that when a timer expires, 
> _POSIX_Timer_TSR() is called and this uses pthread_kill() to send a signal. 
> Shouldn’t ptimer->inf.sigev_value be used here in order to create a siginfo_t 
> object with the right value?
>  
> Did anyone have to deal with this while using posix timers?
>  
> Thanks!
>  
> Von: devel  Im Auftrag von gabriel.moy...@dlr.de
> Gesendet: Mittwoch, 12. Mai 2021 14:37
> An: devel@rtems.org
> Betreff: question about posix timer expiration
>  
> Hello everyone,
>  
> Currently I am trying to get running ptpd on rtems (following the Chris’ 
> work, thx btw).
> Ptpd uses posix timers and when a timer expires a handler with this signature 
> void(int sig, siginfo_t *info, void *ucontext) is called.

Is this on libbsd? If it is I would have expected kqueue being used so I am not 
sure where this is happening. 

Chris

>  Unfortunately (*info) doesn’t have the right values, eg. info->si_code 
> should be SI_TIMER but it is SI_USER and also info->si_signo should be the 
> same as sig but it’s not.
>  
> Diving into the code I’ve found where the handler is called (also where *info 
> is created). This is done in the function _POSIX_signals_Check_signal() in 
> the file psignalunblockthread.c. It doesn’t seems that info is updated with 
> the values (I guess) should take from object ptimer, which was created by 
> create_timer().
>  
> My question is: is this handler fully supported? Or maybe I’m missing 
> something else.
>  
> Thanks in advance,
> Gabriel
>  
> ——
> Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
> Institute for Software Technology | SC-OSS | Lilienthalplatz 7 | 38108 
> Braunschweig  | Germany
>  
> Gabriel Moyano | Research Scientist in Onboard Software Systems group
> gabriel.moy...@dlr.de
> DLR.de
>  
> ___
> 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: Heavy SysInit Dependency

[Sebastian Huber]

On 19/05/2021 10:23, Chris Johns wrote:

On 19 May 2021, at 5:28 pm, Sebastian Huber 
 wrote:

I am not sure how the dependency chain can be fixed with the current struct 
_reent approach of Newlib. A modern approach would be to replace this structure 
with individual thread-local objects. This would be technically feasible, 
however, a lot of work.

Do you mean the _reent structure is expanded out into separate TLS elements?


Yes, something like:

thread_local int errno;

--
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] riscv/console: console-config.c update

[Hesham Almatary]

Hello Somesh,

This patch will break other existing BSPs that don't have
"stdout-path" (in your case serial@x) node part of "/soc" node.
You can either 1) Modify your DTS to have /serial node outside /soc,
or 2) Add a new config for your BSP such as
RISCV_ENABLE_FRDME310ARTY_SUPPORT and use it instead. I am not sure if
 DTS allows having something like /soc/serial@ in the stdout-path.

On Tue, 18 May 2021 at 20:43, Sebastian Huber
 wrote:
>
> On 05/05/2021 19:55, Somesh Deshmukh wrote:
> > - Parsing the sub-node should be available generic not specific to Freedom
> >Arty310 board. If we remove the Freedom Arty macro now, it will lose
> >backward compatibility.The proposed change will retain the backward
> >compatibility and also adds the necessary fix for parsing sub-node.
> > ---
> >   bsps/riscv/riscv/console/console-config.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/bsps/riscv/riscv/console/console-config.c 
> > b/bsps/riscv/riscv/console/console-config.c
> > index d962a5a418..797506a31b 100644
> > --- a/bsps/riscv/riscv/console/console-config.c
> > +++ b/bsps/riscv/riscv/console/console-config.c
> > @@ -91,7 +91,7 @@ static int riscv_get_console_node(const void *fdt)
> >   stdout_path = "";
> > }
> >
> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> > +#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) || 
> > (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
> > int root;
> > int soc;
> > root = fdt_path_offset(fdt, "/");
>
> What is the purpose of this subnode stuff here:
>
> static int riscv_get_console_node(const void *fdt)
> {
>const char *stdout_path;
>int node;
>
>node = fdt_path_offset(fdt, "/chosen");
>
>stdout_path = fdt_getprop(fdt, node, "stdout-path", NULL);
>if (stdout_path == NULL) {
>  stdout_path = "";
>}
>
> #if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) ||
> (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
>int root;
>int soc;
>root = fdt_path_offset(fdt, "/");
>soc = fdt_subnode_offset(fdt, root, "soc");
>
>int offset=fdt_subnode_offset(fdt, soc,stdout_path);
>
>return offset;
> #else
>return fdt_path_offset(fdt, stdout_path);
> #endif
> }
>
> What is the value of stdout_path in your setup? Can you show the
> relevant parts of the device tree sources?
>
> --
> 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

Re: Heavy SysInit Dependency

[Joel Sherrill]

On Wed, May 19, 2021 at 3:54 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19/05/2021 10:23, Chris Johns wrote:
> >> On 19 May 2021, at 5:28 pm, Sebastian Huber<
> sebastian.hu...@embedded-brains.de>  wrote:
> >>
> >> I am not sure how the dependency chain can be fixed with the current
> struct _reent approach of Newlib. A modern approach would be to replace
> this structure with individual thread-local objects. This would be
> technically feasible, however, a lot of work.
> > Do you mean the _reent structure is expanded out into separate TLS
> elements?
>
> Yes, something like:
>
> thread_local int errno;
>

On paper this would work but most architectures do not have TLS
support from RTEMS right now. On top of that, I honestly can't tell
in GCC how TLS is implemented on many architectures. If there is
a generic pattern, I'd be happy to be educated?

FWIW I looked into the MIPS and it uses a specific invalid instruction
as the TLS "get function". Personally, I'd prefer a way to tell GCC to
just call a real subroutine and avoid architecture specific magic unless
it is going to use a register. And document it.



> --
> 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] rtems-bsp-builder: Change to waf build system

[Ryan Long]

Closes #4124
---
 config/rtems-bsps.ini | 28 ++--
 tester/rt/check.py| 35 ++-
 2 files changed, 40 insertions(+), 23 deletions(-)

diff --git a/config/rtems-bsps.ini b/config/rtems-bsps.ini
index 93156fb..d5de667 100644
--- a/config/rtems-bsps.ini
+++ b/config/rtems-bsps.ini
@@ -156,23 +156,23 @@ smp-network-debug = config:base, config:smp, 
config:network, config:debug
 #
 # Base set of configure options every build needs.
 #
-base = --target=@ARCH@-rtems@RTEMS_VERSION@
-   --enable-rtemsbsp=@BSP@
-   --prefix=@PREFIX@
+base = --prefix=@PREFIX@
+   --top=@RTEMS@
+   --rtems-config=config-@ARCH@-@BSP@-@BUILD@.ini
 #
 # Tests.
 #
-tests = --enable-tests
+tests = BUILD_TESTS=True
 #
 # The options for each varations.
 #
-debug = --enable-rtems-debug
-no-debug  = --disable-rtems-debug
-profiling = --enable-profiling
-no-profiling  = --disable-profiling
-smp   = --enable-smp
-no-smp= --disable-smp
-posix = --enable-posix
-no-posix  = --disable-posix
-network   = --enable-networking
-no-network= --disable-networking
+debug = RTEMS_DEBUG=True
+no-debug  = RTEMS_DEBUG=False
+profiling = RTEMS_PROFILING=True
+no-profiling  = RTEMS_PROFILING=False
+smp   = RTEMS_SMP=True
+no-smp= RTEMS_SMP=False
+posix = RTEMS_POSIX_API=True
+no-posix  = RTEMS_POSIX_API=False
+network   = RTEMS_NETWORKING=True
+no-network= RTEMS_NETWORKING=False
diff --git a/tester/rt/check.py b/tester/rt/check.py
index 2a38d99..95fa47e 100755
--- a/tester/rt/check.py
+++ b/tester/rt/check.py
@@ -906,7 +906,9 @@ class build_jobs:
 remove += [b for b in self.builds if e in b.split('-')]
 self.builds = [b for b in self.builds if b not in remove]
 self.build_set = { }
-exclude_options = ' ' + config.exclude_options(self.arch, self.bsp)
+exclude_options = config.exclude_options(self.arch, self.bsp)
+if exclude_options != '':
+exclude_options = ' ' + exclude_options
 for build in self.builds:
 self.build_set[build] = config.build_options(build) + 
exclude_options
 
@@ -938,9 +940,7 @@ class builder:
  'BSP' : '.*libbsp/.*',
  'LibCPU'  : '.*libcpu/.*',
  'Shared'  : '.*shared/.*' })
-if not path.exists(path.join(rtems, 'configure')) or \
-   not path.exists(path.join(rtems, 'Makefile.in')) or \
-   not path.exists(path.join(rtems, 'cpukit')):
+if not path.exists(path.join(rtems, 'waf')):
 raise error.general('RTEMS source path does not look like RTEMS')
 
 def _bsps(self, arch):
@@ -952,15 +952,30 @@ class builder:
 job_index = 1
 for job in jobs:
 tag = '%*d/%d' % (max_job_size, job_index, len(jobs))
+commands = self._commands(job, build_job_count)
+self._create_config(job, commands)
 build_jobs += [arch_bsp_builder(self.results,
 job,
-self._commands(job, 
build_job_count),
+commands,
 self.build_dir,
 tag)]
 job_index += 1
 set_max_build_label(build_jobs)
 return build_jobs
 
+def _create_config(self, job, commands):
+filename = 'config-%s-%s-%s.ini' % (job.arch, job.bsp, job.build)
+cfg_file = open(path.join(self.rtems, filename),'w+')
+cfg_file.write('[%s/%s]' + os.linsep() % (job.arch, job.bsp))
+new_cfg_cmds = []
+for option in commands['configure'].split():
+if 'waf' in option or '--' in option or 'configure' in option:
+new_cfg_cmds += [option]
+else:
+cfg_file.write(option + os.linesep())
+commands['configure'] = ' '.join(new_cfg_cmds)
+cfg_file.close()
+
 def _commands(self, build, build_jobs):
 commands = { 'dry-run'  : self.options['dry-run'],
  'no-clean' : self.options['no-clean'],
@@ -968,16 +983,18 @@ class builder:
  'build': None }
 cmds = build.build_config.split()
 cmds += self.config.bspopts(build.arch, build.bsp)
-cmd = [path.join(self.rtems, 'configure')]
+cmd = [path.join(self.rtems, 'waf') + ' configure']
 for c in cmds:
 c = c.replace('@PREFIX@', self.prefix)
-c = c.replace('@RTEMS_VERSION@', str(self.rtems_version))
 c = c.replace('@ARCH@', build.arch)
 c = c.replace('@BSP@', build.bsp)
+c = c.replace('@RTEMS@', self.rtems)
+c = c.replace('@BUILD@', build.bui

Re: Heavy SysInit Dependency

[Joel Sherrill]

On Wed, May 19, 2021 at 12:27 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 18/05/2021 23:40, Joel Sherrill wrote:
> > Hi
> >
> > In working with Alex to reduce the minimum on his new BSP, we noticed
> > that it is easy for a BSP to accidentally trip up and end up with a
> > minimum.exe that is as much as 2x over what it should be. I have looked
> > at a few BSPs and seen a handful of issues so far. I have patches
> > pending for some. This particular issue I think indicates a dependency
> > path that is too heavy. I spotted this on powerpc/psim and likely
> > impacts a number of BSPs. I made two minor changes reduced the size of
> > minimum.exe as shown below
> >
> >   textdata bss dec hex filename
> >66616   11848 268356980 268435444 ff4 minimum.exe
> >450645884 268384476 268435424 fe0 minimum.exe
> >
> > FWIW That 45K is larger than the ARM or MIPS BSPs I looked at but seems
> > reasonable due to all the PPC helper and IRQ code pulled in.
> >
> > psim  does two things that the arm and mips BSPs I looked at do not. It
> > uses the powerpc shared sbrk.c and it calls malloc() from its
> > irq_init.c. malloc() and sbrk() set errno. Commenting out setting errno
> > in those two methods is what resulted in 21.5K text and 6K data saved.
>
> we have an rtems_malloc() and rtems_calloc() which do not set errno.
>

OK. This and not setting errno in the PPC sbrk() are sufficient to break
this
particular chain.

This means that BSPs and device drivers need to be careful not to call
malloc().


>
> >
> > I think setting errno doesn't directly add this much code but the
> > sysinit dependency chain it trips ends up pulling in getreent,
> > rtems_libio_init, rtems_libio_post_driver (opening /dev/console), open,
> > atexit(), close(), rtems_filesystem_do_unmount() and a host of other
> > things. I am not sure of the exact order of the chain but that's the end
> > result.I do think it starts with getreent though.
>
> Yes, if you use __getreent() with
>
> #define CONFIGURE_DISABLE_NEWLIB_REENTRANCY
>
> then a lot of stuff is pulled in.
>
> If you don't use this option, then a lot of stuff is pulled in by the
> Newlib extensions.
>

Yeah. But if you use any method with errno, you get all this. I know the
reent structure has to be initialized but why did it trigger opening
/dev/console? The console device wasn't configured. Can the post driver
hook dependency be cleaved from this chain?

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/libio_init.c#n69

I think that dependency is only needed if you configure the console
device driver. Shouldn't the sysinit for the post driver hook be part of
configuring the console or simple console?

https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/console.h
https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/iodrivers.h




> >
> > It would be nice to call a method that uses errno without automatically
> > pulling in this much baggage via a long dependency chain.
> >
> > Alternatively, the BSPs should use a malloc alternative that does not
> > set errno. And our sbrk is only used in one place so it could simply not
> > set errno.
> >
> > Fixing the dependency chain is the preferred solution.
>
> I am not sure how the dependency chain can be fixed with the current
> struct _reent approach of Newlib. A modern approach would be to replace
> this structure with individual thread-local objects. This would be
> technically feasible, however, a lot of work.
>

How about just not opening /dev/console? This will eliminate a lot of the
chain.

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/open_dev_console.c

That pulls in open, atexit, and close as a starting point. libio_init by
itself
without the link to the post driver open(/dev/console) doesn't look that bad

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

Re: Heavy SysInit Dependency

[Sebastian Huber]

On 19/05/2021 15:09, Joel Sherrill wrote:
On Wed, May 19, 2021 at 3:54 AM Sebastian Huber 
> wrote:


On 19/05/2021 10:23, Chris Johns wrote:
 >> On 19 May 2021, at 5:28 pm, Sebastian
Hubermailto:sebastian.hu...@embedded-brains.de>>  wrote:
 >>
 >> I am not sure how the dependency chain can be fixed with the
current struct _reent approach of Newlib. A modern approach would be
to replace this structure with individual thread-local objects. This
would be technically feasible, however, a lot of work.
 > Do you mean the _reent structure is expanded out into separate
TLS elements?

Yes, something like:

thread_local int errno;


On paper this would work but most architectures do not have TLS
support from RTEMS right now. On top of that, I honestly can't tell
in GCC how TLS is implemented on many architectures. If there is
a generic pattern, I'd be happy to be educated?


The most relevant architectures have TLS support, at least: arm, 
powerpc, sparc, nios2, m68k.


The arm GCC target has a -mtp=soft option. This approach would work an 
any target. You just have to add the GCC/llvm support for this for all 
targets which need it.


--
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: Heavy SysInit Dependency

[Sebastian Huber]

On 19/05/2021 15:25, Joel Sherrill wrote:


Yeah. But if you use any method with errno, you get all this. I know the
reent structure has to be initialized but why did it trigger opening
/dev/console? The console device wasn't configured. Can the post driver
hook dependency be cleaved from this chain?

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/libio_init.c#n69 



I think that dependency is only needed if you configure the console
device driver. Shouldn't the sysinit for the post driver hook be part of
configuring the console or simple console?

https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/console.h 

https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/iodrivers.h 



Initializing /dev/console via the console drivers is an option. I guess 
you still get the file system support pulled in via the file descriptors.


--
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: Heavy SysInit Dependency

[Sebastian Huber]

On 19/05/2021 16:05, Sebastian Huber wrote:
The most relevant architectures have TLS support, at least: arm, 
powerpc, sparc, nios2, m68k.


Also: riscv.

--
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: Heavy SysInit Dependency

[Joel Sherrill]

On Wed, May 19, 2021 at 9:07 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19/05/2021 15:25, Joel Sherrill wrote:
> >
> > Yeah. But if you use any method with errno, you get all this. I know the
> > reent structure has to be initialized but why did it trigger opening
> > /dev/console? The console device wasn't configured. Can the post driver
> > hook dependency be cleaved from this chain?
> >
> > https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/libio_init.c#n69
> > <
> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/libio_init.c#n69>
> >
> > I think that dependency is only needed if you configure the console
> > device driver. Shouldn't the sysinit for the post driver hook be part of
> > configuring the console or simple console?
> >
> > https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/console.h
> > <
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/console.h>
> >
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/iodrivers.h
> > <
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/iodrivers.h
> >
>
> Initializing /dev/console via the console drivers is an option. I guess
> you still get the file system support pulled in via the file descriptors.
>

Ticket and patch coming.

Moving the post driver hook to be triggered dropped ~20k and then
eliminating
using rtems_malloc and removing errno from the powerpc sbrk eliminated
another
~600 bytes.

  450645884 268384476 268435424 fe0
b-psim/powerpc/psim/testsuites/samples/minimum.exe

That matches exactly what I had with my earlier hacks but now you can
reference errno not pull in the console, libio, open/close, and unmount
overhead.

This seems to be a very acceptable solution. They are now unconnected
dependencies and the linking machinery does its magic.

I wonder what else is lurking as dependencies in the BSPs or implicit
dependency chains. I plan to make a sweep and see which BSPs have
minimum.exe sizes that seem too large.

Thanks.

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

Re: [PATCH v7 5/5] Change filesystem utime_h handler to utimens_h

[Gedare Bloom]

looks good to me, go ahead Joel

On Tue, May 18, 2021 at 6:11 PM Ryan Long  wrote:
>
> Also updated licenses.
>
> Closes #4400
> Updates #3899
> ---
>  bsps/arm/csb337/umon/tfsDriver.c|  2 +-
>  cpukit/Makefile.am  |  4 +-
>  cpukit/include/rtems/confdefs/libio.h   |  4 +-
>  cpukit/include/rtems/imfs.h | 35 -
>  cpukit/include/rtems/libio.h| 55 +--
>  cpukit/libcsupport/src/__usrenv.c   | 39 +--
>  cpukit/libcsupport/src/futimens.c   |  2 +-
>  cpukit/libcsupport/src/utimensat.c  |  2 +-
>  cpukit/libfs/src/defaults/default_ops.c | 34 -
>  cpukit/libfs/src/defaults/default_utime.c   | 32 
>  cpukit/libfs/src/defaults/default_utimens.c | 49 
>  cpukit/libfs/src/dosfs/msdos_init.c | 11 +++---
>  cpukit/libfs/src/ftpfs/ftpfs.c  | 44 --
>  cpukit/libfs/src/ftpfs/tftpDriver.c |  2 +-
>  cpukit/libfs/src/imfs/imfs_init.c   | 30 ---
>  cpukit/libfs/src/imfs/imfs_utime.c  | 41 
>  cpukit/libfs/src/imfs/imfs_utimens.c| 58 
> +
>  cpukit/libfs/src/jffs2/src/fs-rtems.c   | 11 +++---
>  cpukit/libfs/src/rfs/rtems-rfs-rtems.c  | 16 
>  spec/build/cpukit/librtemscpu.yml   |  4 +-
>  20 files changed, 295 insertions(+), 180 deletions(-)
>  delete mode 100644 cpukit/libfs/src/defaults/default_utime.c
>  create mode 100644 cpukit/libfs/src/defaults/default_utimens.c
>  delete mode 100644 cpukit/libfs/src/imfs/imfs_utime.c
>  create mode 100644 cpukit/libfs/src/imfs/imfs_utimens.c
>
> diff --git a/bsps/arm/csb337/umon/tfsDriver.c 
> b/bsps/arm/csb337/umon/tfsDriver.c
> index 0195346..caf3a4b 100644
> --- a/bsps/arm/csb337/umon/tfsDriver.c
> +++ b/bsps/arm/csb337/umon/tfsDriver.c
> @@ -657,7 +657,7 @@ static const rtems_filesystem_operations_table  
> rtems_tfs_ops = {
>.mount_h = rtems_filesystem_default_mount,
>.unmount_h = rtems_filesystem_default_unmount,
>.fsunmount_me_h = rtems_filesystem_default_fsunmount,
> -  .utime_h = rtems_filesystem_default_utime,
> +  .utimens_h = rtems_filesystem_default_utimens,
>.symlink_h = rtems_filesystem_default_symlink,
>.readlink_h = rtems_filesystem_default_readlink,
>.rename_h = rtems_filesystem_default_rename,
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index 29b4207..c144773 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -377,7 +377,7 @@ librtemscpu_a_SOURCES += 
> libfs/src/defaults/default_rmnod.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_statvfs.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_symlink.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_unmount.c
> -librtemscpu_a_SOURCES += libfs/src/defaults/default_utime.c
> +librtemscpu_a_SOURCES += libfs/src/defaults/default_utimens.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_write.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_writev.c
>  librtemscpu_a_SOURCES += libfs/src/dosfs/fat.c
> @@ -434,7 +434,7 @@ librtemscpu_a_SOURCES += libfs/src/imfs/imfs_stat.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_stat_file.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_symlink.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_unmount.c
> -librtemscpu_a_SOURCES += libfs/src/imfs/imfs_utime.c
> +librtemscpu_a_SOURCES += libfs/src/imfs/imfs_utimens.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/ioman.c
>  librtemscpu_a_SOURCES += libfs/src/pipe/fifo.c
>  librtemscpu_a_SOURCES += libfs/src/pipe/pipe.c
> diff --git a/cpukit/include/rtems/confdefs/libio.h 
> b/cpukit/include/rtems/confdefs/libio.h
> index 16a4fb69..1b84f8c 100644
> --- a/cpukit/include/rtems/confdefs/libio.h
> +++ b/cpukit/include/rtems/confdefs/libio.h
> @@ -231,9 +231,9 @@ static const rtems_filesystem_operations_table 
> IMFS_root_ops = {
>#endif
>rtems_filesystem_default_fsunmount,
>#ifdef CONFIGURE_IMFS_DISABLE_UTIME
> -rtems_filesystem_default_utime,
> +rtems_filesystem_default_utimens,
>#else
> -IMFS_utime,
> +IMFS_utimens,
>#endif
>#ifdef CONFIGURE_IMFS_DISABLE_SYMLINK
>  rtems_filesystem_default_symlink,
> diff --git a/cpukit/include/rtems/imfs.h b/cpukit/include/rtems/imfs.h
> index b2a9868..57c498c 100644
> --- a/cpukit/include/rtems/imfs.h
> +++ b/cpukit/include/rtems/imfs.h
> @@ -1,3 +1,5 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /**
>   * @file
>   *
> @@ -5,12 +7,28 @@
>   */
>
>  /*
> - *  COPYRIGHT (c) 1989-2011.
> - *  On-Line Applications Research Corporation (OAR).
> - *
> - *  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.
> + * COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
> + *
> + * Red

Incompatible Newlib Bump Approaching

[Joel Sherrill]

Hi

Ryan's patches to add utimensat and futimens support require a minor patch
to newlib to build. This patch is pending on the newlib list and must be
merged there before the RSB can be bumped and then this patch set applied.

https://lists.rtems.org/pipermail/devel/2021-May/067343.html

This is just a heads up that sometime in the next couple of weeks that
there will be a forced bump in tools. When the above patch is merged, if
you haven't updated your tools, then RTEMS will not build.

Early warning.

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

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

[Niteesh G. S.]

ping.

On Tue, May 11, 2021 at 1:09 AM Niteesh G. S.  wrote:

> Hello Gedare,
>
> On Mon, May 10, 2021 at 8:57 PM Gedare Bloom  wrote:
>
>> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S. 
>> wrote:
>> >
>> > Hi Alan,
>> >
>> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore 
>> wrote:
>> >>
>> >> Hi Niteesh,
>> >>
>> >> I was hoping to try this out as soon as I get some time. No later than
>> weekend. So if nobody else is able to check it out, I will be able to
>> provide some feedback soon.
>> >>
>> >> I should be able to bring up the console on a RPi Zero W and RPi3,
>> correct?
>> >
>> > the consoles should work on Zero W and Pi3 by default. They only fail
>> to work when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>> > this option is used. This is because when that option is used it calls
>> console_initialize which checks if any boot options were present if none
>> were
>> > given it defaults to pl011 which is the secondary UART in Zero w and
>> Pi3 so we get no output. This patch defaults to the primary UART instead of
>> > pl011 depending on the board.
>> > Also, this patch should be applied on RTEMS 5 since we started
>> supporting Pi3 and Zero w from RTEMS 5.
>> >
>> You'll need to provide a separate patch with a ticket to close on 5
>> for a backport. Wait until you get the approval for the master branch
>> though.
>
> OK. I'll create a ticket and request for a backport once this is pushed on
> to the current master
>
> Thanks,
> Niteesh.
>
>>
>> > Thanks,
>> > Niteesh.
>> >
>> >
>> >>
>> >> Thanks,
>> >>
>> >> Alan
>> >>
>> >>
>> >>
>> >> From: Niteesh G. S.
>> >> Sent: Thursday, May 6, 2021 4:29 AM
>> >> To: Joel Sherrill; Christian Mauderer
>> >> Cc: rtems-de...@rtems.org
>> >> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console
>> device
>> >>
>> >>
>> >>
>> >> ping.
>> >>
>> >>
>> >>
>> >> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S. 
>> wrote:
>> >>
>> >> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
>> >>
>> >>
>> >>
>> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S. 
>> wrote:
>> >>
>> >> Just to provide more context,
>> >>
>> >> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
>> >>
>> >> and no --console option is provided, the console driver defaults to
>> PL011.
>> >>
>> >> In raspberry pi 3 and other models whose primary UART is not PL011, we
>> get no output.
>> >>
>> >> This patch fixes that by linking the primary UART to the console
>> device.
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Niteesh
>> >>
>> >>
>> >>
>> >> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu 
>> wrote:
>> >>
>> >> When no console argument is given, the driver defaults to pl011
>> >> this results in no output in case of Rpi3 whose primary uart is
>> >> miniuart.
>> >> This patch fixes that by defaulting to the primary uart when no
>> >> console option is provided.
>> >>
>> >>
>> >>
>> >> Does the default need to vary by model?
>> >>
>> >> Yes, the primary UART is different across models.
>> >>
>> >>
>> >>
>> >> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth
>> >>
>> >> the PL011 is used to talk to the Bluetooth and miniuart acts as the
>> primary UART.
>> >>
>> >> Now we can change this by adding miniuart-bt to config.txt but the
>> miniuart is
>> >>
>> >> based on the VPU core and requires to add another option which sets
>> the core to
>> >>
>> >> a fixed freq.
>> >>
>> >>
>> >>
>> >> ---
>> >>  bsps/arm/raspberrypi/console/console-config.c | 12 +---
>> >>  1 file changed, 9 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> b/bsps/arm/raspberrypi/console/console-config.c
>> >> index 6b8eb80aa4..bd3a8d34c2 100644
>> >> --- a/bsps/arm/raspberrypi/console/console-config.c
>> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> >> @@ -165,10 +165,16 @@ static void console_select( void )
>> >>  }
>> >>}else {
>> >>  /**
>> >> - * If no command line option was given, default to PL011.
>> >> + * If no console option was given we default to the primary uarts.
>> >> + * The initialization of the uart's and BSP_output_char is
>> already done
>> >> + * in the uart_probe function called before this. So now we can
>> safely
>> >> + * compare BSP_output_char.
>> >>   */
>> >> -BSP_output_char = output_char_pl011;
>> >> -link(PL011, CONSOLE_DEVICE_NAME);
>> >> +if (BSP_output_char == output_char_pl011) {
>> >> +  link(PL011, CONSOLE_DEVICE_NAME);
>> >> +}else {
>> >> +  link(MINIUART, CONSOLE_DEVICE_NAME);
>> >> +}
>> >>}
>> >>  }
>> >>
>> >> --
>> >> 2.17.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
>>
>
___
dev

Re: Heavy SysInit Dependency

[Chris Johns]

> On 20 May 2021, at 2:05 am, Sebastian Huber 
>  wrote:
> 
> On 19/05/2021 15:09, Joel Sherrill wrote:
>> On Wed, May 19, 2021 at 3:54 AM Sebastian Huber 
>> > > wrote:
>>On 19/05/2021 10:23, Chris Johns wrote:
>> >> On 19 May 2021, at 5:28 pm, Sebastian
>>Huber>>  wrote:
>> >>
>> >> I am not sure how the dependency chain can be fixed with the
>>current struct _reent approach of Newlib. A modern approach would be
>>to replace this structure with individual thread-local objects. This
>>would be technically feasible, however, a lot of work.
>> > Do you mean the _reent structure is expanded out into separate
>>TLS elements?
>>Yes, something like:
>>thread_local int errno;
>> On paper this would work but most architectures do not have TLS
>> support from RTEMS right now. On top of that, I honestly can't tell
>> in GCC how TLS is implemented on many architectures. If there is
>> a generic pattern, I'd be happy to be educated?
> 
> The most relevant architectures have TLS support, at least: arm, powerpc, 
> sparc, nios2, m68k.

I am not comfortable with this wording. It implies there are archs we consider 
are not relevant and that should not be the case. The tiers attempt to explain 
the level of support archs have. :)

> The arm GCC target has a -mtp=soft option. This approach would work an any 
> target. You just have to add the GCC/llvm support for this for all targets 
> which need it.

Well it seems until this happens we need another solution or wait. 


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

Re: [PATCH] rtems-bsp-builder: Change to waf build system

[Chris Johns]

Looks fine (on my phone)

Thanks for this

> On 20 May 2021, at 1:25 am, Ryan Long  wrote:
> 
> Closes #4124
> ---
> config/rtems-bsps.ini | 28 ++--
> tester/rt/check.py| 35 ++-
> 2 files changed, 40 insertions(+), 23 deletions(-)
> 
> diff --git a/config/rtems-bsps.ini b/config/rtems-bsps.ini
> index 93156fb..d5de667 100644
> --- a/config/rtems-bsps.ini
> +++ b/config/rtems-bsps.ini
> @@ -156,23 +156,23 @@ smp-network-debug = config:base, config:smp, 
> config:network, config:debug
> #
> # Base set of configure options every build needs.
> #
> -base = --target=@ARCH@-rtems@RTEMS_VERSION@
> -   --enable-rtemsbsp=@BSP@
> -   --prefix=@PREFIX@
> +base = --prefix=@PREFIX@
> +   --top=@RTEMS@
> +   --rtems-config=config-@ARCH@-@BSP@-@BUILD@.ini
> #
> # Tests.
> #
> -tests = --enable-tests
> +tests = BUILD_TESTS=True
> #
> # The options for each varations.
> #
> -debug = --enable-rtems-debug
> -no-debug  = --disable-rtems-debug
> -profiling = --enable-profiling
> -no-profiling  = --disable-profiling
> -smp   = --enable-smp
> -no-smp= --disable-smp
> -posix = --enable-posix
> -no-posix  = --disable-posix
> -network   = --enable-networking
> -no-network= --disable-networking
> +debug = RTEMS_DEBUG=True
> +no-debug  = RTEMS_DEBUG=False
> +profiling = RTEMS_PROFILING=True
> +no-profiling  = RTEMS_PROFILING=False
> +smp   = RTEMS_SMP=True
> +no-smp= RTEMS_SMP=False
> +posix = RTEMS_POSIX_API=True
> +no-posix  = RTEMS_POSIX_API=False
> +network   = RTEMS_NETWORKING=True
> +no-network= RTEMS_NETWORKING=False
> diff --git a/tester/rt/check.py b/tester/rt/check.py
> index 2a38d99..95fa47e 100755
> --- a/tester/rt/check.py
> +++ b/tester/rt/check.py
> @@ -906,7 +906,9 @@ class build_jobs:
> remove += [b for b in self.builds if e in b.split('-')]
> self.builds = [b for b in self.builds if b not in remove]
> self.build_set = { }
> -exclude_options = ' ' + config.exclude_options(self.arch, self.bsp)
> +exclude_options = config.exclude_options(self.arch, self.bsp)
> +if exclude_options != '':
> +exclude_options = ' ' + exclude_options
> for build in self.builds:
> self.build_set[build] = config.build_options(build) + 
> exclude_options
> 
> @@ -938,9 +940,7 @@ class builder:
>  'BSP' : '.*libbsp/.*',
>  'LibCPU'  : '.*libcpu/.*',
>  'Shared'  : '.*shared/.*' })
> -if not path.exists(path.join(rtems, 'configure')) or \
> -   not path.exists(path.join(rtems, 'Makefile.in')) or \
> -   not path.exists(path.join(rtems, 'cpukit')):
> +if not path.exists(path.join(rtems, 'waf')):
> raise error.general('RTEMS source path does not look like RTEMS')
> 
> def _bsps(self, arch):
> @@ -952,15 +952,30 @@ class builder:
> job_index = 1
> for job in jobs:
> tag = '%*d/%d' % (max_job_size, job_index, len(jobs))
> +commands = self._commands(job, build_job_count)
> +self._create_config(job, commands)
> build_jobs += [arch_bsp_builder(self.results,
> job,
> -self._commands(job, 
> build_job_count),
> +commands,
> self.build_dir,
> tag)]
> job_index += 1
> set_max_build_label(build_jobs)
> return build_jobs
> 
> +def _create_config(self, job, commands):
> +filename = 'config-%s-%s-%s.ini' % (job.arch, job.bsp, job.build)
> +cfg_file = open(path.join(self.rtems, filename),'w+')
> +cfg_file.write('[%s/%s]' + os.linsep() % (job.arch, job.bsp))
> +new_cfg_cmds = []
> +for option in commands['configure'].split():
> +if 'waf' in option or '--' in option or 'configure' in option:
> +new_cfg_cmds += [option]
> +else:
> +cfg_file.write(option + os.linesep())
> +commands['configure'] = ' '.join(new_cfg_cmds)
> +cfg_file.close()
> +
> def _commands(self, build, build_jobs):
> commands = { 'dry-run'  : self.options['dry-run'],
>  'no-clean' : self.options['no-clean'],
> @@ -968,16 +983,18 @@ class builder:
>  'build': None }
> cmds = build.build_config.split()
> cmds += self.config.bspopts(build.arch, build.bsp)
> -cmd = [path.join(self.rtems, 'configure')]
> +cmd = [path.join(self.rtems, 'waf') + ' configure']
> for c in cmds:
> c = c.replace('@P