simonebortolin-patch-n19

8 files changed, 61 insertions, 61 deletions

diff --git a/_sfp/bosa-tosa-rosa.md b/_sfp/bosa-tosa-rosa.md
index a893170..2558603 100644
--- a/_sfp/bosa-tosa-rosa.md
+++ b/_sfp/bosa-tosa-rosa.md
@@ -5,8 +5,8 @@ nav_order: 3
 layout: default
 ---
 
-In optical-electrical conversion, special components called TOSA (Transmitter Optical Sub Assembly) and ROSA (Receiver Optical Sub Assembly) are used to convert the signal.
-They are responsible for translating the optical signal into a corresponding electrical signal or vice versa, which inputs or outputs symbols corresponding to the optical values. These values, which we refer to as unprocessed or RAW values for simplicity, are not standard signals and must be converted into standard signals[^huawei].
+In optical-electrical conversions, special components called TOSA (Transmitter Optical Sub Assembly) and ROSA (Receiver Optical Sub Assembly) are used to convert the signal.
+They are responsible for translating the optical signal into a corresponding electrical signal and viceversa, which inputs or outputs symbols corresponding to the optical values. These values, which we refer to as unprocessed or RAW values for simplicity, are not standard signals and must be converted into standard signals[^huawei].
 
 TOSA and ROSA are essential components in the uni-directional transceivers which transmit on one fiber optic strand and receive on the other fiber optic strand. 
 
diff --git a/_sfp/ont-wo-mac.md b/_sfp/ont-wo-mac.md
index b1e6faf..06c9c72 100644
--- a/_sfp/ont-wo-mac.md
+++ b/_sfp/ont-wo-mac.md
@@ -5,22 +5,22 @@ nav_order: 2
 layout: default
 ---
 
-PON technologies unlike Ethernet are not P2P but one-to-many with two device types: ONU (Optical Network Unit)/ONT (Optical Network Terminal) and OLT (Optical Line Terminal). Both devices can be manufactured using the SFP form factor[^tibit].
+PON technologies, unlike Ethernet, are not P2P but one-to-many with two device types: ONU (Optical Network Unit)/ONT (Optical Network Terminal) and OLT (Optical Line Terminal). Both devices can be manufactured using the SFP form factor[^tibit].
 
-The OLT provides an integrated access box for Passive Optical Networks. OLTs are typically chassis with one or more line cards inside, and on each line card there is one or more PON transceiver, usually in SFP form factor. Each line card is connected to a secondary switch that provides line card aggregation to the Ethernet uplinks. OLTs are often a mixture of Layer 2 and Layer 3 switching with traffic shaping on a per-customer, per-service basis[^tibit].
+The OLT provides an integrated access box for Passive Optical Networks. OLTs are typically chassis with one or more line cards inside, and on each line card there is one or more PON transceiver, usually in the SFP form factor. Each line card is connected to a secondary switch that provides line card aggregation to the Ethernet uplinks. OLTs are often a mixture of Layer 2 and Layer 3 switching with traffic shaping on a per-customer, per-service basis[^tibit].
 
