Re: Xilinx Zynq console rx not working

[Chris Johns]

On 14/8/21 12:40 am, Kinsey Moore wrote:
> On 8/13/2021 03:05, Chris Johns wrote:
>> Hi,
>>
>> I am bring up a major app on RTEMS 6 and LibBSD on custom Zynq hardware and 
>> I am
>> not getting any receive interrupts from the console UART. The same hardware
>> works with RTEMS 4.11 and RTEMS 5.
>>
>> I also do not see any console input with qemu and I thought this was 
>> something
>> in qemu but I am now not so sure.
>>
>> Anyone else seeing this issue?
>>
>> There has been a lot of playing with the Zynq UART driver recently.
> 
> I just went through and backed out all those changes you mentioned back to 
> when
> the polled-only driver was split out and I still don't have functionality on
> Zynq under QEMU. Testing using fileio.exe, things are partially functional 
> until
> I revert the change that enabled set_attributes. After the commit that enables
> set_attributes for the zynq UART, fileio produces output waiting for user 
> input
> and will accept the first character to open the menu, but accepts no further
> input. Before that commit, the fileio test doesn't produce the expected 
> output.
> 
> A full bisect would probably provide more accurate results, but this is what I
> could do quickly.
> 
> Note that ZynqMP fileio works on QEMU with current code and is fully
> operational. It is almost certainly the exact same emulated peripheral in QEMU
> and the hardware is supposed to be very close if not identical as well.

I have taken a closer look at the driver. I am receiving RX interrupts and the
characters are being queued however the receive FIFO trigger interrupt is only
raised when the FIFO reaches the set threshold of half the FIFO size. I suspect
there is an assumption the RX timeout will fire but it is not.

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

Re: Xilinx Zynq console rx not working

[Chris Johns]

On 16/8/21 6:38 pm, Chris Johns wrote:
> On 14/8/21 12:40 am, Kinsey Moore wrote:
>> On 8/13/2021 03:05, Chris Johns wrote:
>>> Hi,
>>>
>>> I am bring up a major app on RTEMS 6 and LibBSD on custom Zynq hardware and 
>>> I am
>>> not getting any receive interrupts from the console UART. The same hardware
>>> works with RTEMS 4.11 and RTEMS 5.
>>>
>>> I also do not see any console input with qemu and I thought this was 
>>> something
>>> in qemu but I am now not so sure.
>>>
>>> Anyone else seeing this issue?
>>>
>>> There has been a lot of playing with the Zynq UART driver recently.
>>
>> I just went through and backed out all those changes you mentioned back to 
>> when
>> the polled-only driver was split out and I still don't have functionality on
>> Zynq under QEMU. Testing using fileio.exe, things are partially functional 
>> until
>> I revert the change that enabled set_attributes. After the commit that 
>> enables
>> set_attributes for the zynq UART, fileio produces output waiting for user 
>> input
>> and will accept the first character to open the menu, but accepts no further
>> input. Before that commit, the fileio test doesn't produce the expected 
>> output.
>>
>> A full bisect would probably provide more accurate results, but this is what 
>> I
>> could do quickly.
>>
>> Note that ZynqMP fileio works on QEMU with current code and is fully
>> operational. It is almost certainly the exact same emulated peripheral in 
>> QEMU
>> and the hardware is supposed to be very close if not identical as well.
> 
> I have taken a closer look at the driver. I am receiving RX interrupts and the
> characters are being queued however the receive FIFO trigger interrupt is only
> raised when the FIFO reaches the set threshold of half the FIFO size. I 
> suspect
> there is an assumption the RX timeout will fire but it is not.
> 

Doing this is questionable 

https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222

You cannot send a character when touching the attributes. Where is this hardware
bug documented by Xilinx?

My application does this ...

if (tcgetattr(fileno(stdout), &term) < 0)
error_message();
cfsetispeed (&term, B115200);
cfsetospeed (&term, B115200);
if (tcsetattr (fileno(stdout), TCSADRAIN, &term) < 0)
error_message();
if (tcgetattr(fileno(stdin), &term) < 0)
error_message();
cfsetispeed (&term, B115200);
cfsetospeed (&term, B115200);
if (tcsetattr (fileno(stdin), TCSADRAIN, &term) < 0)
error_message();

and this kills the receive interrupts.

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

[PATCH rtems-docs] bsps/raspberrypi: Change firmware version, add SPI & I2C support

[pranav]

---
 user/bsps/arm/raspberrypi.rst | 51 ++-
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
index c26f4b5..11dcc30 100644
--- a/user/bsps/arm/raspberrypi.rst
+++ b/user/bsps/arm/raspberrypi.rst
@@ -5,8 +5,9 @@
 raspberrypi
 ===
 
-This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
-The support for `Raspberry Pi 3` is work under progress.
+The 'raspberrypi' BSP supports the single core models (Zero,  Zero W, A+, B+),
+and the 'raspberrypi2' BSP supports the Raspberry Pi 2, Raspberry Pi 3 A+, and 
Raspberry Pi 3.
+The Raspberry Pi 4 is not supported currently.
 The default bootloader on the Raspberry Pi which is used to boot Raspbian
 or other OS can be also used to boot RTEMS. U-boot can also be used.
 
@@ -19,10 +20,12 @@ The bootloader looks for a kernel image, by default the 
kernel images must
 have a name of the form ``kernel*.img`` but this can be changed by adding
 `kernel=` to ``config.txt``.
 
