Skip to contentSkip to conversation

Device tree FSL description for Microblaze

DISCUSSION Michal Simek 3 participants 5 messages May 25, 2011 – Jul 15, 2011 3 messages not in the archive

lore
Share & tools
lore

Michal Simek

author
#0 lore raw

Hi,

I would like to check with you proper device tree FSL description for Microblaze (PPC can use FSL through IP connected to the bus).

Microblaze supports FSL buses to connect coprocessors or hw accelerators directly to the cpu. Cpu has up to 16 fsl bus connections - master and slave side. (BTW: in the latest Microblaze with AXI is possible to use AXI stream instead of FSL but description should be the same), FSL bus has one master and in most cases one slave (more point-to-point connection than bus) but I think there could be an option to have multiple slaves for cases where the same input data goes to n-slaves.
There is also an option to generate interrupt if there is any data on the bus.

FSL devices can have multiple FSL inputs and outputs and they also can generate interrupts.

There is also one option to have only loopback which means connect CPU FSL master to CPU FSL slave with optional interrupt enabling.

I am also aware of one more option which is possibility to use a bridge instead of CPU (this option is not shown below).

Currently I have changed our generator to have the first description which I would like to use for our discussion.

Below is the important part which I would like to discuss - it is fake hw design but illustrate some important cases.

Here are some my notes:
1. I can't add FSL device directly to the CPU node because connection could be from axi IP. And I need to separate interrupt generation if there is any activity on a bus. That's why I separate fsl bus and devices out of CPU.
2. I think that shouldn't be a problem to have fsl buses in the root node
3. I think fsl devices should be moved out of root node but the point is where.
It is not bus sub/node because device can be connected to several buses. There could be a lot of connections. Any suggestions?
4. Please let me know if there should be any cells properties or similar.
5. There is not any address on the bus. FSL devices has some registers.
6. Should I use different address than 0 for connection from cpu? mfsl@5 instead of mfsl5@0?

Thanks,
Michal

/dts-v1/;

/ {
	#address-cells = <1>;
	#size-cells = <1>;
	compatible = "xlnx,microblaze";
	model = "axi-loopback";

/* cpu node */

	cpus {
		#address-cells = <1>;
		#cpus = <0x1>;
		#size-cells = <0>;
		microblaze_0: cpu@0 {
... /* some cpu parameters */
			xlnx,use-stack-protection = <0x0>;

		/* fsl_m -> master side, fsl_s -> slave side */
			fsl_m_0: mfsl0@0 {
				link = <&fsl_v20_2>; /* bus connection */
			} ;
...
			fsl_m_5: mfsl5@0 {
				link = <&fsl_v20_9>;
			} ;
			fsl_s_0: sfsl0@0 {
				link = <&fsl_v20_1>;
			} ;
...
			fsl_s_5: sfsl5@0 {
				link = <&fsl_v20_10>;
			} ;
		} ;
	} ;

/* FSL buses - all look the same that's why I keep here only two - I expect you will beat me for simple-bus compatible property. */ /* The first where all interrupts are connected */

	fsl_v20_0: fsl-v20-0@0 {
		compatible = "xlnx,fsl-v1.00.a", "simple-bus";
		interrupt-parent = <&microblaze_0_intc>;
		interrupts = < 11 2 4 2 10 2 >;
		xlnx,async-clks = <0x0>;
		xlnx,ext-reset-high = <0x1>;
		xlnx,fsl-depth = <0x10>;
		xlnx,fsl-dwidth = <0x20>;
		xlnx,impl-style = <0x0>;
		xlnx,read-clock-period = <0x0>;
		xlnx,use-control = <0x1>;
	} ;
/* bus without interrupts */
	fsl_v20_10: fsl-v20-10@0 {
		compatible = "xlnx,fsl-v1.00.a", "simple-bus";
		xlnx,async-clks = <0x0>;
		xlnx,ext-reset-high = <0x1>;
		xlnx,fsl-depth = <0x10>;
		xlnx,fsl-dwidth = <0x20>;
		xlnx,impl-style = <0x0>;
		xlnx,read-clock-period = <0x0>;
		xlnx,use-control = <0x1>;
	} ;

....

/* simple ip - one input and one output + parameters and interrupt */

	axi_stream_test_0: axi-stream-test-0@0 {
		MFSL = <&fsl_v20_3>;
		SFSL = <&fsl_v20_2>;
		interrupt-parent = <&microblaze_0_intc>;
		interrupts = < 3 2 >;
		xlnx,use-rexa = <0x0>;
		xlnx,use-rexam = <0x2>;
		xlnx,use-rexample = <0x4>;
	} ;
...
/* IP with two inputs and one output */
	multiinput_dev_0: multiinput-dev-0@0 {
		MFSL0 = <&fsl_v20_11>;
		SFSL0 = <&fsl_v20_12>;
		SFSL1 = <&fsl_v20_13>;
		xlnx,use-exa = <0x0>;
		xlnx,use-exam = <0x2>;
		xlnx,use-example = <0x4>;
	} ;

/* IP with two inputs and two outputs */

	multiport_fsl_0: multiport-fsl-0@0 {
		MFSL0 = <&fsl_v20_8>;
		MFSL1 = <&fsl_v20_5>;
		SFSL0 = <&fsl_v20_7>;
		SFSL1 = <&fsl_v20_6>;
		xlnx,use-test = <0x3>;
	} ;

/* the rest of IP connected to axi */

	axi4lite_0: axi@0 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "xlnx,axi-interconnect-1.03.a", "simple-bus";
		ranges ;
...
		microblaze_0_intc: interrupt-controller@41200000 {
			#interrupt-cells = <0x2>;
			compatible = "xlnx,axi-intc-1.01.a";
			interrupt-controller ;
			reg = < 0x41200000 0x10000 >;
			xlnx,kind-of-intr = <0x144>;
			xlnx,num-intr-inputs = <0xc>;
		} ;
	} ;
} ;
Signature · 4 lines
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#2 lore raw

