04:24 <MCorgano> IS it possible to have both serial console and OpenOCD SWD debuggers running on the same pi?

04:25 <MCorgano> EX say I want to use the same pi to flash the chip and read the console, and be able to access both over telnet from my pc

04:25 <MCorgano> has anyone did that yet?

05:32 <PaulFertser> MCorgano: yes, should be possible

05:32 <PaulFertser> MCorgano: using raspberrypi UART doesn't depend on OpenOCD running or not.

05:32 <PaulFertser> Forwarding it over network is possible with socat.

06:17 <MCorgano> I realize, I can already ssh into the pi

06:17 <MCorgano> what command would I use to pull up a serial console on the pi, to talk from pi <-> to device?

06:28 <PaulFertser> MCorgano: first you need to configure the UART to not use it as a kernel console. raspi-config has the options to enable UART but not to enable the console on it. Then I recommend running picocom.

07:26 <indy> hi all, any patches for libgpiod v2?

07:31 <PaulFertser> indy: hi! I'm afraid nothing since https://review.openocd.org/q/message:libgpiod isn't showing any.

07:35 <indy> PaulFertser, thanks :) i just noticed, that in rawhide openocd started to fail

07:35 <indy> to build or install old

09:08 <karlp> is libgpiodv2 available anywhere yet?

09:08 <karlp> this was such a python3 disaster of an upgrade.

09:10 <karlp> sysfs is dead, losers, you should all use chardev, we built libgpiod for you, because, yeah, no-one actualyl wants to work with the chardev either, but actually no, the chardev is busted, we didn't learn from any of the first 15 gpio implementations, so everything's deprecated now! but don't worry, the kernel has v2 and you can use it's chardev! just not both apis at once, no no...

09:12 <karlp> even within that we had incompatible v1.4 and v1.6.

09:39 <Haohmaru> what's this about?

09:39 <Haohmaru> otherwise my condolesence about the snek situation

09:39 <Haohmaru> f*cking snek everywhere

09:58 <PaulFertser> indy: is Peter Robinson co-maintainer for Fedora now?

10:02 <indy> PaulFertser, he is kind of super-maintainer in fedora :)

10:03 <PaulFertser> indy: please tell me if I did wrong by not pinging you when 0.12.0 final was tagged, I assumed you have the watch file automatically notifying you.

10:09 <indy> PaulFertser, i have, but fedora notification system is quite 'spamming' so i overlooked it as i'm busy with family stuff. irc is more reliable as i don't log in to gmail often

10:10 <PaulFertser> indy: I see. Thank you for caring, it's very nice to have up-to-date packages readily available for end users.

13:41 <Haohmaru> does openocd/gdb have to "touch" the RAM of the MCU when you merely flash an .elf to it?

13:43 <PaulFertser> Haohmaru: for fast flashing, yes. For some MCUs, yes.

13:43 <Haohmaru> huh

13:43 <Haohmaru> cortex-m4f in this case

13:45 <Haohmaru> is there anyway to influence it? i have a "special" chunk in the RAM which i intentionally want to keep dirty (uninitilized), and whenever i flash my bootloader on - that chunk of RAM appears modified

13:47 <Haohmaru> i flash it with that .sh script i stole some weeks ago.. it invokes openocd with "init" "targets" "reset halt" "flash write_image erase" "verify_image" "reset run" "shutdown"

13:50 <PaulFertser> Haohmaru: it depends not on the core but on the way flashing is implemented.

13:51 <Haohmaru> hm

13:51 <PaulFertser> Haohmaru: yes, you can relocate workarea in target config or make it 0 size.

13:52 <PaulFertser> Haohmaru: I can't understand why you're using some script and not "program" functioon.

13:52 <Haohmaru> it happens that my special chunk of RAM is in the beginning of the RAM, maybe that wasn't the greatest decision ever

13:52 <PaulFertser> Haohmaru: you can move workarea elsewhere, no problem.

13:52 <PaulFertser> Or you can make OpenOCD save and restore it.

13:53 <Haohmaru> PaulFertser no idea.. i wanted to have a "quick" way to flash an .elf because doing it from the IDE every time is kinda slow

13:54 <Haohmaru> for the IDE i have to first launch openocd anyway

13:54 <Haohmaru> for the .sh script i simply need to have a terminal open where i repeat the command (executing the script), so i just press UP+enter

13:55 <PaulFertser> Haohmaru: OpenOCD has built-in "program" function for flashing.

13:56 <Haohmaru> i don't remember why i did this but i surely asked here for a script and i think someone showed me an existing script from some project on the internet, i took it and adapted it

13:57 <Haohmaru> https://paste.debian.net/hidden/b2319979/

13:58 <PaulFertser> Up to you

13:58 <Haohmaru> it's NOT up to me, i have zero clue wtf's going on ;P~

13:59 <PaulFertser> There's the official User manual.

13:59 <Haohmaru> so you suggest i change "flash write_image erase ELF" with "program ELF" ?

13:59 <PaulFertser> And if you're into shell scripting, you can read "man bash".

13:59 <Haohmaru> i'm not

