On 3 February 2017 at 04:28, Frank Rowand <frowand.list@xxxxxxxxx> wrote:
> On 02/02/17 09:53, Frederik Lotter wrote:
>> Hi,
>>
>> I have a particular device tree node property which refuses to reach
>> the Linux kernel without corruption:
>>
>> interrupts = <0xc 0x1>;
>>
>>>From the extract below from the preprocessed file:
>>
>> i2c1: i2c@f0018000 {
>> compatible = "atmel,at91sam9x5-i2c";
>> reg = <0xf0018000 0x4000>;
>> interrupts = <0x13 0x4 0x6>;
>> dmas = <0x2 0x2 0x9 0x2 0x2 0xa>;
>> dma-names = "tx", "rx";
>> pinctrl-names = "default";
>> pinctrl-0 = <0x12>;
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>> clocks = <0x13>;
>> status = "okay";
>> clock-frequency = <0x61a80>;
>> atmel,recover-scl = <0x14 0x1b 0x0>;
>> atmel,recover-sda = <0x14 0x1a 0x0>;
>>
>> lsm6ds3@6b {
>> compatible = "st,lsm6ds3";
>> reg = <0x6b>;
>> pinctrl-names = "default";
>> pinctrl-0 = <0x15>;
>> interrupt-parent = <0x16>;
>> interrupts = <0xc 0x1>;
>> interrupt-names = "lsm6ds_int1";
>> st,drdy-int-pin = <0x1>;
>> };
>> };
>>
>> Version: DTC 1.4.0 (ubuntu package) for manual testing.
>>
>> (1) fdtdump mix6000.dtb | grep interrupts
>>
>> Thsi returns the interrupt line as:
>>
>> interrupts = <0x0000000c 0x000001d0>;
>>
>> (2) In the linux kernel the of_platform_populate() reads the same property as:
>>
>> 0x0000000c 0x00000000 with lenth=8
>>
>> (3) If I take the DTS file and manually compile the DTB with the dtc
>> compiler, and convert it back to the DTS the correct values are shown
>>
>> (4) If I change the interrupt value:
>>
>> interrupts = <0xc 0x0>;
>>
>> and I do:
>>
>> cat <file-old.dtb> | od -t x1 > file1.txt
>> cat <file-mod.dtb> | od -t x1 > file2.txt
>> kdiff3 file1.txt file2.txt
>>
>> I actually see a single hex byte change from 0x1 to 0x0.
>>
>> If it was not for the faulty fdtdump output (in conjuection with the
>> Linux kernel zero at the same place) I would have said its definately
>> a kernel issue.
>>
>> Any ideas?
>
> You can see what the dtb looked like when given to the kernel. Take
> /sys/firmware/fdt and decompile that with dtc.
>
> If it already looks bad at this point, does your bootloader have any
> way to look at the dtb?
>
> -Frank
Thank you for the hint - this made me discover a very embarrassing
mistake on my behalf.
Our system is complex and has two boot paths (one from eMMC and one
from SDCARD), each with their own DT file. I was testing on the SDCARD
environment and modifying the eMMC DT file. The SDCARD DT file
happened to have the second property on the "interrupts" field hard
coded as zero from a legacy device we had there.
Thank you for your time to answer me. Much appreciated.
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
