96B Quad Ethernet Mezzanine¶
Description¶
The 96B Quad Ethernet Mezzanine is an add-on/expansion board for SoC based development platforms designed to the 96Boards specification. The mezzanine card has 4x Texas Instruments DP83867 Gigabit Ethernet PHYs to provide 4 ports of gigabit Ethernet connectivity to the carrier development platform.

96B Quad Ethernet Mezzanine on the Ultra96¶
Features¶
4x TI DP83867 Gigabit Ethernet PHYs
Quad Ethernet RJ45 with magnetics
Power and reset pushbuttons
Low-speed expansion connector for stacking
Supports the Avnet Ultra96 v1 and v2 dev platforms
Example designs for Vivado
Standalone and PetaLinux example designs
Where to buy¶
The mezzanine card can be purchased from Opsero’s online shop at the link below:
96B Quad Ethernet Mezzanine order page
Pin Configuration¶
The 96B Quad Ethernet Mezzanine has both the low-speed and high-speed expansion connectors as defined by the 96Boards Consumer Edition specification. The following tables define the pinout of those connectors for this mezzanine card.
Low-speed expansion header¶
The low-speed expansion header connects the main power supply (SYS_DCIN) to the mezzanine card and it also provides I/Os that are used for the MDIO bus, the PHY resets and the “power good” signals from the mezzanine card’s switching regulators.
Only 9 I/O pins of the low-speed expansion header are used by the 96B Quad Ethernet Mezzanine card. The others are directly passed through to the expansion socket on the top side of the board which can be used for stacking a second mezzanine card. See the following section for the pinout of the low-speed expansion socket.
The mezzanine card does not draw power from the +5V pin (37). This pin is directly passed through to the expansion socket on the top side of the board.
The mezzanine card does not draw power from the 1.8V supply pin (35), but it does use this pin to detect power-up of the carrier board. To supply +1.8V power to the Ethernet PHYs, the mezzanine card generates it’s own +1.8VDC supply using an on-board switching regulator that is powered by SYS_DCIN (the main supply). The +1.8VDC that is generated on the mezzanine card is also passed through to the top-side expansion socket to provide power to a stacked mezzanine if required.
96Boards
pin name
|
Pin |
Description |
96Boards
pin name
|
Pin |
Description |
---|---|---|---|---|---|
GND |
1 |
Ground |
GND |
2 |
Ground |
UART0_CTS |
3 |
Passed through |
PWR_BTN_N |
4 |
Passed through |
UART0_TXD |
5 |
Passed through |
RST_BTN_N |
6 |
Passed through |
UART0_RXD |
7 |
Passed through |
SPI0_SCL |
8 |
Passed through |
UART0_RTS |
9 |
Passed through |
SPI0_DIN |
10 |
Passed through |
UART1_TXD |
11 |
Passed through |
SPI0_CS |
12 |
Passed through |
UART1_RXD |
13 |
Passed through |
SPI0_DOUT |
14 |
Passed through |
I2C0_SCL |
15 |
Passed through |
PCM_FS |
16 |
Passed through |
I2C0_SDA |
17 |
Passed through |
PCM_CLK |
18 |
Passed through |
I2C1_SCL |
19 |
Passed through |
PCM_DO |
20 |
Passed through |
I2C1_SDA |
21 |
Passed through |
PCM_DI |
22 |
Passed through |
GPIO-A |
23 |
Passed through |
GPIO-B |
24 |
Passed through |
GPIO-C |
25 |
Passed through |
GPIO-D |
26 |
POWER GOOD 1.0V
(1.8V logic)
|
GPIO-E |
27 |
POWER GOOD 2.5V
(1.8V logic)
|
GPIO-F |
28 |
POWER GOOD 1.8V
(1.8V logic)
|
GPIO-G |
29 |
Port 0 PHY reset
(active low)
|
GPIO-H |
30 |
Port 1 PHY reset
(active low)
|
GPIO-I |
31 |
Port 2 PHY reset
(active low)
|
GPIO-J |
32 |
Port 3 PHY reset
(active low)
|
GPIO-K |
33 |
MDIO data signal |
GPIO-L |
34 |
MDC clock signal |
+1V8 |
35 |
+1.8V supply
from dev platform
|
SYS_DCIN |
36 |
Main power supply |
+5V |
37 |
+5.0V supply
from dev platform
Passed through
|
SYS_DCIN |
38 |
Main power supply |
GND |
39 |
Ground |
GND |
40 |
Ground |
Low-speed expansion socket¶
The low-speed expansion socket is on the top-side of the mezzanine card and can be used for stacking a second mezzanine card. It provides access to all of the I/O that the 96B Quad Ethernet mezzanine does not use, and all of the power supplies.
In the table below, all of the pins with the description “Passed through” can be used by the stacked mezzanine card. The specific usage of the pins will depend on the development platform being used.
Note
The +1.8V power supply pin (35) is connected to the +1.8V that is generated by a switching regulator on the 96B Quad Ethernet Mezzanine, it is not passed through from the development platform. This allows the stacked mezzanine to draw 100mA or more from the supply.
96Boards
pin name
|
Pin |
Description |
96Boards
pin name
|
Pin |
Description |
---|---|---|---|---|---|
GND |
1 |
Ground |
GND |
2 |
Ground |
UART0_CTS |
3 |
Passed through |
PWR_BTN_N |
4 |
Passed through |
UART0_TXD |
5 |
Passed through |
RST_BTN_N |
6 |
Passed through |
UART0_RXD |
7 |
Passed through |
SPI0_SCL |
8 |
Passed through |
UART0_RTS |
9 |
Passed through |
SPI0_DIN |
10 |
Passed through |
UART1_TXD |
11 |
Passed through |
SPI0_CS |
12 |
Passed through |
UART1_RXD |
13 |
Passed through |
SPI0_DOUT |
14 |
Passed through |
I2C0_SCL |
15 |
Passed through |
PCM_FS |
16 |
Passed through |
I2C0_SDA |
17 |
Passed through |
PCM_CLK |
18 |
Passed through |
I2C1_SCL |
19 |
Passed through |
PCM_DO |
20 |
Passed through |
I2C1_SDA |
21 |
Passed through |
PCM_DI |
22 |
Passed through |
GPIO-A |
23 |
Passed through |
GPIO-B |
24 |
Passed through |
GPIO-C |
25 |
Passed through |
GPIO-D |
26 |
Not connected |
GPIO-E |
27 |
Not connected |
GPIO-F |
28 |
Not connected |
GPIO-G |
29 |
Not connected |
GPIO-H |
30 |
Not connected |
GPIO-I |
31 |
Not connected |
GPIO-J |
32 |
Not connected |
GPIO-K |
33 |
Not connected |
GPIO-L |
34 |
Not connected |
+1V8 |
35 |
+1.8V supply from
96B Eth mezzanine
|
SYS_DCIN |
36 |
Main power supply Passed through |
+5V |
37 |
+5.0V supply
from dev platform
Passed through
|
SYS_DCIN |
38 |
Main power supply Passed through |
GND |
39 |
Ground |
GND |
40 |
Ground |
High-speed expansion connector¶
The high-speed expansion connector routes the SGMII input (Soc-to-PHY) and output (PHY-to-SoC) signals to the development platform. It also routes the SGMII 625MHz clock (input to SoC), which is generated by the PHY connected to port 3, and is typically used by the SGMII receiver.
Also routed through the high-speed connector are 2 configurable outputs of the DP83867 PHYs called “GPIO0” and “GPIO1”. These can be used for start-of-packet detection, loss of sync detection, and receive error detection among other things. Please refer to the datasheet of the DP83867 for more detailed information on these pins and their function.
96Boards
pin name
|
Pin |
Description |
96Boards
pin name
|
Pin |
Description |
---|---|---|---|---|---|
SD_DAT0/SPI1_DOUT |
1 |
Not used |
CSI0_C+ |
2 |
Port 0 SGMII output data+ |
SD_DAT1 |
3 |
Not used |
CSI0_C- |
4 |
Port 0 SGMII output data- |
SD_DAT2 |
5 |
Not used |
GND |
6 |
Ground |
SD_DAT3/SPI1_CS |
7 |
Not used |
CSI0_D0+ |
8 |
Port 1 SGMII output data+ |
SD_SCLK/SPI1_SCLK |
9 |
Not used |
CSI0_D0- |
10 |
Port 1 SGMII output data- |
SD_CMD/SPI1_DIN |
11 |
Not used |
GND |
12 |
Ground |
GND |
13 |
Ground |
CSI0_D1+ |
14 |
Port 1 GPIO1 (1.2V output) |
CLK0/CSI0_MCLK |
15 |
Not used |
CSI0_D1- |
16 |
Port 1 GPIO0 (1.2V output) |
CLK1/CSI1_MCLK |
17 |
Not used |
GND |
18 |
Ground |
GND |
19 |
Ground |
CSI0_D2+ |
20 |
Port 0 SGMII input data+ |
DSI_CLK+ |
21 |
Port 3 SGMII input data+ |
CSI0_D2- |
22 |
Port 0 SGMII input data- |
DSI_CLK- |
23 |
Port 3 SGMII input data- |
GND |
24 |
Ground |
GND |
25 |
Ground |
CSI0_D3+ |
26 |
Port 1 SGMII input data+ |
DSI_D0+ |
27 |
Port 2 SGMII output data+ |
CSI0_D3- |
28 |
Port 1 SGMII input data- |
DSI_D0- |
29 |
Port 2 SGMII output data- |
GND |
30 |
Ground |
GND |
31 |
Ground |
I2C2_SCL |
32 |
Not used |
DSI_D1+ |
33 |
Port 0 GPIO1 (1.2V output) |
I2C2_SDA |
34 |
Not used |
DSI_D1- |
35 |
Port 0 GPIO0 (1.2V output) |
I2C3_SCL |
36 |
Not used |
GND |
37 |
Ground |
I2C3_SDA |
38 |
Not used |
DSI_D2+ |
39 |
Port 3 GPIO0 (1.2V output) |
GND |
40 |
Ground |
DSI_D2- |
41 |
Port 3 GPIO1 (1.2V output) |
CSI1_D0+ |
42 |
SGMII 625MHz clock+ |
GND |
43 |
Ground |
CSI1_D0- |
44 |
SGMII 625MHz clock- |
DSI_D3+ |
45 |
Port 2 SGMII input data+ |
GND |
46 |
Ground |
DSI_D3- |
47 |
Port 2 SGMII input data- |
CSI1_D1+ |
48 |
Port 2 GPIO1 (1.2V output) |
GND |
49 |
Ground |
CSI1_D1- |
50 |
Port 2 GPIO0 (1.2V output) |
USB_D+ |
51 |
Not used |
GND |
52 |
Ground |
USB_D- |
53 |
Not used |
CSI1_C+ |
54 |
Port 3 SGMII output data+ |
GND |
55 |
Ground |
CSI1_C- |
56 |
Port 3 SGMII output data- |
HSIC_STR |
57 |
Not used |
GND |
58 |
Ground |
HSIC_DATA |
59 |
Not used |
RESERVED |
60 |
Not used |
Specifications¶
Recommended Operating Conditions¶
MIN |
TYP |
MAX |
UNIT |
||
---|---|---|---|---|---|
Supply voltage |
SYS_DCIN |
+8 |
+12 |
+17 |
V |
Output current |
+1V8 (pin 35)
Low-speed
expansion socket
|
0 |
200 |
mA |
Power Consumption¶
The specifications below refer to the total power consumption of the mezzanine card and the carrier board combined. It is important to note that the use of the mezzanine will affect the power consumption of the SoC on the carrier board. This is due to the peripherals and IP that must be enabled on the SoC to interface with the Ethernet PHYs. Also note that the total power consumption is dependent on the ambient temperature and channel utilization.
Ultra96-v1¶
SYS_DCIN |
UTILIZATION |
MIN |
TYP |
MAX |
UNIT |
|
---|---|---|---|---|---|---|
Current draw |
16 VDC |
100% |
510 |
mA |
||
12 VDC |
100% |
645 |
mA |
|||
8 VDC |
100% |
935 |
mA |
Tests performed at ambient temperature of 25 degrees C
Tests performed using IP in the FPGA to generate the Ethernet packets
Ultra96-v2¶
SYS_DCIN |
UTILIZATION |
MIN |
TYP |
MAX |
UNIT |
|
---|---|---|---|---|---|---|
Current draw |
16 VDC |
100% |
550 |
mA |
||
12 VDC |
100% |
710 |
mA |
|||
8 VDC |
100% |
1050 |
mA |
Tests performed at ambient temperature of 25 degrees C
Tests performed using IP in the FPGA to generate the Ethernet packets
Reset Timing¶
When hardware resetting the PHYs, we recommend using this timing:
Hold the RESET_N signal LOW for 10ms
Release the RESET_N signal (HIGH) and wait for 5ms
MDIO Timing¶
The maximum MDC frequency supported by the DP83867 PHY is 25MHz.
DP83867 Electrical and Timing¶
For electrical specs and timing related to the DP83867 signals listed below, please refer to the DP83867 datasheet:
Reset
SGMII
GPIO0 and GPIO1
MDIO
Start-of-Frame detect
Certifications¶
RoHS
CE
Detailed Description¶
Hardware Overview¶
The figure below illustrates the various hardware components that are located on the top-side of the 96B Quad Ethernet Mezzanine card.

