Home > Community > Blogs > System Design and Verification > combining the linux device tree and kernel image for arm
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Combining the Linux Device Tree and Kernel Image for ARM

Comments(0)Filed under: Jason Andrews, ESL, ARM, linux, SystemC, TLM, System Design & Verification, virtual platforms, virtual prototypes, boot loader, kernel, Virtual System Platform, VSP, system-level, zimage, Linux device tree, ARM kernel image

Back in 2010, I wrote two articles about a SystemC model used to load the Linux kernel and its various artifacts into memory for ARM virtual platforms. The first was A SystemC TLM 2.0 ARM Linux Boot Loader and the second was More on the SystemC ARM Linux Boot Loader. At the time I covered the kernel, Linux kernel command line, and RAM-based file system.

Not too long after those articles most ARM systems started using the Linux Device Tree. The Device Tree takes the place of the kernel command line, but does much more by providing information about the hardware that is present in the system. This creates a separation between the kernel source code and the hardware such that the list of hardware can be modified without requiring the entire kernel to be modified. This is a very nice feature for virtual platform developers as it is often possible to just remove hardware descriptions from the device tree as the models are being developed, or if they have problems.

Like the kernel and file system, the device tree can be loaded into memory using the same SystemC loader model. We have been doing this with the Cadence Virtual System Platform for a couple of years now. If you are interested in examples about using the device tree, I covered it in an article about running a Linaro filesystem on the Zynq Virtual Platform last year. Although it's easy to forget, the kernel source tree also has documentation. For the device tree, look in the Documentation/devicetree directory of any kernel source tree.

The most recent development I wanted to cover today is support for combining the kernel image and the device tree into a single file. It turns out that some bootloaders may have trouble getting the device tree into memory, or maybe it's just easier to eliminate dealing with the extra file on the target system.

I have used the appended device tree feature on the ARM Versatile Express platform with kernel versions in the 3.9 to 3.11 range. Using it is straightforward. First, make sure the kernel configuration has the feature enabled. It is in the "Boot options --->" menu and called "Use appended device tree blob to zImage" as shown in the screenshot below.

Preparing the zImage is easy -- just cat the compiled device tree .dtb file to the end of the zImage:

$ cat arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb >> arch/arm/boot/zImage

That's it -- the need to separately load the device tree into memory is gone. Just the zImage can be loaded into memory and the kernel will automatically find the appended device tree and use it.

The trick is remembering that the new zImage has the device tree appended. It may be better to rename the file so you know the device tree has been appended. Also, don't forget this has to be done after every kernel build or device tree compile.

Jason Andrews


 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.