-You must provide the required files for the GPU to proceed. These files
+You must provide the required firmware files on the SD card for the GPU to 
proceed,
+and thereby to boot RTEMS. 
+The BSP currently boots up with an older version of the official firmware. 
These files
 can be downloaded from
-`the Raspberry Pi Firmware Repository 
`_.
-You can remove the ``kernel*.img`` files if you want too, but don't touch
+`the Raspberry Pi Firmware Repository 
`_.
+You can remove the ``kernel*.img`` files if you want to, but don't touch
 the other files.
 
 Copy these files in to a SD card with FAT filesystem.
@@ -46,10 +49,46 @@ Make sure you have these lines below, in your 
``config.txt``.
 
 .. code-block:: none
 
- enable_uart=1
+ dtoverlay=disable-bt
  kernel_address=0x20
  kernel=kernel.img
 
+SPI Driver
+
+
+SPI drivers are registered by the ``rpi_spi_init(bool bidirectional_mode)`` 
function.
+
+.. code-block:: none
+
+ #include 
+ #include 
+
+ void spi_init(void)
+ {
+   int rv;
+
+   rv = rpi_spi_init(false);
+   assert(rv == 0);
+ }
+
+I2C Driver
+
+
+I2C drivers are registered by the ``rpi_setup_i2c_bus()`` function.
+
+.. code-block:: none
+
+ #include 
+ #include 
+
+ void i2c_init(void)
+ {
+   int rv;
+
+   rv = rpi_setup_i2c_bus();
+   assert(rv == 0);
+ }
+
 Testing using QEMU
 --
 
-- 
2.30.2

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

[PATCH 5/5] score: Delete unused rtems_ada_self

[Sebastian Huber]

---
 cpukit/include/rtems/score/threadimpl.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/cpukit/include/rtems/score/threadimpl.h 
b/cpukit/include/rtems/score/threadimpl.h
index 45c0795d9c..f25e347e33 100644
--- a/cpukit/include/rtems/score/threadimpl.h
+++ b/cpukit/include/rtems/score/threadimpl.h
@@ -74,11 +74,6 @@ typedef struct {
  */
 extern Thread_Zombie_registry _Thread_Zombies;
 
-/**
- *  Self for the GNU Ada Run-Time
- */
-extern void *rtems_ada_self;
-
 /**
  * @brief Object identifier of the global constructor thread.
  *
-- 
2.26.2

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

[PATCH 4/5] score: Make zombie registry observable

[Sebastian Huber]

This helps to write tests for _Thread_Wait_for_execution_stop().

Rename Thread_Zombie_control in Thread_Zombie_registry.
---
 cpukit/include/rtems/score/threadimpl.h | 27 +++
 cpukit/score/src/threadrestart.c| 29 +++--
 2 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/cpukit/include/rtems/score/threadimpl.h 
b/cpukit/include/rtems/score/threadimpl.h
index c4b6c941a4..45c0795d9c 100644
--- a/cpukit/include/rtems/score/threadimpl.h
+++ b/cpukit/include/rtems/score/threadimpl.h
@@ -47,6 +47,33 @@ extern "C" {
  * @{
  */
 
+/**
+ * @brief The thread zombie registry is used to register threads in the
+ *   #STATES_ZOMBIE state.
+ */
+typedef struct {
+#if defined(RTEMS_SMP)
+  /**
+   * @brief This lock protects the zombie chain.
+   */
+  ISR_lock_Control Lock;
+#endif
+
+  /**
+   * @brief This chain contains the registered zombie threads.
+   */
+  Chain_Control Chain;
+} Thread_Zombie_registry;
+
+/**
+ * @brief This object is a registry for threads in the #STATES_ZOMBIE state.
+ *
+ * The registry contains zombie threads waiting to get killed by
+ * _Thread_Kill_zombies().  Use _Thread_Add_to_zombie_registry() to add zombie
+ * threads to the registry.
+ */
+extern Thread_Zombie_registry _Thread_Zombies;
+
 /**
  *  Self for the GNU Ada Run-Time
  */
diff --git a/cpukit/score/src/threadrestart.c b/cpukit/score/src/threadrestart.c
index 5b1d6ae5f1..2240d8f713 100644
--- a/cpukit/score/src/threadrestart.c
+++ b/cpukit/score/src/threadrestart.c
@@ -44,14 +44,11 @@ static void _Thread_Life_action_handler(
   ISR_lock_Context *lock_context
 );
 
-typedef struct {
-  Chain_Control Chain;
-  ISR_lock_Control Lock;
-} Thread_Zombie_control;
-
-static Thread_Zombie_control _Thread_Zombies = {
-  .Chain = CHAIN_INITIALIZER_EMPTY( _Thread_Zombies.Chain ),
-  .Lock = ISR_LOCK_INITIALIZER( "thread zombies" )
+Thread_Zombie_registry _Thread_Zombies = {
+#if defined(RTEMS_SMP)
+  .Lock = ISR_LOCK_INITIALIZER( "Thread Zombies" ),
+#endif
+  .Chain = CHAIN_INITIALIZER_EMPTY( _Thread_Zombies.Chain )
 };
 
 static void _Thread_Raise_real_priority(
@@ -115,10 +112,10 @@ static void _Thread_Wake_up_joining_threads( 
Thread_Control *the_thread )
   );
 }
 
-static void _Thread_Add_to_zombie_chain( Thread_Control *the_thread )
+static void _Thread_Add_to_zombie_registry( Thread_Control *the_thread )
 {
-  ISR_lock_Context   lock_context;
-  Thread_Zombie_control *zombies;
+  ISR_lock_Contextlock_context;
+  Thread_Zombie_registry *zombies;
 
   zombies = &_Thread_Zombies;
   _ISR_lock_ISR_disable_and_acquire( &zombies->Lock, &lock_context );
@@ -148,7 +145,7 @@ static void _Thread_Make_zombie( Thread_Control *the_thread 
)
* threads, so that they are able to clean up the thread immediately.  This
* matters for SMP configurations.
*/
-  _Thread_Add_to_zombie_chain( the_thread );
+  _Thread_Add_to_zombie_registry( the_thread );
 
   _Thread_Wake_up_joining_threads( the_thread );
 }
@@ -169,16 +166,16 @@ static void _Thread_Wait_for_execution_stop( const 
Thread_Control *the_thread )
 #endif
 }
 