Mezzanine card labelled top-side¶
The main components on the top-side of the mezzanine card are:
4x TI DP83867 Gigabit Ethernet PHYs
40-pin low-speed expansion socket for stacking a second mezzanine
Power and reset pushbuttons
25MHz crystal
Switching regulators for +1.0V, +1.8V and +2.5V
Quad-port RJ45 connector
The figure below illustrates the various hardware components that are located on the bottom-side of the mezzanine card.

Mezzanine card labelled bottom-side¶
The main components on the bottom-side of the mezzanine card are:
40-pin low-speed expansion header
Decoupling capacitors for the DP83867 Ethernet PHYs
60-pin high-speed expansion header
TI DP83867 Gigabit Ethernet PHY¶
There are 4x TI DP83867 Gigabit Ethernet PHYs on the mezzanine card, one for each of the four Gigabit Ethernet ports. For interfacing with a MAC, the DP83867 has both RGMII and SGMII interfaces, however the mezzanine card only uses the SGMII interface of each PHY. The DP83867 is designed for low-power, it has low-latency and it provides IEEE 1588 Start of Frame Detection. For more specific information on the DP83867, please refer to the datasheet.
In this documentation, we will refer to the PHYs as PHY0, PHY1, PHY2 and PHY3, corresponding to their placement from left-to-right and as shown in Fig. 2.
Low-speed expansion connectors¶
The 96B Quad Ethernet Mezzanine has two low-speed expansion connectors: a pin header on the bottom-side, and a pin socket on the top-side. The pin header interfaces with the development platform, while the pin socket is used for “stacking” a second mezzanine card on top of the 96B Quad Ethernet Mezzanine. The figure below illustrates the connections to the low-speed expansion pin header (bottom side) and socket (top side).

