Re: [linuxsh-dev] SH-4 RTC

[Stuart M. <Stu...@st...>]

Niibe-san

Yes, I saw the same behaviour, both on the SH7750 and the ST40STB1.
In fact as part of the changes I checked in for the STB1 boards was
a 'fix' to rtc.c to handle this. At the moment it is unconditional, but
if it doesn't occur on SH3 parts, then it sounds like we need to make it
conditional as you suggest.

What's the difference between the SH7750 and SH7750S? That's a new one
on me!

Stuart


On Feb 18, 12:22pm, gn...@m1... wrote:
> Subject: [linuxsh-dev] SH-4 RTC
> 
> While implementing RTC routine in SH IPL+g:
> --------------------------
> static unsigned long get_tick_1 (void)
> {
>   unsigned int cnt128, sec, min, hour;
> 
>   while (1)
>     {
>       p4_outb (RCR1, 0);  /* Clear CF-bit */
> 
>       cnt128 = (p4_inb (R64CNT) ^ RTC_BIT_CHANGE);
>       sec = p4_inb (RSECCNT);
>       min = p4_inb (RMINCNT);
>       hour = p4_inb (RHRCNT);
> 
>       if ((p4_inb (RCR1) & RCR1_CF) == 0)
>       break;
>     }
> 
>   BCD_TO_BIN(sec);
>   BCD_TO_BIN(min);
>   BCD_TO_BIN(hour);
> 
>   return cnt128 + 128*(sec+60*(min+60*hour));
> }
> --------------------------
> 
> I think I've found a hardware bug(? or feature) of SH-4.  I need to
> set RTC_BIT_CHANGE as 0x40, to get the straight value of the tick.
> Without this, the tick value goes backward(!) sometime.
> 
> I see no problem for SH7709A, so I set RTC_BIT_CHANGE as 0 on SH7709A.
> 
> If it's true, we need to fix our RTC related code.  Could you please
> check your CPU?  How about chips by ST?
> 
> I've checked my CqREEK SH-4 and SolutionEngine SH7750 and
> SolutionEngine SH7750S.  Both of SH7750 and SH7750S has this issue.
> -- 
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>-- End of excerpt from gn...@m1...