Re: [PATCH rtems-tools] tester/report: Apply test excludes to fatal-error

2023-08-17 Thread Chris Johns 
On 17/8/2023 10:43 pm, Kinsey Moore wrote:
> On Wed, Aug 16, 2023 at 9:47 PM Chris Johns  > wrote:
> 
> On 17/8/2023 7:36 am, Kinsey Moore wrote:
> > Before the fatal-error test result type was introduced, minimum.exe was
> > classified as an invalid test since it lacked a proper test header and
> > trailer. This applies the test exclusions to all test states to avoid
> > this happening again in the future.
> 
> I do not think this right. What state are you seeing?
> 
> 
> The minimum test fails with a fatal error:
>     "*** FATAL ***",
>     "fatal source: 0 (INTERNAL_ERROR_CORE)",
>     "fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)",
>     "RTEMS version: 6.0.0.c76c98c344d803fa80361884c4cc79f0b3607ec8",
>     "RTEMS tools: 12.3.1 20230626 (RTEMS 6, RSB
> 8e568b2ca3489d6bfa48e1d29618ea9b48a5b408, Newlib 4c7d0df)",
>     "executing thread ID: 0x09010001",
> 
> As far as I'm aware, this is a normal exit for minimum since it does nothing
> which includes not properly exiting the test by allowing Init() to return.
> 
> 
> While we cannot determine the pass state because there is no end message 
> we can
> determine if the test has timed out or is too long and they should be a 
> fail.
> 
> 
> This is not timing out or taking too long as per the above. I could move the
> check to cover just the invalid/fatal-error checks instead of all of them if 
> you
> prefer.

This looks to me like an issue in minimum and it looks to me like minimal has
some other issue. What is printing out the message? If there is code in minimal
to print this error then why not print a normal test start and end banner?

My understanding is minimal has not means to output anything.

Chris

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

Re: [PATCH] spec/cpukit: Omit Cortex-M from libdebugger build

2023-08-17 Thread Chris Johns 
On 18/8/2023 7:01 am, Kinsey Moore wrote:
> On Thu, Aug 17, 2023 at 7:11 AM Kinsey Moore  > wrote:
> 
> On Wed, Aug 16, 2023 at 9:42 PM Chris Johns  > wrote:
> 
> On 17/8/2023 6:30 am, Kinsey Moore wrote:
> > The current ARM support in libdebugger does not cover Cortex-M 
> series
> > cores since it requires support for CP14 system register accessor
> > instructions. Cortex-M series cores support debug monitor mode, but 
> its
> > configuration is accessed by memory mapped registers instead of 
> using
> > CP14. This omits building libdebugger from BSPs that use a cortex-m 
> ABI
> > flag.
> 
> The ARM libdebugger has support to use memory mapped registers. It is
> determined
>  by the ROM and then rtems_debugger_arm_debug_registers. I think the 
> code
> currently assume CP14 instructions but I think that could be made
> conditional
> where needed?
> 
> Are these builds of Cortex-M processors able to support libdebugger?
> 
> I have been rejecting changes like this unless there is a reason it
> cannot be
> made to work. Are there reasons it cannot be made to work?
> 
> 
> As to my current understanding, I believe that the Cortex-M3/4/7 cores can
> support libdebugger via their exclusive monitor mode. I'll see if I can 
> work
> around the CP14 issues instead.
> 
> 
> Reading into the relevant Architecture and Technical reference manuals, the 
> ROM
> tables in the Cortex-M cores do not expose information about the debug and 
> data
> watchpoint blocks. It looks like all the breakpoint (0xE0002000) and 
> watchpoint
> (0xE0001000) controls are the same IP at the same address across the Cortex-M
> line, but are in no way compatible with the CP14-based breakpoint and 
> watchpoint
> blocks in the Cortex-A/R lines of cores. The Cortex-M cores require a nearly
> unrelated libdebugger implementation.

Thanks for this and looking into it. I am fine with the change now we understand
it is not compatible. It sounds like a new back end would be cleaner for both
types of devices.

The patch is approved.

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

Re: [PATCH] spec/cpukit: Omit Cortex-M from libdebugger build

2023-08-17 Thread Kinsey Moore 
On Thu, Aug 17, 2023 at 7:11 AM Kinsey Moore 
wrote:

> On Wed, Aug 16, 2023 at 9:42 PM Chris Johns  wrote:
>
>> On 17/8/2023 6:30 am, Kinsey Moore wrote:
>> > The current ARM support in libdebugger does not cover Cortex-M series
>> > cores since it requires support for CP14 system register accessor
>> > instructions. Cortex-M series cores support debug monitor mode, but its
>> > configuration is accessed by memory mapped registers instead of using
>> > CP14. This omits building libdebugger from BSPs that use a cortex-m ABI
>> > flag.
>>
>> The ARM libdebugger has support to use memory mapped registers. It is
>> determined
>>  by the ROM and then rtems_debugger_arm_debug_registers. I think the code
>> currently assume CP14 instructions but I think that could be made
>> conditional
>> where needed?
>>
>> Are these builds of Cortex-M processors able to support libdebugger?
>>
>> I have been rejecting changes like this unless there is a reason it
>> cannot be
>> made to work. Are there reasons it cannot be made to work?
>>
>
> As to my current understanding, I believe that the Cortex-M3/4/7 cores can
> support libdebugger via their exclusive monitor mode. I'll see if I can
> work around the CP14 issues instead.
>

