Modifying the device tree

Kernels & Hardware, configuring network, installing services

Modifying the device tree

Postby eldiener » 2017-09-12 14:03

I need to modify the device tree on an ARM platform running Debian and rebuild the kernel to use the modification. Is there any document which tells me how to do this for Debian ? I am aware of the Debian Linux Kernel Handbook at https://kernel-handbook.alioth.debian.org/index.html, but I need more specific guidance about what I have to do.
eldiener
 
Posts: 6
Joined: 2017-09-12 12:20

Re: Modifying the device tree

Postby Segfault » 2017-09-12 21:52

Modify the device tree? What does this mean?
Segfault
 
Posts: 468
Joined: 2005-09-24 12:24

Re: Modifying the device tree

Postby GarryRicketson » 2017-09-12 22:06

I can not answer the OP's question, but as far as what is meant
by "modify the device tree on an ARM platform running Debian",
there is a lot of results,....

modify the device tree on an ARM platform running Debian
Is there any document which tells me how to do this for Debian ?

It seems to be a rather complex process, and with out anything from the OP
as to what kind of modifications they want to make, etc. I don't see how any one
can answer, this might help them get started:
http://developer.toradex.com/device-tree-customization

also:
https://community.arm.com/dev-platforms/b/documents/posts/faq-what-is-device-tree
"What we expect you have already Done"

Before doing anything, read the Debian documentation:
Debian Documentation
How to ask the smart way
Debian Foro Español
======================
For the Birds
User avatar
GarryRicketson
 
Posts: 4218
Joined: 2015-01-20 22:16
Location: Durango, Mexico

Re: Modifying the device tree

Postby eldiener » 2017-09-12 22:27

Segfault wrote:Modify the device tree? What does this mean?


I am not concerned with the change to the device tree I need to make. As long as I can find the current device tree I know how to change it. I believe that I once I change the device tree I only need to compile the change to a new device tree blob file, with a .dtb extension, and then the boot loader needs to be set to use my new device tree blob. In this way I do not have to modify the Debian kernel at all. I am new to all of this but I just want to understand that this way of making a change to the device tree and having the Debian system use my change when the system boots, is correct. The system is Debian on an ARM processor for a SOM board.
eldiener
 
Posts: 6
Joined: 2017-09-12 12:20

Re: Modifying the device tree

Postby Head_on_a_Stick » 2017-09-13 05:41

Do you mean the drivers?
"Yes Linus, our patches are such garbage the KSPP can't manage to do anything other than copy+paste from them, and you're slowly merging them (along with our registered copyrights). How do our table scraps taste?" — Brad Spengler, grsecurity
User avatar
Head_on_a_Stick
 
Posts: 6538
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Modifying the device tree

Postby pylkko » 2017-09-13 13:26

Yes, what you described is essentially correct. On ARM, there is no seperate bios or uefi chip and the firmware is put on the actual storage device (emmc or SD card or some such). So you have 2 options either compile the kernel with the data required for hardware initialization (unique to each board) or use a device tree with a stock kernel (have one kernel for all your boards). This is a human readable file that is usually compiled as a binary which is put on the /boot partition that the minimal bootloader (u-boot) requires. It then tells the kernel what devices exist and how to start them.

You will find tutorials all over the internet if you search for devices like Beagle board + tutorial + device tree etc

EDIT: typos and crap.
Last edited by pylkko on 2017-09-13 18:53, edited 1 time in total.
User avatar
pylkko
 
Posts: 1045
Joined: 2014-11-06 19:02

Re: Modifying the device tree

Postby eldiener » 2017-09-13 13:48

pylkko wrote:Yes, what you described is essentially correct. On ARM, there is no seperate bios or uefi chip and the firmware is put on the actual storage device (emmc or SD card or so we such). So you have 2 options either compile the kernel with the data required for hardware initialization or use a device tree with a stock kernel. This is a human readable file that is usually compiled as a binary which is put on the /boot partition that the minimal bootloader (u-boot) requires. It then tells the kernel what devices exist and how to start them.

You will find tutorials all over the internet if you search for devices like Beagle board + tutorial + device tree etc


Thanks for the confirmation. I do not know what "Beagle board" is, but I will follow the instructions for the SOM board with which I am working.
eldiener
 
Posts: 6
Joined: 2017-09-12 12:20

Re: Modifying the device tree

Postby pylkko » 2017-09-13 18:52

