Message-ID: <eb230a32-002f-0da0-08d0-b9ed68ee886f@microchip.com>
Date:   Fri, 22 Mar 2019 14:58:16 +0000
From:   <Nicolas.Ferre@...rochip.com>
To:     <ada@...rsis.com>
CC:     <netdev@...r.kernel.org>, <harini.katakam@...inx.com>,
        <u-boot@...ts.denx.de>, <Eugen.Hristev@...rochip.com>,
        <rafalo@...ence.com>, <Claudiu.Beznea@...rochip.com>
Subject: Re: macb: MID register on SAMA5D2 series?

On 22/03/2019 at 11:49, Alexander Dahl wrote:
> External E-Mail
> 
> 
> Hei hei,
> 
> while bringing up support for a new SAMA5D27 based board I noticed something
> strange in the macb driver in both U-Boot and Linux. There's a function in
> both to determine if or not the IP block in the SoC is the gigabit variant,
> commonly refered to as GEM.
> 
> The function in U-Boot:
> 
> 	static int macb_is_gem(struct macb_device *macb)
> 	{
> 		return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) >= 0x2;
> 	}
> 
> And in Linux:
> 
> 	static bool hw_is_gem(void __iomem *addr, bool native_io)
> 	{
> 	        u32 id;
> 	
> 	        if (native_io)
> 	                id = __raw_readl(addr + MACB_MID);
> 	        else
> 	                id = readl_relaxed(addr + MACB_MID);
> 	
> 	        return MACB_BFEXT(IDNUM, id) >= 0x2;
> 	}
> 
> In both cases a register MID is read, in both cases that has an offset of
> 0x00fc.
> 
> 	#define MACB_MID				0x00fc
> 
> I studied the register layouts in the datasheets for AT91SAM9G20, SAMA5D2
> series, SAMA5D3 series, and SAMA5D4 series. In all but SAMA5D2, offset 0x00fc
> is marked as reserved for both EMAC and GMAC variants.

This is a failure with new (rev C) datasheet of sama5d2. I advice you to 
have a look at a previous datasheet revision (rev B) for this part: 
contact your Microchip representative of open a "support ticket" 
following this link:
http://support.microchip.com
And clicking on "My Support" then the "My Cases" button.

I'm of course reporting it as well internally for a correction of the 
next datasheet (but it can take some time).

Module ID Register is always at address 0xFC and "Module identification 
number" bits are at 31:16 and contain 0x2 for "GEM" revision.

On sama5d2, I read: 0x00020203

Note that this doesn't mean that the IP is capable of doing 1Gbits/s 
transfers: typically SAMA5D2 has GEM but configured in hardware to only 
support 10/100 Mbits/s.

> SAMA5D2 however has a register GMAC_EFTSH (GMAC PTP Event Frame Transmitted
> Seconds High Register) at this offset. Because the check for SAMA5D2 is broken
> in U-Boot since v2017.09-111-g245cbc583d (I will send a patch for that today),
> I got some weird behaviour with our new SAMA5D27 based board. While the
> SAMA5D27-SOM1-EK worked fine in U-Boot, our board did not, but reported
> Gigabit Speed on the ethernet link, which is neither supported by SAMA5D2 nor
> by the ethernet PHY (LAN8720A).
> 
> I suppose the register content at that offset on that SoC, just does not give
> that MID? That would be in line with the SAMA5D2 datasheet, and the detection
> on those SoCs currently works or does not only by chance in U-Boot? However
> that register offset was introduced in both U-Boot and Linux long time ago,
> back in 2011 or 2012, so maybe that IP block looks somewhat different on non
> Atmel/Microchip SoCs?
> 
> Is there some secret meaning to that register offset, not documented in all
> those Atmel/Microchip datasheets? Or is that check just wrong on those
> platforms and nobody noticed yet?
> 
> I would care to send patches, but I would like to get an idea first on what is
> supposed to be in that register. At least I'd like to get the behaviour for
> SAMA5D27 fixed, and would be happy for advice on that. If someone else wants
> to step in, I would happily test it. ;-)
> 
> Sorry if I put anyone on Cc, who is not involved in that macb drivers anymore.
> The get-maintainer scripts on both Linux and U-Boot don't return a maintainer,
> so I got some people from the last commits on each. O:-)

Sorry for this error in our documentation.

Best regards,
-- 
Nicolas Ferre

Powered by blists - more mailing lists