From: Tony M. <am...@en...> - 2013-08-05 23:02:26
|
I have a duovero and am unable to use the hardware clock to restore system time. I am using the 3.6 ubuntu build. The kernel was built with support for the I2C rtc corresponding to the twl. I would appreciate any thoughts on getting this clock up and running. Below are the results of my dabbling so far: Thanks, Tony dmesg gives the follwing twl_rtc twl_rtc: Power up reset detected. twl_rtc twl_rtc: Enabling TWL-RTC twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 [cut] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) hwclock then returns the following error: >hwclock hwclock: select() to /dev/rtc0 to wait for clock tick timed out: No such file or directory however, the file exists and the subsequent command __appears__ to work: >hwclock -f/dev/rtc0 -s (or -w) hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success but the clock isn't getting set (either system ->RTC or vice versa) The debug information is: >hwclock -D -f/dev/rtc0 hwclock from util-linux 2.20.1 Using /dev interface to clock. Last drift adjustment done at 1357002501 seconds after 1969 Last calibration done at 1357002501 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success ...synchronization failed finally, it looks like I am seeing no interrupts [output trimmed to just what I thought might be relevant] >cat \proc\interrupts CPU0 CPU1 5: 0 0 twl6040 twl6040_irq_ready 39: 6 0 GIC TWL6030-PIH 69: 31133 0 GIC gp_timer 356: 0 0 twl6030 twl6030_usb 362: 0 0 twl6030 twl6030_usb 363: 0 0 twl6030 rtc0 368: 3 1 twl6030 mmc0 419: 1 0 PRCM hwmod_io IPI0: 0 0 Timer broadcast interrupts Anthony Miller, Ph.D. Entanglement Technologies 42 Adrian Court Burlingame, CA 94010 www.entanglementtech.com |
From: Ash C. <ash...@gm...> - 2013-08-20 01:10:16
|
Hi Anthony, I just did same test on a recent Yocto image for DuoVero and was also unable to set the system clock. Anyone know of a 4430 platform using the system RTC as a reference for debugging this? --Ash On Mon, Aug 5, 2013 at 3:56 PM, Tony Miller <am...@en...> wrote: > I have a duovero and am unable to use the hardware clock to restore system > time. I am using the 3.6 ubuntu build. The kernel was built with support > for the I2C rtc corresponding to the twl. I would appreciate any thoughts > on getting this clock up and running. Below are the results of my dabbling > so far: > > Thanks, > Tony > > > dmesg gives the follwing > > twl_rtc twl_rtc: Power up reset detected. > twl_rtc twl_rtc: Enabling TWL-RTC > twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 > [cut] > twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) > > hwclock then returns the following error: >>hwclock > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: No such > file or directory > > however, the file exists and the subsequent command __appears__ to work: > >>hwclock -f/dev/rtc0 -s (or -w) > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success > > but the clock isn't getting set (either system ->RTC or vice versa) > > The debug information is: >>hwclock -D -f/dev/rtc0 > hwclock from util-linux 2.20.1 > Using /dev interface to clock. > Last drift adjustment done at 1357002501 seconds after 1969 > Last calibration done at 1357002501 seconds after 1969 > Hardware clock is on UTC time > Assuming hardware clock is kept in UTC time. > Waiting for clock tick... > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success > ...synchronization failed > > finally, it looks like I am seeing no interrupts [output trimmed to just > what I thought might be relevant] >>cat \proc\interrupts > CPU0 CPU1 > 5: 0 0 twl6040 twl6040_irq_ready > 39: 6 0 GIC TWL6030-PIH > 69: 31133 0 GIC gp_timer > 356: 0 0 twl6030 twl6030_usb > 362: 0 0 twl6030 twl6030_usb > 363: 0 0 twl6030 rtc0 > 368: 3 1 twl6030 mmc0 > 419: 1 0 PRCM hwmod_io > IPI0: 0 0 Timer broadcast interrupts > > > > > > Anthony Miller, Ph.D. > Entanglement Technologies > 42 Adrian Court > Burlingame, CA 94010 > www.entanglementtech.com > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Ash C. <ash...@gm...> - 2013-08-20 01:26:18
|
FWIW, I just tried with a 3.11 kernel on DuoVero and the RTC worked using the same rootfs. It persisted through a power cycle using a backup battery. On Mon, Aug 19, 2013 at 6:09 PM, Ash Charles <ash...@gm...> wrote: > Hi Anthony, > > I just did same test on a recent Yocto image for DuoVero and was also > unable to set the system clock. > Anyone know of a 4430 platform using the system RTC as a reference for > debugging this? > > --Ash > > On Mon, Aug 5, 2013 at 3:56 PM, Tony Miller > <am...@en...> wrote: >> I have a duovero and am unable to use the hardware clock to restore system >> time. I am using the 3.6 ubuntu build. The kernel was built with support >> for the I2C rtc corresponding to the twl. I would appreciate any thoughts >> on getting this clock up and running. Below are the results of my dabbling >> so far: >> >> Thanks, >> Tony >> >> >> dmesg gives the follwing >> >> twl_rtc twl_rtc: Power up reset detected. >> twl_rtc twl_rtc: Enabling TWL-RTC >> twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 >> [cut] >> twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) >> >> hwclock then returns the following error: >>>hwclock >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out: No such >> file or directory >> >> however, the file exists and the subsequent command __appears__ to work: >> >>>hwclock -f/dev/rtc0 -s (or -w) >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success >> >> but the clock isn't getting set (either system ->RTC or vice versa) >> >> The debug information is: >>>hwclock -D -f/dev/rtc0 >> hwclock from util-linux 2.20.1 >> Using /dev interface to clock. >> Last drift adjustment done at 1357002501 seconds after 1969 >> Last calibration done at 1357002501 seconds after 1969 >> Hardware clock is on UTC time >> Assuming hardware clock is kept in UTC time. >> Waiting for clock tick... >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success >> ...synchronization failed >> >> finally, it looks like I am seeing no interrupts [output trimmed to just >> what I thought might be relevant] >>>cat \proc\interrupts >> CPU0 CPU1 >> 5: 0 0 twl6040 twl6040_irq_ready >> 39: 6 0 GIC TWL6030-PIH >> 69: 31133 0 GIC gp_timer >> 356: 0 0 twl6030 twl6030_usb >> 362: 0 0 twl6030 twl6030_usb >> 363: 0 0 twl6030 rtc0 >> 368: 3 1 twl6030 mmc0 >> 419: 1 0 PRCM hwmod_io >> IPI0: 0 0 Timer broadcast interrupts >> >> >> >> >> >> Anthony Miller, Ph.D. >> Entanglement Technologies >> 42 Adrian Court >> Burlingame, CA 94010 >> www.entanglementtech.com >> >> >> ------------------------------------------------------------------------------ >> Get your SQL database under version control now! >> Version control is standard for application code, but databases havent >> caught up. So what steps can you take to put your SQL databases under >> version control? Why should you start doing it? Read more to find out. >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> |
From: Akram H. <ak...@aq...> - 2013-08-20 05:14:05
|
Not entirely on topic, but I get the same problem on Overo based systems when using the util-linux-ng hwclock, but not when using the busybox one. Never bothered to investigate in more detail, sorry. For reference, the failure always manifested as a read timeout on the clock. On Tue, Aug 20, 2013 at 11:09 AM, Ash Charles <ash...@gm...> wrote: > Hi Anthony, > > I just did same test on a recent Yocto image for DuoVero and was also > unable to set the system clock. > Anyone know of a 4430 platform using the system RTC as a reference for > debugging this? > > --Ash > > On Mon, Aug 5, 2013 at 3:56 PM, Tony Miller > <am...@en...> wrote: > > I have a duovero and am unable to use the hardware clock to restore > system > > time. I am using the 3.6 ubuntu build. The kernel was built with support > > for the I2C rtc corresponding to the twl. I would appreciate any > thoughts > > on getting this clock up and running. Below are the results of my > dabbling > > so far: > > > > Thanks, > > Tony > > > > > > dmesg gives the follwing > > > > twl_rtc twl_rtc: Power up reset detected. > > twl_rtc twl_rtc: Enabling TWL-RTC > > twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 > > [cut] > > twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC > (946684800) > > > > hwclock then returns the following error: > >>hwclock > > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: No such > > file or directory > > > > however, the file exists and the subsequent command __appears__ to work: > > > >>hwclock -f/dev/rtc0 -s (or -w) > > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success > > > > but the clock isn't getting set (either system ->RTC or vice versa) > > > > The debug information is: > >>hwclock -D -f/dev/rtc0 > > hwclock from util-linux 2.20.1 > > Using /dev interface to clock. > > Last drift adjustment done at 1357002501 seconds after 1969 > > Last calibration done at 1357002501 seconds after 1969 > > Hardware clock is on UTC time > > Assuming hardware clock is kept in UTC time. > > Waiting for clock tick... > > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success > > ...synchronization failed > > > > finally, it looks like I am seeing no interrupts [output trimmed to just > > what I thought might be relevant] > >>cat \proc\interrupts > > CPU0 CPU1 > > 5: 0 0 twl6040 twl6040_irq_ready > > 39: 6 0 GIC TWL6030-PIH > > 69: 31133 0 GIC gp_timer > > 356: 0 0 twl6030 twl6030_usb > > 362: 0 0 twl6030 twl6030_usb > > 363: 0 0 twl6030 rtc0 > > 368: 3 1 twl6030 mmc0 > > 419: 1 0 PRCM hwmod_io > > IPI0: 0 0 Timer broadcast interrupts > > > > > > > > > > > > Anthony Miller, Ph.D. > > Entanglement Technologies > > 42 Adrian Court > > Burlingame, CA 94010 > > www.entanglementtech.com > > > > > > > ------------------------------------------------------------------------------ > > Get your SQL database under version control now! > > Version control is standard for application code, but databases havent > > caught up. So what steps can you take to put your SQL databases under > > version control? Why should you start doing it? Read more to find out. > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Tony M. <am...@en...> - 2013-08-20 05:28:46
|
Thanks for the input. Ash, It's good to hear that the new kernel seems to work. What was the previous kernel that you used that failed to function properly? I might dig through the 3.11 to see if I can find what was updated. I've got quite a bit built on the current system and a deadline approaching so moving to a new kernel might have to wait. -Anthony On Aug 19, 2013, at 9:12 PM, Akram Hameed wrote: > Not entirely on topic, but I get the same problem on Overo based systems when using the util-linux-ng hwclock, but not when using the busybox one. > > Never bothered to investigate in more detail, sorry. > > For reference, the failure always manifested as a read timeout on the clock. > > > On Tue, Aug 20, 2013 at 11:09 AM, Ash Charles <ash...@gm...> wrote: > Hi Anthony, > > I just did same test on a recent Yocto image for DuoVero and was also > unable to set the system clock. > Anyone know of a 4430 platform using the system RTC as a reference for > debugging this? > > --Ash > > On Mon, Aug 5, 2013 at 3:56 PM, Tony Miller > <am...@en...> wrote: > > I have a duovero and am unable to use the hardware clock to restore system > > time. I am using the 3.6 ubuntu build. The kernel was built with support > > for the I2C rtc corresponding to the twl. I would appreciate any thoughts > > on getting this clock up and running. Below are the results of my dabbling > > so far: > > > > Thanks, > > Tony > > > > > > dmesg gives the follwing > > > > twl_rtc twl_rtc: Power up reset detected. > > twl_rtc twl_rtc: Enabling TWL-RTC > > twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 > > [cut] > > twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) > > > > hwclock then returns the following error: > >>hwclock > > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: No such > > file or directory > > > > however, the file exists and the subsequent command __appears__ to work: > > > >>hwclock -f/dev/rtc0 -s (or -w) > > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success > > > > but the clock isn't getting set (either system ->RTC or vice versa) > > > > The debug information is: > >>hwclock -D -f/dev/rtc0 > > hwclock from util-linux 2.20.1 > > Using /dev interface to clock. > > Last drift adjustment done at 1357002501 seconds after 1969 > > Last calibration done at 1357002501 seconds after 1969 > > Hardware clock is on UTC time > > Assuming hardware clock is kept in UTC time. > > Waiting for clock tick... > > hwclock: select() to /dev/rtc0 to wait for clock tick timed out: Success > > ...synchronization failed > > > > finally, it looks like I am seeing no interrupts [output trimmed to just > > what I thought might be relevant] > >>cat \proc\interrupts > > CPU0 CPU1 > > 5: 0 0 twl6040 twl6040_irq_ready > > 39: 6 0 GIC TWL6030-PIH > > 69: 31133 0 GIC gp_timer > > 356: 0 0 twl6030 twl6030_usb > > 362: 0 0 twl6030 twl6030_usb > > 363: 0 0 twl6030 rtc0 > > 368: 3 1 twl6030 mmc0 > > 419: 1 0 PRCM hwmod_io > > IPI0: 0 0 Timer broadcast interrupts > > > > > > > > > > > > Anthony Miller, Ph.D. > > Entanglement Technologies > > 42 Adrian Court > > Burlingame, CA 94010 > > www.entanglementtech.com > > > > > > ------------------------------------------------------------------------------ > > Get your SQL database under version control now! > > Version control is standard for application code, but databases havent > > caught up. So what steps can you take to put your SQL databases under > > version control? Why should you start doing it? Read more to find out. > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk_______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Ash C. <ash...@gm...> - 2013-08-25 23:50:47
|
On Mon, Aug 19, 2013 at 10:28 PM, Tony Miller <am...@en...> wrote: > Ash, It's good to hear that the new kernel seems to work. What was the > previous kernel that you used that failed to function properly? A 3.6 kernel. --Ash |
From: Scott E. <sc...@ju...> - 2014-02-06 09:38:36
|
Any solution for this with a 3.6 kernel? -- View this message in context: http://gumstix.8.x6.nabble.com/Duovero-Ubuntu-Hardware-Clock-questions-tp4967645p4968679.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-02-09 16:23:45
|
Here is a backported patch to enable RTC control with gumstix 3.6 kernel https://github.com/scottellis/meta-duovero/blob/master/recipes-kernel/linux/linux-gumstix-3.6/0013-ARM-OMAP4-TWL-mux-sys_drm_msecure-as-output-for-PMIC.patch -- View this message in context: http://gumstix.8.x6.nabble.com/Duovero-Ubuntu-Hardware-Clock-questions-tp4967645p4968692.html Sent from the Gumstix mailing list archive at Nabble.com. |