<clever>
but the AP only supports certain sizes, 32bit word only i think
<clever>
oh, wait, that looks like the debug rom again!
<clever>
yep, it perfectly matches `dap info 0`
<clever>
but its also interesting to note, BASE said the rom is at 0x80000000, but i also found it at 0
tsal has joined #openocd
tsal_ has quit [Ping timeout: 264 seconds]
Hawk777 has joined #openocd
nerozero has joined #openocd
renrelkha has quit [Quit: bye]
renrelkha has joined #openocd
JakeSays has quit [Ping timeout: 248 seconds]
JakeSays has joined #openocd
<borneoa___>
clever: on cortex-m yes. The bus behind the AP is both accessing the debug registers of the CPU and the memory bus of the CPU.
<borneoa___>
clever: but not on cortex-a and cortex-a. The AP accesses to the debug registers only. You have to halt the CPU and inject a load instruction in the CPU pipeline to read the memory.
<clever>
ahh
<clever>
and then make sure you dont corrupt registers when doing that load
<clever>
which also means, its respecting the MMU?
<borneoa___>
clever: this makes sense because of virtual memory on cortex-a, but is annoying on cortex-a that has no MMU
<clever>
and if i'm attaching to a linux instance, the paging tables are going to be constantly swapping out the userland half of things
<borneoa___>
clever: correct. There is also the cache, but that could be easier to make it coherent withe the debug bus, while the MMU is more complex
<clever>
for the A7, as long as the SMP bit is set in ACTLR, then the cache should remain coherent between all of the arm cores
<clever>
so it doesnt matter which one you halt? it will just steal the L1 from a neighbor, like normal?
<clever>
assuming nothing funny like a page being marked as non-cache on one core but cached on another
<borneoa___>
clever: correct. I was suggesting that a debug bus that access the memory can also be coherent withe the cache, but this will not solve the issue of virtual addressing
<clever>
yeah
<clever>
you would need to walk the paging tables externally
<clever>
but this also implies, that loading a binary into ram, has worse performance on cortex-a?
<clever>
because you have to feed everything thru that special debug register?
<clever>
and have code running on the target core copy it to a register, and then store to ram
<clever>
while on cortex-m, you can just use the TAR and auto-increment, to write 32bits directly to ram with each APACC write, and not have to touch IR or anything else
<borneoa___>
clever: usually in cortex-a SOC you have an AP that has direct access to the system bus and you can access peripheral and memory without haltinc the CPU. But only physical addresses and no cache coherency. Topically named AXI port due to the bus behind
<clever>
ahh
<clever>
but when i was poking around with my custom jtag driver, only AP 0 gave any response
<clever>
AP 1-15 returned 0 in every register
<borneoa___>
clever: for handling paging externally you still need to halt the core and access the virtualization registers
<borneoa___>
clever: probably the other AP are not clocked
<borneoa___>
clever: yes, access through CPU is slower
<clever>
let me connect openocd to it again
<clever>
> dap info 1
<clever>
AP # 0x1 AP ID register 0x00000000 No AP found at this AP#0x1
<clever>
borneoa___: i the ID register present even when unclocked? or might this chip just not have another AP for that?
<clever>
how are you meant to detect the availavle AP's and turn on that clocking?
<clever>
s/i the/is the/
<borneoa___>
clever: yes, you can get zero, it depends on the way the AP is implemented. The only way you have is to check the documentation
<borneoa___>
clever: I mean the doc of the SOC
<clever>
the docs on these SoC's are rather sparse, and dont really say how to use jtag
<clever>
the arm core was more of an after-thought originally, and the SoC already has a second jtag port for all of the system debug stuff
<clever>
so they may have just not included that MEM-AP on the arm side
<clever>
and just to confirm, there is a special register, that both the MEM-AP and arm core have r/w access to? and the MEM-AP debug registers can basically force-feed the instruction decoder? bypassing i-fetch?
<borneoa___>
clever: I don't know, it's really implementation depending.
<clever>
ah, so some might expose all registers via the MEM-AP, while others might expose just 1 register, and you need to use a mov to shuffle data between things?
gpol has quit [Ping timeout: 248 seconds]
gpol has joined #openocd
Andreas has joined #openocd
Andreas has quit [Client Quit]
<borneoa___>
clever: usually the partitioning is per AP. Opening one AP gives access to all the resources behind it. Different security levels can allow different pattern of which AP to open. It could be the boot firmware that decides which AP to enable
<borneoa___>
clever: but again, it's implementation depending, so anything is possible
<clever>
the "jtag gpio" flag allows the jtag pins to be muxed on the gpio array like any other peripheral
Haohmaru has joined #openocd
<clever>
i suspect the "jtag bash" flag relates to 381-L413, and allows the firmware (an entirely seperate cpu cluster) to bit-bash the jtag from internal registers
<clever>
this is the "second" jtag port, the main system one
<Haohmaru>
borneoa___, what kind of cortex were those?
Hawk777 has quit [Quit: Leaving.]
<borneoa___>
Haohmaru: single or dual, cortex-a7 or cortex-a35
<Haohmaru>
fancy
<Haohmaru>
probably very fast but probably not for me
JakeSays_ has joined #openocd
JakeSays has quit [Ping timeout: 260 seconds]
JoseT has joined #openocd
vampirefrog has quit [Quit: Leaving]
JakeSays_ has quit [Quit: passes out]
JakeSays has joined #openocd
slobodan has joined #openocd
JoseT has quit [Quit: Client closed]
<Hammdist>
hey all. I have a custom ft232h board that maps as tck/tms/tdi/tdo/rst, not tck/tdi/tdo/tms/rst. can this be made to work? opening the docs for ftdi driver now
<Hammdist>
site down?
<Hammdist>
openocd.org took too long to respond.
<PaulFertser>
Hammdist: no, TMS, TDO, TCK and TDI are all fixed to certain GPIOs in hardware, you can reed the MPSSE app note.
<PaulFertser>
openocd.org opens, and it's hosted by SF.net currently, not self-hosted.
<Hammdist>
trying access from greece. something's wrong somewhere. could be my ISP
<PaulFertser>
Hammdist: I assume you do not want to bitbang JTAG with an MPSSE capable device.
<PaulFertser>
BTW, if you installed OpenOCD on your machine you should have all the docs too, no need for the Internet web sites.
<Hammdist>
ok you are right I think the pins are wired correctly but in a different order on my pin header than ACBUSx
<Hammdist>
as I'm attaching duponts that's all fine
<PaulFertser>
:)
<Hammdist>
ADBUS*, not ACBUS
zjason`` is now known as zjason
<Hammdist>
is the 3.3v emenating from an ft232h internal regulator sufficient to power a blue pill board typically?
JoseT has joined #openocd
<PaulFertser>
Hammdist: hm, not sure, it's quite weak, why risk it if you can power bluepill externally via USB?
Guest73 has joined #openocd
<Guest73>
Hi, I need to connect to a power-pc target however there is no target for it. The following page suggests open source implementations are available:
<PaulFertser>
Guest73: PPC doesn't seem to be supported by any Free Software solution. Unless you just need to reprogram CFI-attached flash or something like that. There's some rudimentary support in UrJTAG.
<Haohmaru>
mv power-pc weakness-pc
<Guest73>
PaulFertser: Programming the CFI flash should be Ok for my first steps.
<PaulFertser>
Guest73: if you can find BSDL file for the target then UrJTAG will do by bitbanging the flash via boundary scan feature.
<Guest73>
BDSL is available.
<PaulFertser>
Guest73: CFI parallel flash is known to work with UrJTAG implementation then, doesn't matter what target it is, the main thing is having boundary scan available.