On 26 February 2015 at 02:09, Grazvydas Ignotas <notasas@xxxxxxxxx> wrote:
> I've finally got rid of nTRST pulldown (haven't connected TDO though),
> created hw-omap3.{h,cc}, but couldn't get it to do anything, until it
> came to my mind that you may be running ARM on your BBB slower that
> 1GHz that I'm using on my DM3730. So lowered the clock to 500MHz and
> voila, it worked!
I'm actually running at 1 GHz also, but I must admit I only assumed no
explicit delays would be necessary when bit-banging, I didn't actually
check to see what kind of TCK speed it produced. It's actually
slightly surprising to me that the CPU would end up the bottleneck.
Enabling TDO will also assuredly slow things down incredibly: without
it I'm just doing writes, which are posted (aka buffered / performed
asynchronously), while inserting a read will stall the cpu until it
gets an answer from the peripheral.
Thinking of it... unless the control module and relevant GPIO module
are connected to the same L4 interconnect (which they aren't in my
test case) I should actually perform at least a dummy read (aka "OCP
barrier") from the control module before accessing GPIO since
otherwise it's not even guaranteed that all writes to the control
module have completed. Joy.
If you want guaranteed reliability, modify tck_pulse() to insert
aforementioned barrier + an actual delay at all three points where I
put comments about them. usleep(50) or so should do the job.
> I guess I'll still connect TDO as it's not so much fun without it,
> going to try connecting to EMU0 too, hopefully it doesn't mess up the
> boot modes.
Note that you can use *any* gpio. I just used one of the EMU pins
because the am335x lets you reconfigure those to GPIO and it was
conveniently nearby. Anyhow, even if you do use EMU0 (or EMU1) for
this, TDO is only driven during data transfers and high-Z otherwise,
so you'd need very good aim with your power-on-reset pulse to manage
to get the EMU pin sampled low (assuming the line even has enough
capacitance to avoid being pulled up fast enough).
> My main goal is to have hardware watchpoints on the cased production
> unit without extra hardware, and it looks like I can finally have
> that, thanks!
You're welcome!
> It sure is! The only thing I do not understand is why are you using
> that process_vm_readv() call, mmap() already makes unprivileged user
> mode writable mappings.
Obviously, otherwise process_vm_readv() would give EFAULT also.
The issue here is not the MMU but the control module itself. I don't
know the situation on the omap3, but at least on recent SoCs the
control module checks the request privilege (OCP MReqSupervisor
signal) and ignores all unprivileged writes. In this case that request
flag comes from the AWPROT[0] signal of the AXI bus, which (for
uncacheable writes) is set based on the CPU processor mode with which
the store-instruction is executed.
Matthijs
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
