On 5/23/2011 12:33 PM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message<4ddaa705.1040...@comcast.net> you wrote:
My apologies for being a little (perhaps more than a little)
dense. As they say, "after further review", I think the key aspect of
the PPC timer system is that it uses the decrementer register to
generate an interrupt at a 1 KHz rate. What I have been attempting here
is to produce a timer system that does not use interrupts at all. This
is a fundamental design question. Naturally, systems that can generate
No, it is not. It is an implementation detail which is irrelevant to
almost all users of U-Boot.
Or do you actucally care if your UART driver uses polling or
interrupts?
Hi All,
I might care a lot if I expect typeahead to work, or if I am
sending a command script via a terminal emulator and I don't want to
loose characters while u-boot is off executing a command. One might
(correctly) say that that is too much to expect of a boot loader, and
define polling as "good enough", which I advocate, or not. YMMV.
an interrupt at a 1 KHz rate (or at any (reasonable) higher rate for
that matter) using the decrementer register can produce a 1 ms
resolution software counter that updates "by magic". If my understanding
of this PPC code is incorrect, somebody please stop me before I make a
further fool of myself! Is it then a design requirement that the timer
system use interrupts? Is that what is meant by using the PPC system as
No, it is not a design requirement. It is just one possible
implementation. Any other method that achieves the same or similar
results is as good. As noted before, on PowerPC we could have
probably avoided this and just base all timer services on the timebase
register.
[The reason for this dual implementation is historical. When I wrote
this code, I did not know if we would ever need any fancy timer-
controlled callbacks or similar. And I needed to implement interrupt
handling for a few other purposes (for example for use in standalone
applications; this was an explicit requirement at that time). And the
timer was something that made a good and simple example.]
a model? If so, is it possible/reasonable on all the u-boots that are
out there to generate and process timer interrupts at some (hopefully
but not necessarily) programmable rate?
I consider this an implementation detail. On all architectures it
should be possible to use interrupts, so if the hardware supports a
timer that can generate interrupts it should be possible to use this.
But it is not a requirement that all implementations must work like
Ok, this is very nice to understand. I will attempt to summarize
what I think this email and the previous one means. First, the required
properties of the get_timer routine.
1. It must have 1 millisecond resolution and accuracy (more or less).
For instance, the old NIOS timer that incremented the timestamp by
10 every 10 milliseconds in response to an interrupt is not compliant.
2. The get_timer routine must have full period accuracy without any
assumptions regarding what is going on in u-boot. This period is
4294967 seconds or so.
I then suggest that the minimum system requirements to support the
u-boot timer are as follows:
* Either there exists a free-running timer whose period is > 4294967
and whose resolution is 1 millisecond or better. This probably
includes all 64 bit timestamp counters.
* Or there exists a method of generating interrupts at a known rate
of 1 millisecond or faster. This is a superset of the current PPC
method.
* Or there exists a method of generating interrupts at a known fixed
rate slower than once a millisecond AND there exists a readable
free running counter whose period is longer or the same as the
interrupt rate AND whose resolution is at least 1 ms. This would
include N bit counters that generate an interrupt when they
overflow, or some long timestamp counter with another, possibly
unrelated interrupt generating methodology that is faster than the
counter overflow interval.
There are many systems that are able to do all three cases, or two of
three, so they have a choice on how to implement get_timer(). I claim
that these are sufficient conditions. I also claim they are necessary.
If a hardware system does not meet these criteria, I claim it can't meet
the get_timer requirements. Do such systems exist today that use u-boot?
I think probably so, but maybe they are corner cases. Note that you
cannot extend a 32 bit counter to a 64 bit counter reliably without
using interrupts to do so when get_timer is not being called.
Systems using the first approach above have essentially all their logic
in the get_timer routine, but MUST use at least some 64 bit arithmetic
(actually 33 bit arithmetic if you don't count shifts) to do so because
the delta time between calls can be very large. The routine is not too
complex to write however.
Systems using the second approach have a real simple get_timer routine
but a more complex interrupt routine. The interrupt routine is still
quite simple, it being either a single 32 bit add or 2 32 bit adds (if
the update rate is a fraction of a ms).
Systems using the last approach are the most complex. They need a
routine like the get_timer routine I provided yesterday that can be
called in the interrupt routine to kick the timer up to present day,
plus a version of the routine called by the user that disables
interrupts, updates the timestamp, and re-enables interrupts. Are there
any such systems out there? Probably, but I will wait for someone to
identify them before I dive in! Certainly the other two methods are much
easier to create.
Does that sound right?
Best Regards,
Bill Campbell
this.
Best regards,
Wolfgang Denk
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