Ok, the beaglebboard is one of the most common ARM boards used with Debian: https://beagleboard.org/

Their boot sequence:
http://processors.wiki.ti.com/index.php/Boot_Sequence wrote:At power-up an OMAP3 device begins booting from internal Boot ROM. This code is fixed during the manufacturing process and cannot be altered. The Boot ROM reads boot configuration pins (SW4 on the OMAP3 EVM) which tell the Boot ROM where to look for the first external bootloader. The choices include NAND, UART, and SD/MMC Card. Control is then passed to this first external bootloader called x-loader. The x-loader application is included in the Linux PSP provided by TI and can be modified by the end user. The x-loader application passes control to u-boot. U-boot is also a bootloader and is considered the second external bootloader in this case.


U-boot is the application which passes control to the Linux system. The main goal of u-boot is to retrieve the Linux kernel and provide the kernel with information about the location of the Linux filesystem. U-boot can be configured to retrieve the kernel from NAND, SD/MMC Card, UART or Ethernet (via TFTP). U-boot can also specify a root filesystem that is located in NAND (jffs2), SRAM (ramdisk), SD/MMC card (ext3 partition) or mounted over IP (NFS).


U-boot then boots the Linux kernel. The Linux kernel mounts the Linux root filesystem.


But the main idea behind the process is the same. Another popular board the Raspberry pi has a tutorial on their page which goes into explainig DTS syntax, device tree overlays and their fragments and examples. They are not using a pure Device tree setup, however, and the device is a bit odd in that it does not boot up on the CPU but the GPU does the initial boot. That is, the second level bootloader that is not in ROM is read by only the GPU into L2 cache, no RAM and no CPU are even up at this point.

https://www.raspberrypi.org/documentati ... ce-tree.md
User avatar
pylkko
 
Posts: 1045
Joined: 2014-11-06 19:02

Re: Modifying the device tree

Postby eldiener » 2017-09-13 21:44

pylkko wrote:Ok, the beaglebboard is one of the most common ARM boards used with Debian: https://beagleboard.org/

Their boot sequence:
http://processors.wiki.ti.com/index.php/Boot_Sequence wrote:At power-up an OMAP3 device begins booting from internal Boot ROM. This code is fixed during the manufacturing process and cannot be altered. The Boot ROM reads boot configuration pins (SW4 on the OMAP3 EVM) which tell the Boot ROM where to look for the first external bootloader. The choices include NAND, UART, and SD/MMC Card. Control is then passed to this first external bootloader called x-loader. The x-loader application is included in the Linux PSP provided by TI and can be modified by the end user. The x-loader application passes control to u-boot. U-boot is also a bootloader and is considered the second external bootloader in this case.


U-boot is the application which passes control to the Linux system. The main goal of u-boot is to retrieve the Linux kernel and provide the kernel with information about the location of the Linux filesystem. U-boot can be configured to retrieve the kernel from NAND, SD/MMC Card, UART or Ethernet (via TFTP). U-boot can also specify a root filesystem that is located in NAND (jffs2), SRAM (ramdisk), SD/MMC card (ext3 partition) or mounted over IP (NFS).


U-boot then boots the Linux kernel. The Linux kernel mounts the Linux root filesystem.


But the main idea behind the process is the same. Another popular board the Raspberry pi has a tutorial on their page which goes into explainig DTS syntax, device tree overlays and their fragments and examples. They are not using a pure Device tree setup, however, and the device is a bit odd in that it does not boot up on the CPU but the GPU does the initial boot. That is, the second level bootloader that is not in ROM is read by only the GPU into L2 cache, no RAM and no CPU are even up at this point.

https://www.raspberrypi.org/documentati ... ce-tree.md


According to my SOM board's (CL-SOM-iMX7) documentation at http://mediawiki.compulab.com/w/index.p ... vice_trees, the kernel should have DTS support but I wonder how I can determine this other than looking at the kernel source. If the kernel has DTS support I assume that after I make my DTS change and compile the DTS to a .dtb blob I only need to tell the U-boot bootloader to have DTS support, if it does not have it already, and pass the blob to the bootloader. In other words if the kernel already has DTS support I should not need to modify the kernel itself in any way. How I do the rest I will try to figure out based on Internet documentation, but if I run into any problems I will ask again here.
eldiener
 
Posts: 6
Joined: 2017-09-12 12:20


Return to System configuration

Who is online

Users browsing this forum: No registered users and 10 guests

fashionable