-The communication within the SFP PON transceiver is neither MMI nor Ethernet, outside [SFP standards](/sfp-standard.md), but rather it is an *equivalent electrical symbols of optical transmission* (which is simply the input/output of the [BOSA](/bosa-tosa-rosa.md)) that for simplicity's sake we call **PON RAW communication** (also referred to as SFP w/o PON MAC). All the PON management part is left to the line card itself. Each equivalent electrical symbol of optical transmission is a separate dialect, distinct from other dialects. Furthermore, as one can easily guess, this communication is not standard and is not within the signalling standards ([^sfprate],[^sfprate2],[^sfpplusstandard]) but it is compliant with some portions of  the MSA [^sfpstandard],[^sfpplusstandard],[^sfpplusmi]. This requires extreme compatibility between ONT and transreciver. This design choice is made for several reasons:
-- *size*: the size of an OLT w/o PON MAC is very similar to that of an MMI or Ethernet transceiver, and the size of an OLT with the integrated PON MAC far exceeds that of the standard SFP form factor
-- *dissipative heating capacity*: the dissipative heating capacity of an OLT with PON MAC is higher than a normal transceiver, such as a 1 or 10 Gbps Ethernet link.
-- *duplication*: there is a double `MAC` → `MMI` conversion (`MMI` → `MAC` → `PHY` → `MAC` → `OLT CPU`)
-- *repairability*: since lasers often have a shorter lifetime than other ICs, it is good to be able to change only the transceiver
+The communication within the SFP PON transceiver is neither MII nor Ethernet, outside [SFP standards](/sfp-standard.md), but rather it is an *equivalent electrical symbols of optical transmission* (which is simply the input/output of the [BOSA](/bosa-tosa-rosa.md)) that for simplicity's sake we call **PON RAW communication** (also referred to as SFP w/o PON MAC). All the PON management part is left to the line card itself. Each equivalent electrical symbol of optical transmission is a separate dialect, distinct from other dialects. Furthermore, as one can easily guess, this communication is not standard and is not within the signalling standards ([^sfprate],[^sfprate2],[^sfpplusstandard]) but it is compliant with some portions of the MSA [^sfpstandard],[^sfpplusstandard],[^sfpplusmi]. This requires extreme compatibility between ONT and transceiver. This design choice is made for several reasons:
+- *size*: the size of an OLT w/o PON MAC is very similar to that of an MII or Ethernet transceiver, and the size of an OLT with the integrated PON MAC far exceeds that of the standard SFP form factor;
+- *dissipative heating capacity*: the dissipative heating capacity of an OLT with PON MAC is higher than a normal transceiver, such as a 1 or 10 Gbps Ethernet link;
+- *duplication*: there is a double `MAC` → `MII` conversion (`MII` → `MAC` → `PHY` → `MAC` → `OLT CPU`);
+- *repairability*: since lasers often have a shorter lifetime than other ICs, it is good to be able to only change the transceiver.
 
-Despite this, there is a vendor that sells OLT SFP with PON MAC[^tibit]. The following pictures show an OLT SFP with PON MAC part and a transreciver without PON MAC. It is interesting to see that the latter is much longer and requires an additional heatsink.
+Despite this, there is a vendor that sells OLT SFPs with PON MAC[^tibit]. The following pictures show an OLT SFP with PON MAC part and a transreciver without PON MAC. It is interesting to see that the latter is much longer and requires an additional heatsink.
 
 {% include image.html file="ont-wo-mac/tibit.png" alt="PON OLT with MAC" caption="PON OLT with MAC" %}
 {% include image.html file="ont-wo-mac/huawei.png" alt="PON transceiver for OLT w/o MAC" caption="PON transceiver for OLT w/o MAC" %}
 
-Similarly, the same argument can be made for OLT SFPs, especially in 10E-PON and XGS-PON there are a lot of transreceivers w/o PON MAC and few ONTs with PON MAC. In this case the reasons are similar to the previous ones. It is also clear that ONTs w/o PON MAC require a PON MAC part within the end device that supports the relevant communication protocol.
+Similarly, the same argument can be made for ONT SFPs, especially in 10E-PON and XGS-PON there are a lot of transceivers w/o PON MAC and few ONTs with PON MAC. In this case, the reasons are similar to the OLT SFPs'. It is also clear that ONTs w/o PON MAC require a PON MAC part within the end device that supports the relevant communication protocol.
 
 The following pictures show some operating diagrams of some ONT with PON MAC and ONT w/o PON MAC[^SFPP-XGS-ONU-MAC-ASC-I-C],[^SFPP-XGS-ONU-N1-I-C],[^MSOG22-xD6C-xxT1].
 
@@ -40,7 +40,7 @@ graph TD
     end;
     subgraph CS[Cage SFP]
     E --> |I2C| Controller;
-    C --> |MMI on Tx - Rx| MAC;
+    C --> |MII on Tx - Rx| MAC;
     Controller[Controller I2C] --> Switch;
     MAC --> Switch;
     end;
