View source for Novena DVT Issue Log

=Hardware Bringup Notes=

* The DDR3 timing has shifted with the new PCB vendor. The hard-coded timings for Micron memories probably needs to be recalibrated.
* R20S/C16S needs tuning, for sure. The default values break Gbit ethernet. Simply removing R20S does restore bandwidth, but the matter warrants further investigation.
* The heartbeat LED D14D is installed 90 degrees rotated. It still lights, it just fires downwards instead of to the side.
* Y10U/Y11U are missing per factory notes. They must be hand-installed for USB to work.
* C11M, C30M, C18M, C52C C45M capacitor is 1210 instead of 1206. Factory has been notified of the mis-ordering of the part.
* R57B 100 ohm -> move to DNP because there is on-chip termination for the FPGA
* PCIe - Rx-side caps are redundant, need to be removed
* HDMI DDC SCL buffer pull-up resistor is too weak

==PVT change list==
* Change R20S, C16S to DNP
* change R57B to DNP
* Add fab note about D14D being side-firing
* Add 300 ohm, 1% resistor (R21S) pull-up to 2.5V to fix duty cycle asymmetry on RGMII_REF_CLK
* Add 0/5in delay line to Gbit RXC, and 0/5/10 in selectable delays (via 0-ohm jumper) for Gbit TXC. Note that PHY has tuning mechanism to add delays, and RXC delay was fully verified to be compliant, so the 5in delay is just for margin. For TXC I believe delay is also compensated in PHY but it's not possible to measure the internal node, and therefore selectable paths are provided.
* Make sure BOM reflects use of switch TL3342F160QG/TR for momentary push-button locations (SW11B, SW10B, SW10S, SW11S)
* Switch out 32.768 kHz crystal from Abracon ABS10-32.768KHZ-7-T 7pf CL to ABS06-32.768KHZ-T 12.5pF CL, due to EOL of ABS10 [done]
* Check BOM for Y10U/Y11U
* Check BOM for C11M, C30M, C18M, C52C, C45M
* U14F - MX25L512CMI-12G is EOL. Replace with MX25L512EMI-10G.
* Add R28A (0 ohm) to control Audio PA power down explicitly to avoid "pop" on audio codec boot
* Add R30A (0 ohm DNP) to provide back-up option in case previous change fails
* Add R33A (100k, 1%) pulldown to ensure audio PA starts up in a power-down state until powered up
* Change C22N from DNP -> 22uF, 10V X5R 20% -- resolve instability during power-up with a high voltage power supply
* Change C21X, C22X from 0.1uF, 6.3V to 0 ohm 0201
* Add soldermask opening near expansion header for +5V expansion supply (switched), big enough to handle both leaf spring and pogo-pin contact points -- expands +5V power capability to expansion board by approx. 2A (so total 3.5A = 17.5W).
* change R33L from 47k, 1% to 4.7k, 1% -- fix HDMI DDC pull-up resistor
* U12F MT41J128M16HA-125 -> MT41J128M16JT-125QK
* P16D HRS F19SC-8S-0.5SH -> HRS FH19SC-8S-0.5SH(05)
* U200 PMPF0100NPEP -> MMPF0100NPAEP
* D11F CDBMT220L-G change to CDBMT220L-G or CDBMT240-HF

Refactor battery connector:
* Disconnect R23N from J10N -- no more reflash/alert line
* Move BATT_NRST to pin 15 (+3.3V) line
* Connect I2C bus to B+/B- pins of connector (to allow direct gas gauge access via CPU)
* Add D17N (ESD5Z2.5T1)
* Change R21N (47k, 1%) to 330, 1%
* Add J11L (test point, DNP) to absorb BATT_REFLASH_ALRT NC line -- reserve for future use since it's already broken out
* Fix ESD protection - ESD5Z2.5T1 changed to ESD5Z3.3T1 in all instances (D10A, D11A, D12A, D12D, D13A, D13D, D13N, D14A, D14N, D15N, D16N)
* Note: For battery board, a button must be added to enable programming of the STM32

[[Novena DVT to PVT ECO List]]

==Changes on battery board to match PVT==
* Add SW101 for micro programming manual enable
* Moved PM_NRST to new location on J100
* Added HOST_SMB_* pins to B-/B+ pins on J100
* R108 connected to 3.3V_UC so default/unprogrammed behavior is to power on novena, instead of turning it off
* Q102, Q103 (BSS138) added to isolate SMB bus from host when master power is turned off (host leakage could pull down SMB when powered off)