Any comments on this?

Michal

Quoted 147 lines · Michal Simek

Hi,

I would like to check with you proper device tree FSL description for Microblaze (PPC can use FSL through IP connected to the bus).

Microblaze supports FSL buses to connect coprocessors or hw accelerators directly to the cpu. Cpu has up to 16 fsl bus connections - master and slave side. (BTW: in the latest Microblaze with AXI is possible to use AXI stream instead of FSL but description should be the same), FSL bus has one master and in most cases one slave (more point-to-point connection than bus) but I think there could be an option to have multiple slaves for cases where the same input data goes to n-slaves.
There is also an option to generate interrupt if there is any data on the bus.

FSL devices can have multiple FSL inputs and outputs and they also can generate interrupts.

There is also one option to have only loopback which means connect CPU FSL master to CPU FSL slave with optional interrupt enabling.

I am also aware of one more option which is possibility to use a bridge instead of CPU (this option is not shown below).

Currently I have changed our generator to have the first description which I would like to use for our discussion.

Below is the important part which I would like to discuss - it is fake hw design but illustrate some important cases.

Here are some my notes:
1. I can't add FSL device directly to the CPU node because connection could be from axi IP. And I need to separate interrupt generation if there is any activity on a bus. That's why I separate fsl bus and devices out of CPU.
2. I think that shouldn't be a problem to have fsl buses in the root node
3. I think fsl devices should be moved out of root node but the point is where.
It is not bus sub/node because device can be connected to several buses. There could be a lot of connections. Any suggestions?
4. Please let me know if there should be any cells properties or similar.
5. There is not any address on the bus. FSL devices has some registers.
6. Should I use different address than 0 for connection from cpu? mfsl@5 instead of mfsl5@0?

Thanks,
Michal

/dts-v1/;

