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
