Re: [PATCH] build: Add the BSP family to the enable set

On 22/7/21 8:55 am, Joel Sherrill wrote: > On Wed, Jul 21, 2021, 5:49 PM Chris Johns <mailto:chr...@rtems.org>> wrote: > > On 22/7/21 8:35 am, Joel Sherrill wrote: > > On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber > > <mailto:sebastian

Re: [PATCH] bsp: Remove fatal from exit(0). Add extended heap error output

On 22/7/21 8:45 am, Joel Sherrill wrote: > On Wed, Jul 21, 2021 at 2:04 AM Chris Johns wrote: >> >> On 21/7/21 3:37 pm, Sebastian Huber wrote: >>> Hello Chris, >>> >>> thanks, this is a nice improvement. >> >> It helps find the corrupti

Re: [PATCH] build: Add the BSP family to the enable set

On 22/7/21 8:35 am, Joel Sherrill wrote: > On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber > wrote: >> >> On 21/07/2021 21:05, Gedare Bloom wrote: > The problem is that one BSP which supports SMP "riscv/griscv" is > identical to > the family "riscv/griscv" which contains BSPs which

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

On 21/7/21 5:34 pm, Christian MAUDERER wrote: > Hello Chris, > > Am 21.07.21 um 09:22 schrieb Chris Johns: >> On 21/7/21 5:05 pm, Christian MAUDERER wrote: >>> Hello, >>> >>> I don't object to clear rules. At the moment it's a bit of a mix. >> >

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/bspstart.c > > Am 21.07.21 um 07:51 schrieb Sebastian Huber: >> On 21/07/2021 02:46, Chris Johns wrote: >>> On 21/7/21 6:47 am, Gedare Bloom wrote: >>>> This seems fine to me. We don't have any standard way to d

Re: [PATCH] bsp: Remove fatal from exit(0). Add extended heap error output

On 21/7/21 3:37 pm, Sebastian Huber wrote: > Hello Chris, > > thanks, this is a nice improvement. It helps find the corruption with a watch point. > On 21/07/2021 07:17, chr...@rtems.org wrote: >> --- a/bsps/shared/start/bspfatal-default.c >> +++ b/bsps/shared/start/bspfatal-default.c >> @@

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

On 21/7/21 3:51 pm, Sebastian Huber wrote: > On 21/07/2021 02:46, Chris Johns wrote: >> I think we need some guidelines. I do not agree with URL links, email >> addresses, >> phone numbers or street addreses appearing in the source. I also think a >> sponsor >>

Re: [PATCH v2 1/5] rtems-utils.h: Create ostream_guard

Close, some minor formatting issues On 21/7/21 1:06 am, Ryan Long wrote: > --- > rtemstoolkit/rtems-utils.h | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/rtemstoolkit/rtems-utils.h b/rtemstoolkit/rtems-utils.h > index 4ce9c68..c4a262e 100644 > ---

Re: [PATCH] build: Add the BSP family to the enable set

On 20/7/21 8:25 pm, Sebastian Huber wrote: > On 15/07/2021 08:19, Sebastian Huber wrote: >> This makes it possible to use the BSP family in expressions of the enabled-by >> attribute. >> --- >>   wscript | 7 ++- >>   1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/wscript

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

On 21/7/21 6:47 am, Gedare Bloom wrote: > This seems fine to me. We don't have any standard way to document this > kind of attribution. However, we have had individual authors add their > names below their company's copyright. It might make sense to put the > sponsorship part beneath the copyright

Re: [PATCH 1/4] rtems-exeinfo.cpp: Restore ostream format

On 20/7/21 3:13 am, Ryan Long wrote: > CID 1503006: Not restoring ostream format > CID 1503007: Not restoring ostream format > > Used a variable to store the format of the ostream before any changes, > and copied what was originally there back into the stream before > returning from the function.

Re: [PATCH] AddressToLineMapper.h: Remove pointer to temporary string

Hi Alex, This looks good and can be pushed. Thank you. Chris On 17/7/21 4:03 am, Alex White wrote: > CID 1505281: Pointer to local outside scope > > Closes #4473 > --- > tester/covoar/AddressToLineMapper.cc | 11 --- > tester/covoar/AddressToLineMapper.h | 21 - >

Re: [PATCH v2] setbuilder minor list-host option