Low-speed expansion and stacking connectors¶
Bottom-side low-speed expansion pin header¶
The 96B Quad Ethernet Mezzanine has a 40-pin low-speed expansion pin header, located on the bottom side of the board (see Fig. 3). This pin header connects directly to the development platform and it provides the main power supply to the 96B Quad Ethernet Mezzanine card as well as various I/O signals used by the mezzanine:
SYS_DCIN (the main power supply)
Power and reset pushbuttons
MDIO and MDC signals for the Ethernet PHYs
Reset signals for the Ethernet PHYs
Power good signals from the switching regulators
Top-side low-speed expansion socket¶
Not all of the I/Os on the low-speed expansion header are used by the 96B Quad Ethernet Mezzanine card. To make these unused I/Os accessible to another mezzanine card, the 96B Quad Ethernet Mezzanine was designed with a 40-pin low-speed expansion socket, located on the top-side of the board (see Fig. 2). This expansion socket connects to all of the unused I/Os of the 96B Quad Ethernet Mezzanine, as well as the power/reset pushbuttons and the power supplies. It is designed to allow a standard 96Boards mezzanine card to be “stacked” on top of the 96B Quad Ethernet Mezzanine.
There are 21 unused I/Os that are passed through from the low-speed header to the low-speed socket and can be used by a “stacked” (2nd) mezzanine:
UART0_CTS,TXD,RXD,RTS
UART1_TXD,RXD
I2C0_SCL,SDA
I2C1_SCL,SDA
SPI0_SCL,DIN,CS,DOUT
PCM_FS,CLK,DO,DI
GPIO-A,B,C
All power supply pins SYS_DCIN, +5V and +1V8 are connected to the appropriate supplies however only SYS_DCIN and +5V are directly passed through from the bottom-side low-speed expansion header. The +1V8 power supply is instead connected to the +1.8V that is generated by the 96B Quad Ethernet Mezzanine’s on-board switching regulator. This allows the “stacked” mezzanine card to draw more than the standard’s 100mA limit from the +1.8V supply.
The POWER and RESET pushbuttons are directly passed through.
High-speed expansion connector¶
The 96B Quad Ethernet Mezzanine has a 60-pin high-speed expansion header for interfacing with high-speed I/Os on the development platform. The mezzanine uses most of these I/Os for interfacing the SGMII links and the GPIO0/1 outputs of the DP83867 PHYs.

High-speed expansion connector¶
Each SGMII link is composed of two differential pairs, one for the transmit signal and one for the receive signal. These links typically operate at 1.25Gbps in each direction. These differential pairs are routed on the 96B Quad Ethernet Mezzanine with a controlled differential impedance of 100 ohms.
The DP83867 PHYs have two outputs, named GPIO0 and GPIO1, that can be used for Start of Frame detection among other things (see datasheet for details). Both of these outputs are routed through the high-speed expansion header so that they can be used by the development platform.
Power Supplies¶
The 96B Quad Ethernet Mezzanine has three switching regulators that generate the supply voltages required by the TI DP83867 Gigabit Ethernet PHYs (+1.0V, +1.8V and +2.5V). The switching regulators are all fed by the SYS_DCIN main supply voltage that is provided by the development platform through the low-speed expansion connector. The 96B Quad Ethernet Mezzanine can accept a SYS_DCIN input supply voltage of +8VDC to +17VDC, although it is recommended that a +12VDC supply be used.

Power supplies¶
Power Sequencing¶
The SYS_DCIN voltage is always present as long as the power supply is connected to the development platform, and even when the development platform is turned OFF. To prevent the switching regulators from running when the development platform is turned OFF, the 96B Quad Ethernet Mezzanine uses the ENABLE inputs of the switching regulators. The signal used to ENABLE the switching regulators is the +1V8 supply pin of the low-speed expansion connector.
The power sequencing of the switching regulators was designed to meet the requirements of the DP83867 PHY and is as follows:
The power supply is connected to the development platform and the SYS_DCIN voltage rises to +12VDC (+12VDC expected, +8-17VDC accepted).
The development platform is turned ON, and the +1V8 pin of the low-speed expansion connector rises to +1.8V.
The +1.0V and +1.8V switching regulators are enabled by the +1V8 pin, and their respective POWER GOOD signals are asserted.
The +2.5V regulator is enabled by the POWER GOOD signal of the +1.8V switching regulator and it’s POWER GOOD signal is asserted.
Power good signals¶
To enable diagnostic checking of the 96B Quad Ethernet Mezzanine power supplies, each of the POWER GOOD signals are connected to the low-speed expansion connector. They are connected to the following pins:
Power good +1.0V: Pin 26, GPIO-D
Power good +1.8V: Pin 28, GPIO-F
Power good +2.5V: Pin 27, GPIO-E
Stacking socket +1V8¶
The +1V8 supply pin of the low-speed stacking socket (intended for “stacking” a 2nd mezzanine card on top of the 96B Quad Ethernet Mezzanine) is connected to the +1.8V supply that is generated by the on-board switching regulator. The mezzanine was designed this way to allow the “stacked” mezzanine card to draw more than 100mA from the +1.8V supply, the maximum current that many 96Boards development platforms are designed to support.
Note that the SYS_DCIN and +5V supply pins of the low-speed stacking socket are connected directly to the associated pins on the low-speed expansion header on the bottom-side of the board.
Clocks¶
The figure below illustrates the clock connections on the 96B Quad Ethernet Mezzanine.

