07:51 <Haohmaru> oh, so while a "daplink" could "work" with any cortex-M, the stlink(2?) clones don't work with some? or did i misunderstand

08:06 <PaulFertser> I think daplink firmware also needs explicit support for adiv6

08:18 <Haohmaru> oh

08:21 <Haohmaru> >:/ so if i buy one of the "newer" kinds of cortex-M, it is possible that my daplink won't work with them? bluh

08:22 <Haohmaru> i wonder if this affects cortex-M85 too, that one's "new-ish"

08:50 <PaulFertser> Why do not you flash daplink with better daplink firmware in that case?

09:52 <karlp1> stlink-dap is also specific to some versions of stlink firmware isn' tit? it's probably not supported by clones anyway.

10:07 <Haohmaru> yes, as long as such a firmware exists

10:08 <Haohmaru> and most of the daplinks i've seen typically give you a prebuilt firmware and that's all

10:09 <Haohmaru> so if you wanna build your own, you're kinda left to figure it out

10:11 <Haohmaru> i know my kamami daplinks use the very small NXP chip.. what was it.. LPC11U35 or something like that, and i know they include the optional virtual-com-port, but then i think there are a few more possible options that might need to be matched (and figured out) if you wanna rebuild this firmware from source

10:42 <PaulFertser> Haohmaru: come on, the reference daplink implementation is free software

10:43 <Haohmaru> it doesn't matter until i become affected

10:45 <Haohmaru> PaulFertser, IMO, kamami (and the others who make and sell daplinks) could've said "take the source code from <here>, change <these_things> and rebuild it"

10:45 <Haohmaru> but maybe i'm too pretentious

10:46 <Haohmaru> for me, dealing with a new MCU is already gonna be a huge puzzle, i don't want to deal with yet another puzzle around the debugger

10:47 <Haohmaru> also if the PCB with the new MCU is designed by me, if "sh*t don't wurkz" is it because of my board, my soldering, my schematic, my connections, my firmware, or the debugger, or something else <- the fewer possibilities here - the better

10:49 <Haohmaru> afaiu Cortex-M4 and M7 should be "the same" regarding the debugger, right? if my daplink works with M4F, it should also work with M7F

10:49 <Haohmaru> so if that's correct then i'll be okay

10:59 <Haohmaru> btw, i haven't assembled the new revision of my samd21_daplink yet, bluh

10:59 <Haohmaru> oh, also, i think the NXP chip is one of the very very small ones in terms of flash and RAM, which isn't great if a lot of new important features come to "daplink" afterwards

11:23 <sys64738> as of 0.11.0, openocd seems to have configuration files for the ATSAML10 and ATSAML11. however, trying to connect to it results in a "Error: Failed to read memory at 0xe000ed00";"Warn : target saml1x.cpu examination failed" error. does this mean there's no actual support for it, or only using the builtin debugger thingy on the xplained devboards (as opposed to me using an FT4232 here)? what's the

11:23 <sys64738> status exactly?

11:31 <Haohmaru> wait, are you having the SAML11 on a devboard that already includes a built-in debugger, and yet you're attaching another debugger to it?

11:33 <sys64738> no, I have the chip on a https://rtfm.newae.com/Targets/UFO%20Targets/CW308T-ATSAML11/ board connected to the chipwhisperer hardware (which is a thing meant for side channel and fault injection research)

11:33 <sys64738> the chipwhisperer itself can act as an FTDI device, but the devs call it "a bit of a hack" so I checked again with my FT4232 and it has the same result, so it's not the chipwhisperer havving a buggy FTDI/MPSSE impl.

11:34 <sys64738> anyway, I want to connect to that chip using openocd so I can flash some test firmware on it (on which I can then do SCA/FI stuff)

11:35 <Haohmaru> so this blue board.. i guess it is powered independantly from the debugger, what voltage does the SAML11 run on?

11:35 <sys64738> 3.3V

11:35 <sys64738> (IO, that is. 1.2V core)

11:36 <Haohmaru> and the debugger is 3.3V hopefully or has level shifters

11:36 <sys64738> it's 3.3V yes

11:36 <Haohmaru> are your connections to the debugger proper?

11:38 <sys64738> *sigh* yes, the chipwhisperer people also asked me this already. also, it's able to read the DPIDR right before throwing the "can't read from 0xe000ed00" error, so that's not hte issue

11:38 <Haohmaru> so some of the SWD procedures that openocd does "work", but others don't?

11:39 <Haohmaru> the other thing i can think of is that you could try a different openocd version, iirc 0.12.0 is a thing, i have it on debian stable even

11:39 <sys64738> I've tried 0.11.0, 0.12.0, and whatever the latest git commit was last friday

11:39 <Haohmaru> hm

11:40 <Haohmaru> the other thing i can think of is speed.. could the SWD happen to be too fast or something

