current ARCH=powerpc for v2pro.

current ARCH=powerpc for v2pro.

[Stephen Neuendorffer]

Grant,

I'm trying to bring up your arch/powerpc work, using a compiled in
device tree.  I added this:

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..48f745d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -53,7 +53,7 @@ src-wlib :=3D string.S crt0.S stdio.c main.c
flatdevtree.c flatd
                cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c
uartlite.c \
                fsl-soc.c mpc8xx.c pq2.c
 src-plat :=3D of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
-               cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+               virtex.c cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
                ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c \
                cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c=20
                fixed-head.S ep88xc.c cuboot-hpc2.c
@@ -159,6 +159,7 @@ image-$(CONFIG_EBONY)                       +=3D
treeImage.ebo
 image-$(CONFIG_BAMBOO)                 +=3D treeImage.bamboo
cuImage.bamboo
 image-$(CONFIG_SEQUOIA)                        +=3D cuImage.sequoia
 image-$(CONFIG_WALNUT)                 +=3D treeImage.walnut
+image-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD)                    +=3D
zImage.virtex
 endif
=20
 # For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/virtex.c b/arch/powerpc/boot/virtex.c
new file mode 100644
index 0000000..32cebc1
--- /dev/null
+++ b/arch/powerpc/boot/virtex.c
@@ -0,0 +1,20 @@
+
+
+#include "ops.h"
+#include "stdio.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void platform_init(void)
+{
+       unsigned long end_of_ram =3D 0xfffffff;
+       unsigned long avail_ram =3D end_of_ram - (unsigned long) _end;
+
+       simple_alloc_init(_end, avail_ram, 32, 32);
+       ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+       serial_console_init();
+        printf("booting virtex\n");
+}

and got as far as:

---
booting virtex

zImage starting: loaded at 0x00400000 (sp: 0x00551f14)
Allocating 0x2d7324 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040b000:0x00550d74)...done 0x2b35ec bytes

Linux/PowerPC load: root=3D/dev/xsysace/disc0/part2
Finalizing device tree... flat tree at 0x409870
---

Tracing through the code, it appears that there is a machine check in
memset_io in early_init():

unsigned long __init early_init(unsigned long dt_ptr)
{
	unsigned long offset =3D reloc_offset();
	struct cpu_spec *spec;

	/* First zero the BSS -- use memset_io, some platforms don't
have
	 * caches on yet */
	memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
			__bss_stop - __bss_start);

	/*
	 * Identify the CPU type and fix up code sections
	 * that depend on which cpu we have.
	 */
	spec =3D identify_cpu(offset, mfspr(SPRN_PVR));

	do_feature_fixups(spec->cpu_features,
			  PTRRELOC(&__start___ftr_fixup),
			  PTRRELOC(&__stop___ftr_fixup));

	return KERNELBASE + offset;
}

Which seems bizarre, because that code is very simple.  I'm guessing
that something in the memory configuration is wierd (or maybe
zImage.virtex is not the right way to do this?) but I'm a little lost
where to look from here.  I also tried it with both paulus_master and
your virtex-for-2.6.24 branch.

Any ideas?

Steve

Re: current ARCH=powerpc for v2pro.

[Grant Likely]

On 11/30/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> Grant,
>
> I'm trying to bring up your arch/powerpc work, using a compiled in
> device tree.  I added this:
>
<snip>
>
> Which seems bizarre, because that code is very simple.  I'm guessing
> that something in the memory configuration is wierd (or maybe
> zImage.virtex is not the right way to do this?) but I'm a little lost
> where to look from here.  I also tried it with both paulus_master and
> your virtex-for-2.6.24 branch.


I've got a patch that adds 'raw' image support (originally written by
Scott Wood) which somewhat works for booting (but not entirely; I
haven't had time to dig into it properly yet).  It's not suitable to
go into mainline yet.  I'll try to get the patch out to my tree this
evening... actually I've been trying to get my tree pushed out all
today, but other things keep coming up.  :-)

