[U-Boot-Users] 440GX PHY/MII access

[U-Boot-Users] 440GX PHY/MII access

[Kerl, John]

Hello,

I am wondering if anyone can illuminate the following code snippet,
from ppc_440x_eth_init() in cpu/ppc4xx/440gx_enet.c:

	out32 (ZMII_SSR, ZMII_SSR_SP << ZMII_SSR_V(devnum));
	__asm__ volatile ("eieio");

	/* reset emac so we have access to the phy */
	out32 (EMAC_M0 + hw_p->hw_addr, EMAC_M0_SRST);
	__asm__ volatile ("eieio");

	failsafe = 1000;
	while ((in32 (EMAC_M0 + hw_p->hw_addr) & (EMAC_M0_SRST)) && failsafe) {
		udelay (1000);
		failsafe--;
	}
	in32(EMAC_M0 + hw_p->hw_addr), EMAC_M0 + hw_p->hw_addr);

In particular I don't understand the comment "reset emac so we have
access to the phy".  In fact, print statements before and after
the MAC reset indicate that we *can* read PHY registers before
the MAC reset, but we *lose* the ability to read PHY registers
after the MAC reset.  Note that this does not happen on all
three boards, and not all the time.  Also this loss of PHY-register
access after MAC reset is more likely to happen if the Ethernet cable
is connected.

Now, there are a couple oddities: (1) these are brand-new boards,
still being debugged and flywired; (2) we are using EMACs 2 & 3 over
RGMII, but we have EMACs 0 & 1 not connected to anything (unlike
the Ocotea board).

In particular, I don't doubt that the above code is correct; certainly
the finger of doubt points in the direction of our new board.  Still,
though, I don't yet understand why the MAC reset would cause PHY
access to go away.  The scope reveals that after the MAC reset, the
MDIO line is no longer being driven.

Does this ring any bells for anyone?

Thanks.

[U-Boot-Users] 440GX PHY/MII access

[Carl Riechers]

If you are using address zero for the PHY you will
have problems.  The 440GX seems to use this address
for diagnostics.  I could not find any documentation
on this.  I have a simular configuration with only
eth2 and eth3.  If you are using the Marvel PHYs, make
sure you hardware reset them per the specification
otherwise the soft reset will not work correctly.

The author of the code was most likely using a
different brand of PHY and needed to reset the PHY to
have access to certain registers.  The code
reconfigures the selected MAC to interface with the
serial bus to the PHYs.  Each MAC has a MII serial bus
master, but only one can drive the MII serial
interface to the PHYs though the bridge.

Carl

--- "Kerl, John" <John.Kerl@Avnet.com> wrote:
> Hello,
> 
> I am wondering if anyone can illuminate the
> following code snippet,
> from ppc_440x_eth_init() in cpu/ppc4xx/440gx_enet.c:
> 
> 	out32 (ZMII_SSR, ZMII_SSR_SP <<
> ZMII_SSR_V(devnum));
> 	__asm__ volatile ("eieio");
> 
> 	/* reset emac so we have access to the phy */
> 	out32 (EMAC_M0 + hw_p->hw_addr, EMAC_M0_SRST);
> 	__asm__ volatile ("eieio");
> 
> 	failsafe = 1000;
> 	while ((in32 (EMAC_M0 + hw_p->hw_addr) &
> (EMAC_M0_SRST)) && failsafe) {
> 		udelay (1000);
> 		failsafe--;
> 	}
> 	in32(EMAC_M0 + hw_p->hw_addr), EMAC_M0 +
> hw_p->hw_addr);
> 
> In particular I don't understand the comment "reset
> emac so we have
> access to the phy".  In fact, print statements
> before and after
> the MAC reset indicate that we *can* read PHY
> registers before
> the MAC reset, but we *lose* the ability to read PHY
> registers
> after the MAC reset.  Note that this does not happen
> on all
> three boards, and not all the time.  Also this loss
> of PHY-register
> access after MAC reset is more likely to happen if
> the Ethernet cable
> is connected.
> 
> Now, there are a couple oddities: (1) these are
> brand-new boards,
> still being debugged and flywired; (2) we are using
> EMACs 2 & 3 over
> RGMII, but we have EMACs 0 & 1 not connected to
> anything (unlike
> the Ocotea board).
> 
> In particular, I don't doubt that the above code is
> correct; certainly
> the finger of doubt points in the direction of our
> new board.  Still,
> though, I don't yet understand why the MAC reset
> would cause PHY
> access to go away.  The scope reveals that after the
> MAC reset, the
> MDIO line is no longer being driven.
> 
> Does this ring any bells for anyone?
> 
> Thanks.
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/u-boot-users



	
		
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

