Re: RSB Issue with lexicographic comparison of python versions (shown on Ubuntu 22.04 LTS/python 3.10 platform).

[Chris Johns]

On 19/4/2022 8:06 pm, Karel Gardas wrote:
> 
>   Chris,
> 
> testing RSB on soon to be release Ubuntu 22.04 LTS. This distro provides 
> python
> 3.10 and interestingly gdb compilation fails badly on it with:
> 
> making dir:
> /home/karel/workspace/rtems-source-builder/rtems/build/tmp/gmp-6.1.0-x86_64-linux-gnu-1-1000/home/karel/workspace/rtems-tools/share/rtems/rsb
> 
> reporting: devel/gmp-6.1.0.cfg -> gmp-6.1.0-x86_64-linux-gnu-1.xml
> making dir:
> /home/karel/workspace/rtems-source-builder/rtems/build/tmp/gmp-6.1.0-x86_64-linux-gnu-1-1000/home/karel/workspace/rtems-tools/share/rtems/rsb
> 
> config: tools/rtems-gdb-11.2.cfg
> error: shell macro failed:
> /home/karel/workspace/rtems-source-builder/source-builder/sb/rtems-build-dep 
> -c
> gcc  -l : 2: error: no library (-l) provided
> Build Set: Time 0:01:01.843930
> 
> 
> The reason for this is wrong usage of probably lexicographic comparison of
> python versions in gdb-common-1.cfg:
> 
> Let's apply this debug patch to it and see the output:
> 
> diff --git a/source-builder/config/gdb-common-1.cfg
> b/source-builder/config/gdb-common-1.cfg
> index c7f3955..45e3b88 100644
> --- a/source-builder/config/gdb-common-1.cfg
> +++ b/source-builder/config/gdb-common-1.cfg
> @@ -110,6 +110,7 @@
>    %if %{gdb-python-config} != %{nil}
>  %define gdb-python-lib-filter awk 'BEGIN{FS="
> "}/python/{for(i=1;i "lib"substr($i,3)"*";}'
>  %if %{gdb-python-ver-mm} < 3.8
> +    %error "not working, python is %{gdb-python-ver-mm} and yet we're in 
> <
> 3.8 block!"
>  %define gdb-python-config-lib-check-flags --ldflags
>  %else
>  %define gdb-python-config-lib-check-flags --ldflags --embed
> 
> 
> 
> and the output is:
> 
> Build Set: 6/rtems-arm
> config: tools/rtems-gdb-11.2.cfg
> error: config error: gdb-common-1.cfg:113: "not working, python is 3.10 and 
> yet
> we're in < 3.8 block!"
> Build Set: Time 0:00:00.090733
> 
> Sorry about the %error usage, have not found any way how to debug cfg files 
> yet
> except of moving %error directive around...
> 
> Do you have any idea how to make 3.10 to be bigger/higher than 3.8 in this
> comparison?

The number 3.8 is less than 3.10 so if we changed things so it was a numeric
check it would still fail.

I suggest %{gdb-python-ver-mm} is split into major and minor parts and each 
checked:

%define gdb-python-ver-major %(echo "%{gdb-python-ver-mm}" | sed -e 's/\..*//')
%define gdb-python-ver-minor %(echo "%{gdb-python-ver-mm}" | sed -e 's/.*\.//')

then:

  %if %{gdb-python-ver-major} < 3 && %{gdb-python-ver-minor} < 8

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

Re: [PATCH] tester/gdb: allow kill on the test end

[Chris Johns]

Ok and thanks

Chris

On 19/4/2022 10:29 pm, Karel Gardas wrote:
> Sponsored-By: Precidata
> ---
>  tester/rt/config.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tester/rt/config.py b/tester/rt/config.py
> index a7b9ee3..8a433af 100644
> --- a/tester/rt/config.py
> +++ b/tester/rt/config.py
> @@ -258,6 +258,7 @@ class file(config.file):
>  script = self.expand('%%{%s}' % data[2])
>  if script:
>  script = [l.strip() for l in script.splitlines()]
> +self.kill_on_end = True
>  if not self.in_error:
>  if self.console:
>  self.console.open()
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] devel: add configuration for expat 2.4.8

[Chris Johns]

OK and thanks.

