Re: PHY not found after migration of gianfar driver to an of_platform_driver
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] m...@24520:01 not found [8.728330] eth1: Could not attach to PHY [8.732945] m...@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 w...@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 0x000 is returned at an unoccupied PHY address. Signed-off-by: Wolfgang Ocker w...@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 == 0x) + if (phy_id == 0x || phy_id == 0x) break; } -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Thu, Mar 5, 2009 at 12:41 AM, Michael Guntsche m...@it-loops.com wrote: On Wed, 4 Mar 2009 08:57:59 -0700, Grant Likely grant.lik...@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. 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 = 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 = 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. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
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 m...@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 = tbi1; Entries in the ethernet nodes to find the PHY devices. I do not know if you 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. :-) They are needed to init the NICs correctly so I can fix this here before 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? Can't I just do something similar to platforms/iseries/vio.c (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. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Wed, 4 Mar 2009 08:57:59 -0700, Grant Likely grant.lik...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Tue, 03 Mar 2009 08:35:02 +0100, Michael Guntsche m...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Tue, Mar 3, 2009 at 2:49 AM, Michael Guntsche m...@it-loops.com wrote: On Tue, 03 Mar 2009 08:35:02 +0100, Michael Guntsche m...@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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely grant.lik...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche m...@it-loops.com wrote:
On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely grant.lik...@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)
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 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?
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. 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.
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.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Mon, 2 Mar 2009 08:08:02 -0700, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche m...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
[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 m...@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 m...@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. I should have something for you in the next few days. I 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 with 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? It sounds like you're building a cuImage to work with an older version of U-Boot. With 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. If it finds the partition it expects a kernel in there and just boots it adding 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. You can change it. It 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='0x40'. 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 uImage 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 if it is able to use a cuImage right now, is there another way to add the TBI 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. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
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 = /soc8...@e000/ser...@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.
c...@f920 {
lb-timings = 0x5dc 0x3e8 0x1194 0x5dc 0x2af8;
interrupt-at-level = 0x0;
interrupt-parent = 0x700;
interrupts = 0x16 0x8;
lbc_extra_divider = 0x1;
reg = 0xf920 0x20;
device_type = rb,cf;
};
c...@f900 {
lb-timings = 0x5dc 0x3e8 0x1194 0x5dc 0x2af8;
interrupt-at-level = 0x0;
interrupt-parent = 0x700;
interrupts = 0x14 0x8;
lbc_extra_divider = 0x1;
reg = 0xf900 0x20;
device_type = rb,cf;
};
flash {
reg = 0xff80 0x2;
};
nnand {
reg = 0xf000 0x1000;
};
nand {
ale = 0x400 0x6;
cle = 0x400 0x5;
nce = 0x400 0x4;
rdy = 0x400 0x3;
reg = 0xf800 0x1000;
device_type = rb,nand;
};
fancon {
interrupt-parent = 0x700;
interrupts = 0x17 0x8;
sense = 0x400 0x7;
fan_on = 0x400 0x9;
};
soc8...@e000 {
bus-frequency = 0x1;
reg = 0xe000 0x200;
ranges = 0x0 0xe000 0x10;
device_type = soc;
#interrupt-cells = 0x2;
#size-cells = 0x1;
#address-cells = 0x1;
led {
user_led = 0x400 0x8;
};
beeper {
reg = 0x500 0x100;
};
g...@0 {
reg = 0xc08 0x4;
device-id = 0x0;
compatible = gpio;
device_type = gpio;
linux,phandle = 0x400;
};
ether...@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;
};
ether...@25000 {
phy-handle = 0x8;
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;
};
m...@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-...@0 {
device_type = ethernet-phy;
reg = 0x0;
linux,phandle = 0x8;
};
ethernet-...@1 {
device_type = ethernet-phy;
reg = 0x1;
linux,phandle = 0x80001;
};
tbi0: tbi-...@11 {
reg = 0x11;
device_type = tbi-phy;
};
};
m...@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
Re: PHY not found after migration of gianfar driver to an of_platform_driver
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 m...@it-loops.com wrote: 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] m...@24520:01 not found [ 8.728330] eth1: Could not attach to PHY [ 8.732945] m...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
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 m...@24520.00 or .01 depending on the nic but the only mdio device that exists is m...@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 m...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PHY not found after migration of gianfar driver to an of_platform_driver
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] m...@24520:01 not found [8.728330] eth1: Could not attach to PHY [8.732945] m...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
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;
soc8...@e000 {
bus-frequency = 0x1;
reg = 0xe000 0x200;
ranges = 0x0 0xe000 0x10;
device_type = soc;
#interrupt-cells = 0x2;
#size-cells = 0x1;
#address-cells = 0x1;
g...@0 {
reg = 0xc08 0x4;
device-id = 0x0;
compatible = gpio;
device_type = gpio;
linux,phandle = 0x400;
};
ether...@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;
};
ether...@25000 {
phy-handle = 0x8;
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;
};
m...@24520 {
#size-cells = 0x1;
#address-cells = 0x1;
linux,phandle = 0x800;
reg = 0x24520 0x20;
compatible = gianfar;
device_type = mdio;
ethernet-...@1 {
device_type = ethernet-phy;
reg = 0x1;
linux,phandle = 0x80001;
};
ethernet-...@0 {
device_type = ethernet-phy;
reg = 0x0;
linux,phandle = 0x8;
};
};
cpus {
linux,phandle = 0x200;
#size-cells = 0x0;
#address-cells = 0x1;
#cpus = 0x1;
PowerPC,83...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
