i am trying to modify the dtsi file for can clock but while compiling the dtsi file i am getting error
Error: tegra194-soc-can.dtsi:17.1-2 syntax error
FATAL ERROR: Unable to parse input tree
What is the exact file you changed, and what are the edits?
hi,
i am doing following changes in tegra194-soc-can.dtsi file
pll_source = “osc”;
clocks = <0x4 0x11c 0x4 0xa 0x4 0x9 0x4 0x5b>;
clock-names = “can_core”, “can_host”, “can”, “osc”;
while compiling getting above error
dtc -I dts -O dtb -o tegra194-soc-can.dtb tegra194-soc-can.dtsi
using this command
This is incorrect due to the “.dtsi” file. An analogy with a C header file is a good way to describe a “.dtsi” file. Like a header a “.dtsi” is only part of a source file. You cannot compile a header any more than you can compile a “.dtsi” file. You need to include the dtsi into another dts file, and then build the whole file. It gets more complicated because this analogy only works when building the entire kernel source.
Whenever you build a kernel or any part of a kernel there is a configuration system (“Kconfig”). This picks different parts of the kernel to include or ignore, along with making sure two incompatible features are not in conflict. You would need to configure the kernel source to be an exact match to your running system just as if you were going to build your own kernel. You would then build kernel target “make dtbs” (along with whatever setup for native or cross compile).
Note that there isn’t really any device tree include file where one can be included in the other. This is the C compiler being handed bits of a device tree which have been wrapped so that the complete dts file can be created using C code or the Makefile. The actual tool “dtc” (device tree compiler) cannot work with a .dtsi file since it is party C code and not purely device tree. This is why you must use .dtsi files with the C compiler as a kernel build target.
Now if you happen to have an original “.dtb” file you can reverse compile that into source, edit the source, and recompile that back into a binary. You simply need to know which original .dtb file to use.
You also have to beware that if the .dtb file is used for a device tree partition that the content has to be signed. Before you can reverse compile a partition extraced with dd you’d need to remove the signature. If you are putting a modified device tree binary back into a partition, then it needs to (A) be signed first, and (B) fit in the allotted partition space. Most people will just use the “FDT” key/value entry in “/boot/extlinux/extlinux.conf” for working with this since it does not need singing. If the FDT entry is present, then it should use this instead of a partition.
An example decompile of “something.dtb”:
dtc -I dtb -O dts -o something.dts something.dtb
Once something.dts is edited, here is an example recompile:
dtc -I dts -O dtb -o something_modified.dtb something.dts
1 Like
hi,
in the above case where can I get the dtb file to solve the following error
by modifying the clock frequencies
the error i am getting is as metioned below.
Cannot find device "can0"
when I execute ip link set can0 up type can bitrate 500000 command.
I’m using Jetpack 4.4.
…you would configure a kernel build to be an exact match of your currently running system, and then build the “dtbs” target. Example if native compile:
make dtbs
(other options apply for cross compile or other reasons even on a native compile, this is just the simplest possible build target)
A device tree is more or less a set of arguments to pass to the kernel and its drivers at the start of boot. One very common use is to pass the physical address of hardware, e.g., the physical address of “can0”. You’d need to adjust your device tree to include can0’s physical base address. Actual address and other details are up to you and how the hardware is added, but typically you’d find a device tree node looking something like this (your case will differ):
mttcan@c310000
In that example you’d be able to:
cd /proc/device-tree/mttcan@310000
# Browse that node's content:
ls
cat status
cat name
cat compatible
Those files and content reflect the .dtb file as it was during the Linux kernel load. The “compatible” is normally how the driver would know if it can work with that hardware. The “@320000” would be how the driver knows physical address. The “status” being “okay” would be how the driver knows it should load. Other options depend on what the driver and hardware understands.
As to the actual device tree file I do not know the answer. This partially depends on the module model, but there are also details which will depend on your carrier board.
hello,
where we need execute this command and what path we need to give
in kernel_out folder or in path where kernel 4.9 is present
sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install
INSTALL_MOD_PATH=/Linux_for_Tegra/rootfs/
want to install kernel modulels
Are you asking where to run the “sudo make ...” command? Or some other part?
in which directory we need to do the same in compiled kernel directory or kernel4.9 directory
where we need to install kernel modules .
$ sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install
INSTALL_MOD_PATH=/Linux_for_Tegra/rootfs/
Build targets are run from the actual source location. This would usually be from a “source/kernel/kernel-4.9/” subdirectory.
This is pristine source, and separate from the location of the $TEGRA_KERNEL_OUT and $INSTALL_MOD_PATH. Basically, you will have a “.config” file generated or added to the “$TEGRA_KERNEL_OUT” location, which the build will find when running from the actual source code due to specifying “$TEGRA_KERNEL_OUT”. This allows the build to read the source and only write to the alternate $TEGRA_KERNEL_OUT location.
in the above mentioned command , i dont know the exact path that should be given in place of
INSTALL_MOD_PATH= …
is that kernel 4.9 or directory we specified as tegra kernel out
INSTALL_MOD_PATH is something you make up after creating an empty directory. If you happen to name the “Linux_for_Tegra/rootfs/”, then it goes there. Keep in mind that there are “standard” locations for kernel modules, and this includes some subdirectories, so if the kernel were to have a “uname -r” of “4.9.140-tegra”, then naming the rootfs as above would end up putting actual module content here:
Linux_for_Tegra/rootfs/lib/modules/4.9.140-tegra/kernel/
Similar for “firmware”, you’d name “rootfs/” and the correct subdirectories would be appended.
Normally you use INSTALL_MOD_PATH pointing to a temporary empty directory you’ve created. This avoids accidentally overwriting something you didn’t want to overwrite. You could then recursively copy from your “$INSTALL_MOD_PATH” into the actual module directory once you are satisfied the output was correct.
The “kernel-4.9/” location is where you’d cd to to run any build commands. If you’ve created an empty directory for “TEGRA_KERNEL_OUT”, then this would put intermediate output to your clean temporary location rather than cluttering up the “kernel-4.9/” content with temp files. Having your kernel source owned by root, and not writable by anyone else, with actual compile and install steps being performed with your regular user and not root, is ideal. This enforces using a “TEGRA_KERNEL_OUT” and “TEGRA_MODULES_OUT” in some temporary unprivileged location.
hello , done above things
now i am generating image file and getting this error
Jetson Disk Image Creation Tool
ERROR: This script requires root privilege
Usage:
jetson-disk-image-creator.sh -o <sd_blob_name> -b -r
sd_blob_name - valid file name
board - board name. Supported boards are:
jetson-nano
jetson-xavier-nx-devkit
revision - SKU revision number
jetson-nano: 100/200/300 for A01/A02/B00
jetson-xavier-nx-devkit: default
Example:
jetson-disk-image-creator.sh -o sd-blob.img -b jetson-nano -r 300
jetson-disk-image-creator.sh -o sd-blob.img -b jetson-xavier-nx-devkit
I have not used the jetson-disk-image-creator.sh, but you need to prefix your commands for it with “sudo”. Otherwise filesystem IDs cannot be maintained…that kind of access is a “root only” thing.
hello linuxdev ,
i had done with kernel procedure now i want to enable the pllaon clock for can bus
for the above reference what we need to edit here
4.Convert the kernel DTB (e.g, tegra194-p2888-0001-p2822-0000.dtb) to a DTS file using the dtc tool, or obtain the kernel’s source DTS file.
5.Edit the kernel DTS file to make CAN use PLLAON as parent and remove PLLAON from list of clocks to be disabled:
clocks-init{
compatible = “nvidia,clocks-config”;
disable {
/* Edit clocks property to remove clock provider + clock id pair for PLLAON. */
};
};
what property we need to put here.
The procedure looks valid, but I don’t know enough about CAN to answer this. Someone who knows the device tree for CAN should be able to answer what the required change would be.
hello jadhav9354,
you may change BPMP device tree, modify kernel and also kernel device tree.
for your reference, please check Device tree updation - #41 by JerryChang for the steps.
thanks