On 19/4/2022 10:24 pm, Karel Gardas wrote:
> ---
>  bare/config/devel/expat-2.4.8-1.cfg | 19 +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 bare/config/devel/expat-2.4.8-1.cfg
> 
> diff --git a/bare/config/devel/expat-2.4.8-1.cfg 
> b/bare/config/devel/expat-2.4.8-1.cfg
> new file mode 100644
> index 000..d9cddd5
> --- /dev/null
> +++ b/bare/config/devel/expat-2.4.8-1.cfg
> @@ -0,0 +1,19 @@
> +#
> +# Expat 2.4.8
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +%include %{_configdir}/base.cfg
> +
> +%define expat_version 2.4.8
> +%define expat_version_dir R_2_4_8
> +
> +%hash sha256 expat-%{expat_version}.tar.gz 
> 398f6d95bf808d3108e27547b372cb4ac8dc2298a3c4251eb7aa3d4c6d4bb3e2
> +
> +#
> +# The Expat build instructions. We use 2.xx Release 1.
> +#
> +%include %{_configdir}/expat-2-1.cfg
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Last call for Mentors

[Gedare Bloom]

If you're interested in potentially mentoring/co-mentoring in GSOC,
please let me/Joel/Chris know so you can be invited. We're now
ranking/selecting proposed projects and need to match mentors.

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

Re: Tool Suite Build Failed - machine 'arm64-apple' not recognized

[Karel Gardas]

On 4/19/22 19:13, Cedric Berger wrote:
Yeah, you're right: I patched GMP because I first tried to build the 
toolchain on aarch64-mac. Both patches were definitely needed for that.




Just verified what's needed on x64 catalina 10.15.7/darwin 19.6.0 and 
indeed, *only* expat patch is needed for x64 platform which means gmp 
6.1.0 probably suffers from the same issue like expat not recognizing 
aarch64-darwin properly and as you confirm 6.2.1 should fix this...


Karel





Cedric


On 19.04.22 17:50, Alan Cudmore wrote:


Karel Gardas just submitted patches this morning to upgrade expat to 
work on 64 bit Arm.


A couple of months ago, I was able to build an RTEMS toolchain on 
aarch64 Linux with just an expat upgrade. I was not aware that GMP was 
needed as well.


Alan

*From: *Cedric Berger 
*Sent: *Tuesday, April 19, 2022 11:23 AM
*To: *Jay Zhu ; devel@rtems.org
*Subject: *Re: Tool Suite Build Failed - machine 'arm64-apple' not 
recognized


Hello,

On 10.04.22 20:37, Jay Zhu wrote:

> Hi,

> I am a student new to RTEMS and trying to get my first lines to run. 
When following the quick-start guide, I was stuck in Install Tool 
Suite procedure. Using this command:


> ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
6/rtems-sparc


> The output was:

>

> error: building expat-2.1.0-arm64-apple-darwin21.4.0-1

> Build FAILED

>    See error report: 
rsb-report-expat-2.1.0-arm64-apple-darwin21.4.0-1.txt


>

> Then I lookup the log file, in which the errors are:

>

> Invalid configuration `arm64-apple-darwin21.4.0': machine 
`arm64-apple' not recognized


> configure: error: /bin/sh conftools/config.sub 
arm64-apple-darwin21.4.0 failed


> checking build system type...

> checking build system type...

> shell cmd failed: /bin/sh -ex 
/Users/Jay/quick-start/src/rsb/rtems/build/expat-2.1.0-arm64-apple-darwin21.4.0-1/do-build 



> error: building expat-2.1.0-arm64-apple-darwin21.4.0-1

>

> Can you kindly tell me how can I fix this?

I can't help you fix this, but I've successfully built 6/rtems-arm tools

+ BSP on a M1 Mac using multipass. basically:

1) create the ubuntu VM: "multipass launch -n u2004 -c 6 -d 16G -m 4G 
20.04"


2) create a shared folder: "multipass mount /opt/vm/rtems

u2004:/opt/vm/rtems"

3) upgrade expat to 2.4.8 and gmp to 6.2.1

4) before building, specify "ulimit -n 4096" on the linux VM otherwise

GCC will fail to link with incomprehensible error.

Cedric

___

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: Tool Suite Build Failed - machine 'arm64-apple' not recognized

[Cedric Berger]

Yeah, you're right: I patched GMP because I first tried to build the 
toolchain on aarch64-mac. Both patches were definitely needed for that.


Cedric


On 19.04.22 17:50, Alan Cudmore wrote:


Karel Gardas just submitted patches this morning to upgrade expat to 
work on 64 bit Arm.


A couple of months ago, I was able to build an RTEMS toolchain on 
aarch64 Linux with just an expat upgrade. I was not aware that GMP was 
needed as well.


Alan

*From: *Cedric Berger 
*Sent: *Tuesday, April 19, 2022 11:23 AM
*To: *Jay Zhu ; devel@rtems.org
*Subject: *Re: Tool Suite Build Failed - machine 'arm64-apple' not 
recognized


Hello,

On 10.04.22 20:37, Jay Zhu wrote:

> Hi,

> I am a student new to RTEMS and trying to get my first lines to run. 
When following the quick-start guide, I was stuck in Install Tool 
Suite procedure. Using this command:


> ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
6/rtems-sparc


> The output was:

>

> error: building expat-2.1.0-arm64-apple-darwin21.4.0-1

> Build FAILED

>    See error report: 
rsb-report-expat-2.1.0-arm64-apple-darwin21.4.0-1.txt


>

> Then I lookup the log file, in which the errors are:

>

> Invalid configuration `arm64-apple-darwin21.4.0': machine 
`arm64-apple' not recognized


> configure: error: /bin/sh conftools/config.sub 
arm64-apple-darwin21.4.0 failed


> checking build system type...

> checking build system type...

> shell cmd failed: /bin/sh -ex 
/Users/Jay/quick-start/src/rsb/rtems/build/expat-2.1.0-arm64-apple-darwin21.4.0-1/do-build


> error: building expat-2.1.0-arm64-apple-darwin21.4.0-1

>

> Can you kindly tell me how can I fix this?

I can't help you fix this, but I've successfully built 6/rtems-arm tools

+ BSP on a M1 Mac using multipass. basically:

1) create the ubuntu VM: "multipass launch -n u2004 -c 6 -d 16G -m 4G 
20.04"


2) create a shared folder: "multipass mount /opt/vm/rtems

u2004:/opt/vm/rtems"

3) upgrade expat to 2.4.8 and gmp to 6.2.1

4) before building, specify "ulimit -n 4096" on the linux VM otherwise

GCC will fail to link with incomprehensible error.

Cedric

___

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: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

[Pavel Pisa]

Hello Kamlesh,

On Tuesday 19 of April 2022 16:30:25 Kamlesh Bharodiya wrote:
> I was afk for the last two days. As the deadline is already here. I have
> submitted the proposal after reviewing your comments from the mail. Thank
> you for taking the time out. Thanks to Noor Aman and Gedare, I have gone
> through the comments and have incorporated your suggestions in the
> proposal. Will continue in discord group.

Thanks for the submitting proposal. It looks reasonable and realistic
from my side.

Best wishes,

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

Re: Tool Suite Build Failed - machine 'arm64-apple' not recognized

[Joel Sherrill]

On Tue, Apr 19, 2022 at 10:23 AM Cedric Berger  wrote:

> Hello,
>
> On 10.04.22 20:37, Jay Zhu wrote:
> > Hi,
> > I am a student new to RTEMS and trying to get my first lines to run.
> When following the quick-start guide, I was stuck in Install Tool Suite
> procedure. Using this command:
> > ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6
> 6/rtems-sparc
> > The output was:
> >
> > error: building expat-2.1.0-arm64-apple-darwin21.4.0-1
> > Build FAILED
> >See error report:
> rsb-report-expat-2.1.0-arm64-apple-darwin21.4.0-1.txt
> >
> > Then I lookup the log file, in which the errors are:
> >
> > Invalid configuration `arm64-apple-darwin21.4.0': machine `arm64-apple'
> not recognized
> > configure: error: /bin/sh conftools/config.sub arm64-apple-darwin21.4.0
> failed
> > checking build system type...
> > checking build system type...
> > shell cmd failed: /bin/sh -ex
> /Users/Jay/quick-start/src/rsb/rtems/build/expat-2.1.0-arm64-apple-darwin21.4.0-1/do-build
> > error: building expat-2.1.0-arm64-apple-darwin21.4.0-1
> >
> > Can you kindly tell me how can I fix this?
>