@@ -65,11 +65,11 @@ graph TD
     end;
 ```
 
-# Why are there no ONT w/o MAC on Hack GPON?
+# Why are there no ONTs w/o MAC on Hack GPON?
 
-For utility reasons all SFPs w/o PON MAC are not illustrated on Hack GPON as they are not modifiable like ONT with MAC (they require two inter-compatible devices). 
+For usefulness reasons, all SFPs w/o PON MAC are not illustrated on Hack GPON as they are not modifiable like ONTs with MAC (they require two inter-compatible devices). 
 
-In particular, the SFP ONU of the AVM Fritz!Box 5530/5590 belongs in this category, and that the above-mentioned devices are not compatible with any other SFP using MMI/Ethernet/Fibre Channel, while for example the FreeBox or IliadBox supports both ONU w/o PON MAC and some SFP with MAC.
+In particular, the SFP ONU of the AVM Fritz!Box 5530/5590 belongs in this category, and that the above-mentioned devices are not compatible with any other SFP using MII/Ethernet/Fibre Channel, while for example the FreeBox or IliadBox supports both ONU w/o PON MAC and some SFP with MAC.
 
 In general, these devices do not have enough customisation to allow the required parameters to be changed other than the GPON Serial Number and GPON Ploam Password. This means that in most scenarios these devices with ONT w/o MAC are not flexible enough to be used as a replacement for an ISP-provided ONT.
 
diff --git a/_sfp/sfp-standard.md b/_sfp/sfp-standard.md
index 6825ace..892f772 100644
--- a/_sfp/sfp-standard.md
+++ b/_sfp/sfp-standard.md
@@ -7,22 +7,22 @@ layout: default
 
 
 The organisation that developed SFPs (MSA SFP) has always been very cautious about defining a hardened list of admissible signals for SFPs, their first standard only providing pinout, form-factor and dissipative capacity specifications. It is up to the manufacturer to decide which communication to use in the Tx and Rx pins[^sfpstandard]. 
-After the SFP standard entered the market, in the early 2000s Ethernet and Fibre Channel, the MSA SFP also started to standardise signalling, starting with [^sfprate] and [^sfprate2] which define a list of admissible standard signalling limited to the capabilities of the current form factor SFP.
+After the SFP standard entered the market, in the early 2000s with Ethernet and Fibre Channel, the MSA SFP also started standardising signalling, starting with [^sfprate] and [^sfprate2] which define a list of admissible standard signalling limited to the capabilities of the current form factor SFP.
 With the need to increase the heat dissipation characteristics of the modules (in order to increase speeds) and to allow some additions to the EEPROM, an additional standard, called SFP+[^sfpplusstandard],[^sfpplusmi],[^xenpak_xfp], was developed, which contains all the aforementioned improvements. The 16GFC, 20GFC signalling for Fibre Channel and the 10 Gbps and 2.5 signalling for Ethernet were also included in the updated [^sfprate] and [^sfprate2] standard. Some of these are also included in [^sfpplusstandard] locking the SFP+ standard to a tenth of signalling, all other signals should fall under the SFP standard[^sfpstandard], but they can use the extended SFP+ management interface[^sfpplusmi].
 
-The Ethernet signals are all very similar, but there are some differences between Base-X and MMI. The media-independent interface (MMI) was defined in the IEEE 802.11u standard, was originally defined as a standard interface to connect a Fast Ethernet MAC block (i.e. CPU, switch) to a PHY chip (i.e. twisted pair, fiber optic, etc.) in a standardised way. The main advantage is that the MMI can be used without redesigning or replacing the MAC hardware. Thus any MAC may be used with any PHY, independent of the network signal transmission media[^ethernet].
+The Ethernet signals are all very similar, but there are some differences between Base-X and MII. The media-independent interface (MII) was defined in the IEEE 802.11u standard. It was originally defined as a standard interface to connect a Fast Ethernet MAC block (i.e. CPU, switch) to a PHY chip (i.e. twisted pair, fiber optic, etc.) in a standardised way. The main advantage is that MII can be used without redesigning or replacing the MAC hardware. Thus any MAC may be used with any PHY, independent of the network signal transmission media[^ethernet].
 
 The main difference is the physical media over which the frames are: 
-- *Base-X* is based on the Ethernet PHYsical Layer (level 1) and this standard uses the 8B/10B coding (or other encodings as specified in the EEPROM), and *MMI* is based on the Ethernet MAC Device (level 2, the device that actually makes and receives Ethernet frames)[^ethernet].
-- In *Base-X*, auto-negotiation is limited to flow-control (and duplex, which is not really used since it's always full-duplex), and in *MII*, auto-negotiation (AN) also allows the PHY to indicate to the MAC the post-PHY link speed. Even though the MAC-to-PHY SGMII link is always 1000Mbps, it supports 10, 100 and 1000Mbps past the PHY and the MAC need to know this to space out the bits properly (e. g. if the external link is 100Mbps, each bit on the SGMII link is sent 10 times)[^ethernet].
+- *Base-X* is based on the Ethernet PHYsical Layer (layer 1) and this standard uses the 8B/10B coding (or other encodings as specified in the EEPROM), and *MII* is based on the Ethernet MAC Device (layer 2, the device that actually makes and receives Ethernet frames)[^ethernet].
+- In *Base-X*, auto-negotiation is limited to flow-control (and duplex, which is not really used since it's always full-duplex), and in *MII*, auto-negotiation (AN) also allows the PHY to indicate to the MAC the post-PHY link speed. Even though the MAC-to-PHY SGMII link is always 1000Mbps, it supports 10, 100 and 1000Mbps past the PHY and the MAC needs to know this to space out the bits properly (e. g. if the external link is 100Mbps, each bit on the SGMII link is sent 10 times)[^ethernet].
 
-The MII can be used to connect a MAC to an external PHY using a pluggable connector, or directly to a PHY chip on the same PCB. In the first case it is also used in SFP connectors, for example to allow connections between two MAC blocks without passing through a PHY (i.e. passive DAC).
-This technology, and in particular its evolutions such as RGMII[^rgmii], SGMII[^sgmii], QSGMII[^qsgmii], XGMII[^intel], USXGMII[^xilinx], is widely used as a communication bus over SFP, in addition to IEEE BaseX[^ethernet]. The 2.5 SGMII or HSGMII[^altium] and 10 SGMII or XSGMII[^aquantia] standards are specifics that increase the clock speed of the SGMII standard without redefining it.
+MII can be used to connect a MAC to an external PHY using a pluggable connector, or directly to a PHY chip on the same PCB. In the first case it is also used in SFP connectors, for example to allow connections between two MAC blocks without passing through a PHY (i.e. passive DAC).
+This technology, and in particular its evolutions such as RGMII[^rgmii], SGMII[^sgmii], QSGMII[^qsgmii], XGMII[^intel], USXGMII[^xilinx], is widely used as a communication bus over SFP, in addition to IEEE BaseX[^ethernet]. The 2.5G-SGMII or HSGMII[^altium] and 10G-SGMII or XSGMII[^aquantia] standards are specifics that increase the clock speed of the SGMII standard without redefining it.
 
 RGMII, SGMII, 1000BaseX standards allow a speed of 1 Gbps, 2.5BaseX and HSGMII standards of 2.5 Gbps, the XGMII, XSGMII, USXGMII and 10GBaseT of 10 Gbps.
 
 ---
-[^xenpak_xfp]: With the advent of higher speeds MSA has developed several new interfaces, such as XENPAK, X2, XPAK, XFP, but the newest standard is the transceiver is called SFP+. Based on the same form factor as SFP, it is smaller than its predecessors and has lower power than XFP. SFP+ has become the most popular socket on 10GE systems because it shares a common physical form factor with legacy SFP modules, allowing higher port density than XFP and the reuse of existing designs for 24 or 48 ports in a 19-inch rack width blade.
+[^xenpak_xfp]: With the advent of higher speeds MSA has developed several new interfaces, such as XENPAK, X2, XPAK, XFP, but the newest standard is the transceiver is called SFP+. Based on the same form factor as SFP, it is smaller than its predecessors and has lower power than XFP. SFP+ has become the most popular socket on 10GbE systems because it shares a common physical form factor with legacy SFP modules, allowing higher port density than XFP and the reuse of existing designs for 24 or 48 ports in a 19-inch rack width blade.
 [^sfpstandard]: *Specification for SFP (Small Formfactor Pluggable) Transceiver* INF-8074
 [^sfprate]: *SFP Rate and Application Selection* SFF-8079
 [^sfprate2]: *SFP (Small Formfactor Pluggable) Rate and Application Codes* SFF-8089
diff --git a/_sfp_cage/broadcom-57810s.md b/_sfp_cage/broadcom-57810s.md
index be8cd40..4c1c027 100644
--- a/_sfp_cage/broadcom-57810s.md
+++ b/_sfp_cage/broadcom-57810s.md
@@ -17,17 +17,17 @@ layout: default
 | SGMII  | ✅                   |
 | Type   | PCI express SFP card |
 
-In order to be able to set 2.5G speed you will have to patch your kernel's bnx2x module. The easiest way to do so is via DKMS which rebuilds only that module:
+In order for the card to be able to sync at 2.5G speeds, the kernel's bnx2x module has to be patched. The easiest way to do so is via DKMS which rebuilds that module only:
 
 - [DKMS for Linux 6.0.y](https://github.com/darkbasic/bnx2x-2_5g-dkms/tree/6.0.y)
 
-It also adds a module option that can be set to disable SFP TX fault detection, otherwise you won't be able to access your SFP mini-ONT if serial output to SFP is enabled (you can alternatively disable the serial in the SFP module).
+It also adds a module option that can be set to disable SFP TX fault detection, otherwise the SFP mini-ONT will not be accessible if serial output to SFP is enabled. Alternatively the serial interface can be disabled on the SFP module.
 
-Unfortunately, despite the patches, you will still have to use UEFI eDiag to unlock 2.5G capabilities:
+Unfortunately, despite the patches, UEFI eDiag still has to be used to unlock 2.5G capabilities:
 
 - [How-to enable 2.5G capability via UEFI eDiag](https://www.dslreports.com/forum/r32230041-Internet-Bypassing-the-HH3K-up-to-2-5Gbps-using-a-BCM57810S-NIC)
 
-At this point you will be able to use the following command to set the speed to 2.5G:
+At this point, use the following command to set the speed to 2.5G:
 ```
 sudo ethtool -s your_network_interface autoneg off speed 2500 duplex full
 ```
diff --git a/_sfp_cage/macchiatobin.md b/_sfp_cage/macchiatobin.md
index 0f7a4f5..a42c603 100644
--- a/_sfp_cage/macchiatobin.md
+++ b/_sfp_cage/macchiatobin.md
@@ -25,4 +25,4 @@ layout: default
 
 <hr>
 
-[^xor]: In the Dual Shot model the RJ45 and the SFP are in XOR, i.e. either one or the other.
\ No newline at end of file
+[^xor]: In the Dual Shot model the RJ45 and the SFP are in XOR, i.e. either one or the other is usable, not both at the same time.
\ No newline at end of file
diff --git a/_sfp_cage/mikrotik.md b/_sfp_cage/mikrotik.md
index f07db80..ec5269e 100644
--- a/_sfp_cage/mikrotik.md
+++ b/_sfp_cage/mikrotik.md
@@ -21,7 +21,7 @@ layout: default
 
 ## Bridge Mode
 
-Bridge mode allows full HSGMII speed without any major issues and seems to work in a mixed mode too.
+Bridge mode allows full HSGMII speed without any major issues and seems to work in mixed mode too.
 
 Positive results in mixed mode with the following hardware:
 
@@ -36,7 +36,7 @@ In any case, the use of a DAC or MikroTik S+RJ10 is always recommended.
 
 Unfortunately the CPU will have a major impact on end performance with resulting downlink speed topping at ~700Mbps.
 
-Note that when using **Huawei MA5671A with right.com.cn firmware** on a Fastweb Italy IPoE connection you may run into some issues since no VLANs are used. The ONT responds to DHCP requests with **a 802.1Q tag for VLAN 0**, which should be properly handled by bridging properly the WAN as well. Other providers that do rely on VLANs such as 835 won't probably need to resort to the this workaround.
+Note that when using **Huawei MA5671A with right.com.cn firmware** on a Fastweb Italy IPoE connection you may run into some issues since no VLANs are used. The ONT responds to DHCP requests with **a 802.1Q tag for VLAN 0**, which should be handled by properly bridging the WAN as well. Other providers that do rely on VLANs such as 835 won't probably need to resort to the this workaround.
 
 - [2.5Gb Compatibility](https://github.com/Anime4000/RTL960x/blob/main/Docs/2.5Gb.md)
 - [CRS305 Fastweb Italy SFP Router Mode](https://pastebin.com/zRaidTx4)
diff --git a/_sfp_cage/turris.md b/_sfp_cage/turris.md
index 273e1e1..0b256cd 100644
--- a/_sfp_cage/turris.md
+++ b/_sfp_cage/turris.md
@@ -18,7 +18,7 @@ layout: default
 | Type     | Router        | Router                              |
 
 
-We know form the (Turris Forum)[https://forum.turris.cz/t/ma5671a-sfp-issues-on-turris-os-5-0-3/13443] that work:
+As the (Turris Forum)[https://forum.turris.cz/t/ma5671a-sfp-issues-on-turris-os-5-0-3/13443] reports, the following SFPs are known to work:
 - Huawei MA5671A (Original Firmware)
 - Nokia Alcatel G-010S-A (2.5 Gbps)
 - ODI ZTE DFP-34G-2C2 (1 Gbps)
@@ -29,7 +29,7 @@ We know form the (Turris Forum)[https://forum.turris.cz/t/ma5671a-sfp-issues-on-
 - Zisa OP151S[^2min]
 - Zyxel PMG3000-D20B[^2min]
 
-In ONT that expose the serial port on SFP it must be activated, otherwise the Turris sees a TX Fault.
+In ONTs that expose the serial port on SFP it must be activated, otherwise the Turris sees a TX Fault.
 
 
 <hr>
diff --git a/_sfp_cage/zyxel.md b/_sfp_cage/zyxel.md
index 4f1d611..26c5316 100644
--- a/_sfp_cage/zyxel.md
+++ b/_sfp_cage/zyxel.md
@@ -35,7 +35,7 @@ layout: default
 | mtd7 | 04000000 | 00040000  | "ubi2"       |
 | mtd8 | 15a80000 | 00040000  | "zyubi"      |
 
-This router supports dual boot, and has two partitions for the firmware, `ubi` and `ubi2`
+This router supports dual boot, and has two partitions for the firmware, `ubi` and `ubi2`.
 
 To check the current active partition you can use the following command:
 ```sh
