Xilinx: clear data caches.

This code is needed to boot without a boot loader.

Grant: I'm not sure where the right place to put this is. I'm assuming we'll actually need some boot code that is not generic? Also, note that there is a V4FX errata workaround in arch/ppc/boot/head.S, which probably also needs to get pulled to powerpc.

Signed-off-by Stephen Neuendorffer <[email protected]>

---
 arch/powerpc/boot/raw-platform.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

arch/powerpc/boot/raw-platform.c +22 -0

index b9caeee..2a5e493 100644
@@ -24,6 +24,28 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
                    unsigned long r6, unsigned long r7)
 {
 	u64 memsize64 = memsize[0];
+	static const unsigned long line_size = 32;
+	static const unsigned long congruence_classes = 256;
+	unsigned long addr;
+	unsigned long dccr;
+
+	/*
+	 * Invalidate the data cache if the data cache is turned off.
+	 * - The 405 core does not invalidate the data cache on power-up
+	 *   or reset but does turn off the data cache. We cannot assume
+	 *   that the cache contents are valid.
+	 * - If the data cache is turned on this must have been done by
+	 *   a bootloader and we assume that the cache contents are
+	 *   valid.
+	 */
+	__asm__("mfdccr %0": "=r" (dccr));
+	if (dccr == 0) {
+		for (addr = 0;
+		     addr < (congruence_classes * line_size);
+		     addr += line_size) {
+			__asm__("dccci 0,%0": :"b"(addr));
+		}
+	}
 
 	if (mem_size_cells == 2) {
 		memsize64 <<= 32;

Quoted 4 lines · Stephen Neuendorffer

This code is needed to boot without a boot loader.

Grant: I'm not sure where the right place to put this is. I'm assuming we'll actually need some boot code that is not generic? Also, note that there is a V4FX errata workaround in arch/ppc/boot/head.S, which probably also needs to get pulled to powerpc.

Quoted 4 lines

Signed-off-by Stephen Neuendorffer <[email protected]>

---
 arch/powerpc/boot/raw-platform.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

This raw-platform.c file doesn't seem like a good place for code that is totally platform specific ...

-----Original Message-----
From: Benjamin Herrenschmidt [mailto:[email protected]]=20
Sent: Thursday, December 13, 2007 4:10 PM
To: Stephen Neuendorffer
Cc: [email protected]; [email protected];=20 [email protected]; [email protected]
Subject: Re: [PATCH 2/7] [POWERPC] Xilinx: clear data caches. =20
=20

Quoted 4 lines · Benjamin Herrenschmidt

Quoted 3 lines · Stephen Neuendorffer

This code is needed to boot without a boot loader. =20
Grant: I'm not sure where the right place to put this=20

is. I'm assuming we'll actually need some boot code that is=20 not generic? Also, note that there is a V4FX errata=20 workaround in arch/ppc/boot/head.S, which probably also needs=20 to get pulled to powerpc.

Quoted 2 lines

Quoted 2 lines

=20
Signed-off-by: Stephen Neuendorffer=20

<[email protected]>

Quoted 5 lines

Quoted 3 lines

---
 arch/powerpc/boot/raw-platform.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

=20
This raw-platform.c file doesn't seem like a good place for=20

code that is

Quoted 1 line

totally platform specific ...

=20
Maybe best is to do that in asm ? The problem when you are in=20 C code is
that you may already have hit stale cache entries. "raw" platforms probably need to perform various CPU-specific initializations anyway, prior to entering C code, in a custom crt0.S, so that's probably the best place to do the cache clearing.
=20
Ben.
=20
=20
=20

Unfortunately, I think your right... The asm code seems so clean at the moment, I don't really want be the one to start tarnishing it with a bunch of little fixups.. :)

This now better describes what the UBoot device tree generator actually does. In particular:

1) Nodes have a label derived from the device name, and a node name
derived from the device type.
2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.

3) Uartlite requires a port-number property for the console to work.

Quoted 5 lines · Stephen Neuendorffer

This now better describes what the UBoot device tree generator actually does. In particular:

1) Nodes have a label derived from the device name, and a node name
derived from the device type.
2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.

I'm not sure I like this xlnx,compound business, although maybe it's the best you can do.

Quoted 2 lines

3) Uartlite requires a port-number property for the console to work.

Why? In general we try to avoid magical sequence numbers - cell-index should *only* be used when it's needed to index or program some shared register.

Quoted 5 lines · Stephen Neuendorffer

This now better describes what the UBoot device tree generator actually does. In particular:

1) Nodes have a label derived from the device name, and a node name
derived from the device type.
2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.

I'm not sure I like this xlnx,compound business, although maybe it's the best you can do.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Grant" == Grant Likely <[email protected]> writes:

Quoted 5 lines

Quoted 1 line

3) Uartlite requires a port-number property for the console to work.

Why? In general we try to avoid magical sequence numbers - cell-index should *only* be used when it's needed to index or program some shared register.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Grant" == Grant Likely <[email protected]> writes:

Hi,

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

3) Uartlite requires a port-number property for the console to work.

Why? In general we try to avoid magical sequence numbers - cell-index should *only* be used when it's needed to index or program some shared register.

Grant> Aliases is probably the correct construct for this. Grant> port-number was a bad idea and I never should have gone that Grant> direction.

Perhaps it would make more sense to add a _find_match_or_unused(port) like 8250.c and make the initialization order define the index instead of explicitly setting it?

Now we're at it - Why isn't the uartlite of glue handled by of_serial.c?

This now better describes what the UBoot device tree generator actually does. In particular:

1) Nodes have a label derived from the device name, and a node name
derived from the device type.
2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
3) Uartlite requires a port-number property for the console to work.

In addition, I've clarified some of the language relating to how mhs nodes should be represent in the device tree.

---
 Documentation/powerpc/booting-without-of.txt |   61 +++++++++++++++-----------
 1 files changed, 36 insertions(+), 25 deletions(-)

Documentation/powerpc/booting-without-of.txt +0 -0

index e9a3cb1..5e2b85a 100644

Documentation/powerpc/booting-without-of.txt +16 -12

    Typically, the compatible list will include the exact IP core version
    followed by an older IP core version which implements the same

@@ -2326,12 +2326,13 @@ platforms are moved over to use the flattened-device-tree model.
 
    becomes the following device tree node:
 
-       opb-uartlite-0@ec100000 {
+       opb_uartlite_0: serial@ec100000 {
                device_type = "serial";
                compatible = "xlnx,opb-uartlite-1.00.b";
                reg = <ec100000 10000>;
-               interrupt-parent = <&opb-intc>;
+               interrupt-parent = <&opb_intc_0>;
                interrupts = <1 0>; // got this from the opb_intc parameters
+               port-number = <0>;
                current-speed = <d#115200>;     // standard serial device prop
                clock-frequency = <d#50000000>; // standard serial device prop
                xlnx,data-bits = <8>;

@@ -2339,16 +2340,19 @@ platforms are moved over to use the flattened-device-tree model.
                xlnx,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.
+   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.  In addition, the parent node should be
+   compatible with the bus type 'xlnx,compound', and should contain
+   #address-cells and #size-cells, as with any other bus.  (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

@@ -2370,21 +2374,24 @@ platforms are moved over to use the flattened-device-tree model.
 
    It would result in the following device tree nodes:
 

Documentation/powerpc/booting-without-of.txt +3 -3

                        compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
                        reg = <0 40>;
-                       interrupt-parent = <&opb-intc>;
+                       interrupt-parent = <&opb_intc_0>;
                        interrupts = <3 0>;
                        cell-index = <0>;
                };
-               ps2@1000 {
+               opb-ps2-dual-ref@1000 {
                        compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
                        reg = <1000 40>;
-                       interrupt-parent = <&opb-intc>;
+                       interrupt-parent = <&opb_intc_0>;
                        interrupts = <3 0>;
                        cell-index = <0>;
                };

When the driver no longer requires the port number, it's easy to drop. Until then, I'll keep it in.

Also, I'm not so sure that moving to completely generic names is really worth the effort... All the 'semantically' interesting' information is already in the device tree somewhere else. In the limit, the node name could just be a randomly generated string. So now we have a matter of
taste: what is the right amount of detail to put in so that someone who looks at the tree can easily understand what's going on, but not be overwhelmed?

The xilinx ip name seems to usually do that almost as well as
a 'generic name'. Anyway, you proved me wrong last time after a bunch of mulling it over, so maybe I'll just take your word for it and do it that way. :)

In other news, my computer seems to have died this morning, so productivity may be low. :)

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Grant Likely
Sent: Monday, December 17, 2007 7:20 AM
To: Stephen Neuendorffer
Cc: [email protected]; [email protected]; linuxppc- [email protected]; David Gibson
Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of. =20

Documentation/powerpc/booting-without-of.txt platforms are moved over to use the flattened-device-tree model. · line 2279

Quoted 2 lines

Documentation/powerpc/booting-without-of.txt +1 -1

-       (name)@(base-address) {
+       (name): (ip-core-name)@(base-address) {

=20
(name): (generic-name)@(base-address) {

Review

Quoted 7 lines

(quoted diff) +4 -1

-       opb_ps2_dual_ref_0@a9000000 {
+       opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
+               #address-cells =3D <1>;
+               #size-cells =3D <1>;
+               compatible =3D "xlnx,compound";
                ranges =3D <0 a9000000 2000>;
                // If this device had extra parameters, then they

Documentation/powerpc/booting-without-of.txt platforms are moved over to use the flattened-device-tree model. · line 2384

Quoted 3 lines

                // go here.

Documentation/powerpc/booting-without-of.txt +1 -1

-               ps2@0 {
+               opb-ps2-dual-ref@0 {

=20
According to the generic names recommendation, this should be either "keyboard@0" or "mouse@0", but of course the two interfaces are identical and EDK doesn't have any information about how they are used. Perhaps the node name should be: "ps2@0". David, thoughts?

Documentation/powerpc/booting-without-of.txt platforms are moved over to use the flattened-device-tree model. · line 2457

Quoted 2 lines

Documentation/powerpc/booting-without-of.txt +1 -1

-       plb-v34-0 {
+       plb_v34 {

=20
Steve, when I wrote this I was lazy and I didn't add the bus address. However, if we don't have the base address I think we'll end up with name collisions (especially in the MPMC case). So, based on generic names convention, this should probably simply be "plb@<baseaddr>".

Documentation/powerpc/booting-without-of.txt platforms are moved over to use the flattened-device-tree model. · line 2464

Quoted 8 lines

                #address-cells =3D <1>;
                #size-cells =3D <1>;

Documentation/powerpc/booting-without-of.txt +2 -1

+               compatible =3D "xlnx,plb-v34-1.02.a";
                device_type =3D "ibm,plb";
                ranges; // 1:1 translation
 
-               plb-bram-if-cntrl-0@ffff0000 {
+               plb_bram_if_cntrl_0: plb-bram-if-cntrl@ffff0000 {

=20
Node name should probably just be "bram@ffff0000" here.