Download the latest expat source by itself and try to build it. Looks like
they have a release in March. Maybe that adds  arm64-apple-darwin as a
known target.

If that works, we just need to bump the expat version in the RSB.

Building with Ubuntu always side steps issues. :)

>
> I can't help you fix this, but I've successfully built 6/rtems-arm tools
> + BSP on a M1 Mac using multipass. basically:
>
> 1) create the ubuntu VM: "multipass launch -n u2004 -c 6 -d 16G -m 4G
> 20.04"
>
> 2) create a shared folder: "multipass mount /opt/vm/rtems
> u2004:/opt/vm/rtems"
>
> 3) upgrade expat to 2.4.8 and gmp to 6.2.1
>
> 4) before building, specify "ulimit -n 4096" on the linux VM otherwise
> GCC will fail to link with incomprehensible error.
>
> Cedric
>
>
>
> ___
> 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: Tool Suite Build Failed - machine 'arm64-apple' not recognized

[Cedric Berger]

Hello,

On 10.04.22 20:37, Jay Zhu wrote:

Hi,
I am a student new to RTEMS and trying to get my first lines to run. When 
following the quick-start guide, I was stuck in Install Tool Suite procedure. 
Using this command:
../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
6/rtems-sparc
The output was:

error: building expat-2.1.0-arm64-apple-darwin21.4.0-1
Build FAILED
   See error report: rsb-report-expat-2.1.0-arm64-apple-darwin21.4.0-1.txt

Then I lookup the log file, in which the errors are:

Invalid configuration `arm64-apple-darwin21.4.0': machine `arm64-apple' not 
recognized
configure: error: /bin/sh conftools/config.sub arm64-apple-darwin21.4.0 failed
checking build system type...
checking build system type...
shell cmd failed: /bin/sh -ex  
/Users/Jay/quick-start/src/rsb/rtems/build/expat-2.1.0-arm64-apple-darwin21.4.0-1/do-build
error: building expat-2.1.0-arm64-apple-darwin21.4.0-1

Can you kindly tell me how can I fix this?


I can't help you fix this, but I've successfully built 6/rtems-arm tools 
+ BSP on a M1 Mac using multipass. basically:


1) create the ubuntu VM: "multipass launch -n u2004 -c 6 -d 16G -m 4G 20.04"

2) create a shared folder: "multipass mount /opt/vm/rtems 
u2004:/opt/vm/rtems"


3) upgrade expat to 2.4.8 and gmp to 6.2.1

4) before building, specify "ulimit -n 4096" on the linux VM otherwise 
GCC will fail to link with incomprehensible error.


Cedric



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

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

[mbenson]

I’ve received a few emails about our RTEMS on R5 work.  Sorry I haven’t 
responded yet.  I made a quick and dirty BSP about 6 months ago just to prove 
to myself that this was a viable effort.  I got it running in the Xilinx Qemu 
in about a day.  I would be happy to mentor anybody wanting to take this on.  
Sadly, a hard drive failure caused me to lose all my work before I could commit 
it.  One of my new employees has taken up the task.  I can introduce you.  

Our goal is to port RTEMS to the R5 on the Zynq Ultrascale+ first, and a custom 
FMC with an R5 that we designed in house second.  The first iteration of the R5 
board is complete and printed but we haven’t had time to assemble and test it 
yet.  The port to the R5 on the Zynq Ultrascale+ is low lying fruit and should 
be the easiest by far to complete, since it’s booting from Linux on the A53s.  
The FSBL runs on the A53, which loads the FPGA and configures the hard cores.  
Until isolation mode is enabled, the RTEMS/R5 basically piggy backs on 
Linux/A53.  Linux sets up the MMU, the Global Interrupt Controller, and the 
console UART (if shared).  RTEMS just has to setup the timer, and map the 
console to the correct UART.  No uboot.  Linux loads the R5 reserved memory and 
signals the PMU to enable power to the R5.  The BSP is trivial.  All the work 
is in the drivers.  However, if you use our Zynq Ultrascale+ avionics board 
(should be publicly available next year), driver development is simplified for 
designs that follow the commonly used rate monotonic design pattern.  Driver 
code actually runs partitioned in a separate CPU, independent of RTEMS, 
relieving the R5 from non-deterministic interrupts.