-static Thread_Control *_Thread_Get_zombie( Thread_Zombie_control *zombies )
+static Thread_Control *_Thread_Get_zombie( Thread_Zombie_registry *zombies )
 {
   return (Thread_Control *) _Chain_Get_unprotected( &zombies->Chain );
 }
 
 void _Thread_Kill_zombies( void )
 {
-  ISR_lock_Context   lock_context;
-  Thread_Zombie_control *zombies;
-  Thread_Control*the_thread;
+  ISR_lock_Contextlock_context;
+  Thread_Zombie_registry *zombies;
+  Thread_Control *the_thread;
 
   zombies = &_Thread_Zombies;
   _ISR_lock_ISR_disable_and_acquire( &zombies->Lock, &lock_context );
-- 
2.26.2

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

[PATCH 2/5] score: Simplify _Per_CPU_Wait_for_job()

[Sebastian Huber]

The _SMP_Fatal() is a no-return function, so the "break" statement is
superfluous.
---
 cpukit/score/src/percpujobs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cpukit/score/src/percpujobs.c b/cpukit/score/src/percpujobs.c
index f273f7d17d..3de3e4a7bd 100644
--- a/cpukit/score/src/percpujobs.c
+++ b/cpukit/score/src/percpujobs.c
@@ -127,7 +127,6 @@ void _Per_CPU_Wait_for_job(
 break;
   default:
 _SMP_Fatal( SMP_FATAL_WRONG_CPU_STATE_TO_PERFORM_JOBS );
-break;
 }
   }
 }
-- 
2.26.2

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

[PATCH 1/5] score: Simplify _Thread_Create_idle_for_CPU()

[Sebastian Huber]

Online processors have a scheduler assigned.
---
 cpukit/score/src/threadcreateidle.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/cpukit/score/src/threadcreateidle.c 
b/cpukit/score/src/threadcreateidle.c
index 395dcc9c12..f5ffc9bad8 100644
--- a/cpukit/score/src/threadcreateidle.c
+++ b/cpukit/score/src/threadcreateidle.c
@@ -38,13 +38,7 @@ static void _Thread_Create_idle_for_CPU( Per_CPU_Control 
*cpu )
 
   memset( &config, 0, sizeof( config ) );
   config.scheduler = _Scheduler_Get_by_CPU( cpu );
-
-#if defined(RTEMS_SMP)
-  if ( config.scheduler == NULL ) {
-return;
-  }
-#endif
-
+  _Assert( config.scheduler != NULL );
   config.priority = _Scheduler_Map_priority(
 config.scheduler,
 config.scheduler->maximum_priority
-- 
2.26.2

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

[PATCH 3/5] score: Simplify _Thread_Kill_zombies()

[Sebastian Huber]

---
 cpukit/score/src/threadrestart.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/cpukit/score/src/threadrestart.c b/cpukit/score/src/threadrestart.c
index 4b1907a2d9..5b1d6ae5f1 100644
--- a/cpukit/score/src/threadrestart.c
+++ b/cpukit/score/src/threadrestart.c
@@ -153,7 +153,7 @@ static void _Thread_Make_zombie( Thread_Control *the_thread 
)
   _Thread_Wake_up_joining_threads( the_thread );
 }
 
