Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Modifying the device tree

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
eldiener
Posts: 12
Joined: 2017-09-12 12:20

Modifying the device tree

#1 Post by eldiener »

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.

Segfault
Posts: 993
Joined: 2005-09-24 12:24
Has thanked: 5 times
Been thanked: 17 times

Re: Modifying the device tree

#2 Post by Segfault »

Modify the device tree? What does this mean?

User avatar
GarryRicketson
Posts: 5644
Joined: 2015-01-20 22:16
Location: Durango, Mexico

Re: Modifying the device tree

#3 Post by GarryRicketson »

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 ... evice-tree

eldiener
Posts: 12
Joined: 2017-09-12 12:20

Re: Modifying the device tree

#4 Post by eldiener »

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.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Modifying the device tree

#5 Post by Head_on_a_Stick »

Do you mean the drivers?
deadbang

User avatar
pylkko
Posts: 1802
Joined: 2014-11-06 19:02

Re: Modifying the device tree

#6 Post by pylkko »

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.

eldiener
Posts: 12
Joined: 2017-09-12 12:20

Re: Modifying the device tree

#7 Post by eldiener »

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.

User avatar
pylkko
Posts: 1802
Joined: 2014-11-06 19:02

Re: Modifying the device tree

#8 Post by pylkko »

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

eldiener
Posts: 12
Joined: 2017-09-12 12:20

Re: Modifying the device tree

#9 Post by eldiener »

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.

Post Reply