Our second board has a dedicated R5 device.  No Zynq.  It’s an FPGA Mezzanine 
Card (FMC), so it follows a form factor common among FPGA boards.  You can use 
it as an expansion to a main board, but it it does not require a main board.  
It will also work just as well as a stand-alone board.  Just give it power and 
ground.  This platform will take a bit more work to add RTEMS support since you 
have no A53 doing all the heavy lifting.  In its current prototype iteration, 
it has no attached memory, only internal memory.  It also has a UART chip to 
give us additional UARTs.  The next iterations will include additional memory 
and line drivers for RS-422 support.  This board will require driver 
development.

I am most interested in getting RTEMS running on the R5 FMC.

Sent from my iPhone

> On Apr 17, 2022, at 10:20, Joel Sherrill  wrote:
> 
> On Sun, Apr 17, 2022, 5:17 AM Pavel Pisa  wrote:
> 
>> Dear Kamlesh,
>> 
>>> On Sunday 17 of April 2022 10:19:01 Kamlesh Bharodiya wrote:
>>> Thanks for your mail. I have not worked on ZCU102. Though, I'm working
>> with
>>> R4F currently. Shall I go ahead with the GSoC application? Or should I
>> wait
>>> for any other mentor to reply ?
>> 
>> I do not feel competent to be main mentor for this project
>> and some feedback from people working on RTEMS core
>> would be helpfull. But I expect that most are on Easters
>> now so the time to submission deadline is relatively tight.
>> 
> 
> The R5 basic BSP is needed by the RTEMS community. If you get through that,
> you could look at the Xilinx code for interacting with it.
> 
> 
> 
> 
> 
>> I am not sure if somebody else see potential to use RTEMS or Cortex-R5
>> integrated into ZCU102. I see it in general but do not see any
>> such project on my horizon university work nor company projects
>> horizon. I have actually neither project with TMS570LC4357,
>> but I have at least HW and it could be nice platform to test
>> RTEMS CAN support if it is updated during this year another GSoC
>> and interesting platform for LwIP testing... But there is no
>> QEMU support and I do not suggest to change your project to this
>> direction.
>> 
>> As I have checked, it seems that it is possible to use ZCU102 R5
>> somehow with local UART and timer so it makes project initial
>> phases as feasible in the GSoC frame. Do you plan project as
>> the longer or shorter GSoC variant?
>> 
>> I suggest to apply before submission deadline even if the
>> project is not fully clarified before deadline. It will
>> be discussed by RTEMS mentors and can be slightly adjusted,
>> extended before coding phase to match core team vision.
>> Other option is to select another open topic which is on
>> the RTEMS project interest list
>> 
>>  https://devel.rtems.org/wiki/Developer/OpenProjects
>> 
>> But if you have already some experience with Cortex-R4
>> and see some real application use for your work then
>> the goal has reason.
>> 
>> You wrote in your proposal
>> 
>>  Testing R4 BSP on Qemu - but I think that there is no such
>> available target for now
>> 
>> As for the timeline, I suggest to move testing and familiarization
>> with RTEMS and QEMU ecosystem into bonding period and start real
>> coding with start of GSoC coding period to have something to
>> to evaluate and running in 

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

[Kamlesh Bharodiya]

Hi Pavel,

I was afk for the last two days. As the deadline is already here. I have
submitted the proposal after reviewing your comments from the mail. Thank
you for taking the time out. Thanks to Noor Aman and Gedare, I have gone
through the comments and have incorporated your suggestions in the
proposal. Will continue in discord group.

Regards,
Kamlesh

On Mon, Apr 18, 2022 at 3:14 AM Pavel Pisa  wrote:

> Hello Alan and Kamlesh,
>
> On Sunday 17 of April 2022 18:18:03 Alan Cudmore wrote:
> > The R5 basic BSP is needed by the RTEMS community. If you get through
> that,
> > you could look at the Xilinx code for interacting with it.
> >
> > Is the Xilinx R5 QEMU support generic enough for a basic BSP? Or could it
> > be factored in a way that supports non-xilinx BSPs? I would not mind
> seeing
> > a R5 BSP for the Xilinx MPSoC UltraScale+ since RTEMS has support for the
> > A53 now. I thought others on this list might have already created an R5
> > BSP. It looks like the Zephyr RTOS supports the Xilinx R5 QEMU model.
> >
> https://docs.zephyrproject.org/latest/boards/arm/qemu_cortex_r5/doc/index.h
> >tml The Timer and UART are Xilinx specific.
> >
> https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/arm/qemu_cort
> >ex_r5
> > Other than the Xilinx UltraScale+, I see there are TI AM243x processors,
> > but are there any other R5 processors available?
>
> As I have already reported that I have TMDX570LC43HDK at home.
> There is even Hi-Rel version of the used TMS570LC4357-EP.
> Gedare has some smaller boards with these chips as well.
> I know and have located again that there are industrial
> equivalents RM57L843 and RM48L740. RM are usually little
> endian, all TMS570 I have met are big endian.
>
> As I have reported already
>
> On Saturday 16 of April 2022 16:11:02 Pavel Pisa wrote:
> > As I know, the Cortex-R5 core is already supported
> > by RTEMS and our TMS570LS3137 BSP has been used
> > with TMS570LC4357 chips by Frankfurt University
> >
> >   https://www.rz.uni-frankfurt.de/65100666/dcs
> >
> > Relevant repository
> >
> >   https://github.com/jalmito/rtems
> >
> > It would worth to get mainline TMS570 BSP compatible with
> > both chips.
>
> I have not time to work or test that target, nor I have some
> project now and I will be quite busy next months so do not
> expect major contribution.
>
> But I would be happy if the development moves forward.
>
> But in the fact it would worth to start by QEMU
> support the first and it would take whole GSoC
> probably.
>
> TI AM243x seems to be interesting from this respect
> by possible high simmilarty to BeagleBone AM335x
> so probably more peripherals in QEMU could be reused...
>
> Anyway, Kamlesh Bharodiya idea to try R5 on Xilinx MPSoC
> which has QEMU support seems to be reasonable start
> direction. I have enticed that he has written somewhere
> notice that he has some experience with Cortex-R4.
> Is my understanding correct? If you have some personal
> or company working on some project on this target
> than it is even better.
>
> Best wishes,
>
> Pavel
> --
> Pavel Pisa
> phone:  +420 603531357
> e-mail: p...@cmp.felk.cvut.cz
> Department of Control Engineering FEE CVUT
> Karlovo namesti 13, 121 35, Prague 2
> university: http://control.fel.cvut.cz/
> company:https://www.pikron.com/
> personal:   http://cmp.felk.cvut.cz/~pisa
> projects:   https://www.openhub.net/accounts/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> Open Technologies Research Education and Exchange Services
> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] tester/bsps: add stm32h7-stlink family configuration

[Karel Gardas]

Sponsored-By:   Precidata
---
 tester/rtems/testing/bsps/stm32h7-stlink.ini | 43 
 1 file changed, 43 insertions(+)
 create mode 100644 tester/rtems/testing/bsps/stm32h7-stlink.ini

diff --git a/tester/rtems/testing/bsps/stm32h7-stlink.ini 
b/tester/rtems/testing/bsps/stm32h7-stlink.ini
new file mode 100644
index 000..042ec7c
--- /dev/null
+++ b/tester/rtems/testing/bsps/stm32h7-stlink.ini
@@ -0,0 +1,43 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2015 On-Line Applications Research Corporation (OAR).
+# 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 stm32h7 BSP family
+#
+[stm32h7-stlink]
+bsp= stm32h7-stlink
+arch   = arm
+tester = %{_rtscripts}/gdb.cfg
+jobs   = 1
+gdb_script = bsp_gdb_script
+requires: bsp_tty_dev, bsp_gdb_script, target_pretest_command, 
target_posttest_command
+bsp_gdb_script = target extended-remote :61234
+ load
+ cont
-- 
2.25.1

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

[PATCH] tester/gdb: allow kill on the test end

[Karel Gardas]

Sponsored-By:   Precidata
---
 tester/rt/config.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tester/rt/config.py b/tester/rt/config.py
index a7b9ee3..8a433af 100644
--- a/tester/rt/config.py
+++ b/tester/rt/config.py
@@ -258,6 +258,7 @@ class file(config.file):
 script = self.expand('%%{%s}' % data[2])
 if script:
 script = [l.strip() for l in script.splitlines()]
