Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

On Sat, 9 Dec 2000, Philipp Rumpf wrote:

> On Thu, Dec 07, 2000 at 04:29:38PM +0100, Rene Malmgren wrote:
> > Philipp Rumpf wrote:
> > > > Unfortunately I don't have the other specs (bus freq, etc.) in front of
> > > > me, but they're static as well (they're probably the standard SH4 ratio).
> > > you can find those out by decoding FQCR.
> > FQCR ?
> 
> FRQCR, sorry.
> 
> > > For DC it's probably not that much of an issue - for embedded systems it
> > > definitely is.
> 
> > Well yes. But the functions we are talking about are forms of auto
> > detect. Its my personal view that If you got an embedded system with
> 
> there's no way to find out whether your fixed value is correct unless you
> calibrated it (other than comparing with an external time source).  As on
> most SH systems the calibration takes less than 20 ms I don't think it's
> a good idea to ever use a constant timer value for those - for the DC it's
> a different issue.
> 

In order to get my DC to boot I've been using a constant (using #if 0
fare) value of timer_freq = 12500000 (I may be off a zero, I don't have
the source handy).  I can verify this works because the serial console
works at 57600, and it uses the peripheral clock to set the baud rate.
While that doesn't qualify as an external source (heh :), I have an idea
how we can work around the DC's broken interval timer (R64CNT).  Read on.

> > 2 Add an constant to the macvector representing the timer_frequency.
> > 
> > mv_time_freq
> > 
> > This variable is either set by a constant or for the generic vector, by
> > auto detect.
> 
> or specifid on the command line (since 2 seconds of delay during boot just
> because you don't know your CPU speed just aren't acceptable) ?
> 

It's a waste of effort to create a command line parameter for the
frequency if it can be autodetected.  I believe it can be even on the DC,
using timers on the AICA RTC.

> > The get_timer_freq functions is modified to fit the new RTC interface.
> > 
> > This way embedded systems can use a predefined value, and hence boot
> > fast. And lazy people can use the auto detect and pay the 1,5 sec
> > penalty. As an bonus we get nice modular code and move one step away
> > from the abyss.
> > 
> > I dont think its a good coding practise to go pass the RTC interface and
> > go directly at the hardware.
> 
> We don't rely on the hardware we access being an RTC at all - all we need
> is to know the rate of change of the hardware register we read (the
> equivalent code on x86 uses the PIT).  Using the RTC interface if you're
> not using RTC functionality doesn't sound like a good idea.
> 

Ok, here we go.  The AICA sound system (where the DC's RTC is located) has
interval timers (based on the code I've seen to drive the sound
processor).  The only problem is, it may be a kludge to activate the timer
depending on how it's activated.  The AICA system can be accessed from two
places, from the SH-4 or the ARM core that powers the AICA.  I don't know
yet if the IT can be activated from the SH-4 side, if so, we're in luck. 
If not, I'm willing to throw in the towel and special case the timer_freq
value for the Dreamcast to a constant value.  But the elegant, DC-portable
solution would be to try to get the AICA IT working, but I have to spend
some time playing with it to see *exactly* how it works.  If anyone
(Marcus, please? :) has info on AICA timers and if they can be used as an
IT from the SH-4 side please let me know.

> > I get a feeling that doing things like that
> > is a good way to introduse hard found bugs.
> 
> And not doing things this way introduces limitations that I think would be
> unacceptable to many people;  it would also, IMHO needlessly, move things
> out of the cpu data structures into the machvec.
>

I agree here.  get_ and set_rtc_time should go into the machvec, but timer
calibration is another beast altogether.  Now that I understand what's
going on, I would hate to kludge up the timer_freq with a constant value,
so I will try an exhaust other possibilities for auto-calibration on the
DC.  In the end, unless time.c is split off it will boil down to a #ifdef
CONFIG_SH_DREAMCAST to distinguish between the two (since there seems to
be no other SH4-based hardware with no onboard RTC).

M. R.