[U-Boot-Users] quit unclear code in cpu/arm920t/at91rm9200/ether.c Line:220

[U-Boot-Users] quit unclear code in cpu/arm920t/at91rm9200/ether.c Line:220

[Udo Jakobza]

Hello,

inside of arm_init() in the part:

/* MII management start from here */
if (!(p_mac->EMAC_SR & AT91C_EMAC_LINK)) {
		if (!(ret = PhyOps.Init (p_mac))) {
			printf ("MAC: error during MII initialization\n");
			return 0;
		} 
	}
the software checks the status of a LINK-Bit. I thing the EMAC_SR register is wrong, because the EMAC_ISR has this valid LINK bit 
(AT91C_EMAC_LINK on bit 9).

Did anybody find this problem?
If not, so I will check it with our hardware and then I will prepare a patch.

Thanks and Regards

Udo
Forschungs- und Transferzentrum Leipzig e. V.
an der HTWK Leipzig
Udo Jakobza
W?chterstr. 13
04107 Leipzig
Tel: +49(0)341 3076 1136
Fax: +49(0)341 3076 1220

[U-Boot-Users] quit unclear code in cpu/arm920t/at91rm9200/ether.c Line:220

[Marco Cavallini]

Udo Jakobza ha scritto:
 > Hello,
 >
 > inside of arm_init() in the part:
 >
 > /* MII management start from here */
 > if (!(p_mac->EMAC_SR & AT91C_EMAC_LINK)) {
 > 		if (!(ret = PhyOps.Init (p_mac))) {
 > 			printf ("MAC: error during MII initialization\n");
 > 			return 0;
 > 		}
 > 	}
 > the software checks the status of a LINK-Bit. I thing the EMAC_SR 
register is wrong, because the EMAC_ISR has this valid LINK bit
 > (AT91C_EMAC_LINK on bit 9).
 >
 > Did anybody find this problem?
 > If not, so I will check it with our hardware and then I will prepare 
a patch.
 >

You are right.
I am facing to this annoying error message too
"MAC: error during MII initialization"
when forcing the MAC adress into u-boot if I do not u-boot networking.

A patch will be greatly appreciated ;-)
Thank you
-- 
Marco Cavallini
Koan s.a.s. - Bergamo - ITALIA
Embedded and Real-Time Software Engineering
www.koansoftware.com    |    www.klinux.org

[U-Boot-Users] quit unclear code in cpu/arm920t/at91rm9200/ether.c Line:220

[Wolfgang Denk]

In message <4450E1E5.3010706@koansoftware.com> you wrote:
>
> I am facing to this annoying error message too
> "MAC: error during MII initialization"
> when forcing the MAC adress into u-boot if I do not u-boot networking.

Don't do it, then.

There is no need to set the MAC addres when NOT using the network  in
U-Boot. See the FAQ.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If all you have is a hammer, everything looks like a nail.

[U-Boot-Users] quit unclear code in cpu/arm920t/at91rm9200/ether.c Line:220

[Lars Munch]

On Thu, Apr 27, 2006 at 01:12:50PM +0200, Udo Jakobza wrote:
> Hello,
> 
> inside of arm_init() in the part:
> 
> /* MII management start from here */
> if (!(p_mac->EMAC_SR & AT91C_EMAC_LINK)) {
> 		if (!(ret = PhyOps.Init (p_mac))) {
> 			printf ("MAC: error during MII initialization\n");
> 			return 0;
> 		}
> 	}
> the software checks the status of a LINK-Bit. I thing the EMAC_SR register is wrong, because the EMAC_ISR has this valid LINK bit
> (AT91C_EMAC_LINK on bit 9).
> 
> Did anybody find this problem?
> If not, so I will check it with our hardware and then I will prepare a patch.

Yes, that code is wrong. The line:

if (!(p_mac->EMAC_SR & AT91C_EMAC_LINK)) {

makes no sense and always returns true. IMHO we should remove it
completely and always run the PhyOps.Init function. Checking on the
EMAC_ISR register is also wrong since it indicates link changes and is
AFAIK phy dependent and needs to have interrupts enabled.

On most at91rm9200 based systems I have worked on, I do not have link
yet when PhyOps.Init is called. So I have added a small loop in my phy
code waiting for link before returning (max 5 seconds).

Regards
Lars Munch

[U-Boot-Users] quit unclear code in cpu/arm920t/at91rm9200/ether.c Line:220

[Wolfgang Denk]

In message <20060502115845.GA20961@tuxedo.skovlyporten.dk> you wrote:
>
> makes no sense and always returns true. IMHO we should remove it
> completely and always run the PhyOps.Init function. Checking on the
> EMAC_ISR register is also wrong since it indicates link changes and is
> AFAIK phy dependent and needs to have interrupts enabled.
> 
> On most at91rm9200 based systems I have worked on, I do not have link
> yet when PhyOps.Init is called. So I have added a small loop in my phy
> code waiting for link before returning (max 5 seconds).

Maybe you can submit a patch?

Thanks in advance.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the realm of scientific observation, luck is granted only to those
who are prepared.                                     - Louis Pasteur

[U-Boot-Users] quit unclear code in cpu/arm920t/at91rm9200/ether.c Line:220

[Martin Krause]

Hi,

u-boot-users-admin at lists.sourceforge.net wrote on :
> inside of arm_init() in the part:

It's in eth_init() ...

> /* MII management start from here */
> if (!(p_mac->EMAC_SR & AT91C_EMAC_LINK)) {
> 		if (!(ret = PhyOps.Init (p_mac))) {
> 			printf ("MAC: error during MII initialization\n");
> 			return 0;
> 		}
> 	}
> the software checks the status of a LINK-Bit. I thing the EMAC_SR
> register is wrong, because the EMAC_ISR has this valid LINK bit
> (AT91C_EMAC_LINK on bit 9).

I think you are right. Due to the AT91RM9200 datasheet (Rev. 
1768B-ATRM-08/03) bit 0 of the EMAC_SR (ETH_SR) is labeld with
"LINK" and not bit 9. But the description for the "LINK" bit (bit 0)
is "reserved". So this bit couldn't be used at all.

Im'n not sure, if EMAC_ISR register bit 9 is suitable for testing
the link satus. The datasheet says for this bit: "LINK: Set when LINK 
pin changes value. Optional.". Wich pin is the "link" pin? In my
opinion the AT91RM9200 doesn't has such a pin . And is a LINK change
really what we want to test here (a "link" to "no link" transition is 
also a link change, not only a "no link" to "link" transition)?

> Did anybody find this problem?

No, no problem. The current code is wrong, anyway.

> If not, so I will check it with our hardware and then I will prepare
> a patch. 

This would be great!

Regards,
Martin