etwenandClaude Opus 5
dd558a7b0f
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