[Libre-soc-bugs] [Bug 50] nmigen pinmux
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Thu Dec 9 20:35:38 GMT 2021
https://bugs.libre-soc.org/show_bug.cgi?id=50
--- Comment #74 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Luke Kenneth Casson Leighton from comment #73)
> (In reply to Andrey Miroshnikov from comment #72)
> use test_jtag_tap.py instead.
Test_jtag_tap.py doesn't interact with the core/pad signals using the "ios"
dict directly, which I guess it can't anyway (because everything has to be done
via TDI/TDO).
The DMI and WB code I took from test_jtag_tap.py was more just to play with,
see if it did anything. I saw that the FSM was updating and JTAG clocks were
ticking, so good sign there.
Looking at "show jtag", I saw a few signals of note:
-irblock_ir (which is produced from a 4-bit ir in irblock) determines the mux
connections.
-io_bd is connected to the jtag shift register, and is the second option for
the pad muxes
For switching the muxes to break pad/core connection, I need to somehow clear
the irbloc_ir signal, I guess it can be done via one of the "jtag_" commands (I
haven't figured out which one).
Do you know the sequence shifting in data? Or where I can find an example
sequence? (Did not find such an example in jtag.py, jtagutils.py,
test_jtag_tap.py, test_jtag_tap_srv.py)
Your example of writing to the "ios" shift register doesn't change the bits in
io_sr/io_bd:
top.jtag.ios['uart_0__rx'].core.i.eq(1)
yield
top.jtag.ios['uart_0__rx'].core.i.eq(0)
yield
I tried:
-Reseting the JTAG
-Setting the TDI bit (which didn't work)
-Running jtag_set_shift_ir() a few times
Interestingly enough, I'm seeing TDO toggle when jtag_set_shift_ir() is being
called.
>
> $ ps auxww | grep vi | wc
> 586 7162 56392
>
> for the past 10 years i now have to do "jobs | grep {filename}"
> in many of the xterms i have open.
>
Sorry, I don't understand why your are checking for "vi" processes. Is this for
when you have so many terminals open, that you just trying to find the right
one? But then why count the number of entries with wc?
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list