However, the reason that a user may engage BB is that the code is in
some way self modifying - so that following the code static image and
calculating addresses will result in a different path taken.
e.g. imagine an opcode:-
B <address0>
Without BB, this will trace as a single E atom, the decoder will
calculate address0 from the opcode in the static image and continue
from there as the next trace address.
Now look at the case where this is changed on the fly to
B <address1>
With BB, This will trace to
E
TGT_ADDR<address1>
The decoder will initially extract address0 from the static image,
but the immediately following target address packet will alter the
next address traced to address1
This is why we have BB.
So if the user has a reason to engage BB - we should really fail if
it is not present - as the outcome of the trace can be affected.
> Suzuki
>
>
> > + goto out;
> > + } else {
> > + config->cfg |= BIT(ETM4_CFG_BIT_BB);
> > + }
> > + }
> > +
> > out:
> > return ret;
> > }
> > diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h
> > index 4ac5c081af93..6c2fd6cc5a98 100644
> > --- a/include/linux/coresight-pmu.h
> > +++ b/include/linux/coresight-pmu.h
> > @@ -18,6 +18,7 @@
> > * ETMv3.5/PTM doesn't define ETMCR config bits with prefix "ETM3_" and
> > * directly use below macros as config bits.
> > */
> > +#define ETM_OPT_BRANCH_BROADCAST 8
> > #define ETM_OPT_CYCACC 12
> > #define ETM_OPT_CTXTID 14
> > #define ETM_OPT_CTXTID2 15
> > @@ -25,6 +26,7 @@
> > #define ETM_OPT_RETSTK 29
> >
> > /* ETMv4 CONFIGR programming bits for the ETM OPTs */
> > +#define ETM4_CFG_BIT_BB 3
> > #define ETM4_CFG_BIT_CYCACC 4
> > #define ETM4_CFG_BIT_CTXTID 6
> > #define ETM4_CFG_BIT_VMID 7
>
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
