PHY not found after migration of gianfar driver to an of_platform_driver

PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

Hello everyone,

I recently obtained a Mikrotik RB600 and applied the patch from http://cynigram.com/~nfontes/rb600/ 
  to get it up and running with 2.6.28.3
With this patch applied everything was detected on the board and  
worked. For testing purposes I tried a recent git snapshot and noticed  
that the gianfar driver had problems.
While the the Gianfar was detected

[    0.549115] Gianfar MII Bus: probed
[    0.553316] eth0 (fsl-gianfar): not using net_device_ops yet
[    0.560861] eth0: Gianfar Ethernet Controller Version 1.2, 00:0c: 
42:28:de:4e
[    0.568024] eth0: Running with NAPI enabled
[    0.572234] eth0: 256/256 RX/TX BD ring size
[    0.576802] eth1 (fsl-gianfar): not using net_device_ops yet
[    0.584200] eth1: Gianfar Ethernet Controller Version 1.2, 00:0c: 
42:28:de:4f
[    0.591345] eth1: Running with NAPI enabled
[    0.595575] eth1: 256/256 RX/TX BD ring size

trying to up either of the devices gave me

[    8.724818] mdio@24520:01 not found
[    8.728330] eth1: Could not attach to PHY
[    8.732945] mdio@24520:01 not found
[    8.737720] eth1: Could not attach to PHY

I tracked this back to commit  
"b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 gianfar: Convert gianfar to  
an of_platform_driver". Reverting this one and applying for fsc_soc.c  
made the two nics work again.
I tried to figure out what was causing the problem in the first place,  
but failed miserably. I am pretty sure it is just a minor probing  
issue somewhere in the code but I am not able to spot that.
Maybe someone more knowledgeable than me can take a look at it and  
help me out a little bit.

According to lspci the board is a

00:00.0 Power PC: Freescale Semiconductor Inc MPC8343 (rev 30)

Please CC me in any replies since I am not subscribed to the ML .. yet.

Thanks in advance,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

Some more information regarding this board. This is the output of

dtc /proc/device/ree:

I removed all information not relevant to networking

/dts-v1/;

