os/arch/arm/src/amebasmart: Enable/disable loguart rx irq according t…

[zhongnuo-tang]

…o driver call

1. Loguart rx irq should be handled properly with enable/disable

[ewoodev]

I would like to check how it is currently going from booting to when LOG UART RX is first enabled in this regard.

if we enable here, do we need to set privious changs of LOG UART enable during boot?

[ewoodev]

The UART porting layer of TizenRT remains unchanged from amebaD.
I think that routing the LOG UART through up_lowgetc and up_lowputc has caused a number of issues.
Could you please explain why this structure was changed and why it is being maintained?

[zhongnuo-tang]

I would like to check how it is currently going from booting to when LOG UART RX is first enabled in this regard.

if we enable here, do we need to set privious changs of LOG UART enable during boot?

Hi @ewoodev, we can remove the enable during boot with this changes.

[zhongnuo-tang]

The UART porting layer of TizenRT remains unchanged from amebaD. I think that routing the LOG UART through up_lowgetc and up_lowputc has caused a number of issues. Could you please explain why this structure was changed and why it is being maintained?

amebaD's loguart is a common UART which can use the same set of structure like UART1.. However, in amebasmart, there is a dedicated UART for LOGUART only, that is why we are using a separate set of flow different from UART0/1/2..

[sunghan-chang]

@zhongnuo-tang Could you let us know some information as below?

1. How did you verify the PR?
2. If we don't apply this, what happen? (I mean what was the issue?)

[zhongnuo-tang]

@zhongnuo-tang Could you let us know some information as below?

1. How did you verify the PR?
2. If we don't apply this, what happen? (I mean what was the issue?)

Hi @sunghan-chang ,
without this PR, the loguart rx irq is not controlled, meaning it will always be enabled even driver calls disabled.. If uart_disablerxint is called, it will still able to trigger loguart rx irq, which should not be the case.

[sunghan-chang]

@ewoodev @gSahitya-samsung @neel-samsung @ritesh55555 This is necessary to review and to verify. Could you check that?

[ewoodev]

Hello @zhongnuo-tang
Could you please verify uart stuck if enter tash during booting??

[zhongnuo-tang]

Hello @zhongnuo-tang Could you please verify uart stuck if enter tash during booting??

verified with loadable_ext DDR, spamming tash during booting, no stuck occurred.

[ewoodev]

Hello @zhongnuo-tang Could you please verify uart stuck if enter tash during booting??

verified with loadable_ext DDR, spamming tash during booting, no stuck occurred.

In my test, the stuck is occurred. Could you please verify psram also?

need to retest

[zhongnuo-tang]

Hello @zhongnuo-tang Could you please verify uart stuck if enter tash during booting??

verified with loadable_ext DDR, spamming tash during booting, no stuck occurred.

In my test, the stuck is occurred. Could you please verify psram also?

Hi @ewoodev,
Using latest tizenrt sha:511aa520a8c9b080331d60522fe85aa7ba1bfca1
Verified with loadable_ext_psarm: spamming tash during booting, no stuck occurred.
Verified with loadable_ext_ddr: spamming tash during booting, no stuck occurred.
Verified with loadable_apps: spamming tash during booting, no stuck occurred.

Maybe you can share with the git sha u tested on? or which defconfig u are using?