[U-Boot] [PATCH] sandbox: Add timer simulation
Making sleep command work
Signed-off-by: Matthias Weisser weisserm@arcor.de --- arch/sandbox/config.mk | 1 + arch/sandbox/cpu/cpu.c | 2 +- arch/sandbox/cpu/os.c | 15 +++++++++++++++ board/sandbox/sandbox/sandbox.c | 4 +++- include/os.h | 14 ++++++++++++++ 5 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk index ab33026..2ec1bb7 100644 --- a/arch/sandbox/config.mk +++ b/arch/sandbox/config.mk @@ -18,3 +18,4 @@ # MA 02111-1307 USA
PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ +PLATFORM_LIBS += -lrt diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c index c7bf8a9..a15d3c2 100644 --- a/arch/sandbox/cpu/cpu.c +++ b/arch/sandbox/cpu/cpu.c @@ -34,7 +34,7 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /* delay x useconds */ void __udelay(unsigned long usec) { - /* Ignore this for now */ + os_usleep(usec); }
unsigned long timer_get_us(void) diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index b7c3bf5..d3357db 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -23,6 +23,7 @@ #include <stdlib.h> #include <termios.h> #include <unistd.h> +#include <time.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> @@ -94,3 +95,17 @@ void *os_malloc(size_t length) return mmap(NULL, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); } + +void os_usleep(unsigned long usec) +{ + usleep(usec); +} + +u64 os_get_nsec(void) +{ + struct timespec tp; + + clock_gettime(CLOCK_MONOTONIC, &tp); + + return tp.tv_sec * 1000000000ULL + tp.tv_nsec; +} diff --git a/board/sandbox/sandbox/sandbox.c b/board/sandbox/sandbox/sandbox.c index 95a5045..f376c74 100644 --- a/board/sandbox/sandbox/sandbox.c +++ b/board/sandbox/sandbox/sandbox.c @@ -21,6 +21,8 @@
#include <common.h>
+#include <os.h> + /* * Pointer to initial global data area * @@ -34,7 +36,7 @@ void flush_cache(unsigned long start, unsigned long size)
ulong get_timer(ulong base) { - return 0; + return (os_get_nsec() / 1000000) - base; }
int timer_init(void) diff --git a/include/os.h b/include/os.h index fd4120c..f3af4f0 100644 --- a/include/os.h +++ b/include/os.h @@ -84,3 +84,17 @@ void os_tty_raw(int fd); * \return Pointer to length bytes or NULL on error */ void *os_malloc(size_t length); + +/** + * Access to the usleep function of the os + * + * \param usec Time to sleep in micro seconds + */ +void os_usleep(unsigned long usec); + +/** + * Gets a monotonic increasing number of nano seconds from the OS + * + * \return A monotonic increasing time scaled in nano seconds + */ +u64 os_get_nsec(void);
On Monday 28 November 2011 16:40:29 Matthias Weisser wrote:
Making sleep command work
i like the idea, but using clock_xxx funcs makes me sad (generally requires a "newerish" glibc and -lrt). my only alternative proposal is to use usec's with gettimeofday ... maybe that's good enough ? although we'll probably need to add nsec support eventually anyways for the newer timer code ...
feel like wiring up timer_get_us() too ? -mike
Am 28.11.2011 23:57, schrieb Mike Frysinger:
On Monday 28 November 2011 16:40:29 Matthias Weisser wrote:
Making sleep command work
i like the idea, but using clock_xxx funcs makes me sad (generally requires a "newerish" glibc and -lrt). my only alternative proposal is to use usec's with gettimeofday ... maybe that's good enough ? although we'll probably need to add nsec support eventually anyways for the newer timer code ...
I would like to stay with clock_gettime(CLOCK_MONOTONIC, ...) as the value isn't subjected to change when wall time is changed. Still there are chances to get wrong (non monotonic) values when NTP adjusts frequencies. Maybe some ifdef magic can be used to even use CLOCK_MONOTONIC_RAW if it is available and fall back to gettimeofday in case of older systems. The only thing would be then -lrt on the linker command line which has to be sorted out somehow.
feel like wiring up timer_get_us() too ?
Will do in a v2.
Matthias
On Tuesday 29 November 2011 04:35:06 Matthias Weißer wrote:
Am 28.11.2011 23:57, schrieb Mike Frysinger:
On Monday 28 November 2011 16:40:29 Matthias Weisser wrote:
Making sleep command work
i like the idea, but using clock_xxx funcs makes me sad (generally requires a "newerish" glibc and -lrt). my only alternative proposal is to use usec's with gettimeofday ... maybe that's good enough ? although we'll probably need to add nsec support eventually anyways for the newer timer code ...
I would like to stay with clock_gettime(CLOCK_MONOTONIC, ...) as the value isn't subjected to change when wall time is changed. Still there are chances to get wrong (non monotonic) values when NTP adjusts frequencies. Maybe some ifdef magic can be used to even use CLOCK_MONOTONIC_RAW if it is available and fall back to gettimeofday in case of older systems. The only thing would be then -lrt on the linker command line which has to be sorted out somehow.
i think atm, we're focusing on sandbox working on Linux/glibc hosts. we're not *too* worried about portability atm. we can worry about that once sandbox is more than just a PoC toy :). -mike
Making sleep command work
Signed-off-by: Matthias Weisser weisserm@arcor.de --- Changes in v2: - Added check for existence and working of clock_gettime - Added implementation of timer_get_us - Fixed a build error
arch/sandbox/config.mk | 1 + arch/sandbox/cpu/cpu.c | 4 ++-- arch/sandbox/cpu/os.c | 27 +++++++++++++++++++++++++++ board/sandbox/sandbox/sandbox.c | 4 +++- include/os.h | 14 ++++++++++++++ 5 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk index ab33026..2ec1bb7 100644 --- a/arch/sandbox/config.mk +++ b/arch/sandbox/config.mk @@ -18,3 +18,4 @@ # MA 02111-1307 USA
PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ +PLATFORM_LIBS += -lrt diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c index c7bf8a9..d7684d3 100644 --- a/arch/sandbox/cpu/cpu.c +++ b/arch/sandbox/cpu/cpu.c @@ -34,12 +34,12 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /* delay x useconds */ void __udelay(unsigned long usec) { - /* Ignore this for now */ + os_usleep(usec); }
unsigned long timer_get_us(void) { - return 0; + return os_get_nsec() / 1000; }
int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images) diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index b7c3bf5..6d55b5c 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -23,9 +23,12 @@ #include <stdlib.h> #include <termios.h> #include <unistd.h> +#include <time.h> +#include <errno.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> +#include <linux/types.h>
#include <os.h>
@@ -94,3 +97,27 @@ void *os_malloc(size_t length) return mmap(NULL, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); } + +void os_usleep(unsigned long usec) +{ + usleep(usec); +} + +u64 os_get_nsec(void) +{ +#if defined(CLOCK_MONOTONIC) && defined(_POSIX_MONOTONIC_CLOCK) + struct timespec tp; + if (EINVAL == clock_gettime(CLOCK_MONOTONIC, &tp)) { + struct timeval tv; + + gettimeofday(&tv, NULL); + tp.tv_sec = tv.tv_sec; + tp.tv_nsec = tv.tv_usec * 1000; + } + return tp.tv_sec * 1000000000ULL + tp.tv_nsec; +#else + struct timeval tv; + gettimeofday(&tv, NULL); + return tv.tv_sec * 1000000000ULL + tv.tv_usec * 1000; +#endif +} diff --git a/board/sandbox/sandbox/sandbox.c b/board/sandbox/sandbox/sandbox.c index 95a5045..f376c74 100644 --- a/board/sandbox/sandbox/sandbox.c +++ b/board/sandbox/sandbox/sandbox.c @@ -21,6 +21,8 @@
#include <common.h>
+#include <os.h> + /* * Pointer to initial global data area * @@ -34,7 +36,7 @@ void flush_cache(unsigned long start, unsigned long size)
ulong get_timer(ulong base) { - return 0; + return (os_get_nsec() / 1000000) - base; }
int timer_init(void) diff --git a/include/os.h b/include/os.h index fd4120c..f3af4f0 100644 --- a/include/os.h +++ b/include/os.h @@ -84,3 +84,17 @@ void os_tty_raw(int fd); * \return Pointer to length bytes or NULL on error */ void *os_malloc(size_t length); + +/** + * Access to the usleep function of the os + * + * \param usec Time to sleep in micro seconds + */ +void os_usleep(unsigned long usec); + +/** + * Gets a monotonic increasing number of nano seconds from the OS + * + * \return A monotonic increasing time scaled in nano seconds + */ +u64 os_get_nsec(void);
Acked-by: Mike Frysinger vapier@gentoo.org
Simon: did we decide to start a dedicated sandbox repo ? -mike
+Wolfgang
Hi Mike,
On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger vapier@gentoo.org wrote:
Acked-by: Mike Frysinger vapier@gentoo.org
Simon: did we decide to start a dedicated sandbox repo ? -mike
We didn't decide - it was an idea and I suppose given Wolfgang's email about workload and the early and patch-needy state of sandbox I suspect we should do this. The other option is perhaps for an existing maintainer to collect things to push into staging (if there is such a maintainer interested in sandbox).
Wolfgang, do you want a sandbox repo?
Regards, Simon
On Tuesday 29 November 2011 11:55:17 Simon Glass wrote:
On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote:
Simon: did we decide to start a dedicated sandbox repo ?
We didn't decide - it was an idea and I suppose given Wolfgang's email about workload and the early and patch-needy state of sandbox I suspect we should do this. The other option is perhaps for an existing maintainer to collect things to push into staging (if there is such a maintainer interested in sandbox).
Wolfgang, do you want a sandbox repo?
well, one of these two things is going to happen :). i'd prefer a dedicated repo, otherwise i'll start using a branch for it in an existing repo. -mike
Hi Mike,
On Tue, Nov 29, 2011 at 10:40 AM, Mike Frysinger vapier@gentoo.org wrote:
On Tuesday 29 November 2011 11:55:17 Simon Glass wrote:
On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote:
Simon: did we decide to start a dedicated sandbox repo ?
We didn't decide - it was an idea and I suppose given Wolfgang's email about workload and the early and patch-needy state of sandbox I suspect we should do this. The other option is perhaps for an existing maintainer to collect things to push into staging (if there is such a maintainer interested in sandbox).
Wolfgang, do you want a sandbox repo?
well, one of these two things is going to happen :). i'd prefer a dedicated repo, otherwise i'll start using a branch for it in an existing repo. -mike
OK - who can maintain it? Preferably not someone who will be doing a lot of sandbox patches I suppose so that rules me out :-)
Regards, Simon
On Tuesday 29 November 2011 15:04:04 Simon Glass wrote:
On Tue, Nov 29, 2011 at 10:40 AM, Mike Frysinger wrote:
On Tuesday 29 November 2011 11:55:17 Simon Glass wrote:
On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote:
Simon: did we decide to start a dedicated sandbox repo ?
We didn't decide - it was an idea and I suppose given Wolfgang's email about workload and the early and patch-needy state of sandbox I suspect we should do this. The other option is perhaps for an existing maintainer to collect things to push into staging (if there is such a maintainer interested in sandbox).
Wolfgang, do you want a sandbox repo?
well, one of these two things is going to happen :). i'd prefer a dedicated repo, otherwise i'll start using a branch for it in an existing repo.
OK - who can maintain it? Preferably not someone who will be doing a lot of sandbox patches I suppose so that rules me out :-)
you or me or both. i'm fine with any of those three options. -mike
Hi Mike,
On Tue, Nov 29, 2011 at 1:41 PM, Mike Frysinger vapier@gentoo.org wrote:
On Tuesday 29 November 2011 15:04:04 Simon Glass wrote:
On Tue, Nov 29, 2011 at 10:40 AM, Mike Frysinger wrote:
On Tuesday 29 November 2011 11:55:17 Simon Glass wrote:
On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote:
Simon: did we decide to start a dedicated sandbox repo ?
We didn't decide - it was an idea and I suppose given Wolfgang's email about workload and the early and patch-needy state of sandbox I suspect we should do this. The other option is perhaps for an existing maintainer to collect things to push into staging (if there is such a maintainer interested in sandbox).
Wolfgang, do you want a sandbox repo?
well, one of these two things is going to happen :). i'd prefer a dedicated repo, otherwise i'll start using a branch for it in an existing repo.
OK - who can maintain it? Preferably not someone who will be doing a lot of sandbox patches I suppose so that rules me out :-)
you or me or both. i'm fine with any of those three options. -mike
I vote for you as you already do this for blackfin and I might get back into this and break fourth with a huge bunch of sandbox patches at any moment. But I can help if you want to have a holiday sometime.
Regards, Simon
On Tuesday 29 November 2011 16:58:38 Simon Glass wrote:
On Tue, Nov 29, 2011 at 1:41 PM, Mike Frysinger wrote:
On Tuesday 29 November 2011 15:04:04 Simon Glass wrote:
On Tue, Nov 29, 2011 at 10:40 AM, Mike Frysinger wrote:
On Tuesday 29 November 2011 11:55:17 Simon Glass wrote:
On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote:
Simon: did we decide to start a dedicated sandbox repo ?
We didn't decide - it was an idea and I suppose given Wolfgang's email about workload and the early and patch-needy state of sandbox I suspect we should do this. The other option is perhaps for an existing maintainer to collect things to push into staging (if there is such a maintainer interested in sandbox).
Wolfgang, do you want a sandbox repo?
well, one of these two things is going to happen :). i'd prefer a dedicated repo, otherwise i'll start using a branch for it in an existing repo.
OK - who can maintain it? Preferably not someone who will be doing a lot of sandbox patches I suppose so that rules me out :-)
you or me or both. i'm fine with any of those three options.
I vote for you as you already do this for blackfin and I might get back into this and break fourth with a huge bunch of sandbox patches at any moment. But I can help if you want to have a holiday sometime.
until we hear back from Wolfgang, i've started a sandbox branch and merged the patches i think should go in now
if there's other pending ones, please highlight them -mike
participants (4)
-
Matthias Weisser -
Matthias Weißer -
Mike Frysinger -
Simon Glass