04:37 <olerem> zear: hi, since you are still doing some rounds, not mips32_read_c0_prid() should call mips32_cpu_probe(). It should be other way around. mips32_cpu_probe() calls mips32_read_c0_prid()

06:48 <zear> olerem, since mips32_read_c0_prid() gets introduced in the patch preceding mips32_cpu_probe(), if I want to do it the other way around, should I squash both commits into one?

07:14 <zear> or should I retain the first patch as-is, and simply change the function that's being called from mips_m4k_debug_entry() to mips32_cpu_probe() in the second patch?

07:29 <olerem> zear: yes

07:30 <zear> yes for squashing both commits, or preserving the first commit as-is? ;-)

07:34 <olerem> zear: preserve first commit

07:34 <zear> ack

07:36 <zear> also, previously the whole mips32_read_c0_prid() -> mips32_cpu_probe() sequence would only get called once per debug session, because it would return early if ejtag_info->prid is already non-zero. Right now mips32_cpu_probe() will try to identify the CPU every time the probe enters debug mode. Should I also prevent it from being called more than once per session?

07:41 <olerem> zear: yes, it would make sense to read it only once per session

07:52 <zear> olerem, PaulFertser, new version of the patchset: https://pastebin.com/raw/YNhYrEp0

08:00 <olerem> zear: it would read prid reg only once, but running cpu_probe every time we enter debug mode?

08:04 <zear> it returns from cpu_probe early if prid reg was already read once

08:04 <zear> I assume that the cpu won't change during debug session :)

08:07 <olerem> zear: but i requested to make mips32_cpu_probe() call mips32_read_c0_prid(), not other way around. Jist imagine a function called readl() wich runs cpu_probe()

08:08 <zear> And mips32_cpu_probe() calls mips32_read_c0_prid().

08:09 <zear> but it only calls mips32_read_c0_prid() when prid isn't known yet. Is that what you don't agree with?

08:10 <olerem> do i really look to a cirrect pastebin?

08:10 <zear> you should be looking at https://pastebin.com/raw/YNhYrEp0

08:11 <zear> keep in mind this is two patches catted together

08:11 <zear> maybe you're looking only at the first patch

08:11 <olerem> ugr... patebin patch managment is much vorse then using gerrit

08:12 <zear> you can wget this patch and then `git am pastebin_dump`

08:12 <zear> it will apply it as two separate patches nicely

08:12 <olerem> zear: why do you make us more work then just configure gerrit one time and use git push instead?

08:12 <zear> like I said, I don't want to register

08:13 <zear> I don't need to explain myself further there

08:15 <olerem> mips32_read_c0_prid() do not need to prevent if is set ejtag_info->prid. It is enough if cpu_probe will check it

08:16 <zear> yes, that's why that check is removed in the 2nd patch

08:16 <zear> but I guess I should remove it from the first patch as well

08:40 <zear> actually, I think it's fine the way it is - if someone cherry picks the first patch only, we still want to prevent mips32_read_c0_prid() from running every time probe enters debug mode

08:43 <olerem> PaulFertser: can you plase take this latest patch version

08:43 <olerem> zear: https://pastebin.com/raw/YNhYrEp0 rigth?

08:43 <zear> I think PaulFertser needs to push it to gerrit, so the patchset can be read better. The diff strategy went for mixing the code of both functions together, it's hard to read.

08:44 <zear> olerem, correct

08:44 <zear> thanks for your time

08:44 <zear> I'm off to work, ttyl

08:47 <PaulFertser> Pushed

09:44 <olerem> zear: if i see it correctly, in current patch version you are calling mips32_cpu_probe()->mips32_read_c0_prid()->mips32_cpu_probe(). even if last mips32_cpu_probe() call will not trigger recursive execution, it is better to fix it

17:16 <Hiemer> hi

19:23 <zear> olerem, huh, indeed. Somehow I completely missed that. Nice catch!

19:24 <zear> I see you've already fixed that on gerrit - thanks

20:29 <silurian_invader> what's the right way to work around a tap which doesn't put idcode into the ir after reset?

20:30 <silurian_invader> I can shift in the idcode instruction manually and read out the correct id

20:30 <silurian_invader> but openocd complains that the scan chain is all 0s

20:33 <PaulFertser> silurian_invader: it complains but it proceeds anyway

20:33 <silurian_invader> yeah, but I see e.g "Bypassing JTAG setup events due to errors"

20:34 <PaulFertser> silurian_invader: probably harmless in your case?

20:34 <silurian_invader> ok; wasn't sure whether I needed to do anything about that

20:34 <PaulFertser> What device is that btw?

20:35 <silurian_invader> pxa16x

20:35 <PaulFertser> Old stuff

20:35 <silurian_invader> yeah

20:35 <silurian_invader> customer did a lifetime buy for the processor but not the supporting chips...

20:35 <PaulFertser> Was cool back then

20:36 <silurian_invader> definitely a very capable chip

20:36 <silurian_invader> lotsa errata too :)

20:36 <PaulFertser> If you really see any issues with that bypassing, let's discuss. But probably nothing to worry about, and you can rerun manually whatever is needed.

20:37 <PaulFertser> Hopefully most of the errata issues have good workaround in today's tools.