Clocks¶
Each of the 4x DP83867 PHYs requires an input clock of 25MHz that can either be provided by a crystal, by a clock generator or by the CLK_OUT pin of another DP83867 device. To provide the 25MHz clock to all devices, the 96B Quad Ethernet Mezzanine connects a crystal to PHY3, and the CLK_OUT output of that PHY is used to drive the clock inputs of the 3 other PHYs. For hardware verification, the CLK_OUT output of each PHY is connected to a testpoint that can be probed on the top-side of the mezzanine card. Note that the CLK_OUT output pin of the DP83867 can be configured to output other signals/frequencies, however for the correct operation of the 96B Quad Ethernet Mezzanine, the default configuration of a 25MHz output should not be changed.
The DP83867 PHYs each have the ability to generate a 625MHz output clock that can be used by the SGMII receiver. The 96B Quad Ethernet Mezzanine routes only one of these clock outputs to the high-speed expansion connector, the one generated by PHY3. Note that this clock output is not enabled by default and must be enabled via the MDIO bus if required by the development platform.
Resets¶
The DP83867 Ethernet PHYs each have a hardware reset pin (RESET_N) that is routed separately to the low-speed expansion connector (see Fig. 4 for details). The reset pin must be driven by the development platform with an active-low signal. There are no pull-up resistors connected to the reset signals on the 96B Quad Ethernet Mezzanine card, however the DP83867 devices have pull-up resistors internal to the device. We recommend always driving the reset pins from the development platform in order to ensure reliable reset behavior.
PHY Configuration¶
Configuration of the PHY by software is performed using the MDIO bus. The MDIO bus consists of two signals: a bidirectional data signal (MDIO) and a clock signal (MDC). The data signal (MDIO) is driven by the master and slaves as an open drain output, and it is connected to a pull-up resistor located on the mezzanine card. The clock signal (MDC) is driven by the master only (the SoC on the development platform) and it does not require a pull-up resistor. For more information on the MDIO serial bus standard, please refer to the Wikipedia page on MDIO.
All of the 4 Ethernet PHYs are connected in a chain configuration to a single MDIO bus. Each PHY has it’s own unique “PHY address” which is used when targetting the PHY on the MDIO bus. The diagram below illustrates the MDIO bus architecture and it’s connection between the low-speed expansion connector and the Ethernet PHYs.

MDIO bus architecture¶
As illustrated in the diagram, each PHY has a unique address that must be used when communicating with the PHYs over the MDIO bus. The PHY addresses are as follows:
PHY0 (Port 0): PHY address 0x01
PHY1 (Port 1): PHY address 0x03
PHY2 (Port 2): PHY address 0x0C
PHY3 (Port 3): PHY address 0x0F
Mechanical Information¶
Dimensions¶
The mechanical dimensions of the 96B Quad Ethernet Mezzanine card are illustrated in the figure below. All dimensions are in millimeters (mm).