@@ -45,9 +45,9 @@ The result will be something like the following:
 ```
 console=ttyS0,115200n1 loglevel=8 earlycon=uart8250,mmio32,0x11002000 rootubi=ubi
 ```
-If `rootubi=ubi` it means that the active partition is `mtd6`
+If `rootubi=ubi`, the active partition is `mtd6`.
 
-If `rootubi=ubi2` it means that the active partition is `mtd7`
+If `rootubi=ubi2`, the active partition is `mtd7`.
 
 {% include alert.html content="When you flash a new firmware via the web interface the router will automatically write the new firmware in the inactive partition, hence if the firmware upgrade is successfull it will automatically swap the boot partition at next reboot. If everything is ok you don't have to manually swap partitions" alert="Info" icon="svg-info" color="blue" %}
 
@@ -57,21 +57,21 @@ This router has the serial interface pins directly accessible on the board:
 
 {% include image.html file="zyxel-ex5601t0\zyxel_ex5601t0_serial.jpg" alt="EX5601T0 Serial interface" caption="EX5601T0 Serial interface" %}
 
-The serial console speed is 115200.
+The serial console speed is 115200 bauds.
 
 ## ZHAL (Zloader) access
 
 The boot process of this router has multiple stages, long story short we have both u-boot and zloader (ZHAL).
 
