In case others are using the same VisionClick/VisionProbe JTAG debugger from EST ( now WindRiver ) I'm posting this thread. They will be releasing a new version soon that will fix some problems it had with ELF files generated by the GNU tools. (PPC)
Also of note is the fact that there is an undocumented and unmentioned tool called CreateBin.exe in the EST install dir. It will create an EST flat bin file, from any arbitrary file, that Click will load. It is especially useful for dealing with a kernel with initrd situation, as EST's convert tool ignores the image sections. The kernel (vmlinux) can be loaded and source level debugged normally and the compressed initrd rootfs can be subsequently loaded anywhere in mem. after CreateBin is used on it. (i.e. at the physical address that the kernel has been compiled to expect to find the ramdisk.image.gz image). Normally the initrd file offset etc. is defined when arch/ppc/boot/misc.c is re-compiled, but in my case I don't use the secondary boot loader so I've created a post build script that uses the same technique and re-compile sandpoint_setup.c with the offset and size info. I do something very similar to misc.c in sandpoint_setup.c. BTW, at some point I'll create my own renamed copy of the sandpoint files for our board so as to avoid extra work when MontaVista updates their sandpoint files. I also had to modify arch/ppc/Makefile to add the offset and size defines ( zero ) to the CFLAGS list. The only problem with this technique, is that the size of the kernel changes slightly when the offset and size defines are non-zero. Not sure if this also happens for the normal zvmlinux etc. build process. Slighty different code must be generated? Don't have time right now, to really check this and it is easy to deal with anyway. If anyone wants that script, let me know. Cheers, Ron Ron Bianco Computer Systems Technologist Level Control Systems email: ronb at junction.net phone: 250-549-2558 Ext 8 web: www.lcsaudio.com **** thread starts **** Ron - It looks like the elf file is correct. The GNU compiler is generating dis-contiguous module code and we have to do some work in both the convert utility and Click to account for the separate sections within the module. We are working on it -- I will keep you posted. ...gregj ----- Original Message ----- From: Ron Bianco To: Greg J Cc: pete.redlien at windriver.com Sent: Tuesday, September 05, 2000 6:26 PM Subject: RE: wrong source for function Hi Greg, Any progress on this? I can see why Click would have problems with this. Is my elf file screwed? If it is a GNU linker problem, I should try to track this down. What does the Convert guy say? It would very cool and helpful to get this working right. Cheers, Ron -----Original Message----- From: Greg J [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2000 9:35 PM To: Ron Bianco Cc: Pete Redlien; briann at estc.com Subject: wrong source for function Ron - I will attached a newer version of CLick that should restore your assembly labels in a separate email. The wrong source problem is being caused by the symbol information. CLick thinks the address for ncr_snooptest falls in the range of init_microspeed in mac_key.c. In looking at the symbol infomation that convert is producing from your elf file, I find a lot of suspect function end addresses -- I have copy of handful of samples below. These "large" suspect ranges overlap the ligitimate ones an in this particular case, click finds init_microspeed before it finds ncr_snooptest. I will have our symbol expert look at the file to see if this is an elf file problem or a convert problem. regards...gregj **** thread ends **** ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
