05:00 <indy> new gerrit server isn't not in sync with old one?

05:02 <indy> or review.openocd.org is not yet fully up?

05:47 <PaulFertser> indy: please clarify

05:47 <PaulFertser> indy: should be fully up and running

05:47 <PaulFertser> And having all the data.

05:58 <PaulFertser> For the whole week already.

07:21 <Fleck> Hey PaulFertser, does Tarek wants me to build his review from source and try out? https://review.openocd.org/c/openocd/+/6506

07:26 <Guest7132> Hello all. I'm trying openocd on Microchip SAME54 XPLAINED PRO devboard. The problem is that when I secure the chip (e.g. from inside or from Microchip Studio), I cannot issue atsame5 chip-erase command. openocd requires "init" before it, and init says: "Error connecting DP: cannot read IDR". Is this command supposed to work? Unsecured chip is

07:26 <Guest7132> erased just fine.

07:37 <Haohmaru> i use SAME54 on a custom board, no microsh*t tools tho, and i haven't used these "security" options

07:38 <Haohmaru> flashing/debugging worked fine with gdb-multiarch/openocd/code::blocks

07:38 <Haohmaru> i assume you mean some of the "code protection" fuses/features?

07:41 <Guest7132> according to datasheet there is such a thing as "Security bit" which blocks debugger access, it can be set from the firmware for example with the following code:

07:41 <Guest7132> hri_nvmctrl_write_CTRLB_reg(FLASH_0.dev.hw, NVMCTRL_CTRLB_CMD_SSB | NVMCTRL_CTRLB_CMDEX_KEY);

07:41 <Haohmaru> ah, that thing

07:43 <Guest7132> to unlock the access (erasing all the flash on the way) one needs to execute certain sequence on SWD interface. I'm trying to figure out is openocd capable of doing this.

07:44 <Haohmaru> "The only way to clear the security bit is through a debugger Chip Erase command. The NVM security bit is cleared after all internal volatile and NVM have been cleared. The device protection status is updated at the end of the command meaning that no reset is necessary"

07:53 <PaulFertser> Fleck: not sure, I think there's no need.

07:54 <Fleck> ok, thanks! :)

07:55 <Haohmaru> https://sourceforge.net/p/openocd/code/ci/master/tree/src/flash/nor/atsame5.c line 765.. "secured chip" is mentioned below..

07:56 <Haohmaru> Guest7132 what kind of error messages are you getting if you just try to "erase the chip" ?

07:57 <Haohmaru> and, perhaps if you can try, does this scenario work via microsh*t's tools (erasing the secured chip)?

07:58 <Guest7132> I'm getting the error that this command requires "init" before it, but issuing "init" gives "Error connecting DP: cannot read IDR".

07:59 <Guest7132> Secured chip erase works with Microchip studio and with JLink utils from Segger (if I connect JLink to swd header).

08:00 <Haohmaru> okay, so then it *should* work

08:00 <Haohmaru> i can't seem to find such an error message within that file

08:00 <Guest7132> this is an error message from init command

08:02 <Guest7132> chip-erase is registered as COMMAND_EXEC at the end of this file, therefore openocd refuses to execute it without being inited first.

08:05 <Haohmaru> not sure what the meaning of that is

08:05 <Haohmaru> perhaps wait till the others wake up

08:07 <Guest7132> I tried to change it to COMMAND_ANY and issue it without init and then I got another error something like it is not initialized.

08:08 <PaulFertser> Guest7132: probably you can connect when reset is pulled low?

08:08 <Haohmaru> it's possible that the same5x implementation in openocd doesn't have anything for this specific scenario (yet)

08:08 <Haohmaru> PaulFertser by who?

08:09 <PaulFertser> Haohmaru: doesn't matter

08:09 <Haohmaru> i'd think only the debugger should control the reset

08:10 <Haohmaru> or do you mean, instructing the debugger (via openocd) to pull the reset low..?

08:10 <PaulFertser> Reset is normally open drain controlled, so it can be multiple sources, including the debug adapter.

08:11 <Haohmaru> hm, open drain, meaning everybody only ever drive low but no high?

08:12 <Haohmaru> i've had the impression (out of.. nowhere specifically) that some tools may drive the reset signal high as well as low

08:14 <Haohmaru> so i've always tried to be careful with what other stuff i put on the reset, to not fry the programmer/debugger

08:14 <Haohmaru> or maybe that's not done on arm?

08:14 <Haohmaru> iirc dumb PICs had high-ish voltages on the RESET pin

08:29 <Guest7132> PaulFertser, if i pull reset low during starting openocd erase script security bit is cleared just fine.

08:29 <Haohmaru> meaning.. it works?

08:34 <PaulFertser> Guest7132: so you can try "reset_config srst_only connect_assert_srst" to ask OpenOCD to do that.

08:34 <Haohmaru> kewl

08:42 <Guest7132> Yep, this way it works. Thanks.

09:00 <olerem> borneoa_: hi, ho do we proceed with the vdebug driver? it is reworked and not so bad as the first version. Do you see any reason to block it?

09:04 <PaulFertser> indy: ping

09:05 <borneoa_> olerem: I had no time to check its evolution. Wish I can have a look in this week. By the way, thanks for tracking it and for this ping

09:08 <indy> PaulFertser, pong

09:08 <indy> PaulFertser, i can't login with ssh key

09:09 <indy> like i can with old one

09:09 <olerem> borneoa_: i would split it to driver and configs. The most importand part the user configuration interface seems to be ok. I'm not really motivated to spend a lot of time on it

09:10 <indy> PaulFertser, and i can't login to webui with my linked accounts (github)

09:26 <PaulFertser> indy: hm, you're the first to complain. Let's start checking. I'll take a look at the logs first.

09:29 <PaulFertser> indy: can't see anything yet. I see you have plenty of methods to log in: several openid including launchpad.

09:29 <PaulFertser> indy: please try logging in now.

09:29 <PaulFertser> indy: regarding the ssh key, I can check it separately.

09:30 <indy> PaulFertser, oops, i'm in :)

09:32 <indy> PaulFertser, ssh access problem still valid

09:35 <indy> PaulFertser, ssh working - forgot to update .ssh/config :)

09:36 <PaulFertser> indy: cool :) I know there's a problem with old ciphers, Fedora disabled them so either use ed25519 or enable back the deprecated ciphers.

09:52 <PaulFertser> indy: any feedback on the new system is welcome

16:38 <borneoa_> PaulFertser: tested the new improvement in gerrit. Looks great. Thanks

16:54 <PaulFertser> borneoa_: so happy to help you :)

21:25 <marex> Hi, I tried to use OpenOCD to recover my arm64 board recently, but it seems I cannot do it unless I can access SCTLR register to disable cache

21:25 <marex> I then realized that I submitted a patch half a year ago implementing that functionality ... which has not even been reviewed so far

23:08 <borneoa_> marex: went lost... Too many new changes in gerrit recently.

23:13 <borneoa_> PaulFertser: the merge conflicts list looks incorrect. E.g. change 6508 just fixes a typo in a single comment line. gerrit reports 13 conflicts, but at least the top 3 do not change that line. Can you share again the modification at JS?