96B Quad Ethernet Mezzanine mechanical drawing¶
The assembly drawing above is also available as a PDF at the link below:
Getting Started¶
Example Designs¶
The example designs for the 96B Quad Ethernet Mezzanine are hosted on Github and are designed for the Avnet Ultra96 development platform. There are currently two examples and they are differentiated by the type of Ethernet MACs used and their location in the system.
AXI Ethernet based example¶
This example design is based on Xilinx’s soft (ie. FPGA implemented) MAC, the AXI Ethernet Subsystem IP, that can be found in the Vivado IP Catalog. As the MAC is implemented in the FPGA fabric, this example is ideal for applications that require some packet processing to be performed in the FPGA.
PS GEM based example¶
This example design utilizes the 4x Gigabit Ethernet MACs (GEMs) that are embedded into the Processing System (PS) of the Zynq Ultrascale+™ device of the Ultra96. The MACs in this example design do not use up any of the FPGA fabric, which makes it ideal for applications that need to use the FPGA for other purposes.
Requirements¶
In order to use the example designs, you will need the following:
Windows or Linux PC
Xilinx Vivado
Xilinx Vitis
1x Ultra96 development platform
1x 96B Quad Ethernet Mezzanine
If you want to build PetaLinux for the example designs, you will also need:
Linux PC or a virtual Linux machine
PetaLinux SDK
You will also need a CAT-5e Ethernet cable and a link partner, such as a PC with an Ethernet port or a network router.
Additionally, you may need to install the Ultra96 board definition files to your Vivado installation, and obtain an AXI Ethernet evaluation license if you intend to use that design.
Install Ultra96 board definition files¶
To use the example projects, you must first install the board definition files for the Ultra96 into your Vivado and Vitis installation. The Ultra96 board definition files are hosted on Avnet’s Github repo.
Clone or download that repo, then copy the ultra96v1
and ultra96v2
directories from it to the
following directories on your machine:
* <path-to-xilinx-vivado>/data/boards/board_files
* <path-to-xilinx-vitis>/data/boards/board_files
AXI Ethernet evaluation license¶
If you intend to build the AXI Ethernet based design, you will need to get an evaluation (or full) license for the Tri-mode Ethernet MAC from Xilinx. You can find instructions for that here: Xilinx Soft TEMAC license
Build instructions¶
Download the source code¶
The source code for both example designs can be found on our Github page:
96B Quad Ethernet Mezzanine Github page
The repository contains the following directories:
Vivado: Contains the scripts to build the Vivado projects
Vitis: Contains a script to generate and build the standalone software applications
PetaLinux: Contains a script and configuration files to build the PetaLinux projects
EmbeddedSw: Contains modifications to the lwIP software library
Build the Vivado and Vitis projects¶
Once you have installed the board definition files, and you have installed the required licenses, then you can use the sources in this repository to build the Vivado, Vitis and PetaLinux projects. Start by cloning the repo or download it as a zip file and extract the files to your hard drive, then follow these steps depending on your OS:
Windows users¶
Open Windows Explorer, browse to the repo files on your hard drive.
In the Vivado directory, you will find multiple batch files (*.bat). Double click on the batch file of the example project that you would like to generate - this will generate a Vivado project.
You will be asked to select between Ultra96 v1 and v2. It is important to select the correct version of the Ultra96 that you are using. Type 1 or 2 (for v1 or v2) and press ENTER. The script will now generate the Vivado project for your board.
Run Vivado and open the project that was just created.
Click Generate bitstream.
When the bitstream is successfully generated, select “File->Export->Export Hardware”. In the window that opens, tick “Include bitstream” and “Local to project”.
Return to Windows Explorer and browse to the Vitis directory in the repo.
Double click the build-vitis.bat batch file. The batch file will run the build-vitis.tcl script and build the Vitis workspace containing the hardware design and the software application. Please refer to the “README.md” file in the Vitis subdirectory for instructions on running the software application on hardware.
If you are interested in building PetaLinux, you will need to use a Linux machine and follow the steps for Linux users below.
Linux users¶
Launch the Vivado GUI.
On the welcome page, there is a Tcl console. In the Tcl console,
cd
to the repo files on your hard drive and into the Vivado subdirectory. For example:cd /media/projects/ethernet96/Vivado
.Specify the version of Ultra96 you want to build the project for (v1 or v2) by using one of the following commands:
set argv {1}
for v1, orset argv {2}
for v2.In the Vivado subdirectory, you will find multiple Tcl files. To list them, type
exec ls {*}[glob *.tcl]
. Determine the Tcl script for the example project that you would like to generate (for example:build-ps-gem.tcl
), thensource
the script in the Tcl console: For example:source build-ps-gem.tcl
Vivado will run the script and generate the project. When it’s finished, click Generate bitstream.
When the bitstream is successfully generated, select “File->Export->Export Hardware”. In the window that opens, tick “Include bitstream” and “Local to project”.
To build the Vitis workspace, open a Linux command terminal and
cd
to the Vitis directory in the repo.The Vitis directory contains the
build-vitis.tcl
script that will build the Vitis workspace containing the hardware design and the software application. Run the build script by typing the following command:<path-of-xilinx-vitis>/bin/xsct build-vitis.tcl
Note that you must replace<path-of-xilinx-vitis>
with the actual path to your Vitis installation.Please refer to the “README.md” file in the Vitis subdirectory for instructions on running the software application on hardware.
To build the PetaLinux project, follow the steps in the following section.
Build the PetaLinux projects¶
Once the Vivado project(s) have been built and exported, you can now build the PetaLinux project(s).
Note
The PetaLinux projects can only be built on a Linux machine (or virtual Linux machine).
Linux users¶
To build the PetaLinux project, first launch PetaLinux by sourcing the “settings.sh” bash script, eg:
source <path-to-installed-petalinux>/settings.sh
.Now
cd
to the PetaLinux directory in the repo and run thebuild-petalinux
script. You may have to add execute permission to the script first usingchmod +x build-petalinux
, then run it by typing./build-petalinux
.
Warning
UNIX line endings: The scripts and files in the PetaLinux directory of this repository must
have UNIX line endings when they are executed or used under Linux. The best way to ensure UNIX
line endings, is to clone the repo directly onto your Linux machine. If instead you have copied
the repo from a Windows machine, the files will have DOS line endings and
you must use the dos2unix
tool to convert the line endings for UNIX.
Launch on hardware¶
Echo server via JTAG¶
Open Vitis.
Power up your hardware platform and ensure that the JTAG is connected properly.
Select “Xilinx Tools->Program FPGA”. In the “Program FPGA” dialog box that appears, select the “Hardware Platform” that you want to run, this will correspond to name of the Vivado project that you built earlier.
Click on the software application that you want to run, it should be the one with the postfix “_echo_system”.
Open the drop-down menu of the “Run” button (play) on the toolbar. Select “Run Configurations”, then in the dialog box that appears, double-click on the option “Single Application Debug”. This will create a new run configuration for the application.
Select the new run configuration and click “Run”.
PetaLinux via JTAG¶
To launch the PetaLinux project on hardware via JTAG, connect and power up your hardware and then use the following commands in a Linux command terminal:
Change current directory to the PetaLinux project directory:
cd <petalinux-project-dir>
Download bitstream to the FPGA:
petalinux-boot --jtag --fpga
Note that you don’t have to specify the bitstream because this command will use the one that it finds in the./images/linux
directory.Download the PetaLinux kernel to the FPGA:
petalinux-boot --jtag --kernel
PetaLinux via SD card¶
To boot PetaLinux on hardware via SD card:
The SD card must first be prepared with two partitions: one for the boot files and another for the root file system.
Plug the SD card into your computer and find it’s device name using the
dmesg
command. The SD card should be found at the end of the log, and it’s device name should be something like/dev/sdX
, whereX
is a letter such as a,b,c,d, etc. Note that you should replace theX
in the following instructions.Run
fdisk
by typing the commandsudo fdisk /dev/sdX
Make the
boot
partition: typingn
to create a new partition, then typep
to make it primary, then use the default partition number and first sector. For the last sector, type+1G
to allocate 1GB to this partition.Make the
boot
partition bootable by typinga
Make the
root
partition: typingn
to create a new partition, then typep
to make it primary, then use the default partition number, first sector and last sector.Save the partition table by typing
w
Format the
boot
partition (FAT32) by typingsudo mkfs.vfat -F 32 -n boot /dev/sdX1
Format the
root
partition (ext4) by typingsudo mkfs.ext4 -L root /dev/sdX2
Copy the following files to the boot partition of the SD card: Assuming the
boot
partition was mounted to/media/user/boot
, follow these instructions:$ cd /media/user/boot/ $ sudo cp /<petalinux-project>/images/linux/BOOT.bin . $ sudo cp /<petalinux-project>/images/linux/boot.scr . $ sudo cp /<petalinux-project>/images/linux/image.ub .
Create the root file system by extracting the
rootfs.tar.gz
file to theroot
partition. Assuming theroot
partition was mounted to/media/user/root
, follow these instructions:$ cd /media/user/root/ $ sudo cp /<petalinux-project>/images/linux/rootfs.tar.gz . $ sudo tar xvf rootfs.tar.gz -C . $ sync
Once the
sync
command returns, you will be able to eject the SD card from the machine.Connect and power your hardware.
Echo Server Example Usage¶
Default IP address¶
The echo server is designed to attempt to obtain an IP address from a DHCP server. This is useful if the echo server is connected to a network. Once the IP address is obtained, it is printed out in the UART console output.
If instead the echo server is connected directly to a PC, the DHCP attempt will fail and the echo server will default to the IP address 192.168.1.10. To be able to communicate with the echo server from the PC, the PC should be configured with a fixed IP address on the same subnet, for example: 192.168.1.20.
Ping the port¶
The echo server can be “pinged” from a connected PC, or if connected to a network, from
another device on the network. The UART console output will tell you what the IP address of the
echo server is. To ping the echo server, use the ping
command from a command console.
For example: ping 192.168.1.10
Change the targetted port¶
The echo server example design currently can only target one Ethernet port at a time.
Selection of the Ethernet port can be changed by modifying the defines contained in the
platform_config.h
file in the application sources. Set PLATFORM_EMAC_BASEADDR
to one of the following values:
For designs using the GEMs:
Port 0:
XPAR_XEMACPS_0_BASEADDR
Port 1:
XPAR_XEMACPS_1_BASEADDR
Port 2:
XPAR_XEMACPS_2_BASEADDR
Port 3:
XPAR_XEMACPS_3_BASEADDR
For designs using AXI Ethernet:
Port 0:
XPAR_AXIETHERNET_0_BASEADDR
Port 1:
XPAR_AXIETHERNET_1_BASEADDR
Port 2:
XPAR_AXIETHERNET_2_BASEADDR
Port 3:
XPAR_AXIETHERNET_2_BASEADDR
PetaLinux Example Usage¶
In the PetaLinux projects, the Ethernet ports are assigned to the network interfaces eth0-eth3 as follows:
eth0: Port 0
eth1: Port 1
eth2: Port 2
eth3: Port 3
The following examples demonstrate how to use these network interfaces to configure the Ethernet ports for use in PetaLinux.
Enable port¶
In this example we enable port 0 (eth0).
root@ps_gem:~# ifconfig eth0 up
[ 209.778955] TI DP83867 ff0b0000.mdio-mii:03: attached PHY driver [TI DP83867] (mii_bus:phy_addr=ff0b0000.mdio-mii:03, irq=POLL)
[ 209.793249] pps pps1: new PPS source ptp1
[ 209.797193] macb ff0b0000.ethernet: gem-ptp-timer ptp clock registered.
[ 209.803995] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 213.868935] macb ff0b0000.ethernet eth0: link up (1000/Full)
[ 213.874547] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Enable port with fixed IP address¶
In this example we enable port 1 (eth1) with a fixed IP address.
root@ps_gem:~# ifconfig eth1 192.168.2.19 up
[ 209.778955] TI DP83867 ff0b0000.mdio-mii:03: attached PHY driver [TI DP83867] (mii_bus:phy_addr=ff0b0000.mdio-mii:03, irq=POLL)
[ 209.793249] pps pps1: new PPS source ptp1
[ 209.797193] macb ff0c0000.ethernet: gem-ptp-timer ptp clock registered.
[ 209.803995] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 213.868935] macb ff0c0000.ethernet eth1: link up (1000/Full)
[ 213.874547] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Check status of a port with ethtool¶
In this example we check the status of port 2 (eth2) with “ethtool”.
root@ps_gem:~# ethtool eth2
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Link detected: yes
Ping link partner using specific port¶
In this example we ping the link partner from port 1 (eth1).
root@ps_gem:~# ping -I eth1 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 56 data bytes
64 bytes from 192.168.1.10: seq=0 ttl=128 time=0.939 ms
64 bytes from 192.168.1.10: seq=1 ttl=128 time=0.496 ms
64 bytes from 192.168.1.10: seq=2 ttl=128 time=0.486 ms
64 bytes from 192.168.1.10: seq=3 ttl=128 time=0.485 ms
64 bytes from 192.168.1.10: seq=4 ttl=128 time=0.501 ms
^C
--- 192.168.1.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.485/0.581/0.939 ms
Check port configuration¶
In this example we check the configuration of port 1 (eth1).
root@ps_gem:~# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:0A:35:00:01:23
inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20a:35ff:fe00:123%4294741717/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:148 errors:0 dropped:0 overruns:0 frame:0
TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17567 (17.1 KiB) TX bytes:12943 (12.6 KiB)
Interrupt:31
Board Setup¶
Mezzanine fastening hardware¶
For typical development use, in a lab or on a desk, the mating force of the expansion connectors alone is enough to securly fix the mezzanine card to the carrier board. However, for applications requiring higher mechanical robustness, the mezzanine can be fixed to the carrier board using 7mm standoffs and M2.5 machine screws. We suggest the following part numbers, however equivalent parts can also be used:
- Hex standoff, Thread M2.5 x 0.45, Aluminium, Board-to-board length 7mmPart number: M2102-2545-ALManufacturer: RAF Electronic Hardware
- Machine screw, Thread M2.5 x 0.45, Length (below head) 4mm, Stainless steel, Phillips headPart number: 425-035Supplier: Spaenaur
Stacking a second mezzanine¶
A second mezzanine card can be stacked on top of the 96B Quad Ethernet Mezzanine as shown in the image below.