/ {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "xlnx,microblaze";
    model = "axi-loopback";

/* cpu node */

    cpus {
        #address-cells = <1>;
        #cpus = <0x1>;
        #size-cells = <0>;
        microblaze_0: cpu@0 {
... /* some cpu parameters */
            xlnx,use-stack-protection = <0x0>;

        /* fsl_m -> master side, fsl_s -> slave side */
            fsl_m_0: mfsl0@0 {
                link = <&fsl_v20_2>; /* bus connection */
            } ;
...
            fsl_m_5: mfsl5@0 {
                link = <&fsl_v20_9>;
            } ;
            fsl_s_0: sfsl0@0 {
                link = <&fsl_v20_1>;
            } ;
...
            fsl_s_5: sfsl5@0 {
                link = <&fsl_v20_10>;
            } ;
        } ;
    } ;

/* FSL buses - all look the same that's why I keep here only two - I expect you will beat me for simple-bus compatible property. */ /* The first where all interrupts are connected */

    fsl_v20_0: fsl-v20-0@0 {
        compatible = "xlnx,fsl-v1.00.a", "simple-bus";
        interrupt-parent = <&microblaze_0_intc>;
        interrupts = < 11 2 4 2 10 2 >;
        xlnx,async-clks = <0x0>;
        xlnx,ext-reset-high = <0x1>;
        xlnx,fsl-depth = <0x10>;
        xlnx,fsl-dwidth = <0x20>;
        xlnx,impl-style = <0x0>;
        xlnx,read-clock-period = <0x0>;
        xlnx,use-control = <0x1>;
    } ;
/* bus without interrupts */
    fsl_v20_10: fsl-v20-10@0 {
        compatible = "xlnx,fsl-v1.00.a", "simple-bus";
        xlnx,async-clks = <0x0>;
        xlnx,ext-reset-high = <0x1>;
        xlnx,fsl-depth = <0x10>;
        xlnx,fsl-dwidth = <0x20>;
        xlnx,impl-style = <0x0>;
        xlnx,read-clock-period = <0x0>;
        xlnx,use-control = <0x1>;
    } ;

....

/* simple ip - one input and one output + parameters and interrupt */

    axi_stream_test_0: axi-stream-test-0@0 {
        MFSL = <&fsl_v20_3>;
        SFSL = <&fsl_v20_2>;
        interrupt-parent = <&microblaze_0_intc>;
        interrupts = < 3 2 >;
        xlnx,use-rexa = <0x0>;
        xlnx,use-rexam = <0x2>;
        xlnx,use-rexample = <0x4>;
    } ;
...
/* IP with two inputs and one output */
    multiinput_dev_0: multiinput-dev-0@0 {
        MFSL0 = <&fsl_v20_11>;
        SFSL0 = <&fsl_v20_12>;
        SFSL1 = <&fsl_v20_13>;
        xlnx,use-exa = <0x0>;
        xlnx,use-exam = <0x2>;
        xlnx,use-example = <0x4>;
    } ;

/* IP with two inputs and two outputs */

    multiport_fsl_0: multiport-fsl-0@0 {
        MFSL0 = <&fsl_v20_8>;
        MFSL1 = <&fsl_v20_5>;
        SFSL0 = <&fsl_v20_7>;
        SFSL1 = <&fsl_v20_6>;
        xlnx,use-test = <0x3>;
    } ;

/* the rest of IP connected to axi */

    axi4lite_0: axi@0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "xlnx,axi-interconnect-1.03.a", "simple-bus";
        ranges ;
...
        microblaze_0_intc: interrupt-controller@41200000 {
            #interrupt-cells = <0x2>;
            compatible = "xlnx,axi-intc-1.01.a";
            interrupt-controller ;
            reg = < 0x41200000 0x10000 >;
            xlnx,kind-of-intr = <0x144>;
            xlnx,num-intr-inputs = <0xc>;
        } ;
    } ;
} ;
Signature · 4 lines
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 1 line · Michal Simek

Any comments on this?

Sorry I didn't comment, but this is the first I've seen it. I missed it the first time around.

It's hard to provide any useful comments on this. I have no idea what FSL devices are.

g.

Quoted 179 lines

Michal

Quoted 154 lines · Michal Simek

Hi,

I would like to check with you proper device tree FSL description for Microblaze (PPC can use FSL through IP connected to the bus).

Microblaze supports FSL buses to connect coprocessors or hw accelerators directly to the cpu. Cpu has up to 16 fsl bus connections - master and slave side. (BTW: in the latest Microblaze with AXI is possible to use AXI stream instead of FSL but description should be the same),
FSL bus has one master and in most cases one slave (more point-to-point connection than bus) but I think there could be an option to have multiple slaves for cases where the same input data goes to n-slaves. There is also an option to generate interrupt if there is any data on the bus.

FSL devices can have multiple FSL inputs and outputs and they also can generate interrupts.

There is also one option to have only loopback which means connect CPU FSL master to CPU FSL slave with optional interrupt enabling.

