Heads up: Device tree files compiled with wrong address references?

GoogleGroups
1

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.

BB-BONE-RTC-00A0.dts.txt (2.01 KB)

2

rtc@68 is a devicetree node name, not an address as such, it's purpose is to make the node name unique.
It's the "reg = <0x68>;" that defines the address on the i2c bus

My rtc is defined as follows

&i2c1 {
        pinctrl-names = "default";
        pinctrl-0 = <&i2c1_pins>;

        status = "okay";
        clock-frequency = <100000>;

        rtc@foobar {
                compatible = "mcp,mcp7941x";
                reg = <0x6f>;
        };

};

it's using the same rtc-ds1307 driver and works fine.

It may be worth having a read at Documentation/devicetree/booting-without-of.txt in the kernel source tree for the details of how the mode names are formatted and what the "unit address" side of the @ really means.

3

Yes,the kernel documentation is bedtime reading. Thanks.

My example may have been too simple–I have two I2C devices, the RTC and a Solomon SSD1306 display at 3C on the same bus.

I could not get the RTC to detect until I made that change with the address. The display was detected OK.

I take your point, though; This problem would have had to come up long before I brought it up–of course it could be my mistake!

I still think it’s ambiguous, and I am going to spell out the radix, always.

Thanks.

4

Yes,the kernel documentation is bedtime reading. Thanks.

:slight_smile:

My example may have been too simple--I have /two/ I2C devices, the RTC and a Solomon SSD1306 display at 3C on the same bus.

I have multiple devices as well, three on the current setup one of which is at 0x48 and having dev@48 makes no difference, still works.

I still think it's ambiguous, and I am going to spell out the radix, always.

Interestingly, if you ever try to get a change accepted in the mainstream kernel that does that in the node name you'll get told to remove it.

But either way, it's entirely up to you. Only requirement from the doc is that the names are unique.