Re: [PATCH v3] bsps: Move optfdt* files to shared parent directory
yes, I've built all of them
On Thu, Jul 1, 2021 at 10:01 PM Gedare Bloom wrote:
> Did you build all affected BSPs?
>
> On Thu, Jul 1, 2021 at 4:05 AM pranav wrote:
> >
> > ---
> > .../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
> > spec/build/bsps/arm/beagle/grp.yml | 8
> > spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
> > spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16
> > spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
> > spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
> > spec/build/bsps/arm/imx/bspimx.yml | 8
> > spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
> > spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
> > spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
> > spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
> > spec/build/bsps/arm/raspberrypi/grp.yml | 8
> > .../{arm/altera-cyclone-v => }/optfdtcpyro.yml | 0
> > .../{arm/altera-cyclone-v => }/optfdtmxsz.yml| 0
> > .../bsps/{arm/altera-cyclone-v => }/optfdtro.yml | 0
> > .../{arm/altera-cyclone-v => }/optfdtuboot.yml | 0
> > spec/build/bsps/powerpc/qoriq/grp.yml| 4 ++--
> > spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml | 16
> > spec/build/bsps/powerpc/qoriq/optfdtro.yml | 15 ---
> > spec/build/bsps/riscv/riscv/grp.yml | 8
> > spec/build/bsps/riscv/riscv/optfdtcpyro.yml | 15 ---
> > spec/build/bsps/riscv/riscv/optfdtmxsz.yml | 16
> > spec/build/bsps/riscv/riscv/optfdtro.yml | 15 ---
> > spec/build/bsps/riscv/riscv/optfdtuboot.yml | 15 ---
> > 24 files changed, 26 insertions(+), 232 deletions(-)
> > delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
> > delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
> > delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
> > delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
> > delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
> > delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
> > delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
> > delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
> > rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtcpyro.yml (100%)
> > rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtmxsz.yml (100%)
> > rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtro.yml (100%)
> > rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtuboot.yml (100%)
> > delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml
> > delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtro.yml
> > delete mode 100644 spec/build/bsps/riscv/riscv/optfdtcpyro.yml
> > delete mode 100644 spec/build/bsps/riscv/riscv/optfdtmxsz.yml
> > delete mode 100644 spec/build/bsps/riscv/riscv/optfdtro.yml
> > delete mode 100644 spec/build/bsps/riscv/riscv/optfdtuboot.yml
> >
> > diff --git a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > index da567ddd79..a9f3f7dabf 100644
> > --- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > +++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > @@ -73,15 +73,15 @@ links:
> > - role: build-dependency
> >uid: optconuart1
> > - role: build-dependency
> > - uid: optfdtcpyro
> > + uid: ../../optfdtcpyro
> > - role: build-dependency
> >uid: optfdten
> > - role: build-dependency
> > - uid: optfdtmxsz
> > + uid: ../../optfdtmxsz
> > - role: build-dependency
> > - uid: optfdtro
> > + uid: ../../optfdtro
> > - role: build-dependency
> > - uid: optfdtuboot
> > + uid: ../../optfdtuboot
> > - role: build-dependency
> >uid: opti2cspeed
> > - role: build-dependency
> > diff --git a/spec/build/bsps/arm/beagle/grp.yml
> b/spec/build/bsps/arm/beagle/grp.yml
> > index 1375913fd0..3452c3e5c8 100644
> > --- a/spec/build/bsps/arm/beagle/grp.yml
> > +++ b/spec/build/bsps/arm/beagle/grp.yml
> > @@ -22,13 +22,13 @@ links:
> > - role: build-dependency
> >uid: optdm3730
> > - role: build-dependency
> > - uid: optfdtcpyro
> > + uid: ../../optfdtcpyro
> > - role: build-dependency
> > - uid: optfdtmxsz
> > + uid: ../../optfdtmxsz
> > - role: build-dependency
> > - uid: optfdtro
> > + uid: ../../optfdtro
> > - role: build-dependency
> > - uid: optfdtuboot
> > + uid: ../../optfdtuboot
> > - role: build-dependency
> >uid: ../grp
> > - role: build-dependency
> > diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> > deleted file mode 100644
> > index c26b1ae051..00
> > --- a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> > +++ /dev/null
> > @@ -1,15 +0,0
[PATCH] aarch64: improve start code for aarch32 mode
--- bsps/aarch64/shared/start/start.S | 31 --- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/bsps/aarch64/shared/start/start.S b/bsps/aarch64/shared/start/start.S index f4c39dacdf..f47625ef99 100644 --- a/bsps/aarch64/shared/start/start.S +++ b/bsps/aarch64/shared/start/start.S @@ -107,30 +107,43 @@ _start: _el3_start: /* Drop from EL3 to EL2 */ + msr CPTR_EL3, XZR + /* Initialize HCR_EL2 and SCTLR_EL2 */ msr HCR_EL2, XZR msr SCTLR_EL2, XZR + /* Set EL2 Execution state via SCR_EL3 */ mrs x0, SCR_EL3 +#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32 + bic x0, x0, #(1<<10) +#else /* Set EL2 to AArch64 */ orr x0, x0, #(1<<10) -#ifdef AARCH64_IS_NONSECURE +#endif +#if defined(AARCH64_IS_NONSECURE) /* Set EL1 to NS */ orr x0, x0, #1 #endif msr SCR_EL3, x0 +#if defined(AARCH64_IS_NONSECURE) /* set EL2h mode for eret */ -#ifdef AARCH64_IS_NONSECURE mov x0, #0b01001 #else + /* set EL1h mode for eret */ mov x0, #0b00101 #endif +#if defined(AARCH64_MULTILIB_ARCH_V8_ILP32) + /* set aarch32 mode */ + orr x0, x0, #(1<<4) +#endif + msr SPSR_EL3, x0 /* Set EL2 entry point */ -#ifdef AARCH64_IS_NONSECURE +#if defined(AARCH64_IS_NONSECURE) adr x0, _el2_start #else adr x0, _el1_start @@ -143,8 +156,12 @@ _el2_start: /* Configure HCR_EL2 */ mrs x0, HCR_EL2 + +#ifndef AARCH64_MULTILIB_ARCH_V8_ILP32 /* Set EL1 Execution state to AArch64 */ orr x0, x0, #(1<<31) +#endif + /* Disable ID traps */ bic x0, x0, #(1<<15) bic x0, x0, #(1<<16) @@ -152,8 +169,16 @@ _el2_start: bic x0, x0, #(1<<18) msr HCR_EL2, x0 + /* Disable coprocessor traps */ + msr CPTR_EL2, XZR + msr HSTR_EL2, XZR + /* Set to EL1h mode for eret */ mov x0, #0b00101 +#if defined(AARCH64_MULTILIB_ARCH_V8_ILP32) + /* set aarch32 mode */ + orr x0, x0, #(1<<4) +#endif msr SPSR_EL2, x0 /* Set EL1 entry point */ -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
Have you seen this on benchmarking? https://datatracker.ietf.org/doc/html/rfc8238 On Thu, Jul 1, 2021 at 3:16 PM Vijay Kumar Banerjee wrote: > > Hi Kinsey, > > On Thu, Jul 1, 2021 at 12:57 PM Kinsey Moore wrote: > > > > On 7/1/2021 13:40, Vijay Kumar Banerjee wrote: > > > Hi all, > > > > > > 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. > > > > Stephen Clark has recently added TTCP tests/commands to LibBSD which I > > think would be a great starting point. > > > Thanks for the point! It looks interesting and I'll try it out. > > > Best regards, > Vijay > > > > Kinsey > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
Hi Kinsey, On Thu, Jul 1, 2021 at 12:57 PM Kinsey Moore wrote: > > On 7/1/2021 13:40, Vijay Kumar Banerjee wrote: > > Hi all, > > > > 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. > > Stephen Clark has recently added TTCP tests/commands to LibBSD which I > think would be a great starting point. > Thanks for the point! It looks interesting and I'll try it out. Best regards, Vijay > > Kinsey > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] user/bsps: Update ZynqMP for hardware BSPs
On 7/1/2021 14:10, Gedare Bloom wrote: On Thu, Jul 1, 2021 at 12:28 PM Kinsey Moore wrote: Update the ZynqMP documentation for the new hardware BSP variants including information about booting, boot image generation, and networking. --- user/bsps/aarch64/xilinx-zynqmp.rst | 56 - 1 file changed, 48 insertions(+), 8 deletions(-) diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst b/user/bsps/aarch64/xilinx-zynqmp.rst index 7401e84..333ce8e 100644 --- a/user/bsps/aarch64/xilinx-zynqmp.rst +++ b/user/bsps/aarch64/xilinx-zynqmp.rst @@ -4,19 +4,45 @@ .. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_qemu: .. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_qemu: +.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_zu3eg: +.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_zu3eg: Qemu Xilinx ZynqMP == -This BSP supports two variants, `xilinx-zynqmp-ilp32-qemu` and -`xilinx-zynqmp-lp64-qemu`. The basic hardware initialization is performed by the -BSP. These BSPs support the GICv2 interrupt controller present in all ZynqMP -systems. +This BSP supports four variants: `xilinx-zynqmp-ilp32-qemu`, +`xilinx-zynqmp-lp64-qemu`, `xilinx-zynqmp-ilp32-zu3eg`, and +`xilinx-zynqmp-lp64-zu3eg`. The basic hardware initialization is performed by This is a little confusing because there needs to be some hw initialization first (e.g., by u-boot or ATF). Maybe clarify that point. Otherwise, thanks for the addition looks great. Thanks, I'll tweak that wording before commit. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] user/bsps: Update ZynqMP for hardware BSPs
On Thu, Jul 1, 2021 at 12:28 PM Kinsey Moore wrote: > > Update the ZynqMP documentation for the new hardware BSP variants > including information about booting, boot image generation, and > networking. > --- > user/bsps/aarch64/xilinx-zynqmp.rst | 56 - > 1 file changed, 48 insertions(+), 8 deletions(-) > > diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst > b/user/bsps/aarch64/xilinx-zynqmp.rst > index 7401e84..333ce8e 100644 > --- a/user/bsps/aarch64/xilinx-zynqmp.rst > +++ b/user/bsps/aarch64/xilinx-zynqmp.rst > @@ -4,19 +4,45 @@ > > .. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_qemu: > .. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_qemu: > +.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_zu3eg: > +.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_zu3eg: > > Qemu Xilinx ZynqMP > == > > -This BSP supports two variants, `xilinx-zynqmp-ilp32-qemu` and > -`xilinx-zynqmp-lp64-qemu`. The basic hardware initialization is performed by > the > -BSP. These BSPs support the GICv2 interrupt controller present in all ZynqMP > -systems. > +This BSP supports four variants: `xilinx-zynqmp-ilp32-qemu`, > +`xilinx-zynqmp-lp64-qemu`, `xilinx-zynqmp-ilp32-zu3eg`, and > +`xilinx-zynqmp-lp64-zu3eg`. The basic hardware initialization is performed by This is a little confusing because there needs to be some hw initialization first (e.g., by u-boot or ATF). Maybe clarify that point. Otherwise, thanks for the addition looks great. > +the BSP. These BSPs support the GICv2 interrupt controller present in all > ZynqMP > +systems. The zu3eg BSPs have also been tested to be fully functional on zu2cg > +boards and should also work on any other ZynqMP chip variant since the > +Processing Subsystem (PS) does not vary among chip variants other than the > +number of CPU cores available. > > -Boot via ELF > +Boot on QEMU > > The executable image is booted by Qemu in ELF format. > > +Boot on ZynqMP Hardware > +--- > + > +On ZynqMP hardware, RTEMS can be started at EL1, EL2, or EL3 by u-boot or > +directly as part of BOOT.bin. Regardless of the exception level at boot, > RTEMS > +will drop to EL1 for execution. For quick turnaround during testing, it is > +recommended to use the u-boot BOOT.bin that comes with the PetaLinux > prebuilts > +for the board in question. > + > +Hardware Boot Image Generation > +-- > + > +RTEMS expects basic hardware initialization to be performed by ARM Trusted > +Firmware (ATF) as well as the services it provides, so this must be included > +when generating a direct-boot RTEMS BOOT.bin. > + > +When booting via u-boot, RTEMS must be packaged into a u-boot image or booted > +as a raw binary since u-boot does not currently support ELF64 which is > required > +for AArch64 ELF binaries. > + > Clock Driver > > > @@ -25,10 +51,24 @@ The clock driver uses the `ARM Generic Timer`. > Console Driver > -- > > -The console driver supports the default Qemu emulated ARM PL011 PrimeCell > UART. > +The console driver supports the default Qemu emulated ARM PL011 PrimeCell > UART > +as well as the physical ARM PL011 PrimeCell UART in the ZynqMP hardware. > + > +Network Configuration > +- > + > +When used with LibBSD, these BSP variants support networking via the four > +Cadence GEM instances present on all ZynqMP hardware variants. These are > enabled > +using config.inc in LibBSD by setting any of the following constants to 1: > +NET_CFG_ZYNQMP_USE_CGEM0 = 1 > +NET_CFG_ZYNQMP_USE_CGEM1 = 1 > +NET_CFG_ZYNQMP_USE_CGEM2 = 1 > +NET_CFG_ZYNQMP_USE_CGEM3 = 1 > + > +Most ZynqMP dev boards use CGEM3. None of the interfaces are enabled by > default. > > -Running Executables > > +Running Executables on QEMU > +--- > > Executables generated by these BSPs can be run using the following command:: > > -- > 2.20.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] m68k/uC5282: linkcmds KEEP and SORT sections
On Thu, Jul 1, 2021 at 12:58 PM Joel Sherrill wrote: > > On Thu, Jul 1, 2021 at 1:50 PM Gedare Bloom wrote: > > > > Hello all, > > > > The uC5282 stopped working in 5 and master. This patch seems to get > > things working again on both branches. I can run hello.exe and > > ticker.exe on the WIP qemu Harrison is working on. > > Based on our chats, it looks like the move to per function section linking > pointing out deficiencies in a few BSPs linker scripts. Maybe someone > on your side can grep and see if there are any more obvious places > missing KEEP. > > > I will back-port to 5 with a ticket. > > Great! > > > We'll work on full tester configuration after the WIP qemu > > modifications are finished. (Test execution termination isn't working, > > so automation is out.) > > Is there a reset register on the uc5282? Qemu has support in some > machine models for exiting instead of resetting via a command line > option. > > Otherwise, poke Alex to see what he did with the Microblaze. I don't > think qemu exits automatically for it either. > There's some kind of reset controller modeled. I think we're close. "Looks ok to me. Push to both branches." Thanks, I'm going to check this in on both branches. > --joel > > > > > Gedare > > > > On Thu, Jul 1, 2021 at 12:40 PM Gedare Bloom wrote: > > > > > > Fixes a problem with bad epilog code in _fini and to keep sections > > > necessary with the -ffunction/data-sections. > > > --- > > > bsps/m68k/uC5282/start/linkcmds | 34 ++--- > > > 1 file changed, 19 insertions(+), 15 deletions(-) > > > > > > diff --git a/bsps/m68k/uC5282/start/linkcmds > > > b/bsps/m68k/uC5282/start/linkcmds > > > index 6ac9de96ae..2111e53036 100644 > > > --- a/bsps/m68k/uC5282/start/linkcmds > > > +++ b/bsps/m68k/uC5282/start/linkcmds > > > @@ -91,13 +91,13 @@ SECTIONS > > > * crtn.o are in. > > > */ > > > PROVIDE (_init = .); > > > -*crti.o(.init) > > > -*(.init) > > > -*crtn.o(.init) > > > +KEEP (*crti.o(.init)) > > > +KEEP (*(.init)) > > > +KEEP (*crtn.o(.init)) > > > PROVIDE (_fini = .); > > > -*crti.o(.fini) > > > -*(.fini) > > > -*crtn.o(.fini) > > > +KEEP (*crti.o(.fini)) > > > +KEEP (*(.fini)) > > > +KEEP (*crtn.o(.fini)) > > > > > > /* > > > * Special FreeBSD sysctl sections. > > > @@ -122,18 +122,22 @@ SECTIONS > > > * crtend.o. The same comments apply to it. > > > */ > > > . = ALIGN (16); > > > -*crtbegin.o(.ctors) > > > -*(.ctors) > > > -*crtend.o(.ctors) > > > -*crtbegin.o(.dtors) > > > -*(.dtors) > > > -*crtend.o(.dtors) > > > +KEEP (*crtbegin.o(.ctors)) > > > +KEEP (*crtbegin?.o(.ctors)) > > > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors)) > > > +KEEP (*(SORT(.ctors.*))) > > > +KEEP (*(.ctors)) > > > +KEEP (*crtbegin.o(.dtors)) > > > +KEEP (*crtbegin?.o(.dtors)) > > > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors)) > > > +KEEP (*(SORT(.dtors.*))) > > > +KEEP (*(.dtors)) > > > > > > /* > > > * Exception frame info > > > */ > > > . = ALIGN (16); > > > -*(.eh_frame) > > > +KEEP (*(.eh_frame)) > > > > > > /* > > > * Read-only data > > > @@ -141,7 +145,7 @@ SECTIONS > > > . = ALIGN (16); > > > _rodata_start = . ; > > > *(.rodata*) > > > - KEEP (*(SORT(.rtemsroset.*))) > > > +KEEP (*(SORT(.rtemsroset.*))) > > > *(.gnu.linkonce.r*) > > > > > > . = ALIGN (16); > > > @@ -179,7 +183,7 @@ SECTIONS > > > KEEP (*(SORT(.rtemsrwset.*))) > > > *(.gnu.linkonce.d*) > > > *(.gcc_except_table*) > > > -*(.jcr) > > > +KEEP (*(.jcr)) > > > . = ALIGN (16); > > > PROVIDE (_edata = .); > > > PROVIDE (_copy_end = .); > > > -- > > > 2.25.1 > > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] m68k/uC5282: linkcmds KEEP and SORT sections
Looks ok to me. Push to both branches. On Thu, Jul 1, 2021 at 1:40 PM Gedare Bloom wrote: > > Fixes a problem with bad epilog code in _fini and to keep sections > necessary with the -ffunction/data-sections. > --- > bsps/m68k/uC5282/start/linkcmds | 34 ++--- > 1 file changed, 19 insertions(+), 15 deletions(-) > > diff --git a/bsps/m68k/uC5282/start/linkcmds b/bsps/m68k/uC5282/start/linkcmds > index 6ac9de96ae..2111e53036 100644 > --- a/bsps/m68k/uC5282/start/linkcmds > +++ b/bsps/m68k/uC5282/start/linkcmds > @@ -91,13 +91,13 @@ SECTIONS > * crtn.o are in. > */ > PROVIDE (_init = .); > -*crti.o(.init) > -*(.init) > -*crtn.o(.init) > +KEEP (*crti.o(.init)) > +KEEP (*(.init)) > +KEEP (*crtn.o(.init)) > PROVIDE (_fini = .); > -*crti.o(.fini) > -*(.fini) > -*crtn.o(.fini) > +KEEP (*crti.o(.fini)) > +KEEP (*(.fini)) > +KEEP (*crtn.o(.fini)) > > /* > * Special FreeBSD sysctl sections. > @@ -122,18 +122,22 @@ SECTIONS > * crtend.o. The same comments apply to it. > */ > . = ALIGN (16); > -*crtbegin.o(.ctors) > -*(.ctors) > -*crtend.o(.ctors) > -*crtbegin.o(.dtors) > -*(.dtors) > -*crtend.o(.dtors) > +KEEP (*crtbegin.o(.ctors)) > +KEEP (*crtbegin?.o(.ctors)) > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors)) > +KEEP (*(SORT(.ctors.*))) > +KEEP (*(.ctors)) > +KEEP (*crtbegin.o(.dtors)) > +KEEP (*crtbegin?.o(.dtors)) > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors)) > +KEEP (*(SORT(.dtors.*))) > +KEEP (*(.dtors)) > > /* > * Exception frame info > */ > . = ALIGN (16); > -*(.eh_frame) > +KEEP (*(.eh_frame)) > > /* > * Read-only data > @@ -141,7 +145,7 @@ SECTIONS > . = ALIGN (16); > _rodata_start = . ; > *(.rodata*) > - KEEP (*(SORT(.rtemsroset.*))) > +KEEP (*(SORT(.rtemsroset.*))) > *(.gnu.linkonce.r*) > > . = ALIGN (16); > @@ -179,7 +183,7 @@ SECTIONS > KEEP (*(SORT(.rtemsrwset.*))) > *(.gnu.linkonce.d*) > *(.gcc_except_table*) > -*(.jcr) > +KEEP (*(.jcr)) > . = ALIGN (16); > PROVIDE (_edata = .); > PROVIDE (_copy_end = .); > -- > 2.25.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] m68k/uC5282: linkcmds KEEP and SORT sections
On Thu, Jul 1, 2021 at 1:50 PM Gedare Bloom wrote: > > Hello all, > > The uC5282 stopped working in 5 and master. This patch seems to get > things working again on both branches. I can run hello.exe and > ticker.exe on the WIP qemu Harrison is working on. Based on our chats, it looks like the move to per function section linking pointing out deficiencies in a few BSPs linker scripts. Maybe someone on your side can grep and see if there are any more obvious places missing KEEP. > I will back-port to 5 with a ticket. Great! > We'll work on full tester configuration after the WIP qemu > modifications are finished. (Test execution termination isn't working, > so automation is out.) Is there a reset register on the uc5282? Qemu has support in some machine models for exiting instead of resetting via a command line option. Otherwise, poke Alex to see what he did with the Microblaze. I don't think qemu exits automatically for it either. --joel > > Gedare > > On Thu, Jul 1, 2021 at 12:40 PM Gedare Bloom wrote: > > > > Fixes a problem with bad epilog code in _fini and to keep sections > > necessary with the -ffunction/data-sections. > > --- > > bsps/m68k/uC5282/start/linkcmds | 34 ++--- > > 1 file changed, 19 insertions(+), 15 deletions(-) > > > > diff --git a/bsps/m68k/uC5282/start/linkcmds > > b/bsps/m68k/uC5282/start/linkcmds > > index 6ac9de96ae..2111e53036 100644 > > --- a/bsps/m68k/uC5282/start/linkcmds > > +++ b/bsps/m68k/uC5282/start/linkcmds > > @@ -91,13 +91,13 @@ SECTIONS > > * crtn.o are in. > > */ > > PROVIDE (_init = .); > > -*crti.o(.init) > > -*(.init) > > -*crtn.o(.init) > > +KEEP (*crti.o(.init)) > > +KEEP (*(.init)) > > +KEEP (*crtn.o(.init)) > > PROVIDE (_fini = .); > > -*crti.o(.fini) > > -*(.fini) > > -*crtn.o(.fini) > > +KEEP (*crti.o(.fini)) > > +KEEP (*(.fini)) > > +KEEP (*crtn.o(.fini)) > > > > /* > > * Special FreeBSD sysctl sections. > > @@ -122,18 +122,22 @@ SECTIONS > > * crtend.o. The same comments apply to it. > > */ > > . = ALIGN (16); > > -*crtbegin.o(.ctors) > > -*(.ctors) > > -*crtend.o(.ctors) > > -*crtbegin.o(.dtors) > > -*(.dtors) > > -*crtend.o(.dtors) > > +KEEP (*crtbegin.o(.ctors)) > > +KEEP (*crtbegin?.o(.ctors)) > > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors)) > > +KEEP (*(SORT(.ctors.*))) > > +KEEP (*(.ctors)) > > +KEEP (*crtbegin.o(.dtors)) > > +KEEP (*crtbegin?.o(.dtors)) > > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors)) > > +KEEP (*(SORT(.dtors.*))) > > +KEEP (*(.dtors)) > > > > /* > > * Exception frame info > > */ > > . = ALIGN (16); > > -*(.eh_frame) > > +KEEP (*(.eh_frame)) > > > > /* > > * Read-only data > > @@ -141,7 +145,7 @@ SECTIONS > > . = ALIGN (16); > > _rodata_start = . ; > > *(.rodata*) > > - KEEP (*(SORT(.rtemsroset.*))) > > +KEEP (*(SORT(.rtemsroset.*))) > > *(.gnu.linkonce.r*) > > > > . = ALIGN (16); > > @@ -179,7 +183,7 @@ SECTIONS > > KEEP (*(SORT(.rtemsrwset.*))) > > *(.gnu.linkonce.d*) > > *(.gcc_except_table*) > > -*(.jcr) > > +KEEP (*(.jcr)) > > . = ALIGN (16); > > PROVIDE (_edata = .); > > PROVIDE (_copy_end = .); > > -- > > 2.25.1 > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
On 7/1/2021 13:40, Vijay Kumar Banerjee wrote: Hi all, 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. Stephen Clark has recently added TTCP tests/commands to LibBSD which I think would be a great starting point. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems/5] m68k/uC5282: linkcmds KEEP and SORT sections
Fixes a problem with bad epilog code in _fini and to keep sections necessary with the -ffunction/data-sections. Closes #4465. --- bsps/m68k/uC5282/start/linkcmds | 34 ++--- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/bsps/m68k/uC5282/start/linkcmds b/bsps/m68k/uC5282/start/linkcmds index da97472f1b..af9a69b802 100644 --- a/bsps/m68k/uC5282/start/linkcmds +++ b/bsps/m68k/uC5282/start/linkcmds @@ -91,13 +91,13 @@ SECTIONS * crtn.o are in. */ PROVIDE (_init = .); -*crti.o(.init) -*(.init) -*crtn.o(.init) +KEEP (*crti.o(.init)) +KEEP (*(.init)) +KEEP (*crtn.o(.init)) PROVIDE (_fini = .); -*crti.o(.fini) -*(.fini) -*crtn.o(.fini) +KEEP (*crti.o(.fini)) +KEEP (*(.fini)) +KEEP (*crtn.o(.fini)) /* * Special FreeBSD sysctl sections. @@ -122,18 +122,22 @@ SECTIONS * crtend.o. The same comments apply to it. */ . = ALIGN (16); -*crtbegin.o(.ctors) -*(.ctors) -*crtend.o(.ctors) -*crtbegin.o(.dtors) -*(.dtors) -*crtend.o(.dtors) +KEEP (*crtbegin.o(.ctors)) +KEEP (*crtbegin?.o(.ctors)) +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors)) +KEEP (*(SORT(.ctors.*))) +KEEP (*(.ctors)) +KEEP (*crtbegin.o(.dtors)) +KEEP (*crtbegin?.o(.dtors)) +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors)) +KEEP (*(SORT(.dtors.*))) +KEEP (*(.dtors)) /* * Exception frame info */ . = ALIGN (16); -*(.eh_frame) +KEEP (*(.eh_frame)) /* * Read-only data @@ -141,7 +145,7 @@ SECTIONS . = ALIGN (16); _rodata_start = . ; *(.rodata*) - KEEP (*(SORT(.rtemsroset.*))) +KEEP (*(SORT(.rtemsroset.*))) *(.gnu.linkonce.r*) . = ALIGN (16); @@ -179,7 +183,7 @@ SECTIONS KEEP (*(SORT(.rtemsrwset.*))) *(.gnu.linkonce.d*) *(.gcc_except_table*) -*(.jcr) +KEEP (*(.jcr)) . = ALIGN (16); PROVIDE (_edata = .); PROVIDE (_copy_end = .); -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] m68k/uC5282: linkcmds KEEP and SORT sections
Hello all, The uC5282 stopped working in 5 and master. This patch seems to get things working again on both branches. I can run hello.exe and ticker.exe on the WIP qemu Harrison is working on. I will back-port to 5 with a ticket. We'll work on full tester configuration after the WIP qemu modifications are finished. (Test execution termination isn't working, so automation is out.) Gedare On Thu, Jul 1, 2021 at 12:40 PM Gedare Bloom wrote: > > Fixes a problem with bad epilog code in _fini and to keep sections > necessary with the -ffunction/data-sections. > --- > bsps/m68k/uC5282/start/linkcmds | 34 ++--- > 1 file changed, 19 insertions(+), 15 deletions(-) > > diff --git a/bsps/m68k/uC5282/start/linkcmds b/bsps/m68k/uC5282/start/linkcmds > index 6ac9de96ae..2111e53036 100644 > --- a/bsps/m68k/uC5282/start/linkcmds > +++ b/bsps/m68k/uC5282/start/linkcmds > @@ -91,13 +91,13 @@ SECTIONS > * crtn.o are in. > */ > PROVIDE (_init = .); > -*crti.o(.init) > -*(.init) > -*crtn.o(.init) > +KEEP (*crti.o(.init)) > +KEEP (*(.init)) > +KEEP (*crtn.o(.init)) > PROVIDE (_fini = .); > -*crti.o(.fini) > -*(.fini) > -*crtn.o(.fini) > +KEEP (*crti.o(.fini)) > +KEEP (*(.fini)) > +KEEP (*crtn.o(.fini)) > > /* > * Special FreeBSD sysctl sections. > @@ -122,18 +122,22 @@ SECTIONS > * crtend.o. The same comments apply to it. > */ > . = ALIGN (16); > -*crtbegin.o(.ctors) > -*(.ctors) > -*crtend.o(.ctors) > -*crtbegin.o(.dtors) > -*(.dtors) > -*crtend.o(.dtors) > +KEEP (*crtbegin.o(.ctors)) > +KEEP (*crtbegin?.o(.ctors)) > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors)) > +KEEP (*(SORT(.ctors.*))) > +KEEP (*(.ctors)) > +KEEP (*crtbegin.o(.dtors)) > +KEEP (*crtbegin?.o(.dtors)) > +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors)) > +KEEP (*(SORT(.dtors.*))) > +KEEP (*(.dtors)) > > /* > * Exception frame info > */ > . = ALIGN (16); > -*(.eh_frame) > +KEEP (*(.eh_frame)) > > /* > * Read-only data > @@ -141,7 +145,7 @@ SECTIONS > . = ALIGN (16); > _rodata_start = . ; > *(.rodata*) > - KEEP (*(SORT(.rtemsroset.*))) > +KEEP (*(SORT(.rtemsroset.*))) > *(.gnu.linkonce.r*) > > . = ALIGN (16); > @@ -179,7 +183,7 @@ SECTIONS > KEEP (*(SORT(.rtemsrwset.*))) > *(.gnu.linkonce.d*) > *(.gcc_except_table*) > -*(.jcr) > +KEEP (*(.jcr)) > . = ALIGN (16); > PROVIDE (_edata = .); > PROVIDE (_copy_end = .); > -- > 2.25.1 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Throughput/Goodput analysis on RTEMS
Hi all, 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. If such application has not been used with RTEMS, then I might be willing to port it to RTEMS or write one from scratch as a net-demo maybe. Any resource/advice for that is welcome and much appreciated. Thank you, Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] m68k/uC5282: linkcmds KEEP and SORT sections
Fixes a problem with bad epilog code in _fini and to keep sections necessary with the -ffunction/data-sections. --- bsps/m68k/uC5282/start/linkcmds | 34 ++--- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/bsps/m68k/uC5282/start/linkcmds b/bsps/m68k/uC5282/start/linkcmds index 6ac9de96ae..2111e53036 100644 --- a/bsps/m68k/uC5282/start/linkcmds +++ b/bsps/m68k/uC5282/start/linkcmds @@ -91,13 +91,13 @@ SECTIONS * crtn.o are in. */ PROVIDE (_init = .); -*crti.o(.init) -*(.init) -*crtn.o(.init) +KEEP (*crti.o(.init)) +KEEP (*(.init)) +KEEP (*crtn.o(.init)) PROVIDE (_fini = .); -*crti.o(.fini) -*(.fini) -*crtn.o(.fini) +KEEP (*crti.o(.fini)) +KEEP (*(.fini)) +KEEP (*crtn.o(.fini)) /* * Special FreeBSD sysctl sections. @@ -122,18 +122,22 @@ SECTIONS * crtend.o. The same comments apply to it. */ . = ALIGN (16); -*crtbegin.o(.ctors) -*(.ctors) -*crtend.o(.ctors) -*crtbegin.o(.dtors) -*(.dtors) -*crtend.o(.dtors) +KEEP (*crtbegin.o(.ctors)) +KEEP (*crtbegin?.o(.ctors)) +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors)) +KEEP (*(SORT(.ctors.*))) +KEEP (*(.ctors)) +KEEP (*crtbegin.o(.dtors)) +KEEP (*crtbegin?.o(.dtors)) +KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors)) +KEEP (*(SORT(.dtors.*))) +KEEP (*(.dtors)) /* * Exception frame info */ . = ALIGN (16); -*(.eh_frame) +KEEP (*(.eh_frame)) /* * Read-only data @@ -141,7 +145,7 @@ SECTIONS . = ALIGN (16); _rodata_start = . ; *(.rodata*) - KEEP (*(SORT(.rtemsroset.*))) +KEEP (*(SORT(.rtemsroset.*))) *(.gnu.linkonce.r*) . = ALIGN (16); @@ -179,7 +183,7 @@ SECTIONS KEEP (*(SORT(.rtemsrwset.*))) *(.gnu.linkonce.d*) *(.gcc_except_table*) -*(.jcr) +KEEP (*(.jcr)) . = ALIGN (16); PROVIDE (_edata = .); PROVIDE (_copy_end = .); -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-docs] user/bsps: Update ZynqMP for hardware BSPs
Update the ZynqMP documentation for the new hardware BSP variants including information about booting, boot image generation, and networking. --- user/bsps/aarch64/xilinx-zynqmp.rst | 56 - 1 file changed, 48 insertions(+), 8 deletions(-) diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst b/user/bsps/aarch64/xilinx-zynqmp.rst index 7401e84..333ce8e 100644 --- a/user/bsps/aarch64/xilinx-zynqmp.rst +++ b/user/bsps/aarch64/xilinx-zynqmp.rst @@ -4,19 +4,45 @@ .. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_qemu: .. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_qemu: +.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_zu3eg: +.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_zu3eg: Qemu Xilinx ZynqMP == -This BSP supports two variants, `xilinx-zynqmp-ilp32-qemu` and -`xilinx-zynqmp-lp64-qemu`. The basic hardware initialization is performed by the -BSP. These BSPs support the GICv2 interrupt controller present in all ZynqMP -systems. +This BSP supports four variants: `xilinx-zynqmp-ilp32-qemu`, +`xilinx-zynqmp-lp64-qemu`, `xilinx-zynqmp-ilp32-zu3eg`, and +`xilinx-zynqmp-lp64-zu3eg`. The basic hardware initialization is performed by +the BSP. These BSPs support the GICv2 interrupt controller present in all ZynqMP +systems. The zu3eg BSPs have also been tested to be fully functional on zu2cg +boards and should also work on any other ZynqMP chip variant since the +Processing Subsystem (PS) does not vary among chip variants other than the +number of CPU cores available. -Boot via ELF +Boot on QEMU The executable image is booted by Qemu in ELF format. +Boot on ZynqMP Hardware +--- + +On ZynqMP hardware, RTEMS can be started at EL1, EL2, or EL3 by u-boot or +directly as part of BOOT.bin. Regardless of the exception level at boot, RTEMS +will drop to EL1 for execution. For quick turnaround during testing, it is +recommended to use the u-boot BOOT.bin that comes with the PetaLinux prebuilts +for the board in question. + +Hardware Boot Image Generation +-- + +RTEMS expects basic hardware initialization to be performed by ARM Trusted +Firmware (ATF) as well as the services it provides, so this must be included +when generating a direct-boot RTEMS BOOT.bin. + +When booting via u-boot, RTEMS must be packaged into a u-boot image or booted +as a raw binary since u-boot does not currently support ELF64 which is required +for AArch64 ELF binaries. + Clock Driver @@ -25,10 +51,24 @@ The clock driver uses the `ARM Generic Timer`. Console Driver -- -The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART. +The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART +as well as the physical ARM PL011 PrimeCell UART in the ZynqMP hardware. + +Network Configuration +- + +When used with LibBSD, these BSP variants support networking via the four +Cadence GEM instances present on all ZynqMP hardware variants. These are enabled +using config.inc in LibBSD by setting any of the following constants to 1: +NET_CFG_ZYNQMP_USE_CGEM0 = 1 +NET_CFG_ZYNQMP_USE_CGEM1 = 1 +NET_CFG_ZYNQMP_USE_CGEM2 = 1 +NET_CFG_ZYNQMP_USE_CGEM3 = 1 + +Most ZynqMP dev boards use CGEM3. None of the interfaces are enabled by default. -Running Executables +Running Executables on QEMU +--- Executables generated by these BSPs can be run using the following command:: -- 2.20.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC - Code Formatting and Style Checking for RTEMS score
Thank you. I will make changes accordingly. On Thu, 1 Jul 2021, 5:31 pm Gedare Bloom, wrote: > Hi Ida, > > On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine wrote: > > > > Hello mentors, > > > > Here is the code for my pre-commit hook script. How it works is by > default, upon commiting it outputs a warning stating the number of style > issues in case there are mismatches. > > The user can trigger the strict mode which gives a more detailed output > of the style issues by running adding the mode to the config file ( git > config mode "strict") - will document this. > > > > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit > > > I made comments on your commit that added this: > > https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002 > > > I had already sent some screenshots here on how the outcome looks like. > Will love to improve my code based on your feedback and get more > suggestions. > > > > > > On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom wrote: > >> > >> > >> > >> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine wrote: > >>> > >>> Hello everyone, > >>> I updated the hooks script. About the modes, we have the default, > "strict" and "nonstrict" (couldn't think of better names). With the default > mode, it prints a warning specifying the number of style issues if any and > aborts the commit. With the strict mode, it goes into more detail showing > both the formatted and unformatted patch, the number of style issues, and > aborts the commit. In the non-strict mode, it simply displays the warning > with the style issues and the commit happens. > >>> > >>> The default mode basically happens when you run > > git commit -m "Commit message" > >>> > >>> The best method I could find to pass arguments to a script was via > environment variables. So the nonstrict mode applies when you run > > STYLEMODE=nonstrict git commit -m "Commit message" > >>> > >>> The strict mode applies when you run > > STYLEMODE=strict git commit -m "Commit message" > >>> > >>> > >> What are the possible options to pass arguments? (Maybe, a blog post > :)) Reading from a git-config file would be better than environment > variables. > >> > >> It might be better to share screenshots by a link (e.g., a blog post > :)) to avoid hitting the mailing list attachment limits. > >> > >> Gedare > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3] bsps: Move optfdt* files to shared parent directory
Did you build all affected BSPs?
On Thu, Jul 1, 2021 at 4:05 AM pranav wrote:
>
> ---
> .../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
> spec/build/bsps/arm/beagle/grp.yml | 8
> spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
> spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16
> spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
> spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
> spec/build/bsps/arm/imx/bspimx.yml | 8
> spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
> spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
> spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
> spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
> spec/build/bsps/arm/raspberrypi/grp.yml | 8
> .../{arm/altera-cyclone-v => }/optfdtcpyro.yml | 0
> .../{arm/altera-cyclone-v => }/optfdtmxsz.yml| 0
> .../bsps/{arm/altera-cyclone-v => }/optfdtro.yml | 0
> .../{arm/altera-cyclone-v => }/optfdtuboot.yml | 0
> spec/build/bsps/powerpc/qoriq/grp.yml| 4 ++--
> spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml | 16
> spec/build/bsps/powerpc/qoriq/optfdtro.yml | 15 ---
> spec/build/bsps/riscv/riscv/grp.yml | 8
> spec/build/bsps/riscv/riscv/optfdtcpyro.yml | 15 ---
> spec/build/bsps/riscv/riscv/optfdtmxsz.yml | 16
> spec/build/bsps/riscv/riscv/optfdtro.yml | 15 ---
> spec/build/bsps/riscv/riscv/optfdtuboot.yml | 15 ---
> 24 files changed, 26 insertions(+), 232 deletions(-)
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
> rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtcpyro.yml (100%)
> rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtmxsz.yml (100%)
> rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtro.yml (100%)
> rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtuboot.yml (100%)
> delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml
> delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtro.yml
> delete mode 100644 spec/build/bsps/riscv/riscv/optfdtcpyro.yml
> delete mode 100644 spec/build/bsps/riscv/riscv/optfdtmxsz.yml
> delete mode 100644 spec/build/bsps/riscv/riscv/optfdtro.yml
> delete mode 100644 spec/build/bsps/riscv/riscv/optfdtuboot.yml
>
> diff --git a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> index da567ddd79..a9f3f7dabf 100644
> --- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> +++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> @@ -73,15 +73,15 @@ links:
> - role: build-dependency
>uid: optconuart1
> - role: build-dependency
> - uid: optfdtcpyro
> + uid: ../../optfdtcpyro
> - role: build-dependency
>uid: optfdten
> - role: build-dependency
> - uid: optfdtmxsz
> + uid: ../../optfdtmxsz
> - role: build-dependency
> - uid: optfdtro
> + uid: ../../optfdtro
> - role: build-dependency
> - uid: optfdtuboot
> + uid: ../../optfdtuboot
> - role: build-dependency
>uid: opti2cspeed
> - role: build-dependency
> diff --git a/spec/build/bsps/arm/beagle/grp.yml
> b/spec/build/bsps/arm/beagle/grp.yml
> index 1375913fd0..3452c3e5c8 100644
> --- a/spec/build/bsps/arm/beagle/grp.yml
> +++ b/spec/build/bsps/arm/beagle/grp.yml
> @@ -22,13 +22,13 @@ links:
> - role: build-dependency
>uid: optdm3730
> - role: build-dependency
> - uid: optfdtcpyro
> + uid: ../../optfdtcpyro
> - role: build-dependency
> - uid: optfdtmxsz
> + uid: ../../optfdtmxsz
> - role: build-dependency
> - uid: optfdtro
> + uid: ../../optfdtro
> - role: build-dependency
> - uid: optfdtuboot
> + uid: ../../optfdtuboot
> - role: build-dependency
>uid: ../grp
> - role: build-dependency
> diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> deleted file mode 100644
> index c26b1ae051..00
> --- a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> -actions:
> -- get-boolean: null
> -- define-condition: null
> -build-type: option
> -copyrights:
> -- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: true
> -default-by-variant: []
>
Re: GSoC - Code Formatting and Style Checking for RTEMS score
Hi Ida, On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine wrote: > > Hello mentors, > > Here is the code for my pre-commit hook script. How it works is by default, > upon commiting it outputs a warning stating the number of style issues in > case there are mismatches. > The user can trigger the strict mode which gives a more detailed output of > the style issues by running adding the mode to the config file ( git config > mode "strict") - will document this. > > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit > I made comments on your commit that added this: https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002 > I had already sent some screenshots here on how the outcome looks like. Will > love to improve my code based on your feedback and get more suggestions. > > > On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom wrote: >> >> >> >> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine wrote: >>> >>> Hello everyone, >>> I updated the hooks script. About the modes, we have the default, "strict" >>> and "nonstrict" (couldn't think of better names). With the default mode, it >>> prints a warning specifying the number of style issues if any and aborts >>> the commit. With the strict mode, it goes into more detail showing both the >>> formatted and unformatted patch, the number of style issues, and aborts the >>> commit. In the non-strict mode, it simply displays the warning with the >>> style issues and the commit happens. >>> >>> The default mode basically happens when you run git commit -m "Commit message" >>> >>> The best method I could find to pass arguments to a script was via >>> environment variables. So the nonstrict mode applies when you run STYLEMODE=nonstrict git commit -m "Commit message" >>> >>> The strict mode applies when you run STYLEMODE=strict git commit -m "Commit message" >>> >>> >> What are the possible options to pass arguments? (Maybe, a blog post :)) >> Reading from a git-config file would be better than environment variables. >> >> It might be better to share screenshots by a link (e.g., a blog post :)) to >> avoid hitting the mailing list attachment limits. >> >> Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio features
- Use proper typedef for isr (avoid warning in user application)
- Use set input enable register together with pin direction
- Support irqgen == 1 mode if present in capabilities register
---
bsps/include/grlib/gpiolib.h | 7 +--
bsps/include/grlib/grlib.h| 4 +++-
bsps/shared/grlib/drvmgr/ambapp_bus.c | 5 +
bsps/shared/grlib/gpio/gpiolib.c | 2 +-
bsps/shared/grlib/gpio/grgpio.c | 22 --
5 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/bsps/include/grlib/gpiolib.h b/bsps/include/grlib/gpiolib.h
index f82d4fa2c2..37ac140862 100644
--- a/bsps/include/grlib/gpiolib.h
+++ b/bsps/include/grlib/gpiolib.h
@@ -28,6 +28,9 @@ struct gpiolib_config {
#define GPIOLIB_IRQ_POL_LOW 0
#define GPIOLIB_IRQ_POL_HIGH 1
+/* Interrupt Service Routine (ISR) */
+typedef void (*gpiolib_isr)(void *arg);
+
/* Libarary initialize function must be called befor any other */
extern int gpiolib_initialize(void);
@@ -54,7 +57,7 @@ extern int gpiolib_irq_disable(void *handle);
extern int gpiolib_irq_mask(void *handle);
extern int gpiolib_irq_unmask(void *handle);
extern int gpiolib_irq_force(void *handle);
-extern int gpiolib_irq_register(void *handle, void *func, void *arg);
+extern int gpiolib_irq_register(void *handle, gpiolib_isr func, void *arg);
/*** Driver Interface ***/
@@ -66,7 +69,7 @@ struct gpiolib_drv_ops {
int (*config)(void *handle, struct gpiolib_config *cfg);
int (*get)(void *handle, int *val);
int (*irq_opts)(void *handle, unsigned int options);
- int (*irq_register)(void *handle, void *func, void *arg);
+ int (*irq_register)(void *handle, gpiolib_isr func, void
*arg);
int (*open)(void *handle);
int (*set)(void *handle, int dir, int outval);
int (*show)(void *handle);
diff --git a/bsps/include/grlib/grlib.h b/bsps/include/grlib/grlib.h
index 49d807..4aa3e9df4a 100644
--- a/bsps/include/grlib/grlib.h
+++ b/bsps/include/grlib/grlib.h
@@ -17,6 +17,7 @@
#define __GRLIB_H__
#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -125,6 +126,7 @@ struct grgpio_regs {
volatile unsigned int iedge; /* 0x14 Interrupt edge register */
volatile unsigned int bypass; /* 0x18 Bypass register */
volatile unsigned int cap; /* 0x1C Capability register */
+#define GRGPIO_CAP_IRQGEN(reg) BSP_FLD32GET(reg, 8, 12)
volatile unsigned int irqmap[4]; /* 0x20 - 0x2C Interrupt map registers */
volatile unsigned int res_30; /* 0x30 Reserved */
volatile unsigned int res_34; /* 0x34 Reserved */
@@ -132,7 +134,7 @@ struct grgpio_regs {
volatile unsigned int res_3C; /* 0x3C Reserved */
volatile unsigned int iavail; /* 0x40 Interrupt available register */
volatile unsigned int iflag; /* 0x44 Interrupt flag register */
- volatile unsigned int res_48; /* 0x48 Reserved */
+ volatile unsigned int input_en;/* 0x48 Input enable (if present) */
volatile unsigned int pulse; /* 0x4C Pulse register */
volatile unsigned int res_50; /* 0x50 Reserved */
volatile unsigned int output_or; /* 0x54 I/O port output register,
logical-OR */
diff --git a/bsps/shared/grlib/drvmgr/ambapp_bus.c
b/bsps/shared/grlib/drvmgr/ambapp_bus.c
index 3c38fc16e0..0aed29224c 100644
--- a/bsps/shared/grlib/drvmgr/ambapp_bus.c
+++ b/bsps/shared/grlib/drvmgr/ambapp_bus.c
@@ -521,11 +521,8 @@ static int ambapp_dev_fixup(struct drvmgr_dev *dev, struct
amba_dev_info *pnp)
for(core = 0; core < subcores; core++)
drvmgr_dev_register(devs_to_register[core]);
return 1;
- } else if ( (pnp->info.device == GAISLER_GPIO) &&
- (pnp->info.vendor == VENDOR_GAISLER) ) {
- /* PIO[N] is connected to IRQ[N]. */
- pnp->info.irq = 0;
}
+
return 0;
}
diff --git a/bsps/shared/grlib/gpio/gpiolib.c b/bsps/shared/grlib/gpio/gpiolib.c
index cf0038c5bb..0cb76402cc 100644
--- a/bsps/shared/grlib/gpio/gpiolib.c
+++ b/bsps/shared/grlib/gpio/gpiolib.c
@@ -201,7 +201,7 @@ int gpiolib_get(void *handle, int *inval)
}
/*** IRQ Functions ***/
-int gpiolib_irq_register(void *handle, void *func, void *arg)
+int gpiolib_irq_register(void *handle, gpiolib_isr func, void *arg)
{
struct gpiolib_port *port = handle;
diff --git a/bsps/shared/grlib/gpio/grgpio.c b/bsps/shared/grlib/gpio/grgpio.c
index 05504ef020..5bce5f530a 100644
--- a/bsps/shared/grlib/gpio/grgpio.c
+++ b/bsps/shared/grlib/gpio/grgpio.c
@@ -229,6 +229,7 @@ static int grgpio_grpiolib_irq_opts(void *handle, unsigned
int options)
{
struct grgpio_priv *priv;
int portnr;
+ int irq;
drvmgr_isr isr;
void *arg;
@@ -244,33 +245,41 @@ static int grgpio_grpiolib_irq_opts(void *handle,
unsigned int options)
isr =
[PATCH v1 0/1] Add support for newer grgpio features
Hello, I noticed the lack of some features of modern grgpio ip cores in gpiolib. I would also like to backport this to rtems5. The corresponding ticket is here: https://devel.rtems.org/ticket/4464 v2: Fixed tabs/spaces issues. Jan Sommer (1): gpiolib/grgpio: Add support for newer grgpio features bsps/include/grlib/gpiolib.h | 7 +-- bsps/include/grlib/grlib.h| 4 +++- bsps/shared/grlib/drvmgr/ambapp_bus.c | 5 + bsps/shared/grlib/gpio/gpiolib.c | 2 +- bsps/shared/grlib/gpio/grgpio.c | 22 -- 5 files changed, 26 insertions(+), 14 deletions(-) -- 2.17.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1] gpiolib/grgpio: Add support for newer grgpio features
- Use proper typedef for isr (avoid warning in user application)
- Use set input enable register together with pin direction
- Support irqgen == 1 mode if present in capabilities register
---
bsps/include/grlib/gpiolib.h | 7 +--
bsps/include/grlib/grlib.h| 4 +++-
bsps/shared/grlib/drvmgr/ambapp_bus.c | 5 +
bsps/shared/grlib/gpio/gpiolib.c | 2 +-
bsps/shared/grlib/gpio/grgpio.c | 22 --
5 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/bsps/include/grlib/gpiolib.h b/bsps/include/grlib/gpiolib.h
index f82d4fa2c2..37ac140862 100644
--- a/bsps/include/grlib/gpiolib.h
+++ b/bsps/include/grlib/gpiolib.h
@@ -28,6 +28,9 @@ struct gpiolib_config {
#define GPIOLIB_IRQ_POL_LOW 0
#define GPIOLIB_IRQ_POL_HIGH 1
+/* Interrupt Service Routine (ISR) */
+typedef void (*gpiolib_isr)(void *arg);
+
/* Libarary initialize function must be called befor any other */
extern int gpiolib_initialize(void);
@@ -54,7 +57,7 @@ extern int gpiolib_irq_disable(void *handle);
extern int gpiolib_irq_mask(void *handle);
extern int gpiolib_irq_unmask(void *handle);
extern int gpiolib_irq_force(void *handle);
-extern int gpiolib_irq_register(void *handle, void *func, void *arg);
+extern int gpiolib_irq_register(void *handle, gpiolib_isr func, void *arg);
/*** Driver Interface ***/
@@ -66,7 +69,7 @@ struct gpiolib_drv_ops {
int (*config)(void *handle, struct gpiolib_config *cfg);
int (*get)(void *handle, int *val);
int (*irq_opts)(void *handle, unsigned int options);
- int (*irq_register)(void *handle, void *func, void *arg);
+ int (*irq_register)(void *handle, gpiolib_isr func, void
*arg);
int (*open)(void *handle);
int (*set)(void *handle, int dir, int outval);
int (*show)(void *handle);
diff --git a/bsps/include/grlib/grlib.h b/bsps/include/grlib/grlib.h
index 49d807..4aa3e9df4a 100644
--- a/bsps/include/grlib/grlib.h
+++ b/bsps/include/grlib/grlib.h
@@ -17,6 +17,7 @@
#define __GRLIB_H__
#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -125,6 +126,7 @@ struct grgpio_regs {
volatile unsigned int iedge; /* 0x14 Interrupt edge register */
volatile unsigned int bypass; /* 0x18 Bypass register */
volatile unsigned int cap; /* 0x1C Capability register */
+#define GRGPIO_CAP_IRQGEN(reg) BSP_FLD32GET(reg, 8, 12)
volatile unsigned int irqmap[4]; /* 0x20 - 0x2C Interrupt map registers */
volatile unsigned int res_30; /* 0x30 Reserved */
volatile unsigned int res_34; /* 0x34 Reserved */
@@ -132,7 +134,7 @@ struct grgpio_regs {
volatile unsigned int res_3C; /* 0x3C Reserved */
volatile unsigned int iavail; /* 0x40 Interrupt available register */
volatile unsigned int iflag; /* 0x44 Interrupt flag register */
- volatile unsigned int res_48; /* 0x48 Reserved */
+ volatile unsigned int input_en;/* 0x48 Input enable (if present) */
volatile unsigned int pulse; /* 0x4C Pulse register */
volatile unsigned int res_50; /* 0x50 Reserved */
volatile unsigned int output_or; /* 0x54 I/O port output register,
logical-OR */
diff --git a/bsps/shared/grlib/drvmgr/ambapp_bus.c
b/bsps/shared/grlib/drvmgr/ambapp_bus.c
index 3c38fc16e0..0aed29224c 100644
--- a/bsps/shared/grlib/drvmgr/ambapp_bus.c
+++ b/bsps/shared/grlib/drvmgr/ambapp_bus.c
@@ -521,11 +521,8 @@ static int ambapp_dev_fixup(struct drvmgr_dev *dev, struct
amba_dev_info *pnp)
for(core = 0; core < subcores; core++)
drvmgr_dev_register(devs_to_register[core]);
return 1;
- } else if ( (pnp->info.device == GAISLER_GPIO) &&
- (pnp->info.vendor == VENDOR_GAISLER) ) {
- /* PIO[N] is connected to IRQ[N]. */
- pnp->info.irq = 0;
}
+
return 0;
}
diff --git a/bsps/shared/grlib/gpio/gpiolib.c b/bsps/shared/grlib/gpio/gpiolib.c
index cf0038c5bb..0cb76402cc 100644
--- a/bsps/shared/grlib/gpio/gpiolib.c
+++ b/bsps/shared/grlib/gpio/gpiolib.c
@@ -201,7 +201,7 @@ int gpiolib_get(void *handle, int *inval)
}
/*** IRQ Functions ***/
-int gpiolib_irq_register(void *handle, void *func, void *arg)
+int gpiolib_irq_register(void *handle, gpiolib_isr func, void *arg)
{
struct gpiolib_port *port = handle;
diff --git a/bsps/shared/grlib/gpio/grgpio.c b/bsps/shared/grlib/gpio/grgpio.c
index 05504ef020..65b75c96cb 100644
--- a/bsps/shared/grlib/gpio/grgpio.c
+++ b/bsps/shared/grlib/gpio/grgpio.c
@@ -229,6 +229,7 @@ static int grgpio_grpiolib_irq_opts(void *handle, unsigned
int options)
{
struct grgpio_priv *priv;
int portnr;
+int irq;
drvmgr_isr isr;
void *arg;
@@ -244,33 +245,41 @@ static int grgpio_grpiolib_irq_opts(void *handle,
unsigned int options)
isr =
Re: [PATCH] tester: Add Versal VCK190 eval board TFTP support
ok
On Thu, Jul 1, 2021 at 12:34 AM wrote:
>
> From: Chris Johns
>
> ---
> .../testing/bsps/xilinx_versal_vck190.ini | 43 +++
> 1 file changed, 43 insertions(+)
> create mode 100644 tester/rtems/testing/bsps/xilinx_versal_vck190.ini
>
> diff --git a/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
> b/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
> new file mode 100644
> index 000..3bdd6be
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
> @@ -0,0 +1,43 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2021 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +#
> +# The Xilinx Zynq Zedboard and Microzed board connected via TFTP. The console
> +# is connected to a telnet tty device.
> +#
> +[xilinx_versal_vck190]
> +bsp= xilinx_versal_vck190
> +arch = aarch64
> +tester = %{_rtscripts}/tftp.cfg
> +jobs = 1
> +test_restarts = 3
> +target_reset_regex = ^No ethernet found.*|^BOOTP broadcast
> 6.*|^.+complete\.+ TIMEOUT.*
> +target_start_regex = .* PSCI Power Domain Map:$|^U-Boot .*
> +requires = target_on_command, target_off_command,
> target_reset_command, bsp_tty_dev
> --
> 2.24.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Addded test for timer_create with clock_monotonic
On Wed, Jun 30, 2021 at 6:48 PM zack leung wrote:
>
> > + remaining = (uint32_t)result->tv_nsec + result->tv_sec;
> What does "remaining" mean here? What do you get if you add a
> (truncated) nanoseconds value to a seconds value? (Hint: the units
> aren't the same, so the arithmetic is meaningless.)
>
> I thought I could convert it back into the uint32_t. I thought Adding will
> give me the remaining time.
>
There are two problems. First, you mix adding nanoseconds + seconds.
How much time is 1s + 1ns? Your calculation suggests it is 2ns.
Second, you can't cast down to 32-bit unless you're sure the result of
the arithmetic is less than 2^32. You should be ok here, because there
should be at most 10 in the tv_nsec field, but in general you
do need to be very careful about truncating time values in case there
might be any bits used in the upper 32b of a 64b variable.
> remaining = (uint32_t) ( ptimer->Timer.expire - now );
>
> something similar to what was done there.
>
>
>
> > -_Timespec_From_ticks( remaining, >it_value );
>
> > +_Timespec_From_ticks(remaining, >it_value);
>
> Why convert back and forth between timespec and ticks? why not just
>
> update this function to use timespec values?
>
>
> Do you want me to change remaining to be a timespec? change the field
> it_value to a timespec?
>
I would lean toward keeping everything in timespec types.
> Zack
>
> Ps: thanks for being so patient with my patch. I'm still learning !
>
>
> On Tue, 29 Jun 2021 at 16:44, Gedare Bloom wrote:
>>
>> Hi Zack,
>>
>> Please provide a full name in your git-commit author metadata
>> (git-config.user)
>>
>> Please use a short tag at the start of your commit to identify the
>> scope, in this case, it will be "posix/timer"
>>
>> Check typo "addded" in your commit message. I think this commit is
>> related to a ticket? if it finishes it, please use
>> Closes #.
>> where is the ticket number, or
>> Updates #.
>> If the patch does not close the ticket out.
>>
>> On Tue, Jun 29, 2021 at 9:19 AM Zack wrote:
>> >
>> > ---
>> > cpukit/include/rtems/posix/timer.h| 1 +
>> > cpukit/posix/src/psxtimercreate.c | 5 +-
>> > cpukit/posix/src/timergettime.c | 79 ---
>> > testsuites/psxtests/psxtimer02/psxtimer.c | 38 ++-
>> > 4 files changed, 98 insertions(+), 25 deletions(-)
>> >
>> > diff --git a/cpukit/include/rtems/posix/timer.h
>> > b/cpukit/include/rtems/posix/timer.h
>> > index bcbf07a65a..839fe3293c 100644
>> > --- a/cpukit/include/rtems/posix/timer.h
>> > +++ b/cpukit/include/rtems/posix/timer.h
>> > @@ -48,6 +48,7 @@ typedef struct {
>> >uint32_t ticks; /* Number of ticks of the initialization
>> > */
>> >uint32_t overrun;/* Number of expirations of the timer
>> > */
>> >struct timespec time; /* Time at which the timer was started
>> > */
>> > +clockid_t clock_type;
>> To be consistent, add a comment like the lines above.
>>
>> > } POSIX_Timer_Control;
>> >
>> > /**
>> > diff --git a/cpukit/posix/src/psxtimercreate.c
>> > b/cpukit/posix/src/psxtimercreate.c
>> > index a63cf1d100..b60be3f229 100644
>> > --- a/cpukit/posix/src/psxtimercreate.c
>> > +++ b/cpukit/posix/src/psxtimercreate.c
>> > @@ -40,7 +40,7 @@ int timer_create(
>> > {
>> >POSIX_Timer_Control *ptimer;
>> >
>> > - if ( clock_id != CLOCK_REALTIME )
>> > + if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
>> > rtems_set_errno_and_return_minus_one( EINVAL );
>> >
>> >if ( !timerid )
>> > @@ -91,7 +91,8 @@ int timer_create(
>> >ptimer->timer_data.it_value.tv_nsec= 0;
>> >ptimer->timer_data.it_interval.tv_sec = 0;
>> >ptimer->timer_data.it_interval.tv_nsec = 0;
>> > -
>> > + ptimer->clock_type=clock_id;
>> add spaces around =. Here, the lines above are aligned on the =, so
>> you should also align. Write code that uses a consistent style as
>> surrounding code / as the RTEMS Style.
>>
>> > +
>> This blank line adds a lot of whitespace characters (spaces). Blank
>> lines should be empty.
>>
>> >_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
>> >_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
>> >_Objects_Open_u32(&_POSIX_Timer_Information, >Object, 0);
>> > diff --git a/cpukit/posix/src/timergettime.c
>> > b/cpukit/posix/src/timergettime.c
>> > index ee2a566f0e..57b0ab4918 100644
>> > --- a/cpukit/posix/src/timergettime.c
>> > +++ b/cpukit/posix/src/timergettime.c
>> > @@ -6,6 +6,14 @@
>> > * @brief Function Fetches State of POSIX Per-Process Timers
>> > */
>> >
>> > +/**
>> > + * @file
>> > + *
>> > + * @ingroup POSIXAPI
>> > + *
>> > + * @brief Function Fetches State of POSIX Per-Process Timers
>>
>> A file isn't a function
>>
>> > + */
>> > +
>> > /*
>> > * 14.2.4 Per-Process Timers, P1003.1b-1993, p. 267
>> > *
>> > @@ -21,13 +29,13 @@
>> > #include "config.h"
>> > #endif
>> >
>> > -#include
>> > #include
>> >
Re: Question about Raspberry Pi bspstarthooks.c - potential patch
On 01/07/2021 15:43, Alan Cudmore wrote: The define works, but Armv6 does not implement dsb and isb. Ok, I think there are some (now deprecated) CP15 registers for dsb and isb. I created a separate #if block for Armv6 without the dsb and isb instructions and it seems to work on the Raspberry Pi Zero. Do you think the equivalent synchronization operations are necessary here? If so, I can research and test them. I found some references on Raspberry Pi forums that I can follow (also had links to the ARM manuals) Also, for the #if blocks, would you prefer this style: #if (7A or 8) .. #else if (6) .. #endif Yes, this would be good. -- 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: Question about Raspberry Pi bspstarthooks.c - potential patch
On Thu, Jul 1, 2021 at 8:20 AM Sebastian Huber wrote: > > On 29/06/2021 21:09, Alan Cudmore wrote: > >> On 29/06/2021 20:56, Alan Cudmore wrote: > >>> I understand the move in that commit now. > >>> Maybe it's not working on the single core models because the code is > >>> conditional for ARMV7 + A or ARMV8? > >>> https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485 > >>> I think the single core RPIs are ARM1176JZF-S (ARMv6Z). > >> Oh, yes, this is probably the problem. I wasn't aware that we have a BSP > >> which uses Armv6. I will try to figure out the right options. > > Thanks! As soon as you have something that would work, we can test it. > > The CPU architecture is old, but it looks like these models will be in > > production until at least 2026. > > I didn't find an Armv6 Reference Manual, so I have no idea if this works > for all Armv6 systems (the only one in RTEMS is probably the Raspberry Pi) > > diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S > index 698495d32e..028bef6d2d 100644 > --- a/bsps/arm/shared/start/start.S > +++ b/bsps/arm/shared/start/start.S > @@ -482,7 +482,8 @@ bsp_start_hook_0_done: > > .Lvector_table_copy_done: > > -#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8 > +#if __ARM_ARCH == 6 || (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || \ > + __ARM_ARCH >= 8 > /* > * This code path is only executed by the primary processor. > Set the > * VBAR to the normal vector table. For secondary processors, > this is > > > -- The define works, but Armv6 does not implement dsb and isb. I created a separate #if block for Armv6 without the dsb and isb instructions and it seems to work on the Raspberry Pi Zero. Do you think the equivalent synchronization operations are necessary here? If so, I can research and test them. I found some references on Raspberry Pi forums that I can follow (also had links to the ARM manuals) Also, for the #if blocks, would you prefer this style: #if (7A or 8) .. #else if (6) .. #endif or two separate #if blocks? Thanks, Alan > 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: Question about Raspberry Pi bspstarthooks.c - potential patch
On 29/06/2021 21:09, Alan Cudmore wrote: On 29/06/2021 20:56, Alan Cudmore wrote: I understand the move in that commit now. Maybe it's not working on the single core models because the code is conditional for ARMV7 + A or ARMV8? https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485 I think the single core RPIs are ARM1176JZF-S (ARMv6Z). Oh, yes, this is probably the problem. I wasn't aware that we have a BSP which uses Armv6. I will try to figure out the right options. Thanks! As soon as you have something that would work, we can test it. The CPU architecture is old, but it looks like these models will be in production until at least 2026. I didn't find an Armv6 Reference Manual, so I have no idea if this works for all Armv6 systems (the only one in RTEMS is probably the Raspberry Pi) diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S index 698495d32e..028bef6d2d 100644 --- a/bsps/arm/shared/start/start.S +++ b/bsps/arm/shared/start/start.S @@ -482,7 +482,8 @@ bsp_start_hook_0_done: .Lvector_table_copy_done: -#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8 +#if __ARM_ARCH == 6 || (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || \ + __ARM_ARCH >= 8 /* * This code path is only executed by the primary processor. Set the * VBAR to the normal vector table. For secondary processors, this is -- 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 v3] bsps: Move optfdt* files to shared parent directory
---
.../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
spec/build/bsps/arm/beagle/grp.yml | 8
spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16
spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
spec/build/bsps/arm/imx/bspimx.yml | 8
spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
spec/build/bsps/arm/raspberrypi/grp.yml | 8
.../{arm/altera-cyclone-v => }/optfdtcpyro.yml | 0
.../{arm/altera-cyclone-v => }/optfdtmxsz.yml| 0
.../bsps/{arm/altera-cyclone-v => }/optfdtro.yml | 0
.../{arm/altera-cyclone-v => }/optfdtuboot.yml | 0
spec/build/bsps/powerpc/qoriq/grp.yml| 4 ++--
spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml | 16
spec/build/bsps/powerpc/qoriq/optfdtro.yml | 15 ---
spec/build/bsps/riscv/riscv/grp.yml | 8
spec/build/bsps/riscv/riscv/optfdtcpyro.yml | 15 ---
spec/build/bsps/riscv/riscv/optfdtmxsz.yml | 16
spec/build/bsps/riscv/riscv/optfdtro.yml | 15 ---
spec/build/bsps/riscv/riscv/optfdtuboot.yml | 15 ---
24 files changed, 26 insertions(+), 232 deletions(-)
delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtcpyro.yml (100%)
rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtmxsz.yml (100%)
rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtro.yml (100%)
rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtuboot.yml (100%)
delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtro.yml
delete mode 100644 spec/build/bsps/riscv/riscv/optfdtcpyro.yml
delete mode 100644 spec/build/bsps/riscv/riscv/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/riscv/riscv/optfdtro.yml
delete mode 100644 spec/build/bsps/riscv/riscv/optfdtuboot.yml
diff --git a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
index da567ddd79..a9f3f7dabf 100644
--- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
+++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
@@ -73,15 +73,15 @@ links:
- role: build-dependency
uid: optconuart1
- role: build-dependency
- uid: optfdtcpyro
+ uid: ../../optfdtcpyro
- role: build-dependency
uid: optfdten
- role: build-dependency
- uid: optfdtmxsz
+ uid: ../../optfdtmxsz
- role: build-dependency
- uid: optfdtro
+ uid: ../../optfdtro
- role: build-dependency
- uid: optfdtuboot
+ uid: ../../optfdtuboot
- role: build-dependency
uid: opti2cspeed
- role: build-dependency
diff --git a/spec/build/bsps/arm/beagle/grp.yml
b/spec/build/bsps/arm/beagle/grp.yml
index 1375913fd0..3452c3e5c8 100644
--- a/spec/build/bsps/arm/beagle/grp.yml
+++ b/spec/build/bsps/arm/beagle/grp.yml
@@ -22,13 +22,13 @@ links:
- role: build-dependency
uid: optdm3730
- role: build-dependency
- uid: optfdtcpyro
+ uid: ../../optfdtcpyro
- role: build-dependency
- uid: optfdtmxsz
+ uid: ../../optfdtmxsz
- role: build-dependency
- uid: optfdtro
+ uid: ../../optfdtro
- role: build-dependency
- uid: optfdtuboot
+ uid: ../../optfdtuboot
- role: build-dependency
uid: ../grp
- role: build-dependency
diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
deleted file mode 100644
index c26b1ae051..00
--- a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
-actions:
-- get-boolean: null
-- define-condition: null
-build-type: option
-copyrights:
-- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
-default: true
-default-by-variant: []
-description: |
- copy the FDT blob into the read-only load area via bsp_fdt_copy()
-enabled-by: true
-links: []
-name: BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
-type: build
diff --git a/spec/build/bsps/arm/beagle/optfdtmxsz.yml
b/spec/build/bsps/arm/beagle/optfdtmxsz.yml
deleted file mode 100644
Re: [rtems commit] Update Strong APA Scheduler
On 01/07/2021 09:47, Richi Dubey wrote: Hi, How do I reproduce this? I tried using the config produced by $ ./waf bsp_defaults --rtems-bsps=arm/realview_pbx_a9_qemu This BSP uses -O0 by default. Use OPTIMIZATION_FLAGS = -O2 -g to get the warnings. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] Update Strong APA Scheduler
Hi,
How do I reproduce this? I tried using the config produced by
$ ./waf bsp_defaults --rtems-bsps=arm/realview_pbx_a9_qemu
which has:
# Warning flags passed to the C and C++ compiler
WARNING_FLAGS = -Wall
and I enabled the SMP tests:
# Enable the Symmetric Multiprocessing (SMP) support
RTEMS_SMP = True
...
# Build the test programs
BUILD_TESTS = True
It still does not show me any warning during the step
$ ./waf
Also, why do we have both:
# Warning flags passed to the C and C++ compiler
WARNING_FLAGS = -Wall
# Warning flags passed to the C compiler
CC_WARNING_FLAGS = -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs
Does not "-Wall" cover all the warnings? Why are we passing arguments for
some warnings individually when we already passed -Wall?
On Wed, Jun 30, 2021 at 11:18 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> This patch introduced new warnings:
>
> ../../../cpukit/score/src/schedulerstrongapa.c: In function
> '_Scheduler_strong_APA_Get_highest_ready':
> ../../../cpukit/score/src/schedulerstrongapa.c:394:10: warning:
> 'highest_ready' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>394 | if ( curr_node == highest_ready ) {
>| ^
> ../../../cpukit/score/src/schedulerstrongapa.c: In function
> '_Scheduler_strong_APA_Enqueue':
> ../../../cpukit/score/src/schedulerstrongapa.c:600:38: warning:
> 'cpu_to_preempt' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>600 | curr_strong_node->cpu_to_preempt = cpu_to_preempt;
>| ~^~~~
> ../../../cpukit/score/src/schedulerstrongapa.c:676:33: note:
> 'cpu_to_preempt' was declared here
>676 | Per_CPU_Control *cpu_to_preempt;
>| ^~
> In file included from ../../../cpukit/include/rtems/score/objectdata.h:25,
> from ../../../cpukit/include/rtems/score/thread.h:32,
> from ../../../cpukit/include/rtems/score/scheduler.h:23,
> from
> ../../../cpukit/include/rtems/score/schedulerstrongapa.h:41,
> from ../../../cpukit/score/src/schedulerstrongapa.c:67:
> ../../../cpukit/include/rtems/score/chainimpl.h:677:18: warning:
> 'lowest_reachable' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>677 | the_node->next = tail;
>| ~~~^~
> ../../../cpukit/score/src/schedulerstrongapa.c:497:32: note:
> 'lowest_reachable' was declared here
>497 | Scheduler_Node *lowest_reachable;
> --
> 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] tester: Add Versal VCK190 eval board TFTP support
From: Chris Johns
---
.../testing/bsps/xilinx_versal_vck190.ini | 43 +++
1 file changed, 43 insertions(+)
create mode 100644 tester/rtems/testing/bsps/xilinx_versal_vck190.ini
diff --git a/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
b/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
new file mode 100644
index 000..3bdd6be
--- /dev/null
+++ b/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
@@ -0,0 +1,43 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2021 Chris Johns (chr...@rtems.org)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+#
+
+#
+# The Xilinx Zynq Zedboard and Microzed board connected via TFTP. The console
+# is connected to a telnet tty device.
+#
+[xilinx_versal_vck190]
+bsp= xilinx_versal_vck190
+arch = aarch64
+tester = %{_rtscripts}/tftp.cfg
+jobs = 1
+test_restarts = 3
+target_reset_regex = ^No ethernet found.*|^BOOTP broadcast 6.*|^.+complete\.+
TIMEOUT.*
+target_start_regex = .* PSCI Power Domain Map:$|^U-Boot .*
+requires = target_on_command, target_off_command,
target_reset_command, bsp_tty_dev
--
2.24.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
