13:00 <Mis012[m]> so, I tried -ap-num 1 based on this:

13:00 <Mis012[m]> and now I get the following:

13:01 <Mis012[m]> with the following if I try to connect from gdb:

13:02 <PaulFertser> Mis012[m]: I'd instead just defined the dap and would do "dap info 0", "dap info 1" etc.

13:02 <PaulFertser> You can't connect to a target that's not examined.

13:02 <Mis012[m]> PaulFertser: well, iirc if I didn't define the target it just complained that it needs a target

13:09 <Mis012[m]> PaulFertser: this sounds like it really wants a target

13:09 <PaulFertser> Mis012[m]: that's what I said, yes.

13:09 <PaulFertser> Mis012[m]: GDB needs a target

13:10 <Mis012[m]> well, it's not printing the dap info either

16:04 <IoT-Maker> i asked last week for help with my TI am3352 chip and thought i solved the problem because openocd now show me  "1* am335x.cpu         cortex_a   little am335x.tap         running" but i still have problems. I now try a TIAO tumpa interface with default config for tumpa.cfg and am335x.cfg. This is the openocd server output and

16:04 <IoT-Maker> the output of the telnet session: https://pastebin.ubuntu.com/p/BB2sRtsZJq/ The target board has a Compact TI JTAG connector which has EMU0 and EMU1 pin. The EMU0 and EMU1 pin are unconnected.  Here's another log with EMU0 and EMU1 connected to GND https://pastebin.ubuntu.com/p/DvwGdMjhN3/

16:08 <IoT-Maker> it ask  how to reset: JTAG-DP STICKY ERROR, Could not initialize the APB-AP, am335x.cpu: how to reset? and the log show up Error: 319 18762 adi_v5_jtag.c:657 jtagdp_transaction_endcheck(): Debug regions are unpowered, an unexpected reset might have happened

16:09 <IoT-Maker> any idea how i can fix this?

16:11 <cambrian_invader> would it be possible to add files based on apache-licensed code?

16:11 <cambrian_invader> as I understand it, the combined work would be licensed GPL3

16:11 <cambrian_invader> which is the intersection of GPL2-or-later and apache

16:12 <cambrian_invader> so no license conflict, but I am wondering if upstream would take it

16:14 <karlp> cambrian_invader: aiui, yes, it's allowed, though while searching for what I thought were existing references, I only see src/helper/base64.c as being BSD, and nothing particularly apache at present.

16:15 <cambrian_invader> I'm interested in integrating some things from https://github.com/trabucayre/openFPGALoader

16:18 <karlp> IMO apache2 is fine, but I'm not a maintainer :)

16:33 <IoT-Maker> One thing i noticed is, if i only connect EMU0 to GND and leave EMU1 unconnected i can turn on the device but it will not start. It boots up after i run openocd server

16:33 <IoT-Maker> But same problem in openocd https://pastebin.ubuntu.com/p/884H9h9yNp/

19:15 <borneoa__> cambrian_invader: openocd is GPL-v2. Most of the files are "v2 or later", some are bad but we also have some file taken from Linux and U-Boot that are v2-only. If I remember correctly, apache is not compatible with GPL-v2

19:15 <cambrian_invader> :l

19:15 <cambrian_invader> I read the copying file and it said openocd was -or-later

19:21 <borneoa__> cambrian_invader: Humm, and it's me that wrote it!

19:22 <PaulFertser> I think we tried to keep the whole codebase GPLv2+ by asking authors to make it compatible.

19:22 <PaulFertser> But accepting some code that would make it GPLv3+ would be a big decision.

19:22 <cambrian_invader> yeah

19:22 <PaulFertser> (and probably not possible if not all GPLv2-only code was taken care of)

19:23 <cambrian_invader> well, a quick grep reveals just src/helper/list.h as GPL2-only

19:24 <PaulFertser> That's from Linux I guess.

19:24 <cambrian_invader> yup

19:24 <borneoa__> cambrian_invader: I think I should change that file and write that we stick to v2 while invite developers to propose v2-or-later to new files

19:24 <PaulFertser> tbh, I wouldn't be against going GPLv3+

19:24 <borneoa__> There is one flash driver from U-Boot that is v2 only, from Marek

19:24 <PaulFertser> I think GPLv3 is a better license in every possible regard.

19:35 <Mis012[m]> it's like C vs C++ :P

19:35 <Mis012[m]> the ++ overflows

19:41 <IoT-Maker> what error msg is this and how to fix that adi_v5_jtag.c:522 jtagdp_overrun_check(): Timeout during WAIT recovery

20:05 <PaulFertser> IoT-Maker: probably means the target is sleeping deep enough.

20:14 <IoT-Maker> PaulFertser getting the msg at boot time

20:15 <PaulFertser> IoT-Maker: are you stopping the target in u-boot or some such?

20:18 <IoT-Maker> i stopped uboot

20:20 <IoT-Maker> to prevent booting the system image from spi

20:21 <PaulFertser> Usually the target gives you WAITs when it can't fulfill the request for whatever reason, but it's supposed to be temporary.