Pushed and thanks Chris On 16/7/21 10:15 pm, Robin Mueller wrote: > This adds a way to print the host triplet > Can be useful for cross-compiling toolchains > --- > Change from v1 to v2: Removed "Displaying" in printout on first line. > > source-builder/sb/setbuilder.py | 14 +- >

Re: [PATCH] cpukit: occured -> occurred

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

Re: [PATCH 2/2] This adds a way to print the host triplet

On 15/7/21 9:49 pm, Robin Müller wrote: > I think this patch was forgotten so I'm just pushing it up again :-) It was and sorry about that. Minor change below ... no need to say "Displaying" as we know that. :) if opts.get_arg('--list-host'): print('Host operating system information: ')

Re: GSoC - Code Formatting and Style Checking for RTEMS score

Hi, I will bring the discussion to the devel list and I hope the comments are in line with the purpose of the project. Please correct what I say if it is not. The pre-commit script that is in github review is a good base and I believe it solves that problem for those on Linux. It is a great

Re: [PATCH] covoar: Fix errors building on FreeBSD and clang

On 16/7/21 12:22 pm, Alex White wrote: > > On Thu, Jul 15, 2021 at 1:20 AM Chris Johns wrote: >> >> On 15/7/21 12:45 pm, Alex White wrote: >> > On Tue, Jul 6, 2021 at 7:55 PM Chris Johns wrote: >> >> >> >> On 3/7/21 5:56 am, Alex White wro

Re: [PATCH] build: Add the BSP family to the enable set

That is a nice change. OK to push Chris On 15/7/21 4:19 pm, Sebastian Huber wrote: > This makes it possible to use the BSP family in expressions of the enabled-by > attribute. > --- > wscript | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/wscript b/wscript >

Re: [PATCH] covoar: Fix errors building on FreeBSD and clang

On 15/7/21 12:45 pm, Alex White wrote: > On Tue, Jul 6, 2021 at 7:55 PM Chris Johns wrote: >> >> On 3/7/21 5:56 am, Alex White wrote: >> > On Wed, Jun 30, 2021 at 11:40 PM wrote: >> >> >> >> From: Chris Johns >> >> >> >

Re: [PATCH] build: Prefer variant default value over family

Yes this is good thing to do and thanks. Please push. Chris On 15/7/21 4:07 pm, Sebastian Huber wrote: > Update #4468. > --- > wscript | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/wscript b/wscript > index 1206c4d882..bba0c1502a 100755 > --- a/wscript > +++

Re: [PATCH rtems-docs] user: Update ZynqMP network configuration

OK On 15/7/21 5:56 am, Kinsey Moore wrote: > Network configuration is now automatic and requires no user > configuration. > --- > user/bsps/aarch64/xilinx-zynqmp.rst | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst >

Re: [PATCH v2] build: Use BSP family for options

On 14/7/21 5:01 pm, Sebastian Huber wrote: > On 14/07/2021 08:51, chr...@rtems.org wrote: >> @@ -695,12 +692,18 @@ class OptionItem(Item): >>   return True >>   return False >>   -    def default_value(self, variant): >> +    def default_value(self, variant, family): >>

Re: [PATCH v2] build: Use BSP family for options

On 14/7/21 5:24 pm, Sebastian Huber wrote: > On 14/07/2021 09:21, Chris Johns wrote: >> Is there a nice way to catch any missing fields and report them? The waf >> conf is >> not present and I am not sure if we catch any standard python exception and >> report th

Re: [PATCH v2] build: Use BSP family for options

On 14/7/21 5:01 pm, Sebastian Huber wrote: > On 14/07/2021 08:51, chr...@rtems.org wrote: >> @@ -695,12 +692,18 @@ class OptionItem(Item): >>   return True >>   return False >>   -    def default_value(self, variant): >> +    def default_value(self, variant, family): >>

Re: [PATCH] build: Use BSP family for options

On 14/7/21 4:20 pm, Sebastian Huber wrote: > Close #4468. > --- > wscript | 51 --- > 1 file changed, 28 insertions(+), 23 deletions(-) > > diff --git a/wscript b/wscript > index 6626fafb74..357e8918df 100755 > --- a/wscript > +++ b/wscript > @@

Re: [PATCH v1] Reports: Convert to C++