11:40 <sys64738> the thing is, when reading the SAML11 datasheet, it seems like some magic MMIO pokes from the debugger are needed to put the "device service unit" in a state where the debugger can actually access the full system

11:40 <Haohmaru> MMIO?

11:41 <Haohmaru> ah, you mean special registers

11:41 <sys64738> yeah

11:41 <sys64738> and I've tried all this at 50 kHz, same result

11:41 <Haohmaru> lemme see, i would've thought the SAML wouldn't be too different than the SAMD2x

11:42 <sys64738> SAML2x probably is very similar, SAML1x is a bit different due to trustzone and stuff, necessitationg secure boot and other bullshit

11:43 <sys64738> I can also see SAML2x flashing procedures etc. in the openocd source, but not SAML1x. idk if they're shared between the two (and badly named), or if it's just the case that someone added the tcl scripts for the saml1x without *actually* adding support

11:44 <Haohmaru> wat the actual fuq have microsh*t done to the SAM product pages again, f*cking microsh*t

11:44 <Haohmaru> everywhere they wanna click-bait me into PIC32

11:44 <Haohmaru> i can't get to the f*cking datasheet

11:45 <sys64738> https://ww1.microchip.com/downloads/en/DeviceDoc/SAM-L10L11-Family-DataSheet-DS60001513F.pdf

11:46 <Haohmaru> oh wait, it's Cortex-M23

11:47 <sys64738> yeah

11:48 <Haohmaru> so i see some "DAL0" and "DAL2" thing on one hand

11:48 <Haohmaru> DebugAccessLevel2 is said to allow "highest debug features"

11:49 <Haohmaru> i see some fishy "CPU Park mode"

11:51 <sys64738> yeah, there are some "DCC0" and "DCC1" MMIO regs that have to be written to in order to put the CPU in said "park mode"

11:51 <sys64738> which is what I meant by "magic MMIO writes"

11:52 <Haohmaru> no clue then

11:52 <Haohmaru> i wonder if maybe the openocd support for SAML11 is not quite complete

11:53 <Haohmaru> because there is something like that for example for SAME5x and SAMD2x iirc

11:53 <sys64738> feels like it at least

11:53 <Haohmaru> there are a few features which can lock the chip and openocd doesn't have a way to unlock them, since it involves a particular "procedure"

11:56 <sys64738> those shouldn't be active (I hope), as it should be a 100% blank chip

11:56 <sys64738> (fwiw, I also do have a 100% blank chip straight from Farnell on a simple breakout PCB here, same result)

11:57 <Haohmaru> yeah, and there some "Boot ROM" thing that additionally gets involved in this

11:58 <sys64738> yeah, and dumping said bootrom (which normally isn't possible) is one of the reasons why I have this chipwhisperer glitching setup in the first place

11:59 <Haohmaru> you wanna h4x0r it? ;P~

12:04 <sys64738> more or less yeah

12:05 <sys64738> mainly because it apparently has a hardware AES impl, but the datasheet only tells you to use ROM routines to use it

12:05 <sys64738> which is Fishy

12:05 <sys64738> (other people have already attacked the trustzone part anyway)

12:12 <Haohmaru> huh

12:13 <Haohmaru> well, i'm out of clues, you could wait for the wiser folks to say if they got any clues

12:13 <Haohmaru> as for the samd5x and samd2x issue iirc i even tried to figure out what has to be done and modified openocd, but still couldn't manage to get it working

12:14 <Haohmaru> one of the issues was about when you enable CodeProtection

12:15 <Haohmaru> to remove it - you have to erase the chip, but iirc you no longer can do that with openocd

12:17 <Haohmaru> i think some older version of openocd had a patch that can do it but the patch wasn't ever accepted

12:39 <karlp1> sounds like it needs similar to the ti icepick stuff to enable dap access.

12:42 <karlp1> zapb__: you added saml1x originally, ring any bells?

12:53 <Poppy> Hello all, i'm working on ultra96v2 board (from avnet) based on Zynqmp. After modifying configuration I wad able to run openocd but I have some trouble to load the bootloader... If someone has already work on zynqmp any help will be appreciate. traces/logs --> https://pastebin.com/qDSaxwbL In any case, thanks for the work!

15:40 <zapb__> karlp1, not that I'm aware of?

15:42 <Haohmaru> unless it was tested on a chip from the same family, but one which doesn't have the TrustZone crap?

15:42 <Haohmaru> and/or ROM bootloader or whatever else makes this complicated

15:57 <karlp1> aren't you marc schink?? my apologies, I thought you were.

15:57 <karlp1> must hav emixed you up somewhere.

17:27 <zapb__> karlp1, I'm but I cannot remember that I worked on SAML1x :D

18:06 <antto> "selective amnesia" ;P~