daves

The makefile is always using -O2 and no -g. DT build (or try to) the usralgo.ko using Release code independent of the project code. The damning thing is I am seeing this phenomenon when I build my LKM too from the command line. I have exactly the same makefile (based on DT usralgo one) for both CPUs but all I change is the "PMAC_ARCH=ppc465-2" setting. The flags are identical, just the paths and gcc compiler change, and the ARCH setting. I agree, the flags should control it, but could the problem be in where a statically linked library is found? Or is the 465 cross-compiler ignoring flags?

Thanks shansen, I am and do! The -S comparison looked basically the same (just the functions I expected) I did 'objdump --section-headers' on them and it appears debug info is being added to the 465 build. This troubles me. The additional sections in the 465 build were 17 .gnu.attributes 00000010 00000000 00000000 00003790 2**0 CONTENTS, READONLY 18 .debug_aranges 00000068 00000000 00000000 000037a0 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 19 .debug_info 00037b09 00000000 00000000 00003808 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 20 .debug_abbrev 00000f00 00000000 00000000 0003b311 2**0 CONTENTS, READONLY, DEBUGGING 21 .debug_line 000024e9 00000000 00000000 0003c211 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 22 .debug_frame 00000588 00000000 00000000 0003e6fc 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 23 .debug_str 000251aa 00000000 00000000 0003ec84 2**0 CONTENTS, READONLY, DEBUGGING 24 .debug_loc 00001a50 00000000 00000000 00063e2e 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 25 .debug_ranges 000004d8 00000000 00000000 0006587e 2**0 CONTENTS, RELOC, READONLY, DEBUGGING So there is over 400KB of debug info stuck in here, does this mean the libraries linked are debug builds (my initial suspicion)? We have intensive calculation requirements and cannot afford to be running debug code... I've spent a morning hunting where it comes from compiling from the commandline, but it's a bit beyond me and the time I can spend now. How do I get a nice clean build of release code on the 465?

Thanks Steve, I have been caught out by this in the past, but it doesn't explain it this time. They were both in Release and I think the usralgo.ko is built the same irrespective of configuration. If you build in Release or Debug it is the same size, the makefile is identical apart from the output folder.

Should I be worried my usralgo.ko compiles to 600KB when building for a 465 dual core CPU and only 18KB when building for a 460? (Same project/IDE/fw version) I am doing a lot of work on custom kernel modules which compile to 5KB on the 460 and 300KB on the 465. As well as being a lot slower to FTP to the PC I wonder what is in them... I am seeing other performance degradations in the 465 build (like the slow memory allocation erratum). We have a system relying on this up for delivery soon. Is it as expected?

Hi Dan, I am no expert in this but I can cross-compile my own C code on Windows to a .out file and run on the linux system. The key is the make file. I would first build (in Release config) and download a project from the IDE with a background c-app in it then take the makefile from the app's folder ("capp1_release.mak" or similar) and look at that for how to create your own. I run an administrator command prompt with "PATH=C:\DeltaTau\Power PMAC IDE\compilers\bin;C:\DeltaTau\Power PMAC IDE\compilers\usr\local\bin". Then I have, for example, the following: example.c #include int main(void) { struct timespec uSecSleeper = { 0 }; // Initialize time structure struct sched_param param; param.__sched_priority = 0; pthread_setschedparam(pthread_self(), SCHED_OTHER, &param); uSecSleeper.tv_nsec = 1000000; // 1e6 nanoseconds, which equals 1 msec InitLibrary(); while (1) { pshm->P[0]++; nanosleep(&uSecSleeper, NULL); } CloseLibrary(); return 0; } Then I rename the xxx_yyy.mak file to Makefile, put in a directory with your c file, make a subfolder called Release. Then change anything referencing "../../../Bin/Release/" to "Release/" in the makefile. Then make sure the bit defining the sources is [/code] SRCS = \ example.c OBJS = $(SRCS:.c=.o) PROG = "Release/example.out" Then cd your command prompt to wherever your files are and run make. Then you can FTP the example.out file to the PPMAC, change permissions and execute! Watch P0 go up! I have no idea if this is the full story but may help you modify your makefile... I imagine compiling C++ on the linux system has its own issues, I would be interested know how you get on. Dave

