AM5716: AM5716 COUNTER_REALTIME Overflow

Hi Rei,

I will come back to you on the above questions in couple of days.

Best Regards,
Keerthy

Hi Keerthy,

Thank you for your reply. I'll be waiting for you.

Regards,

Rei

Hi Rei,

I have reached out to experts & i am yet to receive any response on this. I will get back
to you as soon as i get an answer.

Best Regards,
Keerthy

Hi Keerthy,

Many thanks. We are looking forward to your answer.

Regards,

Rei

Hi Keerthy,

Do you have any update? Customer's product is used in the field, we are looking for solutions.

Please reply as soon as possible.

Regards,

Rei

Hi Rei,

I finally found some patches that are on 4.9 based kernel. Please try porting them to your specific kernel.
Basically solution is to switch Linux form ARCH timers to GP Timers.

Hi Keerthy,

Thank you for the information. I told it to customers. 

Regards,

Rei

Hi Keerthy,

Customers are trying to switch the Linux timer. Before and after swtiching, we want to confirm how it works, however it's difficult to wait 388days for the reset occur.

How do we reproduce the reset? (For example, overwrite timer count, etc.)

Regards,

Rei

Hi Rei,

GPTimers should not be taking that long to roll over. There is no test readily available
from our side as long as the timers are configured fine and can add debug prints in the
local_timer_set_next_event function introduced by the patch set.

Regards,
Keerthy

Hi Keerthy-san,

Thank you for your reply.

Because this is the critical issue for us, so we want to investigate further details.

Could you confirm the following three questions?

1.Why does the COUNTER_REALTIME(40-bit coarse counter) overflow cause the reset (the source of reset seems the watchdog reset)?

  We want to know the influence of the overflow and what module or software are affected by the overflow.

  In the comment of patch from you (0003 and 0004), "ARM architected timer has a saturation issue at 388days in DRA7 SoCs" is described.

  We think you know the detail of this issue, so could you explain the detail of this issue?

2.We could understand there is no test readily available; however, this is the critical issue for us.

  Could you confirm another rapid way except for "debug prints in the local_timer_set_next_event"?

3.What is the memory mapped address for CNTControlBase memory map?

  We found the register for counter in the "Arm Architecture Reference Manual Armv7-A and Armv7-R edition" document.

  We want to control the register described in Table D5-1 CNTControlBase memory map; however, we couldn't find the register in TRM of AM5716.

Best Regards,

Rei

Hi Keerthy-san,

Customer's products equipped with AM57x are having problem in the field. We must respond in a hurry. Sorry for the rush, please reply.

Regards,

Rei

Hi Keerthy-san,

Do you have any update on this issue?

Regards,

Rei

Hi Rei-San,

No i was out for sometime. To answer question 1:
After the timer expires:

Hi Keerthy-san,

Thank you for your reply. I will wait for your answers.

Best Regards,

Rei

Hi Keerthy-san,

Do you have any update?

Regards,

Rei

Hello Rei-San,

I have reached out to the people who might know. I am yet to receive a response. As you can see that
patches were done on pretty old kernel & hence it is taking time to get more information.

Best Regards
Keerthy

Hello Rei-San,

I haven't been able to find a solution yet. We have reached out to other internal teams to get some additional help. But this process could take longer and therefore I suggest you to look for alternate solutions and update this thread if you have been able to make progress. I will also keep you posted as soon as we have additional information.

Best Regards,
Keerthy

Hi Keerthy-san,

Thank you for checking. Customers are continuing to investigate it themselves because their products have this problem, these information would be very helpful.

I will tell the customers about the current status. I'm sorry for asking so much of you, but we would appreciate it if you could continue to cooperate.

Also, if you have any progress on this question, please let me know.  "3.What is the memory mapped address for CNTControlBase memory map?"

Best regards,

Rei

Hi Keerthy-san,

It's been two weeks, do you have any updates?

Regards,

Rei

rei said:

Also, if you have any progress on this question, please let me know.  "3.What is the memory mapped address for CNTControlBase memory map?"

Hello Rei-san,

https://developer.arm.com/architectures/learn-the-architecture/generic-timer/single-page

These addresses are not memory mapped and need to written via ARM coprocessor.
The above is the ARM documentation link. Hope that helps you.

Best Regards,
Keerthy

Hi Keerthy-san,

Customer has checked the ARM document. I'm terribly sorry many times, but the customers have questions.

Question 1:

We can control the Generic Timer through the coprocessor, however can't disable the System Counter, and it is not memory-mapped. We can't control system counter. Is this understanding correct?

Question 2:

Issue: 40bit Coarse Counter Wrap(Overflow), so System Counter stops. Does it affect features other than ARM's Generic Timer?

Question 3:

We want to reproduce this issue. We need workaround, but we also want to know the extent of the effect of this issue. Would you tell me how to force wrap(overflow)?

I'm sorry for having to rely on you all the time. This issue is occurring in the market, so customers are in trouble. I'd appreciate it if you'd cooperate with us.

Best regards,

Rei

Hello Rei-san,

We will respond to you by tomorrow on this.

Best Regards,
Keerthy

Hello Rei-San,

https://e2e.ti.com/support/processors/f/791/p/952464/3529968#3529968

There is an answer on how we can check if the solution indeed worked.

Best Regards,
Keerthy

Hi Keerthy-san,

Thank you for your reply. I will tell this to customers.

Do you have any information about this question?

Question 2:

Issue: 40bit Coarse Counter Wrap(Overflow), so System Counter stop. Does it affect features other than ARM's Generic Timer?

Regards,

Rei