14:15 <karlp> anyone got any advice on what might be wrong here? https://paste.jvnv.net/view/b3k4r

14:15 <karlp> it's an m33 according to realtek, not an m55, but it's also labeled a "REAL300" or something, so it might have a vendor difference, and we're not checking enough of the right bits for overlaps or something?

15:27 <josuah> CORTEX_M55_PARTNO = 0xD22,

15:27 <josuah> that looks like being the cause... wrong partno detected/read?

15:27 <josuah> CORTEX_M33_PARTNO = 0xD21,

15:28 <josuah> it is a 2-bit error, could be a bit of delay for that last bit though if doing that every time that might not be the reason... also, not sure about how it's really encoded and CRC'ed on the wire

15:30 <josuah> in cortex_m.c:

15:30 <josuah> 2535 /* Get ARCH and CPU types */

15:30 <josuah> 2536 const enum cortex_m_partno core_partno = (cpuid & ARM_CPUID_PARTNO_MASK) >> ARM_CPUID_PARTNO_POS;

15:30 <josuah> And in the logs:

15:30 <josuah> Warn : [rtl8720dn.cpu.km4] karl: raw cpuid = 721fd220, core partno: d22

15:31 <josuah> so it looks like it matches?

15:31 <josuah> a bitmask field of the wrong size would not bring this I guess?

15:32 <josuah> 0xd22 = 0b 00001101 00100010

15:32 <josuah> 0xd21 = 0b 00001101 00100001

15:33 <josuah> Or did they get the partno wrong in silicon (purposedly or not) and hid it under their own software toolchains?

15:40 <Haohmaru> are there checksums of some kind in the SWD communication?

19:03 <karlp> 6ok, so this is easy, the implementer field is not "ARM" so that's why it's off :)

19:04 <karlp> openocd doesn't even ook at the implementer field :)

20:16 <borneoa___> karlp: interesting. We just got https://review.openocd.org/7812 that adds NXP Cortex -M33. We should check for implementer field there too

20:44 <karlp> I was _just_ about to start looking at how to rework it...

20:45 <karlp> I'm 99.9% sure that the STAR_MC1 proably has a different implementor field too, will try and see if tehre's enough info in it frrom when it was submitted to find out the rest of it.

20:47 <borneoa___> karlp: yes, there is also STAR_MC1. Maybe the author of that line can give us the full content of CPUID register

20:50 <karlp> when I switch targets like this, shoudln't I then be reading the memory of te other part? https://paste.jvnv.net/view/hJuCk ?

20:51 <karlp> ah, you've already commented on that issue.

21:00 <karlp> I've replied to Yang Sheng on the star_mc1 issue, hopefully they reply

21:07 <borneoa___> karlp: if I remember correctly, in a gdb connection there is some limited support to change target. Use "monitor target_name mdw address"

21:27 <karlp> meh, f1x flash code uses cortex part number as a heuristic to guess what actual part it is,

21:28 <karlp> that's.. not really correct,

21:50 <karlp> I'm getting https://paste.jvnv.net/view/QSw9a trying to do a "git push review"

21:50 <karlp> I've just updated my commit hook though, perhaps it doesn't take affect afterwards?

22:02 <PaulFertser> karlp: try pushing to refs/for/master instead

22:11 <karlp> doh, I went over and checked that, from my old config, and misred that it was wrong there

22:11 <karlp> now it'ðs missing changeids...

22:12 <karlp> ffs, two hooks dirs again

22:12 <PaulFertser> git commit --amend will add that

22:13 <PaulFertser> Just one hook is enough

22:13 <karlp> no, it was in the .git/hooks not git-hooks

22:13 <karlp> so it wasn't actually running.

22:13 <karlp> nearly there :)

22:16 <karlp> https://review.openocd.org/c/openocd/+/7845 has the implementor bit at least, but we would need the star-mc1 cpuid to prevent regressions there,