I am also aware of one more option which is possibility to use a bridge instead of CPU (this option is not shown below).

Currently I have changed our generator to have the first description which I would like to use for our discussion.

Below is the important part which I would like to discuss - it is fake hw design but illustrate some important cases.

Here are some my notes:
1. I can't add FSL device directly to the CPU node because connection could be from axi IP. And I need to separate interrupt generation if there is any activity on a bus. That's why I separate fsl bus and devices out of CPU.
2. I think that shouldn't be a problem to have fsl buses in the root node
3. I think fsl devices should be moved out of root node but the point is where.
It is not bus sub/node because device can be connected to several buses. There could be a lot of connections. Any suggestions?
4. Please let me know if there should be any cells properties or similar.
5. There is not any address on the bus. FSL devices has some registers.
6. Should I use different address than 0 for connection from cpu? mfsl@5 instead of mfsl5@0?

Thanks,
Michal

/dts-v1/;
/ {
   #address-cells = <1>;
   #size-cells = <1>;
   compatible = "xlnx,microblaze";
   model = "axi-loopback";

/* cpu node */
   cpus {
       #address-cells = <1>;
       #cpus = <0x1>;
       #size-cells = <0>;
       microblaze_0: cpu@0 {
... /* some cpu parameters */
           xlnx,use-stack-protection = <0x0>;

       /* fsl_m -> master side, fsl_s -> slave side */
           fsl_m_0: mfsl0@0 {
               link = <&fsl_v20_2>; /* bus connection */ } ;
...
           fsl_m_5: mfsl5@0 {
               link = <&fsl_v20_9>;
           } ;
           fsl_s_0: sfsl0@0 {
               link = <&fsl_v20_1>;
           } ;
...
           fsl_s_5: sfsl5@0 {
               link = <&fsl_v20_10>;
           } ;
       } ;
   } ;

/* FSL buses - all look the same that's why I keep here only two - I expect you will beat me for simple-bus compatible property.  */ /* The first where all interrupts are connected */
   fsl_v20_0: fsl-v20-0@0 {
       compatible = "xlnx,fsl-v1.00.a", "simple-bus"; interrupt-parent = <&microblaze_0_intc>; interrupts = < 11 2 4 2 10 2 >;
       xlnx,async-clks = <0x0>;
       xlnx,ext-reset-high = <0x1>;
       xlnx,fsl-depth = <0x10>;
       xlnx,fsl-dwidth = <0x20>;
       xlnx,impl-style = <0x0>;
       xlnx,read-clock-period = <0x0>;
       xlnx,use-control = <0x1>;
   } ;
/* bus without interrupts */
   fsl_v20_10: fsl-v20-10@0 {
       compatible = "xlnx,fsl-v1.00.a", "simple-bus"; xlnx,async-clks = <0x0>;
       xlnx,ext-reset-high = <0x1>;
       xlnx,fsl-depth = <0x10>;
       xlnx,fsl-dwidth = <0x20>;
       xlnx,impl-style = <0x0>;
       xlnx,read-clock-period = <0x0>;
       xlnx,use-control = <0x1>;
   } ;

....

/* simple ip - one input and one output + parameters and interrupt */
   axi_stream_test_0: axi-stream-test-0@0 {
       MFSL = <&fsl_v20_3>;
       SFSL = <&fsl_v20_2>;
       interrupt-parent = <&microblaze_0_intc>;
       interrupts = < 3 2 >;
       xlnx,use-rexa = <0x0>;
       xlnx,use-rexam = <0x2>;
       xlnx,use-rexample = <0x4>;
   } ;
...
/* IP with two inputs and one output */
   multiinput_dev_0: multiinput-dev-0@0 {
       MFSL0 = <&fsl_v20_11>;
       SFSL0 = <&fsl_v20_12>;
       SFSL1 = <&fsl_v20_13>;
       xlnx,use-exa = <0x0>;
       xlnx,use-exam = <0x2>;
       xlnx,use-example = <0x4>;
   } ;

/* IP with two inputs and two outputs */
   multiport_fsl_0: multiport-fsl-0@0 {
       MFSL0 = <&fsl_v20_8>;
       MFSL1 = <&fsl_v20_5>;
       SFSL0 = <&fsl_v20_7>;
       SFSL1 = <&fsl_v20_6>;
       xlnx,use-test = <0x3>;
   } ;

/* the rest of IP connected to axi */
   axi4lite_0: axi@0 {
       #address-cells = <1>;
       #size-cells = <1>;
       compatible = "xlnx,axi-interconnect-1.03.a", "simple-bus"; ranges ;
...
       microblaze_0_intc: interrupt-controller@41200000 { #interrupt-cells = <0x2>;

Quoted 13 lines

           compatible = "xlnx,axi-intc-1.01.a";
           interrupt-controller ;
           reg = < 0x41200000 0x10000 >;
           xlnx,kind-of-intr = <0x144>;
           xlnx,num-intr-inputs = <0xc>;
       } ;
   } ;
} ;

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Signature · 2 lines
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

