diff for duplicates of <3F004440.6000301@peak.uklinux.net> diff --git a/a/1.txt b/N1/1.txt index 3676530..01ed833 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,51 +1,47 @@ - Wolfgang Denk wrote: [ snip ] ->>Ok, well I've successfully compiled with CONFIG_HARD_I2C and have ->>communicated with my clock, so that is good. Next up is transferring the +>>Ok, well I've successfully compiled with CONFIG_HARD_I2C and have +>>communicated with my clock, so that is good. Next up is transferring the >>date in u-boot to linux, but I'm sure that will be documented somewhere. ->> +>> >> > >You don't "transfer" the daye. Linux will pick it up itself (which >requires an RTC driver and eventually some modifications). > -Let me check that I understand: As far as I can see the u-boot realtime -clock drivers just allow you to set and read the time from the u-boot -command line; a useful utility. If linux is to read the time from the -realtime clock it must have a realtime clock driver of its own; there's -no way that u-boot can pass the time to linux at boot time? (Of course, -this would be fraught with difficulties, because depending on how fast -your cpu boots linux, a different amount of time would elapse before +Let me check that I understand: As far as I can see the u-boot realtime +clock drivers just allow you to set and read the time from the u-boot +command line; a useful utility. If linux is to read the time from the +realtime clock it must have a realtime clock driver of its own; there's +no way that u-boot can pass the time to linux at boot time? (Of course, +this would be fraught with difficulties, because depending on how fast +your cpu boots linux, a different amount of time would elapse before linux could actually do something with the passed date stamp). -So, next up for me is to write a linux driver for the ds1307. I was -actually in the middle of that before getting sidetracked by the u-boot -rtc code. However, the u-boot code has enabled me to hardware debug my -realtime clock circuit, so that was very useful. Has anyone written a -linux driver for the ds1307 or similar? (I'm cross posting to the +So, next up for me is to write a linux driver for the ds1307. I was +actually in the middle of that before getting sidetracked by the u-boot +rtc code. However, the u-boot code has enabled me to hardware debug my +realtime clock circuit, so that was very useful. Has anyone written a +linux driver for the ds1307 or similar? (I'm cross posting to the linuxppc-embedded list to ask this question). ->>As for CONFIG_SOFT_I2C; Attached (really this time) is a diff between ->>the original u-boot-0.4.0/include/configs/TQM823L.h and the one that I ->>have altered. The compile of soft_i2c.c fails with the following error +>>As for CONFIG_SOFT_I2C; Attached (really this time) is a diff between +>>the original u-boot-0.4.0/include/configs/TQM823L.h and the one that I +>>have altered. The compile of soft_i2c.c fails with the following error >>messages: ->> +>> >> > >That's because you did not define the required macros (see for >example the configuration in lwmon.h). +> > -> -Right, so it's not the case that you just #define CONFIG_SOFT_I2C; you -have to correctly define the macros. I shall do some work on the readme +Right, so it's not the case that you just #define CONFIG_SOFT_I2C; you +have to correctly define the macros. I shall do some work on the readme and post a diff later on. Thanks for the pointers. best, Seb - - -** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ diff --git a/a/content_digest b/N1/content_digest index 9ac9b09..24a051e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,62 +1,56 @@ "ref\020030630133530.CC405C592A@atlas.denx.de\0" "From\0Seb James <seb@peak.uklinux.net>\0" - "Subject\0Re: [U-Boot-Users] soft_i2c and ds1307 with tqm823l\0" + "Subject\0[U-Boot-Users] soft_i2c and ds1307 with tqm823l\0" "Date\0Mon, 30 Jun 2003 15:08:00 +0100\0" - "To\0Wolfgang Denk <wd@denx.de>\0" - "Cc\0u-boot-users@lists.sourceforge.net" - " linuxppc-embedded@lists.linuxppc.org\0" + "To\0u-boot@lists.denx.de\0" "\00:1\0" "b\0" - "\n" "Wolfgang Denk wrote:\n" "[ snip ]\n" "\n" - ">>Ok, well I've successfully compiled with CONFIG_HARD_I2C and have\n" - ">>communicated with my clock, so that is good. Next up is transferring the\n" + ">>Ok, well I've successfully compiled with CONFIG_HARD_I2C and have \n" + ">>communicated with my clock, so that is good. Next up is transferring the \n" ">>date in u-boot to linux, but I'm sure that will be documented somewhere.\n" - ">>\n" + ">> \n" ">>\n" ">\n" ">You don't \"transfer\" the daye. Linux will pick it up itself (which\n" ">requires an RTC driver and eventually some modifications).\n" ">\n" "\n" - "Let me check that I understand: As far as I can see the u-boot realtime\n" - "clock drivers just allow you to set and read the time from the u-boot\n" - "command line; a useful utility. If linux is to read the time from the\n" - "realtime clock it must have a realtime clock driver of its own; there's\n" - "no way that u-boot can pass the time to linux at boot time? (Of course,\n" - "this would be fraught with difficulties, because depending on how fast\n" - "your cpu boots linux, a different amount of time would elapse before\n" + "Let me check that I understand: As far as I can see the u-boot realtime \n" + "clock drivers just allow you to set and read the time from the u-boot \n" + "command line; a useful utility. If linux is to read the time from the \n" + "realtime clock it must have a realtime clock driver of its own; there's \n" + "no way that u-boot can pass the time to linux at boot time? (Of course, \n" + "this would be fraught with difficulties, because depending on how fast \n" + "your cpu boots linux, a different amount of time would elapse before \n" "linux could actually do something with the passed date stamp).\n" "\n" - "So, next up for me is to write a linux driver for the ds1307. I was\n" - "actually in the middle of that before getting sidetracked by the u-boot\n" - "rtc code. However, the u-boot code has enabled me to hardware debug my\n" - "realtime clock circuit, so that was very useful. Has anyone written a\n" - "linux driver for the ds1307 or similar? (I'm cross posting to the\n" + "So, next up for me is to write a linux driver for the ds1307. I was \n" + "actually in the middle of that before getting sidetracked by the u-boot \n" + "rtc code. However, the u-boot code has enabled me to hardware debug my \n" + "realtime clock circuit, so that was very useful. Has anyone written a \n" + "linux driver for the ds1307 or similar? (I'm cross posting to the \n" "linuxppc-embedded list to ask this question).\n" "\n" - ">>As for CONFIG_SOFT_I2C; Attached (really this time) is a diff between\n" - ">>the original u-boot-0.4.0/include/configs/TQM823L.h and the one that I\n" - ">>have altered. The compile of soft_i2c.c fails with the following error\n" + ">>As for CONFIG_SOFT_I2C; Attached (really this time) is a diff between \n" + ">>the original u-boot-0.4.0/include/configs/TQM823L.h and the one that I \n" + ">>have altered. The compile of soft_i2c.c fails with the following error \n" ">>messages:\n" - ">>\n" + ">> \n" ">>\n" ">\n" ">That's because you did not define the required macros (see for\n" ">example the configuration in lwmon.h).\n" + "> \n" ">\n" - ">\n" - "Right, so it's not the case that you just #define CONFIG_SOFT_I2C; you\n" - "have to correctly define the macros. I shall do some work on the readme\n" + "Right, so it's not the case that you just #define CONFIG_SOFT_I2C; you \n" + "have to correctly define the macros. I shall do some work on the readme \n" "and post a diff later on. Thanks for the pointers.\n" "\n" "best,\n" "\n" - "Seb\n" - "\n" - "\n" - ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ + Seb -c1f4bd03c070d261e3f2fa997964fea128c274ed614d25d6a5e23981c52c50a1 +3592b0b4cf69ac7b4e4cac7753d822328651ef0a85c18efa1488b0fad3ec5511
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.