NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
wingsorc__ has quit [Remote host closed the connection]
vfazio has quit [Remote host closed the connection]
vfazio has joined #openocd
wingsorc__ has joined #openocd
Hawk777 has left #openocd [#openocd]
Hawk777 has joined #openocd
crabbedhaloablut has joined #openocd
zkrx has quit [Ping timeout: 246 seconds]
zkrx has joined #openocd
nerozero has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Haohmaru has joined #openocd
Jybz[m] has joined #openocd
shoragan[m] has joined #openocd
LinuxHackerman has joined #openocd
chrysn[m] has joined #openocd
damex has quit [Ping timeout: 240 seconds]
damex has joined #openocd
zkrx has quit [Ping timeout: 245 seconds]
PaulFertser has quit [Ping timeout: 246 seconds]
PaulFertser has joined #openocd
marekvrbka has joined #openocd
zkrx has joined #openocd
merethan has joined #openocd
Foxyloxy has joined #openocd
marekvrbka has quit [Quit: Leaving]
zkrx has quit [Ping timeout: 245 seconds]
zkrx has joined #openocd
Haohmaru has quit [Ping timeout: 246 seconds]
wachag has joined #openocd
nerozero has quit [Ping timeout: 246 seconds]
wachag has quit [Client Quit]
wachag has joined #openocd
<wachag> Hello,
<PaulFertser> Hi
<wachag> I have a short question. On cortexr4 or aarch64 target when one uses write_memory, are caches handled?
<wachag> I would think cache should not make a mess and memory write goes straight into physical memory, but I am not yet sure and see strange things
<PaulFertser> They should be automatically handled I think.
<wachag> Thank you! I am not yet familiar with this part
<PaulFertser> wachag: there might be bugs lurking, and it's recommended you use current git HEAD.
<wachag> I always use that
<wachag> Exactly for that reason
<PaulFertser> Feel free to discuss on the dev mailing list if you're able to isolate any strange behaviour.
<wachag> I've checked aarch64.c, haven't seen any mention of cache
<wachag> Ok, thanks
<wachag> As far as I understand it just executes some memory load instructions and sends the data back via DCC, am I right?
<PaulFertser> wachag: if you're not going through AHB direct memory access then the CPU should handle cache coherency for you I'd guess.
<wachag> AHB direct memory access - how would you do that?
<PaulFertser> wachag: with the mem-ap target.
<wachag> Hmm, mem-ap is strange with my system
<PaulFertser> mem_ap
<wachag> Don't seem to read back valid data
<PaulFertser> It's not normally used for debugging, yes.
<wachag> Will check it. Currently I am using a cpu target, which most probably has cache coherency uses
<wachag> Issues, not uses
<wachag> I have a mem_ap, just read_memory doesn't seem to get valid data back
<wachag> Or I am holding it wrong
wachag has quit [Quit: Client closed]
wachag has joined #openocd
<PaulFertser> cpu target should handle caches properly automatically.
<wachag> Thank you!
<wachag> If I use mem_ap, am I doing it right (0x80000000 is backed by physical memory)
<wachag> soc.r5mem0 write_memory 0x80000000 32 0xbabe1 phys
<wachag> soc.r5mem0 read_memory 0x80000000 32 1 phys
<wachag> 0x80003
<wachag> 0x80003 which I read back. I always get a variation of 0x?0003
<wachag> So I think I don't use the mem_ap correctly
<PaulFertser> Do you get the same result with mdw/mww ?
<wachag> Yes
<PaulFertser> Also, what AP do you connect this mem_ap to? Have you checked "dap info 0" etc?
<wachag> Yes
<PaulFertser> And on memory bus probably the memory is mapped from 0, not with the offset you have in CPU memory map, I'm not sure.
<wachag> Tried that too
<PaulFertser> So are you connecting mem_ap to the AHB AP?
<wachag> But!
<wachag> The values I read via mem_ap are the values in the ROM table
<wachag> This is how I create the target:
<wachag> target create soc.r5mem0 mem_ap -dap soc.r5dap -ap-num 0
<PaulFertser> But what's on AP 0, is it AHB?
<wachag> > dap info 0
<wachag> AP # 0x0
<wachag>                 AP ID register 0x24770002
<wachag>                 Type is MEM-AP APB2 or APB3
<wachag> MEM-AP BASE 0x80000000
<wachag>                 ROM table in legacy format
<wachag>                 Component base address 0x80000000
<wachag>                 Peripheral ID 0x0701080203
<wachag>                 Designer is 0x380, <invalid>
<wachag>                 Part is 0x203, Unrecognized
<wachag>                 Component class is 0x1, ROM table
<wachag>                 MEMTYPE system memory not present: dedicated debug bus
<wachag>         ROMTABLE[0x0] = 0x00080003
<wachag>                 Component base address 0x80080000
<wachag>                 Peripheral ID 0x04000bb4b5
<wachag>                 Designer is 0x23b, ARM Ltd
<wachag>                 Part is 0x4b5, Cortex-R5 ROM (ROM Table)
<wachag>                 Component class is 0x1, ROM table
<PaulFertser> wachag: please never paste to public IRC channel, use some pastebin.
<PaulFertser> wachag: what's on AP 1 and the others?
<wachag> Nothing
<wachag> Only have ap 1
<PaulFertser> wachag: but why would you be trying to write to the ROM table location?
<wachag> I don't want to
<wachag> I want to access the system memory
<wachag> RAM
<wachag> It is very possible I am confused about what is mem_ap for
merethan has quit [Quit: Leaving]
<PaulFertser> wachag: so where is system memory mapped to on your target?
<wachag> 0x80000000
<PaulFertser> I guess you need to wait for somebody who understands more than me here.
<wachag> Ok, thanks
<wachag> I will try to contact the manufacturer too
<wachag> As far as I understand, mem_ap can connect to many different things
<wachag> Not necessarily to the system bus
wachag has quit [Quit: Client closed]
wachag has joined #openocd
wachag has quit [Ping timeout: 246 seconds]
cambria6 has joined #openocd
cambria6 is now known as ordovician_invad
ordovician_invad is now known as silurian_invader
Foxyloxy_ has joined #openocd
Foxyloxy has quit [Ping timeout: 245 seconds]
crabbedhaloablut has quit []
flatmush has quit [Ping timeout: 250 seconds]
flatmush_ has joined #openocd