API Rewrite
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 16 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 16 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Quoted 2 lines · Wolfgang Denk
Dear Graeme Russ,
[snip]
Quoted 14 lines
One thing I always wanted to do in the previous discussion was to check what other projects (like Linux, barebox, etc.) are doing in this area. I think it is worth reading the Linux
Documentation/timers/highres.txtdocument, especially the sections about John Stultz's Generic Time Of Day (GTOD) framework, please the documents linked there (i. e. the OLS slides [the link inDocumentation/timers/highres.txtis stale; use
http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/ols2006-hrtimers.pdf
instead] and the paper "We Are Not Getting Any Younger: A New Approach to Time and Timers" by J. Stultz et al. in
http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf p. 219ff).Having this still in mind, I took a look across the fence to what barebox is doing. Guess what? From "
common/clock.c":
Quoted 6 lines
*
clock.c- generic clocksource implementation
*
* This file contains the clocksource implementation from the Linux
* kernel originally by John StultzOK. Message received.
Yes, and barebox is also pulling in slabs of other Linux code such as driver framework etc. I think you will find barebox will ultimately have a very large code-base and binary image because of that. I think that U-Boot and barebox are heading in two different directions (and so they should, what would be the point otherwise) - barebox will become modular but larger, U-Boot will continue to be homogeneous and small.
Quoted 2 lines
What I'm asking myself (and now you) is: Should we really re-invent the wheel again?
OK, I've now had a brief look and I have the following comments:
- Looking at the low-level framework described in ols2006-hrtimers.pdf (Linux API), we are looking at implementing the same thing - An architecture specific free running, high speed, high resolution, high accuracy hardware counter/timer and a low speed interrupt which translates the hardware counter/timer to a common API. In this respect, we are not re-inventing that wheel at all
- The rest of the Linux API is like hitting a thumb-tack with a sledgehammer - Timer Queues, NTP, Callbacks, Scheduling etc, etc, etc. We only want to do two things:
1. Monitor timeouts
2. Calculate code execution time (and even then, not everyone all the time)
- The Linux API is nanosecond resolution. We are hard pressed to get the average hardware to support microsecond resolution
- The Linux API includes usage of 'clock events' - These are timer interrupts driven by programmable hardware and relieve the stress on the timer scheduler keeping track of every single timer - Overkill for a boot loader
- The Linux API includes 'Time of Day' (Wall Time) - Again, I don't think we really need this in a boot loader (we have an RTC API we can use if we want to get the current Date and Time).
So, all we need is a fixed resolution free running timer we can use to do simple (one at a time) timing operations. No callbacks, no scheduling, to 'Wall Time', no 'Clock Events', no NTP etc. The Linux API is 'Too Big'
I don't think we are re-inventing the wheel with our underlying concept - Use a hardware counter to handle the accuracy and resolution and use a less frequent interrupt to map the hardware implementation to a common software API. In U-Boot, the interrupt can be as simple as the actual call into the API, but where the hardware timer does not have sufficient resolution (a 32-bit nanosecond timer of 16-bit millisecond timer for example) an additional hardware interrupt will be required.
I personally think we are headed in the right direction 'for U-Boot' - small, tight, elegant, and fit-for-purpose
Regards,
Graeme