[U-Boot-Users] Cascaded U-Boot setup question

[Mike Wellington]

Hi-
   I have multiple Xilinx ML300 boards.  Each one has its own
ip address.  Each board may have different boot parameters - baud
rate, root file system, etc.  Basically each board needs its
own boot parameters stored in some kind of non-volatile storage.
But there is no working non-volatile storage on these boards (yet),
until I get I2C EEPROM working.  Each board just boots from its
copy of u-boot (which is generic) from the microdrive.  Now, I
could sit at each board and as it comes up, stop the autoboot
and manually enter the parameters, but that's clunky.  What
I want to do is build a board-specific u-boot with parameters
that are specific to that machine-name.   So my boot
process would be:

1)  Load the generic u-boot off the microdrive.  It knows what
  *machine-name*  is and where to get the next stage at.

2)  Use the generic u-boot to download a machine-specific u-boot,
     uboot-<machine-name>, which I can recompile and change at will
     since it resides on my tftp server.  I don't have to rewrite
     the microdrive every time I want to change the boot parameters,
     all I have to do is build a new *second-stage* machine-specific
     u-boot-<machine-name> and put it in the /tftp download directory.

3)  Run the 2nd u-boot (u-boot-<machine-name>)
   (which has the machine specific parameters)
     and let it boot the kernel with the arguments that I want.

I tried downloading an uncompressed u-boot and loading it at 0x20000,
then just saying "go 0x20000" and it doesn't work, it generates and
illegal instruction exception.  (is the starting address of u-boot not
at the beginning of the .TEXT section - I'll go check after I send this
email)

I tried downloading a compressed u-boot with '-T standalone' and then
saying "bootm 0x200000"  and that doesn't work either.

Is this doable? It should be.  Does anybody know how to do it?

I guess the other thing I "could" do is run expect on the serial port
and set up the paramters that way, but I think the *cascaded u-boot*
idea is better.

-mike wellington
  wellington at lucent.com
  platforms at bithead.com

[U-Boot-Users] Cascaded U-Boot setup question

[Mike Wellington]

Now I tried:

 > tftp 0x200000 u-boot.bin ;  go 0x200100

U-boot begins execution but hangs after the DRAM message.



Mike Wellington wrote:
> 
> Hi-
>   I have multiple Xilinx ML300 boards.  Each one has its own
> ip address.  Each board may have different boot parameters - baud
> rate, root file system, etc.  Basically each board needs its
> own boot parameters stored in some kind of non-volatile storage.
> But there is no working non-volatile storage on these boards (yet),
> until I get I2C EEPROM working.  Each board just boots from its
> copy of u-boot (which is generic) from the microdrive.  Now, I
> could sit at each board and as it comes up, stop the autoboot
> and manually enter the parameters, but that's clunky.  What
> I want to do is build a board-specific u-boot with parameters
> that are specific to that machine-name.   So my boot
> process would be:
> 
> 1)  Load the generic u-boot off the microdrive.  It knows what
>  *machine-name*  is and where to get the next stage at.
> 
> 2)  Use the generic u-boot to download a machine-specific u-boot,
>     uboot-<machine-name>, which I can recompile and change at will
>     since it resides on my tftp server.  I don't have to rewrite
>     the microdrive every time I want to change the boot parameters,
>     all I have to do is build a new *second-stage* machine-specific
>     u-boot-<machine-name> and put it in the /tftp download directory.
> 
> 3)  Run the 2nd u-boot (u-boot-<machine-name>)
>   (which has the machine specific parameters)
>     and let it boot the kernel with the arguments that I want.
> 
> I tried downloading an uncompressed u-boot and loading it at 0x20000,
> then just saying "go 0x20000" and it doesn't work, it generates and
> illegal instruction exception.  (is the starting address of u-boot not
> at the beginning of the .TEXT section - I'll go check after I send this
> email)
> 
> I tried downloading a compressed u-boot with '-T standalone' and then
> saying "bootm 0x200000"  and that doesn't work either.
> 
> Is this doable? It should be.  Does anybody know how to do it?
> 
> I guess the other thing I "could" do is run expect on the serial port
> and set up the paramters that way, but I think the *cascaded u-boot*
> idea is better.
> 
> -mike wellington
>  wellington at lucent.com
>  platforms at bithead.com
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] Cascaded U-Boot setup question

