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
Modifying the device tree
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.
- GarryRicketson
- Posts: 5644
- Joined: 2015-01-20 22:16
- Location: Durango, Mexico
Re: Modifying the device tree
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
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
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
It seems to be a rather complex process, and with out anything from the OPIs there any document which tells me how to do this for Debian ?
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
"What we expect you have already Done"
==========
Old Website
======================
For the Birds
==================
What Does a Parrot Know About PTSD?
==========
Old Website
======================
For the Birds
==================
What Does a Parrot Know About PTSD?
Re: Modifying the device tree
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.Segfault wrote:Modify the device tree? What does this mean?
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Modifying the device tree
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.
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.
Re: Modifying the device tree
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.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
Re: Modifying the device tree
Ok, the beaglebboard is one of the most common ARM boards used with Debian: https://beagleboard.org/
Their boot sequence:
https://www.raspberrypi.org/documentati ... ce-tree.md
Their boot sequence:
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.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.
https://www.raspberrypi.org/documentati ... ce-tree.md
Re: Modifying the device tree
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.pylkko wrote:Ok, the beaglebboard is one of the most common ARM boards used with Debian: https://beagleboard.org/
Their boot sequence: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.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.
https://www.raspberrypi.org/documentati ... ce-tree.md