[fedora-arm] Using device trees (dtb files) on trimslice

[Peter Robinson]

On Tue, Feb 21, 2012 at 2:09 PM, William Cohen <wcohen at 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 at 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