[VanBaren, Gerald]

Yup, that is the u-boot execute out of RAM issue #1 -- your new u-boot is trying to (re)initialize the RAM that it is executing out of, effectively pulling the rug out from under itself.  You have to suppress the RAM initialization and possibly other hardware initializations (issues #2-#n) in the second u-boot before you can run it.

gvb


> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Mike
> Wellington
> Sent: Tuesday, April 13, 2004 12:22 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Cascaded U-Boot setup question
>
>
> Now I tried:
>
>  > tftp 0x200000 u-boot.bin ;  go 0x200100
>
> U-boot begins execution but hangs after the DRAM message.
>
>
>
> Mike Wellington wrote:
> >
> > Hi-
> >   I have multiple Xilinx ML300 boards.  Each one has its own
> > ip address.  Each board may have different boot parameters - baud
> > rate, root file system, etc.  Basically each board needs its
> > own boot parameters stored in some kind of non-volatile storage.
> > But there is no working non-volatile storage on these boards (yet),
> > until I get I2C EEPROM working.  Each board just boots from its
> > copy of u-boot (which is generic) from the microdrive.  Now, I
> > could sit at each board and as it comes up, stop the autoboot
> > and manually enter the parameters, but that's clunky.  What
> > I want to do is build a board-specific u-boot with parameters
> > that are specific to that machine-name.   So my boot
> > process would be:
> >
> > 1)  Load the generic u-boot off the microdrive.  It knows what
> >  *machine-name*  is and where to get the next stage at.
> >
> > 2)  Use the generic u-boot to download a machine-specific u-boot,
> >     uboot-<machine-name>, which I can recompile and change at will
> >     since it resides on my tftp server.  I don't have to rewrite
> >     the microdrive every time I want to change the boot parameters,
> >     all I have to do is build a new *second-stage* machine-specific
> >     u-boot-<machine-name> and put it in the /tftp download
> directory.
> >
> > 3)  Run the 2nd u-boot (u-boot-<machine-name>)
> >   (which has the machine specific parameters)
> >     and let it boot the kernel with the arguments that I want.
> >
> > I tried downloading an uncompressed u-boot and loading it
> at 0x20000,
> > then just saying "go 0x20000" and it doesn't work, it generates and
> > illegal instruction exception.  (is the starting address of
> u-boot not
> > at the beginning of the .TEXT section - I'll go check after
> I send this
> > email)
> >
> > I tried downloading a compressed u-boot with '-T
> standalone' and then
> > saying "bootm 0x200000"  and that doesn't work either.
> >
> > Is this doable? It should be.  Does anybody know how to do it?
> >
> > I guess the other thing I "could" do is run expect on the
> serial port
> > and set up the paramters that way, but I think the *cascaded u-boot*
> > idea is better.
> >
> > -mike wellington
> >  wellington at lucent.com
> >  platforms at bithead.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President
> and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> >
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > U-Boot-Users mailing list
> > U-Boot-Users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>



******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************