Re: Build Linux: FAILED 5/bsps/atsamv on x86_64-linux-gnu (rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1)

[Sebastian Huber]

Hello,

I am not sure what we should do with this one. The libbsd is well 
supported on this BSP, however, with default options, the BSP has not 
enough memory to link all the libbsd tests. For this BSP you likely have 
to specify some BSP options to build it for your target. I suggest to 
remove this build set.


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

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

[Alan Cudmore]

Chris,
I tested this release on the Raspberry Pi (Zero), Raspberry Pi 2,
Beaglebone Black with LibBSD, xilinx_zynq_a9_qemu, and partially on
the leon3. ( samples all work on Leon3 QEMU, but I'm still configuring
my application )

To help generate tools and BSPs for releases like this, I created a
series of Dockerfiles to generate a base system, Add tools, then build
BSPs. I was learning docker, and I thought generating release
candidate images might be a good exercise :)

Here are the Dockerfiles in case anyone is interested:
https://github.com/alanc98/rtems-release-docker

To use these, create the "rtems5-m2004-base" image first, then for the
ARM tools, the "rtems5-m2004-arm-tools" image. Finally, you can create
an image like "rtems5-m2004-arm-bbb" to build the RTEMS BSP and
rtems-libbsd for the Beaglebone Black.

The resulting Docker image will allow you to build RTEMS applications
that are shared through the "/host" directory in the container.

With these, I hope to be able to crank out a series of builds for the
targets I'm interested in for future releases.

I'm also working on integration of my RTEMS Kernel Image (RKI) with
rtems-libbsd. I have it working on the Beaglebone black and the
zynq_a9_qemu target. That is a work in progress here:
https://github.com/alanc98/rki2
All of the above targets work except for the leon3 right now. (
Raspberry Pi targets are not libbsd)

Alan

On Thu, Apr 2, 2020 at 6:13 AM  wrote:
>
> RTEMS Release Build - 5.0.0-m2004
>
> RTEMS 5 Release snapshot m2004 is avaliable for testing.
> It can be found at:
>
>  https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2004
>
> Please test and report any issues to the u...@rtems.org or devel@rtems.org
> mailing lists or please raise a ticket.
>
> If you are part of the RTEMS testing program please build on your preferred
> host posting build and BSP test results to bu...@rtems.org.
>
> This is a development release and may have errors and be unstable.
>
> Thanks
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Failures on Overnight build sweep

[Chris Johns]

On 2020-04-06 22:06, Christian Mauderer wrote:

I checked it: Chris pulled that one in together with the reverted commit
from Sebastian today at about 7:00 UTC. So both patches are included in
current RSB master.

Sorry for missing that step. It's something normally not really
necessary during normal development (except if we really want to have a
commit for every RTEMS commit) and I'm still not aware of a lot of stuff
that is touched by the release.


I think the rules to guide us are ...

If anyone pushes a patch to rtems.git or rtems-libbsd.git branch 
5-freebsd-12 the corresponding RSB configs need to be updated. If you 
think the patch does not warrant an update of these configurations then 
please do not push the patch and please consider not posting the patches 
for review. This helps Joel, Gedare and I figure out where we stand in 
getting the release stable so a branch can be made.


There is a small window of difference between the git builds from the 
RSB and a release. The RSB git builds use the hash in the config file 
while a release uses the sources held in the release URL and the release 
scripts that create the release source packages for rtems.git and 
rtems-libbsd.git use the branch's HEAD. This is the key reason we 
currently need to keep the RSB configs at the HEAD.


Once we branch these restrictions can be relaxed so the sooner this 
happens the sooner the restrictions can be relaxed.


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

PC BSP bset failure

[Joel Sherrill]

Hi

I haven't investigated them all but the pc fails to build libbsd and I
thought this one should work given recent attention:

  50/1916] Compiling freebsd/lib/libc/rpc/clnt_dg.c
[  51/1916] Compiling freebsd/sbin/sysctl/sysctl.c
../../freebsd/sbin/sysctl/sysctl.c:72:10: fatal error: machine/pc/bios.h:
No such file or directory
 #include 
  ^~~
compilation terminated.

