* macb: MID register on SAMA5D2 series?
@ 2019-03-22 10:49 ` Alexander Dahl
0 siblings, 0 replies; 6+ messages in thread
From: Alexander Dahl @ 2019-03-22 10:49 UTC (permalink / raw)
To: Nicolas Ferre
Cc: netdev, Harini Katakam, u-boot, Bo Shen, Rafal Ozieblo, Claudiu Beznea
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. ;-)
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:-)
Curious greetings
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] macb: MID register on SAMA5D2 series?
@ 2019-03-22 10:49 ` Alexander Dahl
0 siblings, 0 replies; 6+ messages in thread
From: Alexander Dahl @ 2019-03-22 10:49 UTC (permalink / raw)
To: u-boot
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. ;-)
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:-)
Curious greetings
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: macb: MID register on SAMA5D2 series?
2019-03-22 10:49 ` [U-Boot] " Alexander Dahl
@ 2019-03-22 11:10 ` Harini Katakam
-1 siblings, 0 replies; 6+ messages in thread
From: Harini Katakam @ 2019-03-22 11:10 UTC (permalink / raw)
To: Alexander Dahl
Cc: Nicolas Ferre, netdev, Harini Katakam, u-boot, Bo Shen,
Rafal Ozieblo, Claudiu Beznea
Hi Alex,
On Fri, Mar 22, 2019 at 4:30 PM Alexander Dahl <ada@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] macb: MID register on SAMA5D2 series?
@ 2019-03-22 11:10 ` Harini Katakam
0 siblings, 0 replies; 6+ messages in thread
From: Harini Katakam @ 2019-03-22 11:10 UTC (permalink / raw)
To: u-boot
Hi Alex,
On Fri, Mar 22, 2019 at 4:30 PM Alexander Dahl <ada@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: macb: MID register on SAMA5D2 series?
2019-03-22 10:49 ` [U-Boot] " Alexander Dahl
@ 2019-03-22 14:58 ` Nicolas.Ferre at microchip.com
-1 siblings, 0 replies; 6+ messages in thread
From: Nicolas.Ferre @ 2019-03-22 14:58 UTC (permalink / raw)
To: ada; +Cc: netdev, harini.katakam, u-boot, Eugen.Hristev, rafalo, Claudiu.Beznea
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] macb: MID register on SAMA5D2 series?
@ 2019-03-22 14:58 ` Nicolas.Ferre at microchip.com
0 siblings, 0 replies; 6+ messages in thread
From: Nicolas.Ferre at microchip.com @ 2019-03-22 14:58 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-22 14:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-22 10:49 macb: MID register on SAMA5D2 series? Alexander Dahl
2019-03-22 10:49 ` [U-Boot] " Alexander Dahl
2019-03-22 11:10 ` Harini Katakam
2019-03-22 11:10 ` [U-Boot] " Harini Katakam
2019-03-22 14:58 ` Nicolas.Ferre
2019-03-22 14:58 ` [U-Boot] " Nicolas.Ferre at microchip.com
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.