Difference between revisions of "BELK-TN-013: Managing ethernet and USB physical transceivers reset"
(→ethernet) |
(→Reference) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 19: | Line 19: | ||
|- | |- | ||
|1.0.0 | |1.0.0 | ||
| − | | | + | |Apr 2022 |
|[[BORA_SOM/BELK-L/General/Release_Notes#BELK_4.1.5|4.1.5]] | |[[BORA_SOM/BELK-L/General/Release_Notes#BELK_4.1.5|4.1.5]] | ||
|First release | |First release | ||
| Line 25: | Line 25: | ||
== Introduction == | == Introduction == | ||
| − | This technical note provides some information for managing the | + | This technical note provides some information for managing the reset of Ethernet and USB physical transceivers used in [[BORA SOM |BORA]], [[BORA Xpress SOM |BORA Xpress]] and [[BORA Lite SOM |BORA Lite]] DAVE Embedded Systems' SOMs. |
=== Reference === | === Reference === | ||
| − | The BORA and BORA Xpress ethernet and USB PHY reset signals are actually managed by the two MIO pins dedicated to this functionality. The MIO pins are documented in the Power and Reset wiki page for [[BORA_SOM/BORA_Hardware/Power_and_Reset/Reset_scheme_and_control_signals# | + | The BORA and BORA Xpress ethernet and USB PHY reset signals are actually managed by the two MIO pins dedicated to this functionality. The MIO pins are documented in the Power and Reset wiki page for [[BORA_SOM/BORA_Hardware/Power_and_Reset/Reset_scheme_and_control_signals#PS_MIO51_501_.28Ethernet_PHY_reset.29 | PS MIO51 501]] and [[BORA_SOM/BORA_Hardware/Power_and_Reset/Reset_scheme_and_control_signals#PS_MIO50_501_.28USB_PHY_reset.29 | PS MIO50 501]] pins. |
== Hardware reset using MIO pins == | == Hardware reset using MIO pins == | ||
| − | The default configuration for the two PHY is managed - by default - in the BORA and BORA Xpress SOMS using the two dedicated [[BORA_SOM/BORA_Hardware/Peripherals/Processing_System_(PS)| MIO pins]]. | + | The default configuration for the two PHY reset signals is managed - by default - in the BORA and BORA Xpress SOMS using the two dedicated [[BORA_SOM/BORA_Hardware/Peripherals/Processing_System_(PS)| MIO pins]]. |
| − | + | These MIO pins are connected to the PHY reset signals and the reset pulse can be generated using a proper software routine. | |
=== U-Boot PHY reset === | === U-Boot PHY reset === | ||
| Line 41: | Line 41: | ||
int board_init(void) | int board_init(void) | ||
</pre> | </pre> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== kernel PHY reset === | === kernel PHY reset === | ||
| − | The Linux kernel is assumed to find the two physical transceivers already reset. So, the | + | The Linux kernel is assumed to find the two physical transceivers '''already reset'''. So, the reset is not implemented at ''driver nor userspace'' levels. |
==== ethernet ==== | ==== ethernet ==== | ||
| Line 86: | Line 56: | ||
<b>phy-reset-gpio = <&gpio0 51 1>; | <b>phy-reset-gpio = <&gpio0 51 1>; | ||
phy-reset-duration = <100>; | phy-reset-duration = <100>; | ||
| − | phy-reset-active-low | + | phy-reset-active-low;</b> |
... | ... | ||
... | ... | ||
==== USB ==== | ==== USB ==== | ||
| − | For issuing a reset pulse to the USB PHY, a dedicated kernel hacking | + | For issuing a reset pulse to the USB PHY, a dedicated kernel hacking has to be implemented: the USB PHY driver to be modified is the ULPI <code>drivers/usb/phy/phy-ulpi.c</code> kernel driver. |
| + | |||
| + | An example of a USB driver with the hardware reset capability can be found on <code>drivers/usb/phy/phy-generic.c</code>. The reset management, via device tree property <code>reset-gpios</code> can be used as a reference for implementing the hacking in the ULPI driver. | ||
== Software reset == | == Software reset == | ||
| − | The ethernet PHY - in general - supports a software reset | + | The ethernet PHY - in general - supports a software reset via the BCMR register. The MAC kernel driver issues a software reset during the ''phy attach'' to the ethernet device: |
| + | |||
| + | <pre> | ||
| + | ret = phy_write(phydev, MII_BMCR, BMCR_RESET); | ||
| + | </pre> | ||
| + | |||
| + | in the <code>genphy_soft_reset</code> function. | ||
Latest revision as of 09:37, 9 September 2022
| HOME | SOMs | SBCs | ToloMEO Embedded Assistant |  GET A QUOTE
|
 ONLINE HELPDESK
|
| Roadmap | IoT Services | ML/AI services | Embedded Design Services |
Info Box
|
|
This technical note was validated against specific versions of hardware and software. What is described here may not work with other versions. |
|
Contents
History[edit | edit source]
| Version | Date | BELK/BXELK version | Notes |
|---|---|---|---|
| 1.0.0 | Apr 2022 | 4.1.5 | First release |
Introduction[edit | edit source]
This technical note provides some information for managing the reset of Ethernet and USB physical transceivers used in BORA, BORA Xpress and BORA Lite DAVE Embedded Systems' SOMs.
Reference[edit | edit source]
The BORA and BORA Xpress ethernet and USB PHY reset signals are actually managed by the two MIO pins dedicated to this functionality. The MIO pins are documented in the Power and Reset wiki page for PS MIO51 501 and PS MIO50 501 pins.
Hardware reset using MIO pins[edit | edit source]
The default configuration for the two PHY reset signals is managed - by default - in the BORA and BORA Xpress SOMS using the two dedicated MIO pins.
These MIO pins are connected to the PHY reset signals and the reset pulse can be generated using a proper software routine.
U-Boot PHY reset[edit | edit source]
In the BELK BSP, the following U-Boot routine contains the reset pulse generation:
int board_init(void)
kernel PHY reset[edit | edit source]
The Linux kernel is assumed to find the two physical transceivers already reset. So, the reset is not implemented at driver nor userspace levels.
ethernet[edit | edit source]
The ethernet PHY kernel driver, i.e. drivers/net/ethernet/cadence/macb.c supports a device tree entry for generating the hardware reset pulse.
It is enough to add the following entries in order to let the kernel to reset the PHY too:
&gem0 {
status = "okay";
phy-mode = "rgmii-id";
phy-handle = <&phy0>;
phy-reset-gpio = <&gpio0 51 1>;
phy-reset-duration = <100>;
phy-reset-active-low;
...
...
USB[edit | edit source]
For issuing a reset pulse to the USB PHY, a dedicated kernel hacking has to be implemented: the USB PHY driver to be modified is the ULPI drivers/usb/phy/phy-ulpi.c kernel driver.
An example of a USB driver with the hardware reset capability can be found on drivers/usb/phy/phy-generic.c. The reset management, via device tree property reset-gpios can be used as a reference for implementing the hacking in the ULPI driver.
Software reset[edit | edit source]
The ethernet PHY - in general - supports a software reset via the BCMR register. The MAC kernel driver issues a software reset during the phy attach to the ethernet device:
ret = phy_write(phydev, MII_BMCR, BMCR_RESET);
in the genphy_soft_reset function.
