Re: [PATCH 1/2] basp/aarch64: Make the unexpected sections origin address 64bit

On 25/7/2022 2:00 pm, Kinsey Moore wrote: > On 7/24/2022 17:04, Chris Johns wrote: >> On 22/7/2022 11:14 pm, Kinsey Moore wrote: >>> Has this patch been tested with ILP32? I suspect that this line might need >>> to >>> get yanked out to a shared l

Re: [PATCH v4 3/7] bsps: Add GPIO API

On 23/7/2022 1:53 pm, Duc Doan wrote: > This is the new GPIO API. The header file is > gpio2.h. > --- > bsps/include/bsp/gpio2.h| 526 > bsps/shared/dev/gpio/gpio.c | 189 + > spec/build/bsps/obj.yml | 2 +- > 3 files changed, 716

Re: [PATCH 1/2] basp/aarch64: Make the unexpected sections origin address 64bit

On 22/7/2022 11:14 pm, Kinsey Moore wrote: > Has this patch been tested with ILP32? I suspect that this line might need to > get yanked out to a shared lp64 linkcmds.base and a shared ilp32 linkcmds.base > or this line pulled up into the bsp-specific linkcmds variants. No it has not been tested

Re: [PATCH 2/2] aarch64/versal: Support DDRMC0 region 0 and 1