<several hours after I wrote the above>

Okay, I pushed my current patch set out to the master branch of my
linux-2.6-virtex tree.  Give it a whirl.  It's not perfect, but it
should be usable for booting.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

RE: current ARCH=powerpc for v2pro.

[Stephen Neuendorffer]

I tried that, which essentially differed from what I was trying in that
interrupts were turned off.
It fails in the same way as before.

I've booted ARCH=3Dppc from your tree on the exact same hardware design,
and as near as I can tell, the code that runs in the kernel proper up to
the point where I see the machine check is almost identical.

The machine check (a trap into the Machine Check handler at 0x200)
occurs at a nondeterministic point during the execution of memset_io in
early_init.

In the kernel I have, _bss_start is c02c8000, and these are the
registers in the trap handler on two different runs of the kernel:

    r3: c02c80cc r5: 00022874
    r3: c02c8248 r5: 000226f4

r3 is the current point being initialized, and r5 is the count remaining
in the .bss.

So, what would cause a machine check in the middle of a loop, in the
middle of the almost the simplest code absolutely possible, and not on
an obvious memory boundary?

Steve

> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Friday, November 30, 2007 10:40 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: current ARCH=3Dpowerpc for v2pro.
>=20
> On 11/30/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > Grant,
> >
> > I'm trying to bring up your arch/powerpc work, using a compiled in
> > device tree.  I added this:
> >
> <snip>
> >
> > Which seems bizarre, because that code is very simple.  I'm guessing
> > that something in the memory configuration is wierd (or maybe
> > zImage.virtex is not the right way to do this?) but I'm a=20
> little lost
> > where to look from here.  I also tried it with both=20
> paulus_master and
> > your virtex-for-2.6.24 branch.
>=20
>=20
> I've got a patch that adds 'raw' image support (originally written by
> Scott Wood) which somewhat works for booting (but not entirely; I
> haven't had time to dig into it properly yet).  It's not suitable to
> go into mainline yet.  I'll try to get the patch out to my tree this
> evening... actually I've been trying to get my tree pushed out all
> today, but other things keep coming up.  :-)
>=20
> <several hours after I wrote the above>
>=20
> Okay, I pushed my current patch set out to the master branch of my
> linux-2.6-virtex tree.  Give it a whirl.  It's not perfect, but it
> should be usable for booting.
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>=20
>=20

RE: current ARCH=powerpc for v2pro.

[Stephen Neuendorffer]

Hmm...  This code (from arch/ppc/boot/simple/embed_config.c) appears to
help:

	static const unsigned long line_size =3D 32;
	static const unsigned long congruence_classes =3D 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": "=3Dr" (dccr));
	if (dccr =3D=3D 0) {
		for (addr =3D 0;
		     addr < (congruence_classes * line_size);
		     addr +=3D line_size) {
			__asm__("dccci 0,%0": :"b"(addr));
		}
	}

Although, I'm not sure why that should be virtex specific.

Steve=20

> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
> labs.org] On Behalf Of Stephen Neuendorffer
> Sent: Monday, December 03, 2007 4:49 PM
> To: Grant Likely
> Cc: linuxppc-embedded
> Subject: RE: current ARCH=3Dpowerpc for v2pro.
>=20
> I tried that, which essentially differed from what I was=20
> trying in that
> interrupts were turned off.
> It fails in the same way as before.
>=20
> I've booted ARCH=3Dppc from your tree on the exact same hardware =
design,
> and as near as I can tell, the code that runs in the kernel=20
> proper up to
> the point where I see the machine check is almost identical.
>=20
> The machine check (a trap into the Machine Check handler at 0x200)
> occurs at a nondeterministic point during the execution of=20
> memset_io in
> early_init.
>=20
> In the kernel I have, _bss_start is c02c8000, and these are the
> registers in the trap handler on two different runs of the kernel:
>=20
>     r3: c02c80cc r5: 00022874
>     r3: c02c8248 r5: 000226f4
>=20
> r3 is the current point being initialized, and r5 is the=20
> count remaining
> in the .bss.
>=20
> So, what would cause a machine check in the middle of a loop, in the
> middle of the almost the simplest code absolutely possible, and not on
> an obvious memory boundary?
>=20
> Steve
>=20
> > -----Original Message-----
> > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> > Behalf Of Grant Likely
> > Sent: Friday, November 30, 2007 10:40 PM
> > To: Stephen Neuendorffer
> > Cc: linuxppc-embedded
> > Subject: Re: current ARCH=3Dpowerpc for v2pro.
> >=20
> > On 11/30/07, Stephen Neuendorffer=20
> > <stephen.neuendorffer@xilinx.com> wrote:
> > >
> > > Grant,
> > >
> > > I'm trying to bring up your arch/powerpc work, using a compiled in
> > > device tree.  I added this:
> > >
> > <snip>
> > >
> > > Which seems bizarre, because that code is very simple. =20
> I'm guessing
> > > that something in the memory configuration is wierd (or maybe
> > > zImage.virtex is not the right way to do this?) but I'm a=20
> > little lost
> > > where to look from here.  I also tried it with both=20
> > paulus_master and
> > > your virtex-for-2.6.24 branch.
> >=20
> >=20
> > I've got a patch that adds 'raw' image support (originally=20
> written by
> > Scott Wood) which somewhat works for booting (but not entirely; I
> > haven't had time to dig into it properly yet).  It's not suitable to
> > go into mainline yet.  I'll try to get the patch out to my tree this
> > evening... actually I've been trying to get my tree pushed out all
> > today, but other things keep coming up.  :-)
> >=20
> > <several hours after I wrote the above>
> >=20
> > Okay, I pushed my current patch set out to the master branch of my
> > linux-2.6-virtex tree.  Give it a whirl.  It's not perfect, but it
> > should be usable for booting.
> >=20
> > Cheers,
> > g.
> >=20
> > --=20
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > grant.likely@secretlab.ca
> > (403) 399-0195
> >=20
> >=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

Device Tree updates for xilinx.

[Stephen Neuendorffer]

These patches synchronize all the in-kernel drivers to use the
compatible names generated by the UBoot BSP generator.
(at git://git.xilinx.com/gen-mhs-devtree.git)

The patches to make this work are coming shortly:

patches 1-2 are provided for context only...  They're not ready for
mainline.  They provide 'raw' boot support and port some initialization
code from ARCH=3Dppc.
patches 3-7 are the interesting patches, which I think could be taken
for 2.6.25.

I've also pushed the working tree up to git.xilinx.com containing these
patches.  This tree also includes updates for ps2, gpio, etc.
The ll_temac currently doesn't work because I haven't gone back and
fixed the mechanism by which it finds out about the DMA that it is
connected to.

If you want output from the boot loader, you'll need something like:
		linux,stdout-path =3D "/plb_v34/opb_v20/serial@40400000";=20
This seems to work with uartlite, but I wasn't able to get it working
with a UART design.

Currently, you'll need to add, by hand the following labels:

mem_size_cells, on the toplevel #address-cells attribue, e,g. :
	mem_size_cells: #address-cells =3D <1>;

timebase, on the processors timebase-frequency attribute, e.g. :
			timebase: timebase-frequency =3D <11e1a300>;

memsize, on the memory's size, e.g.:
	DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
		device_type =3D "memory";
		reg =3D < 0 memsize:10000000 >;
	} ;

In addition, if you're using uartlite, you'll have to specify
'console=3DttyUL0' as boot args.

For reference, below is the device tree for a Virtex2Pro design.  Except
for the changes noted above, this is entirely automatically generated.

Steve

