05:54 <olerem> lol, nowdays i'm busy to fix ancient drivers for old HW. Becouse the industry can get only old/depricated chips :D

05:55 <olerem> actually it is not so bad. finally we have resources to make better drivers instead of fighting against windmills

08:03 <bencoh> yeah it's actually better than racing to new-but-not-better hw every year just because it's hype-new

08:16 <jancoow> Hi. So, I didn't have trouble with many boards, but now I've two atsaml21e18b which won't be able to use "flash write_image erase unlock image.hex". I'm receiving this error: Error: SAMD: NVM programming error Error: Failed to erase row containing 0000f200 Error: SAMD: failed to erase sector 242 at 0x0000f200 Error: failed erasing sectors 64 to 848

08:16 <jancoow> When I remove the "erase" portion of the flash command, it works fine

08:16 <jancoow> I also ran a verify after it and that also confirmed it flashed correctly without the erase option

08:17 <jancoow> so.. I'm not sure if I should use that erase option. I'm doing a chip-erase at the start of the programming session anyways

12:39 <rkta> So, I can connect with my jlink to the RPi pico using 'openocd -f "interface/jlink.cfg" -c "transport select swd" -c "adapter speed 1000" -f "target/rp2040-core0.cfg". But I cannot connect with gdb. Here is the complete log when running with -d3: http://vs.rkta.de/files/rp2040_d3.log

16:07 <PaulFertser> rkta: probably the target is in some weird state during that.

16:14 <PaulFertser> rkta: are you sure this OpenOCD version is known to work with rp2040? Probably they have published some patches which are not upstream yet?

17:07 <rkta> PaulFertser: no, I don't know if this OpenOCD version (which is the current master) is known to work with rp2040. That's why I asked yesterday if someone managed to do this.

17:42 <borneoa_> rkta: if I remember correctly, rp2040 requires swd multidrop, that is already merged. But Tomas validated the patches against another pair of devices, not rp2040

18:03 <rkta> borneoa_: I read something about multidrop, I guess you remember correctly. I don't understand much (if any) about this topic, though. Can I provide more info or test something to help getting this working?

18:08 <borneoa_> rkta: there was an initial patch from RPi https://review.openocd.org/c/openocd/+/4935

18:09 <borneoa_> rkta: but was not ready for merge. Then Tomas made his own version, but testes on other devices

18:11 <borneoa_> rkta: rp2040 has 2 cortex-m on the same swd port but instead of using 2 access ports it uses 2 swd dap in multidrop configuration

18:12 <borneoa_> rkta: I reviewed the patches without testing them

18:13 <borneoa_> rkta: if you succeed to get it working for rp2040, please report it here

18:16 <rkta> borneoa_: I have no idea how to proceed. I see there is a openocd fork from RPi, I'll check this out. Maybe I get some helpful logs from this. I'll report back. I'd like to keep my workflow.

18:19 <borneoa_> rkta: maybe looking at the original patch from RPi. But it does not include the TCL script because at that time the rp2040 was still not disclosed

18:20 <borneoa_> rkta: but there is one script already upstream for rp2040....

18:21 <rkta> borneoa_: yes, ...core0.cfg, the RPi fork has a rp2040.cfg

18:23 <borneoa_> rkta: do they use the same code we have upstream or the old multidrop proposal?

18:24 <rkta> borneoa_: I don't know, haven't looked into it in detail, yet.

18:27 <borneoa_> rkta: the old patch https://github.com/raspberrypi/openocd/commit/dd9dbe8dc9d5fd7d510a102676e266bf857e5f53

18:28 <rkta> Ok, so they have it working, but failed to submit it in a form that would be accepted from upstream, right?

18:31 <borneoa_> rkta: yes

18:36 <rkta> I just read the comments on gerrit, it's a pity they didn't come back with a review since April 2021...

18:37 <rkta> That's not how open source is supposed to work

18:41 <PaulFertser> rkta: it should be easy for you to try their version

18:41 <PaulFertser> rkta: and compare the logs

18:46 <rkta> PaulFertser: will do and come back with the logs

18:47 <rkta> can I somehow 'subscribe' to the gerrit patch? I want to get an email if something happens.

18:52 <rkta> And yes, I have an account.

18:53 <PaulFertser> rkta: then yes, add yourself to Cc list.

18:53 <PaulFertser> rkta: but it's not like anything will happen on the original patch I think.

18:53 <rkta> PaulFertser: just in case, where is this cc list? that ui is confusing

18:55 <rkta> ah, it's behind show more

18:56 <PaulFertser> rkta: hm, current docs say dap_create should have -dp-id and -instance-id