Waf: Leaving directory
`/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/i386-rtems5-pc686-default'
Build failed
 -> task in 'objs02' failed with exit status 1 (run with -v to display more
information)
shell cmd failed: /bin/sh -ex
 
/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/do-build
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] user/bsps: Moving all other M68K BSPs from Wiki to User

[Gedare Bloom]

On Mon, Apr 6, 2020 at 3:26 PM Mritunjay  wrote:
>
> ---
>  user/bsps/bsps-m68k.rst | 829 +++-
>  1 file changed, 818 insertions(+), 11 deletions(-)
>
> diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
> index bdb516b..a035137 100644
> --- a/user/bsps/bsps-m68k.rst
> +++ b/user/bsps/bsps-m68k.rst
> @@ -8,7 +8,22 @@ m68k (Motorola 68000 / ColdFire)
>  av5282
>  ==
>
> -TODO.
> +Overview
> +-
> +
> +The Freescale ColdFire? Evaluation Board provides a reference platform for
?

Please make sure to read the text after you copy-paste and reformat
it. You should also build the docs and read, at least the html.

> +engineers to develop a variety of embedded processing applications requiring
> +networking connectivity. The board hosts all the necessary hardware and 
> firmware
> +needed to implement a networked interface using the Freescale MCF5282 
> processor.
> +By including all the necessary physical layer (PHY) devices, memory and 
> external
> +expansion capability the designer can implement any bridging application that
> +requires 10/100 Ethernet, UARTs, CAN interface, QSPI, analog inputs and/or
> +memory-mapped peripherals. The AvBus expansion connector allows for user 
> defined
> +add-on hardware, or can be utilized with over 20 compatible evaluation and
> +development boards from Avnet Electronics Marketing. These boards can be 
> mixed
> +and matched to provide a variety of additional hardware and firmware 
> capability
> +from PCI and PCI-X connectivity, RapidIO, memory and communications and
> +video/audio functions.
>
>  csb360
>  ==
> @@ -18,27 +33,372 @@ TODO.
>  gen68340
>  
>
> -TODO.
> +Overview
> +
> +
> +The MC68340 is a high-performance 32-bit integrated processor with direct 
> memory
> +access (DMA), combining an enhanced M68000-compatible processor, 32-bit DMA, 
> and
> +other peripheral subsystems on a single integrated circuit. The MC68340 CPU32
> +delivers 32-bit CISC processor performance from a lower cost 16-bit memory
> +system. The combination of peripherals offered in the MC68340 can be found 
> in a
> +diverse range of microprocessor-based systems.Systems requiring very 
> high-speed
space after period

> +block transfers of data can benefit from the MC68340.
> +
> +Organization
> +-
need one more -?
> +
> +The M68300 family of integrated processors and controllers is built on an 
> M68000
> +core processor, an on-chip bus, and a selection of intelligent peripherals
> +appropriate for a set of applications. The CPU32 is a powerful central
> +processor with nearly the performance of the MC68020. A system integration
> +module incorporates the external bus interface and many of the smaller 
> circuits
> +that typically surround a microprocessor for address decoding, wait-state
> +insertion, interrupt prioritization, clock generation, arbitration, watchdog
> +timing, and power-on reset timing. Each member of the M68300 family is
> +distinguished by its selection of peripherals. Peripherals are chosen to 
> address
> +specific applications but are often useful in a wide variety of applications.
> +The peripherals may be highly sophisticated timing or protocol engines that 
> have
> +their own processors, or they may be more traditional peripheral functions, 
> such
> +as UARTs and timers. Since each major function is designed in a standalone
> +module, each module might be found in many different M68300 family parts.
> +
> +Architecture
> +-
Need one more -?

> +
> +The CPU32 is upward source- and object-code compatible with the MC68000 and
> +MC68010. It is downward source- and object-code compatible with the MC68020.
> +Within the M68000 family, architectural differences are limited to the
> +supervisory operating state. User state programs can be executed unchanged on
> +upward-compatible devices. The major CPU32 features are as follows:
> +
> +* 32-Bit Internal Data Path and Arithmetic Hardware
> +* 32-Bit Address Bus Supported by 32-Bit Calculations
> +* Rich Instruction Set
> +* Eight 32-Bit General-Purpose Data Registers
> +* Seven 32-Bit General-Purpose Address Registers
> +* Separate User and Supervisor Stack Pointers
> +* Separate User and Supervisor State Address Spaces
> +* Separate Program and Data Address Spaces
> +* Many Data Types
> +* Flexible Addressing Modes
> +* Full Interrupt Processing
> +* Expansion Capability
> +
> +The CPU32 is an M68000 family processor specially designed for use as a 
> 32-bit
> +core processor and for operation over the intermodule bus (IMB). Designers 
> used
> +the MC68020 as a model and included advances of the later M68000 family
> +processors, resulting in an instruction execution performance of 4 MIPS
> +(VAX-equivalent) at 25.16 MHz. The powerful and flexible M68000 architecture 
> is
> +the basis of the CPU32. MC68000 (including the MC68HC000 and the MC68EC000) 
> and
> +MC68010 user programs will run unmodified on the CPU32. 

Re: [PATCH rtems-docs] user/bsps: Moving all other M68K BSPs from Wiki to User

[Mritunjay Sharma]

Hi all,

After this patch, you can safely remove all the Motorola M68xxx and
Coldfire BSPs
from the wiki except probably mvme162lx (It was not mentioned in the
user/bsps/bsps-m68k.rst , does it also has to be added?)

Thanks
-Mritunjay

On Tue, Apr 7, 2020 at 2:56 AM Mritunjay 
wrote:

> ---
>  user/bsps/bsps-m68k.rst | 829 +++-
>  1 file changed, 818 insertions(+), 11 deletions(-)
>
> diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
> index bdb516b..a035137 100644
> --- a/user/bsps/bsps-m68k.rst
> +++ b/user/bsps/bsps-m68k.rst
> @@ -8,7 +8,22 @@ m68k (Motorola 68000 / ColdFire)
>  av5282
>  ==
>
> -TODO.
> +Overview
> +-
> +
> +The Freescale ColdFire? Evaluation Board provides a reference platform for
> +engineers to develop a variety of embedded processing applications
> requiring
> +networking connectivity. The board hosts all the necessary hardware and
> firmware
> +needed to implement a networked interface using the Freescale MCF5282
> processor.
> +By including all the necessary physical layer (PHY) devices, memory and
> external
> +expansion capability the designer can implement any bridging application
> that
> +requires 10/100 Ethernet, UARTs, CAN interface, QSPI, analog inputs and/or
> +memory-mapped peripherals. The AvBus expansion connector allows for user
> defined
> +add-on hardware, or can be utilized with over 20 compatible evaluation and
> +development boards from Avnet Electronics Marketing. These boards can be
> mixed
> +and matched to provide a variety of additional hardware and firmware
> capability
> +from PCI and PCI-X connectivity, RapidIO, memory and communications and
> +video/audio functions.
>
>  csb360
>  ==
> @@ -18,27 +33,372 @@ TODO.
>  gen68340
>  
>
> -TODO.
> +Overview
> +
> +
> +The MC68340 is a high-performance 32-bit integrated processor with direct
> memory
> +access (DMA), combining an enhanced M68000-compatible processor, 32-bit
> DMA, and
> +other peripheral subsystems on a single integrated circuit. The MC68340
> CPU32
> +delivers 32-bit CISC processor performance from a lower cost 16-bit memory
> +system. The combination of peripherals offered in the MC68340 can be
> found in a
> +diverse range of microprocessor-based systems.Systems requiring very
> high-speed
> +block transfers of data can benefit from the MC68340.
> +
> +Organization
> +-
> +
> +The M68300 family of integrated processors and controllers is built on an
> M68000
> +core processor, an on-chip bus, and a selection of intelligent peripherals
> +appropriate for a set of applications. The CPU32 is a powerful central
> +processor with nearly the performance of the MC68020. A system integration
> +module incorporates the external bus interface and many of the smaller
> circuits
> +that typically surround a microprocessor for address decoding, wait-state
> +insertion, interrupt prioritization, clock generation, arbitration,
> watchdog
> +timing, and power-on reset timing. Each member of the M68300 family is
> +distinguished by its selection of peripherals. Peripherals are chosen to
> address
> +specific applications but are often useful in a wide variety of
> applications.
> +The peripherals may be highly sophisticated timing or protocol engines
> that have
> +their own processors, or they may be more traditional peripheral
> functions, such
> +as UARTs and timers. Since each major function is designed in a standalone
> +module, each module might be found in many different M68300 family parts.
> +
> +Architecture
> +-
> +
> +The CPU32 is upward source- and object-code compatible with the MC68000
> and
> +MC68010. It is downward source- and object-code compatible with the
> MC68020.
> +Within the M68000 family, architectural differences are limited to the
> +supervisory operating state. User state programs can be executed
> unchanged on
> +upward-compatible devices. The major CPU32 features are as follows:
> +
> +* 32-Bit Internal Data Path and Arithmetic Hardware
> +* 32-Bit Address Bus Supported by 32-Bit Calculations
> +* Rich Instruction Set
> +* Eight 32-Bit General-Purpose Data Registers
> +* Seven 32-Bit General-Purpose Address Registers
> +* Separate User and Supervisor Stack Pointers
> +* Separate User and Supervisor State Address Spaces
> +* Separate Program and Data Address Spaces
> +* Many Data Types
> +* Flexible Addressing Modes
> +* Full Interrupt Processing
> +* Expansion Capability
> +
> +The CPU32 is an M68000 family processor specially designed for use as a
> 32-bit
> +core processor and for operation over the intermodule bus (IMB).
> Designers used
> +the MC68020 as a model and included advances of the later M68000 family
> +processors, resulting in an instruction execution performance of 4 MIPS
> +(VAX-equivalent) at 25.16 MHz. The powerful and flexible M68000
> architecture is
> +the basis of the CPU32. MC68000 (including the MC68HC000 and the
> MC68EC000) and
> +MC68010 user 

[PATCH rtems-docs] user/bsps: Moving all other M68K BSPs from Wiki to User

[Mritunjay]

---
 user/bsps/bsps-m68k.rst | 829 +++-
 1 file changed, 818 insertions(+), 11 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index bdb516b..a035137 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -8,7 +8,22 @@ m68k (Motorola 68000 / ColdFire)
 av5282
 ==

-TODO.
+Overview
+-
+
+The Freescale ColdFire? Evaluation Board provides a reference platform for
+engineers to develop a variety of embedded processing applications requiring
+networking connectivity. The board hosts all the necessary hardware and 
firmware
+needed to implement a networked interface using the Freescale MCF5282 
processor.
+By including all the necessary physical layer (PHY) devices, memory and 
external
+expansion capability the designer can implement any bridging application that
+requires 10/100 Ethernet, UARTs, CAN interface, QSPI, analog inputs and/or
+memory-mapped peripherals. The AvBus expansion connector allows for user 
defined
+add-on hardware, or can be utilized with over 20 compatible evaluation and
+development boards from Avnet Electronics Marketing. These boards can be mixed
+and matched to provide a variety of additional hardware and firmware capability
+from PCI and PCI-X connectivity, RapidIO, memory and communications and
+video/audio functions.

 csb360
 ==
@@ -18,27 +33,372 @@ TODO.
 gen68340
 

-TODO.
+Overview
+
+
+The MC68340 is a high-performance 32-bit integrated processor with direct 
memory
+access (DMA), combining an enhanced M68000-compatible processor, 32-bit DMA, 
and
+other peripheral subsystems on a single integrated circuit. The MC68340 CPU32
+delivers 32-bit CISC processor performance from a lower cost 16-bit memory
+system. The combination of peripherals offered in the MC68340 can be found in a
+diverse range of microprocessor-based systems.Systems requiring very high-speed
+block transfers of data can benefit from the MC68340.
+
+Organization
+-
+
+The M68300 family of integrated processors and controllers is built on an 
M68000
+core processor, an on-chip bus, and a selection of intelligent peripherals
+appropriate for a set of applications. The CPU32 is a powerful central
+processor with nearly the performance of the MC68020. A system integration
+module incorporates the external bus interface and many of the smaller circuits
+that typically surround a microprocessor for address decoding, wait-state
+insertion, interrupt prioritization, clock generation, arbitration, watchdog
+timing, and power-on reset timing. Each member of the M68300 family is
+distinguished by its selection of peripherals. Peripherals are chosen to 
address
+specific applications but are often useful in a wide variety of applications.
+The peripherals may be highly sophisticated timing or protocol engines that 
have
+their own processors, or they may be more traditional peripheral functions, 
such
+as UARTs and timers. Since each major function is designed in a standalone
+module, each module might be found in many different M68300 family parts.
+
+Architecture
+-
+
+The CPU32 is upward source- and object-code compatible with the MC68000 and
+MC68010. It is downward source- and object-code compatible with the MC68020.
+Within the M68000 family, architectural differences are limited to the
+supervisory operating state. User state programs can be executed unchanged on
+upward-compatible devices. The major CPU32 features are as follows:
+
+* 32-Bit Internal Data Path and Arithmetic Hardware
+* 32-Bit Address Bus Supported by 32-Bit Calculations
+* Rich Instruction Set
+* Eight 32-Bit General-Purpose Data Registers
+* Seven 32-Bit General-Purpose Address Registers
+* Separate User and Supervisor Stack Pointers
+* Separate User and Supervisor State Address Spaces
+* Separate Program and Data Address Spaces
+* Many Data Types
+* Flexible Addressing Modes
+* Full Interrupt Processing
+* Expansion Capability
+
+The CPU32 is an M68000 family processor specially designed for use as a 32-bit
+core processor and for operation over the intermodule bus (IMB). Designers used
+the MC68020 as a model and included advances of the later M68000 family
+processors, resulting in an instruction execution performance of 4 MIPS
+(VAX-equivalent) at 25.16 MHz. The powerful and flexible M68000 architecture is
+the basis of the CPU32. MC68000 (including the MC68HC000 and the MC68EC000) and
+MC68010 user programs will run unmodified on the CPU32. The programmer can use
+any of the eight 32-bit data registers for fast manipulation of data and any of
+the eight 32-bit address registers for indexing data in memory. The CPU32 can
+operate on data types of single bits, binary-coded decimal (BCD)digits, and 8,
+16, and 32 bits. Peripherals and data in memory can reside anywhere in the
+4-Gbyte linear address space. A supervisor operating mode protects system-level
+resources from the more restricted user mode, allowing 

Re: [PATCH 1/2] score: Add and use RTEMS_SYMBOL_NAME()

[Sebastian Huber]

On 06/04/2020 21:40, Gedare Bloom wrote:


On Mon, Apr 6, 2020 at 11:57 AM Sebastian Huber
  wrote:

Update #3799.
---
  cpukit/include/rtems/score/basedefs.h | 21 +
  1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/cpukit/include/rtems/score/basedefs.h 
b/cpukit/include/rtems/score/basedefs.h
index 4589bea4aa..a2eb14a642 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -321,6 +321,19 @@
  #define RTEMS_DECLARE_GLOBAL_SYMBOL( _name ) \
extern char _name[]

+/**
+ * @brief Constructs a symbol name.
+ *
+ * @param _name The user defined name of the symbol.  The name must be a valid
+ *   designator.  On the name a macro expansion is performed.
+ */
+#if defined(__USER_LABEL_PREFIX__)
+  #define RTEMS_SYMBOL_NAME( _name ) RTEMS_XCONCAT( __USER_LABEL_PREFIX__, 
_name )
+#else
+  #define _RTEMS_SYMBOL_NAME( _name ) _name
+  #define RTEMS_SYMBOL_NAME( _name ) _RTEMS_SYMBOL_NAME( _name )

Am just  curious why there is _RTEMS_SYMBOL_NAME here and not in the other path
This is just to perform the macro expansion. In the other path it is 
done by RTEMS_XCONCAT().
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] config: Fix _ISR_Stack_area_end

[Sebastian Huber]

On 06/04/2020 21:42, Gedare Bloom wrote:

On Mon, Apr 6, 2020 at 11:57 AM Sebastian Huber
  wrote:

Update #3799.
---
  cpukit/include/rtems/confdefs/percpu.h | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/confdefs/percpu.h 
b/cpukit/include/rtems/confdefs/percpu.h
index 730571b54a..8ae848659c 100644
--- a/cpukit/include/rtems/confdefs/percpu.h
+++ b/cpukit/include/rtems/confdefs/percpu.h
@@ -96,11 +96,11 @@ RTEMS_DEFINE_GLOBAL_SYMBOL(
  char _ISR_Stack_area_begin[
_CONFIGURE_MAXIMUM_PROCESSORS * CONFIGURE_INTERRUPT_STACK_SIZE
  ] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT )
-RTEMS_SECTION( ".rtemsstack.interrupt.begin" );
+RTEMS_SECTION( ".rtemsstack.interrupt" );

-RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION(
+RTEMS_DEFINE_GLOBAL_SYMBOL(
_ISR_Stack_area_end,
-  ".rtemsstack.interrupt.end"
+  RTEMS_SYMBOL_NAME( _ISR_Stack_area_begin ) + CONFIGURE_INTERRUPT_STACK_SIZE

This needs * _CONFIGURE_MAXIMUM_PROCESSORS?

Oh, yes. This is really amazingly difficult to get right.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] config: Fix _ISR_Stack_area_end

[Gedare Bloom]

On Mon, Apr 6, 2020 at 11:57 AM Sebastian Huber
 wrote:
>
> Update #3799.
> ---
>  cpukit/include/rtems/confdefs/percpu.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/include/rtems/confdefs/percpu.h 
> b/cpukit/include/rtems/confdefs/percpu.h
> index 730571b54a..8ae848659c 100644
> --- a/cpukit/include/rtems/confdefs/percpu.h
> +++ b/cpukit/include/rtems/confdefs/percpu.h
> @@ -96,11 +96,11 @@ RTEMS_DEFINE_GLOBAL_SYMBOL(
>  char _ISR_Stack_area_begin[
>_CONFIGURE_MAXIMUM_PROCESSORS * CONFIGURE_INTERRUPT_STACK_SIZE
>  ] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT )
> -RTEMS_SECTION( ".rtemsstack.interrupt.begin" );
> +RTEMS_SECTION( ".rtemsstack.interrupt" );
>
> -RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION(
> +RTEMS_DEFINE_GLOBAL_SYMBOL(
>_ISR_Stack_area_end,
> -  ".rtemsstack.interrupt.end"
> +  RTEMS_SYMBOL_NAME( _ISR_Stack_area_begin ) + CONFIGURE_INTERRUPT_STACK_SIZE
This needs * _CONFIGURE_MAXIMUM_PROCESSORS?
>  );
>
>  /* Thread stack size configuration */
> --
> 2.16.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] score: Add and use RTEMS_SYMBOL_NAME()

[Gedare Bloom]

On Mon, Apr 6, 2020 at 11:57 AM Sebastian Huber
 wrote:
>
> Update #3799.
> ---
>  cpukit/include/rtems/score/basedefs.h | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/basedefs.h 
> b/cpukit/include/rtems/score/basedefs.h
> index 4589bea4aa..a2eb14a642 100644
> --- a/cpukit/include/rtems/score/basedefs.h
> +++ b/cpukit/include/rtems/score/basedefs.h
> @@ -321,6 +321,19 @@
>  #define RTEMS_DECLARE_GLOBAL_SYMBOL( _name ) \
>extern char _name[]
>
> +/**
> + * @brief Constructs a symbol name.
> + *
> + * @param _name The user defined name of the symbol.  The name must be a 
> valid
> + *   designator.  On the name a macro expansion is performed.
> + */
> +#if defined(__USER_LABEL_PREFIX__)
> +  #define RTEMS_SYMBOL_NAME( _name ) RTEMS_XCONCAT( __USER_LABEL_PREFIX__, 
> _name )
> +#else
> +  #define _RTEMS_SYMBOL_NAME( _name ) _name
> +  #define RTEMS_SYMBOL_NAME( _name ) _RTEMS_SYMBOL_NAME( _name )
Am just  curious why there is _RTEMS_SYMBOL_NAME here and not in the other path

> +#endif
> +
>  /**
>   * @brief Defines a global symbol with the specified name and value.
>   *
> @@ -335,8 +348,8 @@
>  #if defined(__GNUC__)
>#define RTEMS_DEFINE_GLOBAL_SYMBOL( _name, _value ) \
>  __asm__( \
> -  "\t.globl " RTEMS_XSTRING( __USER_LABEL_PREFIX__ ) #_name \
> -  "\n\t.set " RTEMS_XSTRING( __USER_LABEL_PREFIX__ ) #_name \
> +  "\t.globl " RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) \
> +  "\n\t.set " RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) \
>", " RTEMS_STRING( _value ) "\n" \
>  )
>  #else
> @@ -355,8 +368,8 @@
>  __asm__( \
>".pushsection \"" _section "\"\n" \
>"\t.globl " \
> -  RTEMS_XSTRING( RTEMS_XCONCAT( __USER_LABEL_PREFIX__, _name ) ) "\n" \
> -  RTEMS_XSTRING( RTEMS_XCONCAT( __USER_LABEL_PREFIX__, _name ) ) ":\n" \
> +  RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) "\n" \
> +  RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) ":\n" \
>"\t.popsection\n" \
>  )
>  #else
> --
> 2.16.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] dtc: Update to 1.6.0.

[Joel Sherrill]

On Mon, Apr 6, 2020 at 12:29 PM Christian Mauderer 
wrote:

> Hello Joel,
>
> On 06/04/2020 19:09, Joel Sherrill wrote:
> > I tested it and it failed.
> >
> >  CC treesource.o
> > gmake: *** No rule to make target 'yaml.h', needed by 'yamltree.o'.
> Stop.
> > + cd
> >
> /usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1
> > + echo '==> %install:'
> > ==> %install:
> > + pwd
> > +
> >
> build_top=/usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1
> >
> > I am guessing it has picked up a dependency on yaml that is not
> > accounted for.
>
> Hm. Not really good. I checked an the yaml dependency is already there
> in 1.5.1. So most likely the best solution for the release is to just
> switch the default dtc to the 1.4.1 that is already used for spike.
> Otherwise we will have to add libyaml which might isn't a good idea in
> the pre-release phase. What do you think?
>

I completely agree. No further than 1.4. But this bothers me now. I couldn't
build spike. I haven't removed GCC from the machine though.

config.status: creating config.h
configure: WARNING: unrecognized options: --with-fesvr
+ gmake -j 4 'all$'

After we branch, it is probably worth updating. Perhaps a ticket to update
and target 6 as the milestone.

--joel

>
> Best regards
>
> Christian
>
> >
> > This is the place where spike references dtc.
> >
> > ===
> > $ git diff
> > diff --git a/bare/config/devel/spike.bset b/bare/config/devel/spike.bset
> > index 76392f7..bf52b9f 100644
> > --- a/bare/config/devel/spike.bset
> > +++ b/bare/config/devel/spike.bset
> > @@ -4,5 +4,5 @@
> >
> >  %define release 1
> >
> > -devel/dtc-1.4.1-1
> > +devel/dtc-1.6.0-1
> >  devel/spike-1.1.0
> > 
> >
> > On Mon, Apr 6, 2020 at 11:29 AM Joel Sherrill  > > wrote:
> >
> > Before I test it, what about the spike.bset? It still references dtc
> > 1.4?
> >
> > On Mon, Apr 6, 2020 at 10:54 AM Christian Mauderer
> > mailto:o...@c-mauderer.de>> wrote:
> >
> > ---
> >  bare/config/devel/dtc-1.6.0-1.cfg | 18 ++
> >  bare/config/devel/dtc.bset|  2 +-
> >  2 files changed, 19 insertions(+), 1 deletion(-)
> >  create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg
> >
> > diff --git a/bare/config/devel/dtc-1.6.0-1.cfg
> > b/bare/config/devel/dtc-1.6.0-1.cfg
> > new file mode 100644
> > index 000..f293f12
> > --- /dev/null
> > +++ b/bare/config/devel/dtc-1.6.0-1.cfg
> > @@ -0,0 +1,18 @@
> > +#
> > +# DTC (Device Tree Compiler) 1.6.0
> > +#
> > +
> > +%if %{release} == %{nil}
> > +%define release 1
> > +%endif
> > +
> > +%include %{_configdir}/base.cfg
> > +
> > +%define dtc_version 1.6.0
> > +
> > +%hash sha256 dtc-%{dtc_version}.tar.gz
> > 9fbe07223a98f2d7088a340b5505d4dfe682d77580e788d08cfcc1b61d8be237
> > +
> > +#
> > +# The DTC build instructions. We use 1.x.x Release 1.
> > +#
> > +%include %{_configdir}/dtc-1-1.cfg
> > diff --git a/bare/config/devel/dtc.bset
> b/bare/config/devel/dtc.bset
> > index d701f93..6700823 100644
> > --- a/bare/config/devel/dtc.bset
> > +++ b/bare/config/devel/dtc.bset
> > @@ -4,4 +4,4 @@
> >
> >  %define release 1
> >
> > -devel/dtc-1.2.0
> > +devel/dtc-1.6.0-1
> > --
> > 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: bare/qemu broken?

[Joel Sherrill]

On Mon, Apr 6, 2020 at 12:48 PM Joel Sherrill  wrote:

>
>
> On Mon, Apr 6, 2020 at 12:43 PM Gedare Bloom  wrote:
>
>> This is a problem caused by newer versions of perl. The unescaped { }
>> in regex was deprecated and then eliminated. It requires an upstream
>> fix to escape with \.
>>
>
> Unfortunately, it appears that the qemu bset only works on older
> distributions.
> The qemu4 bset is a newer qemu version that builds on newer distributions.
>
> Seems to be a rat hole. It might be worth considering renaming qemu to
> qemu2
> if that's the major version so people have to make a more conscious
> choice.
>

I forgot qemu-couverture. It is there for coverage support.  That's
AdaCore's
tracking version with coverage tracing and it should always work on the
embedded
targets we care about.

--joel


>
>> On Mon, Apr 6, 2020 at 11:38 AM Gedare Bloom  wrote:
>> >
>> > I'm trying to build qemu in RSB, I get a build error, from the tail of
>> > the report it appears as:
>> >
>> >   GEN   kvm_stat.1
>> > Unescaped left brace in regex is illegal here in regex; marked by <--
>> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
>> >
>> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/
>> texi2pod.pl
>> > line 320.
>> > Makefile:509: recipe for target 'qemu-nbd.8' failed
>> > make: *** [qemu-nbd.8] Error 255
>> > make: *** Waiting for unfinished jobs
>> > Unescaped left brace in regex is illegal here in regex; marked by <--
>> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
>> >
>> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/
>> texi2pod.pl
>> > line 320.
>> > Makefile:515: recipe for target 'kvm_stat.1' failed
>> > make: *** [kvm_stat.1] Error 255
>> >   GEN   qga/qapi-generated/qga-qapi-types.h
>> > shell cmd failed: /bin/sh -ex
>> >
>> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/do-build
>> > error: building
>> qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1
>> >   407,1
>>  Bot
>> ___
>> 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

[PATCH 2/2] config: Fix _ISR_Stack_area_end

[Sebastian Huber]

Update #3799.
---
 cpukit/include/rtems/confdefs/percpu.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/confdefs/percpu.h 
b/cpukit/include/rtems/confdefs/percpu.h
index 730571b54a..8ae848659c 100644
--- a/cpukit/include/rtems/confdefs/percpu.h
+++ b/cpukit/include/rtems/confdefs/percpu.h
@@ -96,11 +96,11 @@ RTEMS_DEFINE_GLOBAL_SYMBOL(
 char _ISR_Stack_area_begin[
   _CONFIGURE_MAXIMUM_PROCESSORS * CONFIGURE_INTERRUPT_STACK_SIZE
 ] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT )
-RTEMS_SECTION( ".rtemsstack.interrupt.begin" );
+RTEMS_SECTION( ".rtemsstack.interrupt" );
 
-RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION(
+RTEMS_DEFINE_GLOBAL_SYMBOL(
   _ISR_Stack_area_end,
-  ".rtemsstack.interrupt.end"
+  RTEMS_SYMBOL_NAME( _ISR_Stack_area_begin ) + CONFIGURE_INTERRUPT_STACK_SIZE
 );
 
 /* Thread stack size configuration */
-- 
2.16.4

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

[PATCH 1/2] score: Add and use RTEMS_SYMBOL_NAME()

[Sebastian Huber]

Update #3799.
---
 cpukit/include/rtems/score/basedefs.h | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/cpukit/include/rtems/score/basedefs.h 
b/cpukit/include/rtems/score/basedefs.h
index 4589bea4aa..a2eb14a642 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -321,6 +321,19 @@
 #define RTEMS_DECLARE_GLOBAL_SYMBOL( _name ) \
   extern char _name[]
 
+/**
+ * @brief Constructs a symbol name.
+ *
+ * @param _name The user defined name of the symbol.  The name must be a valid
+ *   designator.  On the name a macro expansion is performed.
+ */
+#if defined(__USER_LABEL_PREFIX__)
+  #define RTEMS_SYMBOL_NAME( _name ) RTEMS_XCONCAT( __USER_LABEL_PREFIX__, 
_name )
+#else
+  #define _RTEMS_SYMBOL_NAME( _name ) _name
+  #define RTEMS_SYMBOL_NAME( _name ) _RTEMS_SYMBOL_NAME( _name )
+#endif
+
 /**
  * @brief Defines a global symbol with the specified name and value.
  *
@@ -335,8 +348,8 @@
 #if defined(__GNUC__)
   #define RTEMS_DEFINE_GLOBAL_SYMBOL( _name, _value ) \
 __asm__( \
-  "\t.globl " RTEMS_XSTRING( __USER_LABEL_PREFIX__ ) #_name \
-  "\n\t.set " RTEMS_XSTRING( __USER_LABEL_PREFIX__ ) #_name \
+  "\t.globl " RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) \
+  "\n\t.set " RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) \
   ", " RTEMS_STRING( _value ) "\n" \
 )
 #else
@@ -355,8 +368,8 @@
 __asm__( \
   ".pushsection \"" _section "\"\n" \
   "\t.globl " \
-  RTEMS_XSTRING( RTEMS_XCONCAT( __USER_LABEL_PREFIX__, _name ) ) "\n" \
-  RTEMS_XSTRING( RTEMS_XCONCAT( __USER_LABEL_PREFIX__, _name ) ) ":\n" \
+  RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) "\n" \
+  RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) ":\n" \
   "\t.popsection\n" \
 )
 #else
-- 
2.16.4

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

Re: [PATCH] sparc64: update linkcmds with missing sections for TLS

[Sebastian Huber]

On 06/04/2020 19:19, Gedare Bloom wrote:


I checked this in. It fixes the testsuite build error reported. I
built niagara and usiii all tests.

Thanks for fixing this.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bare/qemu broken?

[Gedare Bloom]

On Mon, Apr 6, 2020 at 11:49 AM Joel Sherrill  wrote:
>
>
>
> On Mon, Apr 6, 2020 at 12:43 PM Gedare Bloom  wrote:
>>
>> This is a problem caused by newer versions of perl. The unescaped { }
>> in regex was deprecated and then eliminated. It requires an upstream
>> fix to escape with \.
>
>
> Unfortunately, it appears that the qemu bset only works on older 
> distributions.
> The qemu4 bset is a newer qemu version that builds on newer distributions.
>
> Seems to be a rat hole. It might be worth considering renaming qemu to qemu2
> if that's the major version so people have to make a more conscious choice.

I think that is a good idea.

Also, the qemu.bset could build a version of perl that would work?

>>
>>
>> On Mon, Apr 6, 2020 at 11:38 AM Gedare Bloom  wrote:
>> >
>> > I'm trying to build qemu in RSB, I get a build error, from the tail of
>> > the report it appears as:
>> >
>> >   GEN   kvm_stat.1
>> > Unescaped left brace in regex is illegal here in regex; marked by <--
>> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
>> > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
>> > line 320.
>> > Makefile:509: recipe for target 'qemu-nbd.8' failed
>> > make: *** [qemu-nbd.8] Error 255
>> > make: *** Waiting for unfinished jobs
>> > Unescaped left brace in regex is illegal here in regex; marked by <--
>> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
>> > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
>> > line 320.
>> > Makefile:515: recipe for target 'kvm_stat.1' failed
>> > make: *** [kvm_stat.1] Error 255
>> >   GEN   qga/qapi-generated/qga-qapi-types.h
>> > shell cmd failed: /bin/sh -ex
>> > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/do-build
>> > error: building 
>> > qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1
>> >   407,1
>> >  Bot
>> ___
>> 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: bare/qemu broken?

[Gedare Bloom]

On Mon, Apr 6, 2020 at 11:46 AM Gedare Bloom  wrote:
>
> On Mon, Apr 6, 2020 at 11:43 AM Gedare Bloom  wrote:
> >
> > This is a problem caused by newer versions of perl. The unescaped { }
> > in regex was deprecated and then eliminated. It requires an upstream
> > fix to escape with \.
> >
> PS: probably this means we need to bump qemu version in RSB. Suggestions?
>
https://github.com/qemu/qemu/commit/aa5ccadcca3e6018ebd9d2e8b0a0604f7cb0cd59

> > On Mon, Apr 6, 2020 at 11:38 AM Gedare Bloom  wrote:
> > >
> > > I'm trying to build qemu in RSB, I get a build error, from the tail of
> > > the report it appears as:
> > >
> > >   GEN   kvm_stat.1
> > > Unescaped left brace in regex is illegal here in regex; marked by <--
> > > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> > > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
> > > line 320.
> > > Makefile:509: recipe for target 'qemu-nbd.8' failed
> > > make: *** [qemu-nbd.8] Error 255
> > > make: *** Waiting for unfinished jobs
> > > Unescaped left brace in regex is illegal here in regex; marked by <--
> > > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> > > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
> > > line 320.
> > > Makefile:515: recipe for target 'kvm_stat.1' failed
> > > make: *** [kvm_stat.1] Error 255
> > >   GEN   qga/qapi-generated/qga-qapi-types.h
> > > shell cmd failed: /bin/sh -ex
> > > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/do-build
> > > error: building 
> > > qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1
> > >   407,1   
> > >   Bot
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bare/qemu broken?

[Joel Sherrill]

On Mon, Apr 6, 2020 at 12:43 PM Gedare Bloom  wrote:

> This is a problem caused by newer versions of perl. The unescaped { }
> in regex was deprecated and then eliminated. It requires an upstream
> fix to escape with \.
>

Unfortunately, it appears that the qemu bset only works on older
distributions.
The qemu4 bset is a newer qemu version that builds on newer distributions.

Seems to be a rat hole. It might be worth considering renaming qemu to qemu2
if that's the major version so people have to make a more conscious choice.

>
> On Mon, Apr 6, 2020 at 11:38 AM Gedare Bloom  wrote:
> >
> > I'm trying to build qemu in RSB, I get a build error, from the tail of
> > the report it appears as:
> >
> >   GEN   kvm_stat.1
> > Unescaped left brace in regex is illegal here in regex; marked by <--
> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> >
> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/
> texi2pod.pl
> > line 320.
> > Makefile:509: recipe for target 'qemu-nbd.8' failed
> > make: *** [qemu-nbd.8] Error 255
> > make: *** Waiting for unfinished jobs
> > Unescaped left brace in regex is illegal here in regex; marked by <--
> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> >
> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/
> texi2pod.pl
> > line 320.
> > Makefile:515: recipe for target 'kvm_stat.1' failed
> > make: *** [kvm_stat.1] Error 255
> >   GEN   qga/qapi-generated/qga-qapi-types.h
> > shell cmd failed: /bin/sh -ex
> >
> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/do-build
> > error: building
> qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1
> >   407,1
>Bot
> ___
> 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: bare/qemu broken?

[Gedare Bloom]

On Mon, Apr 6, 2020 at 11:43 AM Gedare Bloom  wrote:
>
> This is a problem caused by newer versions of perl. The unescaped { }
> in regex was deprecated and then eliminated. It requires an upstream
> fix to escape with \.
>
PS: probably this means we need to bump qemu version in RSB. Suggestions?

> On Mon, Apr 6, 2020 at 11:38 AM Gedare Bloom  wrote:
> >
> > I'm trying to build qemu in RSB, I get a build error, from the tail of
> > the report it appears as:
> >
> >   GEN   kvm_stat.1
> > Unescaped left brace in regex is illegal here in regex; marked by <--
> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
> > line 320.
> > Makefile:509: recipe for target 'qemu-nbd.8' failed
> > make: *** [qemu-nbd.8] Error 255
> > make: *** Waiting for unfinished jobs
> > Unescaped left brace in regex is illegal here in regex; marked by <--
> > HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
> > line 320.
> > Makefile:515: recipe for target 'kvm_stat.1' failed
> > make: *** [kvm_stat.1] Error 255
> >   GEN   qga/qapi-generated/qga-qapi-types.h
> > shell cmd failed: /bin/sh -ex
> > /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/do-build
> > error: building 
> > qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1
> >   407,1 
> > Bot
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bare/qemu broken?

[Gedare Bloom]

This is a problem caused by newer versions of perl. The unescaped { }
in regex was deprecated and then eliminated. It requires an upstream
fix to escape with \.

On Mon, Apr 6, 2020 at 11:38 AM Gedare Bloom  wrote:
>
> I'm trying to build qemu in RSB, I get a build error, from the tail of
> the report it appears as:
>
>   GEN   kvm_stat.1
> Unescaped left brace in regex is illegal here in regex; marked by <--
> HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
> line 320.
> Makefile:509: recipe for target 'qemu-nbd.8' failed
> make: *** [qemu-nbd.8] Error 255
> make: *** Waiting for unfinished jobs
> Unescaped left brace in regex is illegal here in regex; marked by <--
> HERE in m/^\@strong{ <-- HERE (.*)}$/ at
> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
> line 320.
> Makefile:515: recipe for target 'kvm_stat.1' failed
> make: *** [kvm_stat.1] Error 255
>   GEN   qga/qapi-generated/qga-qapi-types.h
> shell cmd failed: /bin/sh -ex
> /mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/do-build
> error: building 
> qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1
>   407,1 
> Bot
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

bare/qemu broken?

[Gedare Bloom]

I'm trying to build qemu in RSB, I get a build error, from the tail of
the report it appears as:

  GEN   kvm_stat.1
Unescaped left brace in regex is illegal here in regex; marked by <--
HERE in m/^\@strong{ <-- HERE (.*)}$/ at
/mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
line 320.
Makefile:509: recipe for target 'qemu-nbd.8' failed
make: *** [qemu-nbd.8] Error 255
make: *** Waiting for unfinished jobs
Unescaped left brace in regex is illegal here in regex; marked by <--
HERE in m/^\@strong{ <-- HERE (.*)}$/ at
/mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144/scripts/texi2pod.pl
line 320.
Makefile:515: recipe for target 'kvm_stat.1' failed
make: *** [kvm_stat.1] Error 255
  GEN   qga/qapi-generated/qga-qapi-types.h
shell cmd failed: /bin/sh -ex
/mnt/devel/rtems/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1/do-build
error: building qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1
  407,1 Bot
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] dtc: Update to 1.6.0.

[Christian Mauderer]

Hello Joel,

On 06/04/2020 19:09, Joel Sherrill wrote:
> I tested it and it failed.
> 
>          CC treesource.o
> gmake: *** No rule to make target 'yaml.h', needed by 'yamltree.o'.  Stop.
> + cd
> /usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1
> + echo '==> %install:'
> ==> %install:
> + pwd
> +
> build_top=/usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1
> 
> I am guessing it has picked up a dependency on yaml that is not
> accounted for.

Hm. Not really good. I checked an the yaml dependency is already there
in 1.5.1. So most likely the best solution for the release is to just
switch the default dtc to the 1.4.1 that is already used for spike.
Otherwise we will have to add libyaml which might isn't a good idea in
the pre-release phase. What do you think?

Best regards

Christian

> 
> This is the place where spike references dtc.
> 
> ===
> $ git diff
> diff --git a/bare/config/devel/spike.bset b/bare/config/devel/spike.bset
> index 76392f7..bf52b9f 100644
> --- a/bare/config/devel/spike.bset
> +++ b/bare/config/devel/spike.bset
> @@ -4,5 +4,5 @@
>  
>  %define release 1
>  
> -devel/dtc-1.4.1-1
> +devel/dtc-1.6.0-1
>  devel/spike-1.1.0
> 
> 
> On Mon, Apr 6, 2020 at 11:29 AM Joel Sherrill  > wrote:
> 
> Before I test it, what about the spike.bset? It still references dtc
> 1.4?
> 
> On Mon, Apr 6, 2020 at 10:54 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> 
> ---
>  bare/config/devel/dtc-1.6.0-1.cfg | 18 ++
>  bare/config/devel/dtc.bset        |  2 +-
>  2 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg
> 
> diff --git a/bare/config/devel/dtc-1.6.0-1.cfg
> b/bare/config/devel/dtc-1.6.0-1.cfg
> new file mode 100644
> index 000..f293f12
> --- /dev/null
> +++ b/bare/config/devel/dtc-1.6.0-1.cfg
> @@ -0,0 +1,18 @@
> +#
> +# DTC (Device Tree Compiler) 1.6.0
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +%include %{_configdir}/base.cfg
> +
> +%define dtc_version 1.6.0
> +
> +%hash sha256 dtc-%{dtc_version}.tar.gz
> 9fbe07223a98f2d7088a340b5505d4dfe682d77580e788d08cfcc1b61d8be237
> +
> +#
> +# The DTC build instructions. We use 1.x.x Release 1.
> +#
> +%include %{_configdir}/dtc-1-1.cfg
> diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
> index d701f93..6700823 100644
> --- a/bare/config/devel/dtc.bset
> +++ b/bare/config/devel/dtc.bset
> @@ -4,4 +4,4 @@
> 
>  %define release 1
> 
> -devel/dtc-1.2.0
> +devel/dtc-1.6.0-1
> -- 
> 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] sparc64: update linkcmds with missing sections for TLS

[Gedare Bloom]

I checked this in. It fixes the testsuite build error reported. I
built niagara and usiii all tests.

On Mon, Apr 6, 2020 at 11:16 AM Gedare Bloom  wrote:
>
> Closes #3936.
> ---
>  bsps/sparc64/shared/start/linkcmds | 74 +-
>  1 file changed, 22 insertions(+), 52 deletions(-)
>
> diff --git a/bsps/sparc64/shared/start/linkcmds 
> b/bsps/sparc64/shared/start/linkcmds
> index 86a3bdcde1..aaf48b5d83 100644
> --- a/bsps/sparc64/shared/start/linkcmds
> +++ b/bsps/sparc64/shared/start/linkcmds
> @@ -36,56 +36,6 @@ SECTIONS
>.gnu.version   : { *(.gnu.version)   }
>.gnu.version_d   : { *(.gnu.version_d)   }
>.gnu.version_r   : { *(.gnu.version_r)   }
> -  .rel.init  : { *(.rel.init)  }
> -  .rela.init : { *(.rela.init) }
> -  .rel.text  :
> -{
> -  *(.rel.text)
> -  *(.rel.text.*)
> -  *(.rel.gnu.linkonce.t*)
> -}
> -  .rela.text :
> -{
> -  *(.rela.text)
> -  *(.rela.text.*)
> -  *(.rela.gnu.linkonce.t*)
> -}
> -  .rel.fini  : { *(.rel.fini)  }
> -  .rela.fini : { *(.rela.fini) }
> -  .rel.rodata:
> -{
> -  *(.rel.rodata)
> -  *(.rel.rodata.*)
> -  *(.rel.gnu.linkonce.r*)
> -}
> -  .rela.rodata   :
> -{
> -  *(.rela.rodata)
> -  *(.rela.rodata.*)
> -  *(.rela.gnu.linkonce.r*)
> -}
> -  .rel.data  :
> -{
> -  *(.rel.data)
> -  *(.rel.data.*)
> -  *(.rel.gnu.linkonce.d*)
> -}
> -  .rela.data :
> -{
> -  *(.rela.data)
> -  *(.rela.data.*)
> -  *(.rela.gnu.linkonce.d*)
> -}
> -  .rel.ctors : { *(.rel.ctors) }
> -  .rela.ctors: { *(.rela.ctors)}
> -  .rel.dtors : { *(.rel.dtors) }
> -  .rela.dtors: { *(.rela.dtors)}
> -  .rel.got   : { *(.rel.got)   }
> -  .rela.got  : { *(.rela.got)  }
> -  .rel.bss   : { *(.rel.bss)   }
> -  .rela.bss  : { *(.rela.bss)  }
> -  .rel.plt   : { *(.rel.plt)   }
> -  .rela.plt  : { *(.rela.plt)  }
>/* Internal text space or external memory */
>.text 0x4000 : AT (0x4000)
>{
> @@ -168,8 +118,25 @@ SECTIONS
>_TLS_BSS_size = _TLS_BSS_end - _TLS_BSS_begin;
>_TLS_Size = _TLS_BSS_end - _TLS_Data_begin;
>_TLS_Alignment = MAX (ALIGNOF (.tdata), ALIGNOF (.tbss));
> -
> -  .data  : AT (ADDR (.tbss) + SIZEOF (.tbss))
> +
> +  .rela.dyn : AT (ADDR (.tbss) + SIZEOF (.tbss))
> +  {
> +*(.rela.init)
> +*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
> +*(.rela.fini)
> +*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
> +*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
> +*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
> +*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
> +*(.rela.ctors)
> +*(.rela.dtors)
> +*(.rela.got)
> +*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
> +*(.rela.rtemsroset*)
> +*(.rela.rtemsrwset*)
> +  } > ram
> +
> +  .data  : AT (ADDR (.rela.dyn) + SIZEOF (.rela.dyn))
>{
>   PROVIDE (__data_start = .) ;
>  data_start = . ;
> @@ -193,6 +160,9 @@ SECTIONS
> . = ALIGN (16);
>.dynamic   : { *(.dynamic)   } >ram
>.jcr: { *(.jcr) } > ram
> +  .got   : { *(.got)   } >ram
> +  .plt   : { *(.plt)   } >ram
> +  .dynrel: { *(.dynrel)} >ram
>.shbss  : { *(.shbss)  } > ram
>.bss:
>{
> --
> 2.17.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] sparc64: update linkcmds with missing sections for TLS

[Gedare Bloom]

Closes #3936.
---
 bsps/sparc64/shared/start/linkcmds | 74 +-
 1 file changed, 22 insertions(+), 52 deletions(-)

diff --git a/bsps/sparc64/shared/start/linkcmds 
b/bsps/sparc64/shared/start/linkcmds
index 86a3bdcde1..aaf48b5d83 100644
--- a/bsps/sparc64/shared/start/linkcmds
+++ b/bsps/sparc64/shared/start/linkcmds
@@ -36,56 +36,6 @@ SECTIONS
   .gnu.version   : { *(.gnu.version)   }
   .gnu.version_d   : { *(.gnu.version_d)   }
   .gnu.version_r   : { *(.gnu.version_r)   }
-  .rel.init  : { *(.rel.init)  }
-  .rela.init : { *(.rela.init) }
-  .rel.text  :
-{
-  *(.rel.text)
-  *(.rel.text.*)
-  *(.rel.gnu.linkonce.t*)
-}
-  .rela.text :
-{
-  *(.rela.text)
-  *(.rela.text.*)
-  *(.rela.gnu.linkonce.t*)
-}
-  .rel.fini  : { *(.rel.fini)  }
-  .rela.fini : { *(.rela.fini) }
-  .rel.rodata:
-{
-  *(.rel.rodata)
-  *(.rel.rodata.*)
-  *(.rel.gnu.linkonce.r*)
-}
-  .rela.rodata   :
-{
-  *(.rela.rodata)
-  *(.rela.rodata.*)
-  *(.rela.gnu.linkonce.r*)
-}
-  .rel.data  :
-{
-  *(.rel.data)
-  *(.rel.data.*)
-  *(.rel.gnu.linkonce.d*)
-}
-  .rela.data :
-{
-  *(.rela.data)
-  *(.rela.data.*)
-  *(.rela.gnu.linkonce.d*)
-}
-  .rel.ctors : { *(.rel.ctors) }
-  .rela.ctors: { *(.rela.ctors)}
-  .rel.dtors : { *(.rel.dtors) }
-  .rela.dtors: { *(.rela.dtors)}
-  .rel.got   : { *(.rel.got)   }
-  .rela.got  : { *(.rela.got)  }
-  .rel.bss   : { *(.rel.bss)   }
-  .rela.bss  : { *(.rela.bss)  }
-  .rel.plt   : { *(.rel.plt)   }
-  .rela.plt  : { *(.rela.plt)  }
   /* Internal text space or external memory */
   .text 0x4000 : AT (0x4000)
   {
@@ -168,8 +118,25 @@ SECTIONS
   _TLS_BSS_size = _TLS_BSS_end - _TLS_BSS_begin;
   _TLS_Size = _TLS_BSS_end - _TLS_Data_begin;
   _TLS_Alignment = MAX (ALIGNOF (.tdata), ALIGNOF (.tbss));
-  
-  .data  : AT (ADDR (.tbss) + SIZEOF (.tbss))
+ 
+  .rela.dyn : AT (ADDR (.tbss) + SIZEOF (.tbss))
+  {
+*(.rela.init)
+*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
+*(.rela.fini)
+*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
+*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
+*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
+*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
+*(.rela.ctors)
+*(.rela.dtors)
+*(.rela.got)
+*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
+*(.rela.rtemsroset*)
+*(.rela.rtemsrwset*)
+  } > ram
+
+  .data  : AT (ADDR (.rela.dyn) + SIZEOF (.rela.dyn))
   {
  PROVIDE (__data_start = .) ;
 data_start = . ;
@@ -193,6 +160,9 @@ SECTIONS
. = ALIGN (16);
   .dynamic   : { *(.dynamic)   } >ram
   .jcr: { *(.jcr) } > ram
+  .got   : { *(.got)   } >ram
+  .plt   : { *(.plt)   } >ram
+  .dynrel: { *(.dynrel)} >ram
   .shbss  : { *(.shbss)  } > ram
   .bss:
   {
-- 
2.17.1

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

Re: [PATCH rtems-source-builder] dtc: Update to 1.6.0.

[Joel Sherrill]

I tested it and it failed.

 CC treesource.o
gmake: *** No rule to make target 'yaml.h', needed by 'yamltree.o'.  Stop.
+ cd
/usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1
+ echo '==> %install:'
==> %install:
+ pwd
+
build_top=/usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1

I am guessing it has picked up a dependency on yaml that is not accounted
for.

This is the place where spike references dtc.

===
$ git diff
diff --git a/bare/config/devel/spike.bset b/bare/config/devel/spike.bset
index 76392f7..bf52b9f 100644
--- a/bare/config/devel/spike.bset
+++ b/bare/config/devel/spike.bset
@@ -4,5 +4,5 @@

 %define release 1

-devel/dtc-1.4.1-1
+devel/dtc-1.6.0-1
 devel/spike-1.1.0


On Mon, Apr 6, 2020 at 11:29 AM Joel Sherrill  wrote:

> Before I test it, what about the spike.bset? It still references dtc 1.4?
>
> On Mon, Apr 6, 2020 at 10:54 AM Christian Mauderer 
> wrote:
>
>> ---
>>  bare/config/devel/dtc-1.6.0-1.cfg | 18 ++
>>  bare/config/devel/dtc.bset|  2 +-
>>  2 files changed, 19 insertions(+), 1 deletion(-)
>>  create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg
>>
>> diff --git a/bare/config/devel/dtc-1.6.0-1.cfg
>> b/bare/config/devel/dtc-1.6.0-1.cfg
>> new file mode 100644
>> index 000..f293f12
>> --- /dev/null
>> +++ b/bare/config/devel/dtc-1.6.0-1.cfg
>> @@ -0,0 +1,18 @@
>> +#
>> +# DTC (Device Tree Compiler) 1.6.0
>> +#
>> +
>> +%if %{release} == %{nil}
>> +%define release 1
>> +%endif
>> +
>> +%include %{_configdir}/base.cfg
>> +
>> +%define dtc_version 1.6.0
>> +
>> +%hash sha256 dtc-%{dtc_version}.tar.gz
>> 9fbe07223a98f2d7088a340b5505d4dfe682d77580e788d08cfcc1b61d8be237
>> +
>> +#
>> +# The DTC build instructions. We use 1.x.x Release 1.
>> +#
>> +%include %{_configdir}/dtc-1-1.cfg
>> diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
>> index d701f93..6700823 100644
>> --- a/bare/config/devel/dtc.bset
>> +++ b/bare/config/devel/dtc.bset
>> @@ -4,4 +4,4 @@
>>
>>  %define release 1
>>
>> -devel/dtc-1.2.0
>> +devel/dtc-1.6.0-1
>> --
>> 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 rtems-source-builder] dtc: Update to 1.6.0.

[Joel Sherrill]

Before I test it, what about the spike.bset? It still references dtc 1.4?

On Mon, Apr 6, 2020 at 10:54 AM Christian Mauderer 
wrote:

> ---
>  bare/config/devel/dtc-1.6.0-1.cfg | 18 ++
>  bare/config/devel/dtc.bset|  2 +-
>  2 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg
>
> diff --git a/bare/config/devel/dtc-1.6.0-1.cfg
> b/bare/config/devel/dtc-1.6.0-1.cfg
> new file mode 100644
> index 000..f293f12
> --- /dev/null
> +++ b/bare/config/devel/dtc-1.6.0-1.cfg
> @@ -0,0 +1,18 @@
> +#
> +# DTC (Device Tree Compiler) 1.6.0
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +%include %{_configdir}/base.cfg
> +
> +%define dtc_version 1.6.0
> +
> +%hash sha256 dtc-%{dtc_version}.tar.gz
> 9fbe07223a98f2d7088a340b5505d4dfe682d77580e788d08cfcc1b61d8be237
> +
> +#
> +# The DTC build instructions. We use 1.x.x Release 1.
> +#
> +%include %{_configdir}/dtc-1-1.cfg
> diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
> index d701f93..6700823 100644
> --- a/bare/config/devel/dtc.bset
> +++ b/bare/config/devel/dtc.bset
> @@ -4,4 +4,4 @@
>
>  %define release 1
>
> -devel/dtc-1.2.0
> +devel/dtc-1.6.0-1
> --
> 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

[PATCH rtems-source-builder 0/1] dtc: Update to 1.6.0

[Christian Mauderer]

Hello,

Joel mentioned in the following thread that the DTC build with RSB is a
bit old:

https://lists.rtems.org/pipermail/devel/2020-April/059026.html

This patch updates it to the latest V1.6.0.

I tested it only with Linux. So we should definitively not merge it
without further feedback. Joel: I think you offered tests on FreeBSD?

Best regards

Christian


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

[PATCH rtems-source-builder] dtc: Update to 1.6.0.

[Christian Mauderer]

---
 bare/config/devel/dtc-1.6.0-1.cfg | 18 ++
 bare/config/devel/dtc.bset|  2 +-
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg

diff --git a/bare/config/devel/dtc-1.6.0-1.cfg 
b/bare/config/devel/dtc-1.6.0-1.cfg
new file mode 100644
index 000..f293f12
--- /dev/null
+++ b/bare/config/devel/dtc-1.6.0-1.cfg
@@ -0,0 +1,18 @@
+#
+# DTC (Device Tree Compiler) 1.6.0
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define dtc_version 1.6.0
+
+%hash sha256 dtc-%{dtc_version}.tar.gz 
9fbe07223a98f2d7088a340b5505d4dfe682d77580e788d08cfcc1b61d8be237
+
+#
+# The DTC build instructions. We use 1.x.x Release 1.
+#
+%include %{_configdir}/dtc-1-1.cfg
diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
index d701f93..6700823 100644
--- a/bare/config/devel/dtc.bset
+++ b/bare/config/devel/dtc.bset
@@ -4,4 +4,4 @@
 
 %define release 1
 
-devel/dtc-1.2.0
+devel/dtc-1.6.0-1
-- 
2.25.1

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

Re: Failures on Overnight build sweep

[Christian Mauderer]

On 06/04/2020 13:59, Christian Mauderer wrote:
> On 06/04/2020 01:40, Chris Johns wrote:
>> On 2020-04-06 09:11, Joel Sherrill wrote:
>>> On Sun, Apr 5, 2020, 5:55 PM Chris Johns >> > wrote:
>>>
>>>     On 2020-04-06 05:04, Christian Mauderer wrote:
>>>  > libbsd on raspberry should work again since yesterday (if you
>>>     refer to
>>>  > that ticket: https://devel.rtems.org/ticket/3903).
>>>
>>>     Did the libbsd config in the RSB get updated?
>>>
>>> I have no idea. Someone who is fixing issues in libbsd should check
>>> that and ensure the RSB reflects the best state of the world.
>>> Otherwise, my testing is a huge HUGE waste of time.
>>>
>>> Ditto for rtems-tools fixes and other repos. If you fix something,
>>> bump hashes
>>
>> It might be the rtems-kernel that needs to be update 
>>
>> https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-5.cfg
> 
> Hello Joel and Chris,
> 
> sorry I missed to update that. I'll check it and send a patch for review.
> 
> Best regards
> 
> Christian

I checked it: Chris pulled that one in together with the reverted commit
from Sebastian today at about 7:00 UTC. So both patches are included in
current RSB master.

Sorry for missing that step. It's something normally not really
necessary during normal development (except if we really want to have a
commit for every RTEMS commit) and I'm still not aware of a lot of stuff
that is touched by the release.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Failures on Overnight build sweep

[Christian Mauderer]

On 06/04/2020 01:40, Chris Johns wrote:
> On 2020-04-06 09:11, Joel Sherrill wrote:
>> On Sun, Apr 5, 2020, 5:55 PM Chris Johns > > wrote:
>>
>>     On 2020-04-06 05:04, Christian Mauderer wrote:
>>  > libbsd on raspberry should work again since yesterday (if you
>>     refer to
>>  > that ticket: https://devel.rtems.org/ticket/3903).
>>
>>     Did the libbsd config in the RSB get updated?
>>
>> I have no idea. Someone who is fixing issues in libbsd should check
>> that and ensure the RSB reflects the best state of the world.
>> Otherwise, my testing is a huge HUGE waste of time.
>>
>> Ditto for rtems-tools fixes and other repos. If you fix something,
>> bump hashes
> 
> It might be the rtems-kernel that needs to be update 
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-5.cfg

Hello Joel and Chris,

sorry I missed to update that. I'll check it and send a patch for review.

Best regards

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