<warpme>
jernej: fyi: i done series of boot tests on h616 ddr3, lpddr3 and lpddr4 devices with ram sizing & emmc patches applied. all 400-600 services per ram type were ok. fantastic work!
<warpme>
services->boots
<jernej>
warpme: great! That's a good reason to post patches
<warpme>
i'm a bit loaded now with display port support on rk3588 + some seriously sad events in my family....
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<jernej>
warpme: Sorry to hear that. I mean that I should post patches, but if you want, I can put you in cc.
<jernej>
there is an issue with 64-bit platforms - you need CTI and DBG addresses, which are not documented
<jernej>
A523 has fortunately an info table, accessible through debug interface and with H616 I had a bit of luck doing educated guesses
<paulk>
so "dap info" doesn't list the address?
<paulk>
I'll take a look, normally the ROM table should describe everything
<jernej>
"dap info" always crashes for me, but "h616.dap info" (or whatever you call dap interface) only showed useful info on a523. On H616 it was empty.
<jernej>
tell me if you have luck with other SoCs
<paulk>
maybe you had a mem-ap as target when it crashes
<paulk>
normally it should use the current dap target
<jernej>
good point
<paulk>
I didn't know much about jtag/adi/coresight but it's a really nice architecture actually
<paulk>
with an internal debug apb bus for register control of the debug components
<paulk>
then the trace part looks to be the most complex
<paulk>
with the ATB interface that has plenty of elements in the topology
<paulk>
just to stream trace entries, timestamp them, store them
<paulk>
openocd already has some tracing support for older ARM generations
<paulk>
where it was just a single ETM module that was added
<paulk>
with little to no buffering
<paulk>
jernej: nothing from the rom on h616 for me as well
<paulk>
ahh got
<paulk>
ahh got it, there are two things: it's using soc-400 (not soc-600) so it's adiv5 and the first ap is mem-ap
<jernej>
paulk: those addresses are in h6 dram space. does that mean they are accessible only on ap 0x1 with different memory decoder?
<paulk>
oh but it's not the same address space
<paulk>
I was about to say your sun55i config also uses the main memory access for the registers
<paulk>
so there is a separate APB bus with its own address space
<paulk>
which is usually ap 0
evgeny_boger has quit [Ping timeout: 480 seconds]
<paulk>
and the base addresses reported from the roms are relative to that
<paulk>
so instead of using the ahb/apb mem-ap to access the registers (which are mapped there for cpu convenience), openocd should instead use the debug apb interface
<paulk>
but since the registers are the same it also works to use the main memory via system ahb/apb
<jernej>
I think so too, but I get slightly different behaviour with a523. Only on one ap it detected more than 1 watchpoint
<paulk>
ah interesting
radxanaoki has joined #linux-sunxi
<paulk>
jernej: same thing works on h616
apritzel has joined #linux-sunxi
apritzel has quit []
apritzel has joined #linux-sunxi
<jernej>
oh, nice
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<paulk>
I get 6 bp / 4 wp on h6/h16
<paulk>
jernej: you're right 0x1000 is the ap to use for sun55i
<paulk>
it's actually not the system apb
<paulk>
it's really the debug apb
<paulk>
and for some reason the rom is also on ap 0
<paulk>
but it doesn't work to access the coresight components
<paulk>
0x2000 is a mem-ap to the system ahb
<paulk>
like h6 and h616's ap 0
<paulk>
so sun55i is really the first allwinner chip that has a "modern" design with dynamiq and soc-600
<jernej>
yes, it seems so
IlikeTech has quit [Quit: Bye!]
vagrantc has quit [Ping timeout: 480 seconds]
IlikeTech has joined #linux-sunxi
ftg has joined #linux-sunxi
vagrantc has joined #linux-sunxi
ftg^ has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
<paulk>
for a80 there seems to be two separate JTAG interfaces, one for A7 and one for A15