Reading into the relevant Architecture and Technical reference manuals, the
ROM tables in the Cortex-M cores do not expose information about the debug
and data watchpoint blocks. It looks like all the breakpoint (0xE0002000)
and watchpoint (0xE0001000) controls are the same IP at the same address
across the Cortex-M line, but are in no way compatible with the CP14-based
breakpoint and watchpoint blocks in the Cortex-A/R lines of cores. The
Cortex-M cores require a nearly unrelated libdebugger implementation.

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

Re: Status of CAN API?

2023-08-17 Thread Gedare Bloom 
Hi Phil,

On Wed, Aug 9, 2023 at 6:38 AM Philip Kirkpatrick
 wrote:
>
> Hello,
>
> Some people on our team here at Reflex are preparing to implement some CAN 
> drivers.  Specifically for TMS570 and for ZynqMP-RPU (side note my latest 
> patch for that on Jun 29th is still sitting there unreviewed).  I was 
> wondering what the current status of the CAN API is.
Feel free to ping the patch. At the moment, this email based system is
all we have, and sometimes patches may not get a lot of attention
especially if no one "owns" it -- such as new BSPs.

> I saw in August of last year and API was added and then last month was 
> reverted with this patch:
> https://lists.rtems.org/pipermail/devel/2023-July/076013.html
> The comment on the patch says the API isn't mature enough for release.  What 
> deficiencies need to be resolved in the API, is this being actively worked 
> on, and should we design against this API or is there a different API we 
> should target?
>
The implementation of that API was deficient. It did not support
multiple read/write transactions, it had a custom-built ring buffer
that was not fully vetted, and some other problems related to
threads+priorities. I expect to have some time to look at how to
provide better CAN support inside of RTEMS. This has been an ongoing
discussion I've been having with Pavel Pisa and others for many years
now (a decade?). The direction that I will prefer to go is to port
LinCAN
https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf

Both Pavel and I are interested in seeing this come through. So far,
we mostly do it on volunteer time or as side pieces of other work.
Pavel's group has good experience with CAN and CAN FD, and with both
TMS570 and the Zynq (non-MP) boards, with Linux, RTEMS, and NuttX. We
would be open to collaborating, subject to whatever time or resource
constraints everyone has :) Michal Lenc has been working on this topic
as a thesis, "CAN FD Support for Space Grade Real-Time RTEMS
Executive"

Regarding LinCAN itself, there is one design challenge to port it,
which has to do with the use of internal FIFOs already in LinCAN code
base, or to use RTEMS/POSIX message queue style to interface the CAN
drivers and userspace. I actually see there are good reasons to
support both ways, and may explore exactly that. We have had quite
some discussions here on the topic:
* https://lists.rtems.org/pipermail/devel/2023-March/074537.html
* https://lists.rtems.org/pipermail/devel/2022-April/071235.html
* https://lists.rtems.org/pipermail/devel/2013-April/030761.html (for
historical good measure)

Gedare

> Thank you,
> Phil
> ___
> 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-tools] tester/report: Apply test excludes to fatal-error

2023-08-17 Thread Kinsey Moore 
On Wed, Aug 16, 2023 at 9:47 PM Chris Johns  wrote:

> On 17/8/2023 7:36 am, Kinsey Moore wrote:
> > Before the fatal-error test result type was introduced, minimum.exe was
> > classified as an invalid test since it lacked a proper test header and
> > trailer. This applies the test exclusions to all test states to avoid
> > this happening again in the future.
>
> I do not think this right. What state are you seeing?
>

The minimum test fails with a fatal error:
"*** FATAL ***",
"fatal source: 0 (INTERNAL_ERROR_CORE)",
"fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)",
"RTEMS version: 6.0.0.c76c98c344d803fa80361884c4cc79f0b3607ec8",
"RTEMS tools: 12.3.1 20230626 (RTEMS 6, RSB
8e568b2ca3489d6bfa48e1d29618ea9b48a5b408, Newlib 4c7d0df)",
"executing thread ID: 0x09010001",

As far as I'm aware, this is a normal exit for minimum since it does
nothing which includes not properly exiting the test by allowing Init() to
return.


> While we cannot determine the pass state because there is no end message
> we can
> determine if the test has timed out or is too long and they should be a
> fail.
>

This is not timing out or taking too long as per the above. I could move
the check to cover just the invalid/fatal-error checks instead of all of
them if you prefer.

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

Re: [PATCH] spec/cpukit: Omit Cortex-M from libdebugger build

2023-08-17 Thread Kinsey Moore 
On Wed, Aug 16, 2023 at 9:42 PM Chris Johns  wrote:

> On 17/8/2023 6:30 am, Kinsey Moore wrote:
> > The current ARM support in libdebugger does not cover Cortex-M series
> > cores since it requires support for CP14 system register accessor
> > instructions. Cortex-M series cores support debug monitor mode, but its
> > configuration is accessed by memory mapped registers instead of using
> > CP14. This omits building libdebugger from BSPs that use a cortex-m ABI
> > flag.
>
> The ARM libdebugger has support to use memory mapped registers. It is
> determined
>  by the ROM and then rtems_debugger_arm_debug_registers. I think the code
> currently assume CP14 instructions but I think that could be made
> conditional
> where needed?
>
> Are these builds of Cortex-M processors able to support libdebugger?
>
> I have been rejecting changes like this unless there is a reason it cannot
> be
> made to work. Are there reasons it cannot be made to work?
>

As to my current understanding, I believe that the Cortex-M3/4/7 cores can
support libdebugger via their exclusive monitor mode. I'll see if I can
work around the CP14 issues instead.

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