96B Quad Ethernet Mezzanine with stacked Sensors mezzanine (front)¶
The RJ45 connector (0826-1X4T-23-F) has a height of 13.59mm, while the expansion socket has a height of 4.5mm as defined by the 96Boards spec. For this reason, an extender (see image below) is required for stacking most mezzanine cards onto the 96B Quad Ethernet Mezzanine. The extender is a 40-pin pin socket with 8mm long pins that is inserted into the 96B Quad Ethernet Mezzanine’s low-speed expansion socket, effectively increasing it’s height above that of the RJ45 connector. The stacked mezzanine card is then plugged into the extender socket and sits comfortably above the RJ45 connector. We recommend that the following connector be used as the extender socket, however equivalent parts can also be used:
- 40-pin Pin socket with 8mm long pinsPart number: F263-1220A0BSYE1Manufacturer: Yxcon

Extender for stacking second mezzanine card¶
When using the extender socket recommended above, the stacked mezzanine sits at a height of 16mm above the 96B Quad Ethernet Mezzanine, and it can be fixed to the mezzanine by using 16mm standoffs and M2.5 machine screws. We suggest the following part numbers, however equivalent parts can also be used:
- Hex standoff, Thread M2.5 x 0.45, Aluminium, Board-to-board length 16mmPart number: M2111-2545-ALManufacturer: RAF Electronic Hardware
- Machine screw, Thread M2.5 x 0.45, Length (below head) 4mm, Stainless steel, Phillips headPart number: 425-035Supplier: Spaenaur
The image below illustrates the use of the extender socket and 16mm standoffs.