===Other issues on battery board===
* PACK signal needs a bootstrapping method. You can prime PACK by turning on the charger, to provide a "PACK" voltage, so when AC is present, you can bootstrap the gas gauge. However, if there is no AC present, and you are just swapping in a battery pack, some method needs to exist to prime PACK, otherwise the gas gauge may go into shutdown after an AC-free battery swap.
* 3.3V_UC bias may not be present when ACIN goes away. This is a problem. Currently, 3.3V_UC is sourced from the charger IC's VREF pin. Originally, I had assumed this VREF would be present whether there was a battery present *or* AC present. However, the enable line to the VREF also looks at ACIN, and will shut down the VREF regulator if ACIN goes below 0.6V. One possibility is to pull from the *protected* battery line enough voltage to keep ACIN above 0.6V (but below the 2.4V required to recognize AC is truly there). Pulling from the protected line means that if the pack gets deeply discharged, the bias circuitry is still turned off and no harm is done. Another possibility is to simply put an extra voltage regulator down that is powered off the diode-OR of the protected battery line and the battery pack that ultimately powers the STM32. This could be a switching regulator to minimize current draw (unlike the present solution which is a linear regulator inside the charger IC). There is a small spot I could put such a regulator on the board, but things are very tight already. Something to ponder.

=Gigabit Ethernet Debug Notes=
Gigabit ethernet has been inconsistent in performance. Multiple factors have been affecting this. Here are the findings.

==You learn something new every day==
Fun fact: RGMII, for versions prior to 2.0, require a 1.6ns skewed clock -- done by adding about 10 inches or so of trace on FR-4 to the clock line versus the data lines. Apparently, someone in HP thought this was a good idea, to the point where HP decided to put notes about patents and IP ownership inside the spec.

Turns out it's a terrible idea. Nobody wants to route 10 inches of extra trace on a clock line. Fortunately, the Micrel PHY chip offers a skew adjust bank of registers to enable you to route clocks with no skew on the PCB. 

xobs wrote a tool to manipulate MII registers directly, https://github.com/xobs/mii-talk

These parameters tune out the skew fairly well:

 miitalk -w 11=0x8104 -w 12=0xf0f0
 miitalk -w 11=0x8105 -w 12=0x0
 miitalk -w 11=0x8106 -w 12=0xffff

We're using the extended control register set for MII, which means we can't just read and write them directly. You set bit 12 of register 11 to indicate a write, and then enter the extended register number in the lower 12 bits. Then, you put the write data into register 12, hence the odd form for miitalk arguments.

*MII extended register number 0x104 is the RGMII clock and control pad skew. Basically, we apply max skew to the clock.
*MII extended register number 0x105 is the RGMII RX data pad skew. We maximally unskew it.
*MII extended register number 0x106 is undocumented in the data sheet, but tests show that it controls RGMII TX data pad skew. A value of 0xFFFF worked nicely.

For the PVT version of the board, an extra 5in trace length (~0.7ns path length) will be added to give more margin, as currently the cal values get us to near the minimum value required (min requirement 1ns, measured 1.3ns), and the spec calls for up to 2.6ns. 

Another issue discovered is that IOMUXC_SW_PAD_CTL_GRP_DDR_TYPE_RGMII was set for a 1.2V I/O, when it should be set for 2.5V I/O. This is fixed using the manual command 

 devmem2 0x20e0790 w 0xc0000

iperf testing shows we're limited now by the 100Mbit hub. Previously bandwidths would drop to <10Mbits/s without proper cal on some boards.

<pre>
root@novena:~/tests/mii-talk# iperf -c xx.xx.xx.xx -d                              
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to xx.xx.xx.xx, TCP port 5001
TCP window size: 78.5 KByte (default)
------------------------------------------------------------
[  4] local xx.xx.xx.xx port 43017 connected with xx.xx.xx.xx port 5001
[  5] local xx.xx.xx.xx port 5001 connected with xx.xx.xx.xx port 15521
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec    108 MBytes  90.7 Mbits/sec
[  5]  0.0-10.0 sec    110 MBytes  91.8 Mbits/sec
</pre>

Fixing the hub problem gets bandwidth up higher:
<pre>
root@bunnie-novena:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local xx.xx.xx.novena port 5001 connected with xx.xx.xx.host port 29480
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec    440 MBytes    369 Mbits/sec
[  5] local xx.xx.xx.novena port 5001 connected with with xx.xx.xx.host port 29494
[  5]  0.0- 9.9 sec    379 MBytes    320 Mbits/sec
[  4] local xx.xx.xx.novena port 5001 connected with with xx.xx.xx.host port 29498
[  4]  0.0-10.0 sec    441 MBytes    370 Mbits/sec

