>
> I ran into this last week when configuring an I2C RTC device, and I have 
> not seen this mentioned in the group.


Angstrom for the BBB, at least the most recent version, has a selection of 
device tree files, both in source and precompiled form.  I used them as a 
basis for my own Beagleboard NTPD device tree.  I've found an ambiguous 
address reference that tripped me up.

Consider this segment of a device tree for an I2C RTC device, such as the 
Dallas DS1307, or the DS3231 (packaged as the Chronodot, which I have).  
I've omitted most of it for clarity:


>         fragment@1 {
>                 target = <&i2c2>;
>
>                 __overlay__ {
>                         /* shut up DTC warnings */
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>
>                         /* DS1307 RTC module */
>                         rtc@68 {
>                                 compatible = "dallas,ds1307";
>                                 reg = <0x68>;
>                         };
>                 };
>         }
>
 Note the rtc@68 address.  This is ambiguous.  The real address of this 
device is 0x68 in hex.  The DTC parser must interpret numeric values in a 
default decimal radix, unless it has a hex digit already in it;  another 
device I have is addressed as 3C, which is represented correctly.

My RTC was not being detected by the kernel.  The fix is simple:  always 
insert the 0x prefix for all addresses (represented in most databooks in 
hex);  the corrected reference is rtc@0x68.  My Chronodot was since 
detected by the kernel with no fuss.

I've "decompiled" the original binary device tree file 
(BB-BONE-RTC-00A0.dtbo) and it matches the source (BB-BONE-RTC-00A0.dts) as 
far as the address reference is concerned.

I believe this would affect all I2C devices represented in the device 
tree.  I haven't had the chance to scan the other device tree files.  I am 
running this on a Beaglebone White, but I have both species of Beaglebone 
(white and black) and they both are running the latest Angstrom so this 
problem appears to still exist.

I've attached a corrected version of the BB-BONE-RTC-00A0.dts file.

Regards,

Dave M.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
/*
* Copyright (C) 2013 Matt Ranostay <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/plugin/;

/*
 * Pin assignments
 *
 * Module     Connector
 * SCL     -> P9.19
 * SDA     <- P9.20
 * SQW/PPS <- P9.15
 *
 */

/ {
        compatible = "ti,beaglebone", "ti,beaglebone-black";
        part-number = "BB-BONE-RTC-01";
        version = "00A0";

        /* state the resources this cape uses */
        exclusive-use =
                /* the pin header uses */
                "P9.15";        /*gpio1_16 */


        fragment@0 {
                target = <&am33xx_pinmux>;
                __overlay__ {
                        pps_pins: pinmux_pps_pins {
                                pinctrl-single,pins = <
                                        0x040   0x27    /* gpmc_a0.gpio1_16, 
INPUT | PULLDIS | MODE7 */
                                >;
                        };
                };
        };


        fragment@1 {
                target = <&i2c2>;

                __overlay__ {
                        /* shut up DTC warnings */
                        #address-cells = <1>;
                        #size-cells = <0>;

                        /* DS1307 RTC module */
                        rtc@0x68 {
                                compatible = "dallas,ds1307";
                                reg = <0x68>;
                        };
                };
        };

        fragment@2 {
                target = <&ocp>;
                __overlay__ {
                        pps {
                                compatible = "pps-gpio";
                                status = "okay";
                                pinctrl-names = "default";
                                pinctrl-0 = <&pps_pins>;

                                gpios = <&gpio2 16 0>;
                                assert-falling-edge;
                        };
                };
        };
};

Reply via email to