/ {
	linux,phandle = <0x100>;
	#size-cells = <0x1>;
	#address-cells = <0x1>;
	compatible = "MPC83xx";
	model = "RB600";

	
	soc8343@e0000000 {
		bus-frequency = <0x1>;
		reg = <0xe0000000 0x200>;
		ranges = <0x0 0xe0000000 0x100000>;
		device_type = "soc";
		#interrupt-cells = <0x2>;
		#size-cells = <0x1>;
		#address-cells = <0x1>;

	
		gpio@0 {
			reg = <0xc08 0x4>;
			device-id = <0x0>;
			compatible = "gpio";
			device_type = "gpio";
			linux,phandle = <0x400>;
		};

		ethernet@24000 {
			phy-handle = <0x80001>;
			interrupt-parent = <0x700>;
			interrupts = <0x20 0x8 0x21 0x8 0x22 0x8>;
			mac-address = [00 0c 42 28 de 4f];
			reg = <0x24000 0x1000>;
			compatible = "gianfar";
			model = "TSEC";
			device_type = "network";
		};

		ethernet@25000 {
			phy-handle = <0x80000>;
			interrupt-parent = <0x700>;
			interrupts = <0x23 0x8 0x24 0x8 0x25 0x8>;
			mac-address = [00 0c 42 28 de 4e];
			reg = <0x25000 0x1000>;
			compatible = "gianfar";
			model = "TSEC";
			device_type = "network";
		};

		mdio@24520 {
			#size-cells = <0x1>;
			#address-cells = <0x1>;
			linux,phandle = <0x800>;
			reg = <0x24520 0x20>;
			compatible = "gianfar";
			device_type = "mdio";

			ethernet-phy@1 {
				device_type = "ethernet-phy";
				reg = <0x1>;
				linux,phandle = <0x80001>;
			};

			ethernet-phy@0 {
				device_type = "ethernet-phy";
				reg = <0x0>;
				linux,phandle = <0x80000>;
			};
		};

	cpus {
		linux,phandle = <0x200>;
		#size-cells = <0x0>;
		#address-cells = <0x1>;
		#cpus = <0x1>;

		PowerPC,8343E@0 {
			linux,boot-cpu;
			linux,phandle = <0x201>;
			32-bit;
			clock-frequency = <0x17d77460>;
			timebase-frequency = <0x3f93e10>;
			i-cache-size = <0x8000>;
			d-cache-size = <0x8000>;
			i-cache-line-size = <0x20>;
			d-cache-line-size = <0x20>;
			reg = <0x0>;
			device_type = "cpu";
		};
	};


I still do not understand why phy_attach fails. Does someone have an  
idea or can tell me how to debug this further?

Kind regards,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

Ok, I made some progress but still no fix for it.

The code fails in bus_find_device

if (match(dev, data)

returns false. Data in this case is mdio@24520.00 or .01 depending on  
the nic but the only mdio device that exists is mdio@24520.1f which is  
not the phy.
If I boot with 2.6.28.3 I see the following under

/sys/devices/platform:
fsl-gianfar.0
fsl-gianfar.1
fsl-gianfar_mdio.14
	24520:00
	24520:01

So the old code finds the PHYs and puts them in the sys-tree. With the  
new code I do not have these entries any longer. I think the reason is  
because the init code went from fsl_soc.c to the driver code, is this  
correct?
If yes I need to figure out why the mdio@24520.00 and 01 PHYs are not  
probed/detected correctly. As always I am very grateful for some  
input, hints help here. :)

Kind regards,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

Hello list,

Just a little update and one question.

I spent this night to create a DTS file for the board. I took the  
output of the existing /proc/device-tree as basis and added  
information regarding the TBI's.
Then I created a simpleImage.

/dts-v1/;

/ {
	linux,phandle = <0x100>;
	#size-cells = <0x1>;
	#address-cells = <0x1>;
	compatible = "MPC83xx";
	model = "RB600";

	chosen {
		linux,platform = <0x8062>;
		linux,initrd = <0x477000 0x0>;
		linux,stdout-path = "/soc8343@e0000000/serial@4500";
		interrupt-controller = <0x700>;
		bootargs = "root=/dev/sda2 console=ttyS0,115200 board=mpc8343 boot=1";
	};

I left root in there so I do not need to add a kernparm segment, I  
think this is not best practice but it works for now.


	cf@f9200000 {
		lb-timings = <0x5dc 0x3e8 0x1194 0x5dc 0x2af8>;
		interrupt-at-level = <0x0>;
		interrupt-parent = <0x700>;
		interrupts = <0x16 0x8>;
		lbc_extra_divider = <0x1>;
		reg = <0xf9200000 0x200000>;
		device_type = "rb,cf";
	};

	cf@f9000000 {
		lb-timings = <0x5dc 0x3e8 0x1194 0x5dc 0x2af8>;
		interrupt-at-level = <0x0>;
		interrupt-parent = <0x700>;
		interrupts = <0x14 0x8>;
		lbc_extra_divider = <0x1>;
		reg = <0xf9000000 0x200000>;
		device_type = "rb,cf";
	};

	flash {
		reg = <0xff800000 0x20000>;
	};

	nnand {
		reg = <0xf0000000 0x1000>;
	};

	nand {
		ale = <0x400 0x6>;
		cle = <0x400 0x5>;
		nce = <0x400 0x4>;
		rdy = <0x400 0x3>;
		reg = <0xf8000000 0x1000>;
		device_type = "rb,nand";
	};

	fancon {
		interrupt-parent = <0x700>;
		interrupts = <0x17 0x8>;
		sense = <0x400 0x7>;
		fan_on = <0x400 0x9>;
	};

	soc8343@e0000000 {
		bus-frequency = <0x1>;
		reg = <0xe0000000 0x200>;
		ranges = <0x0 0xe0000000 0x100000>;
		device_type = "soc";
		#interrupt-cells = <0x2>;
		#size-cells = <0x1>;
		#address-cells = <0x1>;

		led {
			user_led = <0x400 0x8>;
		};

		beeper {
			reg = <0x500 0x100>;
		};

		gpio@0 {
			reg = <0xc08 0x4>;
			device-id = <0x0>;
			compatible = "gpio";
			device_type = "gpio";
			linux,phandle = <0x400>;
		};

		ethernet@24000 {
			phy-handle = <0x80001>;
			tbi-handle = <&tbi1>;

TBI-Handle1

			interrupt-parent = <0x700>;
			interrupts = <0x20 0x8 0x21 0x8 0x22 0x8>;
			mac-address = [00 0c 42 28 de 4f];
			reg = <0x24000 0x1000>;
			compatible = "gianfar";
			model = "TSEC";
			device_type = "network";
		};

		ethernet@25000 {
			phy-handle = <0x80000>;
			tbi-handle = <&tbi0>;
TBI-Handle2
			interrupt-parent = <0x700>;
			interrupts = <0x23 0x8 0x24 0x8 0x25 0x8>;
			mac-address = [00 0c 42 28 de 4e];
			reg = <0x25000 0x1000>;
			compatible = "gianfar";
			model = "TSEC";
			device_type = "network";
		};

		mdio@24520 {
			#size-cells = <0x0>;
			#address-cells = <0x1>;
			linux,phandle = <0x800>;
			reg = <0x24520 0x20>;
			compatible = "fsl,gianfar-mdio";

Here I replace gianfar with fsl,gianfar-mdio
			
			ethernet-phy@0 {
				device_type = "ethernet-phy";
				reg = <0x0>;
				linux,phandle = <0x80000>;
			};

			ethernet-phy@1 {
				device_type = "ethernet-phy";
				reg = <0x1>;
				linux,phandle = <0x80001>;
			};

			tbi0: tbi-phy@11 {
				reg = <0x11>;
				device_type = "tbi-phy";
			};
		};

		mdio@25520 {
			#address-cells = <1>;
			#size-cells = <0>;
			compatible = "fsl,gianfar-tbi";
			reg = <0x25520 0x20>;

			tbi1: tbi-phy@11 {
				reg = <0x11>;
				device_type = "tbi-phy";
			};
		};

Additional entry for the second tbi

		pic@700 {
			device_type = "ipic";
			built-in;
			reg = <0x700 0x100>;
			#interrupt-cells = <0x2>;
			#address-cells = <0x0>;
			interrupt-controller;
			linux,phandle = <0x700>;
		};

		pci@8500 {
			device_type = "pci";
			compatible = "83xx";
			reg = <0x8500 0x100>;
			#address-cells = <0x3>;
			#size-cells = <0x2>;
			#interrupt-cells = <0x1>;
			ranges = <0x2000000 0x0 0x80000000 0x80000000 0x0 0x20000000  
0x1000000 0x0 0x0 0xd0000000 0x0 0x4000000>;
			bus-range = <0x0 0x0>;
			interrupt-map = <0x5800 0x0 0x0 0x1 0x700 0x15 0x8 0x6000 0x0 0x0  
0x1 0x700 0x30 0x8 0x6000 0x0 0x0 0x2 0x700 0x11 0x8 0x6800 0x0 0x0  
0x1 0x700 0x11 0x8 0x6800 0x0 0x0 0x2 0x700 0x12 0x8 0x7000 0x0 0x0  
0x1 0x700 0x12 0x8 0x7000 0x0 0x0 0x2 0x700 0x13 0x8 0x7800 0x0 0x0  
0x1 0x700 0x13 0x8 0x7800 0x0 0x0 0x2 0x700 0x30 0x8 0x8000 0x0 0x0  
0x1 0x700 0x30 0x8 0x8000 0x0 0x0 0x2 0x700 0x12 0x8 0x8000 0x0 0x0  
0x3 0x700 0x11 0x8 0x8000 0x0 0x0 0x4 0x700 0x13 0x8 0xa000 0x0 0x0  
0x1 0x700 0x30 0x8 0xa000 0x0 0x0 0x2 0x700 0x11 0x8 0xa000 0x0 0x0  
0x3 0x700 0x12 0x8 0xa000 0x0 0x0 0x4 0x700 0x13 0x8 0xa800 0x0 0x0  
0x1 0x700 0x11 0x8 0xa800 0x0 0x0 0x2 0x700 0x12 0x8 0xa800 0x0 0x0  
0x3 0x700 0x13 0x8 0xa800 0x0 0x0 0x4 0x700 0x30 0x8>;
			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
			linux,phandle = <0x8500>;
		};

		serial@4500 {
			interrupt-parent = <0x700>;
			interrupts = <0x9 0x8>;
			clock-frequency = <0xfe4f840>;
			reg = <0x4500 0x100>;
			compatible = "ns16550";
			device_type = "serial";
		};

		wdt@200 {
			reg = <0x200 0x100>;
			compatible = "mpc83xx_wdt";
			device_type = "watchdog";
		};
	};

	memory {
		reg = <0x0 0x8000000>;
		linux,phandle = <0x300>;
		device_type = "memory";
	};

	cpus {
		linux,phandle = <0x200>;
		#size-cells = <0x0>;
		#address-cells = <0x1>;
		#cpus = <0x1>;

		PowerPC,8343E@0 {
			linux,boot-cpu;
			linux,phandle = <0x201>;
			32-bit;
			clock-frequency = <0x17d77460>;
			timebase-frequency = <0x3f93e10>;
			i-cache-size = <0x8000>;
			d-cache-size = <0x8000>;
			i-cache-line-size = <0x20>;
			d-cache-line-size = <0x20>;
			reg = <0x0>;
			device_type = "cpu";
		};
	};
};


Now my questions:

* In arch/powerpc/boot/wrapper I had to increase the link_address  
otherwise I got an error during boot.

       Insufficient memory for kernel at address...

My initial vmlinux file was 6MB but increasing link_address > 0x47xxxx  
gave me an out of memory region error. Is this a bootloader related  
issue?
I am asking since I did not find the message in the kernel sources.
During boot it looks for a partition of type 0x27 and if it is there  
it expects a linux kernel to be there. Without the simpleImage the  
kernel could be larger as 4MB (6, 8 or even 10) and it booted.
With the simpleimage everything > ~ 4.6MB gives me the error.
For now I keep the memory image at 4MB. The boot process of this board  
works the following way.

* My two gianfar devices are detected, BUT the order is reversed  
between ETH0<->ETH1.
Is there a way to define the order they appear, or is the probing non- 
deterministic?
I am asking because I want to keep the order like it was before if  
possible.


* kernparm:
with the old kernel image I had to add a kernparm entry so I could  
specify the root device. As mentioned earlier, for now I have this in  
the DTS file.
If I want to get rid of it I have to extract the kernel from the  
simpleimage, add the segment and put it back in again because adding  
the segment to the simpleimage won't do anything, right?


Kind regards,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

Hey Michael,

I just wanted to let you know that I'm reading your questions, and I'm
crafting a reply, but it's not trivial and I'm also swamped under at
the moment.  I should have something for you in the next few days.  I
just didn't want you to think you were being ignored.

g.

On Thu, Feb 26, 2009 at 12:15 PM, Michael Guntsche <mike@it-loops.com> wrot=
e:
> Hello everyone,
>
> I recently obtained a Mikrotik RB600 and applied the patch from
> http://cynigram.com/~nfontes/rb600/=A0to get it up and running with 2.6.2=
8.3
> With this patch applied everything was detected on the board and worked. =
For
> testing purposes I tried a recent git snapshot and noticed that the gianf=
ar
> driver had problems.
> While the the Gianfar was detected
>
> [ =A0 =A00.549115] Gianfar MII Bus: probed
> [ =A0 =A00.553316] eth0 (fsl-gianfar): not using net_device_ops yet
> [ =A0 =A00.560861] eth0: Gianfar Ethernet Controller Version 1.2,
> 00:0c:42:28:de:4e
> [ =A0 =A00.568024] eth0: Running with NAPI enabled
> [ =A0 =A00.572234] eth0: 256/256 RX/TX BD ring size
> [ =A0 =A00.576802] eth1 (fsl-gianfar): not using net_device_ops yet
> [ =A0 =A00.584200] eth1: Gianfar Ethernet Controller Version 1.2,
> 00:0c:42:28:de:4f
> [ =A0 =A00.591345] eth1: Running with NAPI enabled
> [ =A0 =A00.595575] eth1: 256/256 RX/TX BD ring size
>
> trying to up either of the devices gave me
>
> [ =A0 =A08.724818] mdio@24520:01 not found
> [ =A0 =A08.728330] eth1: Could not attach to PHY
> [ =A0 =A08.732945] mdio@24520:01 not found
> [ =A0 =A08.737720] eth1: Could not attach to PHY
>
> I tracked this back to commit "b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4
> gianfar: Convert gianfar to an of_platform_driver". Reverting this one an=
d
> applying for fsc_soc.c made the two nics work again.
> I tried to figure out what was causing the problem in the first place, bu=
t
> failed miserably. I am pretty sure it is just a minor probing issue
> somewhere in the code but I am not able to spot that.
> Maybe someone more knowledgeable than me can take a look at it and help m=
e
> out a little bit.
>
> According to lspci the board is a
>
> 00:00.0 Power PC: Freescale Semiconductor Inc MPC8343 (rev 30)
>
> Please CC me in any replies since I am not subscribed to the ML .. yet.
>
> Thanks in advance,
> Michael
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

[moving this conversation back to the mailing list.  Don't forget to
use 'reply-all' on mailing list conversations.]

On Sun, Mar 1, 2009 at 4:49 PM, Michael Guntsche <mike@it-loops.com> wrote:
>
> On Mar 1, 2009, at 22:53, Grant Likely wrote:
>
>> On Sun, Mar 1, 2009 at 1:04 PM, Michael Guntsche <mike@it-loops.com>
>> wrote:
>>>
>>> On Feb 28, 2009, at 16:03, Grant Likely wrote:
>>>
>>>> Hey Michael,
>>>>
>>>> I just wanted to let you know that I'm reading your questions, and I'm
>>>> crafting a reply, but it's not trivial and I'm also swamped under at
>>>> the moment. =A0I should have something for you in the next few days. =
=A0I
>>>> just didn't want you to think you were being ignored.
>>>>
>>>> g.
>>>>
>>>
>>> Hi Grant,
>>>
>>> thanks for the help. As you might have already read, I can now boot wit=
h
>>> a
>>> self-written DTS file based of the device-tree.
>>> My three questions still remain.
>>>
>>> * Why not more than 4MB during boot
>>
>> First, are you building a cuImage, or a uImage? =A0It sounds like you're
>> building a cuImage to work with an older version of U-Boot. =A0With a
>> newer version of u-boot you can pass u-boot a kernel image and a
>> device tree blob (.dtb) which doesn't have this limitation.
>>
>
> Ok, I am building a simpleImage right now, since the routerboard (RB600A)
> does not seem to have uboot in the nand.
> Reading through the documentation again it clearly states that the
> simpleimage just uses the provided DTS file and nothing else.

Ah, okay.  Yeah, simpleImage gets you going, but ultimately it isn't
what you need.  I wrote simpleimage when I was working with Xilinx
Virtex platforms when booting a kernel with absolutely no firmware
support.

> The bootloader is called RouterBoot.
> So what the Board does (according to the docs).
>
> * During start it searches for a partition of type 0x27 in one CF slot. I=
f
> it finds the partition it expects a kernel in there and just boots it add=
ing
> a few parameters.

So, what you need is a new adapter which parses the data passed in by
routerboot (maybe call it routerImage?) and modifies the .dtb blob to
match.  You can use simpleImage as a starting point.

>> There is no reason for the 4MB limit in a cuImage other than that is
>> what is specified by default in arch/powerpc/boot/wrapper. =A0You can
>> change it. =A0It is not ideal, and the wrapper could be made more
>> robust, but it is what we have for the moment.
>>
>
> If you are talking about link_address=3D'0x400000'.
> I can increase this somewhat, if I Increase this too much I get a "Kernel
> region out of range" error from the boards bootloader apparently.
>
> To cut this short. I do need uboot on the board for either cuImage or uIm=
age
> support, right?

Yes, uImage and cuImage.* are u-boot specific.  You need a routerboard
specific image.

> Since the routerboard does have its own bootloader and I have not tried i=
f
> it is able to use a cuImage right now, is there another way to add the TB=
I
> entries?

TBI?

> Can't I just add them in the rbppc.c specific init stuff programmatically
> withouth a DTS file?

You need a device tree.  You could theoretically generate the entire
tree programmatically, but that is the long way around.  What you want
is a base .dts file and a new bootwrapper to fill in the missing bits
at boot time.

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely <grant.likely@secretlab.ca>
wrote:
> 
> So, what you need is a new adapter which parses the data passed in by
> routerboot (maybe call it routerImage?) and modifies the .dtb blob to
> match.  You can use simpleImage as a starting point.
I had a look at that. And this is what I understood so-far.
SimpleImage just takes the dtb from the segment and parses it as the new
device tree. 

  _dtb_start = .;
  .kernel:dtb : { *(.kernel:dtb) }
  _dtb_end = .;

No I do understand that dtb_start points to this device tree. I also know
that the standard kernel boot-process
is able to read he device tree out of the firmware/bootloader (it works if
I just put with a standard kernel image) but I cannot figure out, where
exactly (in the code) it is doing that. My problem is now that I have zero
documentation of the existing bootloader. All I know is that the prom code
is able to find and parse it.
So now my question, is there a way to get to the device tree at this stage
of the boot process?


>> Can't I just add them in the rbppc.c specific init stuff
programmatically
>> withouth a DTS file?
> 
> You need a device tree.  You could theoretically generate the entire
> tree programmatically, but that is the long way around.  What you want
> is a base .dts file and a new bootwrapper to fill in the missing bits
> at boot time.
Well the board already provides a device tree so all I would need is the
missing entries so the PHYs are detected correctly. So I would modify an
existing tree.


thanks for your help,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche <mike@it-loops.com> wrote:
> On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely <grant.likely@secretlab.c=
a>
> wrote:
>>
>> So, what you need is a new adapter which parses the data passed in by
>> routerboot (maybe call it routerImage?) and modifies the .dtb blob to
>> match. =A0You can use simpleImage as a starting point.
> I had a look at that. And this is what I understood so-far.
> SimpleImage just takes the dtb from the segment and parses it as the new
> device tree.
>
> =A0_dtb_start =3D .;
> =A0.kernel:dtb : { *(.kernel:dtb) }
> =A0_dtb_end =3D .;
>
> No I do understand that dtb_start points to this device tree. I also know
> that the standard kernel boot-process
> is able to read he device tree out of the firmware/bootloader (it works i=
f
> I just put with a standard kernel image)

Only if the firmware supports passing in a device tree.  Many embedded
firmwares do not, in which case the .dtb must be linked into the
bootwrapper statically.

> but I cannot figure out, where
> exactly (in the code) it is doing that.

Every bootwrapper image (simpleBoot, zImage, cuImage, etc.  uImage is
the exception; it doesn't use the bootwarpper) has a function called
platform_init() with the arguments r3, r4, r5, r6, and r7 which hold
the values of those registers when the bootwrapper is called.
platform_init() is called by crt0.S before calling the 'start()' entry
point in main.c and one purpose of it is to adapt the information
available about the board into the device tree.

platform_init is different for each kind of bootwrapper image.  In
simpleboot.c, r3-r7 are simply ignored.  In a cuImage, a pointer to
the bd_info structure is retrieved from r3 (cuboot.h).

> My problem is now that I have zero
> documentation of the existing bootloader. All I know is that the prom cod=
e
> is able to find and parse it.
> So now my question, is there a way to get to the device tree at this stag=
e
> of the boot process?

You mean like loading it of the CF or something?  Yeah, I suppose so
if you wrote a minimal CF driver, but that seems the hard way around
also.  You're far better off to statically link in a .dtb image and
modify it.  If the bootloader doesn't provide you with any useful
information, you can read the SoC registers to detect memory size and
clock rate.  If you're lucky, the bootloader will have already
assigned the correct MAC addresses for you and you can read those out
also.

You can also try inspecting the memory pointed to by r3-r7 and seeing
if any of them point to something interesting.

>>> Can't I just add them in the rbppc.c specific init stuff
> programmatically
>>> withouth a DTS file?
>>
>> You need a device tree. =A0You could theoretically generate the entire
>> tree programmatically, but that is the long way around. =A0What you want
>> is a base .dts file and a new bootwrapper to fill in the missing bits
>> at boot time.
>
> Well the board already provides a device tree so all I would need is the
> missing entries so the PHYs are detected correctly. So I would modify an
> existing tree.

Oh.  So routerboot does understand dtb blobs?  Okay, I didn't
understand that.  Yes, you can call the libfdt functions in your
platform_init() to add the missing nodes.

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

On Mon, 2 Mar 2009 08:08:02 -0700, Grant Likely <grant.likely@secretlab.ca>
wrote:
> On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche <mike@it-loops.com>
wrote:
> You mean like loading it of the CF or something?  Yeah, I suppose so
> if you wrote a minimal CF driver, but that seems the hard way around
> also.  You're far better off to statically link in a .dtb image and
> modify it.  If the bootloader doesn't provide you with any useful
> information, you can read the SoC registers to detect memory size and
> clock rate.  If you're lucky, the bootloader will have already
> assigned the correct MAC addresses for you and you can read those out
> also.



> 
> You can also try inspecting the memory pointed to by r3-r7 and seeing
> if any of them point to something interesting.

Regarding the registers I did a 

printf("Reg: %lu\n", r3); 

after the init of the serial console. While r4 to r7 where empty, I got
back a number 8756... from R3. 
I do not know what's in there though. Is there another better way to get to
the data?


> Oh.  So routerboot does understand dtb blobs?  Okay, I didn't
> understand that.  Yes, you can call the libfdt functions in your
> platform_init() to add the missing nodes.
I don't know if routerboot understands dtb blobs. If I boot with a standard
vmlinux image the board boots
as well so I think that the firmware provides a tree the prom code can
read. 
As for adding additional information to the tree, can I also use libfdt
functions in platform/83xx/rbppc.c or is it better to do this via a
dedicated platform_init that simpleboot then uses?


Once again thank you very much for helping me with this,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

On Tue, 03 Mar 2009 08:35:02 +0100, Michael Guntsche <mike@it-loops.com>
wrote:
> As for adding additional information to the tree, can I also use libfdt
> functions in platform/83xx/rbppc.c or is it better to do this via a
> dedicated platform_init that simpleboot then uses?

Sorry, please forget this quesiton. Of course simpleboot only reads the
embedded tree 
so if I change the tree there it is the same as changing the initial DTS
file.
I will try to boot with a standard vmlinux image and then add the values in
rbppc.c.

Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

On Tue, Mar 3, 2009 at 2:49 AM, Michael Guntsche <mike@it-loops.com> wrote:
> On Tue, 03 Mar 2009 08:35:02 +0100, Michael Guntsche <mike@it-loops.com>
> wrote:
>> As for adding additional information to the tree, can I also use libfdt
>> functions in platform/83xx/rbppc.c or is it better to do this via a
>> dedicated platform_init that simpleboot then uses?

I'd do this in the bootwrapper.  I think it is easier to follow and
understand that way.

> Sorry, please forget this quesiton. Of course simpleboot only reads the
> embedded tree
> so if I change the tree there it is the same as changing the initial DTS
> file.
> I will try to boot with a standard vmlinux image and then add the values in
> rbppc.c.

Okay, that makes more sense.  So, now if you want a common wrapper
image to boot on all of the routerboard variants, then you need to
pull all the tricks you have out of your hat to figure out what board
it is running on so that the .dtb can be updated.  Is there an eeprom
or something on the board which might store serial numbers or MAC
addresses?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

I'm posting this back on the mailing list.  You're not being dense and
there are good questions here which others might elaborate more on.

On Tue, Mar 3, 2009 at 2:56 PM, Michael Guntsche <mike@it-loops.com> wrote:
> The routeboard is already providing a device-tree albeit not a very good
> one, otherwise the board would not boot in the first please if I just use=
 a
> plain kernel

I need more information here.  What do you mean when you say "plain
kernel".  What file from the build process do you use, and how do you
boot it?

> without an embedded tree. I need to fix this device tree since the new
> gianfar network code is expecting
>
> tbi-handle =3D <&tbi1>;
>
> Entries in the ethernet nodes to find the PHY devices. I do not know if y=
ou
> looked at the source of rbppc.c in detail. There is already code in there=
 to
> init the PCI bus
> since the tree is missing data for this.

I don't see a file named rbppc.c in the current kernel tree.

> * Why can't I just add those missing values in the setup-arch section of =
the
> code?

You might be able to use of_attach_node() & prom_add_property() to
modify the tree, but I've never done it myself.  Give it a try and
tell me if it works.  :-)

> =A0They are needed to init the NICs correctly so I can fix this here befo=
re
> the driver is loaded

Another option is to add a workaround to the driver.  This isn't
ideal, but driver authors aren't supposed to break device tree
bindings either.  Drivers are supposed to remain backwards compatible
with older device trees (either by patching the device tree or with
explicit workarounds).  Downside is that this type of change may be
harder to get merged.  And it's just plain not very pretty.

> * How could I add those information?
> =A0Can't I just do something similar to platforms/iseries/vio.c
> =A0(add_string_property and do_device_node)?

Maybe.  I don't know why those functions are tucked away in vio.c
instead of being common code.  If you go that approach, refactor the
functions you use to be shared.

> This wold have the benefit of getting the rest of the data from the board
> and just patch it with the needed values.

This is definitely preferred to wholesale replacement of the available tree=
.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

On Mar 4, 2009, at 16:57, Grant Likely wrote:

> I need more information here.  What do you mean when you say "plain
> kernel".  What file from the build process do you use, and how do you
> boot it?
>
I build the kernel with

  make ARCH="powerpc" CROSS_COMPILE="powerpc-linux-gnu-" vmlinux

I take the kernel file and add a kernparm segment to it, where I  
specify my root directory.
Then I dd the file to the first partition of my CF card on the board.
As I said before, the bootloader looks at the first partition of the  
CF-card with a partition type of 0x27.
It expects a standard elf kernel to be in there and boots that.
That's all there is to it.

>
> I don't see a file named rbppc.c in the current kernel tree.
>
Sorry, this patch is not in mainline yet. You can find it at

http://cynigram.com/~nfontes/rb600/

It adds the pata driver, and the board specific stuff to the stock  
kernel.
The patch applies cleanly to 2.6.28.x but fails due to the gianfar  
related changes in the 2.6.29 release cycle.


>> You might be able to use of_attach_node() & prom_add_property() to
> modify the tree, but I've never done it myself.  Give it a try and
> tell me if it works.  :-)

I am trying to do it this way right now, when I was looking at them I  
was just wondering if those two functions were the correct ones to use.

As for backwards compatibility. All in-tree drivers were fixed as well  
to work with the new code so you cannot call this change breakage IMHO.
Off-tree code that is affected by it (like the one I am struggling  
with right now) just has to follow those changes. I do not think that  
the changes broke any
defined interface standards.

It would be a lot easier if the board would use uboot or cuboot in the  
first place, but there is no way I can change that, other thanflashing  
the boot-loader
itself NS I am neither brave nor knowledgeable enough to try that  
anyway.

Kind regards,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Michael Guntsche]

