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/403ae3e955d728762159e2f2740c5987c25862c4 > > 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 > >
