eng: Add Formal Verification chapter

2022-09-13 Thread andrew.butterfi...@scss.tcd.ie 
Dear RTEMS Developers,

  The attached patch file adds a new Formal Verification chapter as discussed 
in the previous email thread
regarding "Integrating the Formal Methods part of Qualification"
(see https://lists.rtems.org/pipermail/devel/2022-July/072167.html ).

This is just the documentation for what was done. None of the files or tools 
mentioned are contained
in the patch. Most of those would be deployed to rtems-central or the "main" 
rtems repo.

Best Regards,
  Andrew


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/

 



0001-eng-Add-Formal-Verification-chapter.patch
Description: 0001-eng-Add-Formal-Verification-chapter.patch
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

eng: Add Formal Verification chapter v2

2022-09-13 Thread andrew.butterfi...@scss.tcd.ie 
Dear RTEMS Developers,

  The inlined patch file below adds a new Formal Verification chapter as 
discussed in the previous email thread
regarding "Integrating the Formal Methods part of Qualification"
(see https://lists.rtems.org/pipermail/devel/2022-July/072167.html ).

This is just the documentation for what was done. None of the files or tools 
mentioned are contained
in the patch. Most of those would be deployed to rtems-central or the "main" 
rtems repo.

Best Regards,
  Andrew

From ca8d303e7b25b02d9c4aad3b7f76dbdc1cdfa396 Mon Sep 17 00:00:00 2001
From: Andrew Butterfield 
Date: Mon, 23 May 2022 17:02:21 +0100
Subject: [PATCH] eng: Add Formal Verification chapter

---
 common/refs.bib|   56 ++
 eng/fv/index.rst   |   32 +
 eng/fv/maintenance.rst |   70 ++
 eng/fv/methodology.rst |  228 +++
 eng/fv/model-guide.rst | 1482 
 eng/fv/overview.rst|   33 +
 eng/fv/promela.rst |  320 +
 eng/fv/refinement.rst  |  359 ++
 eng/fv/tool-setup.rst  |   80 +++
 eng/index.rst  |2 +
 10 files changed, 2662 insertions(+)
 create mode 100644 eng/fv/index.rst
 create mode 100644 eng/fv/maintenance.rst
 create mode 100644 eng/fv/methodology.rst
 create mode 100644 eng/fv/model-guide.rst
 create mode 100644 eng/fv/overview.rst
 create mode 100644 eng/fv/promela.rst
 create mode 100644 eng/fv/refinement.rst
 create mode 100644 eng/fv/tool-setup.rst

diff --git a/common/refs.bib b/common/refs.bib
index 066d746..6b25fae 100644
--- a/common/refs.bib
+++ b/common/refs.bib
@@ -9,6 +9,25 @@
   year= {1973},
   pages   = {46-61},
 }
+@article{Djikstra:1975:GCL,
+author = {Dijkstra, Edsger W.},
+title = {Guarded Commands, Nondeterminacy and Formal Derivation of Programs},
+year = {1975},
+issue_date = {Aug. 1975},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+volume = {18},
+number = {8},
+issn = {0001-0782},
+url = {https://doi.org/10.1145/360933.360975},
+doi = {10.1145/360933.360975},
+abstract = {So-called “guarded commands” are introduced as a building block 
for alternative and repetitive constructs that allow nondeterministic program 
components for which at least the activity evoked, but possibly even the final 
state, is not necessarily uniquely determined by the initial state. For the 
formal derivation of programs expressed in terms of these constructs, a 
calculus will be be shown.},
+journal = {Commun. ACM},
+month = {aug},
+pages = {453–457},
+numpages = {5},
+keywords = {correctness proof, programming methodology, program semantics, 
case-construction, termination, nondeterminancy, programming languages, 
derivation of programs, sequencing primitives, repetition, programming language 
semantics}
+}
 @inproceedings{Varghese:1987:TimerWheel,
   author  = {Varghese, G. and Lauck, T.},
   title   = {{Hashed and Hierarchical Timing Wheels: Data Structures for 
the Efficient Implementation of a Timer Facility}},
@@ -95,6 +114,16 @@
   url   = {http://www.rfc-editor.org/rfc/rfc2119.txt},
   note  = {\url{http://www.rfc-editor.org/rfc/rfc2119.txt}},
 }
+@ARTICLE{Holzmann:1997:SPIN,
+  author={Holzmann, G.J.},
+  journal={IEEE Transactions on Software Engineering},
+  title={The model checker SPIN},
+  year={1997},
+  volume={23},
+  number={5},
+  pages={279-295},
+  doi={10.1109/32.588521}
+}
 @article{Blumofe:1999:WS,
   author  = {Blumofe, Robert D. and Leiserson, Charles E.},
   title   = {{Scheduling multithreaded computations by work stealing}},
@@ -373,6 +402,33 @@
   title = {{RTEMS CPU Architecture Supplement}},
   url   = {https://docs.rtems.org/branches/master/cpu-supplement.pdf},
 }
+@mastersthesis{Jennings:2021:FV,
+  author =   {Robert Jennings},
+  title ={{Formal Verification of a Real-Time Multithreaded Operating 
System}},
+  school =   {School of Computer Science and Statistics},
+  year = {2021},
+  type = {Master of Science in {Computer Science (MCS)}},
+  address =  {Trinity College, Dublin 2, Ireland},
+  month ={August},
+}
+@mastersthesis{Jaskuc:2022:TESTGEN,
+  author =   {Jerzy Ja{\'{s}}ku{\'{c}}},
+  title ={{SPIN/Promela-Based Test Generation Framework for RTEMS 
Barrier Manager}},
+  school =   {School of Computer Science and Statistics},
+  year = {2022},
+  type = {Master of Science in {Computer Science (MCS)}},
+  address =  {Trinity College, Dublin 2, Ireland},
+  month ={April},
+}
+@mastersthesis{Lynch:2022:TESTGEN,
+  author =   {Eoin Lynch},
+  title ={{Using Promela/SPIN to do Test Generation for RTEMS-SMP}},
+  school =   {School of Engineering},
+  year = {2022},
+  type = {Master of {Engineering (Computer Engineering)}},
+  address =  {Trinity College, Dublin 2, Ireland},
+  month ={April},
+}
 % ECSS
 % Sort lexicographically
 @manual{ECSS_E_ST_10_02C_R1,
diff --git a/eng

[PATCH] icpp remedy

2022-09-13 Thread Strange369 
---
 cpukit/include/rtems/score/coremuteximpl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/score/coremuteximpl.h 
b/cpukit/include/rtems/score/coremuteximpl.h
index d489a0d946..72d32f8030 100644
--- a/cpukit/include/rtems/score/coremuteximpl.h
+++ b/cpukit/include/rtems/score/coremuteximpl.h
@@ -445,7 +445,7 @@ RTEMS_INLINE_ROUTINE Status_Control 
_CORE_ceiling_mutex_Set_owner(
   scheduler_node = _Thread_Scheduler_get_home_node( owner );
 
   if (
-_Priority_Get_priority( &scheduler_node->Wait.Priority )
+owner->Real_priority.priority
   < the_mutex->Priority_ceiling.priority
   ) {
 _Thread_Wait_release_default_critical( owner, &lock_context );
-- 
2.25.1

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

Re: [PATCH] icpp remedy

2022-09-13 Thread Joel Sherrill 
What is this a remedy for?

Why isn't the helper method OK to use?

--joel

On Tue, Sep 13, 2022 at 7:41 AM Strange369 
wrote:

> ---
>  cpukit/include/rtems/score/coremuteximpl.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/include/rtems/score/coremuteximpl.h
> b/cpukit/include/rtems/score/coremuteximpl.h
> index d489a0d946..72d32f8030 100644
> --- a/cpukit/include/rtems/score/coremuteximpl.h
> +++ b/cpukit/include/rtems/score/coremuteximpl.h
> @@ -445,7 +445,7 @@ RTEMS_INLINE_ROUTINE Status_Control
> _CORE_ceiling_mutex_Set_owner(
>scheduler_node = _Thread_Scheduler_get_home_node( owner );
>
>if (
> -_Priority_Get_priority( &scheduler_node->Wait.Priority )
> +owner->Real_priority.priority
>< the_mutex->Priority_ceiling.priority
>) {
>  _Thread_Wait_release_default_critical( owner, &lock_context );
> --
> 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] icpp remedy

2022-09-13 Thread Joel Sherrill 
On Tue, Sep 13, 2022, 1:14 PM Kuan-Hsun Chen  wrote:

> (Oh, I just noticed that the patch was submitted faster than my mail to
> share this patch :P).
>

No problem. That's why I asked what the issue was.

It needs at least a much better log message. It needs a ticket given the
gravity of the issue. That ticket can explain the situation and include
links. Probably needs a comment above the change explaining what's going on.

Is there a test case for this?

If it applies to 5 or 4.11, there needs to be another ticket to get the fix
back ported.

Great catch. Just need to do a good job on the log, test, ticket(s), etc

--joel


> Hi Joel,
>
> Let me clarify what happened here. In our recent study, we adopt Frama-C
> to formally verify the implementation of ICPP (also MrsP) and note that the
> current flow may lead to a deadlock. The patch is a simple remedy to fix
> the issue.
>
> The resource’s ceiling is not checked against the thread’s base priority,
> but against its current dynamic priority derived from the task’s priority
> aggregation. However, a resource’s ceiling is required to be set as the
> highest base priority of all tasks that are requesting it. This mismatch
> may lead to a deadlock by denying legitimate nested resource access if
> resources are requested in descending order of priority. So this adaption
> is needed to resolve the issue. A similar issue can also be found in MrsP
> due to the usage of this function. A detailed explanation can be found at
> the end of Section V in the attached preprint, and a toy example is
> provided there to reveal the issue.
>
> The verification framework will be presented in EMSOFT this year, which is
> publicly available here:
> https://github.com/tu-dortmund-ls12-rt/Resource-Synchronization-Protocols-Verification-RTEMS
> *I notice that Andrew today also sent a patch for a chapter on formal
> verification. Since our result is relevant, I plan to respond to the
> previous thread (
> https://lists.rtems.org/pipermail/devel/2022-July/072167.html).
>
> Best regards,
> Kuan-Hsun
>
> On Tue, Sep 13, 2022 at 3:35 PM Joel Sherrill  wrote:
>
>> What is this a remedy for?
>>
>> Why isn't the helper method OK to use?
>>
>> --joel
>>
>> On Tue, Sep 13, 2022 at 7:41 AM Strange369 
>> wrote:
>>
>>> ---
>>>  cpukit/include/rtems/score/coremuteximpl.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/cpukit/include/rtems/score/coremuteximpl.h
>>> b/cpukit/include/rtems/score/coremuteximpl.h
>>> index d489a0d946..72d32f8030 100644
>>> --- a/cpukit/include/rtems/score/coremuteximpl.h
>>> +++ b/cpukit/include/rtems/score/coremuteximpl.h
>>> @@ -445,7 +445,7 @@ RTEMS_INLINE_ROUTINE Status_Control
>>> _CORE_ceiling_mutex_Set_owner(
>>>scheduler_node = _Thread_Scheduler_get_home_node( owner );
>>>
>>>if (
>>> -_Priority_Get_priority( &scheduler_node->Wait.Priority )
>>> +owner->Real_priority.priority
>>>< the_mutex->Priority_ceiling.priority
>>>) {
>>>  _Thread_Wait_release_default_critical( owner, &lock_context );
>>> --
>>> 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
>
>
>
> --
> Diese Mail wurde mobil geschrieben. Etwaige Rechtschreibfehler sind volle
> Absicht und als großzügiges Geschenk zu verstehen.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] icpp remedy

2022-09-13 Thread Kuan-Hsun Chen 
Thanks for the prompt reply. Yes, I will guide Junjie to make a ticket and
go through the issue.

>Is there a test case for this?
Yes, a test case is also ready to be reviewed and can be part of the
testsuite to test out ICPP (MrsP should also pass).

> If it applies to 5 or 4.11, there needs to be another ticket to get the
fix back ported.
So each release version with one ticket? We only check 5.1 in this work. My
intuitive guess is that if the functionality does not change over the
versions, the remedy should be similar.
Let us figure it out.

On Tue, Sep 13, 2022 at 8:21 PM Joel Sherrill  wrote:

>
>
> On Tue, Sep 13, 2022, 1:14 PM Kuan-Hsun Chen  wrote:
>
>> (Oh, I just noticed that the patch was submitted faster than my mail to
>> share this patch :P).
>>
>
> No problem. That's why I asked what the issue was.
>
> It needs at least a much better log message. It needs a ticket given the
> gravity of the issue. That ticket can explain the situation and include
> links. Probably needs a comment above the change explaining what's going on.
>
> Is there a test case for this?
>
> If it applies to 5 or 4.11, there needs to be another ticket to get the
> fix back ported.
>
> Great catch. Just need to do a good job on the log, test, ticket(s), etc
>
> --joel
>
>
>> Hi Joel,
>>
>> Let me clarify what happened here. In our recent study, we adopt Frama-C
>> to formally verify the implementation of ICPP (also MrsP) and note that the
>> current flow may lead to a deadlock. The patch is a simple remedy to fix
>> the issue.
>>
>> The resource’s ceiling is not checked against the thread’s base priority,
>> but against its current dynamic priority derived from the task’s
>> priority aggregation. However, a resource’s ceiling is required to be
>> set as the highest base priority of all tasks that are requesting it. This
>> mismatch may lead to a deadlock by denying legitimate nested resource
>> access if resources are requested in descending order of priority. So this
>> adaption is needed to resolve the issue. A similar issue can also be found
>> in MrsP due to the usage of this function. A detailed explanation can be
>> found at the end of Section V in the attached preprint, and a toy example
>> is provided there to reveal the issue.
>>
>> The verification framework will be presented in EMSOFT this year, which
>> is publicly available here:
>> https://github.com/tu-dortmund-ls12-rt/Resource-Synchronization-Protocols-Verification-RTEMS
>> *I notice that Andrew today also sent a patch for a chapter on formal
>> verification. Since our result is relevant, I plan to respond to the
>> previous thread (
>> https://lists.rtems.org/pipermail/devel/2022-July/072167.html).
>>
>> Best regards,
>> Kuan-Hsun
>>
>> On Tue, Sep 13, 2022 at 3:35 PM Joel Sherrill  wrote:
>>
>>> What is this a remedy for?
>>>
>>> Why isn't the helper method OK to use?
>>>
>>> --joel
>>>
>>> On Tue, Sep 13, 2022 at 7:41 AM Strange369 
>>> wrote:
>>>
 ---
  cpukit/include/rtems/score/coremuteximpl.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/cpukit/include/rtems/score/coremuteximpl.h
 b/cpukit/include/rtems/score/coremuteximpl.h
 index d489a0d946..72d32f8030 100644
 --- a/cpukit/include/rtems/score/coremuteximpl.h
 +++ b/cpukit/include/rtems/score/coremuteximpl.h
 @@ -445,7 +445,7 @@ RTEMS_INLINE_ROUTINE Status_Control
 _CORE_ceiling_mutex_Set_owner(
scheduler_node = _Thread_Scheduler_get_home_node( owner );

if (
 -_Priority_Get_priority( &scheduler_node->Wait.Priority )
 +owner->Real_priority.priority
< the_mutex->Priority_ceiling.priority
) {
  _Thread_Wait_release_default_critical( owner, &lock_context );
 --
 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
>>
>>
>>
>> --
>> Diese Mail wurde mobil geschrieben. Etwaige Rechtschreibfehler sind volle
>> Absicht und als großzügiges Geschenk zu verstehen.
>>
>

-- 
Diese Mail wurde mobil geschrieben. Etwaige Rechtschreibfehler sind volle
Absicht und als großzügiges Geschenk zu verstehen.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Integrating the Formal Methods part of Qualification

2022-09-13 Thread Kuan-Hsun Chen 
Dear Andrew,

It's great to see a move toward formal verification for RTEMS.

>From our side (TU Dortmund in Germany and the University of Twente in the
Netherlands), we recently adopted Frama-C to verify ICPP and MrsP. A
potential deadlock is successfully identified, and a remedy is provided.
The result will be presented in EMSOFT this year (
https://ieeexplore.ieee.org/document/9852753/), and the verification
framework is publicly released here:
https://github.com/tu-dortmund-ls12-rt/Resource-Synchronization-Protocols-Verification-RTEMS

Due to the double-blind review process, I cannot chime in earlier in this
thread. Today earlier I have seen your patches regarding the chapter you
proposed. I wonder if you could take our contribution into account when you
organize the chapter?
A preprint can be found here
.
(The corresponding ticket will be prepared, and the patch together with a
test case will be submitted)

Best,
Kuan-Hsun

On Fri, Jul 22, 2022 at 12:37 PM andrew.butterfi...@scss.tcd.ie <
andrew.butterfi...@scss.tcd.ie> wrote:

> Dear RTEMS developers,
>
>
>
> thanks for the feedback below - I want to wrap this up and move to the
> next step.
>
>
>
> I propose to produce a complete draft of a formal methods section for the
> Software Engineering manual in rtems-docs
>
> This will add a "Formal Verification" section just after the existing
> "Test Framework" section.
>
>
>
> This will allow developers to get a much better idea of what is proposed,
> and for me to get feedback.
>
>
>
> For now, the section will state clearly at the start that this is a
> proposal and that the tooling and resources it describes
>
> won't yet be available in RTEMS proper.
>
>
>
> Files likely to be modified in rtems-docs:
>
> eng/index.rst
>
> common/refs.bib
>
>
>
> I'll add in  eng/formal-verification.rst
>
>
>
> I'll then submit patches for review in the usual way.
>
>
>
> Regards,
>
>   Andrew
>
>
>
>
>
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>  http://www.scss.tcd.ie/Andrew.Butterfield/
> 
>
>
>
>
>
> On 11/07/2022, 12:43, "devel on behalf of andrew.butterfi...@scss.tcd.ie"
> 
> wrote:
>
>
>
> On 6 Jul 2022, at 20:07, Gedare Bloom  wrote:
>
>
>
> On Sun, Jul 3, 2022 at 7:49 PM Chris Johns  wrote:
>
>
> On 2/7/2022 12:59 am, Andrew Butterfield wrote:
>
> On 1 Jul 2022, at 00:59, Chris Johns  > wrote:
>
>
> On 28/6/2022 11:09 pm, andrew.butterfi...@scss.tcd.ie
>  wrote:
>
> Dear RTEMS Developers,
>
> While the validation tests from the RTEMS pre-qualification activity are
> now merged into the RTEMS master, the work done in investigating and
> deploying formal methods techniques is not yet merged.
>
> The activity had two main phases: a planning phase (Nov 2018-Oct 2019)
> that explored various formal techniques, followed by an execution phase
> (Oct 2019-Nov 2021) that then applied selected techniques to selected
> parts of RTEMS. Some discussions occurred with the RTEMS community
> via the mailings lists over this time. A short third phase (Nov 2021 - Dec
> 2021)
> then reported on the outcomes. Each phase resulted in a technical report.
>
> The key decision made was to use Promela/SPIN for test generation, and
> to apply it to the Chains API, the Event Manager, and the SMP scheduler
> thread queues. This involved developing models in the Promela language
> and using the SPIN model-checker tool to both check their correctness
> and to generate execution scenarios that could be used to generate tests.
> Tools were developed using Python 3.8 to support this. Initial
> documentation
> about tools and how to use them was put into the 2nd phase report.
>
>
> Congratulations for the work and results you and others have managed to
> achieve.
> It is exciting to see this happening with RTEMS and being made public.
>
> We now come to the part where we explore the best way to integrate this
> into RTEMS. I am proposing to do this under the guidance of Sebastian
> Huber.
>
> The first suggested step is adding in new documentation to the RTEMS
> Software Engineering manual, as a new Formal Methods chapter. This would
> provide some motivation, as well as a "howto".
>
> I assume that I would initially describe the proposed changes using the
> patch
> review process described in the section on Preparing and Sending Patches in
> the User Manual.
>
> How do you feel I should best proceed?
>
>
> It is hard for me to answer until I understand what is bei

Console Input with xilinx_zynq_a9_qemu

2022-09-13 Thread Joel Sherrill 
Hi

This appears to be broken yet again. I am using qemu 5.1.91 built with the
RSB back in July. Does this work for anyone?

Advice or (even better) a fix appreciated.

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

Re: Console Input with xilinx_zynq_a9_qemu

2022-09-13 Thread Chris Johns 
On 14/9/2022 7:40 am, Joel Sherrill wrote:
> This appears to be broken yet again. I am using qemu 5.1.91 built with the RSB
> back in July. Does this work for anyone?
> 
> Advice or (even better) a fix appreciated.

It has been broken for a while. I first noticed it after the development branch
switched to an interrupt driven console but I have no idea if this is related or
not. I worked around the issue by using telnet.

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

Re: [PATCH 3/3] bsps/shared/: Use device tree blob

2022-09-13 Thread Alan Cudmore 
Hi Padmarao,
I am working on a RISC-V bsp variant for the Kendryte K210 and I am also
using an included DTB. For my k210 bsp, I changed
riscv/shared/start/start.S to set the address of the DTB array before
calling bsp_fdt_copy. If we change start.S to handle the following three
cases, we would not have to change the bsp_fdt_copy function. The three
cases are:
- no FDT, I assume griscv bsp
- uboot - a0 in contains the address of the u-boot loaded DTB
- polarfire, k210 and others - set a0 to the address of the included DTB
array
I think it's better to keep this function generic and not have to
conditionally ignore the input parameter.

Thanks,
Alan


On Thu, Sep 8, 2022 at 11:44 AM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:

> If the bsp is integrated and supported a device tree
> blob(dtb) then use dtb instead of using it from the U-Boot.
> ---
>  bsps/shared/start/bsp-fdt.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
> index 75a1ea41c9..7e1a698896 100644
> --- a/bsps/shared/start/bsp-fdt.c
> +++ b/bsps/shared/start/bsp-fdt.c
> @@ -32,6 +32,10 @@
>  #include 
>  #include 
>
> +#ifdef BSP_DTB_IS_SUPPORTED
> +#include BSP_DTB_HEADER_PATH
> +#endif
> +
>  #ifndef BSP_FDT_IS_SUPPORTED
>  #warning "BSP FDT support indication not defined"
>  #endif
> @@ -51,7 +55,12 @@ bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
>
>  void bsp_fdt_copy(const void *src)
>  {
> +#ifdef BSP_DTB_IS_SUPPORTED
> +const volatile uint32_t *s = (const uint32_t *) system_dtb;
> +#else
>const volatile uint32_t *s = (const uint32_t *) src;
> +#endif
> +
>  #ifdef BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
>uint32_t *d = (uint32_t *) ((uintptr_t) &bsp_fdt_blob[0]
>  - (uintptr_t) bsp_section_rodata_begin
> @@ -61,7 +70,7 @@ void bsp_fdt_copy(const void *src)
>  #endif
>
>if (s != d) {
> -size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
> +size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(s));
>  size_t aligned_size = roundup2(m, CPU_CACHE_LINE_BYTES);
>  size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
>  size_t i;
> --
> 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: Console Input with xilinx_zynq_a9_qemu

2022-09-13 Thread Joel Sherrill 
On Tue, Sep 13, 2022, 6:27 PM Chris Johns  wrote:

> On 14/9/2022 7:40 am, Joel Sherrill wrote:
> > This appears to be broken yet again. I am using qemu 5.1.91 built with
> the RSB
> > back in July. Does this work for anyone?
> >
> > Advice or (even better) a fix appreciated.
>
> It has been broken for a while. I first noticed it after the development
> branch
> switched to an interrupt driven console but I have no idea if this is
> related or
> not. I worked around the issue by using telnet.
>

Grrr... Does it work on hardware?

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

Re: Console Input with xilinx_zynq_a9_qemu

2022-09-13 Thread Chris Johns 
On 14/9/2022 2:45 pm, Joel Sherrill wrote:
> On Tue, Sep 13, 2022, 6:27 PM Chris Johns  > wrote:
> On 14/9/2022 7:40 am, Joel Sherrill wrote:
> > This appears to be broken yet again. I am using qemu 5.1.91 built with 
> the RSB
> > back in July. Does this work for anyone?
> >
> > Advice or (even better) a fix appreciated.
> 
> It has been broken for a while. I first noticed it after the development 
> branch
> switched to an interrupt driven console but I have no idea if this is 
> related or
> not. I worked around the issue by using telnet.
> 
> Grrr... Does it work on hardware?

Yes.

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