Hi Ryan, Looks great and thank you for making the changes. I have a minor nit below and with that change the patch to OK to push. There is no need for a fruther review. Thanks Chris On 12/7/21 11:42 pm, Ryan Long wrote: > --- > tester/covoar/ReportsBase.cc | 296 ++-- >

Re: [PATCH 19/41] bsps/irq: Implement new directives for GICv2/3

On 13/7/21 10:55 pm, Kinsey Moore wrote: > On 7/13/2021 00:16, Sebastian Huber wrote: >> On 13/07/2021 04:46, Kinsey Moore wrote: index a1ba5e9112..6f5d4015e4 100644 --- a/bsps/shared/dev/irq/arm-gicv2.c +++ b/bsps/shared/dev/irq/arm-gicv2.c @@ -1,5 +1,5 @@   /* - *

Re: [PATCH rtems-libbsd v2 1/2] freebsd/if_cgem: Fail probe for unterminated MII

On 10/7/21 12:53 am, Kinsey Moore wrote: > When the MII bus is unterminated on unused interfaces, it results in PHY > read timeouts which manifest as spurious PHYs during the attach call. > Detect these timeouts during the probe so the device can be ignored. > --- >

Re: Throughput/Goodput analysis on RTEMS

On 10/7/21 1:28 pm, Vijay Kumar Banerjee wrote: > On Fri, Jul 9, 2021 at 8:25 PM Chris Johns wrote: >> >> On 2/7/21 4:40 am, Vijay Kumar Banerjee wrote: >>> I'm planning to do a throughput analysis on the RTEMS network stacks >>> and I'm looking for some sugg

Re: Throughput/Goodput analysis on RTEMS

On 2/7/21 4:40 am, Vijay Kumar Banerjee wrote: > I'm planning to do a throughput analysis on the RTEMS network stacks > and I'm looking for some suggestions on the tools/applications for > that if anyone has done something like that before. This is a great project. > If such application has not

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

On 9/7/21 3:39 pm, Sebastian Huber wrote: > On 08/07/2021 03:11, Kinsey Moore wrote: >> I wonder why this never came up with Zynq or QorIQ. Maybe no one wanted to >> run >> network tests on the alternate interfaces because dev boards with those >> interfaces configured didn't exist? It's possible

Re: [PATCH rtems-libbsd 1/3] dev/mii: Handle PHY read timeouts

On 9/7/21 3:28 pm, Sebastian Huber wrote: > On 09/07/2021 03:14, Kinsey Moore wrote: >> PHY read timeouts return 0x and bypass the current bad/no PHY >> checks. This adds a check specifically for that read timeout to avoid >> probing PHYs that don't exist. >> --- >>  

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

On 9/7/21 7:32 am, Kinsey Moore wrote: > On 7/8/2021 10:36, Kinsey Moore wrote: >> On 7/8/2021 02:48, Chris Johns wrote: >>> On 8/7/21 11:11 am, Kinsey Moore wrote: >>>> On 7/7/2021 19:28, Chris Johns wrote: >>>>> We can: >>>>> 1. Add FDT

Re: [PATCH] Reports: Convert to C++

On 9/7/21 3:06 am, Alex White wrote: > On Wed, Jul 7, 2021 at 6:55 PM Chris Johns wrote: >> >> On 7/7/21 11:37 pm, Ryan Long wrote: >> > I'll get those pointers changed to references, and remove the whitespace >> > changes. Is there a particular reason to

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

On 8/7/21 11:11 am, Kinsey Moore wrote: > On 7/7/2021 19:28, Chris Johns wrote: >> On 7/7/21 11:26 pm, Kinsey Moore wrote: >>> On 7/6/2021 21:20, Chris Johns wrote: >>>> On 7/7/21 12:03 pm, Kinsey Moore wrote: >>>>> On 7/6/2021 20:57, Chris Johns w

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

On 7/7/21 11:26 pm, Kinsey Moore wrote: > On 7/6/2021 21:20, Chris Johns wrote: >> On 7/7/21 12:03 pm, Kinsey Moore wrote: >>> On 7/6/2021 20:57, Chris Johns wrote: >>>> On 7/7/21 11:05 am, Kinsey Moore wrote: >>>>> The need for the difference

Re: [PATCH] Reports: Convert to C++

On 7/7/21 11:37 pm, Ryan Long wrote: > I'll get those pointers changed to references, and remove the whitespace > changes. Is there a particular reason to not use '\n' instead of std::endl? Awesome and thanks. > I read that std::endl is slower since it's flushing the buffer each time that >

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

On 7/7/21 12:03 pm, Kinsey Moore wrote: > On 7/6/2021 20:57, Chris Johns wrote: >> On 7/7/21 11:05 am, Kinsey Moore wrote: >>> The need for the difference on ZynqMP is that there are 4 different CGEM >>> interfaces of which dev boards

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

On 7/7/21 11:05 am, Kinsey Moore wrote: > The need for the difference on ZynqMP is that there are 4 different CGEM > interfaces of which dev boards primarily make use of CGEM3. RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);

Re: [PATCH] covoar: Fix errors building on FreeBSD and clang

On 3/7/21 5:56 am, Alex White wrote: > On Wed, Jun 30, 2021 at 11:40 PM wrote: >> >> From: Chris Johns >> >> - The member variable `path_` cannot be a reference and initialised to >>   a const char* type input. To do so would require there is a temporary w

Re: [PATCH] Reports: Convert to C++

On 7/7/21 1:53 am, Ryan Long wrote: > Made formatting consistent and converted C code to C++. > --- > tester/covoar/ReportsBase.cc | 525 +-- > tester/covoar/ReportsBase.h | 156 +++--- > tester/covoar/ReportsHtml.cc | 1183 > +- >

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

On 7/7/21 5:46 am, Kinsey Moore wrote: > This is an alternate patch to solve the issue of test-related information > being included in an installed application-targeted header. Why is the ZYNQMP different to the zync BSP? I have been running the tests on the zynq for years and the CGEM hard IP

Re: [PATCH] waf: Ensure network-config.h gets installed

On 6/7/21 11:52 pm, Kinsey Moore wrote: > On 7/6/2021 04:45, Chris Johns wrote: >> On 3/7/21 11:16 am, Kinsey Moore wrote: >>> network-config.h is now required for application compilation when using >>> nexus-devices.h. This makes sure that it gets installed to resolve b

Re: Is rtems/bsd/test/network-config.h supposed to be installed?

> On 3 Jul 2021, at 5:14 am, Peter Dufault wrote: > > I updated my libbsd today and an application is failing to build because it > can't find the include file "rtems/bsd/test/network-config.h". It was added > yesterday to "rtemsbsd/include/bsp/nexus-devices.h". "nexus-devices.h" the >

Re: [PATCH] waf: Ensure network-config.h gets installed

On 3/7/21 11:16 am, Kinsey Moore wrote: > network-config.h is now required for application compilation when using > nexus-devices.h. This makes sure that it gets installed to resolve build > errors. I think it is a mistake to install this file. It is an internal file generated by config.inc to

Re: [PATCH rtems-libbsd] rtembsd: Use config.inc to control ZynqMP ethernet

Looks good and thanks. Chris On 1/7/21 6:11 am, Kinsey Moore wrote: > This alters the selection of the 4 Cadence GEM interfaces on the Zynq > Ultrascale+ MPSoC BSP to be provided by config.inc instead of being > provided by options in the RTEMS BSP itself since those options appear > to be dead

Re: [PATCH] defaults.mc: Remove any checks for objdump and objcopy

On 1/7/21 12:31 am, Joel Sherrill wrote: > On Wed, Jun 30, 2021 at 3:28 AM wrote: >> >> From: Chris Johns >> >> - FreeBSD is removing any dependence on binutils and release 13 >> has remove objdump. This is fine as we build our own version. > > rem

Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled

On 30/6/21 2:19 am, Kinsey Moore wrote: > On 6/29/2021 11:10, Gedare Bloom wrote: >> On Tue, Jun 29, 2021 at 6:34 AM Kinsey Moore >> wrote: >>> I suppose this could have been configured in libbsd (possibly >>> config.inc) instead if that's what you're getting at. The overall goal >>> is to be

Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled

On 30/6/21 1:21 am, Gedare Bloom wrote: > On Tue, Jun 29, 2021 at 7:50 AM Sebastian Huber > wrote: >> >> On 29/06/2021 15:48, Kinsey Moore wrote: >>> On 6/9/2021 00:27, Sebastian Huber wrote: On 08/06/2021 22:18, Kinsey Moore wrote: > Provide the options necessary to enable any

Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled

Hi, I am just catching up and missed this one until I saw the patch was pushed. I am sorry but I am confused by this patch. Could someone please explain this reason for this addition to the BSP and approach being taken? Is there something in the BSP that requires this information be provided

Re: [PATCH] covoar/Explanations.cc: Remove unnecessary newline strip

OK On 25/6/21 1:40 pm, Alex White wrote: > This corrects an issue where the starting line numbers of explanations > had their last digit removed. This was caused by code left over for > handling C file IO where the newline was included in the buffer. > --- > tester/covoar/Explanations.cc | 2 --

Re: [PATCH v2] covoar/ Explanations.cc: Handle newline at end of file

OK On 25/6/21 1:37 pm, Alex White wrote: > --- > tester/covoar/Explanations.cc | 24 +++- > 1 file changed, 11 insertions(+), 13 deletions(-) > > diff --git a/tester/covoar/Explanations.cc b/tester/covoar/Explanations.cc > index 1449fb2..4d177eb 100644 > ---

Re: BBB hello does not run...

> https://github.com/freebsd/freebsd-src/tree/19a6ceb89dbacf74697d493e48c388767126d418 > > > Note: I don't think that using that FDT is a solution. It's just to find out > whether it's the problem. A solution would be to find a method how we can > distribute matching FDTs with various licenses. > > Be

Re: rtems-docs: Update eclipse/rtems.rst?

On 23/6/21 5:13 am, Raymond Garza wrote: > While going through the docs to update everything for RTEMS 6, I’ve noticed > one > particular file to be problematic. Before I do anything to it, I’d like to > consult the mailing list. > > In the rtems-docs repository, the eclipse -> rtems.rst file

Re: BBB hello does not run...

I have bisect'ed the failure and this is the commit that is the problem: https://git.rtems.org/rtems/commit/?id=56074644a733ecc984722da2a1b61736275270c0 Hm Is there a new requirement on the needed FDT for a beagleboneblack. Chris On 23/6/21 2:52 pm, Chris Johns wrote: >

BBB hello does not run...

Hi, hello.exe is not running. Any hints? master at ... https://git.rtems.org/rtems/commit/?id=b47dbbc5f7c8518634c7c5fccd57d78c65444f2d config.ini: [DEFAULT] BUILD_TESTS = False RTEMS_DEBUG = True RTEMS_POSIX_API = True [arm/beagleboneblack] BUILD_TESTS = True output: RTEMS Beagleboard:

Re: [PATCH 0/3] Simplify generic interrupt controller support

On 18/6/21 5:20 pm, Sebastian Huber wrote: > This patch set simplifies the generic interrupt controller support a bit to > prepare for more complex follow up changes. This change touches a large number of BSPs in an important area. I spent some time this year fixing a 10+ year old IRQ bug

Re: [PATCH] covoar/ Explanations.cc: Handle newline at end of file

On 19/6/21 7:00 am, Alex White wrote: > --- > tester/covoar/Explanations.cc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tester/covoar/Explanations.cc b/tester/covoar/Explanations.cc > index 1449fb2..64cad5c 100644 > --- a/tester/covoar/Explanations.cc > +++

Re: New API directives to enable/disable interrupt vectors

On 18/6/21 1:28 am, Gedare Bloom wrote: > On Wed, Jun 16, 2021 at 11:40 PM Sebastian Huber > wrote: >> >> On 16/06/2021 20:36, Gedare Bloom wrote: >>> Looks like the existing irq-extension.h uses 'vector', so >>> rtems_interrupt_disable_vector() is a possibility, or else >>>

Re: [PATCH] covoar/CoverageMapBase: Use reference for iteration in validAddress

Ok On 18/6/21 7:13 am, Alex White wrote: > --- > tester/covoar/CoverageMapBase.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tester/covoar/CoverageMapBase.cc > b/tester/covoar/CoverageMapBase.cc > index 6ca5cf7..f0b5890 100644 > ---

Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF

On 17/6/21 1:01 pm, Alex White wrote: > So is this ok to push now that it is known to have an insignificant > performance > impact or is a different approach still warranted? OK to push. Chris ___ devel mailing list devel@rtems.org

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

On 15/6/21 4:50 pm, Sebastian Huber wrote: > On 15/06/2021 08:46, Chris Johns wrote: >> If this is pushed through and the task it left for the "demand" queue it is >> actually being placed on my queue because I am the one releasing RTEMS and I >> think having

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

On 15/6/21 4:28 pm, Sebastian Huber wrote: > On 15/06/2021 07:50, Chris Johns wrote: >> On 15/6/21 3:44 pm, Sebastian Huber wrote: >>> On 15/06/2021 06:03, Chris Johns wrote: >>>> On 8/6/21 10:23 pm, Sebastian Huber wrote: >>>>> On 08/06/2021 14:08,

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

On 15/6/21 3:44 pm, Sebastian Huber wrote: > On 15/06/2021 06:03, Chris Johns wrote: >> On 8/6/21 10:23 pm, Sebastian Huber wrote: >>> On 08/06/2021 14:08, Joel Sherrill wrote: >>>> Is the kernel rsb recipe fixed yet? That was a blocker. >>> Is this really

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

On 8/6/21 10:23 pm, Sebastian Huber wrote: > On 08/06/2021 14:08, Joel Sherrill wrote: >> Is the kernel rsb recipe fixed yet? That was a blocker. > > Is this really a blocker? Can't this be done on demand when someone wants to > update them? This depends on our shared view of supporting an

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On 9/6/21 5:05 pm, Christian Mauderer wrote: > On 09/06/2021 01:52, Chris Johns wrote: >> On 8/6/21 8:26 pm, Sebastian Huber wrote: >>> On 08/06/2021 05:07, Chris Johns wrote: >>>> On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't >>>

Re: [PATCH v2 2/2] i386: Remove unneeded include header files

On 8/6/21 11:52 pm, jan.som...@dlr.de wrote: > I would also like to backport this to 5-freebsd-12 to solve this issue there > as well. > I created a corresponding ticket: https://devel.rtems.org/ticket/4452#ticket OK for 5. Chris ___ devel mailing

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On 8/6/21 8:26 pm, Sebastian Huber wrote: > On 08/06/2021 05:07, Chris Johns wrote: >> On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need >> documentation changes because the options in the >>> waf based build system are now documented

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On 8/6/21 7:08 pm, Christian Mauderer wrote: > Hello Chris, > > On 08/06/2021 05:07, Chris Johns wrote: >> On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need >> documentation changes because the options in the >>> waf based build s

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need documentation changes because the options in the > waf based build system are now documented directly in the yaml files and > printed > if you generate the default config. Hmm I am not sure I agree with the premise the

Re: [PATCH v2 2/2] i386: Remove unneeded include header files

I agree this is the way to solve this issue. Chris On 8/6/21 3:09 am, Gedare Bloom wrote: > This looks like a much better solution :) If no one complains by > Thursday go ahead and push it. > > On Mon, Jun 7, 2021 at 2:53 AM Jan Sommer wrote: >> >> --- >>

Re: Selection of ethernet peripheral by application

On 7/6/21 10:05 pm, Kinsey Moore wrote: > On 6/6/2021 17:42, Chris Johns wrote: >> On 4/6/21 11:26 pm, Joel Sherrill wrote: >>> On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore >> <mailto:kinsey.mo...@oarcorp.com>> wrote: >>> >>> On 6/4/

Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF

On 8/6/21 1:44 am, Joel Sherrill wrote: > > > On Mon, Jun 7, 2021 at 7:00 AM Alex White <mailto:alex.wh...@oarcorp.com>> wrote: > > > On Wed, Jun 2, 2021 at 7:37 PM Chris Johns <mailto:chr...@rtems.org>> wrote: > > >

Re: Selection of ethernet peripheral by application

On 4/6/21 11:26 pm, Joel Sherrill wrote: > On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore > wrote: > > On 6/4/2021 02:32, Christian MAUDERER wrote: > > Am 02.06.21 um 20:37 schrieb Kinsey Moore: > >> Hello, > >> > >>  From what I’ve seen of the

Re: [PATCH v1] Explanations.cc: Convert to c++ file handling

Ok On 5/6/21 4:17 am, Ryan Long wrote: > --- > tester/covoar/Explanations.cc | 45 > --- > 1 file changed, 17 insertions(+), 28 deletions(-) > > diff --git a/tester/covoar/Explanations.cc b/tester/covoar/Explanations.cc > index d94cd2e..1449fb2 100644 >

Re: [PATCH v1 1/6] Explanations.cc: Fix resource leaks

On 5/6/21 2:47 am, Ryan Long wrote: > We'll submit the C++ conversions as separate patches since they are larger. > That patch will be submitted shortly. Excellent and thanks. Chris ___ devel mailing list devel@rtems.org

Re: [PATCH] cpukit/libblock/src: Add better memory handling in flashdisk.c

On 5/6/21 8:11 am, Gedare Bloom wrote: > On Fri, Jun 4, 2021 at 1:17 PM Joel Sherrill wrote: >> >> On the surface, this looks OK to me. But I remember looking at this one >> and wondering if there was any cleanup required because of the various >> subroutine calls as you work down through this

Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF

Looking good with a single comment below ... On 3/6/21 6:08 am, Alex White wrote: > This adds the AddressToLineMapper class and supporting classes to > assume responsibility of tracking address-to-line information. > > This allows the DWARF library to properly cleanup all of its resources > and

Re: Selection of ethernet peripheral by application

On 3/6/21 4:37 am, Kinsey Moore wrote: > Hello, > > From what I’ve seen of the various BSPs supported by LibBSD that have multiple > ethernet peripherals, > > only one tends to be chosen and supported. I’ve encountered a situation where > the majority of platform > > examples (Zynq Ultrascale+

Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers

On 2/6/21 4:20 am, Christian Mauderer wrote: > On 01/06/2021 19:24, Gedare Bloom wrote: >> On Mon, May 10, 2021 at 11:26 AM Jan Sommer wrote: >>> >>> Hello, >>> >>> This is a follow-up on this discussion regarding the installed header files >>> in libbsd:

Re: [PATCH v1 4/4] rtl-allocator.c: Put dereferences after nullcheck

Ok On 29/5/21 7:11 am, Ryan Long wrote: > CID 1444139: Dereference null return value in rtems_rtl_alloc_hook(). > > Closes #4333 > --- > cpukit/libdl/rtl-allocator.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/cpukit/libdl/rtl-allocator.c

Re: [PATCH v1 1/6] Explanations.cc: Fix resource leaks

On 29/5/21 8:08 am, Ryan Long wrote: > CID 1399608: Resource leak in load(). > CID 1399611: Resource leak in load(). > > Closes #4417 > --- > tester/covoar/Explanations.cc | 18 +++--- > 1 file changed, 11 insertions(+), 7 deletions(-) > > diff --git a/tester/covoar/Explanations.cc

Re: [PATCH] rtems-binutils-head.cfg, rtems-gdb-head.cfg: Bump to 3b2bef8

On 28/5/21 6:01 am, Joel Sherrill wrote: > On Wed, May 26, 2021 at 2:29 AM Chris Johns <mailto:chr...@rtems.org>> wrote: > > I am ok with this going in but > > I am becoming concerned we are building a debt around MacOS and Windows > in the > tool

Re: [PATCH rtems v2] cpukit: Add description of release version numbers

Ok and thanks. :) On 27/5/21 6:56 pm, Christian Mauderer wrote: > The release version in the git sources doesn't change. Add a note why > that is the case. > --- > v2: Integrate suggestions from Chris Johns. > > cpukit/include/rtems/version.h | 21 + >

Re: RFS and 2038

On 1/5/21 6:19 am, Joel Sherrill wrote: > Hi > > Ryan has been working to add support for the new (not obsolete) nanosecond > granularity variants of utime. In changing the utime_h file system handler to > utimens_h and propagating the changes, Ryan tripped across this. > >

Re: [PATCH] tester: Expand special case for minimum.exe

On 27/5/21 2:04 pm, Kinsey Moore wrote: > On 5/26/2021 19:22, Chris Johns wrote: >> On 27/5/21 12:06 pm, Joel Sherrill wrote: >>> On Wed, May 26, 2021, 7:03 PM Chris Johns >> <mailto:chr...@rtems.org>> wrote: >>> >>> On 26/5/21 1:52 am, Kinse

Re: RTEMS source builder: can't find RTEMS include files but then can?

On 30/4/21 1:15 am, dufa...@hda.com wrote: > > >> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote: >> >> Can I override what to use as "cmake" in RSB to specify "cmake3"? >> >>> On Apr 30, 2021, at 04:41 , Peter Dufault wrote: >>> >>> I verified my environment is squeaky-clean with a simple

Re: [PATCH v4] sb: Merge mailer changes from rtems-tools

gt; # RTEMS Tools Project (http://www.rtems.org/) > -# Copyright 2013 Chris Johns (chr...@rtems.org) > +# Copyright 2013-2016 Chris Johns (chr...@rtems.org) > +# Copyright (C) 2021 On-Line Applications Research Corporation (OAR) > # All rights reserved. > # > # This file is part

Re: AW: question about posix timer expiration

On 21/5/21 9:44 pm, gabriel.moy...@dlr.de wrote: > Did you compile ptpd with kqueue only? I’ve tried with posix timer, which are > implemented in rtems, but it seems that the handler with siginfo_t is not > called > correctly. I’ve managed to get it working using a workaround but I’ll continue >

Re: [PATCH] tester: Expand special case for minimum.exe

On 27/5/21 12:06 pm, Joel Sherrill wrote: > On Wed, May 26, 2021, 7:03 PM Chris Johns <mailto:chr...@rtems.org>> wrote: > > On 26/5/21 1:52 am, Kinsey Moore wrote: > > The minimum.exe test case is expected to fail as an "invalid" test in > > th

Re: [PATCH] tester: Expand special case for minimum.exe

On 26/5/21 1:52 am, Kinsey Moore wrote: > The minimum.exe test case is expected to fail as an "invalid" test in > the tester since it is completely stripped down and does not output the > normal test header and footer. When fatal error detection support was > added, this caught minimum.exe and

Re: [PATCH] cpukit: Add description of release version numbers

Thank you for this. On 26/5/21 7:41 pm, Christian Mauderer wrote: > The release version in the git sources doesn't change. Add a note why > that is the case. > --- > cpukit/include/rtems/version.h | 12 > 1 file changed, 12 insertions(+) > > diff --git

Re: [PATCH] rtems-binutils-head.cfg, rtems-gdb-head.cfg: Bump to 3b2bef8

I am ok with this going in but I am becoming concerned we are building a debt around MacOS and Windows in the tools that we need to resolve. Our ability to release when we would like to depends on the state of the tools and the state of the tools for all archs. :) On 22/5/21 9:20 am, Joel

Re: RTEMS_VERSION on 5 branch

On 26/5/21 6:47 pm, Christian MAUDERER wrote: > thanks for the detailed response. Should we add a bit of that to the doxygen > documentation of the rtems_version_* functions so that I don't ask it again > because I have forgotten it in a year? Yes we should. I also would to add a detailed section

Re: [PATCH 2/2] covoar: Store address-to-line info outside of DWARF

On 1/5/21 8:01 am, Alex White wrote: > This adds the AddressToLineMapper class and supporting classes to > assume responsibility of tracking address-to-line information. > > This allows the DWARF library to properly cleanup all of its resources > and leads to significant memory savings. > >

Re: [PATCH 1/2] covoar: Store only the file name in ExecutableInfo

On 4/5/21 7:07 pm, Gedare Bloom wrote: > On Fri, Apr 30, 2021 at 2:02 PM Alex White wrote: >> >> This changes the ExecutableInfo class to only store the executable >> file's name rather than an entire instance of rld::files::object. This >> allows the rld::files::object to be cleaned up in the

Re: RTEMS_VERSION on 5 branch

On 25/5/21 8:56 pm, Christian MAUDERER wrote: > Hello, Great question :) > if I build a BSP on the 5 branch, I still have the following defines in > cpuopts.h: > > #define RTEMS_VERSION "5.0.0" > #define __RTEMS_MAJOR__ 5 > #define __RTEMS_MINOR__ 0 > #define __RTEMS_REVISION__ 0 > > We are

Re: RTEMS Documentation build problem

On 21/5/21 4:28 am, Jeff Mayes wrote: > I’m trying to build the RTEMS Documentation, but having a problem with > sphinxcontrib-bibtex.  It’s been a long time since I’ve tried this, so maybe > there’s a configuration problem on my end.  Anyway, I’ve pulled down the > rtems-docs repo and tried to

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

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

Re: Heavy SysInit Dependency

> 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 >> > <mailto:sebastian.hu...@embedded-brains.de>> wrote: >>On 19/05/2021 10:23, Chris Johns w

<    8   9   10   11   12   13   14   15   16   17   >