/ {
	mem_size_cells: #address-cells =3D <1>;
	#size-cells =3D <1>;
	compatible =3D "xlnx,virtex";
	model =3D "testing";
	DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
		device_type =3D "memory";
		reg =3D < 0 memsize:10000000 >;
	} ;
	chosen {
		bootargs =3D "root=3D/dev/nfs
nfsroot=3D172.19.221.221:/exports/xup/ydl41 ip=3Ddhcp console=3DttyUL0";
	} ;
	cpus {
		#address-cells =3D <1>;
		#cpus =3D <1>;
		#size-cells =3D <0>;
		PowerPC,405@0 {
			clock-frequency =3D <11e1a300>;
			d-cache-line-size =3D <20>;
			d-cache-size =3D <4000>;
			device_type =3D "cpu";
			i-cache-line-size =3D <20>;
			i-cache-size =3D <4000>;
			reg =3D <0>;
			timebase: timebase-frequency =3D <11e1a300>;
			xlnx,dcr-resync =3D <0>;
			xlnx,deterministic-mult =3D <0>;
			xlnx,disable-operand-forwarding =3D <1>;
			xlnx,mmu-enable =3D <1>;
		} ;
	} ;
	plb_v34 {
		#address-cells =3D <1>;
		#size-cells =3D <1>;
		compatible =3D "xlnx,plb-v34-1.02.a";
		ranges ;
		Ethernet_MAC: ethernet@80400000 {
			compatible =3D "xlnx,plb-ethernet-1.01.a";
			device_type =3D "network";
			interrupt-parent =3D <&opb_intc_0>;
			interrupts =3D < 2 0 >;
			local-mac-address =3D [ 00 00 00 00 00 00 ];
			reg =3D < 80400000 10000 >;
			xlnx,dev-blk-id =3D <0>;
			xlnx,dev-mir-enable =3D <1>;
			xlnx,dma-intr-coalesce =3D <1>;
			xlnx,dma-present =3D <1>;
			xlnx,err-count-exist =3D <1>;
			xlnx,fcs-insert-exist =3D <1>;
			xlnx,half-duplex-exist =3D <1>;
			xlnx,include-dev-pencoder =3D <1>;
			xlnx,ipif-fifo-depth =3D <8000>;
			xlnx,mac-fifo-depth =3D <40>;
			xlnx,mii-exist =3D <1>;
			xlnx,miim-clkdvd =3D <13>;
			xlnx,pad-insert-exist =3D <1>;
			xlnx,reset-present =3D <1>;
			xlnx,source-addr-insert-exist =3D <1>;
		} ;
		opb_v20 {
			#address-cells =3D <1>;
			#size-cells =3D <1>;
			compatible =3D "xlnx,opb-v20-1.10.c";
			ranges ;
			Audio_Codec: opb-ac97@7d400000 {
				compatible =3D "xlnx,opb-ac97-2.00.a";
				interrupt-parent =3D <&opb_intc_0>;
				interrupts =3D < 1 0 >;
				reg =3D < 7d400000 10000 >;
				xlnx,intr-level =3D <1>;
				xlnx,playback =3D <1>;
				xlnx,record =3D <1>;
				xlnx,use-bram =3D <1>;
			} ;
			DIPSWs_4Bit: opb-gpio@40020000 {
				compatible =3D "xlnx,opb-gpio-3.01.b";
				reg =3D < 40020000 10000 >;
				xlnx,all-inputs =3D <1>;
				xlnx,all-inputs-2 =3D <0>;
				xlnx,dout-default =3D <0>;
				xlnx,dout-default-2 =3D <0>;
				xlnx,gpio-width =3D <4>;
				xlnx,interrupt-present =3D <0>;
				xlnx,is-bidir =3D <1>;
				xlnx,is-bidir-2 =3D <1>;
				xlnx,is-dual =3D <0>;
				xlnx,tri-default =3D <ffffffff>;
				xlnx,tri-default-2 =3D <ffffffff>;
				xlnx,user-id-code =3D <3>;
			} ;
			LEDs_4Bit: opb-gpio@40000000 {
				compatible =3D "xlnx,opb-gpio-3.01.b";
				reg =3D < 40000000 10000 >;
				xlnx,all-inputs =3D <0>;
				xlnx,all-inputs-2 =3D <0>;
				xlnx,dout-default =3D <0>;
				xlnx,dout-default-2 =3D <0>;
				xlnx,gpio-width =3D <4>;
				xlnx,interrupt-present =3D <0>;
				xlnx,is-bidir =3D <0>;
				xlnx,is-bidir-2 =3D <1>;
				xlnx,is-dual =3D <0>;
				xlnx,tri-default =3D <ffffffff>;
				xlnx,tri-default-2 =3D <ffffffff>;
				xlnx,user-id-code =3D <3>;
			} ;
			PS2_Ports: opb-ps2-dual-ref@7a400000 {
				#address-cells =3D <1>;
				#size-cells =3D <1>;
				compatible =3D "xlnx,compound";
				ranges =3D < 0 7a400000 10000 >;
				opb-ps2-dual-ref@0 {
					compatible =3D
"xlnx,opb-ps2-dual-ref-1.00.a";
					interrupt-parent =3D
<&opb_intc_0>;
					interrupts =3D < 6 0 >;
					reg =3D < 0 40 >;
				} ;
				opb-ps2-dual-ref@1000 {
					compatible =3D
"xlnx,opb-ps2-dual-ref-1.00.a";
					interrupt-parent =3D
<&opb_intc_0>;
					interrupts =3D < 5 0 >;
					reg =3D < 1000 40 >;
				} ;
			} ;
			PushButtons_5Bit: opb-gpio@40040000 {
				compatible =3D "xlnx,opb-gpio-3.01.b";
				reg =3D < 40040000 10000 >;
				xlnx,all-inputs =3D <1>;
				xlnx,all-inputs-2 =3D <0>;
				xlnx,dout-default =3D <0>;
				xlnx,dout-default-2 =3D <0>;
				xlnx,gpio-width =3D <5>;
				xlnx,interrupt-present =3D <0>;
				xlnx,is-bidir =3D <1>;
				xlnx,is-bidir-2 =3D <1>;
				xlnx,is-dual =3D <0>;
				xlnx,tri-default =3D <ffffffff>;
				xlnx,tri-default-2 =3D <ffffffff>;
				xlnx,user-id-code =3D <3>;
			} ;
			RS232_Uart_1: serial@40400000 {
				compatible =3D "xlnx,opb-uartlite-1.00.b";
				device_type =3D "serial";
				interrupt-parent =3D <&opb_intc_0>;
				interrupts =3D < 4 0 >;
				port-number =3D <0>;
				reg =3D < 40400000 10000 >;
				xlnx,baudrate =3D <2580>;
				xlnx,clk-freq =3D <5f5e100>;
				xlnx,data-bits =3D <8>;
				xlnx,odd-parity =3D <0>;
				xlnx,use-parity =3D <0>;
			} ;
			SysACE_CompactFlash: opb-sysace@41800000 {
				compatible =3D "xlnx,opb-sysace-1.00.c";
				interrupt-parent =3D <&opb_intc_0>;
				interrupts =3D < 3 0 >;
				reg =3D < 41800000 10000 >;
				xlnx,mem-width =3D <10>;
			} ;
			dcr_v29 {
				#address-cells =3D <1>;
				#size-cells =3D <1>;
				compatible =3D "xlnx,dcr-v29-1.00.a";
				ranges =3D < 0 40700000 1000 >;
				VGA_FrameBuffer: plb-tft-cntlr-ref@200 {
					compatible =3D
"xlnx,plb-tft-cntlr-ref-1.00.a";
					reg =3D < 200 8 >;
					xlnx,default-tft-base-addr =3D
<7f>;
					xlnx,dps-init =3D <1>;
					xlnx,on-init =3D <1>;
					xlnx,pixclk-is-busclk-divby4 =3D
<1>;
				} ;
			} ;
			onewire_0: opb-onewire@7a200000 {
				compatible =3D "xlnx,opb-onewire-1.00.a";
				reg =3D < 7a200000 10000 >;
				xlnx,add-pullup =3D "true";
				xlnx,checkcrc =3D "true";
				xlnx,clk-div =3D <f>;
			} ;
			opb_hwicap_0: opb-hwicap@41300000 {
				compatible =3D "xlnx,opb-hwicap-1.00.b";
				reg =3D < 41300000 10000 >;
			} ;
			opb_intc_0: interrupt-controller@41200000 {
				#interrupt-cells =3D <2>;
				compatible =3D "xlnx,opb-intc-1.00.c";
				interrupt-controller ;
				reg =3D < 41200000 10000 >;
				xlnx,num-intr-inputs =3D <7>;
			} ;
			opb_timer_0: opb-timer@40800000 {
				compatible =3D "xlnx,opb-timer-1.00.b";
				interrupt-parent =3D <&opb_intc_0>;
				interrupts =3D < 0 0 >;
				reg =3D < 40800000 100 >;
				xlnx,count-width =3D <20>;
				xlnx,gen0-assert =3D <1>;
				xlnx,gen1-assert =3D <1>;
				xlnx,one-timer-only =3D <0>;
				xlnx,trig0-assert =3D <1>;
				xlnx,trig1-assert =3D <1>;
			} ;
		} ;
	} ;
}  ;

