@@ -52,6 +52,7 @@ Table of Contents i) Freescale QUICC Engine module (QE) j) CFI or JEDEC memory-mapped NOR flash k) Global Utilities Block+ l) Xilinx IP cores VII - Specifying interrupt information for devices 1) interrupts property
@@ -2242,6 +2243,269 @@ platforms are moved over to use the flattened-device-tree model. available. For Axon: 0x0000012a+ l) Xilinx IP cores++ The Xilinx EDK toolchain ships with a set of IP cores (devices) for use+ in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range+ of standard device types (network, serial, etc.) and miscellanious+ devices (gpio, LCD, spi, etc). Also, since these devices are+ implemented within the fpga fabric every instance of the device can be+ synthesised with different options that change the behaviour.++ Each IP-core has a set of parameters which the FPGA designer can use to+ control how the core is synthesized. Historically, the EDK tool would+ extract the device parameters relevant to device drivers and copy them+ into an 'xparameters.h' in the form of #define symbols. This tells the+ device drivers how the IP cores are configured, but it requres the kernel+ to be recompiled every time the FPGA bitstream is resynthesized.++ The new approach is to export the parameters into the device tree and+ generate a new device tree each time the FPGA bitstream changes. The+ parameters which used to be exported as #defines will now become+ properties of the device node. In general, device nodes for IP-cores+ will take the following form:++ (name)@(base-address) {+ compatible = "xilinx,(ip-core-name)-(HW_VER)"+ [, (list of compatible devices), ...];+ reg = <(baseaddr) (size)>;+ interrupt-parent = <&interrupt-controller-phandle>;+ interrupts = < ... >;+ xilinx,(parameter1) = "(string-value)";+ xilinx,(parameter2) = <(int-value)>;+ };++ (ip-core-name): the name of the ip block (given after the BEGIN+ directive in system.mhs). Should be in lowercase+ and all underscores '_' converted to dashes '-'.+ (name): is derived from the "PARAMETER INSTANCE" value.+ (parameter#): C_* parameters from system.mhs. The C_ prefix is+ dropped from the parameter name, the name is converted+ to lowercase and all underscore '_' characters are+ converted to dashes '-'.+ (baseaddr): the C_BASEADDR parameter.+ (HW_VER): from the HW_VER parameter.+ (size): equals C_HIGHADDR - C_BASEADDR + 1++ Typically, the compatible list will include the exact IP core version+ followed by an older IP core version which implements the same+ interface or any other device with the same interface.++ 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.++ For example, the following block from system.mhs:++ BEGIN opb_uartlite+ PARAMETER INSTANCE = opb_uartlite_0+ PARAMETER HW_VER = 1.00.b+ PARAMETER C_BAUDRATE = 115200+ PARAMETER C_DATA_BITS = 8+ PARAMETER C_ODD_PARITY = 0+ PARAMETER C_USE_PARITY = 0+ PARAMETER C_CLK_FREQ = 50000000+ PARAMETER C_BASEADDR = 0xEC100000+ PARAMETER C_HIGHADDR = 0xEC10FFFF+ BUS_INTERFACE SOPB = opb_7+ PORT OPB_Clk = CLK_50MHz+ PORT Interrupt = opb_uartlite_0_Interrupt+ PORT RX = opb_uartlite_0_RX+ PORT TX = opb_uartlite_0_TX+ PORT OPB_Rst = sys_bus_reset_0+ END++ becomes the following device tree node:++ opb-uartlite-0@ec100000 {+ device_type = "serial";+ compatible = "xilinx,opb-uartlite-1.00.b";+ reg = <ec100000 10000>;+ interrupt-parent = <&opb-intc>;+ interrupts = <1 0>; // got this from the opb_intc parameters+ current-speed = <d#115200>; // standard serial device prop+ clock-frequency = <d#50000000>; // standard serial device prop+ xilinx,data-bits = <8>;+ xilinx,odd-parity = <0>;+ xilinx,use-parity = <0>;+ };++ Some IP cores actually implement 2 or more logical devices. In this case,+ the device should still describe the whole IP core with a single node+ and add a child node for each logical device. The ranges property can+ be used to translate from parent IP-core to the registers of each device.+ (Note: this makes the assumption that both logical devices have the same+ bus binding. If this is not true, then separate nodes should be used for+ each logical device). The 'cell-index' property can be used to enumerate+ logical devices within an IP core. For example, the following is the+ system.mhs entry for the dual ps2 controller found on the ml403 reference+ design.++ BEGIN opb_ps2_dual_ref+ PARAMETER INSTANCE = opb_ps2_dual_ref_0+ PARAMETER HW_VER = 1.00.a+ PARAMETER C_BASEADDR = 0xA9000000+ PARAMETER C_HIGHADDR = 0xA9001FFF+ BUS_INTERFACE SOPB = opb_v20_0+ PORT Sys_Intr1 = ps2_1_intr+ PORT Sys_Intr2 = ps2_2_intr+ PORT Clkin1 = ps2_clk_rx_1+ PORT Clkin2 = ps2_clk_rx_2+ PORT Clkpd1 = ps2_clk_tx_1+ PORT Clkpd2 = ps2_clk_tx_2+ PORT Rx1 = ps2_d_rx_1+ PORT Rx2 = ps2_d_rx_2+ PORT Txpd1 = ps2_d_tx_1+ PORT Txpd2 = ps2_d_tx_2+ END++ It would result in the following device tree nodes:++ opb_ps2_dual_ref_0@a9000000 {+ ranges = <0 a9000000 2000>;+ // If this device had extra parameters, then they would+ // go here.+ ps2@0 {+ compatible = "xilinx,opb-ps2-dual-ref-1.00.a";+ reg = <0 40>;+ interrupt-parent = <&opb-intc>;+ interrupts = <3 0>;+ cell-index = <0>;+ };+ ps2@1000 {+ compatible = "xilinx,opb-ps2-dual-ref-1.00.a";+ reg = <1000 40>;+ interrupt-parent = <&opb-intc>;+ interrupts = <3 0>;+ cell-index = <0>;+ };+ };++ Also, the system.mhs file defines bus attachments from the processor+ to the devices. The device tree structure should reflect the bus+ attachments. Again an example; this system.mhs fragment:++ BEGIN ppc405_virtex4+ PARAMETER INSTANCE = ppc405_0+ PARAMETER HW_VER = 1.01.a+ BUS_INTERFACE DPLB = plb_v34_0+ BUS_INTERFACE IPLB = plb_v34_0+ END++ BEGIN opb_intc+ PARAMETER INSTANCE = opb_intc_0+ PARAMETER HW_VER = 1.00.c+ PARAMETER C_BASEADDR = 0xD1000FC0+ PARAMETER C_HIGHADDR = 0xD1000FDF+ BUS_INTERFACE SOPB = opb_v20_0+ END++ BEGIN opb_uart16550+ PARAMETER INSTANCE = opb_uart16550_0+ PARAMETER HW_VER = 1.00.d+ PARAMETER C_BASEADDR = 0xa0000000+ PARAMETER C_HIGHADDR = 0xa0001FFF+ BUS_INTERFACE SOPB = opb_v20_0+ END++ BEGIN plb_v34+ PARAMETER INSTANCE = plb_v34_0+ PARAMETER HW_VER = 1.02.a+ END++ BEGIN plb_bram_if_cntlr+ PARAMETER INSTANCE = plb_bram_if_cntlr_0+ PARAMETER HW_VER = 1.00.b+ PARAMETER C_BASEADDR = 0xFFFF0000+ PARAMETER C_HIGHADDR = 0xFFFFFFFF+ BUS_INTERFACE SPLB = plb_v34_0+ END++ BEGIN plb2opb_bridge+ PARAMETER INSTANCE = plb2opb_bridge_0+ PARAMETER HW_VER = 1.01.a+ PARAMETER C_RNG0_BASEADDR = 0x20000000+ PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF+ PARAMETER C_RNG1_BASEADDR = 0x60000000+ PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF+ PARAMETER C_RNG2_BASEADDR = 0x80000000+ PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF+ PARAMETER C_RNG3_BASEADDR = 0xC0000000+ PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF+ BUS_INTERFACE SPLB = plb_v34_0+ BUS_INTERFACE MOPB = opb_v20_0+ END++ Gives this device tree (some properties removed for clarity):++ plb-v34-0 {+ #address-cells = <1>;+ #size-cells = <1>;+ device_type = "ibm,plb";+ ranges; // 1:1 translation++ plb-bram-if-cntrl-0@ffff0000 {+ reg = <ffff0000 10000>;+ }++ opb-v20-0 {+ #address-cells = <1>;+ #size-cells = <1>;+ ranges = <20000000 20000000 20000000+ 60000000 60000000 20000000+ 80000000 80000000 40000000+ c0000000 c0000000 20000000>;++ opb-uart16550-0@a0000000 {+ reg = <a00000000 2000>;+ };++ opb-intc-0@d1000fc0 {+ reg = <d1000fc0 20>;+ };+ };+ };++ That covers the general approach to binding xilinx IP cores into the+ device tree. The following are bindings for specific devices:++ i) Xilinx ML300 Framebuffer++ Simple framebuffer device from the ML300 reference design (also on the+ ML403 reference design as well as others).++ Optional properties:+ - resolution : <xres yres> pixel resolution of framebuffer. Some+ implementations use a different resolution. Default+ is <d#640 d#480>+ - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.+ Default is <d#1024 d#480>.+ - rotate-display (empty) : rotate display 180 degrees.++ ii) Xilinx SystemACE++ The Xilinx SystemACE device is used to program FPGAs from an FPGA+ bitstream stored on a CF card. It can also be used as a generic CF+ interface device.++ Required properties:+ - compatible : Should include "xilinx,sysace" in the list++ Optional properties:+ - 8-bit (empty) : Set this property for SystemACE in 8 bit mode++ iii) Xilinx EMAC and Xilinx TEMAC++ Xilinx Ethernet devices. In addition to general xilinx properties+ listed above, nodes for these devices should include a phy-handle+ property, and may include other common network device properties+ like local-mac-address.++ iv) Xilinx Uartlite++ Xilinx uartlite devices are simple fixed speed serial ports.++ Requred properties:+ - current-speed : Baud rate of uartlite+ More devices will be defined as this spec matures. VII - Specifying interrupt information for devices
From: Stephen Neuendorffer <hidden> Date: 2007-10-18 17:50:16
=20
-----Original Message-----
From: Grant Likely [mailto:grant.likely@secretlab.ca]=20
Sent: Thursday, October 18, 2007 10:23 AM
To: linuxppc-dev@ozlabs.org; Stephen Neuendorffer; Wolfgang=20
Reissnegger; Leonid; microblaze-uclinux@itee.uq.edu.au; Josh=20
Boyer; Arnd Bergmann
Subject: [PATCH v3] Device tree bindings for Xilinx devices
=20
From: Grant Likely <redacted>
=20
Signed-off-by: Grant Likely <redacted>
Acked-by: Stephen Neuendorffer <redacted>
This is good enough for the moment, and it reflects the best we can do
right now... But:
+ (parameter#): C_* parameters from system.mhs. The C_=20
prefix is
+ dropped from the parameter name, the=20
name is converted
+ to lowercase and all underscore '_'=20
characters are
+ converted to dashes '-'.
Unfortunately, xparameters don't follow this exactly, particularly for
the 'multiple logical devices' case... Maybe it's worth adding
something like: "For simple devices, the parameter name can be formed
by:"
In any event, this should essentially document what the mechanism for
generating the device trees actually does... Have you updated
gen_mhs_devtree.py to reflect all this?
+ Typically, the compatible list will include the exact IP=20
core version
+ followed by an older IP core version which implements the same
+ interface or any other device with the same interface.
This seems to be awkward, since it means that the tree *and* the driver
will likely have long lists of compatible types. In the driver, this is
hard to maintain, and in the device tree we don't have an easy way of
knowing exactly what is compatible and what isn't anyway... It seems
better to me to have the
compatible list include the exact type (e.g. xilinx,opb-uartlite-1.00.b)
and
a generic compatibility class (e.g. xilinx,uartlite), and for the
drivers
to essentially define the gross compatibility classes. Then the driver
only has an of_match with:
.compatible =3D "xilinx,uartlite"
Steve
From: Grant Likely <hidden> Date: 2007-10-18 18:12:50
On 10/18/07, Stephen Neuendorffer [off-list ref] wrote:
quoted
-----Original Message-----
From: Grant Likely [mailto:grant.likely@secretlab.ca]
Sent: Thursday, October 18, 2007 10:23 AM
To: linuxppc-dev@ozlabs.org; Stephen Neuendorffer; Wolfgang
Reissnegger; Leonid; microblaze-uclinux@itee.uq.edu.au; Josh
Boyer; Arnd Bergmann
Subject: [PATCH v3] Device tree bindings for Xilinx devices
From: Grant Likely <redacted>
Signed-off-by: Grant Likely <redacted>
Acked-by: Stephen Neuendorffer <redacted>
This is good enough for the moment, and it reflects the best we can do
right now... But:
quoted
+ (parameter#): C_* parameters from system.mhs. The C_
prefix is
+ dropped from the parameter name, the
name is converted
+ to lowercase and all underscore '_'
characters are
+ converted to dashes '-'.
Unfortunately, xparameters don't follow this exactly, particularly for
the 'multiple logical devices' case... Maybe it's worth adding
something like: "For simple devices, the parameter name can be formed
by:"
What specific parts of this are you concerned about? Examples?
In any event, this should essentially document what the mechanism for
generating the device trees actually does... Have you updated
gen_mhs_devtree.py to reflect all this?
No; I'm looking at this as a line in the sand that we can use as a
starting point and discuss the issues.
quoted
+ Typically, the compatible list will include the exact IP
core version
+ followed by an older IP core version which implements the same
+ interface or any other device with the same interface.
This seems to be awkward, since it means that the tree *and* the driver
will likely have long lists of compatible types. In the driver, this is
hard to maintain, and in the device tree we don't have an easy way of
knowing exactly what is compatible and what isn't anyway... It seems
better to me to have the
compatible list include the exact type (e.g. xilinx,opb-uartlite-1.00.b)
and
a generic compatibility class (e.g. xilinx,uartlite), and for the
drivers
to essentially define the gross compatibility classes. Then the driver
only has an of_match with:
.compatible = "xilinx,uartlite"
The problem with this is how do you define what "xilinx,uartlite" is?
For example; there have been 3 major versions of the plb_temac, and
IIRC v2 and v3 are *not* compatible. Which one is xilinx,temac?
However, this does not need to result in a long list. Basically, the
list should include the exact version of the device plus the first
version that implemented that interface. (hence it is "compatible"
with the earlier version of the device). If there are no prior
devices implementing the same device, then the compatible list has
exactly one instance. This document should probably include a list of
the well-known compatible values for each of the xilinx devices.
I used to try and come up with generic values for compatible, but it
just ends up causing problems in the long run. The concept of what is
generic changes over time, but a specific version is a known quantity.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
From: Stephen Neuendorffer <hidden> Date: 2007-10-18 19:06:20
=20
-----Original Message-----
From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
Behalf Of Grant Likely
Sent: Thursday, October 18, 2007 11:13 AM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;=20
microblaze-uclinux@itee.uq.edu.au; Josh Boyer; Arnd Bergmann
Subject: Re: [PATCH v3] Device tree bindings for Xilinx devices
=20
On 10/18/07, Stephen Neuendorffer=20
[off-list ref] wrote:
quoted
quoted
-----Original Message-----
From: Grant Likely [mailto:grant.likely@secretlab.ca]
Sent: Thursday, October 18, 2007 10:23 AM
To: linuxppc-dev@ozlabs.org; Stephen Neuendorffer; Wolfgang
Reissnegger; Leonid; microblaze-uclinux@itee.uq.edu.au; Josh
Boyer; Arnd Bergmann
Subject: [PATCH v3] Device tree bindings for Xilinx devices
From: Grant Likely <redacted>
Signed-off-by: Grant Likely <redacted>
Acked-by: Stephen Neuendorffer <redacted>
This is good enough for the moment, and it reflects the=20
best we can do
quoted
right now... But:
quoted
+ (parameter#): C_* parameters from system.mhs. The C_
prefix is
+ dropped from the parameter name, the
name is converted
+ to lowercase and all underscore '_'
characters are
+ converted to dashes '-'.
Unfortunately, xparameters don't follow this exactly,=20
particularly for
quoted
the 'multiple logical devices' case... Maybe it's worth adding
something like: "For simple devices, the parameter name can=20
be formed
quoted
by:"
=20
What specific parts of this are you concerned about? Examples?
Imagine if the ps2 adapter had a parameter "FOO" for each logical
device, In the core, one would be named C_PORT_0_FOO and another
C_PORT_1_FOO. But, of course, you would want the FOO parameters to be
unmangled in the correct way for each port (as your hierarchical example
shows, but without any parameters). In the xparameters, this unmangling
has been done, and the xparameters would look something like
XPAR_PS2_0_FOO and XPAR_PS2_1_FOO.
In other cases, xparameters for one core might be extracted from another
core that it is connected to, and in fact might reflect how the two are
connected. This is how some cores under development will work (in EDK
9.2).
In short, I think its better to think about this all relative to
xparameters, rather than relative to the .mhs file. In all current
cases, this is (I think) the same, but in the (very near future) it
won't be.
quoted
In any event, this should essentially document what the=20
mechanism for
quoted
generating the device trees actually does... Have you updated
gen_mhs_devtree.py to reflect all this?
=20
No; I'm looking at this as a line in the sand that we can use as a
starting point and discuss the issues.
OK... Well, as far as I'm concerned it looks good enough that we should
try it out... :) I'll hack up gen_mhs_devtree and see how far we get.
quoted
quoted
+ Typically, the compatible list will include the exact IP
core version
+ followed by an older IP core version which implements the same
+ interface or any other device with the same interface.
This seems to be awkward, since it means that the tree=20
*and* the driver
quoted
will likely have long lists of compatible types. In the=20
driver, this is
quoted
hard to maintain, and in the device tree we don't have an=20
easy way of
quoted
knowing exactly what is compatible and what isn't anyway...=20
It seems
quoted
better to me to have the
compatible list include the exact type (e.g.=20
xilinx,opb-uartlite-1.00.b)
quoted
and
a generic compatibility class (e.g. xilinx,uartlite), and for the
drivers
to essentially define the gross compatibility classes. =20
Then the driver
quoted
only has an of_match with:
.compatible =3D "xilinx,uartlite"
=20
The problem with this is how do you define what "xilinx,uartlite" is?
For example; there have been 3 major versions of the plb_temac, and
IIRC v2 and v3 are *not* compatible. Which one is xilinx,temac?
=20
However, this does not need to result in a long list. Basically, the
list should include the exact version of the device plus the first
version that implemented that interface. (hence it is "compatible"
with the earlier version of the device). If there are no prior
devices implementing the same device, then the compatible list has
exactly one instance. This document should probably include a list of
the well-known compatible values for each of the xilinx devices.
=20
I used to try and come up with generic values for compatible, but it
just ends up causing problems in the long run. The concept of what is
generic changes over time, but a specific version is a known quantity.
OK... I'll buy it... :) I missed the emphasis on the 'sparseness'...
And I agree about the versions being really canonical: we just need to
make sure that the actual versions that are critical get back in at some
point.
Steve
From: Michal Simek <hidden> Date: 2007-10-20 02:28:32
Hi Steve and all,
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
I think that is no good idea generate dts with all information.
Especially information about PVR - number 2 means - Full PVR and you can
obtain information directly from PVR. It is waste of memory space.
xilinx,pvr = <2>;
In my opinion will be better generate only parameters which you want not all.
That smells with unusable parameters.
Michal Simek
From: Grant Likely <hidden> Date: 2007-10-20 05:38:52
On 10/19/07, Stephen Neuendorffer [off-list ref] wrote:
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
Grant: Is this pretty what you intend?
Pretty close; comments below on how we still need to change gen_mhs_devtree.py
BTW, thanks for doing this.
Cheers,
g.
Not quite; the bus itself needs to be one level deeper. Compatible
here is refering to the platform itself, not the bus and so should be
the actual board name or something similar. Maybe something like:
"xlnx,ml403","xlnx,generic-virtex4";
All devices should be children or grandchildren of a 'plb' node.
model = "system.mhs";
Should be the model name of the board in the form "<mfg>,<model>". It
might be appropriate to also have a property which describes the
version of the FPGA build or some other way to identify where this
FPGA bitstream came from. I'll need to think about this some more.
Yes; this is the idea; but I don't like "xilinx,opb-ethernet". I
think we should always specify specific versions and not try to guess
what the 'generic' device compatible interface is.
Also, dtc now accepts the form "string1","string2". the embedded '\0'
is no longer needed.
device_type = "opb_ethernet";
device_type = "network";
interrupt-parent = <101>;
interrupt-parent = <&opb_intc0>; (and a label needs to be added to
the interrupt node).
I got a comment from one of the ppc folks that we should use the stock
ticker abbreviation 'xlnx,' here instead of 'xilinx,'
} ;
IIC_EEPROM {
Node name needs to be unique. Convention is to use the form
device@address. We could either use the instance name or the IP core
name here; I'm not sure which is best.
From: Grant Likely <hidden> Date: 2007-10-20 05:47:30
On 10/19/07, Michal Simek [off-list ref] wrote:
Hi Steve and all,
quoted
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
I think that is no good idea generate dts with all information.
Especially information about PVR - number 2 means - Full PVR and you can
obtain information directly from PVR. It is waste of memory space.
xilinx,pvr = <2>;
In my opinion will be better generate only parameters which you want not all.
That smells with unusable parameters.
That is the hard part about crafting the dts; deciding which
parameters the OS is going to care about and which ones are
irrelevant. The goal is to sufficiently and uniquely describe the
board so that the OS can easily figure out what exactly what it needs
to do to drive the board, but not to try and describe every aspect
which it knows about. Anything that is pollable (ie. USB devices)
doesn't need to be in the tree.
It's also important to remember that the device tree will *never* be
perfect. Eventually something will come up that the device tree
doesn't describe well(a bug/quirk, something described poorly, etc).
In this case, as long as the device tree is specific enough to
identify which version of the board it is running on; we can alwasy
add platform specific fixups for that unique system.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
From: Michal Simek <hidden> Date: 2007-10-20 07:05:57
Hi Grant,
quoted
Hi Steve and all,
quoted
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
I think that is no good idea generate dts with all information.
Especially information about PVR - number 2 means - Full PVR and you can
obtain information directly from PVR. It is waste of memory space.
xilinx,pvr = <2>;
In my opinion will be better generate only parameters which you want not all.
That smells with unusable parameters.
That is the hard part about crafting the dts; deciding which
parameters the OS is going to care about and which ones are
irrelevant. The goal is to sufficiently and uniquely describe the
board so that the OS can easily figure out what exactly what it needs
to do to drive the board, but not to try and describe every aspect
which it knows about. Anything that is pollable (ie. USB devices)
doesn't need to be in the tree.
It's also important to remember that the device tree will *never* be
perfect. Eventually something will come up that the device tree
doesn't describe well(a bug/quirk, something described poorly, etc).
In this case, as long as the device tree is specific enough to
identify which version of the board it is running on; we can alwasy
add platform specific fixups for that unique system.
yes, but I think that is the right time to specify which parameters are relevant.
I will focus on in EDK renerator.
Michal Simek
From: David Gibson <hidden> Date: 2007-10-22 00:29:00
On Fri, Oct 19, 2007 at 04:42:58PM -0700, Stephen Neuendorffer wrote:
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
Grant: Is this pretty what you intend?
Steve
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "ibm,plb4";
model = "system.mhs";
Although strictly speaking the root node can represent the top-level
system bus, to match the other 4xx chips it would be beter, as Grant
says, to make a /plb node and put the devices under that.
Ethernet_MAC {
Node names should be lower case, and must include a unit address
derived from the reg property. Furthermore, the generic names
convention means this should be called just "ethernet@...".
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Stephen Neuendorffer <hidden> Date: 2007-10-22 18:07:06
-----Original Message-----
From: owner-microblaze-uclinux@itee.uq.edu.au=20
[mailto:owner-microblaze-uclinux@itee.uq.edu.au] On Behalf Of=20
Michal Simek
Sent: Friday, October 19, 2007 7:28 PM
To: microblaze-uclinux@itee.uq.edu.au
Cc: Stephen Neuendorffer; Grant Likely; Leonid; Arnd=20
Bergmann; linuxppc-dev@ozlabs.org; Wolfgang Reissnegger
Subject: [microblaze-uclinux] Re: [microblaze-uclinux] RE:=20
[PATCH v3] Device tree bindings for Xilinx devices
=20
Hi Steve and all,
quoted
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
=20
I think that is no good idea generate dts with all information.
Especially information about PVR - number 2 means - Full PVR=20
and you can
obtain information directly from PVR. It is waste of memory space.
xilinx,pvr =3D <2>;
PowerPC does something with the powerpc equivalent of the PVR.
We should just do what they do...
=20
In my opinion will be better generate only parameters which=20
you want not all.
That smells with unusable parameters.
In the long term, this may be true. In the short term:
1) dtb size is not the key problem
2) making sure that everything works is a key problem.
3) The code that generates the dts should be as simple as possible,
so that we can easily document what it does.
In the long term, I'm all for optimizing the device tree that gets
built,
assuming that it appears to be a problem in real systems.
Steve
From: Michal Simek <hidden> Date: 2007-10-23 04:07:59
quoted
In my opinion will be better generate only parameters which
you want not all.
That smells with unusable parameters.
In the long term, this may be true. In the short term:
1) dtb size is not the key problem
Yes of course
2) making sure that everything works is a key problem.
3) The code that generates the dts should be as simple as possible,
so that we can easily document what it does.
Yes but you must document every parameter which your generate do. The better way is
document only parameters which you want use.
In the long term, I'm all for optimizing the device tree that gets
built,
assuming that it appears to be a problem in real systems.
We can optimize now. I made new version of my generator u-boot_v3_00_a (monstr.eu)
where you can simply add parameter which you want to use.
If you want use any parameter add it.
For microblaze cpu - line 1184.
And for others peripherals lines 926-980. (The last parameter of function call).
Which parameters do you want for PPC405, Grant?
Regards,
Michal Simek
This is example of generator.
/ {
model = "mONStR";
chosen {
linux,platform = <600>;
bootargs = "root=/dev/xsysace/disc0/part2";
} ;
cpus {
#size-cells = <0>;
#cpus = < 0 >;
#address-cells = <1>;
microblaze_0,5.00.c {
32-bit;
linux,boot-cpu;
device_type = "cpu";
reg = <0>;
clock-frequency = <5f5e1000>;
timebase-frequency = <1FCA055>;
i-cache-line-size = <2000>;
i-cache-size = <10>;
d-cache-line-size = <2000>;
d-cache-size = <10>;
xilinx,pvr = <0>;
xilinx,debug-enabled = <1>;
xilinx,fsl-links = <0>;
} ;
} ;
opb_mdm@41400000 {
compatible = "opb_mdm_2.00.a\0opb_mdm";
name = "debug_module";
reg = < 41400000 10000 >;
device_type = "opb_mdm";
xilinx,mb-dbg-ports = <1>;
xilinx,uart-width = <8>;
xilinx,use-uart = <1>;
} ;
opb_uartlite@40600000 {
compatible = "opb_uartlite_1.00.b\0opb_uartlite";
name = "RS232_Uart_1";
interrupts = < 4 0 >;
reg = < 40600000 10000 >;
device_type = "opb_uartlite";
xilinx,baudrate = <2580>;
xilinx,data-bits = <8>;
xilinx,clk-freq = <5f5e100>;
xilinx,odd-parity = <0>;
xilinx,use-parity = <0>;
} ;
opb_ethernet@40c00000 {
compatible = "opb_ethernet_1.04.a\0opb_ethernet";
name = "Ethernet_MAC";
interrupts = < 3 0 >;
reg = < 40c00000 10000 >;
device_type = "opb_ethernet";
xilinx,cam-exist = <0>;
xilinx,dev-blk-id = <1>;
xilinx,dev-mir-enable = <1>;
xilinx,dma-present = <1>;
xilinx,include-dev-pencoder = <1>;
xilinx,ipif-rdfifo-depth = <8000>;
xilinx,ipif-wrfifo-depth = <8000>;
xilinx,mii-exist = <1>;
} ;
opb_sysace@41820000 {
compatible = "opb_sysace_1.00.c\0opb_sysace";
name = "SysACE_CompactFlash";
reg = < 41820000 10000 >;
device_type = "opb_sysace";
xilinx,mem-width = <10>;
} ;
opb_gpio@40000000 {
compatible = "opb_gpio_3.01.b\0opb_gpio";
name = "LEDs_4Bit";
reg = < 40000000 10000 >;
device_type = "opb_gpio";
xilinx,gpio-width = <4>;
xilinx,is-dual = <0>;
} ;
memory@30000000 {
edk_name = "DDR_256MB_32MX64_rank1_row13_col10_cl2_5";
compatible = "opb_ddr";
memreg:reg = < 30000000 10000000 >;
device_type = "memory";
} ;
opb_ps2_dual_ref@7a400000 {
compatible = "opb_ps2_dual_ref_1.00.a\0opb_ps2_dual_ref";
name = "PS2_Ports";
interrupts = < 2 0 >;
interrupts = < 1 0 >;
reg = < 7a400000 10000 >;
device_type = "opb_ps2_dual_ref";
} ;
opb_timer@41c00000 {
compatible = "opb_timer_1.00.b\0opb_timer";
name = "opb_timer_1";
interrupts = < 0 0 >;
reg = < 41c00000 10000 >;
device_type = "opb_timer";
xilinx,count-width = <20>;
xilinx,one-timer-only = <0>;
} ;
opb_intc@41200000 {
compatible = "opb_intc_1.00.c\0opb_intc";
name = "opb_intc_0";
reg = < 41200000 10000 >;
device_type = "opb_intc";
} ;
opb_uart16550@40400000 {
compatible = "opb_uart16550_1.00.d\0opb_uart16550";
name = "opb_uart16550_0";
reg = < 40400000 10000 >;
device_type = "opb_uart16550";
} ;
opb_sysace@41800000 {
compatible = "opb_sysace_1.00.c\0opb_sysace";
name = "opb_sysace_0";
reg = < 41800000 10000 >;
device_type = "opb_sysace";
xilinx,mem-width = <10>;
} ;
} ;
From: David Gibson <hidden> Date: 2007-10-23 04:34:43
On Tue, Oct 23, 2007 at 06:07:56AM +0200, Michal Simek wrote:
quoted
quoted
In my opinion will be better generate only parameters which
you want not all.
That smells with unusable parameters.
In the long term, this may be true. In the short term:
1) dtb size is not the key problem
Yes of course
quoted
2) making sure that everything works is a key problem.
3) The code that generates the dts should be as simple as possible,
so that we can easily document what it does.
Yes but you must document every parameter which your generate do. The better way is
document only parameters which you want use.
quoted
In the long term, I'm all for optimizing the device tree that gets
built,
assuming that it appears to be a problem in real systems.
We can optimize now. I made new version of my generator u-boot_v3_00_a (monstr.eu)
where you can simply add parameter which you want to use.
If you want use any parameter add it.
For microblaze cpu - line 1184.
And for others peripherals lines 926-980. (The last parameter of function call).
Which parameters do you want for PPC405, Grant?
Regards,
Michal Simek
This is example of generator.
/ {
model = "mONStR";
Please use the new "opb_mdm_2.00.a", "opb_mdm" syntax.
name = "debug_module";
Don't create properties called 'name'. In real OF the 'name' property
is a synonym for the node name without the @address part. Although
it's possible to encode a name property in a flattened tree with a
different value, it's a bad idea since it will clash with the OF
notion of this property. In Linux this will cause a collision when
the tree is unflattened.
We should probably fix dtc to reject this, in fact.
Get rid of all your device_type values, they're all bogus. The only
devices which should have device_type at all are the ethernets and
maybe the uarts, and in these cases the values should be "network" and
"serial" respectively.
The memory node shouldn't generally need a compatible property. Note
that the RAM itself probably needs to be separate from the RAM
controller node, if such a thing exists.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Grant Likely <hidden> Date: 2007-10-23 14:01:20
On 10/23/07, Michal Simek [off-list ref] wrote:
Hi David,
I remove some labels from my generator. I created fake system with some peripherals.
There are 3 buses and 3 bridges.
Can you check it and tell me what is wrong?
Thanks,
Michal Simek
/ {
model = "mONStR";
You should have a board-level compatible property here
- add manufacture prefix
- convert underscores to dashes
- drop "opb_ethernet"; there's no such thing
Just "xlnx,opb-ethernet-1.04.a" will do; or something like
"xlnx,opb-ethernet-1.04b","xlnx,opb-ethernet-1.04a" works too.
'opb_uart16550' is bogus non-device; Always specify a version for IP
core compatible fields. There was some talk about defining a
'sparse16550' or some such value to reflect things that were almost a
16550 but had a different register layout; but in the mean time leave
it out.
- change '_' to '-', add 'xlnx,'; etc.
Since you're bus uses the ranges property value to translate; the
device address should reflect the offset off the base of the bus:
opb_gpio@20000
If instead your ranges property was empty then the full address still
works. Address translation makes sense for the opb-opb-lite because
it's only got one translation range. However, the plb-opb bridge
covers multiple ranges so it's probably easier to leave out the
translation.
My patch to booting-without-of says that you should have a
'current-speed' property (instead of xlnx,baudrate) because it's a
standard property; but 'xlnx,baudrate' might be a suitable alternative
because this is a fixed speed device. Segher, David; what say you?
There are no nodes on this bus. What is the intended usage? Also,
you cannot have two properties with the same name, I think the syntax
you want is:
ranges = <0 10000000 10000000 2 20000000 10000000>;
Also, these values won't work. They state that you've got two address
range translations. The first translates from address 10000000 to
address 0 (which makes sense). The second translates from address
20000000 to address 1 (which overlaps the first region, only offset by
1 byte).
Sent: Monday, October 22, 2007 9:08 PM
To: microblaze-uclinux@itee.uq.edu.au
Cc: Leonid; Wolfgang Reissnegger; Arnd Bergmann;=20
linuxppc-dev@ozlabs.org
Subject: RE: [microblaze-uclinux] Re: [microblaze-uclinux]=20
RE: [PATCH v3] Device tree bindings for Xilinx devices
=20
quoted
quoted
In my opinion will be better generate only parameters which=20
you want not all.
That smells with unusable parameters.
In the long term, this may be true. In the short term:
1) dtb size is not the key problem
Yes of course
quoted
2) making sure that everything works is a key problem.
3) The code that generates the dts should be as simple as possible,
so that we can easily document what it does.
Yes but you must document every parameter which your generate=20
do. The better way is=20
document only parameters which you want use.
No, that's exactly my point. The generator should document what it
*does*
i.e. When there is a parameter in the EDK file, then such and such
corresponding parameter will be generated in the dts. The devices and
drivers
will inevitably change over time: your proposal would result in
an unnecessary maintenance headache... The documentation of what the
individual
parameters are should be unambiguous from the EDK documentation.
The only things that the generator should handle 'specially', in my
opinion
are parameters that need to be munged to be standard names.
Steve
From: David Gibson <hidden> Date: 2007-10-24 00:05:23
On Tue, Oct 23, 2007 at 09:34:37AM +0200, Michal Simek wrote:
Hi David,
I remove some labels from my generator. I created fake system with some peripherals.
There are 3 buses and 3 bridges.
Can you check it and tell me what is wrong?
Grant's comments all seem reasonable, apologies if I've duplicated
some of them below.
Thanks,
Michal Simek
/ {
model = "mONStR";
You should have #address-cells and #size-cells properties.
That name is acceptable, but I think just cpu@0 would be better. The
generic names convention seems to be frequently ignored for cpus, but
I don't see a good reason to.
This is a bus bridge, and so needs #address-cells and #size-cells
properties. It should also have a compatible property to describe the
type of bridge.
This doesn't look quite right. The reg property is translated by the
parent's ranges property. So shouldn't this be just reg = <20000
10000>, with the 30000000 added by the parent?
Uh... duplicate property names here. Should be
interrupts = <2 0 1 0>;
Also you need an interrupt-parent property somewhere. Either here, or
in one of the ancestor bridges.
This really doesn't look right. I don't think it's technically
forbidden, but almost nothing is going to look for cpus anywhere other
than /cpus. If this dt is for some sort of daughter card, and these
entries represent the cpu of the containing system, we'll need to work
out a different representation (that won't have device_type="cpu").
Although it may be a cpu, it's not *the* cpu from the prespective of
something running on the microblaze.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Stephen Neuendorffer <hidden> Date: 2007-10-24 01:15:31
I've incorporated a good portion of the combined feedback and pushed the
gen_mhs_devtree patches back to Grant.
The few things I haven't done are relatively cosmetic (like getting rid
of linux,phandle references, decimal vs. hex, and the 'embedded \0')
,=20
The one significant problem that I'm not sure how to deal with pertains
to multiple memory nodes, which often happens. Should they all be
exported at the toplevel (which dtc seems to require), or only the main
memory which is used by Linux?
Some specific responses below:
Not quite; the bus itself needs to be one level deeper. Compatible
here is refering to the platform itself, not the bus and so should be
the actual board name or something similar. Maybe something like:
"xlnx,ml403","xlnx,generic-virtex4";
perhaps the toplevel compatible node should contain a SHA1 hash of
system.mhs?
Yes; this is the idea; but I don't like "xilinx,opb-ethernet". I
think we should always specify specific versions and not try to guess
what the 'generic' device compatible interface is.
Any node with children must have #address-cells and #size-cells
properties. This one almost certainly needs 'ranges' too. If it has
any bridge control registers, it should have 'reg' also.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson