Hi Antonio > from what I see, it's libaji_client.so that needs libsafestring.so. > The code you have added in openocd doesn't need libsafestring directly.
Correct. > I didn't enter in the details of dlopen() & friends, but maybe it's enough > to only load libaji_client.so that will in turn load libsafestring.so? > But this is just for reducing the code, not really an important point. When I experimented with dlopen(), I could not get libaji_client.so to automatically load libsafestring.so, but the reason might be I was using a old gcc version or just did not use the correct flags to it. That was a while ago. Then when it comes to implement it for real, the "same directory as openocd" approach meant I do have to check make sure libsafestring is on the same directory so it made playing with it again moot. >Being the libraries loaded at runtime through dlopen() is a good step. >OpenOCD can be distributed with aji support compiled in and without the extra >libraries. >If the user selects aji driver and has the libraries, it will work. If possible I should follow the openocd approach where except for libraries expected from the OS, e.g. ftdi and libusb, everything should be compiled into openocd. > Without the libraries he can still use the same OpenOCD binary with other > drivers. At present, because of the minidriver approach, aji_openocd cannot work with other drivers. It is one of the main reason why I would want to move it away from minidriver. > About your limit of libraries in the same folder of openocd ... > I don't see this as a security feature. Plus some linux distribution > could distribute the libraries in /usr/lib/ It does not follow Unix convention. I need to discuss it with our security experts here. I think they are open to it. >> 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. > From the license side, it seems ok for me. MIT is more permissive than GPL > so, if I'm not wrong, it's possible to add MIT code in OpenOCD and to load > MIT libraries. Thank you. It is my understanding as well, i.e. one way from MIT to OpenOCD >There was some discussion about moving OpenOCD to GPL-v3. >OpenOCD benefits from code taken by other projects, mainly Linux and U-Boot. >These two are GPL-v2 "only". Their code cannot be incorporated in GPL-v3 >projects. >Plus we have a couple of files in OpenOCD that are GPL-v2 "only". >Moving to GPL-v3 will mean dropping these files. >Due to these limitations, personally I don't expect the move to GPL-v3 will >happen. >Your code licensed as MIT can always be linked in another GPL-v3 project. So I >believe your question is not strictly about your code but more about the >future use of OpenOCD by intel, correct? Intel is fine with GPL-v3 as far as OpenOCD is concerned. I just wanted to future-proof it. >> Part 2: >Clear! >The daemon jtagd guarantees concurrent access by different players and bridges >openocd to the core inside the FPGA. Well put! >From the OpenOCD license point of view, there is no need to get jtagd >open-sourced. And for the time being I don't think it is needed for this >development. It remains up to intel what to do with jtagd. Noted. > Maybe I'm missing something, but moving from minidriver to jtag driver does > not look so disruptive. > interface_jtag_add_ir_scan() and interface_jtag_add_dr_scan() skip the unused > TAPs, but the other API just queue the commands. Then > jtag_interface->execute_queue() unpacks the queue. I agree it is not very destructive. The main difference between aji_client and all other jtag drivers, including those capable of operating over TCP/IP is, while all jtag drivers send the full jtag bitstream (tms/tclk/tdi) over to the server, aji_client does not send bitstream but high level commands. In fact there is almost a 1:1 mapping between interface_jtag_*() instructions to its equivalent c_aji_*() functions in AJI. Take for example interface_jtag_add_ir_scan(), it is a 1:1 mapping to c_aji_access_ir() (https://github.com/intel/aji_openocd/blob/discuss/openocd/src/jtag/aji_client/aji_client.c#L855) the other code inside interface_jtag_ir_scan() are to bridge the difference between interface_jtag_add_ir_scan() and this function. Ditto interface_jtag_add_dr_scan() with c_aji_access_dr (line 975) and interface_jtag_add_tlr() with c_aji_test_logic_reset() (line 1054). All the others modification to OpenOCD that I had made are to support this difference. AJI commands can be queued. I did not do it because as a newbie to openocd, I am trying to avoid complexity in my code because it interferes with me studying OpenOCD. The other reason is libaji_client has it own queueing capability. However, looking at overhead of setting up for AJI in interface_jtag_*() functions, a command queue might be able to reduce the overhead and may be implemented. At present jtag_interface->execute_queue() is called to ensure all the callbacks are executed. >Anyway, if you really hit a blocking point, as written in the commit message >of http://openocd.zylin.com/6091/ , the minidriver can be back in a modern >re-implementation. Thank you for that. However, ideally I will prefer to work with you are other OpenOCD folks to get a proper interface for our driver, as we are hoping to contribute aji_client back to OpenOCD official repository. We would also like to have aji_client sharing the same openocd binaries with other drivers, instead of hogging the OpenOCD binary to the exclusion of others. We are prepare to put the work in but we do need guidance from you and OpenOCD folks on how to approach it. Many thanks in advance Best regards Cinly
