[U-Boot-Users] [PATCH] Add support for M41T60 serial access real-time clock
Andrew Dyer
amdyer at gmail.com
Tue Jun 19 17:50:40 CEST 2007
On 6/18/07, Lawrence R. Johnson <lrj at arlinx.com> wrote:
> Hi everyone,
>
> Here is a patch to add support to U-Boot for the STMicroelectronics M41T60 serial RTC. I used the driver for the M41T11 as a template.
>
We also use this chip. A few comments below:
> The code was tested using an AMCC Sequoia board (PPC440EPx processor) with the M41T60 connected to the board's I2C0 header.
>
> In the intended application, the RTC will be powered by a large capacitor, rather than a battery. The driver therefore checks to see whether the RTC has lost power. The chip's OUT bit is normally reset from its power-up state. If the OUT bit is read as set, or if the date and time are not valid, then the RTC is assumed to have lost power, and its date and time are reset to 1900-01-01 00:00:00.
>
> Signed-off-by: Larry Johnson <lrj at acm.org>
>
> diff -Naur a/rtc/m41t60.c b/rtc/m41t60.c
> --- a/rtc/m41t60.c 1969-12-31 19:00:00.000000000 -0500
> +++ b/rtc/m41t60.c 2007-06-18 11:02:11.000000000 -0400
> +/*
> + Convert between century and "century bits" (CB1 and CB0). These
> + routines assume years are in the range 1900 - 2299.
> +*/
> +
> +static unsigned char year2cb(unsigned const year)
> +{
> + if (year < 1900 || year >= 2300) {
> + printf("M41T60 RTC: year %d out of range\n", year);
> + }
> + return (year / 100) & 0x3;
> +}
This doesn't match the defined mapping in the datasheet between the
century bits and years which has '00' corresponding to 2000.
> +
> +static unsigned cb2year(unsigned const cb)
> +{
> + return 1900 + 100 * ((cb + 1) & 0x3);
> +}
> +
> +/*
> + * These are simple defines for the chip local to here so they aren't too
> + * verbose. DAY/DATE aren't nice but that is how they are on the data sheet.
> + */
> +#define RTC_SEC 0x0
> +#define RTC_MIN 0x1
> +#define RTC_HOUR 0x2
> +#define RTC_DAY 0x3
> +#define RTC_DATE 0x4
> +#define RTC_MONTH 0x5
> +#define RTC_YEARS 0x6
> +
> +#define RTC_REG_CNT 7
> +
> +#define RTC_CTRL 0x7
> +
> +#if defined(DEBUG)
> +static void rtc_dump(char const *const label)
> +{
> + uchar data[8];
> +
> + if (i2c_read(CFG_I2C_RTC_ADDR, 0, 1, data, sizeof(data))) {
> + printf("I2C read failed in rtc_dump()\n");
> + return;
> + }
> + printf("RTC dump %s: %02X-%02X-%02X-%02X-%02X-%02X-%02X-%02X\n",
> + label, data[0], data[1], data[2], data[3],
> + data[4], data[5], data[6], data[7]);
> +}
> +#else /* !defined(DEBUG) */
> +#define rtc_dump(label)
> +#endif /* defined(DEBUG) */
I would suggest to use the u-boot debug() macro here
> + if (0x00 != (data[RTC_CTRL] & 0x80)) {
couldn't this be written as
if(data[RTC_CTRL] & 0x80)
> + /*
> + * If the ocsillator is stopped or the date is invalid, then set the OUT
> + * bit to "1", reset the date registers, and start the oscillator.
> + */
> + min = data[RTC_MIN] & 0x7F;
> + date = data[RTC_DATE];
> + month = data[RTC_MONTH] & 0x3F;
> + years = data[RTC_YEARS];
> + if (0x59 < data[RTC_SEC] || 0x09 < (data[RTC_SEC] & 0x0F) ||
> + 0x59 < min || 0x09 < (min & 0x0F) ||
> + 0x23 < data[RTC_HOUR] || 0x09 < (data[RTC_HOUR] & 0x0F) ||
> + 0x07 < data[RTC_DAY] || 0x00 == data[RTC_DAY] ||
> + 0x12 < month ||
> + 0x99 < years || 0x09 < (years & 0x0F) ||
> + daysInMonth[month] < date || 0x09 < (date & 0x0F) || 0x00 == date ||
> + (0x29 == date && 0x02 == month &&
> + ((0x00 != (years & 0x03)) ||
> + (0x00 == years && 0x00 != (data[RTC_MONTH] & 0xC0))))) {
> + printf("Resetting M41T60 RTC clock.\n");
> + /*
> + * Set to 00:00:00 1900-01-01 (Monday)
> + */
> + data[RTC_SEC] = 0x00;
> + data[RTC_MIN] = 0x00;
> + data[RTC_HOUR] = 0x00;
> + data[RTC_DAY] = 0x02;
> + data[RTC_DATE] = 0x01;
> + data[RTC_MONTH] = 0xC1;
> + data[RTC_YEARS] = 0x00;
> + data[RTC_CTRL] &= 0x7F;
here you are resetting the calibration bits. It would be nice to have
the option to try to fetch the calibration bits from the u-boot
environment and restore them. Also your code is clearing the FT and
OUT/OFIE bits, which someone might be using for something. This
behaviour should at least be noted in the comments. Better would be
an option as to how to handle those bits on reset.
--
Hardware, n.:
The parts of a computer system that can be kicked.
More information about the U-Boot
mailing list