The Marvell CN9130 has a rather somewhat strange TAP setup with a custom two level TAP router.
Top level TAP. Uses a custom bypass instruction to access inner TAPs. The standard BYPASS instruction bypasses all. List of inner TAPs, uses a config instruction to enable their DAP which enables both IR and DR for the DAP DAP From what I remember the custom bypass instruction also affects IDCODE. Possibly required for any command that requires assess to data from the inner TAPs. But it was several years ago since I was probing the JTAG implemenation and memory on this detail is a little dim. The IR length is not affected by the custom bypass instruction. The top level TAP is the chip level boundary scan TAP. Some years ago I implemented support for this (tcl/target/marvell/cn9130.cfg), using a two stage initialization 1. Start with a single TAP for the chip, enabling initial chain validation to detect the chip 2. Switch TAP declaration to the full setup splitting the IR in the individual TAPs provided by the chip and with the custom bypass instruction on the top level TAP. 3. Enable each DAP that should be enabled, using irscan/drscan to access the Marvell specific JTAG command. And enable their corresponding TAP. And this works fine on initial access. But if a DAP is already enabled then things breaks down due to the unexpected IR length when OpenOCD verifies the JTAG chain, creating a problem when repeatedly attaching to a running system where the scan chain might differ from the reset state. Any suggestions on how to handle this in a reasonably clean manner? As a workaround one can hack the irlen of the initial TAP (bs for boundary scan) to 25 instead of 19 bits to match the ir length with the main CPU DAP enabled. But this then obviously fails is the chip is in default state or if another DAP have been enabled. Is there some way to probe and massage the JTAG a bit using adapter level irscan/drscan to reset the DAP enable configuration before OpenOCD initializes the actual scan chain?
