Hi Antonio Thank you for the quick reply. I broken it down to two parts in this reply. The first part is about the dependencies and the second part about why use aji_client?
Part 1: Sorry for the link. I used the wrong one, it should be " https://github.com/intel/libaji_client";. I have too many permutation of "lib","aji","client" I am using right now that I got confused. libsafestring is at https://github.com/intel/safestringlib. Libaji_client pulls it in for Linux only libaji_client and libsafestring are on MIT license. While we are on the subject of licensing, note that the MD5 routines in libaji_client (https://github.com/intel/libaji_client/blob/release/21.1/src/jtag/jtag_md5_pd.cpp and it's .h counterparts) are Public Domain licensed. Allow me to take sometime to explain the relationship between libaji_client, libsafestring and OpenOCD: libaji_client uses Linux to provide it with safer string manipulation routine (strcat_s() etc) found in Windows but not Linux. On Windows, there is no libsafestring.dll as it is not needed. libaji_client.so/.dll (and libsafestring.so on linux) must be on the same directory as openocd.exe for security reasons. This is enforced in https://github.com/intel/aji_openocd/blob/release/21.1/src/jtag/aji_client/aji/c_jtag_client_gnuaji_lib64.c#L57 and its win64 counterpart. It will be very clear in the same file that I used the mangled name to access libaji_client from opencod. Please check for me that I am in compliance of GPL-v2. I tried my best, but I might be missing parts. Where possible can you also check me against GPLv3 please? The source code for aji_openocd is under GPL-v2+ and we do intent to go to GPL-v3(+) if and when openocd decides to do it. Part 2: You are right to say that ftdi and ublast2 drivers in OpenOCD already access USB-Blaster and USB-Blaster2. I got ublast2 working and use it as a reference to understand how OpenOCD work before embarking on writing aji_client driver. You had also understand the chain correctly. But take note that the current implementation cannot yet access the FPGA, instead, it is accessing the ARM SOC HPS on the jtag scan chain where FPGA is in the chain description. FPGA access is of course one of our goal. For ease of discussion, I will use this ommunication flow in this email and subsequent emails: OpenOCD -> libaji_client -> <TCP/IP> -> jtagd -> <jtag> ->FPGA where <TCP/IP> and <jtag> refers to TCP/IP and jtag protocol. Needless to say, libaji_client and jtagd can be on different computing hosts, as long as they are accessible via the internet. One way for me to argue for aji-client is to say that we have customer that wants to use our aji_client. While true, is not going to cut it even for me, so I am just going to mention it for completeness. I will say the contribution here is the AJI API documented in https://github.com/intel/libaji_client/blob/release/21.1/src/h/aji.h and the actual client side implementation in the same repository. I think the advantage is how jtagd works. It is a server capable of managing multiple JTAG scan chains, expressed physically as multiple USB-Blaster 2 cables. It exposes those cables via the same TCP/IP port. Jtagd also allows multiple client instances, such as multiple instances of openOCD, to access the same JTAG scan chain at the same time. The effort of setting up jtagd is only worthwhile when you have a pool of USB Blaster2-connected boards to be shared by multiple developers/users. Obviously we deploy several of the pools here, and we do have customers who have similar deployments. Having said that, anyone having jtagd (jtagserver.exe on windows) deployed, this includes all users of Quartus, can connect to their board using OpenOCD. However, your mileage is not very great if it is both openocd/libaji_client and jtagd is on the same host. The TCP/IP communication is not raw jtag bitstream, but high level JTAG commands, i.e. those exposed by interface_jtag*() in the minidriver interface. That was the main reason for using minidriver interface. The important IR and DR access command is at https://github.com/intel/libaji_client/blob/a99de19d6224eb064feb4f13061504c1b50beb6f/src/jtag/jtag_client_open.cpp#L1151, with the link pointing to the code fragment composing the message to be sent to jtagd for DR access. Note that m_openid is the representation of the particular TAP of interest. The control communication can be found at https://github.com/intel/libaji_client/blob/a99de19d6224eb064feb4f13061504c1b50beb6f/src/jtag/jtag_client_chain.cpp I had also elude the the fact that I am writing some code to allow aji_client to access virtual JTAG / SLD (System Level Debuggin) hub/node. Hopefully this will count as a plus for aji_client. More details later as we further our conversation. Finally please note that Intel is willing to consider opensourcing jtagd if there is demand. One of the reason for opensourcing the libaji_client is to see whether there is appetite for jtagd like implementation in open source world. Looking forward to hearing from you soon. Many thanks in advance Best regards Cinly -----Original Message----- From: Antonio Borneo <[email protected]> Sent: Wednesday, April 7, 2021 4:07 AM To: Ooi, Cinly <[email protected]> Cc: OpenOCD <[email protected]> Subject: Re: Moving away from minidriver [Was: [OpenOCD-devel] Survivability of minidriver] Hi Cinly, thanks for releasing your work on OpenOCD. The link https://github.com/intel/aji_client is not accessible. I don't know if it's incorrect or without proper permissions. I want to understand more about the two dynamic libraries "libSafeString.so" and "libaji_client.so", mainly in terms of license and compatibility with OpenOCD license GPL-v2. If I understand correctly, the chain will be: OpenOCD <-> AJI driver <-> above DLLs <-> network <-> jtagd daemon <-> USB-Blaster2 <-> JTAG <-> FPGA Currently OpenOCD supports already USB-Blaster2. What would be the advantage for OpenOCD users to justify this long chain, passing through proprietary SW? Are the API of the jtagd network protocol available? Do we really need to link with the two DLLs above? Or can we simply open and use a socket to talk with jtagd in the OpenOCD driver? Best Regards, Antonio On Tue, Apr 6, 2021 at 1:16 PM Ooi, Cinly <[email protected]> wrote: > > Hi Antonio and all OpenOCD developers > > > > Finally we released our driver on github.com/intel/aji_openocd. It uses the > minidriver and is based on v0.10.0 (mid June 2020). > > > > I am finally ready to discuss how to go forward with the deprecation of > minidriver. My ideal outcome from this discussion will be to have my driver > implementation coexists with other drivers. At present, being a minidriver, > it demands exclusive access to OpenOCD. > > > > > > I had updated the the driver to use release v0.11, and it is in branch > discuss/openocd. More specifically > https://github.com/intel/aji_openocd/commit/403ae3e955d728762159e2f274 > 0c5987c25862c4 > > should get you to the commit of interest. The commit previous to it is from > v0.11 in case you need to find the actual commit where I had forked the > driver from. > > > > Ignoring configure.ac, docs, and config files, the files of interest to us > are all in src/jtag. My driver code is in src/jtag/aji_client. I have to > overwrite interface_* functions because the driver we use is expecting high > level jtag commands and not jtag bitstream to drive the pins. > src/jtag/aji_client/aji_client.c is where all the implementation of > interface_* from minidriver are. > > > > I also have to use conditional compilation to help me bypass/replace > functions in core OpenOCD to get the driver to work. To find them, use “grep > -R BUILD_AJI_CLIENT”. > > > > For v0.11, I also have to revert some minor changes to restore minidriver > functionality. Those should be obvious. > > > > Technically we need a lib/dll to be built from > https://github.com/intel/aji_client . Just in case you need to compile it, > instruction is in README. [Original openocd instruction was moved to > README.openocd]. For this discussion, I believe compilation is not necessary. > > > > Looking forward to your replies. If there is any questions, please do not > hesitate to contact me. > > > > Many thanks > > Cinly > > > > P.S.> In a few days’ time I will be asking for help again. This time is ask > for comment on current preliminary code to integrate virtual JTAG/SLD > infrastructure (See > https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_virtualjtag.pdf) > into OpenOCD. I am currently tidying up the code to make it more > presentable. > > > > > > > > From: Ooi, Cinly <[email protected]> > Sent: Saturday, March 6, 2021 12:50 AM > To: Antonio Borneo <[email protected]> > Cc: OpenOCD <[email protected]> > Subject: Re: [OpenOCD-devel] Survivability of minidriver > > > > Hi Antonio > > > > Thank you for the reply. > > > > I did had a look at other adapter_drivers, including aice and > libjaylink (which was the closest to mine) > > > > Let’s wait for a few week for the driver to clear internal process and > officially open sourced in a few weeks. That way we have the source code laid > in front of us, and we can discuss (1) how to proceed with both this and (2) > discuss how I have to modify my driver to your satisfaction to allow me to > create a pull request for openocd. I will based the modification on the new > 0.11 base instead of 0.10 base I am using now. > > > > I will be back. Your reply that minidriver will be gone soon is not a > surprise. When we started doing the driver, we were too new to OpenOCD and > that was the fastest way to get things prototyped and working. Management > knew they have to revisit the issue. > > > > Many thanks for the quick reply. Looking forward to talk to you about this > further in a few weeks. > > > > Best regards > > Cinly > > > > From: Antonio Borneo <[email protected]> > Sent: Friday, March 5, 2021 7:12 PM > To: Ooi, Cinly <[email protected]> > Cc: OpenOCD <[email protected]> > Subject: Re: [OpenOCD-devel] Survivability of minidriver > > > > > > On Fri, Mar 5, 2021, 12:00 Ooi, Cinly <[email protected]> wrote: > > Hi All > > > > I had written a driver which uses the minidriver interface, It is working > fine and we plan to open source it in a few weeks (>5) time when all > internal due-diligence are done. > > > > Before I started I already noted that only zy1000.c is using the minidriver > interface, and it itself is scheduled for removal. With that only use case > gone it will mean there is a high chance that interface will be removed. > This meant that I have to come here and ask the OpenOCD development team > whether do they have plans to deprecate and remove this interface? and if so, > when? And is there a replacement? > > > > Many thanks in advance and best regards > > Cinly > > > > Hi Cinly, > > > > I'm just waiting for the new release v0.11.0 within next few days to upstream > a patch set that drops zy1000 and the minidriver. > > > > Have you checked the other drivers based on struct adapter_driver? > > If you can share your current code, we can check together how to move it to > the new API, or even detect that minidriver is the best option and has to > stay! > > > > Regards > > Antonio > >
