Device tree overlay compile error

[Ritisha Shettigar]

Hello,

I have interfaced an external RTC. I have added a device tree overlay using the link  https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-PCF8523-00A0.dts

However on compiling, it gives me an error -

Error: BB-I2C2-PCF8523-00A0.dts:9.1-9 syntax error

FATAL ERROR: Unable to parse input tree

Have also run make src/arm/BB-I2C2-PCF8523-00A0.dtbo.

Please give me a solution.

[Jeff Andich]

Hi,

(I deleted my last-post because it was too wordy.).

I'm having an issue where I sometimes get DTC compile errors and run-time behavior when I compile a Device Tree file (dts) within the u-boot source code tree vs the kernel source tree.  I made some modifications to the device tree, am57xx-evm-reva.dts to enable UART's 1 and 5.  The DTS compiles ok from within the kernel tree, and the am572xEVM/BB-X15 boots fine with that DTB. However, when I drop that same modified-DTS into the u-boot source code tree, and build u-boot, the DTC compile breaks.  Additionally, when I fix the compile errors within the u-boot tree, I see run-time issues when I load that device tree into the /boot/dtbs/uname-r directory on the BB-X15.

For u-boot, I'm using 2017.01 with a patchset which is 2-3 months old.  For the kernel, I followed the instructions on eewiki, and checked out the 4.4.y branch.

Has anyone seen anything strange like this when compiling DTB's DTBO's?

Thanks!

Jeff..

[Jeff Andich]

I went back to the default device trees in both the u-boot source tree and kernel source tree.  I tried copying the version of am57xx-evm-reva3.dts from the kernel version (rcn-4.4.y) to the u-boot source tree (u-boot version 2017.01 patched ala TI and RCN), and DTC flagged the error on the very  same line.  

It looks like the version of am57xx-evm-reva3.dts in the u-boot tree is calling out a different mode option (MODE_SELECT for the u-boot version vs. MANUAL_MODE for the kernel version) for the DRA7XX_CORE_IOPAD macro than in the kernel version (which appears to be older).  In the kernel version of pinmux/dra.h MANUAL_MODE is defined to MODE_SELECT, but in the u-boot version, MANUAL_MODE is gone.  There's probably a github change log on this somewhere...

I'm not sure what this means in terms of mixing and matching u-boot versions with debian/beagleboard images.  I mixed u-boot 2017.01 with the debian 8.6 image for the BB-X15.   I could just plunk #define MANUAL_MODE MODE_SELECT on the kernel version of the custom device tree so that we can have the same custom_board_port.DTS file in both u-boot, the kernel, and on target, but I'm not sure this is the best solution... 

*** Ritisha  *** Are you sure you're compiling your DTS file with all of the correct versions of  included files ??

Thanks,

Jeff

[Robert Nelson]

On Tue, Sep 19, 2017 at 6:13 PM, Jeff Andich <jeff....@gmail.com> wrote:
> I went back to the default device trees in both the u-boot source tree and
> kernel source tree. I tried copying the version of am57xx-evm-reva3.dts
> from the kernel version (rcn-4.4.y) to the u-boot source tree (u-boot
> version 2017.01 patched ala TI and RCN), and DTC flagged the error on the
> very same line.
>
> It looks like the version of am57xx-evm-reva3.dts in the u-boot tree is
> calling out a different mode option (MODE_SELECT for the u-boot version vs.
> MANUAL_MODE for the kernel version) for the DRA7XX_CORE_IOPAD macro than in
> the kernel version (which appears to be older). In the kernel version of
> pinmux/dra.h MANUAL_MODE is defined to MODE_SELECT, but in the u-boot
> version, MANUAL_MODE is gone. There's probably a github change log on this
> somewhere...
>
> I'm not sure what this means in terms of mixing and matching u-boot versions
> with debian/beagleboard images. I mixed u-boot 2017.01 with the debian 8.6
> image for the BB-X15. I could just plunk #define MANUAL_MODE MODE_SELECT
> on the kernel version of the custom device tree so that we can have the same
> custom_board_port.DTS file in both u-boot, the kernel, and on target, but
> I'm not sure this is the best solution...

Yeah, don't share v4.4.x-ti kernel dtbs with ti-u-boot v2017.01...

It took a long time to get the tiodelay driver into upstream kernel.
At one point, the plan was to "everything" in u-boot and the kernel
would not touch the iodelay/pinmuxing..

btw, once v2017.11-rc1 get's tagged, i'm moving the x15 based targets
to mainline u-boot. ;)

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Jeff Andich]

Thanks Robert!!

If the kernel device tree doesn't explicitly configure/re-configure a pad (e.g. pinmux, iodelay) then will the kernel leave an existing pad configuration performed by the SPL alone? In other words, if you setup a pad configuration in the SPL do you need to mimic that configuration in the kernel's device tree or only the items you want to change in the kernel ?

Now that I can build a working u-boot again (thanks to the post about u boot image size) I will try varying pinmux separately in he SPL and the kernel dev tree to try to get data visible on UART1 or 5 on the expansion header...