A message that is not in the archive (sent off-list or not yet received): CACxGe6tVGa4H8-Bep89-wNQzR11bFeJ6dS3S18sYN=g0_1r+tw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

#6 lore raw
Quoted 9 lines · Grant Likely
Quoted 1 line · Michal Simek

Any comments on this?

Sorry I didn't comment, but this is the first I've seen it. I missed it the first time around.

It's hard to provide any useful comments on this. I have no idea what FSL devices are.

FSL is a point-to-point FIFO bus architecture. MicroBlaze has native ports on the CPU that allow direct connection to up to 16 master / slave pairs of these buses.

It's equivalent in some senses to the AXI streaming protocol - indeed newer MicroBlaze versions can talk AXI stream, and it will also have a role in the Zynq architecture.

FSL / AXI stream is a bit wierd from a device tree point of view - they are point to point, unidirectional buses - FIFOs basically. Completely different from your standard shared SoC bus.

We are looking for a good way to express this topology in the device tree. It is important to get this right - FSL and AXI stream will be an increasingly important way of connecting coprocessors and devices within Xilinx MicroBlaze and Zynq systems. We'd like to get consensus now rather than finding opposition 6-12 months from now when we try to push stuff that we've already shipped.

Thanks,

John

Signature · 3 lines
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss

#7 lore raw
In reply to a message not in the archive
Quoted 31 lines · Michal Simek

Hi,

I would like to check with you proper device tree FSL description for Microblaze (PPC can use FSL through IP connected to the bus).

Microblaze supports FSL buses to connect coprocessors or hw accelerators directly to the cpu. Cpu has up to 16 fsl bus connections - master and slave side. (BTW: in the latest Microblaze with AXI is possible to use AXI stream instead of FSL but description should be the same),
FSL bus has one master and in most cases one slave (more point-to-point connection than bus) but I think there could be an option to have multiple slaves for cases where the same input data goes to n-slaves.
There is also an option to generate interrupt if there is any data on the bus.

FSL devices can have multiple FSL inputs and outputs and they also can generate interrupts.

There is also one option to have only loopback which means connect CPU FSL master to CPU FSL slave with optional interrupt enabling.

I am also aware of one more option which is possibility to use a bridge instead of CPU (this option is not shown below).

Currently I have changed our generator to have the first description which I would like to use for our discussion.

Below is the important part which I would like to discuss - it is fake hw design but illustrate some important cases.

Quoted 9 lines

Here are some my notes:
1. I can't add FSL device directly to the CPU node because connection could be from axi IP. And I need to separate interrupt generation if there is any activity on a bus. That's why I separate fsl bus and devices out of CPU.
2. I think that shouldn't be a problem to have fsl buses in the root node
3. I think fsl devices should be moved out of root node but the point is where. It is not bus sub/node because device can be connected to several buses. There could be a lot of connections. Any suggestions?

As mentioned below, you can create a node to collect them into. It doesn't have to be a memory mapped device node.

Quoted 1 line

4. Please let me know if there should be any cells properties or similar.

That's up to you. I don't really understand the architecture being described, so I'm not a good person to say. :-)

Quoted 43 lines

5. There is not any address on the bus. FSL devices has some registers.
6. Should I use different address than 0 for connection from cpu? mfsl@5 instead of mfsl5@0?

Thanks,
Michal

/dts-v1/;