On Wed, 4 Mar 2009 08:57:59 -0700, Grant Likely <grant.likely@secretlab.ca>
wrote:
> You might be able to use of_attach_node() & prom_add_property() to
> modify the tree, but I've never done it myself.  Give it a try and
> tell me if it works.  :-)
> 

Hello Grant,

I made some progress in this area, but I have now hit a problem I do not
know how to solve.
Taking code from the iseries/vio.c files I am able to add properties with
add_string_property and add_raw_property. 
The problem I have is adding properties like

    reg = <0x2520 0x20>

I know how to add a property

   reg = <0x2520>

but I do not know what data structure to pass to add_raw_property to add
two numbers there.

Kind regards,
Michael

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

On Thu, Mar 5, 2009 at 12:41 AM, Michael Guntsche <mike@it-loops.com> wrote=
:
> On Wed, 4 Mar 2009 08:57:59 -0700, Grant Likely <grant.likely@secretlab.c=
a>
> wrote:
>> You might be able to use of_attach_node() & prom_add_property() to
>> modify the tree, but I've never done it myself. =A0Give it a try and
>> tell me if it works. =A0:-)
>>
>
> Hello Grant,
>
> I made some progress in this area, but I have now hit a problem I do not
> know how to solve.
> Taking code from the iseries/vio.c files I am able to add properties with
> add_string_property and add_raw_property.
> The problem I have is adding properties like
>
> =A0 =A0reg =3D <0x2520 0x20>
>
> I know how to add a property
>
> =A0 reg =3D <0x2520>
>
> but I do not know what data structure to pass to add_raw_property to add
> two numbers there.

