Skip to contentSkip to conversation

AT91SAM9260EK with KS8721 PHY

U-Boot-Users Sander Vermin 4 participants 12 messages Apr 7, 2008 – Apr 8, 2008

lore
Share & tools
lore
#0 lore raw

Hello,

I'm trying to build a U-Boot from your git tree with the AT91 patches. My board is a custom board with a KS8721 instead of the DM9161 network PHY chip. This is the same chip as Olimex used on their development board.

Olimex build a U-Boot for their board, they did some code hacking on u-boot. As far as I know they did the following to get the ethernet up and running. [1] This is in the board/at91sam9260ek/dm9161a.c file

On the latest git version with the AT91 patches the ethernet driver is called macb??!!

Do you know how I can get this working? (as hack and in the future more clean)

Kind regards,

Sander Vermin

[1]
static unsigned int dm9161a_IsPhyConnected (AT91PS_EMAC p_mac)

{
    unsigned short Id1, Id2;

    at91_EmacEnableMDIO (p_mac);
    at91_EmacReadPhy (p_mac, SAM9260EK_PHY_ADDRESS, DM9161_PHYID1, &Id1);
    at91_EmacReadPhy (p_mac, SAM9260EK_PHY_ADDRESS, DM9161_PHYID2, &Id2);
    at91_EmacDisableMDIO (p_mac);
   
    /*printf(" Id1 0x%04x\n", Id1);
    printf(" Id1 0x%04x\n", Id2);*/
   

    if ((Id1 == (DM9161_PHYID1_OUI >> 6)) &&
        ((Id2 >> 10) == (DM9161_PHYID1_OUI & DM9161_LSB_MASK))) {
      printf("DM9161A PHY Detected\n\r");
      return TRUE;
    }
   
    if ((Id1 == MICREL_ID_1) && (Id2 == MICREL_ID_2)) {
        printf("KS8721 PHY Detected\n\r");
        return TRUE;
    }
   
    return FALSE;
}
#1 lore raw

Le lundi 07 avril 2008 ? 15:16 +0200, Sander Vermin a ?crit :

Quoted 9 lines

Hello,

I'm trying to build a U-Boot from your git tree with the AT91 patches. My board is a custom board with a KS8721 instead of the DM9161 network PHY chip. This is the same chip as Olimex used on their development board.

Olimex build a U-Boot for their board, they did some code hacking on u-boot. As far as I know they did the following to get the ethernet up and running. [1] This is in the board/at91sam9260ek/dm9161a.c file

Are the changes limited to recognizing the MICREL_* phy id

Quoted 3 lines

On the latest git version with the AT91 patches the ethernet driver is called macb??!!

Yes.

Quoted 2 lines

Do you know how I can get this working? (as hack and in the future more clean)

Did you test it as is ? From what I see in the code, the macb driver doesn't care much about the PHY type...

Stelian.

Signature · 1 line
Stelian Pop <[email protected]>
#2 lore raw

Stelian Pop a ?crit :

Quoted 7 lines

Le lundi 07 avril 2008 ? 15:16 +0200, Sander Vermin a ?crit :

Quoted 6 lines

Hello,

I'm trying to build a U-Boot from your git tree with the AT91 patches. My board is a custom board with a KS8721 instead of the DM9161 network PHY chip. This is the same chip as Olimex used on their development board.

Quoted 5 lines
Quoted 3 lines

Olimex build a U-Boot for their board, they did some code hacking on u-boot. As far as I know they did the following to get the ethernet up and running. [1] This is in the board/at91sam9260ek/dm9161a.c file

Are the changes limited to recognizing the MICREL_* phy id

from memory, on AT91RM9200 with KS8721SL, it was necessary to tweak some bits in order to change the "isolate" setting of the PHY.

Eric

#3 lore raw
In reply to Stelian Pop

Stelian Pop schreef:

Quoted 22 lines

Le lundi 07 avril 2008 ? 15:16 +0200, Sander Vermin a ?crit :

Quoted 10 lines

Hello,

I'm trying to build a U-Boot from your git tree with the AT91 patches. My board is a custom board with a KS8721 instead of the DM9161 network PHY chip. This is the same chip as Olimex used on their development board.

Olimex build a U-Boot for their board, they did some code hacking on u-boot. As far as I know they did the following to get the ethernet up and running. [1] This is in the board/at91sam9260ek/dm9161a.c file