+self.kill_on_end = True
 if not self.in_error:
 if self.console:
 self.console.open()
-- 
2.25.1

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

[PATCH 2/2] 6: update default set to use expat 2.4.8

[Karel Gardas]

This solves issues with compilation on aarch64-linux platform since
it is not recognized by previous expat 2.1.0.
---
 rtems/config/6/rtems-default.bset | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index bf16170..25e139a 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -10,7 +10,7 @@
 
 devel/dtc-1.6.1-1
 
-devel/expat-2.1.0-1
+devel/expat-2.4.8-1
 devel/gmp-6.1.0
 tools/rtems-gdb-11.2
 
-- 
2.25.1

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

[PATCH 1/2] devel: add configuration for expat 2.4.8

[Karel Gardas]

---
 bare/config/devel/expat-2.4.8-1.cfg | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 bare/config/devel/expat-2.4.8-1.cfg

diff --git a/bare/config/devel/expat-2.4.8-1.cfg 
b/bare/config/devel/expat-2.4.8-1.cfg
new file mode 100644
index 000..d9cddd5
--- /dev/null
+++ b/bare/config/devel/expat-2.4.8-1.cfg
@@ -0,0 +1,19 @@
+#
+# Expat 2.4.8
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define expat_version 2.4.8
+%define expat_version_dir R_2_4_8
+
+%hash sha256 expat-%{expat_version}.tar.gz 
398f6d95bf808d3108e27547b372cb4ac8dc2298a3c4251eb7aa3d4c6d4bb3e2
+
+#
+# The Expat build instructions. We use 2.xx Release 1.
+#
+%include %{_configdir}/expat-2-1.cfg
-- 
2.25.1

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

RSB Issue with lexicographic comparison of python versions (shown on Ubuntu 22.04 LTS/python 3.10 platform).

[Karel Gardas]

  Chris,

testing RSB on soon to be release Ubuntu 22.04 LTS. This distro provides 
python 3.10 and interestingly gdb compilation fails badly on it with:


making dir: 
/home/karel/workspace/rtems-source-builder/rtems/build/tmp/gmp-6.1.0-x86_64-linux-gnu-1-1000/home/karel/workspace/rtems-tools/share/rtems/rsb

reporting: devel/gmp-6.1.0.cfg -> gmp-6.1.0-x86_64-linux-gnu-1.xml
making dir: 
/home/karel/workspace/rtems-source-builder/rtems/build/tmp/gmp-6.1.0-x86_64-linux-gnu-1-1000/home/karel/workspace/rtems-tools/share/rtems/rsb

config: tools/rtems-gdb-11.2.cfg
error: shell macro failed: 
/home/karel/workspace/rtems-source-builder/source-builder/sb/rtems-build-dep 
-c gcc  -l : 2: error: no library (-l) provided

Build Set: Time 0:01:01.843930


The reason for this is wrong usage of probably lexicographic comparison 
of python versions in gdb-common-1.cfg:


Let's apply this debug patch to it and see the output:

diff --git a/source-builder/config/gdb-common-1.cfg 
b/source-builder/config/gdb-common-1.cfg

index c7f3955..45e3b88 100644
--- a/source-builder/config/gdb-common-1.cfg
+++ b/source-builder/config/gdb-common-1.cfg
@@ -110,6 +110,7 @@
   %if %{gdb-python-config} != %{nil}
 %define gdb-python-lib-filter awk 'BEGIN{FS=" 
"}/python/{for(i=1;i"lib"substr($i,3)"*";}'

 %if %{gdb-python-ver-mm} < 3.8
+%error "not working, python is %{gdb-python-ver-mm} and yet 
we're in < 3.8 block!"

 %define gdb-python-config-lib-check-flags --ldflags
 %else
 %define gdb-python-config-lib-check-flags --ldflags --embed



and the output is:

Build Set: 6/rtems-arm
config: tools/rtems-gdb-11.2.cfg
error: config error: gdb-common-1.cfg:113: "not working, python is 3.10 
and yet we're in < 3.8 block!"

Build Set: Time 0:00:00.090733

Sorry about the %error usage, have not found any way how to debug cfg 
files yet except of moving %error directive around...


Do you have any idea how to make 3.10 to be bigger/higher than 3.8 in 
this comparison?


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