-static void _Thread_Wait_for_execution_stop( Thread_Control *the_thread )
+static void _Thread_Wait_for_execution_stop( const Thread_Control *the_thread )
 {
 #if defined(RTEMS_SMP)
   /*
@@ -169,16 +169,21 @@ static void _Thread_Wait_for_execution_stop( 
Thread_Control *the_thread )
 #endif
 }
 
+static Thread_Control *_Thread_Get_zombie( Thread_Zombie_control *zombies )
+{
+  return (Thread_Control *) _Chain_Get_unprotected( &zombies->Chain );
+}
+
 void _Thread_Kill_zombies( void )
 {
-  ISR_lock_Context lock_context;
-  Thread_Zombie_control *zombies = &_Thread_Zombies;
-  Thread_Control *the_thread;
+  ISR_lock_Context   lock_context;
+  Thread_Zombie_control *zombies;
+  Thread_Control*the_thread;
 
+  zombies = &_Thread_Zombies;
   _ISR_lock_ISR_disable_and_acquire( &zombies->Lock, &lock_context );
 
-  the_thread = (Thread_Control *) _Chain_Get_unprotected( &zombies->Chain );
-  while ( the_thread != NULL ) {
+  while ( ( the_thread = _Thread_Get_zombie( zombies ) ) != NULL ) {
 Thread_Information *information;
 
 _ISR_lock_Release_and_ISR_enable( &zombies->Lock, &lock_context );
@@ -188,8 +193,6 @@ void _Thread_Kill_zombies( void )
 _Thread_Free( information, the_thread );
 
 _ISR_lock_ISR_disable_and_acquire( &zombies->Lock, &lock_context );
-
-the_thread = (Thread_Control *) _Chain_Get_unprotected( &zombies->Chain );
   }
 
   _ISR_lock_Release_and_ISR_enable( &zombies->Lock, &lock_context );
-- 
2.26.2

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

Re: Xilinx Zynq console rx not working

[Kinsey Moore]

On 8/16/2021 04:45, Chris Johns wrote:

On 16/8/21 6:38 pm, Chris Johns wrote:
I have taken a closer look at the driver. I am receiving RX 
interrupts and the

characters are being queued however the receive FIFO trigger interrupt is only
raised when the FIFO reaches the set threshold of half the FIFO size. I suspect
there is an assumption the RX timeout will fire but it is not.


Doing this is questionable 

https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222

You cannot send a character when touching the attributes. Where is this hardware
bug documented by Xilinx?
The attributes are done being touched and the TX/RX enable flags are set 
again before sending the character. I was seeing the same behavior on 
Zynq QEMU even with this code removed.


I couldn't find the hardware bug documented anywhere, but out of the 3 
ZynqMP boards I have one requires this consistently.


My application does this ...

 if (tcgetattr(fileno(stdout), &term) < 0)
 error_message();
 cfsetispeed (&term, B115200);
 cfsetospeed (&term, B115200);
 if (tcsetattr (fileno(stdout), TCSADRAIN, &term) < 0)
 error_message();
 if (tcgetattr(fileno(stdin), &term) < 0)
 error_message();
 cfsetispeed (&term, B115200);
 cfsetospeed (&term, B115200);
 if (tcsetattr (fileno(stdin), TCSADRAIN, &term) < 0)
 error_message();

and this kills the receive interrupts.


Does removing the null character kick restore functionality for you in 
this case?



Kinsey

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

Re: Xilinx Zynq console rx not working

[mbenson]

I just built and ran the zc702 build on Qemu yesterday with no problems.  I ran 
the hello.exe sample.  But, I launched it using Vitis 2020.2 so maybe it was a 
qemu difference?  Master branch.  RTEMS 6.

Sent from my iPhone

> On Aug 16, 2021, at 08:03, Kinsey Moore  wrote:
> 
> On 8/16/2021 04:45, Chris Johns wrote:
>>> On 16/8/21 6:38 pm, Chris Johns wrote:
>>> I have taken a closer look at the driver. I am receiving RX interrupts and 
>>> the
>>> characters are being queued however the receive FIFO trigger interrupt is 
>>> only
>>> raised when the FIFO reaches the set threshold of half the FIFO size. I 
>>> suspect
>>> there is an assumption the RX timeout will fire but it is not.
>> Doing this is questionable 
>> https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222
>> You cannot send a character when touching the attributes. Where is this 
>> hardware
>> bug documented by Xilinx?
> The attributes are done being touched and the TX/RX enable flags are set 
> again before sending the character. I was seeing the same behavior on Zynq 
> QEMU even with this code removed.
> 
> I couldn't find the hardware bug documented anywhere, but out of the 3 ZynqMP 
> boards I have one requires this consistently.
>> My application does this ...
>>if (tcgetattr(fileno(stdout), &term) < 0)
>>error_message();
>>cfsetispeed (&term, B115200);
>>cfsetospeed (&term, B115200);
>>if (tcsetattr (fileno(stdout), TCSADRAIN, &term) < 0)
>>error_message();
>>if (tcgetattr(fileno(stdin), &term) < 0)
>>error_message();
>>cfsetispeed (&term, B115200);
>>cfsetospeed (&term, B115200);
>>if (tcsetattr (fileno(stdin), TCSADRAIN, &term) < 0)
>>error_message();
>> and this kills the receive interrupts.
> 
> Does removing the null character kick restore functionality for you in this 
> case?
> 
> 
> Kinsey
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Xilinx Zynq console rx not working

[Kinsey Moore]

On 8/16/2021 08:40, mben...@windhoverlabs.com wrote:

I just built and ran the zc702 build on Qemu yesterday with no problems.  I ran 
the hello.exe sample.  But, I launched it using Vitis 2020.2 so maybe it was a 
qemu difference?  Master branch.  RTEMS 6.

Sent from my iPhone


Output seems to work fine; it's the input that's not working properly. 
You'll see this behavior if you run the fileio.exe test since it 
requires interaction with the console. I haven't tried on hardware, so 
that may also be a difference.



Kinsey

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

Re: Xilinx Zynq console rx not working

[mbenson]

Ah.  Yes.  I did not test input.  Thanks for the heads up.

Sent from my iPhone

> On Aug 16, 2021, at 09:04, Kinsey Moore  wrote:
> 
> On 8/16/2021 08:40, mben...@windhoverlabs.com wrote:
>> I just built and ran the zc702 build on Qemu yesterday with no problems.  I 
>> ran the hello.exe sample.  But, I launched it using Vitis 2020.2 so maybe it 
>> was a qemu difference?  Master branch.  RTEMS 6.
>> 
>> Sent from my iPhone
> 
> Output seems to work fine; it's the input that's not working properly. You'll 
> see this behavior if you run the fileio.exe test since it requires 
> interaction with the console. I haven't tried on hardware, so that may also 
> be a difference.
> 
> 
> Kinsey
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS Tools on 5 release can't be build with modern LLVM

[Christian MAUDERER]

Hello,

I noted that I can't build the RTEMS 5 toolchain if I have a modern LLVM 
installed using the RTEMS source builder. Therefore I would like to 
backport the patch 37ad446d9dce3 ([1]) to the 5 branch. Is that OK? If 
someone acknowledges it, I would do the following steps without further 
review (but of course with testing):


1. Create a ticket for the problem.
2. In rtems-tools: Cherry pick the patch 37ad446d9dce3 to the 5 branch.
3. In rtems-source-builder: Backport the patch 91932d0a0 [2] to the 5 
branch (or rather re-create it because it will be a different commit and 
a different hash).


Best regards

Christian

[1] 
https://git.rtems.org/rtems-tools/commit/?id=37ad446d9dce3438d6d32e1caf56d3fdccdd2ad0


[2] 
https://git.rtems.org/rtems-source-builder/commit/?id=91932d0a0c86400366f9c75a62123b6488ff458a

--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Tools on 5 release can't be build with modern LLVM

[Joel Sherrill]

On Mon, Aug 16, 2021 at 9:49 AM Christian MAUDERER
 wrote:
>
> Hello,
>
> I noted that I can't build the RTEMS 5 toolchain if I have a modern LLVM
> installed using the RTEMS source builder. Therefore I would like to
> backport the patch 37ad446d9dce3 ([1]) to the 5 branch. Is that OK? If
> someone acknowledges it, I would do the following steps without further
> review (but of course with testing):
>
> 1. Create a ticket for the problem.
> 2. In rtems-tools: Cherry pick the patch 37ad446d9dce3 to the 5 branch.
> 3. In rtems-source-builder: Backport the patch 91932d0a0 [2] to the 5
> branch (or rather re-create it because it will be a different commit and
> a different hash).

I'm ok with this. I remember doing a patch for the opposite direction.
I couldn't
build on an older gcc because it assumed a different language version as
default. gcc 4.8 as on CentOS 7 assumes C++03. Newer versions assume C++11
as the base. Similarly newer gcc's seem to default to C11.

I posted a few weeks ago that users should really be careful to always use
-std and consciously pick what they want.

--joel

>
> Best regards
>
> Christian
>
> [1]
> https://git.rtems.org/rtems-tools/commit/?id=37ad446d9dce3438d6d32e1caf56d3fdccdd2ad0
>
> [2]
> https://git.rtems.org/rtems-source-builder/commit/?id=91932d0a0c86400366f9c75a62123b6488ff458a
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Tools on 5 release can't be build with modern LLVM

[Christian MAUDERER]

Hello Joel,

Am 16.08.21 um 17:03 schrieb Joel Sherrill:

On Mon, Aug 16, 2021 at 9:49 AM Christian MAUDERER
 wrote:


Hello,

I noted that I can't build the RTEMS 5 toolchain if I have a modern LLVM
installed using the RTEMS source builder. Therefore I would like to
backport the patch 37ad446d9dce3 ([1]) to the 5 branch. Is that OK? If
someone acknowledges it, I would do the following steps without further
review (but of course with testing):

1. Create a ticket for the problem.
2. In rtems-tools: Cherry pick the patch 37ad446d9dce3 to the 5 branch.
3. In rtems-source-builder: Backport the patch 91932d0a0 [2] to the 5
branch (or rather re-create it because it will be a different commit and
a different hash).


I'm ok with this. I remember doing a patch for the opposite direction.
I couldn't
build on an older gcc because it assumed a different language version as
default. gcc 4.8 as on CentOS 7 assumes C++03. Newer versions assume C++11
as the base. Similarly newer gcc's seem to default to C11.


Thanks. I'll wait a bit more before adding the patches in case someone 
else want's to object.




I posted a few weeks ago that users should really be careful to always use
-std and consciously pick what they want.


In this case, the version of the standard depends quite a lot on the 
LLVM headers. LLVM seems to love using new features.


Best regards

Christian



--joel



Best regards

Christian

[1]
https://git.rtems.org/rtems-tools/commit/?id=37ad446d9dce3438d6d32e1caf56d3fdccdd2ad0

[2]
https://git.rtems.org/rtems-source-builder/commit/?id=91932d0a0c86400366f9c75a62123b6488ff458a
--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Tools on 5 release can't be build with modern LLVM

[Joel Sherrill]

On Mon, Aug 16, 2021 at 10:08 AM Christian MAUDERER
 wrote:
>
> Hello Joel,
>
> Am 16.08.21 um 17:03 schrieb Joel Sherrill:
> > On Mon, Aug 16, 2021 at 9:49 AM Christian MAUDERER
> >  wrote:
> >>
> >> Hello,
> >>
> >> I noted that I can't build the RTEMS 5 toolchain if I have a modern LLVM
> >> installed using the RTEMS source builder. Therefore I would like to
> >> backport the patch 37ad446d9dce3 ([1]) to the 5 branch. Is that OK? If
> >> someone acknowledges it, I would do the following steps without further
> >> review (but of course with testing):
> >>
> >> 1. Create a ticket for the problem.
> >> 2. In rtems-tools: Cherry pick the patch 37ad446d9dce3 to the 5 branch.
> >> 3. In rtems-source-builder: Backport the patch 91932d0a0 [2] to the 5
> >> branch (or rather re-create it because it will be a different commit and
> >> a different hash).
> >
> > I'm ok with this. I remember doing a patch for the opposite direction.
> > I couldn't
> > build on an older gcc because it assumed a different language version as
> > default. gcc 4.8 as on CentOS 7 assumes C++03. Newer versions assume C++11
> > as the base. Similarly newer gcc's seem to default to C11.
>
> Thanks. I'll wait a bit more before adding the patches in case someone
> else want's to object.


Good plan.

> >
> > I posted a few weeks ago that users should really be careful to always use
> > -std and consciously pick what they want.
>
> In this case, the version of the standard depends quite a lot on the
> LLVM headers. LLVM seems to love using new features.

Then this is probably not the first time we will face this.

--joel

> Best regards
>
> Christian
>
> >
> > --joel
> >
> >>
> >> Best regards
> >>
> >> Christian
> >>
> >> [1]
> >> https://git.rtems.org/rtems-tools/commit/?id=37ad446d9dce3438d6d32e1caf56d3fdccdd2ad0
> >>
> >> [2]
> >> https://git.rtems.org/rtems-source-builder/commit/?id=91932d0a0c86400366f9c75a62123b6488ff458a
> >> --
> >> 
> >> embedded brains GmbH
> >> Herr Christian MAUDERER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: christian.maude...@embedded-brains.de
> >> phone: +49-89-18 94 741 - 18
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Tools on 5 release can't be build with modern LLVM

[Christian MAUDERER]

Am 16.08.21 um 17:12 schrieb Joel Sherrill:

On Mon, Aug 16, 2021 at 10:08 AM Christian MAUDERER
 wrote:


Hello Joel,

Am 16.08.21 um 17:03 schrieb Joel Sherrill:

On Mon, Aug 16, 2021 at 9:49 AM Christian MAUDERER
 wrote:


Hello,

I noted that I can't build the RTEMS 5 toolchain if I have a modern LLVM
installed using the RTEMS source builder. Therefore I would like to
backport the patch 37ad446d9dce3 ([1]) to the 5 branch. Is that OK? If
someone acknowledges it, I would do the following steps without further
review (but of course with testing):

1. Create a ticket for the problem.
2. In rtems-tools: Cherry pick the patch 37ad446d9dce3 to the 5 branch.
3. In rtems-source-builder: Backport the patch 91932d0a0 [2] to the 5
branch (or rather re-create it because it will be a different commit and
a different hash).


I'm ok with this. I remember doing a patch for the opposite direction.
I couldn't
build on an older gcc because it assumed a different language version as
default. gcc 4.8 as on CentOS 7 assumes C++03. Newer versions assume C++11
as the base. Similarly newer gcc's seem to default to C11.


Thanks. I'll wait a bit more before adding the patches in case someone
else want's to object.



Good plan.



I posted a few weeks ago that users should really be careful to always use
-std and consciously pick what they want.


In this case, the version of the standard depends quite a lot on the
LLVM headers. LLVM seems to love using new features.


Then this is probably not the first time we will face this.


Definitively not. It is only a backport of a patch so I had that problem 
already on another system. I only missed to add it to the 5 branch back 
then.


Best regards

Christian



--joel


Best regards

Christian



--joel



Best regards

Christian

[1]
https://git.rtems.org/rtems-tools/commit/?id=37ad446d9dce3438d6d32e1caf56d3fdccdd2ad0

[2]
https://git.rtems.org/rtems-source-builder/commit/?id=91932d0a0c86400366f9c75a62123b6488ff458a
--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-tools 2/2] misc: Add rtems-style command

[Ida Delphine]

Signed-off-by: Ida Delphine 

This command helps to check for style issues or reformat code given a file
or directory. There are 4 flags:
* -c, --check : Checks for style issues
* -r, --reformat : Reformats the code
* -p, --path : Path to file or dir to be checked or reformatted
* -i, --ignore : Files to be ignored when checking or reformatting
* -v, --verbose : Produces a more detailed output.
---
 misc/rtems-style|  16 +
 misc/tools/style.py | 144 
 2 files changed, 160 insertions(+)
 create mode 100644 misc/rtems-style
 create mode 100644 misc/tools/style.py

diff --git a/misc/rtems-style b/misc/rtems-style
new file mode 100644
index 000..5a3e0e8
--- /dev/null
+++ b/misc/rtems-style
@@ -0,0 +1,16 @@
+#! /usr/bin/env python
+
+from __future__ import print_function
+
+import sys, os
+
+base = os.path.dirname(os.path.dirname(os.path.abspath(sys.argv[0])))
+rtems = os.path.join(base, 'share', 'rtems')
+sys.path = sys.path[0:1] + [rtems, base] + sys.path[1:]
+
+try:
+import misc.tools.style
+misc.tools.style.run()
+except ImportError:
+print("Incorrect RTEMS Tools installation", file = sys.stderr)
+sys.exit(1)
\ No newline at end of file
diff --git a/misc/tools/style.py b/misc/tools/style.py
new file mode 100644
index 000..a101146
--- /dev/null
+++ b/misc/tools/style.py
@@ -0,0 +1,144 @@
+import argparse
+import os
+import sys
+import re
+
+from rtemstoolkit import execute
+from rtemstoolkit import git
+
+
+def get_command():
+from rtemstoolkit import check
+
+for version in ['', '8', '9', '10', '11']:
+if check.check_exe(None, 'clang-format' + version):
+command = 'clang-format' + version
+return command
+print("Clang-format not found in your system")
+sys.exit(1)
+
+
+def arguments():
+parser = argparse.ArgumentParser(description="Tool for code formatting and 
style checking \
+for RTEMS")
+parser.add_argument("-c", "--check", dest="check", help="Check for style 
differences and \
+report the number of issues if found", action="store_true")
+parser.add_argument("-r", "--reformat", dest="reformat", help="Reformat 
the file/directory \
+with any style differences found", action="store_true")
+parser.add_argument("-p", "--path", dest="path", help="The path to be 
checked for style issues \
+or reformatted")
+parser.add_argument("--ignore", dest="ignore", help="Ignore files to be 
checked or reformatted")
+parser.add_argument("-v", "--verbose", dest="verbose", help="A more 
detailed outline of the \
+style issues", action='store_true')
+return [parser.parse_args(), parser.print_usage()]
+
+
+
+def get_diff(path, ignore_file=None):
+diff = ""
+ex = execute.capture_execution()
+
+
+def clang_to_git_diff(clang_output, path):
+import os
+import tempfile
+
+fd, tmp_path = tempfile.mkstemp()
+try:
+with os.fdopen(fd, 'w') as tmp:
+
+tmp.write(clang_output)
+repo = git.repo(".")
+return repo.diff(['--no-index', path, tmp_path])
+
+finally:
+os.remove(tmp_path)
+
+if os.path.isfile(path) == True:
+cmd = get_command() + " --style=file " + path
+output_clang = ex.command(command=cmd, shell=True)
+output_clang = output_clang[2]
+diff = clang_to_git_diff(output_clang, path)
+else:
+onlyfiles = [f for f in os.listdir(path)]
+for file in onlyfiles:
+file = os.path.join(path, file)
+
+if ignore_file is not None and file == ignore_file:
+continue
+
+if file.endswith('.c') or file.endswith('.h'):
+cmd = get_command() + " --style=file " + file
+output_clang = ex.command(command=cmd, shell=True)
+output_clang = output_clang[2]
+diff += clang_to_git_diff(output_clang, os.path.join(path, 
file))
+return diff
+
+
+def color_text(string, col, style=1):
+return f"\033[{style};{col};{col}m{string}\033[0;0m"
+
+
+def handle_errors(path, output, verbose=False,):
+if len(output) < 1:
+print("Everything is clean - No style issues")
+else:
+print(color_text("Checking for style differences...", 34, style=3))
+
+out = output.split('\n')
+files = []
+num_diff = 0
+for line in out:
+
+if line.startswith("---"):
+file = str(re.sub('^---\s[ab]', '', line))
+files.append(file)
+
+elif line.startswith('+'):
+num_diff += 1
+if verbose == True:
+print(color_text(line, 34))
+continue
+if verbose == True:
+print(line)
+
+print(color_text("\nFiles affected:", 33))
+
+for file in files:
+

[PATCH rtems-tools 1/2] rt: Add diff method to git.py

[Ida Delphine]

Signed-off-by: Ida Delphine 
---
 rtemstoolkit/git.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/rtemstoolkit/git.py b/rtemstoolkit/git.py
index f65300b..b544a9b 100644
--- a/rtemstoolkit/git.py
+++ b/rtemstoolkit/git.py
@@ -119,6 +119,10 @@ class repo:
 args = [args]
 ec, output = self._run(['clean'] + args, check = True)
 
+def diff(self, args = []):
+ec, output = self._run(['diff'] + args)
+return output
+
 def status(self):
 _status = {}
 if path.exists(self.path):
@@ -229,3 +233,4 @@ if __name__ == '__main__':
 print('remotes:', g.remotes())
 print('email:', g.email())
 print('head:', g.head())
+print('diff:', g.diff())
-- 
2.25.1

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

Re: RTEMS Tools on 5 release can't be build with modern LLVM

[Chris Johns]

Looks good and thank you for sorting this out.

Chris

On 17/8/21 1:17 am, Christian MAUDERER wrote:
> Am 16.08.21 um 17:12 schrieb Joel Sherrill:
>> On Mon, Aug 16, 2021 at 10:08 AM Christian MAUDERER
>>  wrote:
>>>
>>> Hello Joel,
>>>
>>> Am 16.08.21 um 17:03 schrieb Joel Sherrill:
 On Mon, Aug 16, 2021 at 9:49 AM Christian MAUDERER
  wrote:
>
> Hello,
>
> I noted that I can't build the RTEMS 5 toolchain if I have a modern LLVM
> installed using the RTEMS source builder. Therefore I would like to
> backport the patch 37ad446d9dce3 ([1]) to the 5 branch. Is that OK? If
> someone acknowledges it, I would do the following steps without further
> review (but of course with testing):
>
> 1. Create a ticket for the problem.
> 2. In rtems-tools: Cherry pick the patch 37ad446d9dce3 to the 5 branch.
> 3. In rtems-source-builder: Backport the patch 91932d0a0 [2] to the 5
> branch (or rather re-create it because it will be a different commit and
> a different hash).

 I'm ok with this. I remember doing a patch for the opposite direction.
 I couldn't
 build on an older gcc because it assumed a different language version as
 default. gcc 4.8 as on CentOS 7 assumes C++03. Newer versions assume C++11
 as the base. Similarly newer gcc's seem to default to C11.
>>>
>>> Thanks. I'll wait a bit more before adding the patches in case someone
>>> else want's to object.
>>
>>
>> Good plan.
>>

 I posted a few weeks ago that users should really be careful to always use
 -std and consciously pick what they want.
>>>
>>> In this case, the version of the standard depends quite a lot on the
>>> LLVM headers. LLVM seems to love using new features.
>>
>> Then this is probably not the first time we will face this.
> 
> Definitively not. It is only a backport of a patch so I had that problem 
> already
> on another system. I only missed to add it to the 5 branch back then.
> 
> Best regards
> 
> Christian
> 
>>
>> --joel
>>
>>> Best regards
>>>
>>> Christian
>>>

 --joel

>
> Best regards
>
> Christian
>
> [1]
> https://git.rtems.org/rtems-tools/commit/?id=37ad446d9dce3438d6d32e1caf56d3fdccdd2ad0
>
>
> [2]
> https://git.rtems.org/rtems-source-builder/commit/?id=91932d0a0c86400366f9c75a62123b6488ff458a
>
> -- 
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> -- 
>>> 
>>> embedded brains GmbH
>>> Herr Christian MAUDERER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: christian.maude...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 18
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Xilinx Zynq console rx not working

[Chris Johns]

On 16/8/21 11:03 pm, Kinsey Moore wrote:
> On 8/16/2021 04:45, Chris Johns wrote:
>> On 16/8/21 6:38 pm, Chris Johns wrote:
>>> I have taken a closer look at the driver. I am receiving RX interrupts and 
>>> the
>>> characters are being queued however the receive FIFO trigger interrupt is 
>>> only
>>> raised when the FIFO reaches the set threshold of half the FIFO size. I 
>>> suspect
>>> there is an assumption the RX timeout will fire but it is not.
>>>
>> Doing this is questionable 
>>
>> https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222
>>
>> You cannot send a character when touching the attributes. Where is this 
>> hardware
>> bug documented by Xilinx?
> The attributes are done being touched and the TX/RX enable flags are set again
> before sending the character. I was seeing the same behavior on Zynq QEMU even
> with this code removed.
> 
> I couldn't find the hardware bug documented anywhere, but out of the 3 ZynqMP
> boards I have one requires this consistently.

I suggest we use chip maker errata when documenting hardware bugs as it could
turn out to be a bug in a our code.

This smells to me like a set up problem.

>>
>> My application does this ...
>>
>>  if (tcgetattr(fileno(stdout), &term) < 0)
>>  error_message();
>>  cfsetispeed (&term, B115200);
>>  cfsetospeed (&term, B115200);
>>  if (tcsetattr (fileno(stdout), TCSADRAIN, &term) < 0)
>>  error_message();
>>  if (tcgetattr(fileno(stdin), &term) < 0)
>>  error_message();
>>  cfsetispeed (&term, B115200);
>>  cfsetospeed (&term, B115200);
>>  if (tcsetattr (fileno(stdin), TCSADRAIN, &term) < 0)
>>  error_message();
>>
>> and this kills the receive interrupts.
> 
> Does removing the null character kick restore functionality for you in this 
> case?

No it did not.

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

Re: Xilinx Zynq console rx not working

[Chris Johns]

On 17/8/21 8:59 am, Chris Johns wrote:
> On 16/8/21 11:03 pm, Kinsey Moore wrote:
>> On 8/16/2021 04:45, Chris Johns wrote:
>>> On 16/8/21 6:38 pm, Chris Johns wrote:
 I have taken a closer look at the driver. I am receiving RX interrupts and 
 the
 characters are being queued however the receive FIFO trigger interrupt is 
 only
 raised when the FIFO reaches the set threshold of half the FIFO size. I 
 suspect
 there is an assumption the RX timeout will fire but it is not.

>>> Doing this is questionable 
>>>
>>> https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222
>>>
>>> You cannot send a character when touching the attributes. Where is this 
>>> hardware
>>> bug documented by Xilinx?
>> The attributes are done being touched and the TX/RX enable flags are set 
>> again
>> before sending the character. I was seeing the same behavior on Zynq QEMU 
>> even
>> with this code removed.
>>
>> I couldn't find the hardware bug documented anywhere, but out of the 3 ZynqMP
>> boards I have one requires this consistently.
> 
> I suggest we use chip maker errata when documenting hardware bugs as it could
> turn out to be a bug in a our code.
> 
> This smells to me like a set up problem.
> 
>>>
>>> My application does this ...
>>>
>>>  if (tcgetattr(fileno(stdout), &term) < 0)
>>>  error_message();
>>>  cfsetispeed (&term, B115200);
>>>  cfsetospeed (&term, B115200);
>>>  if (tcsetattr (fileno(stdout), TCSADRAIN, &term) < 0)
>>>  error_message();
>>>  if (tcgetattr(fileno(stdin), &term) < 0)
>>>  error_message();
>>>  cfsetispeed (&term, B115200);
>>>  cfsetospeed (&term, B115200);
>>>  if (tcsetattr (fileno(stdin), TCSADRAIN, &term) < 0)
>>>  error_message();
>>>
>>> and this kills the receive interrupts.
>>
>> Does removing the null character kick restore functionality for you in this 
>> case?
> 
> No it did not.

I have read the Zynq-7000 TRM and the Versal ACAP TRM and there is a difference
in the wording around the RX timeout. It seems the RX timeout has evolved in the
Versal to a timer that can interrupt if data has entered the FIFO then no more
within the timeout period and the FIFO trigger level has not been reached. The
timer on the Zynq does not do this. It is something that can handle inter-gap
checks for those serial protocols that require this and there a few of them.
They delimit frames using time domain signalling. To make it work on a zynq-7000
I think you need to receive the first character (rtrig=1) then in the interrupt
handler raise the FIFO trigger level and prime the timer to achieve the Versal
timer functionality. I cannot be bothered doing this.

All we have is a console and that is a pretty basic use case for a UART. As a
result I have lowered the RX trigger level to 1 and disabled the RX timer. I
have also added support to send a FIFO full of data.

The solution is not as optimal as it could be with the Versal UART. If this
becomes a problem and someone wants a lower interrupt count we can look
specialising the driver based on the variant of the UART or implement the timer
protocol I outlined above.

I will create a patch and test on qemu and the Versal then post.

Chris

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