18:56 <PaulFertser> rkta: and in your config they're lacking

18:57 <rkta> PaulFertser: that's the current master. I can try a clean install in case something is messed up.

18:57 <PaulFertser> rkta: oh, and I might have misguided you regarding jlink support, I'm not sure anymore, the docs say only "cmsis_dap (use an adapter with CMSIS-DAP version 2.0), ftdi, all bitbang based." support multidrop, but that should be fixable for jlink too.

18:57 <PaulFertser> rkta: no, it needs some digging, clean install can't help.

18:58 <PaulFertser> rkta: really sorry, I somehow have forgotten this rp2040 thing is multidrop.

18:59 <rkta> PaulFertser: np, I/we learned something atleast ;)

19:00 <rkta> To sum it up, with a different probe it might work, but not with a jlink.

19:00 <PaulFertser> rkta: I see no upstream configs have -dp-id specified yet.

19:00 <PaulFertser> rkta: no, it won't with this config.

19:02 <rkta> PaulFertser: Shouldn't be too hard, if it's only config. I could try the config from the RPi fork.

19:02 <PaulFertser> rkta: the config file you're using is for pico-debug. It's when one core of rp2040 runs special debug firmware, and another you debug. Without any additional debuggers.

19:02 <rkta> PaulFertser: ah, ok.

19:03 <PaulFertser> rkta: give that a try: https://github.com/majbthrd/pico-debug

19:04 <rkta> PaulFertser: will do, thanks. But I still would like to have it working without such things. :)

19:05 <PaulFertser> rkta: indeed, for that you should try creating a config using those multi-drop dp-id and instance-id parameters.

19:06 <PaulFertser> rkta: https://github.com/raspberrypi/openocd/blob/rp2040/tcl/target/rp2040.cfg give this a try

19:07 <rkta> PaulFertser: yep, that's the config I was talking about. I'll give it a try and report back with a -d3 log.

19:09 <PaulFertser> rkta: found something https://github.com/raspberrypi/openocd/issues/9

19:09 <PaulFertser> rkta: see, they have a jlink working branch.

19:12 <rkta> PaulFertser: nice, now I have something to do on the weekend. :)

19:14 <rkta> let's if it works and then poke them to send it upstream

21:36 <cambrian_invader> how do I use the hwthread rtos?

21:37 <cambrian_invader> I specified `-rtos hwthread` when creating my targets

21:37 <cambrian_invader> but I only see one thread in gdb

21:37 <karlp> are the other cores alive? does the target know about them?

21:37 <karlp> that's all you should need as i understand it, but i've never used it sorry.

21:38 <cambrian_invader> yes and yes

21:40 <cambrian_invader> here's my log https://paste.debian.net/1230600/

21:51 <cambrian_invader> ah, I had to use -coreid

21:52 <karlp> excellent

21:53 <cambrian_invader> this stuff should really be documented

21:53 <cambrian_invader> all the in-tree scripts use -rtos hawt still...

21:54 <karlp> that's a shame :(

21:54 <karlp> the hawt to hwthread naming was done during review, to try and pick a magic word that was a bit easier to find

21:54 <karlp> looks like the configs didnt get changed :(

21:55 <cambrian_invader> from what I can tell this was merged 5 years ago

21:55 <cambrian_invader> I guess people just don't update scripts

21:55 <karlp> that long ago already? that... feels like too long

21:55 <karlp> I think it's more that _very_ few people use it, and they never share their own configs because they're normally "doing somethign important"

21:56 <cambrian_invader> idk, seems pretty essential for debugging a multi-processor system

21:56 <cambrian_invader> the other thing I'm having trouble with is etm

21:57 <cambrian_invader> the command is just missing, even though the file is compiled in

21:57 <cambrian_invader> oh, and what happens if you want to debug an rtos on a multi-core system?

21:59 <karlp> I personally don't :) and I'm just another user, but my _feeling_ frrom the cortex-a level people that drive by, is that _nothing_ gets proposed back in any way shape or form. people hack enough shit locally to get their bootoader running or whatever, and then it's dropped, never heard from again, no further information...

22:00 <cambrian_invader> I personally had to use a vendor openocd fork for a particular processor and it was awful; had to re-launch openocd to change cores

22:00 <cambrian_invader> I looked at upstreaming things but it was an absolute mess to untangle

22:01 <karlp> and that seems to be what people leave it at... and so the next person comes along to the same ball of shit :)

22:01 <karlp> not blaming you at all, not in the least,

22:01 <karlp> but that seems to be the way things have been going

22:02 <karlp> perhaps I'm too pessimistic, there have been a couple of people doing more work on cortex-a stuff, but it still feels like a warzone.