bcm_100g_dsc_cycle.sh tunes once - gbsyncd paused, serdes-tx-set on
sys 0..7, tx_taps per lane - then repeats: port 268 en=0, wait, en=1,
wait, phydiag 268 dsc on both units, and the retimer read back with
serdes-tx-get / serdes-rx-get for sys 0..7. One log per run under
~/dsc_log, split by "### TEST CYCLE n/N", ending in
"### DSC_CYCLE_DONE rc=<n>" for a TTL wait to key on.
Waiting for a link state polls "bcmcmd ps <port>" rather than reading
"show interfaces status". "port en=" changes the SDK, and the SONiC
table only follows once gbsyncd and orchagent have synced it - and this
test pauses gbsyncd, so the SONiC table was the wrong thing to wait on.
The state is read from the row whose first field ends in "(<port>)", and
"down" is tested as "not up" so !ena counts.
All output is ASCII English on purpose: the DUT serial console mangles
UTF-8, and a Chinese error message came back as "ERROR: -c ? 1" - an
error you cannot read is worse than none. -d echoes every command as a
grey [CMD] line, CMD_DELAY paces them, and -n is a dry run that touches
nothing and sleeps not at all. The cycle count may be given as a bare
argument, which is what people type first.
Not verified on hardware. gbsyncd is unpaused again on exit, Ctrl-C
included.
tools/100G_dsc_cycle.txt is the hand-typed bench version of the same
commands, kept the way BER_Test.txt and TR518.txt are, so the script can
be checked against what a person would actually run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014RetWKFZFG1ZHcitQAyhwM
etwenandClaude Opus 5
dd558a7b0f