[U-Boot] macb: MID register on SAMA5D2 series?

[Harini Katakam]

Hi Alex,

On Fri, Mar 22, 2019 at 4:30 PM Alexander Dahl <ada at thorsis.com> wrote:
>
> 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.
>
> 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. ;-)

This register is present in both Zynq and ZynqMP:
https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html
The "ID number" field used here is bits[27:16], usually referred to as
"module identification"
number and all Gigabit supported IP versions have this value at 2 or higher.
In general, I believe this and the bottom 15 bits are used to track
fix and non-fix releases of the IP.

Regards,
Harini