[U-Boot] Micrel Controller KSZ8841-16MBL
Hi all,
I need some help here...
I'm working on adding a driver for KSZ8841 ethernet controller which I found at this forum: blackfin.uclinux.org.
I was looking at the mail list archive and found a message from Prafulla answering Raphael Amorin.
Mr. Prafulla suggested him to add the input code into drivers/net/phy/ and public interfaces in netdev.h
Since drivers/net/phy/ does not exist anymore, I'm assuming that input code should go to drivers/net/ instead.
But what about the public interfaces (aka. eth_init, eth_send)? Where should it go?
Thanks for your time, Best regards, Douglas
[tags: KSZ8841; KSZ8842; KSZ884X; KS8841; KS8842; KS884X; Micrel; Ethernet Controller]
On 6/10/2010 12:02 PM, Douglas Lopes Pereira wrote:
Hi all,
I need some help here...
I'm working on adding a driver for KSZ8841 ethernet controller which I found at this forum: blackfin.uclinux.org.
I was looking at the mail list archive and found a message from Prafulla answering Raphael Amorin.
Mr. Prafulla suggested him to add the input code into drivers/net/phy/ and public interfaces in netdev.h
Since drivers/net/phy/ does not exist anymore, I'm assuming that input code should go to drivers/net/ instead.
Huh? drivers/net/phy does exist... But the KS8841 is a MAC/PHY, so belongs in driver/net proper.
But what about the public interfaces (aka. eth_init, eth_send)? Where should it go?
You're using an out-of-date API. Please read the documentation (doc/README.drivers.eth)
I actually wrote a driver for this controller a few years ago, but didn't submit it because at the time it didn't make sense to submit my board and we don't allow bare drivers (ones for which there is no in-tree board). If you'd like, I can clean up the driver and send it to you, and then put it in the tree. Unfortunately I don't have hardware to test it on anymore.
Thanks for your time, Best regards, Douglas
regards, Ben
Hi Ben,
thanks for the quick reply.
On Thu, Jun 10, 2010 at 4:18 PM, Ben Warren biggerbadderben@gmail.comwrote:
On 6/10/2010 12:02 PM, Douglas Lopes Pereira wrote:
Hi all,
I need some help here...
I'm working on adding a driver for KSZ8841 ethernet controller which I found at this forum: blackfin.uclinux.org.
I was looking at the mail list archive and found a message from Prafulla answering Raphael Amorin.
Mr. Prafulla suggested him to add the input code into drivers/net/phy/ and public interfaces in netdev.h
Since drivers/net/phy/ does not exist anymore, I'm assuming that input code should go to drivers/net/ instead.
Huh? drivers/net/phy does exist... But the KS8841 is a MAC/PHY, so belongs in driver/net proper.
But what about the public interfaces (aka. eth_init, eth_send)? Where
should it go?
You're using an out-of-date API. Please read the documentation (doc/README.drivers.eth)
I will take a look at the documentation.
I actually wrote a driver for this controller a few years ago, but didn't submit it because at the time it didn't make sense to submit my board and we don't allow bare drivers (ones for which there is no in-tree board). If you'd like, I can clean up the driver and send it to you, and then put it in the tree. Unfortunately I don't have hardware to test it on anymore.
If it is not taking much of your effort, I would appreciate to have a path/copy of the driver.
Thanks for your time,
Best regards, Douglas
regards, Ben
Thank again, Regards, Douglas
On Sat, Jun 12, 2010 at 7:35 PM, Mike Frysinger vapier@gentoo.org wrote:
On Thu, Jun 10, 2010 at 3:18 PM, Ben Warren wrote:
Huh? drivers/net/phy does exist... But the KS8841 is a MAC/PHY, so belongs in driver/net proper.
unrelated, but the current phy/ subdir isnt a phylib setup like linux, right ?
Not yet.
-mike
--Ben
Hi all,
I managed to get KS8841 driver recognized by u-boot. But I'm certain that it was not in the correct way.
The driver I've found on BlackFin forum was written for a 2008 u-boot version and we are working on a 1.3.1 (very old) version. So I just modify some function calls.
The problem is that the KS8841 driver does not have a ks884x_initialize function. So we created it. All it does is create and fill an eth_device structure. Register it using eth_register function and them it should initialize the PHY (that is what I suppose it should do).
Since I am not sure on how to do that, I just called the ks884x_init function.
It ends in a TRAP message just after the Micrel device being printed at the console.
Could anyone point me out some directions to get my driver correctly initialized?
Thanks for your time.
Regards, Douglas
On Sun, Jun 13, 2010 at 1:18 AM, Ben Warren biggerbadderben@gmail.comwrote:
On Sat, Jun 12, 2010 at 7:35 PM, Mike Frysinger vapier@gentoo.org wrote:
On Thu, Jun 10, 2010 at 3:18 PM, Ben Warren wrote:
Huh? drivers/net/phy does exist... But the KS8841 is a MAC/PHY, so belongs in driver/net proper.
unrelated, but the current phy/ subdir isnt a phylib setup like linux, right ?
Not yet.
-mike
--Ben
Hi Douglas,
On Tue, Jun 15, 2010 at 7:24 AM, Douglas Lopes Pereira < douglaslopespereira@gmail.com> wrote:
Hi all,
I managed to get KS8841 driver recognized by u-boot. But I'm certain that it was not in the correct way.
The driver I've found on BlackFin forum was written for a 2008 u-boot version and we are working on a 1.3.1 (very old) version. So I just modify some function calls.
The problem is that the KS8841 driver does not have a ks884x_initialize function. So we created it. All it does is create and fill an eth_device structure. Register it using eth_register function and them it should initialize the PHY (that is what I suppose it should do).
Since I am not sure on how to do that, I just called the ks884x_init function.
It ends in a TRAP message just after the Micrel device being printed at the console.
Could anyone point me out some directions to get my driver correctly initialized?
Looks like that driver's using the old API. I have my new one almost
finished and will send it to you today. Hopefully debugging it will be trivial.
Thanks for your time.
Regards, Douglas
regards,
Ben
On Tue, Jun 15, 2010 at 9:14 AM, Ben Warren biggerbadderben@gmail.com wrote:
Hi Douglas,
On Tue, Jun 15, 2010 at 7:24 AM, Douglas Lopes Pereira < douglaslopespereira@gmail.com> wrote:
Hi all,
I managed to get KS8841 driver recognized by u-boot. But I'm certain that it was not in the correct way.
The driver I've found on BlackFin forum was written for a 2008 u-boot version and we are working on a 1.3.1 (very old) version. So I just modify some function calls.
The problem is that the KS8841 driver does not have a ks884x_initialize function. So we created it. All it does is create and fill an eth_device structure. Register it using eth_register function and them it should initialize the PHY (that is what I suppose it should do).
Since I am not sure on how to do that, I just called the ks884x_init function.
It ends in a TRAP message just after the Micrel device being printed at the console.
Could anyone point me out some directions to get my driver correctly initialized?
Looks like that driver's using the old API. I have my new one almost
finished and will send it to you today. Hopefully debugging it will be trivial.
I've just started looking at doing a KS8851 driver (on SPI) for one of the OMAP4 boards.
Did you start from scratch with the KS8841 driver or did you begin with Micrel sample code?
The Micrel sample u-boot driver clearly can't be used as is since it doesn't even come close to following the coding style guidelines (CamelCase, etc) and is for an older u-boot revision.
I'm debating whether it makes more sense to correct the coding style on the vendor code, or just start from scratch. Any advice based on your experience?
Steve
Hi Steve,
On 6/22/2010 4:44 PM, Steve Sakoman wrote:
On Tue, Jun 15, 2010 at 9:14 AM, Ben Warrenbiggerbadderben@gmail.com wrote:
Hi Douglas,
On Tue, Jun 15, 2010 at 7:24 AM, Douglas Lopes Pereira< douglaslopespereira@gmail.com> wrote:
Hi all,
I managed to get KS8841 driver recognized by u-boot. But I'm certain that it was not in the correct way.
The driver I've found on BlackFin forum was written for a 2008 u-boot version and we are working on a 1.3.1 (very old) version. So I just modify some function calls.
The problem is that the KS8841 driver does not have a ks884x_initialize function. So we created it. All it does is create and fill an eth_device structure. Register it using eth_register function and them it should initialize the PHY (that is what I suppose it should do).
Since I am not sure on how to do that, I just called the ks884x_init function.
It ends in a TRAP message just after the Micrel device being printed at the console.
Could anyone point me out some directions to get my driver correctly initialized?
Looks like that driver's using the old API. I have my new one almost
finished and will send it to you today. Hopefully debugging it will be trivial.
I've just started looking at doing a KS8851 driver (on SPI) for one of the OMAP4 boards.
Did you start from scratch with the KS8841 driver or did you begin with Micrel sample code?
The Micrel sample u-boot driver clearly can't be used as is since it doesn't even come close to following the coding style guidelines (CamelCase, etc) and is for an older u-boot revision.
I'm debating whether it makes more sense to correct the coding style on the vendor code, or just start from scratch. Any advice based on your experience?
A few years ago I wrote a driver for KS8841 and got it working (16-bit memory-mapped on PowerPC). I started with the Micrel driver, but as you know it's pretty ugly. Last week I dusted off that old driver and got it to compile with the latest U-boot, but wasn't able to test it because the company that I worked for is long gone. It's hopefully close to functional, but still has too many style issues to post publicly. I sent the driver to Douglas off-line, and am awaiting feedback. If you'd like, I can send it to you too. It'd be nice to have a single driver that handles different chips, but with configurable accessors.
Steve
regards, Ben
Hi Ben,
I was able to integrate your driver to u-boot and load it on my PowerPC board. Since the device was not recognized, I started debugging it and found some hardware issues.
For some reason we are not able to change the bank registers by writing the bank number into 30e address. Ps. I'm writing directly to the memory, so it not driver related.
Hardware team is still working on that and once it is fixed, we will be able to test your driver.
Steve, if you have any success on using Ben's driver or if I can be of any help, please let me know.
Regards, Douglas
On Tue, Jun 22, 2010 at 9:26 PM, Ben Warren biggerbadderben@gmail.comwrote:
Hi Steve,
On 6/22/2010 4:44 PM, Steve Sakoman wrote:
On Tue, Jun 15, 2010 at 9:14 AM, Ben Warrenbiggerbadderben@gmail.com wrote:
Hi Douglas,
On Tue, Jun 15, 2010 at 7:24 AM, Douglas Lopes Pereira< douglaslopespereira@gmail.com> wrote:
Hi all,
I managed to get KS8841 driver recognized by u-boot. But I'm certain that it was not in the correct way.
The driver I've found on BlackFin forum was written for a 2008 u-boot version and we are working on a 1.3.1 (very old) version. So I just modify some function calls.
The problem is that the KS8841 driver does not have a ks884x_initialize function. So we created it. All it does is create and fill an eth_device structure. Register it using eth_register function and them it should initialize the PHY (that is what I suppose it should do).
Since I am not sure on how to do that, I just called the ks884x_init function.
It ends in a TRAP message just after the Micrel device being printed at the console.
Could anyone point me out some directions to get my driver correctly initialized?
Looks like that driver's using the old API. I have my new one almost
finished and will send it to you today. Hopefully debugging it will be trivial.
I've just started looking at doing a KS8851 driver (on SPI) for one of the OMAP4 boards.
Did you start from scratch with the KS8841 driver or did you begin with Micrel sample code?
The Micrel sample u-boot driver clearly can't be used as is since it doesn't even come close to following the coding style guidelines (CamelCase, etc) and is for an older u-boot revision.
I'm debating whether it makes more sense to correct the coding style on the vendor code, or just start from scratch. Any advice based on your experience?
A few years ago I wrote a driver for KS8841 and got it working (16-bit memory-mapped on PowerPC). I started with the Micrel driver, but as you know it's pretty ugly. Last week I dusted off that old driver and got it to compile with the latest U-boot, but wasn't able to test it because the company that I worked for is long gone. It's hopefully close to functional, but still has too many style issues to post publicly. I sent the driver to Douglas off-line, and am awaiting feedback. If you'd like, I can send it to you too. It'd be nice to have a single driver that handles different chips, but with configurable accessors.
Steve
regards, Ben
On Tue, Jun 22, 2010 at 5:26 PM, Ben Warren biggerbadderben@gmail.com wrote:
A few years ago I wrote a driver for KS8841 and got it working (16-bit memory-mapped on PowerPC). I started with the Micrel driver, but as you know it's pretty ugly. Last week I dusted off that old driver and got it to compile with the latest U-boot, but wasn't able to test it because the company that I worked for is long gone. It's hopefully close to functional, but still has too many style issues to post publicly. I sent the driver to Douglas off-line, and am awaiting feedback. If you'd like, I can send it to you too. It'd be nice to have a single driver that handles different chips, but with configurable accessors.
Yes, please send me a copy! I'll take a look and see if it looks like it will work with the 8851.
I agree it would be quite nice if we could have a single driver.
Steve
Hi Steve.
Did you succeed on running the driver for KS8841? Did you have to change anything?
We are debugging it and some modifications might be necessary for our platform.
Hope to hear from you.
Regards, Douglas
On Tue, Jun 22, 2010 at 11:25 PM, Steve Sakoman sakoman@gmail.com wrote:
On Tue, Jun 22, 2010 at 5:26 PM, Ben Warren biggerbadderben@gmail.com wrote:
A few years ago I wrote a driver for KS8841 and got it working (16-bit memory-mapped on PowerPC). I started with the Micrel driver, but as you know it's pretty ugly. Last week I dusted off that old driver and got it
to
compile with the latest U-boot, but wasn't able to test it because the company that I worked for is long gone. It's hopefully close to
functional,
but still has too many style issues to post publicly. I sent the driver
to
Douglas off-line, and am awaiting feedback. If you'd like, I can send it
to
you too. It'd be nice to have a single driver that handles different
chips,
but with configurable accessors.
Yes, please send me a copy! I'll take a look and see if it looks like it will work with the 8851.
I agree it would be quite nice if we could have a single driver.
Steve
On Tue, Jun 29, 2010 at 8:08 AM, Douglas Lopes Pereira douglaslopespereira@gmail.com wrote:
Hi Steve. Did you succeed on running the driver for KS8841? Did you have to change anything? We are debugging it and some modifications might be necessary for our platform.
Well, after taking a look at the KS8841 driver it didn't look like the KS8851 was software compatible.
I'm waiting for a response from Micrel regarding their sample KS8851 u-boot driver code. After I hear back from them I'll put together some sort of plan, but things are on hold till they respond.
Steve
Hope to hear from you. Regards, Douglas On Tue, Jun 22, 2010 at 11:25 PM, Steve Sakoman sakoman@gmail.com wrote:
On Tue, Jun 22, 2010 at 5:26 PM, Ben Warren biggerbadderben@gmail.com wrote:
A few years ago I wrote a driver for KS8841 and got it working (16-bit memory-mapped on PowerPC). I started with the Micrel driver, but as you know it's pretty ugly. Last week I dusted off that old driver and got it to compile with the latest U-boot, but wasn't able to test it because the company that I worked for is long gone. It's hopefully close to functional, but still has too many style issues to post publicly. I sent the driver to Douglas off-line, and am awaiting feedback. If you'd like, I can send it to you too. It'd be nice to have a single driver that handles different chips, but with configurable accessors.
Yes, please send me a copy! I'll take a look and see if it looks like it will work with the 8851.
I agree it would be quite nice if we could have a single driver.
Steve
Hi Steve,
On 7/1/2010 10:25 AM, Steve Sakoman wrote:
On Tue, Jun 29, 2010 at 8:08 AM, Douglas Lopes Pereira douglaslopespereira@gmail.com wrote:
Hi Steve. Did you succeed on running the driver for KS8841? Did you have to change anything? We are debugging it and some modifications might be necessary for our platform.
Well, after taking a look at the KS8841 driver it didn't look like the KS8851 was software compatible.
I'm waiting for a response from Micrel regarding their sample KS8851 u-boot driver code. After I hear back from them I'll put together some sort of plan, but things are on hold till they respond.
Good luck with that. I predict that you will learn nothing new. Is the register layout different on the KS8851, or just the physical link (SPI vs memory bus)?
regards, Ben
participants (4)
-
Ben Warren -
Douglas Lopes Pereira -
Mike Frysinger -
Steve Sakoman