Are the changes limited to recognizing the MICREL_* phy id

Quoted 3 lines

On the latest git version with the AT91 patches the ethernet driver is called macb??!!

Yes.

Quoted 9 lines
Quoted 3 lines

Do you know how I can get this working? (as hack and in the future more clean)

Did you test it as is ? From what I see in the code, the macb driver doesn't care much about the PHY type...

Stelian.

I did test it, u-boot says no PHY present. I had to change from RMII mode to MII mode due to my hardware design.

Regards,

Sander

#4 lore raw

Le lundi 07 avril 2008 ? 16:14 +0200, Sander Vermin a ?crit :

Quoted 5 lines
Quoted 2 lines

Did you test it as is ? From what I see in the code, the macb driver doesn't care much about the PHY type...

I did test it, u-boot says no PHY present. I had to change from RMII mode to MII mode due to my hardware design.

Ok, so there must be something else in the code which was changed to support your PHY (look for some "isolate" setting like Eric said). You'll need to find out what it is...

Signature · 1 line
Stelian Pop <[email protected]>
#5 lore raw

Stelian Pop a ?crit :

Quoted 5 lines

Le lundi 07 avril 2008 ? 16:14 +0200, Sander Vermin a ?crit :

Quoted 2 lines
Quoted 2 lines

Did you test it as is ? From what I see in the code, the macb driver doesn't care much about the PHY type...

Quoted 7 lines
Quoted 2 lines

I did test it, u-boot says no PHY present. I had to change from RMII mode to MII mode due to my hardware design.

Ok, so there must be something else in the code which was changed to support your PHY (look for some "isolate" setting like Eric said). You'll need to find out what it is...

please find attached a quick and dirty hacked ks8721.c and the corresponding .h
It works on an AT91RM9200 with u-boot 1.3.2.

Eric

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ks8721.c
Type: text/x-csrc
Size: 7208 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080407/a34ed1bf/attachment.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ks8721.h
Type: text/x-chdr
Size: 5093 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080407/a34ed1bf/attachment.h

#6 lore raw

Le lundi 07 avril 2008 ? 22:23 +0200, Eric BENARD a ?crit :

Quoted 9 lines

Stelian Pop a ?crit :

Quoted 8 lines

Le lundi 07 avril 2008 ? 16:14 +0200, Sander Vermin a ?crit :

Quoted 5 lines
Quoted 2 lines

Did you test it as is ? From what I see in the code, the macb driver doesn't care much about the PHY type...

I did test it, u-boot says no PHY present. I had to change from RMII mode to MII mode due to my hardware design.

Quoted 7 lines
Quoted 4 lines

Ok, so there must be something else in the code which was changed to support your PHY (look for some "isolate" setting like Eric said). You'll need to find out what it is...

please find attached a quick and dirty hacked ks8721.c and the corresponding .h
It works on an AT91RM9200 with u-boot 1.3.2.

Hmm, if I sed:

	s/KS8721/DM9161/g
and
	s/ks8721/dm9161/g

on your files I find almost no change with regard to the original version, except:

#define PHY_ADDRESS (1<<5)

and a #if 0 commenting out a bit of the initialisation sequence...

This makes me think it may only be a PHY_ADDRESS issue: what happens if you change in cpu/arm926ejs/at91sam9/ether.c :

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

to

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

Stelian.

Signature · 1 line
Stelian Pop <[email protected]>
#7 lore raw

Stelian Pop a ?crit :

Quoted 5 lines

Hmm, if I sed:

	s/KS8721/DM9161/g
and
	s/ks8721/dm9161/g
Quoted 7 lines

on your files I find almost no change with regard to the original version, except:

#define PHY_ADDRESS (1<<5)

and a #if 0 commenting out a bit of the initialisation sequence...

