3

I am trying to add an mpu 9250 to the device tree of my RPi 3 A+ so that my custom driver's probe function will be called. I have followed this documentation about the Raspberry Pi device tree and this documentation describing the required properties for binding the mpu9250. Here is what I have so far:

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    fragment@0 {
        target = <&i2c1>;
        __overlay__ {
            status = "okay";
            mpu9250@68 {
                compatible = "invensense,mpu9250";
                reg = <0x68>;
                interrupt-parent = <&gpio3>;
                interrupts = <21 IRQ_TYPE_EDGE_RISING>;
                status = "okay";
                };
        };
    };
};

I build it on the target RPi 3 A+ with this command:

dtc -@ -I dts -O dtb -o mpu_9250.dtbo mpu_9250.dts

and here is the result:

Error: mpu_9250.dts:19.25-26 syntax error
FATAL ERROR: Unable to parse input tree

I think it is complaining about IRQ_TYPE_EDGE_RISING. When I change IRQ_TYPE_EDGE_RISING to a 1 then build, I get:

mpu_9250.dtbo: Warning (reg_format): "reg" property in /fragment@0/__overlay__/mpu9250@68 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
mpu_9250.dtbo: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
mpu_9250.dtbo: Warning (pci_device_reg): Failed prerequisite 'reg_format'
mpu_9250.dtbo: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
mpu_9250.dtbo: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
mpu_9250.dtbo: Warning (avoid_default_addr_size): Relying on default #address-cells value for /fragment@0/__overlay__/mpu9250@68
mpu_9250.dtbo: Warning (avoid_default_addr_size): Relying on default #size-cells value for /fragment@0/__overlay__/mpu9250@68
dtc: livetree.c:521: get_node_by_phandle: Assertion `(phandle != 0) && (phandle != -1)' failed.
Aborted (core dumped)

How do I fix these issues? What resources should I turn to?

I know that a driver already exists for the device, allowing access to it thru sysfs, and about i2c-dev but they don't suit my purposes.

Thanks

0

Use the Hex number of the IRQ_TYPE_EDGE_RISING.

interrupts = <21 0x1>;

  • 1
    The OP already tried to replace IRQ_TYPE_EDGE_RISING by 1. – Dmitry Grigoryev Mar 18 at 11:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.