We have a design that uses a TI 66AK2H06. We want to use the SGMII interfaces on that part for 1Gb Ethernet. The reference clock supplied to the SGMII interfaces (SRIOSGMIICLK, package balls AW34 and AW35) in our design is 125 MHz. According to table 10-29 in the datasheet (SPRS866E), the acceptable frequencies for this clock (expressed as clock periods) are 312.5 MHz, 156.25 MHz and 125 MHz, so our clock frequency meets the datasheet spec.
The KeyStone II Architecture Serializer/Deserializer (SerDes) User’s Guide (SPRUKO3B) section 9.3 on page 49 (SGMII Interface: Recommended SerDes Register Configuration Options) says “Configuration of this PHY interface is handled through the driver code provided in the TI Multicore Software Development Kit (MCSDK) and Chip Support Library (CSL).... The configurations supported are listed below in Table 9-1.”
Table 9-1. SGMII Configurations supported by TI MCSDK / CSL
Config Baud Rate 1X Rate (Gbps) 1/2X Rate (Gbps) 1/4X Rate (Gbps) Ref Clock (MHz) Bit Width
5.0 Gbps -(1) - 1.25 125 10
5.0 Gbps - - 1.25 156.25 10
5.0 Gbps - - 1.25 312.5 10
(1) Indicates that the rate is NOT supported
Now, I assume that the “driver code” referred to above means the U-Boot bootloader and the Linux kernel driver, which I checked out from the TI git repositories at
git://git.ti.com/keystone-linux/u-boot.git
git://git.ti.com/keystone-linux/linux.git
The 66AK2H Evaluation Module (EVMK2H) uses 156.25 MHz, and as far as I can tell, the driver code in both the bootloader and Linux assume that the SGMII reference clock is 156.25 MHz. For example, in u-boot/drivers/net/keystone_serdes.c, I find the following:
struct serdes_cfg {
u32 ofs;
u32 val;
u32 mask;
};
static struct serdes_cfg cfg_cmu_156p25m_5g[] = {
{0x0000, 0x00800000, 0xffff0000},
{0x0014, 0x00008282, 0x0000ffff},
{0x0060, 0x00142438, 0x00ffffff},
{0x0064, 0x00c3c700, 0x00ffff00},
{0x0078, 0x0000c000, 0x0000ff00}
};
static struct serdes_cfg cfg_comlane_156p25m_5g[] = {
{0x0a00, 0x00000800, 0x0000ff00},
{0x0a08, 0x38a20000, 0xffff0000},
{0x0a30, 0x008a8a00, 0x00ffff00},
{0x0a84, 0x00000600, 0x0000ff00},
{0x0a94, 0x10000000, 0xff000000},
{0x0aa0, 0x81000000, 0xff000000},
{0x0abc, 0xff000000, 0xff000000},
{0x0ac0, 0x0000008b, 0x000000ff},
{0x0b08, 0x583f0000, 0xffff0000},
{0x0b0c, 0x0000004e, 0x000000ff}
};
static struct serdes_cfg cfg_lane_156p25mhz_5g[] = {
{0x0004, 0x38000080, 0xff0000ff},
{0x0008, 0x00000000, 0x000000ff},
{0x000c, 0x02000000, 0xff000000},
{0x0010, 0x1b000000, 0xff000000},
{0x0014, 0x00006fb8, 0x0000ffff},
{0x0018, 0x758000e4, 0xffff00ff},
{0x00ac, 0x00004400, 0x0000ff00},
{0x002c, 0x00100800, 0x00ffff00},
{0x0080, 0x00820082, 0x00ff00ff},
{0x0084, 0x1d0f0385, 0xffffffff}
};
These are arrays of triplets that contain the address offset, value and mask used in read-modify-write operations to configure the SerDes registers. The base address to which the offsets are added is 0x0232a000 (there is a preprocessor symbol KS2_SGMII_SERDES_BASE defined to this value). Table 6-1, part 5 of 13 on page 86 of the datasheet (SPRS866E) states that this address is, indeed, the bottom of the 8K PA (Packet Accelerator) SerDes configuration space.
As far as I can tell, these registers are completely undocumented.
Furthermore, there do not exist corresponding blobs of magic numbers for the other two supported reference clock frequencies (312.5 MHz and 125 MHz). It almost seems as if someone hasn’t gotten around to generating the values yet.