Device tree properties are just "bags of bytes".  'cells' in device
tree nomenclature are big endian u32 values.  So, for specifying a
property with one cell (ie: reg =3D <0x2520>;), the data length is 4
bytes and the data is an array of 4 bytes: 0x00 0x00 0x25 0x20.  To
add a property with two cells (ie: reg =3D <0x2520 0x20>;), the data
length is 8 bytes and the data is and array of 8 bytes: 0x00 0x00 0x25
0x20 0x00 0x00 0x00 0x20.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Wolfgang Ocker]

On Thu, 2009-02-26 at 20:15 +0100, Michael Guntsche wrote:
> For testing purposes I tried a recent git snapshot and noticed  
> that the gianfar driver had problems.
> While the the Gianfar was detected
> [...]
> trying to up either of the devices gave me
> 
> [    8.724818] mdio@24520:01 not found
> [    8.728330] eth1: Could not attach to PHY
> [    8.732945] mdio@24520:01 not found
> [    8.737720] eth1: Could not attach to PHY

I saw exactly the same symptoms on an 8560 board, and the patch below
helped. But I have no idea what's going on there ...

Wolfgang

From: Wolfgang Ocker <weo@reccoware.de>
Date: Sat, 7 Mar 2009 14:27:50 +0100
Subject: [PATCH] fsl-gianfar: improved detection of unoccupied PHY address

At least on one 8560 board the id 0x000ffff is returned at an
unoccupied PHY address.

Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
---
 drivers/net/gianfar_mii.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index f49a426..9c5e0c1 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -211,7 +211,7 @@ static int gfar_mdio_find_free(struct mii_bus *new_bus)
 		if (get_phy_id(new_bus, i, &phy_id))
 			return -1;
 
-		if (phy_id == 0xffffffff)
+		if (phy_id == 0xffffffff || phy_id == 0x0000ffff)
 			break;
 	}
 
-- 
1.6.0.6