$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  4] local xx.xx.xx.host port 5001 connected with xx.xx.xx.novena port 41491
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec    235 MBytes    197 Mbits/sec
[  4] local xx.xx.xx.host port 5001 connected with xx.xx.xx.novena port 41492
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec    223 MBytes    187 Mbits/sec
</pre>

==Tuning TX to PHY==

The PHY default values are overdriving the outputs. Drive clock at 60 ohms, data at 48 ohms.

Therefore:

 devmem2 0x20e036c w 0x1b020  # set RGMII_TXC
 devmem2 0x20e0388 w 0x1b028  # set TX_CTL
 devmem2 0x20e0370 w 0x1b028  # set RGMII_TD0
 devmem2 0x20e0374 w 0x1b028  # TD1, etc.
 devmem2 0x20e0378 w 0x1b028
 devmem2 0x20e037c w 0x1b028

Due to asymmetry in the refclk, it may be necessary to juice up TD0-TD3 to a value of 0x1b0b0, but this causes a lot of overshoot. Let's try 0x1b028 and instead fix the asymmetry issue.

Note that DVT has TXC and TD* exactly lined up when measured at the PHY, so adding a few inches of trace length on TXC isn't a bad idea. On PVT there will be an option to put a 0-ohm jumper to select 0 in, 5in, and 10in delays.

Refclk asymmetry can be largely corrected by adding a 300 ohm pull-up to 2.5V on the receiving end as a terminator. A stronger pull-up (100 ohms) causes too much upward shift of the low value; a weaker one (1k) has virtually no impact.

==TL;DR version==

<pre>
#!/bin/sh

echo "Temp fix to patch up gigabit ethernet timings. Will be rolled into a later kernel release."
echo "Assumes you have checked out and built  https://github.com/xobs/mii-talk in ~/tests/mii-talk"

/home/root/tests/mii-talk/miitalk -w 11=0x8104 -w 12=0xf0f0
/home/root/tests/mii-talk/miitalk -w 11=0x8105 -w 12=0x0
/home/root/tests/mii-talk/miitalk -w 11=0x8106 -w 12=0xffff

devmem2 0x20e0790 w 0xc0000

devmem2 0x20e036c w 0x1b020  # set RGMII_TXC
devmem2 0x20e0388 w 0x1b028  # set TX_CTL
devmem2 0x20e0370 w 0x1b028  # set RGMII_TD0
devmem2 0x20e0374 w 0x1b028  # TD1, etc.
devmem2 0x20e0378 w 0x1b028
devmem2 0x20e037c w 0x1b028
</pre>

=Quick Tests=
* Memory tester: http://memtester.sourcearchive.com/downloads/4.2.2-1/memtester_4.2.2.orig.tar.gz
* wget large file from bunniefoo on all active interfaces: curl -o /dev/null http://bunniefoo.com/bunnie/test.bin
* mass storage on both USB ports

Helpful: stty rows 72 columns 132

=Distribution Log=
SN001: bunnie
* first time pass

SN002: xobs
* first time pass

SN003: bn.d
* ASIX chip has bad solder joints; now fixed, runs at 8428kiB
* Gbit: 365 Mbps (incoming) 202Mbps (outgoing) - iperf test
** has 300 ohm pull-up to 2.5V on termination of ethernet refclk
* 2GB single-rank Crucial SO-DIMM
* USB ok

SN004: ra.e
* Gbit: 366 Mbps (incoming) 200 Mbps (outgoing) - iperf test
* ASIX: 8400kiB
* 4GB dual-rank Crucial SO-DIMM
* USB ok

SN005: te.r
* 4GB dual-rank PNY SO-DIMM
* Gbit: 351 Mbps (incoming) 199 Mbps (outgoing) - iperf test
* ASIX: 8319kiB
* USB ok

SN006: to.r
* 4GB dual-rank crucial SO-DIMM
* Gbit: 198 Mbps (outgoing) 370 Mbps (incoming)
* Asix: 94.6 Mbps (incoming) 94.0 Mbps (outgoing)
* USB ok

SN007: bi.m
* 2GB single-rank crucial SO-DIMM
* Gbit:
* Asix:
* USB ok
* 200 hours burn-in ok
* RTC measurement (~80PPM)
* note to self -- update kernel to latest image prior to shipment