Re: Device Tree updates for xilinx.

[David Gibson]

On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:
> These patches synchronize all the in-kernel drivers to use the
> compatible names generated by the UBoot BSP generator.
> (at git://git.xilinx.com/gen-mhs-devtree.git)
> 
> The patches to make this work are coming shortly:
> 
> patches 1-2 are provided for context only...  They're not ready for
> mainline.  They provide 'raw' boot support and port some initialization
> code from ARCH=ppc.
> patches 3-7 are the interesting patches, which I think could be taken
> for 2.6.25.
> 
> I've also pushed the working tree up to git.xilinx.com containing these
> patches.  This tree also includes updates for ps2, gpio, etc.
> The ll_temac currently doesn't work because I haven't gone back and
> fixed the mechanism by which it finds out about the DMA that it is
> connected to.
> 
> If you want output from the boot loader, you'll need something like:
> 		linux,stdout-path = "/plb_v34/opb_v20/serial@40400000"; 
> This seems to work with uartlite, but I wasn't able to get it working
> with a UART design.
> 
> Currently, you'll need to add, by hand the following labels:
> 
> mem_size_cells, on the toplevel #address-cells attribue, e,g. :
> 	mem_size_cells: #address-cells = <1>;

Having a label called *_size_cells which is attached to
#address-cells, rather than #size-cells seems like a bad idea.  Plus,
if I understood correctly, this is used to interpret the 'memsize'
value, which means it should be #size-cells anyway.

Also, if I understood the code in your later patches correctly, this
label is used as a direct pointer to the value you want.  That means
it needs to be on the property value, not on the property, i.e.
	#size-cells = <mem_size_cells: 1>;
instead of
	mem_size_cells: #size-cells = <1>;
(the latter form will put the label on the tag which introduces the
property instead).

> timebase, on the processors timebase-frequency attribute, e.g. :
> 			timebase: timebase-frequency = <11e1a300>;
> 
> memsize, on the memory's size, e.g.:
> 	DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> 		device_type = "memory";
> 		reg = < 0 memsize:10000000 >;
> 	} ;
> 
> In addition, if you're using uartlite, you'll have to specify
> 'console=ttyUL0' as boot args.
> 
> For reference, below is the device tree for a Virtex2Pro design.  Except
> for the changes noted above, this is entirely automatically generated.
> 
> Steve
> 
> / {
> 	mem_size_cells: #address-cells = <1>;
> 	#size-cells = <1>;
> 	compatible = "xlnx,virtex";
> 	model = "testing";
> 	DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> 		device_type = "memory";
> 		reg = < 0 memsize:10000000 >;
> 	} ;
> 	chosen {
> 		bootargs = "root=/dev/nfs
> nfsroot=172.19.221.221:/exports/xup/ydl41 ip=dhcp console=ttyUL0";
> 	} ;
> 	cpus {
> 		#address-cells = <1>;
> 		#cpus = <1>;
> 		#size-cells = <0>;
> 		PowerPC,405@0 {

I'm trying to encourage people to move to naming cpu nodes simply
"cpu@XX", with the type of core in "compatible" instead - in keeping
with the generic names convention used elsewhere.  I think this will
make your generator simpler, too.

-- 
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

Re: Device Tree updates for xilinx.

[Josh Boyer]

On Sun, 16 Dec 2007 18:04:04 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> > 	cpus {
> > 		#address-cells = <1>;
> > 		#cpus = <1>;
> > 		#size-cells = <0>;
> > 		PowerPC,405@0 {
> 
> I'm trying to encourage people to move to naming cpu nodes simply
> "cpu@XX", with the type of core in "compatible" instead - in keeping
> with the generic names convention used elsewhere.  I think this will
> make your generator simpler, too.

cpu@XX with the model property of the node set to "PowerPC,405" please.

josh

RE: Device Tree updates for xilinx.

[Stephen Neuendorffer]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]


Since there don't seem to be any examples of this in the tree: do you have a format preference?  For the rest of the compatible lists, I'm using something like: xlnx,ipname-version.  So for the microblaze, I'd prefer something like:

xlnx,microblaze-6.00.b

For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be more in character than PowerPC,405.

Steve

-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sat 12/15/2007 11:04 PM
To: Stephen Neuendorffer
Cc: Grant Likely; Michal Simek; John Williams; linuxppc-dev@ozlabs.org; git
Subject: Re: Device Tree updates for xilinx.
 
On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:

> 
> For reference, below is the device tree for a Virtex2Pro design.  Except
> for the changes noted above, this is entirely automatically generated.
> 
> Steve
> 
> / {
> 	mem_size_cells: #address-cells = <1>;
> 	#size-cells = <1>;
> 	compatible = "xlnx,virtex";
> 	model = "testing";
> 	DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> 		device_type = "memory";
> 		reg = < 0 memsize:10000000 >;
> 	} ;
> 	chosen {
> 		bootargs = "root=/dev/nfs
> nfsroot=172.19.221.221:/exports/xup/ydl41 ip=dhcp console=ttyUL0";
> 	} ;
> 	cpus {
> 		#address-cells = <1>;
> 		#cpus = <1>;
> 		#size-cells = <0>;
> 		PowerPC,405@0 {

I'm trying to encourage people to move to naming cpu nodes simply
"cpu@XX", with the type of core in "compatible" instead - in keeping
with the generic names convention used elsewhere.  I think this will
make your generator simpler, too.

-- 
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



[-- Attachment #2: Type: text/html, Size: 3744 bytes --]

Re: Device Tree updates for xilinx.

[David Gibson]

On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
> 
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference?  For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version.  So for the
> microblaze, I'd prefer something like:
> 
> xlnx,microblaze-6.00.b

Sounds reasonable.

> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.

Well, we could list both forms, but PowerPC,405 should be included
since it's an established name.  There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.

With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s).  In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files.  So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.

In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.

-- 
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

RE: Device Tree updates for xilinx.

[Stephen Neuendorffer]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]


Thanks, I've updated the generator to reflect this.

Steve

-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sun 12/16/2007 9:21 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; Michal Simek; git
Subject: Re: Device Tree updates for xilinx.
 
On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
> 
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference?  For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version.  So for the
> microblaze, I'd prefer something like:
> 
> xlnx,microblaze-6.00.b

Sounds reasonable.

> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.

Well, we could list both forms, but PowerPC,405 should be included
since it's an established name.  There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.

With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s).  In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files.  So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.

In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.

-- 
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



[-- Attachment #2: Type: text/html, Size: 3105 bytes --]