|-
|1.0.0
|Apri Apr 2022
|[[BORA_SOM/BELK-L/General/Release_Notes#BELK_4.1.5|4.1.5]]
|First release
== Introduction ==
This technical note provides some information for managing the rest 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 ===
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 PS_MIO51_501_.28Ethernet_PHY_reset.29 | PS MIO51 501]] and [[BORA_SOM/BORA_Hardware/Power_and_Reset/Reset_scheme_and_control_signals#PS_MIO51_500 PS_MIO50_501_.28USB_PHY_reset.29 | PS MIO50 501]] pins.
== Hardware reset using 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]].
Those These MIO pins are connected to the PHY reset signals and the reset pulse is can be generated at using a proper software levelsroutine.
=== U-Boot PHY reset ===
</pre>
In this specific case=== kernel PHY reset ===The Linux kernel is assumed to find the two physical transceivers '''already reset'''. So, the reset pulse is generated directly by writing in not implemented at ''driver nor userspace'' levels. ==== ethernet ====The ethernet PHY kernel driver, i.e. <code>drivers/net/ethernet/cadence/macb.c</code> supports a device tree entry for generating the MIO registers as per the following source code:hardware reset pulse.
<pre class="board-terminal"> /* * temporary hack It is enough to add the following entries in order to let the kernel to take USB0 out of reset */ temp = readl(0xE000A244); writel(temp | USB0_rst , 0xE000A244); temp = readl(0xE000A248); writel(temp | USB0_rst , 0xE000A248); temp = readl(0xE000A044); writel(temp & ~USB0_rst , 0xE000A044); udelay(10000); // pause for 10ms temp = readl(0xE000A044); writel(temp | USB0_rst , 0xE000A044);the PHY too:
/* * temporary hack to take ETH PHY out of reset */ &gem0 { temp status = readl(0xE000A244)"okay"; writel((temp | ETH0_rst) , 0xE000A244) phy-mode = "rgmii-id"; temp phy-handle = readl(0xE000A248)<&phy0>; writel((temp | ETH0_rst), 0xE000A248); writel((temp <b>phy-reset-gpio = <& ~ETH0_rst), 0xE000A044)gpio0 51 1>; mdelay(500); /* 500ms */ temp phy-reset-duration = readl(0xE000A044)<100>; writel((temp | ETH0_rst), 0xE000A044) phy-reset-active-low;</preb> ... ...
==== USB ====
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.
=== kernel PHY An example of a USB driver with the hardware reset ===capability can be found on <code>drivers/usb/phy/phy-generic.c</code>. The Linux kernel is assumed to find the two physical transceivers already reset. Somanagement, via device tree property <code>reset-gpios</code> can be used as a reference for implementing the hardware reset is not implemented at hacking in the ULPI driver nor userspace levels.
For issuing a == Software reset pulse to the PHYs, a dedicated kernel hacking is to be realized; this taking into account:* the status of software protocols stack==* the component driver** the The ethernet PHY is - in general - supports a Micrel KSZ9031 and so its related <code>drivers/net/phy/micrelsoftware reset via the BCMR register.c</code> The MAC kernel driver** issues a software reset during the USB PHY is a * ''phy attach'' to the PHY re-initialization (see for example [[httpsethernet device://microchipsupport.force.com/s/article/KSZ9031-initialization-procedure this]] article
i.e. a proper BSP modifications have to be evaluated.<pre>ret = phy_write(phydev, MII_BMCR, BMCR_RESET);</pre>
== Software reset ==in the <code>genphy_soft_reset</code> function.