14:00 <Haohmaru> i just wanted a quick thing that can flash a firmware with least bullsh*t

14:00 <PaulFertser> -f interface/... -f target/... -c "program /path/to.elf verify reset exit"

14:00 <PaulFertser> That's it.

14:00 <Haohmaru> i certainly added the "adapter speed 4000" there btw

14:01 <Haohmaru> so you say i remove all the other crap and change it to this ^?

14:02 <PaulFertser> No, adapter speed shouldn't be needed with upstream configs.

14:02 <Haohmaru> hm?

14:02 <PaulFertser> Yes, target configs should have sane default value in them.

14:02 <Haohmaru> i think i set that because by default i get something like 1 or 2MHz with my debugger

14:03 <PaulFertser> Probably the reset-init handler changes it to a higher value if applicable.

14:03 <Haohmaru> and i'm a semi-impatient person ;P~

14:09 <Haohmaru> okay, it works, that RAM still gets touched tho

14:11 <karlp> yes, you will need to change workarea and/or workarea size.

14:11 <karlp> do you really need the ram preserved when you're reflashing?

14:12 <karlp> I use first sections of ram for bootloader/app comms, but you're reflashing, what's to communicate with

14:12 <karlp> setting work area size to 0 will be "quick" to implement, but very slow to flash.

14:12 <Haohmaru> well, my bootloader uses the data there to figure out what's going on

14:13 <karlp> ok, and what does it do on power on reset?

14:13 <Haohmaru> it clears it

14:13 <karlp> so...

14:13 <karlp> no problem?

14:14 <Haohmaru> i'm working on the bootloader and firmware still, so i just reflash the bootloader with the script

14:20 <Haohmaru> "-work-area-phys address" can this be passed like the other commands in my silly .sh script?

14:24 <Haohmaru> ..so i don't want to have to switch the power off/on all the time, on the other hand, i wanted to debug a POR situation and it wasn't possible because when my debugger is "active" - the chip voltage doesn't fall low enough and i get brown-out reset instead of POR

14:25 <Haohmaru> but i think i figured out the POR issues already

14:34 <Haohmaru> seems not

16:02 <Haohmaru> i think i got it working

16:05 <Haohmaru> behold: https://paste.debian.net/hidden/c269500d/

16:06 <PaulFertser> :D

16:06 <Haohmaru> what's so funny? ;P~

16:07 <PaulFertser> Why bash, why "sh -c", why the tricky variable assignment, why functions...

16:08 <Haohmaru> because i sprinkle scripts into different project folders, i have projects with SAM E5x/D5x and SAMD20 for now

16:08 <Haohmaru> so i wanted to have a dumb and simple script that is capable of programming a firmware onto a chip with least bullsh*t

16:09 <Haohmaru> so i could, for example, instruct a $collegue how to do it over the $phone

16:10 <Haohmaru> this seemed simpler than instructing folks how to open my IDE, load the project, additionally also launch openocd with a set of arguments i can't synthesize out of my head, and then press some funky buttons in the IDE

16:10 <Haohmaru> also that scenario requires openocd+IDE+gdb

16:12 <Haohmaru> as for the other things - i don't know, i don't schprachen ze .sh much, but i wanted all the "important" things i may want to modify in the script, to be at the top, instead of in the middle of that hairy-looking command

16:14 <Haohmaru> i tried without "sh -c" and it... didn't quite work

16:14 <PaulFertser> Haohmaru: I'm not talking about the idea to use a script for that. I'm talking about the implementation details that are kind of amusing me.

16:15 <Haohmaru> i stole it from $somewhere and modified it

16:15 <Haohmaru> i think it was intended as a post-build step in a Makefile for some $thing

16:16 <Haohmaru> btw, the debian wiki also suggest a similar set of commands for flashing a chip https://wiki.debian.org/OpenOCD

16:16 <Haohmaru> see at the very bottom

16:18 <PaulFertser> Haohmaru: yeah, it's quite outdated and has sudo, but at least no strange shell scripting "solutions" are present.

16:19 <PaulFertser> Ah, it's also using "halt" to prepare for flashing. Issues almost guaranteed.

16:19 <Haohmaru> *shrug*

16:20 <Haohmaru> any suggestions on how to debug POR issues?

16:20 <Haohmaru> i guess this heavily depends on how the debugger is made electrically around the SWD port.. and maybe also my target board

16:27 <PaulFertser> I really feel like I need to fix this wiki now...

16:30 <PaulFertser> Haohmaru: hm, I have an idea actually. Unpower the target and pull reset line low externally. Then power the target while still having it low. Start OpenOCD with -c "init; reset halt; wait_halt 10000", and release the reset line manually after seeing "timeout waiting for the target halted".

16:31 <Haohmaru> i guess i'll write that down for the future, but i can't try it now since the reset doesn't go anywhere else besides to the SWD port

22:33 <borneoa__> karlp: the maintainer of libgpiod is writing since few weeks that the release would probably be the following week. Anyway, it's arriving... If you have any suggestions on how to support it, you are welcome.

22:37 <borneoa__> Also capstone has tagged today 5.0-rc2 https://github.com/capstone-engine/capstone/tree/5.0-rc2