/ {
	#address-cells = <1>;
	#size-cells = <1>;
	compatible = "xlnx,microblaze";
	model = "axi-loopback";

/* cpu node */

	cpus {
		#address-cells = <1>;
		#cpus = <0x1>;
		#size-cells = <0>;
		microblaze_0: cpu@0 {
... /* some cpu parameters */
			xlnx,use-stack-protection = <0x0>;

		/* fsl_m -> master side, fsl_s -> slave side */
			fsl_m_0: mfsl0@0 {
				link = <&fsl_v20_2>; /* bus connection */
			} ;
...
			fsl_m_5: mfsl5@0 {
				link = <&fsl_v20_9>;
			} ;
			fsl_s_0: sfsl0@0 {
				link = <&fsl_v20_1>;
			} ;
...
			fsl_s_5: sfsl5@0 {
				link = <&fsl_v20_10>;
			} ;
		} ;
	} ;
Quoted 5 lines

/* FSL buses - all look the same that's why I keep here only two - I expect you will beat me for simple-bus compatible property. */ /* The first where all interrupts are connected */

	fsl_v20_0: fsl-v20-0@0 {
		compatible = "xlnx,fsl-v1.00.a", "simple-bus";

Heh, yeah you're right. simple-bus doesn't make sense when this isn't a memory mapped bus, and there are no child nodes :-)

I think that if you don't want these nodes under the cpu (which is probably the right decision), then it would be best to collect these nodes in a container node of some kind.

Quoted 25 lines
		interrupt-parent = <&microblaze_0_intc>;
		interrupts = < 11 2 4 2 10 2 >;
		xlnx,async-clks = <0x0>;
		xlnx,ext-reset-high = <0x1>;
		xlnx,fsl-depth = <0x10>;
		xlnx,fsl-dwidth = <0x20>;
		xlnx,impl-style = <0x0>;
		xlnx,read-clock-period = <0x0>;
		xlnx,use-control = <0x1>;
	} ;
/* bus without interrupts */
	fsl_v20_10: fsl-v20-10@0 {
		compatible = "xlnx,fsl-v1.00.a", "simple-bus";
		xlnx,async-clks = <0x0>;
		xlnx,ext-reset-high = <0x1>;
		xlnx,fsl-depth = <0x10>;
		xlnx,fsl-dwidth = <0x20>;
		xlnx,impl-style = <0x0>;
		xlnx,read-clock-period = <0x0>;
		xlnx,use-control = <0x1>;
	} ;

....

/* simple ip - one input and one output + parameters and interrupt */

Quoted 9 lines
	axi_stream_test_0: axi-stream-test-0@0 {
		MFSL = <&fsl_v20_3>;
		SFSL = <&fsl_v20_2>;
		interrupt-parent = <&microblaze_0_intc>;
		interrupts = < 3 2 >;
		xlnx,use-rexa = <0x0>;
		xlnx,use-rexam = <0x2>;
		xlnx,use-rexample = <0x4>;
	} ;

Yeah, I'm really lost since I don't understand the hardware. It would be helpful to have a binding document describing the properties being used.

Quoted 48 lines

...
/* IP with two inputs and one output */

	multiinput_dev_0: multiinput-dev-0@0 {
		MFSL0 = <&fsl_v20_11>;
		SFSL0 = <&fsl_v20_12>;
		SFSL1 = <&fsl_v20_13>;
		xlnx,use-exa = <0x0>;
		xlnx,use-exam = <0x2>;
		xlnx,use-example = <0x4>;
	} ;

/* IP with two inputs and two outputs */

	multiport_fsl_0: multiport-fsl-0@0 {
		MFSL0 = <&fsl_v20_8>;
		MFSL1 = <&fsl_v20_5>;
		SFSL0 = <&fsl_v20_7>;
		SFSL1 = <&fsl_v20_6>;
		xlnx,use-test = <0x3>;
	} ;

/* the rest of IP connected to axi */

	axi4lite_0: axi@0 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "xlnx,axi-interconnect-1.03.a", "simple-bus";
		ranges ;
...
		microblaze_0_intc: interrupt-controller@41200000 {
			#interrupt-cells = <0x2>;
			compatible = "xlnx,axi-intc-1.01.a";
			interrupt-controller ;
			reg = < 0x41200000 0x10000 >;
			xlnx,kind-of-intr = <0x144>;
			xlnx,num-intr-inputs = <0xc>;
		} ;
	} ;
} ;
Signature · 4 lines
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian