Xilinx EDK BSP generation of device trees for microblaze and PowerPC

Stephen Neuendorffer stephen.neuendorffer at xilinx.com
Sun Nov 25 17:24:55 EST 2007


Here's what I've gotten so far:

		Hard_Ethernet_MAC: xps-ll-temac at 81c00000 {
			#address-cells = <1>;
			#size-cells = <1>;
			network at 81c00000 {
				compatible = "xlnx,xps-ll-temac-1.00.a", "xlnx,xps-ll-temac";
				interrupt-parent = <&xps_intc_0>;
				interrupts = < 3 0 >;
				llink-connected = <&PIM3>;
				reg = < 81c00000 40 >;
				xlnx,bus2core-clk-ratio = <1>;
				xlnx,phy-type = <1>;
				xlnx,phyaddr = <1>;
				xlnx,rxcsum = <0>;
				xlnx,rxfifo = <1000>;
				xlnx,temac-type = <0>;
				xlnx,txcsum = <0>;
				xlnx,txfifo = <1000>;
			} ;
		} ;
		mpmc at 90000000 {
			#address-cells = <1>;
			#size-cells = <1>;
			compatible = "xlnx,mpmc-3.00.a", "xlnx,mpmc";
			PIM3: sdma at 84600180 {
				compatible = "xlnx,ll-dma-1.00a", "xlnx,ll-dma";
				interrupt-parent = <&xps_intc_0>;
				interrupts = < 1 0 0 0 >;
				reg = < 84600180 80 >;
			} ;
		} ;
	DDR2_SDRAM: memory at 90000000 {
		device_type = "memory";
		reg = < 90000000 10000000 >;
	} ;

So: the mpmc generates a 'memory' node, corresponding to it's memory interface.  It also gets a separate entry which contains the (optional, not present in this example) slave management interface (for ECC and performance information), and any sdma ports.  In this case, this node is mpmc at 90000000, because there is no management interface.  If a management interface was present, then it would be @ the management address.
The mpmc gets a compatible string that describes its management interface.
The sdma port has information about the tx and rx interrupts and the slave management interface.  Note that the slave management interface has the correct baseaddress for port3, generated from the base SDMA_CTRL_ address from the mpmc + the port 3 offset.  Note that sdma has an artificial compatible name.  I'm not sure whether the ll_dma driver can be easily convinced to bind to this, or whether the ll_temac driver will just traverse the device tree and then do a match against this.

The temac works similarly, although the temac itself doesn't have a slave interface, so no compatible node for it.  The sub nodes get the compatible string for the ll_temac driver.  In this case, there is only one temac port active.  Some of the parameters are specific to port 0, in which case the parameter names (e.g. phyaddr) are generated by stripping off the complete C_TEMAC0 prefix.  Other parameters (e.g. phy-type) are common to both sub nodes, but are duplicated to make it easier for the driver to get the information out.  At runtime, the driver has to follow the llink-connected path to find what it is connected to, and use the dma code, or the fifo code.

the xps-ll-fifo structure is a bit simpler, with llink-connected pointing to the fifo, which looks like a 'normal' peripheral.

Points for comment:
1) I don't like the "PIM3" label, which is artificial (i.e. it doesn't correspond to a name in the .mhs) and not guaranteed to be unique.  However, in the BSP generator it seems awkward to generate path references easily in a single pass.  What I'd might prefer is:
		DDR2_SDRAM: mpmc at 90000000 {
			sdma at 3 {

and refer to the sdma port using something like <&DDR2_SDRAM/sdma at 3>, but I don't think you can do that in dtc?

2) Not sure whether this is really simpler than just having a 'simple' node with both temacs and letting the driver sort everything out.  In particular, I'm concerned about maintaining a bunch of semantic information about the ll_temac driver outside of the driver itself.

3) All of this is very different in structure from the way that the xparameters are organized.  The ll_temac BSP code copies the xparameters out of the MPMC and they are simply other parameters of the ll_temac driver.  Although the above structure better represents the actual system, there is another organization for people to be confused about.

Steve

-----Original Message-----
From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com at ozlabs.org on behalf of Stephen Neuendorffer
Sent: Tue 11/20/2007 11:44 AM
To: microblaze-uclinux at itee.uq.edu.au; linuxppc-dev at ozlabs.org; Grant Likely; Michal Simek
Subject: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
 

	
I've updated some code from Michel Simek to generate Flat Device Trees
from Xilinx EDK projects.  This code is now hosted at:
git://git.xilinx.com/gen-mhs-devtree.git

This has one major advantage over the gen-mhs-devtree.py approach:
default IP core parameters that are not specified in the mhs file can
now be generated, since EDK pulls these in from the core .mpd file.
I've also managed to incorporate a few more improvements from the
previous review, so the BSP generator should include at least as much
information as gen-mhs-devtree.py

The next major order of business is to represent the DMA engines in the
MPMC and locallink connections to the lltemac.

Steve

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20071124/f465c446/attachment.htm>


More information about the Linuxppc-dev mailing list