-When the router is powered-up u-boot is loaded, u-boot will load zloader which is the zyxel proprietary boot manager.
+When the router is powered-up u-boot is loaded and it will load zloader, the Zyxel proprietary boot manager.
 
 Zloader allows to manually swap boot partitions (`ubi` and `ubi2`), recover the supervisor password and many additional useful (and dangerous) things.
 
 By default zloader access is blocked.
 
-### Unlock zloader 
+### Unlocking zloader 
 
-{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile of it in any way." alert="Warning" icon="svg-warning" color="red" %}
+{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile for any damage in any way." alert="Warning" icon="svg-warning" color="red" %}
 
 1. Open the router case and connect your usb-ttl adapter to the router as show in the picture.
 2. Open putty or any other serial capable software and configure it to use your COMX port with 115200 speed.
@@ -95,13 +95,13 @@ ZHAL>
 ```
 You have successfully unlocked zloader access, this procedure must be done only once.
 
-{% include alert.html content="There is an alternative procedure to achieve the same, you flash the firmware which gives you root access via ssh and you give the same fw_setenv command from point 8. Still you need the usb to serial adapter to access ZHAL" alert="Info" icon="svg-info" color="blue" %}
+{% include alert.html content="There is an alternative procedure to achieve the same end result. Flashing the firmware which gives you root access via ssh and you give the same fw_setenv command from point 8. The USB to serial adapter is still needed to access ZHAL" alert="Info" icon="svg-info" color="blue" %}
 
 
-### Dump supervisor password
-{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile of it in any way." alert="Warning" icon="svg-warning" color="red" %}
+### Dumping supervisor password
+{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile for any damage in any way." alert="Warning" icon="svg-warning" color="red" %}
 
-{% include alert.html content="The supervisor user is the most powerful user that can be used from the web interface. The supervisor password is written in the nand and it's encrypted. To dump the password you must first complete the Unlock zloader procedure" alert="Info" icon="svg-info" color="blue" %}
+{% include alert.html content="The supervisor user is the most powerful user that can be used from the web interface. The supervisor password is written in the nand and it's encrypted. To dump the password you must first complete the **Unlocking zloader** procedure" alert="Info" icon="svg-info" color="blue" %}
 
 1. Open the router case and connect your usb to serial adapter.
 2. Open putty or any other serial capable software and configure it to use your COMX port with 115200 speed.
@@ -117,11 +117,11 @@ atck
 atsr
 ```
 
-### Manually swap the boot partition
+### Manually swapping the boot partition
 
-{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile of it in any way." alert="Warning" icon="svg-warning" color="red" %}
+{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile for any damage in any way." alert="Warning" icon="svg-warning" color="red" %}
 
-{% include alert.html content="To swap the boot partition you first have to complete the Unlock zloader procedure" alert="Info" icon="svg-info" color="blue" %}
+{% include alert.html content="To swap the boot partition you first have to complete the **Unlocking zloader** procedure" alert="Info" icon="svg-info" color="blue" %}
 
 1. Open the router case and connect your usb to serial adapter.
 2. Open putty or any other serial capable software and configure it to use your COMX port with 115200 speed.
@@ -139,14 +139,14 @@ atsr    # reboot the router
 cat /proc/cmdline
 ```
 
-## Unlock u-boot access
-{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile of it in any way." alert="Warning" icon="svg-warning" color="red" %}
+## Unlocking u-boot access
+{% include alert.html content="The following procedure is provided as-is, if you damage the device this community is not responsibile for any damage in any way." alert="Warning" icon="svg-warning" color="red" %}
 
-{% include alert.html content="To unlock u-boot access you first have to complete the Unlock zloader procedure" alert="Info" icon="svg-info" color="blue" %}
+{% include alert.html content="To unlock u-boot access you first have to complete the **Unlocking zloader** procedure" alert="Info" icon="svg-info" color="blue" %}
 
 {% include alert.html content="Having full u-boot access can be very dangerous, with great power comes great responsibility." alert="Warning" icon="svg-warning" color="red" %}
 
-Up to today a strange combination of actions must be completed in a special sequence to access the u-boot command line interface.
+Up to today a strange combination of actions must be completed in a special sequence to access the u-boot CLI:
 
 1. Open the router case and connect your usb to serial adapter.
 2. Open putty or any other serial capable software and configure it to use your COMX port with 115200 speed.
@@ -158,7 +158,7 @@ atgu
 ```
 6. Apparently that command doesn't do anything and the router will reboot itself.
 7. Again for the second time you will read `Hit any key to stop autoboot:`, press Enter again to access ZHAL again.
-8. Type again the following command and press enter:
+8. Type the following command again and press enter:
 ```
 atgu
 ```
@@ -167,12 +167,12 @@ atgu
 MT7986>
 ```
 
-## Flashing a firmware or firmware downgrade
+## Flashing a firmware or downgrading firmware
 
 {% include alert.html content="The following procedure is provided as-is and if anything goes wrong you will likely need to open the router case and attach a USB serial adapter to the router to recover it.
 This community is not responsible of any damage you cause by following these procedures." alert="Warning" icon="svg-warning" color="red" %}
 
-1. access via ssh or telnet to the router with admin user (admin password is printed on the back of the router).
+1. Access the router via ssh or telnet with admin user (admin password is printed on the back of the router).
 2. Disable firmware version check and model check by running the following commands.
 ```
 zycli fwidcheck off
@@ -180,7 +180,7 @@ zycli modelcheck off
 ```
 3. You can close the ssh console, do not reboot the router.
 4. Open the router web interface and in the maintenance/firmware upgrade section select the "Restore Default Settings After Firmware Upgrade" option.
-5. Select choose file to select the firmware file you want to upload and click Upload.
+5. Select "Choose file" to select the firmware file you want to upload and click Upload.
 6. The router will automatically reboot and should get back up on 192.168.1.1
 
 ## Firmware Version V5.70(ACDZ.0)C0 no-brand
@@ -190,12 +190,12 @@ https://github.com/pameruoso/zyxel-ex5601t0
 
 1. Added start-up script to reset and enable root access via ssh.
 The script reads the device serial number and resets the root password with that. Do not try to reset the root password because that will last until next reboot.
-2. the `/bin` path contains `sfp_wan.sh_wind` and `check_sfp_link.sh_wind` scripts which are very similar to the standard `sfp_wan.sh` and `check_sfp_link.sh` scripts. If everything works with the original ones do not swap them. If you want to allow 2.5gbit HSGMII with AFM0003 sfp stick you need to swap and enable the `_wind` scripts.
+2. the `/bin` path contains `sfp_wan.sh_wind` and `check_sfp_link.sh_wind` scripts which are very similar to the standard `sfp_wan.sh` and `check_sfp_link.sh` scripts. If everything works with the original ones do not swap them. If you want to allow 2.5gbit HSGMII with the Technicolor AFM0003 SFP stick you need to swap and enable the `_wind` scripts.
 3. Additional packages installed: `mtr`, `htop`, `openvpn`, `wireguard`.
 
-{% include alert.html content="The openvpn and wireguard functionalities will not be directly usable in the Zyxel web interface, they are not supported. If you want to setup a vpn with openvpn or wireguard you must know how to use the command-line and do your own setup" alert="Info" icon="svg-info" color="blue" %}
+{% include alert.html content="The OpenVPN and Wireguard functionalities will not be directly usable in the Zyxel web interface, they are not supported. If you want to setup a VPN with either protocol you must know how to use the command-line and do your own setup" alert="Info" icon="svg-info" color="blue" %}
 
-{% include alert.html content="Do not try to install packages directly from the internet with opkg update/install, the default repositories are not working and most likely if you edit them you'll end up breaking the partition overlay" alert="Warning" icon="svg-warning" color="red" %}
+{% include alert.html content="Do not try to install packages directly from the internet with opkg update/install, the default repositories are not working and, if you edit them, you'll most likely end up breaking the partition overlay" alert="Warning" icon="svg-warning" color="red" %}
 
 - [Firmware Version V5.70(ACDZ.0)C0_no-brand_pa_0.1](https://mega.nz/file/OJxBCKqR#z31OiJwY6_iaDtj_yrOTrx1oKnFEdnm4Rh0pi3wRtoE)
 
@@ -208,7 +208,7 @@ You are free to clone the git code and build your own OpenWrt firmware or use th
 
 The OpenWrt firmware has the following working features out of the box:
 - 3 Gbit LAN ports
-- Wi-Fi AX6000: 5Ghz 4x4ax + 2.4GHz 4x4ax
+- Wi-Fi AX6000: 5Ghz 4x4 ax + 2.4GHz 4x4 ax
 - Zyxel partitioning for coexistance with Zloader and dual boot
 - Leds
 - Reset button
@@ -216,11 +216,11 @@ The OpenWrt firmware has the following working features out of the box:
 - USB port
 - LAN RJ45 2.5 Gbit port
 - WAN RJ45 2.5 Gbit port
-- WAN SFP port only works after exporting pins 57 and 10 (`gpiobase411`). Too there must be a cable with a link active on the WAN 2.5 Gbe port to make the SFP work. This is due to missing support into the phy-link code of the mediatek ethernet soc.
+- WAN SFP port only works after exporting pins 57 and 10 (`gpiobase411`). There must also be a cable with a link active on the WAN 2.5 Gbe port to make the SFP work. This is due to missing support into the phy-link code of the Mediatek ethernet SoC.
 
-To workaround the missing phy-link support some modifications to the DTS are needed. Setting the `gmac1` node to fixed link 2500Base-X gives the possibility to hot-swap the SFP/RJ45 port.
+To workaround the missing phy-link support, some modifications to the DTS are needed. Setting the `gmac1` node to fixed link 2500Base-X gives the possibility to hot-swap the SFP/RJ45 port.
 
-The following is a repo that contains a proper example: [EX5601-T0 fixed SFP link git repo](https://github.com/pameruoso/openwrt-ex5601t0-porting/tree/ex5601-t0-fixedlink) you can apply the  [patch](https://github.com/openwrt/openwrt/compare/main...pameruoso:openwrt-ex5601t0-porting:ex5601-t0-fixedlink.patch) to the official OpenWrt repo.
+The following repo contains a proper example: [EX5601-T0 fixed SFP link git repo](https://github.com/pameruoso/openwrt-ex5601t0-porting/tree/ex5601-t0-fixedlink) you can apply the [patch](https://github.com/openwrt/openwrt/compare/main...pameruoso:openwrt-ex5601t0-porting:ex5601-t0-fixedlink.patch) to the official OpenWrt repo.
 
 {% include alert.html content="It is highly recommended to use the OpenWrt official builds instead of this fork because the latter is not updated that often, still if you want to use the SFP you can insert it into a media converter and use the 2.5Gbe RJ45 port with the official build." alert="Info" icon="svg-info" color="blue" %}
 
@@ -237,4 +237,4 @@ Here is a flashable bin file based on OpenWrt 5.15.114 with the mod to swap SFP/
 
 <hr>
 
-[^xor]: the WAN Eth and WAN SFP ports are in XOR, i.e. either one or the other.
+[^xor]: the Ethernet and SFP WAN ports are in XOR, i.e. either one or the other is usable, not both at the same time.