On 22/7/2022 4:35 pm, chr...@rtems.org wrote: > +void bsp_r1_heap_extend(void); > +void bsp_r1_heap_extend(void) > +{ > + const aarch64_mmu_config_entry* r1 = _r1_region[0]; > + if (false && r1->begin != r1->end) { Hmmm, I left a check in while debugging something and removing the false is

Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

On 22/7/2022 12:42 pm, Chris Johns wrote: > On 22/7/2022 1:55 am, Noor Aman wrote: >> A brief gist of what i found compatible with the older code >> ---COMPATIBLE HEADER--- >> - BCM2835 timer >> - GPIO >> - AUX >> - GPU timer >> ---DIDNT CHECK--- >

Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

On 22/7/2022 1:55 am, Noor Aman wrote: > A brief gist of what i found compatible with the older code > ---COMPATIBLE HEADER--- > - BCM2835 timer > - GPIO > - AUX > - GPU timer > ---DIDNT CHECK--- > - SPI > - I2C > ---MINOR CHNAGE--- > - IRQ > - FIQ > ---NOT SURE ABOUT--- > - Watchdog > - Power

Re: [PATCH rtems-lwip] README: Add build instruction

On 22/7/2022 8:59 am, Vijay Kumar Banerjee wrote: > Patch pushed. The repository is working, and I see the commit email in vc. Nice. Thanks for the feedback. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 3/5] cpukit/libdl: Add support for AArch64

On 22/7/2022 1:11 am, Ryan Long wrote: > On 7/20/2022 11:39 PM, Chris Johns wrote: >> On 21/7/2022 7:36 am, Ryan Long wrote: >>> rtl-mdreloc-aarch64.c and elf_machdep.h came from NetBSD. >>> +bool >>> +rtems_rtl_elf_unwind_deregister (rtems_rtl_obj* obj) >

Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option

On 21/7/2022 6:30 pm, Sebastian Huber wrote: > On 21.07.22 10:27, Chris Johns wrote: >> On 21/7/2022 6:21 pm, Sebastian Huber wrote: >>> On 21.07.22 10:16, Chris Johns wrote: >>>> On 21/7/2022 6:11 pm, Sebastian Huber wrote: >>>>> On 21.07.22 10:03, Ch

Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option

On 21/7/2022 6:21 pm, Sebastian Huber wrote: > On 21.07.22 10:16, Chris Johns wrote: >> On 21/7/2022 6:11 pm, Sebastian Huber wrote: >>> On 21.07.22 10:03, Chris Johns wrote: >>>> As an aside, does gdb know about TLS variables and so will `errno` be >>>&g

Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option

On 21/7/2022 6:11 pm, Sebastian Huber wrote: > On 21.07.22 10:03, Chris Johns wrote: >> As an aside, does gdb know about TLS variables and so will `errno` be >> visible? > > Good question, there seems to be some support missing. For example for > arm/xilinx_zynq_a9_qemu:

Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option

+1 Really great patch and change. I think the performance improvements will be excellent. As an aside, does gdb know about TLS variables and so will `errno` be visible? Chris On 21/7/2022 5:09 pm, Sebastian Huber wrote: > This patch set adds support for the --enable-newlib-reent-thread-local >

Re: [RSB 1/3] 6/7: Update Newlib

On 21/7/2022 3:21 pm, Sebastian Huber wrote: > On 20.07.22 22:52, Chris Johns wrote: >> On 20/7/2022 6:20 pm, Sebastian Huber wrote: >>> On 20/07/2022 10:11, Chris Johns wrote: >>>>>> Are these TLS allocations in newlib based on a single use of a newlib &

Re: [PATCH v1 0/5] Add AArch64 support to libdl

On 21/7/2022 7:36 am, Ryan Long wrote: > This series of patches adds support for AArch64 in libdl and makes some small > tweaks to get the dynamic loader tests working. Thank you for this contribution. It is great to see this arch being supported. It is close. I have posted some questions about

Re: [PATCH v1 3/5] cpukit/libdl: Add support for AArch64

On 21/7/2022 7:36 am, Ryan Long wrote: > rtl-mdreloc-aarch64.c and elf_machdep.h came from NetBSD. > > Updates #4682 > --- > cpukit/libdl/rtl-mdreloc-aarch64.c| 598 ++ > .../cpu/aarch64/include/machine/elf_machdep.h | 256 > spec/build/cpukit/objdl.yml

Re: [PATCH rtems-docs v2] zynqmp: Add commentary about lwIP usage

This is much clearer. I now understand the limitation. OK to push. Thanks Chris On 20/7/2022 11:34 pm, Kinsey Moore wrote: > --- > user/bsps/aarch64/xilinx-zynqmp.rst | 12 > 1 file changed, 12 insertions(+) > > diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst >

Re: [RSB 1/3] 6/7: Update Newlib

On 20/7/2022 6:20 pm, Sebastian Huber wrote: > On 20/07/2022 10:11, Chris Johns wrote: >>>> Are these TLS allocations in newlib based on a single use of a newlib call >>>> that >>>> brings in the reent stuff? How does that work? >>> No, each TLS

Re: [RBW] New Bike Day (last week) A New to me Quickbeam

Not a touring bike, nor a one day build, but a super cool fixed gear over on the Radavist. Riv content, the cut down Choco bars really contribute to the vintage look... https://theradavist.com/readers-rides-todds-morlock-the-time-machine/ Enjoy! John On Wednesday, July 20, 2022 at 1:39:28 PM

Re: [RSB 1/3] 6/7: Update Newlib

On 20/7/2022 5:03 pm, Sebastian Huber wrote: > On 20/07/2022 02:24, Chris Johns wrote: >> On 19/7/2022 5:18 pm, Sebastian Huber wrote: >>> On 13/07/2022 11:24, Sebastian Huber wrote: >>>> This makes the --enable-newlib-reent-thread-local >>>>

Re: [RSB 1/3] 6/7: Update Newlib

On 19/7/2022 5:18 pm, Sebastian Huber wrote: > On 13/07/2022 11:24, Sebastian Huber wrote: >> This makes the --enable-newlib-reent-thread-local >> (_REENT_THREAD_LOCAL_STORAGE) >> Newlib configuration option available. > > Any comments with respect to using the Newlib thread-local storage >

Re: Time to promote lwip git repo

Thanks to everyone for this effort. Vijay, if you need a hand doing this please ping me on discord. Chris On 20/7/2022 12:40 am, Gedare Bloom wrote: > On Wed, Jul 13, 2022 at 11:27 PM Christian MAUDERER > wrote: >> >> Am 13.07.22 um 04:51 schrieb Chris Johns: >>>

Re: [PATCH rtems-docs] zynqmp: Add commentary about lwIP usage

On 20/7/2022 5:42 am, Kinsey Moore wrote: > --- > user/bsps/aarch64/xilinx-zynqmp.rst | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst > b/user/bsps/aarch64/xilinx-zynqmp.rst > index 78bff12..58954d6 100644 > ---

Re: [PATCH] aarch64: Use page table level 0

On 20/7/2022 2:58 am, Kinsey Moore wrote: > This alters the AArch64 page table generation and mapping code and MMU > configuration to use page table level 0 in addition to levels 1, 2, and > 3. This allows the mapping of up to 48 bits of memory space and is the > maximum that can be mapped without

Re: [PATCH] aarch64: Memory map the noinit section

Thanks for handling this. I have tested it works and is now required. I will push it. Chris On 16/7/2022 6:45 am, Kinsey Moore wrote: > This section was added recently and must be mapped to be accessed > without generating an exception. > --- > bsps/aarch64/include/bsp/aarch64-mmu.h| 4

Re: [PATCH v2 0/3] Reduce system initialization time

OK to push Chris On 15/7/2022 4:38 pm, Sebastian Huber wrote: > This patch set reduces the system initialization time in the default > configuration. Applications can change the default behaviour through the > CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY and CONFIGURE_DIRTY_MEMORY > configuration >

Re: [PATCH 2/3] score: Place object controls into .noinit sections

On 15/7/2022 3:41 pm, Sebastian Huber wrote: > On 15.07.22 04:03, Chris Johns wrote: >> On 14/7/2022 11:13 pm, Sebastian Huber wrote: >>> Place the statically allocated object control blocks, local tables, and >>> thread >>> queue heads into the dedicated

Re: [PATCH 1/3] bsps: Sort .noinit* sections

On 14/7/2022 11:13 pm, Sebastian Huber wrote: > Sort the .noinit* input sections by name first, then by alignment if two > sections have the same name. This allows the placement of begin/end symbols > to > initialize some areas with a special value. How are the areas initialised with a special

Re: [PATCH 2/3] score: Place object controls into .noinit sections

On 14/7/2022 11:13 pm, Sebastian Huber wrote: > Place the statically allocated object control blocks, local tables, and thread > queue heads into the dedicated .noinit intput sections. The output section is > not zero initialized. Does the data held in no-init rely on code having to initialise

Re: [PATCH] cdtest: Restrict exceptions during sysinit

On 14/7/2022 6:39 pm, Sebastian Huber wrote: > I think the message is clear, applications should start their work in the > initialization thread. I have reviewed the test and yes I agree. The work can start in global constrictors but they should work. I think C++ should be used very carefully

Re: [PATCH] samples/cdtest: Test execeptions during system init

On 14/7/2022 4:02 pm, Sebastian Huber wrote: > On 14/07/2022 02:31, Chris Johns wrote: >> On 13/7/2022 6:42 pm, Sebastian Huber wrote: >>> On 01/07/2022 12:02, Sebastian Huber wrote: >>>> +static void early_exception() >>>> +{ >>>> +

Re: [PATCH] cdtest: Restrict exceptions during sysinit

On 14/7/2022 4:08 pm, Sebastian Huber wrote: > On 14/07/2022 02:36, Chris Johns wrote: >>> Exceptions during system initialization work only on targets which do not >>> need >>> a registration of exception frames during the global construction.  In >>> p

Re: [PATCH] cdtest: Restrict exceptions during sysinit

On 13/7/2022 9:41 pm, Sebastian Huber wrote: > Exceptions during system initialization work only on targets which do not need > a registration of exception frames during the global construction. In > particular, targets which use the DWARF2 unwinder cannot use exceptions during > system

Re: [PATCH] samples/cdtest: Test execeptions during system init

On 13/7/2022 6:42 pm, Sebastian Huber wrote: > On 01/07/2022 12:02, Sebastian Huber wrote: >> +static void early_exception() >> +{ >> +    try >> +    { >> +  throw "early exception"; >> +    } >> +    catch( const char *e ) >> +    { >> +  rtems_test_assert(strcmp(e, "early exception") ==

Re: Time to promote lwip git repo

On 13/7/2022 10:08 am, Joel Sherrill wrote: > Vijay and Kinsey have made great progress in addressing the issues that were > raised about the lwip tcpip stack that needed to be addressed before it became > an official top level repository. Thanks to both of them. Well done. Great effort. > I

Re: [PATCH v3] irq/arm-gicv3.h: Customize CPU Interface init

On 11/7/2022 7:16 pm, Sebastian Huber wrote: > Use the existing WRITE_SR() abstraction to access the interrupt group 0 and 1 > enable registers. This fixes the build for the AArch32 target. > > Add BSP options which define the initial values of CPU Interface registers. > --- > v3: > > * Fix

Re: [PATCH 00/35] Relicense multiple BSPs

On 12/7/2022 8:36 am, Joel Sherrill wrote: > Hi > > Another round of license changes for the bsps/ subdirectory. Again this > only touches files which have one copyright notice and that sole one is > from OAR, embedded brains, Chris Johns, or Gedare Bloom. I have split > th

Re: [PATCH 00/23] Relicense multiple BSPs

On 9/7/2022 12:02 am, Joel Sherrill wrote: > Another round of license changes for the bsps/ subdirectory. Again this > only touches files which have one copyright notice and that sole one is > from OAR, embedded brains, Chris Johns, or Gedare Bloom. I have split > them per BSP,

Re: [PATCH v2] irq/arm-gicv3.h: Customize ICC_IGRPEN0/1 init

> On 8 Jul 2022, at 6:15 pm, Sebastian Huber > wrote: > > On 08.07.22 09:55, Chris Johns wrote: >> I have finally managed to test this patch and it does not work on a >> secure/non-secure Versal. I did a `distclean configure` and rebuild so it >> would

Re: [PATCH v2] irq/arm-gicv3.h: Customize ICC_IGRPEN0/1 init

On 5/7/2022 3:53 pm, Sebastian Huber wrote: > On 05/07/2022 00:28, Chris Johns wrote: >> On 4/7/2022 4:06 pm, Sebastian Huber wrote: >>> On 04/07/2022 03:43, Chris Johns wrote: >>>> On 1/7/2022 11:21 pm, Sebastian Huber wrote: >>>>> Use the existing WRITE_S

Re: [PATCH] bsps/microblaze: Fix build option definition order

On 8/7/2022 5:26 am, Joel Sherrill wrote: > I'm ok with this but since you said Sebastian committed something which broke > this, it would be good for him to ack as well. > > Are there other BSPs which might have this issue? I am also wondering this. There is another patch Duc posted for ARM and

Re: [tools] tester: Remove hard coded time limit for SIS

On 7/7/2022 5:34 pm, Sebastian Huber wrote: > On 07/07/2022 09:29, Chris Johns wrote: >> -1 from me. >> >> On 7/7/2022 4:44 pm, Sebastian Huber wrote: >>> Remove the hard coded time limit in the SIS configuration which would >>> overrule >>> the ge

Re: [tools] tester: Remove hard coded time limit for SIS

-1 from me. On 7/7/2022 4:44 pm, Sebastian Huber wrote: > Remove the hard coded time limit in the SIS configuration which would overrule > the general tester settings (for example the --timeout command line option). > Users can set a SIS time limit in the configuration if necessary. I would this

[PHP-DEV] Karma for voting - loophole in the system?

Hi internals, eleven months ago, there was an interesting thread about a karma for voting on RFCs (https://externals.io/message/115464), which resulted in not providing this karma to Tobias Nyholm. But in the latest RFCs  (like  https://wiki.php.net/rfc/fetch_property_in_const_expressions, 

Re: [PATCH] tester: Make the SIS time limit user configurable

On 6/7/2022 6:00 pm, Sebastian Huber wrote: > Yes, if tests go wrong the tester can kill a test execution after the > specified > timeout. Killing should be taken as a sign something in the test equipment is broken. > Why do we need this arbitrary SIS -tlim of 400 s? There was a few values and

Re: [PATCH] tester: Make the SIS time limit user configurable

On 6/7/2022 4:26 pm, Sebastian Huber wrote: > On 06/07/2022 01:51, chr...@rtems.org wrote: >> +# >> +# Timeout option. This is the default for timeout for the CPU realtime >> +# clock >> + >> +%ifn %{defined sis_time_limit} >> + %define sis_time_limit -tlim 400 s >> +%endif > > Making this

Re: [PATCH] bsps/aarch64: Use MMU pages appropriately

On 6/7/2022 5:38 am, Joel Sherrill wrote: > I'm ok with this. But Chris should speak up about the Versal. OK to push. Tested on Versal hardware and it boots as before. I have not returned to see if I can get access to at least 4G of memory in the lower 32bits of the address space. That is in the

Re: [tools] tester: Remove hard coded time limits for SIS

On 5/7/2022 8:50 pm, Jiri Gaisler wrote: > > On 7/5/22 12:45, Sebastian Huber wrote: >> >> >> On 05/07/2022 12:31, Chris Johns wrote: >>> >>>> On 5 Jul 2022, at 6:23 pm, Sebastian >>>> Huber  wrote: >>>> >>>> On

Re: [tools] tester: Remove hard coded time limits for SIS

> On 5 Jul 2022, at 6:23 pm, Sebastian Huber > wrote: > > On 05/07/2022 10:21, Chris Johns wrote: >>> On 5/7/2022 4:29 pm, Sebastian Huber wrote: >>> On 05/07/2022 08:23, Chris Johns wrote: >>>> On 5/7/2022 4:02 pm, Sebastian Huber wrote: &g

Re: [tools] tester: Remove hard coded time limits for SIS

On 5/7/2022 4:29 pm, Sebastian Huber wrote: > On 05/07/2022 08:23, Chris Johns wrote: >> On 5/7/2022 4:02 pm, Sebastian Huber wrote: >>> On 05/07/2022 07:14, Chris Johns wrote: >>>> On 5/7/2022 2:58 pm, Sebastian Huber wrote: >>>>> On 05/07/2022 03:08,

Re: [tools] tester: Remove hard coded time limits for SIS

On 5/7/2022 4:02 pm, Sebastian Huber wrote: > On 05/07/2022 07:14, Chris Johns wrote: >> On 5/7/2022 2:58 pm, Sebastian Huber wrote: >>> On 05/07/2022 03:08, Chris Johns wrote: >>>> On 5/7/2022 9:44 am, Joel Sherrill wrote: >>>>> The limit removed i

Re: [tools] tester: Remove hard coded time limits for SIS

On 5/7/2022 2:58 pm, Sebastian Huber wrote: > On 05/07/2022 03:08, Chris Johns wrote: >> On 5/7/2022 9:44 am, Joel Sherrill wrote: >>> The limit removed in sis and tsim is the simulated cpu time used. If not >>> using >>> that, the behavior of the tester is

Re: [PATCH] score: Add _CPU_Use_thread_local_storage()

On 5/7/2022 2:56 pm, Sebastian Huber wrote: > On 05/07/2022 00:33, Chris Johns wrote: >> On 4/7/2022 4:08 pm, Sebastian Huber wrote: >>> On 29/06/2022 15:07, Sebastian Huber wrote: >>>> At some point during system initialization, the idle threads are created. >&

Re: [tools] tester: Remove hard coded time limits for SIS

On 5/7/2022 9:44 am, Joel Sherrill wrote: > The limit removed in sis and tsim is the simulated cpu time used. If not using > that, the behavior of the tester is to let the simulator run for so much real > processor time.  > > Replacing these with a command line argument is probably good but just

Re: [tools] tester: Remove hard coded time limits for SIS

OK Chris On 4/7/2022 6:52 pm, Sebastian Huber wrote: > Remove the hard coded time limits in the SIS configurations which would > overrule the general tester settings (for example the--timeout command line > option). > --- > tester/rtems/testing/bsps/erc32-sis.ini | 2 +- >

Re: [PATCH] score: Add _CPU_Use_thread_local_storage()

On 4/7/2022 4:08 pm, Sebastian Huber wrote: > On 29/06/2022 15:07, Sebastian Huber wrote: >> At some point during system initialization, the idle threads are created. >> Afterwards, the boot processor basically executes within the context of an >> idle >> thread with thread dispatching disabled. 

Re: [PATCH v2] irq/arm-gicv3.h: Customize ICC_IGRPEN0/1 init

On 4/7/2022 4:06 pm, Sebastian Huber wrote: > On 04/07/2022 03:43, Chris Johns wrote: >> On 1/7/2022 11:21 pm, Sebastian Huber wrote: >>> Use the existing WRITE_SR() abstraction to access the interrupt group 0 and >>> 1 >>> enable registers.  This fi

Re: [PATCH v2 00/13] Support gcov instrumentation

OK Thanks Chris On 1/7/2022 9:49 pm, Sebastian Huber wrote: > This patch set adds support to build the RTEMS libraries with gcov > instrumentation to get code and branch coverage. There are some improvements > necessary in the build system to support different compiler flags for > libraries >

Re: [PATCH] samples/cdtest: Test execeptions during system init

OK Thanks Chris On 1/7/2022 8:02 pm, Sebastian Huber wrote: > Update #4668. > Update #4672. > --- > testsuites/samples/cdtest/main.cc | 44 --- > 1 file changed, 35 insertions(+), 9 deletions(-) > > diff --git a/testsuites/samples/cdtest/main.cc >

Re: Integrating the Formal Methods part of Qualification

On 2/7/2022 12:59 am, Andrew Butterfield wrote: > On 1 Jul 2022, at 00:59, Chris Johns <mailto:chr...@rtems.org>> wrote: >> >> On 28/6/2022 11:09 pm, andrew.butterfi...@scss.tcd.ie >> <mailto:andrew.butterfi...@scss.tcd.ie> wrote: >>> Dear RTEMS Develo

Re: [PATCH v2] irq/arm-gicv3.h: Customize ICC_IGRPEN0/1 init

On 1/7/2022 11:21 pm, Sebastian Huber wrote: > Use the existing WRITE_SR() abstraction to access the interrupt group 0 and 1 > enable registers. This fixes the build for the AArch32 target. > --- > bsps/include/dev/irq/arm-gicv3.h | 30 --- >

[gccsdk] IPv6

A quick question... With RISC OS Development's new TCP/IP stack, does anyone have a rough "finger in the air" guess as to what would be required to use IPv6? Is it likely to be a case of rebuilding network libs with it enabled, or are there going to be a bunch of changes lower down too?

Re: [PATCH 00/12] Support gcov instrumentation

On 1/7/2022 4:25 pm, Sebastian Huber wrote: > On 01.07.22 08:22, Chris Johns wrote: >>>> I am encouraged by some of the generated code I have reviewed. I like what >>>> it >>>> does. >>>> >>>>>> I am a littl

Re: [PATCH 00/12] Support gcov instrumentation

On 1/7/2022 4:03 pm, Sebastian Huber wrote: > On 01.07.22 07:38, Chris Johns wrote: >>>> If this enable is specific to GCC's gcov then maybe we should clearly >>>> label it >>>> as that and avoid overloading the term and any possible confusion t

Re: [PATCH 08/12] gcov: Add functions to dump the gcov information

On 1/7/2022 3:59 pm, Sebastian Huber wrote: > On 01.07.22 07:48, Chris Johns wrote: >> On 1/7/2022 3:00 pm, Sebastian Huber wrote: >>> On 01.07.22 02:37, Chris Johns wrote: >>>>> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg ); >>>>

Re: [PATCH] irq/arm-gicv3.h: Enable interrupt groups 0 and 1

On 28/6/2022 1:14 pm, Kinsey Moore wrote: > On 6/26/2022 22:37, Chris Johns wrote: >> On 24/6/2022 7:43 pm, Sebastian Huber wrote: >>> The GICv3 support is used by AArch32 (indicated by the ARM_MULTILIB_ARCH_V4 >>> define) and AArch64 targets.  Use the exis

Re: [PATCH 08/12] gcov: Add functions to dump the gcov information

On 1/7/2022 3:00 pm, Sebastian Huber wrote: > On 01.07.22 02:37, Chris Johns wrote: >>> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg ); >>> + >> Why just a per char interface? Given this is in the score a buffer plus >> length >> interfa

Re: [PATCH 00/12] Support gcov instrumentation

On 1/7/2022 3:07 pm, Sebastian Huber wrote: > On 01.07.22 03:19, Chris Johns wrote: >> On 29/6/2022 4:30 pm, Sebastian Huber wrote: >>> This patch set adds support to build the RTEMS libraries with gcov >>> instrumentation to get code and branch coverage.  There

Re: [PATCH 00/12] Support gcov instrumentation

On 29/6/2022 4:30 pm, Sebastian Huber wrote: > This patch set adds support to build the RTEMS libraries with gcov > instrumentation to get code and branch coverage. There are some improvements > necessary in the build system to support different compiler flags for > libraries > and tests. In

Re: [PATCH 08/12] gcov: Add functions to dump the gcov information

On 29/6/2022 4:30 pm, Sebastian Huber wrote: > Update #4670. > --- > cpukit/include/rtems/score/io.h | 4 + > cpukit/include/rtems/test-info.h| 6 ++ > cpukit/libtest/testgcovdumpinfo.c | 66 ++ > cpukit/score/src/iogcovdumpinfo.c | 101

Re: [PATCH 04/12] build: Improve value substitution

On 29/6/2022 4:30 pm, Sebastian Huber wrote: > The waf build system uses lists for tool flags. The build items may use > variable substitution. Add the ability to use the variable substitution in > lists. For example: > > MORE_FLAGS = ['-more', '-flags'] > > flags: > - -some-flag > -

Re: [PATCH] bsps/xilinx-zynq: Init debug console only once

OK and thanks Chris On 29/6/2022 12:19 am, Sebastian Huber wrote: > Initialize the debug console only once during early system initialization. > --- > bsps/arm/xilinx-zynq/console/debug-console.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git

Re: Congratulations to Two Core Developers

Gedare and Hesham ... congratulations, this is fantastic news. I know there has been a lot of work in these achievements and they are well deserved. Chris On 29/6/2022 12:23 am, Joel Sherrill wrote: > Hi > > I'd like to congratulate two RTEMS core developers on recent significant >

Re: Integrating the Formal Methods part of Qualification

On 28/6/2022 11:09 pm, andrew.butterfi...@scss.tcd.ie wrote: > Dear RTEMS Developers, > > While the validation tests from the RTEMS pre-qualification activity are > now merged into the RTEMS master, the work done in investigating and > deploying formal methods techniques is not yet merged. > >

Re: [PATCH] arm/gicv3: Fix building arm/r52

On 30/6/2022 1:42 am, Sebastian Huber wrote: > On 27/06/2022 08:27, Sebastian Huber wrote: >> On 27/06/2022 05:02, Chris Johns wrote: >>> On 24/6/2022 7:44 pm, Sebastian Huber wrote: >>>> On 20.06.22 04:03, chr...@rtems.org wrote: >>>>> From: Chris Joh

Re: [tools] tester: Normalize JSON and YAML reports

On 30/6/2022 4:34 pm, Sebastian Huber wrote: > On 30/06/2022 07:58, Sebastian Huber wrote: >> On 29/06/2022 17:54, Kinsey Moore wrote: >>> On 6/29/2022 04:34, Sebastian Huber wrote: >>>> On 29/06/2022 11:20, Chris Johns wrote: >>>>> >>>>>

Re: [tools] tester: Normalize JSON and YAML reports

> On 29 Jun 2022, at 4:42 pm, Sebastian Huber > wrote: > > On 29/06/2022 08:40, Sebastian Huber wrote: >> Report the same data in JSON and YAML reports. Do not report redundant >> information. >> Update 4671. > > This patch changes the JSON reports. Are there already consumers for the JSON

Re: [libbsd 10/22] Update CONTRIBUTING.rst

On 27/6/2022 2:40 pm, Chris Johns wrote: > We was this micro-optimisations. We saw this as micro-optimisations. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: [libbsd 10/22] Update CONTRIBUTING.rst

Hi Sebastian, Thank you for this submission. It will take a time for me to work through all the changes in detail and I may need your assistance if that is OK? I am heading out of town so I am sorry it will not be this week. On 24/6/2022 4:33 pm, Sebastian Huber wrote: > +Porting Advice >

Re: [PATCH] irq/arm-gicv3.h: Enable interrupt groups 0 and 1

On 24/6/2022 7:43 pm, Sebastian Huber wrote: > The GICv3 support is used by AArch32 (indicated by the ARM_MULTILIB_ARCH_V4 > define) and AArch64 targets. Use the existing WRITE_SR() abstraction to > access > the interrupt group 0 and 1 enable registers. This fixes the build for the > AArch32

Re: [PATCH] arm/gicv3: Fix building arm/r52

On 24/6/2022 7:44 pm, Sebastian Huber wrote: > On 20.06.22 04:03, chr...@rtems.org wrote: >> From: Chris Johns >> >> --- >>   bsps/include/dev/irq/arm-gicv3.h | 5 + >>   1 file changed, 5 insertions(+) >> >> diff --git a/bsps/include/dev/irq/arm-g

Re: [libbsd 0/4] Replace LPC Ethernet interface driver

OK Chris On 23/6/2022 7:20 pm, Sebastian Huber wrote: > The standard FreeBSD MII support causes severe problems on the LPC3200 > chip family. If an Ethernet module register is accessed while there is > no clock from the PHY, the chip completely locks up and only an external > watchdog can

Re: [gcc v2] Enable some features for RTEMS in libstdc++

On 22/6/2022 4:39 pm, Sebastian Huber wrote: > On 22/06/2022 08:36, Chris Johns wrote: >>> The patch works also for GCC 12. I only did a test run of the RTEMS tests. >> It failed to apply for me with the gcc-12 for rtems6. The configure pieces >> did >> not apply.

Re: [gcc v2] Enable some features for RTEMS in libstdc++

On 22/6/2022 4:05 pm, Sebastian Huber wrote: > On 22/06/2022 05:34, Chris Johns wrote: >> On 22/6/2022 6:38 am, Chris Johns wrote: >>>> On 21 Jun 2022, at 5:39 pm, Sebastian Huber >>>> wrote: >>>> >>>> On 09/06/2022 20:19, Sebastian Hu

Re: [gcc v2] Enable some features for RTEMS in libstdc++

On 22/6/2022 6:38 am, Chris Johns wrote: >> On 21 Jun 2022, at 5:39 pm, Sebastian Huber >> wrote: >> >> On 09/06/2022 20:19, Sebastian Huber wrote: >>> Remove RTEMS support from crossconfig.m4 since this code is not used due to >>> "with_

Re: [gcc v2] Enable some features for RTEMS in libstdc++

> On 21 Jun 2022, at 5:39 pm, Sebastian Huber > wrote: > > On 09/06/2022 20:19, Sebastian Huber wrote: >> Remove RTEMS support from crossconfig.m4 since this code is not used due to >> "with_newlib" being "yes". >> libstdc++-v3/ChangeLog: >>* configure: Regnerate. >>* configure.ac

Re: [PATCH 13/13] jffs2: Update baseline version to Linux v5.9

On 20/6/22 4:06 pm, Sebastian Huber wrote: > On 11/06/2022 03:57, Chris Johns wrote: >> I will take a look at the heap fragmentation under large block writes as a >> background task. I have openedhttps://devel.rtems.org/ticket/4664  to track >> this >> issue. >

Re: [rtems-libbsd commit] freebsd/nfsv4: Fix misaligned 64bit user dirent write

On 20/6/22 4:14 pm, Sebastian Huber wrote: > On 20/06/2022 04:57, Chris Johns wrote: >> Module:    rtems-libbsd >> Branch:    6-freebsd-12 >> Commit:    c56a34f54767decf3e398651c30bea9ebbd9572a >> Changeset:http://git.rtems.org/rtems-libbsd/commit/?id=c56a34f54767d

Re: [xubuntu-users] Please help

Try Ubuntu Mate 22.04 Have had trouble with an early Toshiba. but Mate sorted it -- xubuntu-users mailing list xubuntu-users@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/xubuntu-users

Re: [xubuntu-users] Please help

On 20/06/22 05:20, Donny Turang wrote: hi, can anyone help? I have many times installed xubuntu 20.04 LTS on acer aspire 4750 laptop. What happens is that it boots very slowly. Likewise for shutdown. In addition, the wifi on the laptop cannot be connected. This is my brief explanation.

Re: Fwd: [rtems-bsp-builder] 2022-06-18 06:34:41: Profile(s): everything

On 19/6/22 2:29 am, Joel Sherrill wrote: > Looks like some tooling broke Hmmm > >    1 debug arm/fvp_cortex_r52 build: >       configure: /home/tester/rtems-cron-6/rtems/waf configure\ >       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\ >       /rtems-cron-6/rtems

Re: Runtime Loader Exported Symbols Address Size

On 19/6/22 5:21 am, Joel Sherrill wrote: > > > On Fri, Jun 17, 2022 at 8:13 PM Chris Johns <mailto:chr...@rtems.org>> wrote: > > On 18/6/22 10:08 am, Joel Sherrill wrote: > > On Fri, Jun 17, 2022, 2:28 PM Alex White <mailto:alex.wh...@oar

Re: [RBW] Searching for bike akin to Quickbeam

James, Currently at $500 on e-bay, 60cm SimpleOne... https://www.ebay.com/itm/165534998129?hash=item268aa79e71:g:LAwAAOSwzytiqi8m Good luck, John On Thursday, June 16, 2022 at 1:56:28 PM UTC-4 leifec...@gmail.com wrote: > Brian, > That Trek/Crust conversion sounds awesome. Please post some

Re: Runtime Loader Exported Symbols Address Size

On 18/6/22 10:08 am, Joel Sherrill wrote: > On Fri, Jun 17, 2022, 2:28 PM Alex White > wrote: > > Hi, > > While testing libdl on AArch64 QEMU, we found a bug where the exported > symbol table appears to always use 32-bit values for addresses, but where

Re: [PATCH] tools/gnu: Enable LTO in RSB tools

On 16/6/2022 8:41 am, Joel Sherrill wrote: > On Wed, Jun 15, 2022 at 5:29 PM Chris Johns <mailto:chr...@rtems.org>> wrote: > > On 15/6/2022 10:58 pm, Joel Sherrill wrote: > > What's the problem with enabling LTO support in the tools by default? > > None

Re: [PATCH] tools/gnu: Enable LTO in RSB tools

On 15/6/2022 10:58 pm, Joel Sherrill wrote: > What's the problem with enabling LTO support in the tools by default? None that I know of and this patch enables the support by default. The RSB incorrectly supported the configure `--enable-lto` option. That option controls the host build and when

Re: Building gcc 12 cross-compiler with --enable-lto on FreeBSD fails

On 15/6/22 7:56 pm, Richard Biener wrote: > On Wed, Jun 15, 2022 at 11:27 AM Chris Johns > wrote: >> >> Hi, >> >> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a >> chip vendor is using it when building controller s

Building gcc 12 cross-compiler with --enable-lto on FreeBSD fails

Hi, I am trying to build a cross-compiler on FreeBSD with --enable-lto because a chip vendor is using it when building controller software that is part of a system. The build I am using symlinks gmp, mpfr etc as source so they are built as part of the gcc build. The mpfr package is reporting

Re: [PATCH 2/3] cpukit: Change _COMPILING_NEWLIB to _LIBC for helper functions decls

On 15/6/2022 2:42 am, Joel Sherrill wrote: > This is OK. Changed in newlib here: > > commit 6226bad0eafe762b811c62d1dc096bc0858b0d1a > Author: Mike Frysinger mailto:vap...@gentoo.org>> > Date:   Mon Nov 8 22:22:27 2021 -0500 > >     change _COMPILING_NEWLIB to _LIBC >     >     Use the same name

Re: [PATCH 3/3] aarch64/gicv3: Remove accesses to secure registers

On 14/6/2022 11:44 pm, Gedare Bloom wrote: > On Mon, Jun 13, 2022 at 7:39 PM wrote: >> >> From: Chris Johns >> >> --- >> bsps/include/dev/irq/arm-gicv3.h | 18 +++--- >> 1 file changed, 15 insertions(+), 3 deletions(-) >> >> diff

Re: [PATCH 2/3] bsp/versal: Support more than 4G of RAM

On 15/6/2022 2:43 am, Joel Sherrill wrote: > OK but the commit message could be a bit more enlightening.  What about: bsp/versal: Make RAM base 64bit to support more than 4G of RAM > It took me a minute to realize that all this did was change the type > of the memory length parameter. It

<    5   6   7   8   9   10   11   12   13   14   >