Since I still not sure, what missing functionality should be covered, I try to ques: the point is to make OpenOCD and Quartus users happy. Without need to support Quartus, this construction is not needed. Correct?
Am 07.04.21 um 13:49 schrieb Ooi, Cinly: > 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 >> >> -- Regards, Oleksij
