[PATCH] serial: DCC(JTAG) serial and console emulation support
Nicolas Pitre
nico at fluxnic.net
Fri Oct 8 17:25:24 EDT 2010
On Fri, 8 Oct 2010, Tony Lindgren wrote:
> * Nicolas Pitre <nico at fluxnic.net> [101007 18:16]:
> > On Thu, 7 Oct 2010, Tony Lindgren wrote:
> > >
> > > Can you please pass the read and write functions to the driver
> > > in platform_data? We are already booting kernels with both
> > > ARMv6 and 7 compiled in.
> >
> > No. This has nothing to do with platform as this can be determined
> > within the driver itself. Would be much better to simply determine
> > which flavor to use at driver init time and assign two function pointers.
>
> In the long run some platform init code is needed for powering
> up the JTAG interface and take care of pin multiplexing etc.
Really? That would be really strange and rather different from all the
JTAG setups I've seen where the power-up of the interface is done
externally i.e. controlled by the JTAG dongle.
> Also, isn't DCC (Debug Communications Channel) a JTAG standard?
No.
> At least the following does not say anything about DCC being ARM
> specific:
>
> http://en.wikipedia.org/wiki/Joint_Test_Action_Group
So called DCC may be part of an extension built on top of JTAG which is
not "standardized". Each vendor implements their own extensions, which
may or may not include something that can be described as DCC. The JTAG
standard concerns itself with only the basic stuff in the full stack.
You may have a look at OpenOCD to see how wildly different the debugging
interfaces implemented on top of JTAG are.
Furthermore, the DCC access from within the target are implementation
specific. In this case, it is a particular ARM coprocessor access,
which as the patch shows is not even the same across all ARM versions.
And that's valid only for those ARM flavors that implement the
EmbeddedICE or CoreSight. On XScale, the debug facility built on top of
the JTAG interface is completely different from the ARM Ltd one, relying
mostly on software support injected in a special i-cache. In that case,
the notion of a DCC would be implemented in software instead of relying
on a specific hardware register, multiplexed with other messages sent
over the JTAG interface.
> BTW, we already have ETM (Embedded Trace Module) in arch/arm/kernel/etm.c.
> That is set up as amba driver.
That should be Embedded Trace Macrocell.
Nicolas
More information about the linux-arm-kernel
mailing list