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.
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…
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
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,
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...