Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Grant Likely
grant.likely at secretlab.ca
Thu Mar 18 06:02:57 EST 2010
2010/3/13 Németh Márton <nm127 at freemail.hu>:
> Hi,
>
> here is a version with modified cpu node, xbar ranges and added interrupt sources.
> Please send comments.
Hi Márton. A few comments below.
> ---
> From: Márton Németh <nm127 at freemail.hu>
>
> Add device tree for Freescale MPC5554.
>
> Signed-off-by: Márton Németh <nm127 at freemail.hu>
> ---
> diff -uprN linux-2.6.33.orig/arch/powerpc/boot/dts/mpc5554.dts linux/arch/powerpc/boot/dts/mpc5554.dts
> --- linux-2.6.33.orig/arch/powerpc/boot/dts/mpc5554.dts 1970-01-01 01:00:00.000000000 +0100
> +++ linux/arch/powerpc/boot/dts/mpc5554.dts 2010-03-13 12:52:32.000000000 +0100
> @@ -0,0 +1,473 @@
> +/*
> + * Freescale MPC5554 Device Tree Source
> + *
> + * Based on MPC5553/5554 Microcontroller Reference Manual, Rev. 4.0, 04/2007
> + * http://www.freescale.com/files/32bit/doc/ref_manual/MPC5553_MPC5554_RM.pdf
> + * - Block Diagram: page 1-3, Figure 1-1
> + * - Memory Map: page 1-21, Table 1-2
> + * - Interrupt Request Sources: page 10-16, Table 10-9
> + *
> + * Copyright 2010 Márton Németh
> + * Márton Németh <nm127 at freemail.hu>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "MPC5554";
> + compatible = "fsl,MPC5554EVB"; // Freescale MPC5554 Evaluation Board
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&intc>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "PowerPC,5554", "fsl,mpc5554-e200z6", "fsl,powerpc-e200z6";
> + reg = <0>;
> + d-cache-line-size = <32>;
> + i-cache-line-size = <32>;
> + d-cache-size = <0x8000>; // L1, 32KiB
> + i-cache-size = <0x8000>; // L1, 32KiB
> + timebase-frequency = <0>; // from bootloader
> + bus-frequency = <0>; // from bootloader
> + clock-frequency = <0>; // from bootloader
> + };
> + };
> +
> + memory at 40000000 {
> + device_type = "memory";
> + reg = <0x40000000 0x10000>; // 32KiB internal SRAM
> + };
Oh.... this is the small SRAM. yeah, you should move this under the
appropriate bridge node, remove the device_type property, and add a
compatible property. Memory nodes at the root like this are used to
describe what is basically main memory (what Linux will execute out
of). You'll want a new memory node for the external ram hooked up to
the 5554.
> +
> + xbar at fff04000 { // System Bus Crossbar Switch (XBAR)
> + compatible = "fsl,mpc5554-xbar";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + // The full memory range is covered by XBAR
> + ranges;
> + reg = <0xfff04000 0x4000>;
> +
> + flash at 0 { // read-only FLASH
> + compatible = "fsl,mpc5554-flash";
> + reg = <0x00000000 0x200000>; // 2MiB internal FLASH
> + };
> +
> + bridge at c3f00000 {
> + compatible = "fsl,mpc5554-pbridge-a";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0xc0000000 0x20000000>;
> + reg = <0xc3f00000 0x4000>;
> +
> + fmpll at 3f80000 { // Frequency Modulated PLL
> + compatible = "fsl,mpc5554-fmpll";
> + reg = <0x03f80000 0x4000>;
> + interrupts = <43 1 // Loss of Clock
> + 44 1>; // Loss of Lock
> + };
> +
> + flashconfig at 3f88000 { // Flash Configuration
> + compatible = "fsl,mpc5554-flashconfig";
> + reg = <0x03f88000 0x4000>;
> + };
> +
> + siu at 3f89000 { // System Integration Unit
> + compatible = "fsl,mpc5554-siu";
> + reg = <0x03f90000 0x4000>;
> + interrupts = <45 1 // External Interrupt Overrun 0-15
> + 46 1 // External Interrupt 0
> + 47 1 // External Interrupt 1
> + 48 1 // External Interrupt 2
> + 49 1 // External Interrupt 3
> + 50 1>; // External Interrupt 4-15
> + };
This doesn't look quite right.... /me goes to look at the 5554
reference manual....
Okay, so all the external IRQs go through the SIU then, even though
the first 4 get passed straight through to the intc? And I see that
all the level/edge sensing and masking/acknowledging is done at the
SIU level, not the intc level, correct? So, what you effectively have
is the SIU is *another* interrupt controller that is cascaded to the
intc. Therefore you need to add the following to this node:
#interrupt-cells = <2>; // cell1:extirq#, cell2:level/edge flags
interrupt-controller;
Also give the node a label so that nodes for external devices can
reference it for hooking up external irqs by overriding the top-level
interrupt-parent property.
Also, it would appear that intc interrupts don't have any level/edge
configuration associated with them. They are either asserted, or they
are not, correct? At the moment you're specifying every intc
interrupt with 2 cells, and the 2nd cell is always '1'. I think you
can change #interrupt-cells to <1> in the intc node and drop the '1'
everywhere.
When you write your intc driver, you'll also need to write the
cascaded driver for the external IRQs.
> +
> + emios at 3fa0000 { // Modular Timer System
> + compatible = "fsl,mpc5554-emios";
> + reg = <0x03fa0000 0x4000>;
> + interrupts = <51 1 // Channel 0
> + 52 1 // Channel 1
> + 53 1 // Channel 2
> + 54 1 // Channel 3
> + 55 1 // Channel 4
> + 56 1 // Channel 5
> + 57 1 // Channel 6
> + 58 1 // Channel 7
> + 59 1 // Channel 8
> + 60 1 // Channel 9
> + 61 1 // Channel 10
> + 62 1 // Channel 11
> + 63 1 // Channel 12
> + 64 1 // Channel 13
> + 65 1 // Channel 14
> + 66 1 // Channel 15
> + 202 1 // Channel 16
> + 203 1 // Channel 17
> + 204 1 // Channel 18
> + 205 1 // Channel 19
> + 206 1 // Channel 20
> + 207 1 // Channel 21
> + 208 1 // Channel 22
> + 209 1>; // Channel 23
These long lists bother me, but looking at the manual they seem to
describe the actual hardware architecture, so I think they are
probably fine. But you may want to compact your formatting somewhat.
You can probably list more than one channel per
source line in the file.
Ditto through the rest of the file.
> + };
> +
> + etpu at 3fc0000 { // Enhanced Time Processing Unit
> + compatible = "fsl,mpc5554-etpu";
> + reg = <0x03fc0000 0x4000>;
> + interrupts = <67 1 // Global Exception
> + 68 1 // A Channel 0
> + 69 1 // A Channel 1
> + 70 1 // A Channel 2
> + 71 1 // A Channel 3
> + 72 1 // A Channel 4
> + 73 1 // A Channel 5
> + 74 1 // A Channel 6
> + 75 1 // A Channel 7
> + 76 1 // A Channel 8
> + 77 1 // A Channel 9
> + 78 1 // A Channel 10
> + 79 1 // A Channel 11
> + 80 1 // A Channel 12
> + 81 1 // A Channel 13
> + 82 1 // A Channel 14
> + 83 1 // A Channel 15
> + 84 1 // A Channel 16
> + 85 1 // A Channel 17
> + 86 1 // A Channel 18
> + 87 1 // A Channel 19
> + 88 1 // A Channel 20
> + 89 1 // A Channel 21
> + 90 1 // A Channel 22
> + 91 1 // A Channel 23
> + 92 1 // A Channel 24
> + 93 1 // A Channel 25
> + 94 1 // A Channel 26
> + 95 1 // A Channel 27
> + 96 1 // A Channel 28
> + 97 1 // A Channel 29
> + 98 1 // A Channel 30
> + 99 1 // A Channel 31
> + 243 1 // B Channel 0
> + 244 1 // B Channel 1
> + 245 1 // B Channel 2
> + 246 1 // B Channel 3
> + 247 1 // B Channel 4
> + 248 1 // B Channel 5
> + 249 1 // B Channel 6
> + 250 1 // B Channel 7
> + 251 1 // B Channel 8
> + 252 1 // B Channel 9
> + 253 1 // B Channel 10
> + 254 1 // B Channel 11
> + 255 1 // B Channel 12
> + 256 1 // B Channel 13
> + 257 1 // B Channel 14
> + 258 1 // B Channel 15
> + 259 1 // B Channel 16
> + 260 1 // B Channel 17
> + 261 1 // B Channel 18
> + 262 1 // B Channel 19
> + 263 1 // B Channel 20
> + 264 1 // B Channel 21
> + 265 1 // B Channel 22
> + 266 1 // B Channel 23
> + 267 1 // B Channel 24
> + 268 1 // B Channel 25
> + 269 1 // B Channel 26
> + 270 1 // B Channel 27
> + 271 1 // B Channel 28
> + 272 1 // B Channel 29
> + 273 1 // B Channel 30
> + 274 1>; // B Channel 31
Are A and B two instances of the same hardware block? Consider having
a subnode for each instance to give some logical separation to this
list and associate register ranges with instances. Doing it that way
also makes it easier for external device nodes to describe an
attachment to a particular channel.
> + };
> +
> + etpudata at 3fc8000 { // eTPU Shared Data Memory (Parameter RAM)
> + compatible = "fsl,mpc5554-etpudata";
> + reg = <0x03fc8000 0x4000>;
> + };
> +
> + etpudata at 3fcc000 { // eTPU Shared Data Memory (Parameter RAM) mirror
> + compatible = "fsl,mpc5554-etpudata";
> + reg = <0x03fcc000 0x4000>;
> + };
> +
> + etpucode at 3fd0000 { // eTPU Shared Code RAM
> + compatible = "fsl,mpc5554-etpucode";
> + reg = <0x03fd0000 0x4000>;
> + };
Should all this etpu stuff be part of the etpu node?
This looks like it is getting close. Once you've got a version that
looks good to everyone, you also need to document what the new
bindings mean. Essentially this task involves writing down all the
new compatible property values that you've defined, what device each
one describes, and what properties/subnodes are expected for each new
compatible value. Documentation currently goes in the
Documentation/powerpc/dts-bindings directory, and you can see lots of
examples there. (However, I'm hoping to moving it to
http://devicetree.org in the near future so it can be shared by other
OSes. I've currently got a test site up at http://fdt.secretlab.ca).
The rule is that we will not merge drivers using new OF bindings until
those bindings have been documented and reviewed.
Cheers,
g.
More information about the Linuxppc-dev
mailing list