<clever>
now that i look at this again, after writing jtag stuff, it makes a lot more sense
<clever>
`-irlen` is obvious, and `-ircapture` is what the hw loads into the shift-reg on capture-ir, and what openocd should then expect as a result after every shift-ir
<Hawk777>
Yep!
<clever>
Hawk777: i also notice, the ADI is talking about large address spaces, and addr 8 is the upper 32bits of the TAR register
<clever>
that seems to imply that TAR acts within the physical memory bus?
<clever>
but that conflicts with other things ive see....
<clever>
and if i try to use BD0 thru BD3 to dump a 256 byte block, i just get those 4 words repeating
<clever>
thats the addr that BASE pointed to
<clever>
and i get the same pattern if i dump a whole 4096 byte chunk
<Hawk777>
Doesn’t the TAR act within the bus attached to the MEM-AP? I thought it did.
<Hawk777>
Though again that is ADIv5 I am familiar with.
<clever>
Hawk777: yeah, but why else would the ADI mention support for 64bit addressing? might there be multiple MEM-AP's? for the rom and physical bus?
<Hawk777>
There could be multiple APs.
<Hawk777>
Some MCUs have multiple.
<clever>
ive tried reading AP's 0-15, and only 0 returns non-zero values
<clever>
1-15 are all 0 for every reg
<Hawk777>
So you read BASE and get 0x80000000, then you put 0x80000000 into TAR, then you read from BD0, BD1, BD2, and BD3 and you get those four values?
<clever>
yep
<clever>
then i increment TAR by 16, and read those 4 again, and get the same 4 values
<Hawk777>
And you’re sure your JTAG-layer stuff (e.g. OK/FAULT-vs-WAIT, RnW, SELECT, not expecting data on the first APACC but instead doing a final DPACC to RDBUFF, checking CTRL/STAT for faults, …)?
<clever>
the value at the very end, after all of my poking around
<clever>
dpacc_read(0,4); was how i read it
<clever>
ah yes, this is where the power-up request/ack bits are
<clever>
and those are the only bits set
<Hawk777>
Is it possible that this AP can’t access anything because the bus you’re trying to read from is powered down or its clock is stopped? Or perhaps the device’s reset signal is held asserted?
<clever>
Hawk777: linux is running, and responding over both uart and ssh
<Hawk777>
I’m most familiar with STM32H7; on there, if SRST is asserted, only AP2 works.
<Hawk777>
Oh, it could be putting the processor to sleep and stopping the clock though perhaps?
<clever>
dont think it has support for that, beyond the stock stuff arm has
<clever>
and i probe jtab just seconds into the boot
<clever>
when linux is busy doing a bunch of stuff
<Hawk777>
Also, is it possible you need to set some nonzero values in PROT, CACHE, and TYPE (in CSW) in order to access that memory?
<clever>
there is a "slight" hw design flaw, and re-flashing the debugger hard-resets the target
<clever>
so linux gets a improper reboot on every test, lol
<Hawk777>
Still, I wouldn’t assume that just because it’s fairly busy that the CPU must be running. It could be sleeping on I/O.
<clever>
and both linux and the pico are booting together
<Hawk777>
Waiting for an interrupt, or whatever.
<clever>
let me go over CSW again
<Hawk777>
Your printout said 0x42 in the Github paste.
<Hawk777>
For which PROT, CACHE, and TYPE would all be zero.
<Hawk777>
I also wonder whether it’s possible that the MEM-AP addresses could be subjected to MMU translation, so you’re not actually reading the address you ask for.
<Hawk777>
I don’t know whether they’re physical or virtual.
<Hawk777>
My guess would be physical.
<clever>
i would also guess physical, because each arm core can have its own paging table tree
<clever>
and there is only one AP?
<clever>
so it would be weird for it to be subject to the MMU of just a single core
<Hawk777>
That would be very weird yes.
<Hawk777>
Also conceptually weird; I would expect the MEM-AP to just be another master in the system bus matrix.
<clever>
yeah
<clever>
oh, interesting, the size field in CSW is set to byte mode
<clever>
ah wait no, the 2, word mode, nvm
<clever>
auto-increment is off, but it doesnt matter much here
<Hawk777>
Yeah, that shouldn’t matter, you’re re-writing TAR every loop iteration anyway.
<clever>
DeviceEn is high, so "Transactions can be issued through the MEM-AP."
<clever>
the BD regs also dont trigger auto-increment
<Hawk777>
Oh OK.
<clever>
only DRW can
<clever>
the bank registers ignore the lower 4bits of the TAR register, forcing it to access a 16 byte aligned window
<clever>
with each bank register accessing a 4 byte chunk of that window
<Hawk777>
Not relevant, but I don’t think there’s any reason for apacc_write to return a value, nor read from RDBUFF.
<clever>
let me see what type and cache do
<clever>
good point, i mostly just copied the write function, and flipped the r/w flag
<clever>
the ADI mentions that the prog/type bits should default to a valid access type
<clever>
i suspect those are to emulate secure and non-secure access from the debugger
<clever>
CFG comes back all 0, so the large-data flag is missing, so this MEM-AP lacks 64bit support
<clever>
and its currently connected to a pi2, so it should be a 32bit only arm core
<clever>
the dram controller and general system bus are also limited to a max of 1gig of ram
<clever>
so its more of a 30bit addr bus
nerozero has joined #openocd
<clever>
only starting with the pi4 did that 1gig limit get broken
braunr has quit [Remote host closed the connection]
Hawk777 has quit [Quit: Leaving.]
braunr has joined #openocd
zjason`` has joined #openocd
zjason` has quit [Ping timeout: 255 seconds]
<gamiee>
borneoa___ : hi, thank you for merging my TCL patch. I want to ask, I sent email to tom-van few weeks ago about my BL602 flash driver, asking for review, sadly, no answer. Beside you and tom-van, in the past 2 years, I don't see any other maintainer commiting into Flash drivers part.
<gamiee>
Please, do you know about anyone else I can contact about reviewing the patch? Thank you.
<borneoa___>
gamiee: hi Marek, lack of maintainer's time is unfortunately a common issue in most of open source projects. And for OpenOCD all maintainers contribute in their spare time. I could eventually review your flash driver, but I will left Tomas to do the last review and merge.
<gamiee>
borneoa___ : I totally understand that, and I appreciate both yours, Tomas and other maintainers work. I just wanted to know if there is anyone else who I can ask for review, or if I can do anything to help up with the upstreaming process.
<gamiee>
Thank you for fast answer, and I will patiently wait for review :)