At present the sandbox timer uses localtime() which can jump around twice a year when daylight-saving time changes. It would be tricky to make use of gmtime() since we still need to present the time in local time, as seems to be required by U-Boot's RTC interface. The problem can only happen once, so use a loop to detect it and try again. This should be sufficient to detect either a change in the 'second' value, or a daylight-saving change. We can assume that the latter also incorporates a 'second' change, so there is no need to loop more than twice. Signed-off-by: Simon Glass <sjg@chromium.org>
It seems that the time can change in between getting it and reading the offset. Check for this and try again if this happens. Signed-off-by: Simon Glass <sjg@chromium.org>
Since resetting the RTC on sandbox causes it to read the base time from the system, we cannot rely on this being unchanged since it was last read. Allow for a one-second delay. Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Fixes: https://source.denx.de/u-boot/u-boot/-/issues/4 Reported-by: Bin Meng <bmeng.cn@gmail.com> Reported-by: Tom Rini <trini@konsulko.com> Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Simon Glass <sjg@chromium.org>
Use this (newish) macro since it is designed for the purpose of making sure things are non-NULL. Signed-off-by: Simon Glass <sjg@chromium.org>
At present with print_buffer() U-Boot shows four spaces between the hex and ASCII data. Two seems enough and matches print_hex_dump(). Change it. Signed-off-by: Simon Glass <sjg@chromium.org>
The test flags used by driver model are currently not available to other tests. Rather than creating two sets of flags, make these flags generic by changing the DM_ prefix to UT_ and moving them to the test.h header. This will allow adding other test flags without confusion. Signed-off-by: Simon Glass <sjg@chromium.org>
These header file should not be included in other header files. Remove them and add to each individual file. Add test/test.h to test/ui.h since that is a reasonable place. Signed-off-by: Simon Glass <sjg@chromium.org>
Add tests of the "list", "read" and "write" subcommands of the rtc shell command. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Define a few aux registers and check that they can be read/written individually. Also check that one can access the time-keeping registers directly and get the expected results. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
The current set method is broken; a simple test case is to first set the date to something in April, then change the date to 31st May: => date 040412122020.34 Date: 2020-04-04 (Saturday) Time: 12:12:34 => date 053112122020.34 Date: 2020-05-01 (Friday) Time: 12:12:34 or via the amending of the existing rtc_set_get test case similarly: $ ./u-boot -T -v => ut dm rtc_set_get Test: dm_test_rtc_set_get: rtc.c expected: 31/08/2004 18:18:00 actual: 01/08/2004 18:18:00 The problem is that after each register write, sandbox_i2c_rtc_complete_write() gets called and sets the internal time from the current set of registers. However, when we get to writing 31 to mday, the registers are in an inconsistent state (mon is still 4), so the mktime machinery ends up translating April 31st to May 1st. Upon the next register write, the registers are populated by sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets overwritten by a 1. Fix it by writing all registers at once, and for consistency, update the get method to retrieve them all with one "i2c transfer". Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>