Has any luck in using the device trees (dtb files) on arm machines? Things do not seem to be working with the tegra-trimslice.dtb and CONFIG_ARM_APPENDED_DTB=y for me.
I have been looking at Red hat Bug 741325 (ARM fc14 kernels does not provide hardware perf counter support). I suspect the reason that performance monitoring hardware is not working on my trimslice because it isn't using a device tree. The performance monitoring hardware is never getting registered (https://bugzilla.redhat.com/show_bug.cgi?id=741325#c18). I have made a tegra-trimslice.dtb, appended it to the vmlinuz file (suppose to work kernel built with CONFIG_ARM_APPENDED_DTB=y in the config file), done a mkimage on the resulting concatenated file. and attempted to boot the machine. However, it seem to hang right after "Staring kernel ..." message.
-Will
Hi Will,
On Mon, Feb 20, 2012 at 9:31 PM, William Cohen wcohen@redhat.com wrote:
Has any luck in using the device trees (dtb files) on arm machines? Things do not seem to be working with the tegra-trimslice.dtb and CONFIG_ARM_APPENDED_DTB=y for me.
I have been looking at Red hat Bug 741325 (ARM fc14 kernels does not provide hardware perf counter support). I suspect the reason that performance monitoring hardware is not working on my trimslice because it isn't using a device tree. The performance monitoring hardware is never getting registered (https://bugzilla.redhat.com/show_bug.cgi?id=741325#c18). I have made a tegra-trimslice.dtb, appended it to the vmlinuz file (suppose to work kernel built with CONFIG_ARM_APPENDED_DTB=y in the config file), done a mkimage on the resulting concatenated file. and attempted to boot the machine. However, it seem to hang right after "Staring kernel ..." message.
A couple of points. Firstly all configurable HW bits and features should be configurable in our kernels without device tree, it's just not a dynamic config that we could use on any device. That said I was looking at the kernels over the weekend to get the 3.3 bits compiling on all our current various kernel configs and discovered the "CONFIG_HIGH_RES_TIMERS=y" option was configured on some of our ARM kernels but not others inc tegra. I think that might be the general config option we need to fix our kernels for the support. The tegra kernels compiles with that option, I'm in the process of getting the rest cleaned up to get a new build but you might like to try that option in the interim to see if that helps.
Peter
On 02/20/2012 07:04 PM, Peter Robinson wrote:
Hi Will,
On Mon, Feb 20, 2012 at 9:31 PM, William Cohen wcohen@redhat.com wrote:
Has any luck in using the device trees (dtb files) on arm machines? Things do not seem to be working with the tegra-trimslice.dtb and CONFIG_ARM_APPENDED_DTB=y for me.
I have been looking at Red hat Bug 741325 (ARM fc14 kernels does not provide hardware perf counter support). I suspect the reason that performance monitoring hardware is not working on my trimslice because it isn't using a device tree. The performance monitoring hardware is never getting registered (https://bugzilla.redhat.com/show_bug.cgi?id=741325#c18). I have made a tegra-trimslice.dtb, appended it to the vmlinuz file (suppose to work kernel built with CONFIG_ARM_APPENDED_DTB=y in the config file), done a mkimage on the resulting concatenated file. and attempted to boot the machine. However, it seem to hang right after "Staring kernel ..." message.
A couple of points. Firstly all configurable HW bits and features should be configurable in our kernels without device tree, it's just not a dynamic config that we could use on any device. That said I was looking at the kernels over the weekend to get the 3.3 bits compiling on all our current various kernel configs and discovered the "CONFIG_HIGH_RES_TIMERS=y" option was configured on some of our ARM kernels but not others inc tegra. I think that might be the general config option we need to fix our kernels for the support. The tegra kernels compiles with that option, I'm in the process of getting the rest cleaned up to get a new build but you might like to try that option in the interim to see if that helps.
Peter
Hi Peter,
I am quite willing to try new kernels to see if they address the perf and time of day problems.
I thought that the there were things that are not dynamically probed on arm and that was the reason for the device tree support. Is there some other way that the perf support is initialized other than device tree? Does the perf support work on the beagle board xm (omap3/omap4 processors) with the kernel-2.6.42.2-1.fc15 or kernel-3.3.0-0.rc3.git3.1.fc17?
-Will
On Tue, Feb 21, 2012 at 2:09 PM, William Cohen wcohen@redhat.com wrote:
On 02/20/2012 07:04 PM, Peter Robinson wrote:
Hi Will,
On Mon, Feb 20, 2012 at 9:31 PM, William Cohen wcohen@redhat.com wrote:
Has any luck in using the device trees (dtb files) on arm machines? Things do not seem to be working with the tegra-trimslice.dtb and CONFIG_ARM_APPENDED_DTB=y for me.
I have been looking at Red hat Bug 741325 (ARM fc14 kernels does not provide hardware perf counter support). I suspect the reason that performance monitoring hardware is not working on my trimslice because it isn't using a device tree. The performance monitoring hardware is never getting registered (https://bugzilla.redhat.com/show_bug.cgi?id=741325#c18). I have made a tegra-trimslice.dtb, appended it to the vmlinuz file (suppose to work kernel built with CONFIG_ARM_APPENDED_DTB=y in the config file), done a mkimage on the resulting concatenated file. and attempted to boot the machine. However, it seem to hang right after "Staring kernel ..." message.
A couple of points. Firstly all configurable HW bits and features should be configurable in our kernels without device tree, it's just not a dynamic config that we could use on any device. That said I was looking at the kernels over the weekend to get the 3.3 bits compiling on all our current various kernel configs and discovered the "CONFIG_HIGH_RES_TIMERS=y" option was configured on some of our ARM kernels but not others inc tegra. I think that might be the general config option we need to fix our kernels for the support. The tegra kernels compiles with that option, I'm in the process of getting the rest cleaned up to get a new build but you might like to try that option in the interim to see if that helps.
Peter
Hi Peter,
I am quite willing to try new kernels to see if they address the perf and time of day problems.
I thought that the there were things that are not dynamically probed on arm and that was the reason for the device tree support. Is there some other way that the perf support is initialized other than device tree? Does the perf support work on the beagle board xm (omap3/omap4 processors) with the kernel-2.6.42.2-1.fc15 or kernel-3.3.0-0.rc3.git3.1.fc17?
I believe it's more that things aren't advertised as opposed to things being probes so a driver is unable to find components unless explicitly told where they are for a particular board. Because manufacturers can wire up each SoC a multitude of different ways you could get different devices wired to different pins. Device Trees are the new way of dealing with that in a more dynamic way for each different device. Prior to device trees the means of discovering feautres was still there but a whole lot complex and much harder to support with more duplicated code.
The latest kernel I'm building has some overall clean ups and will use more upstream mainline kernel options and more of the general ARM config options have moved to a shared ARM config file so we can start to ensure more standardisation between the ARM kernels we ship before the supposed ultimate panacea of device tree arrives in a completely usable state across all the various ARM devices we wish to support.
Peter
On 02/20/2012 03:31 PM, William Cohen wrote:
Has any luck in using the device trees (dtb files) on arm machines? Things do not seem to be working with the tegra-trimslice.dtb and CONFIG_ARM_APPENDED_DTB=y for me.
I've gotten DTB working under QEMU for the Calxeda Highbank. I haven't tried it on real hardware yet.
--Mark Langsdorf Calxeda, Inc.
-
Mark Langsdorf -
Peter Robinson -
William Cohen