96B Quad Ethernet Mezzanine with stacked Sensors mezzanine (back)¶
Programming Guide¶
This programming guide is specific to users of the Avnet Ultra96 board. The purpose of the guide is to provide the user with the details of the programming requirements to enable them to operate the hardware and customise functionality.
Vivado design¶
We recommend that all users start with our example Vivado designs when using the mezzanine card with the Ultra96. For those who wish to better understand the example designs, or develop their own Vivado designs, this section provides more detail on the critical elements.
SGMII Implementation¶
The 96B Quad Ethernet Mezzanine card was designed to conform with the 96Boards specification for mezzanine cards, however the pinout of the high-speed expansion connector was chosen to maximize its usability when paired with the Ultra96. This section provides an explanation of the pin selection of the SGMII lanes and how to implement the SGMII interfaces in the Vivado design.
The Ultra96 high-speed expansion connector does not provide access to any gigabit transceivers of the Zynq Ultrascale+ device. For this reason, the SGMII interfaces must be implemented using SGMII over LVDS. To implement SGMII over LVDS on the Zynq Ultrascale+, the appropriate IP core is the PCS/PMA or SGMII IP. This IP core has several requirements on the I/O pins with which it can be used. Two of the critical requirements are:
The I/O pair used for TX, and that used for RX must be in the same BYTE_GROUP
The I/O pair used for TX must be in the opposite nibble to that used for RX
For example, the TX and RX pairs of a single SGMII interface could be located in BYTE_GROUP 1, with the TX pair in the lower nibble and the RX pair in the upper nibble.
Given these requirements, the possible pin selections can be determined by looking at the I/O pins that are available to us, and their respective BYTE_GROUPs and nibbles. The high-speed expansion connector of the Ultra96 makes these I/O pins from bank 65 available for use:
BYTE_GROUP |
Nibble |
Available bits (pairs) |
---|---|---|
0 |
Lower |
0,1,2 |
Upper |
Not connected |
|
1 |
Lower |
0,1,2 |
Upper |
0,1 |
|
2 |
Lower |
Not connected |
Upper |
0 |
|
3 |
Lower |
0,1,2 |
Upper |
0 |
Considering the requirements of the SGMII IP and the choice of I/O pins on the high-speed expansion connector of the Ultra96, it is only possible to connect 3 SGMII interfaces:
Interface 0: BYTE_GROUP 1, lower pair 0, upper pair 0
Interface 1: BYTE_GROUP 1, lower pair 1, upper pair 1
Interface 2: BYTE_GROUP 3, lower pair 0, upper pair 0
The 96B Quad Ethernet Mezzanine card has 4 SGMII interfaces. To connect the 4th interface to the Ultra96, we in fact use two SGMII interfaces, where only one direction (TX/RX) of each interface is actually used. This allows us to satisfy the requirements of the SGMII IP with the remaining pins that are available to us. Here is how the 4th interface is connected:
Interface 3 RX: BYTE_GROUP 0, lower pair 0 (RX), upper pair 0 (N/C pins)
Interface 3 TX: BYTE_GROUP 2, upper pair 0 (TX), lower pair 0 (N/C pins)
With this pin selection, the 4th interface requires two SGMII IPs to function - one that handles the RX interface and another that handles the TX interface. The unused TX and RX pins of the SGMII IP cores are assigned to pins that are not externally connected. To connect the GMII interface between the MAC IP and the two SGMII IP cores, we open the interfaces and connect only the RX GMII pins to the RX SGMII core, and the TX GMII pins to the TX SGMII core.
A single SGMII IP core implements all of the SGMII interfaces connected to a single BYTE_GROUP. As interfaces 0 and 1 are connected to BYTE_GROUP 1, they are implemented by a single SGMII IP core. Interface 2 has its own SGMII IP core, as does interface 3’s RX lane and interface 3’s TX lane.
Note
It is possible to implement SGMII over LVDS using the AXI Ethernet Subsystem IP. However, at the time of this writing, the AXI Ethernet Subsystem IP can only implement a single SGMII over LVDS interface. For this reason, the IP cannot be used to implement both interface 0 and interface 1. Instead, to use both interfaces 0 and 1 with AXI Ethernet Subsystem IP, the SGMII over LVDS interface must be implemented with the PCS/PMA or SGMII IP core, and then connected to the AXI Ethernet Subsystem IP cores through internal GMII interfaces. See the AXI Ethernet example design for the required connections.
MDIO bus¶
The 96B Quad Ethernet Mezzanine card uses a single MDIO bus to connect the development platform to the Ethernet PHYs. The Vivado design should only contain one MDIO interface that connects to the external MDIO bus. Communication with all Ethernet PHYs must be performed through this single bus.
The mezzanine card Ethernet PHYs for ports 0,1,2 and 3 have addresses 0x1, 0x2, 0xC and 0xF respectively. If your Vivado design uses IP cores that themselves have PHY addresses (such as the PCS/PMA or SGMII IP), and connect to the same MDIO bus as that of the external PHYs, ensure that these IP cores have unique addresses with respect to the external PHYs.
If using the PCS/PMA or SGMII IP core, the MDIO interfaces of these cores can be chained together such that the output of one connects to the input of another. Be sure to also connect the tri-state signal (MDIO_T) from one core to the next, this is essential for correct operation of the MDIO bus.
EMIO GPIOs¶
In both the PS GEM and AXI Ethernet designs, the EMIO GPIOs are connected to the PHY resets and the PHY GPIOs as shown in the table below:
EMIO
GPIO
|
PHY
Connection
|
GPIO
bank
|
GPIO
bit
|
Pin
mapping
|
---|---|---|---|---|
0 |
PHY0 RESET_N |
3 |
0 |
416 |
1 |
PHY1 RESET_N |
3 |
1 |
417 |
2 |
PHY2 RESET_N |
3 |
2 |
418 |
3 |
PHY3 RESET_N |
3 |
3 |
419 |
4 |
PHY0 GPIO_0 |
3 |
4 |
420 |
5 |
PHY0 GPIO_1 |
3 |
5 |
421 |
6 |
PHY1 GPIO_0 |
3 |
6 |
422 |
7 |
PHY1 GPIO_1 |
3 |
7 |
423 |
8 |
PHY2 GPIO_0 |
3 |
8 |
424 |
9 |
PHY2 GPIO_1 |
3 |
9 |
425 |
10 |
PHY3 GPIO_0 |
3 |
10 |
426 |
11 |
PHY3 GPIO_1 |
3 |
11 |
427 |
The first four EMIO GPIOs are connected to the external PHY RESET_N pins. These can be driven LOW to place the respective PHY in hardware reset. The remaining EMIO GPIOs are connected to the external PHY GPIO_x pins. Although named “GPIO_x”, these PHY pins are in fact output-only and their purpose can be configured by setting the GPIO Mux Control Register of the PHYs via the MDIO bus. Please refer to the DP83867 datasheet for more information.
Constraints¶
For more information on the required constraints, please refer to the XDC files used by the example designs, located in the constraints directory of the Github repository.
PetaLinux¶
This section provides the information required to build PetaLinux or other Linux distributions for use with the 96B Quad Ethernet Mezzanine card.
Device tree for GEM design¶
The required additions to the device tree include:
Define the
phy0
tophy3
nodes within thegem0
nodeWithin each phy node:
Define the PHY address (
reg
)Set the TX and RX internal delay
Set the FIFO depth
Enable SGMII clock for PHY3 (
ti,sgmii-ref-clock-output-enable
)Disable SGMII auto-negotiation in PHY3 (
ti,dp83867-sgmii-autoneg-dis
see DP83867 patch below)
Add these properties to each of the
gem0
togem3
nodes:Set PHY handle (use labels defined in the
gem0
node)Set PHY mode set to GMII
Set PHY reset to connected GPIO
Set PHY reset to active-low
For more detail, refer to the device tree for the GEM design in the Github repository.
Device tree for AXI Ethernet design¶
Define the
phy0
tophy3
nodes within themdio
node of theaxi_ethernet_0
nodeWithin each phy node:
Define the PHY address (
reg
)Specify PHY type to SGMII (
xlnx,phy-type = <0x4>;
)Set the TX and RX internal delay
Set the FIFO depth
Enable SGMII clock for PHY3 (
ti,sgmii-ref-clock-output-enable
)Disable SGMII auto-negotiation in PHY3 (
ti,dp83867-sgmii-autoneg-dis
see DP83867 patch below)
Add these properties to each of the
axi_ethernet_0
toaxi_ethernet_3
nodes:Set PHY handle (use labels defined in the
axi_ethernet_0
node)Set PHY mode set to GMII
For more detail, refer to the device tree for the AXI Ethernet design in the Github repository.
Rootfs configuration¶
In the rootfs configuration, we add the following packages:
ethtool
ethtool-dev
ethtool-dbg
git
iperf3
In PetaLinux SDK, the rootfs is configured using this command: petalinux-config -c rootfs
Kernel configuration¶
The following options must be set in the Kernel configuration:
CONFIG_XILINX_DMA_ENGINES=y
CONFIG_XILINX_DPDMA=y
CONFIG_XILINX_ZYNQMP_DMA=y
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_XILINX=y
CONFIG_XILINX_AXI_EMAC=y
CONFIG_XILINX_PHY=y
CONFIG_NET_CADENCE=y
CONFIG_MACB=y
CONFIG_NETDEVICES=y
CONFIG_HAS_DMA=y
CONFIG_CPU_IDLE=n
In PetaLinux SDK, the kernel is configured using this command: petalinux-config -c kernel
DP83867 Ethernet PHY driver patch¶
SGMII autonegotiation is disabled in the PCS/PMA or SGMII core for port 3, therefore we need to modify the driver so that it can also disable SGMII autonegotiation in the PHY.
To allow for this, we patch the DP83867 driver to accept an extra property in the device tree:
ti,dp83867-sgmii-autoneg-dis
: When added to the GEM node, this will disable the SGMII autonegotiation feature when the PHY is configured (eg. ipconfig eth0 up)
This property should be included in the gem3
node or the axi_ethernet_3
node of
the device tree (depending on the Vivado design being used).
Since PetaLinux release 2020.1, the DP83867 driver will only configure the PHY for SGMII
if the phy-mode
property (PHY interface) in the device tree is set to sgmii
. In
earlier releases, it would assume SGMII if phy-mode
was not set to rgmii
. In our
case, we cannot set phy-mode="sgmii"
because that would cause the MACB driver to
set the SGMIIEN and PCSSEL bits in the GEM. Instead, we use phy-mode="gmii"
and we
patch the DP83867 driver such that it doesn’t require phy-mode="sgmii"
to configure
for SGMII.
The source code for this patch can be found in this path of the Github repo:
PetaLinux/src/common/project-spec/meta-user/recipes-kernel/linux/linux-xlnx
ZynqMP FSBL hooks patch¶
This patch modifies the ZynqMP FSBL to add code to the XFsbl_HookBeforeHandoff which is executed before the FSBL hands over control to U-Boot. This code is necessary for initialization of the 96B Quad Ethernet Mezzanine and the PCS/PMA or SGMII IP cores, so that U-Boot and Linux can make use of the Ethernet ports. The added code does the following:
Initializes GEM0 so that it’s MDIO interface can be used (we need it to communicate with the external PHYs and the PCS/PMA or SGMII IP cores)
Assert reset of PCS/PMA or SGMII IP core
Hardware reset the 4x Ethernet PHYs and release from reset
Enable the 625MHz SGMII output clock of the PHY of port 3 of the 96B Quad Ethernet Mezzanine card (PHY address 0xF). This clock is required by the PCS/PMA or SGMII IP core
Release the PCS/PMA or SGMII IP core from reset
Disable ISOLATE bit on all PCS/PMA or SGMII IP cores, and enable autonegotiation on those cores for ports 0-2. Note that port 3 cannot support SGMII autonegotiation.
The source code for this patch can be found in this path of the Github repo:
PetaLinux/src/common/project-spec/meta-user/recipes-bsp/fsbl/files
xilinx_uartps: Really fix id assignment patch for 2020.1¶
This patch comes originated here: https://www.spinics.net/lists/linux-serial/msg39343.html Without this patch PetaLinux boot hangs after these lines:
console [tty0] enabled
bootconsole [cdns0] disabled
This problem occurs with PetaLinux 2020.1 on Ultra96 when using UART1 as the console output (serial0). Xilinx produced a patch for this problem but it does not properly fix the problem: https://www.xilinx.com/support/answers/75417.html
The complete solution is described in this Xilinx forum post: https://forums.xilinx.com/t5/Embedded-Linux/Freeze-in-Xilinx-Linux-2020-1-Serial-UART-Driver/td-p/1130457