yes, goal was to make a clean driver starting from dm9161 with PHY_ADDRESS in the config file ... but I didn't had time to progress on it :-(
Isolate problem can happen depending on the pullup/down configuration I think (I didn't check in tthe datasheet, but I once met the problem).

Quoted 9 lines

This makes me think it may only be a PHY_ADDRESS issue: what happens if you change in cpu/arm926ejs/at91sam9/ether.c :

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

to

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

It's not running on a 9260 so I can't test but it should work (and this may be the problem Sander have).

Eric

#8 lore raw

Eric BENARD schreef:

Quoted 24 lines

Stelian Pop a ?crit :

Quoted 5 lines

Hmm, if I sed:

    s/KS8721/DM9161/g
and
    s/ks8721/dm9161/g
Quoted 7 lines

on your files I find almost no change with regard to the original version, except:

#define PHY_ADDRESS (1<<5)

and a #if 0 commenting out a bit of the initialisation sequence...

yes, goal was to make a clean driver starting from dm9161 with PHY_ADDRESS in the config file ... but I didn't had time to progress on it :-(
Isolate problem can happen depending on the pullup/down configuration I think (I didn't check in tthe datasheet, but I once met the problem).

Quoted 5 lines

This makes me think it may only be a PHY_ADDRESS issue: what happens if you change in cpu/arm926ejs/at91sam9/ether.c :

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

Quoted 8 lines
Quoted 4 lines

to

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

It's not running on a 9260 so I can't test but it should work (and this may be the problem Sander have).

Eric

I did a new build with:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

in stead of:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

But still no PHY detected :-(

The files that Eric send were for a AT91RM9200? and don't work on my AT91SAM9260?

Sander

#9 lore raw

Sander Vermin a ?crit :

Quoted 10 lines

I did a new build with:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

in stead of:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

But still no PHY detected :-(

You need to check your schematic, and the PHY datasheet in order to know what could be the address of your PHY (set by pull up/down resistors on several pins of the PHY at reset of the PHY).

Or you can try a loop on the PHY address and see if it answers at any address ...

Eric

#10 lore raw

Eric BENARD schreef:

Quoted 11 lines

Sander Vermin a ?crit :

Quoted 10 lines

I did a new build with:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

in stead of:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

But still no PHY detected :-(

Quoted 8 lines

You need to check your schematic, and the PHY datasheet in order to know what could be the address of your PHY (set by pull up/down resistors on several pins of the PHY at reset of the PHY).

Or you can try a loop on the PHY address and see if it answers at any address ...

Eric

It works!!

The detection of the PHY works, the base address was 0x01 instead of 0x00.

Wen I try to enable RII mode (CONFIG_CMD_MII) I get all kinds of errors about variable not being found:

macb.c: In function 'miiphy_read':
macb.c:528: error: 'macb' undeclared (first use in this function) macb.c:528: error: (Each undeclared identifier is reported only once macb.c:528: error: for each function it appears in.) macb.c:528: error: 'MACB_EMACB_NCR' undeclared (first use in this function) macb.c:539: error: 'MACB_EMACB_MAN' undeclared (first use in this function) macb.c:542: error: 'MACB_EMACB_NSR' undeclared (first use in this function) macb.c: In function 'miiphy_write':
macb.c:566: error: 'macb' undeclared (first use in this function) macb.c:566: error: 'MACB_EMACB_NCR' undeclared (first use in this function) macb.c:578: error: 'MACB_EMACB_MAN' undeclared (first use in this function) macb.c:581: error: 'MACB_EMACB_NSR' undeclared (first use in this function) make[1]: *** [macb.o] Error 1

Looking at the code I see that macb should be a pointer to "struct macb_device *macb" how should this code work? I don't see any functions point to the miiphy_read an write functions.

Sander

#11 lore raw
In reply to Eric BENARD

Hi,

Quoted 3 lines

Sander Vermin a ?crit :> I did a new build with:> > macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);> > in stead of:> > macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);> > But still no PHY detected :-(> You need to check your schematic, and the PHY datasheet in order to know what could be the address of your PHY (set by pull up/down resistors on several pins of the PHY at reset of the PHY). Or you can try a loop on the PHY address and see if it answers at any address ...

Try this code to do the loop test.

#if defined(CONFIG_YOURBOARD)

#define MAX_PHY_ADDR    64
        for (i = 0 ; i < MAX_PHY_ADDR; i++) {
                macb->phy_addr = i;
                phy_id = macb_mdio_read(macb, MII_PHYSID1);
                if (phy_id != 0xffff)
                        break;
        }
        printf("phy_id %x found at %d\n", phy_id, i);
#else
        phy_id = macb_mdio_read(macb, MII_PHYSID1);

#endif

Michael