IDE: 2.1.0.107 I'm seeing some weirdness and don't know if it is intentional but it is inconvenient. I'm struggling to build my project to test the C compilation when not connected. This used to work fine on 2.0.3.40. Starting the IDE with No Device, then loading my project I get a message I've not seen before (I don't get this choice when changing communication settings once the IDE is running): --------------------------- Comparing Project IP Address --------------------------- Phase2.ppproj IP Address (195.0.0.1) is different from Power PMAC IDE's IP address (No Device). Would you like to change your project's IP Address to match Power PMAC IDE's IP Address? --------------------------- Yes No --------------------------- It doesn't matter which I choose in terms of the failure (see below). If I choose No the behaviour changes depending on if I actually have a device connected. If I do, it goes ahead and uploads libraries and says (195.0.0.1:PowerPC,APM86xxx) on the project. If there is truly no device the project says (195.0.0.1:Disconnected) for a second, then just (195.0.0.1:). Then on build I get the additional message: --------------------------- Upload libraries failed --------------------------- Uploding Power Pmac Libraries Failed. Do you wish to continue the build process with your default set of libraries --------------------------- Yes No --------------------------- Choosing No aborts, so I choose Yes (note: There is a spelling mistake here, a few capitalisation errors and a missing question mark). Then the errors appear on all the background C apps (names redacted): Build Process For ███.out has started. ███: Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_printf' ███: Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_fwrite' ███: Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_fprintf' ███: Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_puts' ███: Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_free' ███: Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_fputs' ███: Error : collect2: ld returned 1 exit status Build Process For ███.out has ended. How do I do an offline build?

Hi, we have a project originally created in IDE 1.7.0.53 (or earlier) but which we have taken with us through the various upgrades. After upgrading to firmware 2.1.0.39 and staying on IDE 2.0.3.40 this fails the download with Error: Loading RT Address of preProcessFeedback Error: Loading RT Address of CBAR_throttle Error: Loading RT Address of SR_control_logic Error: Loading RT Address of user_pid_ctrl Error: Loading RT Address of CfromScript Error: Loading RT Address of CaptCompISR The first four are our userservo/phase functions. CaptCompISR doesn't exist as the template from the vintage of IDE we start with doesn't have this code in (or CFromScript but we added that). To help anyone else flummoxed by this, adding to usercode.c: void CaptCompISR(void) { } and usrcode.h: void CaptCompISR(void); EXPORT_SYMBOL(CaptCompISR); fixes all the errors. This reminds me that "now" you get all the // Required Startup Code: Insures that this APP is run as an RT or NON // RT APP otherwise depending upon how it is started it will inherit // the scheduling priority and policy of the task that started it. stuff in a new c-app... but we had to manually add the code to our apps. I know you can't automatically do it but there is no notification to do it, at least not obvious enough for me to spot. My 2 questions: 1) Are these things documented? A list of instructions on upgrading your project. I figured out the CaptComISR thing but many people would be a bit stumped 2) Can you provide a comprehensive list of compatibilities between Projects, IDEs and firmwares? I have never been confident. E.g. can I send a project created in IDE v2.0.3.40 to a client running v1.7.0.53? Obviously if you use new firmware features you have to use at least that firmware, although I notice some removals which complicates matters.

OK thanks for the info

Thanks Steve, I've just upgraded and with IDE 2.1.0.107, FW 2.1.0.39 I do seem to get the same error report as you on the test program now. However, the error comes after download, I really need it to be at the start, or the first time pp_proj.h is generated, as my issue was in the C-code (i.e. the Build process, way before the download and post-process). In our main project we use _PPScriptMode_. The first build of pp_proj.h is incomplete. Due to the overrun of M-vars and large number of other variables it seems to not completely define all the ptr and globals in the _PPScriptMode_ section. Then during the build of the 10s of C modules, I get hundreds of "Error : 'FLHWPMSEnc04' undeclared (first use in this function)" messages which take forever (I killed after 15mins). It is hard to recreate the conditions causing it. I will email you a test project with our pmh header an a c app which demonstrates it.

So, I examined firmware 2.1.0.39 and see the addition of libSecureDongle. This seems to be exactly what I was asking about! Is there going to be a DT supported dongle option? Should I hold off on investigating UniKey? I have some on order and to be honest we like the nano size they offer (can't see that on SecureDongle)...

OK, thanks for clearing that up. Trapping this in the IDE would be great! Also the SRM section for "ptr" needs fixing (p1156 in Jan 6, 2015 version). Something to consider, 16384 is not a large number when you have GB of RAM available . It seems I am using ~7000 before wanting two arrays in memory of 8192 elements (agreed, probably not the best way to do what I need). I am aware of the alternatives and will have to look at them (just reserving user shared memory and using pushm+0xNNNNNNNN, dropping below the M8192 start, using Sys.DData, etc). But... your programmers won't like this... it seems wasteful to allocate a precious M variable for each element of a ptr array. Could there be some cunning way to free them up? Or add more? I understand there would be compatibility issues.

I just got confused by apparently hitting the M-variable limit. Took a while to twig. The behaviour seems odd, and should definitely halt the build (not the download as it breaks the C-files with a bad pp_proj.h), reporting the error. I have seen some strange things: Make a new project with the following in "global definitions.pmh": ptr Dave(8192)->d.user:6400000+; ptr Blob(8192)->d.user:6465536+; ptr Foo(8192)->d.user:6531072+; Build reports OK and puts ,Dave=8192 ,Blob=16384 ,Foo=24576}; in pp_proj.h. But the SRM M{data} definition says M vars can only be in (0 – 16,383). Indeed RtGpShm has "#define MAX_M 16384". So is this OK? Then the SRM ptr definition states there are 65536 M variables. Which is it? How does SHM cope with Mdef over 16384? If you try something like: ptr Dave1(8192)->d.user:1000000+; ptr Blob1(8192)->d.user:2000000+; ptr Dave2(8192)->d.user:3000000+; ptr Blob2(8192)->d.user:4000000+; ptr Dave3(8192)->d.user:5000000+; ptr Blob3(8192)->d.user:6000000+; ptr Dave4(8192)->d.user:7000000+; ptr Blob4(8192)->d.user:8000000+; ptr Foo->d.user:9000000; You end up with enum ptrM {_ptrM_=-1 ,Foo=73728}; which is bigger than both stated limits. However my error manifested itself slightly differently and if you change the pmh to the following you see something similar (I can't quite figure out what caused mine but it was adding an 8192 array) ptr Dave1(16400)->d.user:1000000+; ptr Blob1(8192)->d.user:5000000+; ptr Foo->d.user:9000000; pp_proj.h just gives you enum ptrM {_ptrM_=-1 ,Foo=16384}; enum ptrMarray {_ptrMarray_=-1 ,Blob1=8192}; Here Dave1 doesn't appear and there are no error messages. The SRM definition of an array says the size must be "either a positive integer constant or a previously defined identifier for a positive integer constant". In my real project thousands of variables didn't make it into pp_proj.h. Then the IDE has thousands of errors on the build of the 10s of CPLCs etc. There is no way to interrupt or to see what caused it. I had to End Task after 30 minutes (the reporting of each error in the IDE listview is very slow)

Thanks for the replies. shansen: That sounds like an interesting idea. If we had more resources I would look into it. Not sure about encrypting the filesystem (how to do it or what it might affect...) I think the risk of our customers actually bothering to "crack" our systems is very small so we are looking for a minimal effort solution. We have experience of dongles and the UniKey one seems to have linux driverless ability to get a HID or SoftID (plus other features we may find useful in future). I'm going to evaluate it.

Sorry Steve, I was talking about connecting a PC directly to the daughterboard USB socket which mounts it as a drive, running WinImage to backup one PPMAC to VHD and restore to another. It is the same approach you use to repair a bricked card (and maybe even when you commission a new card) or put your non-video image on a card. Also the direct USB connection bypasses the need for root login to examine the filesystem and edit files on it as a removable drive. I have pointed out this security flaw before.

I didn't think this would prevent a filesystem image clone from one PPMAC to another, or would it?

Is there a code-accessible globally unique ID for each CPU card? We have customers with multiple systems with differing specifications (i.e. they have paid for advanced features on one system). We want to prevent cloning of the better system. Hiding a file / MAC addresses can be cloned. Do we have to buy USB dongles (we would rather not)? Do you recommend one? (I am tempted by a UniKey STD)...

Thanks again I am floundering with this makefile/cygwin stuff (my ignorance I'm afraid). I cannot figure out how to get my Module.symvers easily found... I can do it if I set: KBUILD_EXTRA_SYMBOLS := /usr/local/dtlibs/libppmac/Module.symvers /usr/local/dtlibs/libppmac/Module2.symvers and copy my Module.symvers to "C:\DeltaTau\Power PMAC IDE\compilers\usr\local\dtlibs\libppmac" as Module2.symvers I cannot figure out how to get the path to it if it resides in a subfolder (mymod) off where the c files are (current directory running make from a Windows command window). I have messed around for ages with $(PWD), cygpath etc if I add stuff like the following (or any combination, or not at all!) WIN_MOD := $(shell cygpath -m -a mymod/Module.symvers) WIN_MOD := $(shell cygpath -u $(WIN_MOD)) ifneq ("$(wildcard $(WIN_MOD))","") FILE_EXISTS = 1 else FILE_EXISTS = 0 endif I always get the file reported as existing but not accepted in KBUILD_EXTRA_SYMBOLS. Maybe I just give up and do the copying thing above which works. It must be a cygwin/windows path issue but I am stuck. I do the /lib/modules/$(uname -r), depmod, and modprobe bits so it all works in terms of functioning. I just don't like the warning on make!

Thank you very very much shansen. It is comforting to know someone else is doing this! I have followed your advice and now have a LKM I can rmmod/FTP/modprobe on the fly, locate the function address, and stuff into userservo. All using a background C-app reacting to a command from the HMI. I can supply our customers with some template code and a makefile along with the compilers/libraries (of the best way to do this I am unsure; I am waiting for a response about any distribution issues, also I assume this will need to be tied to a particular firmware release). Another question: Everything "works". My customer module calls some functions I export from the usralgo module (making them available between modules). However the build of the customer module warns these functions are undefined. I see Module.symvers is the key. Do you know much about it? I must admit I haven't looked into it much but have failed to get the makefile to use the module.symvers from the DT project on my first attempts. Thanks again

Background We like to push the DT products to their limits. Our customers can currently write custom code of their own in a DLL which talks through our HMI. Feedback from the machine is passed to the DLL. The output from the DLL then modifies the command to the machine. Aim We want to move this custom module to the PPMAC (to improve performance etc). We cannot provide the source to the customer so it has to be an extension of the existing project. Proposals I have managed to write a new kernel module and call it from userservo. This works but is a hassle to set up and exposes too much stuff to the customer. I have also managed to compile user kernel code and link it to the existing usrcode.o and usralgomain.o files to make the useralgo.ko file and FTP it across. This works and is my preferred method. I think I understand the limitations of writing LKMs and realise the dangers of exposing this to customers but I cannot think of another way to extend functions called from userservo (we really want to run on the realtime core of a 465 card). Questions Does anyone else have experience of this? Advice? Can anyone see any pitfalls? Please can someone tell me how to stop/start the usralgo module? Currently I have to cycle the power every time I change my rebuilt module. I need to avoid this as the customer will need to easily swap between custom modules. I am awaiting DT assistance from an email but if any other users have experience this would be great.

There is an empty "2016-02 Ver 2.1.0" IDE folder in the file depot. Is this imminent? We are looking forward to the next release!

Hi Steve As I said to Charles in message #8 released firmware 2.0.2.14 shows no sign of the _PP_PROJ_HDR_ sections in pp_proj.h and doesn't work. I can see them in my pre-release 2.0.2.235 firmware and it does seem to compile with your suggestion. Are you saying this should work in the released f/w? I too would love it if it did!

Charles, not wanting to speak for the OP, and not knowing for sure what firmware he has, I would like to comment: The _PP_PROJ_HDR_ feature looks a little like the re-engineering I was hinting at. It certainly looks interesting and I would love some details of how it works. Plus it seems simpler than my suggestions! However a quick try on the released firmware 2.0.2.14 shows no sign of the _PP_PROJ_HDR_ sections in pp_proj.h and indeed your suggestion doesn't work. I can see them in my pre-release 2.0.2.235 firmware and it does seem to compile with your suggestion. The pp_proj.h Windell supplied shows no sign either, so I don't hold out much hope.

This is to do with the way DT have function definitions in the pp_proj.h file. (These functions are only present in the _PPScriptMode_ and _EnumMode_ states) Your TCSserv app has multiple c files with '#include "../../Include/pp_proj.h"'. This means the function definitions get compiled into multiple .o files. The linker then tries to link these together but there are multiple definitions of the same function. (This can easily be demonstrated with a blank project adding a new c file to capp1 then make both c files have '#define _PPScriptMode_') I think you have a few of options (maybe someone else can think of more). 1) Could you restructure your project to have, say, tcsmain and tcspmac as separate libraries in the Libraries folder? 2) It might be possible to restructure your background app to just have one C file which contains all the PPMAC interaction (basically some sort of abstraction). Then you can include pp_proj.h in only one file. This may be a lot of work for you. 3) You can build the file manually. I have managed to do this on your files (maybe someone knows a better way to do it, I just made it up!). It is not very convenient and I may have not explained it in enough detail! Open a command prompt (as administrator maybe). Type "path=C:\DeltaTau\Power PMAC IDE\compilers\bin;C:\DeltaTau\Power PMAC IDE\compilers\usr\local\bin" Change to your TSCserv folder with e.g. "cd \blahblah\Background Programs\TCSserv" Edit pp_proj.h (you will need to do this every time the IDE regenerates it) Change the functions to be of the form: "static void __attribute__ ((unused)) SetEnumGlobalVar(enum globalP var, double data)", this keeps the function 'private' to each .o file (and suppresses warnings about any unused functions). In the command prompt type "make -f TCSserv_debug.mak" This should build "PowerPMACProject\bin\Debug\TCSserv.out" You then need to FTP this to PPMAC (after IDE build and download excluding TCSserv). It will take quite a bit of manual fiddling each download. 4) Persuade DT to re-engineer the pp_proj.h file... :)

Through my own fault I ended up with a bad config and saved it and $$$ed. There was no indication of what was wrong but the ConfigLoadErr was on. A) Would it be possible to expose the error I eventually found in pp_error_hist.log to the IDE window? [PMAC_HARDWARE] [PMAC_CONFIG] /var/ftp/usrflash/Project/Configuration/pp_save.cfg:575:18: error #31: invalid function in equation: Motor[1].InvAmax=nan B) Wouldn't it be better to raise the error on save, and what is the problem? The system allows a setting of "nan". It allows a save of "nan", but not the load apparently...

Thanks this is neat and pleasing!