Ahh, I would be interested to see if Rurik's suggestion works. --Louis P. Dartez On Feb 17, 2012 12:43 PM, "Rurik A. Primiani" <[email protected]> wrote:
> Hi Laura, > > I think you can get this error if you're attempting to run a 32-bit binary > on a 64-bit machine without the compatibility libraries. Have you installed > these? You can do so by running: > > $ apt-get install ia32-libs > > Best, > Rurik > > On 2/17/12 1:22 PM, Laura Vertatschitsch wrote: > >> Hey Griffin, >> >> It is definitely there and is executable. We tried simply running in >> the command line the same syntax described in gen_prog_files right from >> the directory with mkbof - still same error. I mentioned that we did >> need to use the gmake fix described, not sure if the executable that was >> built is just not compatible with the Ubuntu specs. I am a bit out of >> my expertise there. >> >> We still have Ubuntu set up and wouldn't mind getting to the bottom of >> it, but have started to push forward with a RHEL build to sync up with >> others and minimize the occurrence of completely unique errors. >> >> --Laura >> >> On Fri, Feb 17, 2012 at 2:18 AM, Griffin Foster >> <[email protected] >> <mailto:griffin.foster@gmail.**com<[email protected]>>> >> wrote: >> >> Hi Laura, the line './gen_prog_files: line 3: ./mkbof: No such file or >> directory' in your error log suggests that mkbof is missing, which is >> pretty odd. Is the mkbof executable in the <model >> name>/XPS_ROACH_base/ directory after you run the compile? The >> original is in mlib_devel/xps_lib/XPS_ROACH_**base/ . What happens >> when >> you run mkbof outside the toolflow? >> >> i.e. in <model name>/XPS_ROACH_base/ run >> ./mkbof -o implementation/system.bof -s core_info.tab -t 3 >> implementation/system.bin >> >> -Griff >> >> On Wed, Feb 15, 2012 at 10:35 PM, Laura Vertatschitsch >> <[email protected] <mailto:[email protected]>> wrote: >> > Thank you so much for your kind replies. For what it's worth, I >> will >> > include the error at the end of the message. It boils down to >> mkbof. I >> > searched the archives and found a similar error that Louis >> commented on, but >> > didn't see a resolution in that thread. Louis was kind enough to >> suggest >> > changing permissions (tried, same error), seems consistent with >> this error >> > that John was seeing. Starting to suspect operating system >> issues - perhaps >> > even libc in 64 bit ubuntu (the web seems to see issues from >> 11.04 on). >> > >> > A "solution": I copied the file over to my windows machine and >> just ran the >> > windows executable, and no problems. It's not an elegant flow >> by any >> > means, but hey, we now have our first compiled bof file and the >> Roach board >> > is blinking as expected - an exciting little victory. >> > >> > We will grab our sys admin who is a linux guru to see if he can see >> a >> > solution that we could share with the community in case anyone is >> interested >> > in using Ubuntu. >> > >> > While its set up here we will update to 12.4 as Alec suggests to >> see what >> > changes. After that we will just take a few hours and set up our >> virtual >> > machine with Red Hat so we can be synced up with the rest of the >> community. >> > >> > --Laura Vertatschitsch >> > >> > ::::::::::::::: >> > >> > Specs: Ubuntu 11.10, Xilinx 11.5 (Including system generator >> 11.5), and >> > Matlab 2009a. We are operating in a virtual machine, and we set >> up 11.5 >> > using the Linux XPS webpage, including copying the 3 files >> necessary, and we >> > did need to apply the gmake fix as well as a symbolic link fix >> that we found >> > in the listserve archive (sh-->dash changed to sh-->bash). And >> of course >> > added 11.5 to the case statements in bee_xps. >> > >> > ::::::::::::::: >> > >> > [edited to show the final few lines] >> > >> > Running DRC. >> > WARNING:PhysDesignRules:367 - The signal >> <infrastructure_inst/dly_clk> is >> > incomplete. The signal does not drive any load pins in the >> design. >> > WARNING:PhysDesignRules:367 - The signal <sys_reset> is >> incomplete. The >> > signal >> > does not drive any load pins in the design. >> > DRC detected 0 errors and 2 warnings. Please see the previously >> displayed >> > individual error or warning messages for more details. >> > Creating bit map... >> > Saving bit stream in "system.bit". >> > Saving bit stream in "system.bin". >> > Bitstream generation is complete. >> > No changes to be saved in MSS file >> > Saved project XMP file >> > ./gen_prog_files: line 3: ./mkbof: No such file or directory >> > chmod: cannot access `implementation/system.bof': No such file or >> directory >> > cp: cannot stat `implementation/system.bof': No such file or >> directory >> > >> > Error using ==> gen_xps_files at 702 >> > Programation files generation failed, EDK compilation probably >> also failed. >> > >> > >> ::::::::::::::::::::::::::::::**::::::::::::::::::::::::::::::** >> :::::::::: >> > >> > >> > On Wed, Feb 15, 2012 at 12:01 AM, Jason Manley >> <[email protected] <mailto:[email protected]>**> >> > wrote: >> >> >> >> I would encourage you to just use CentOS/Redhat. You have to change >> >> various libraries in Ubuntu (to very old ones!) to make the 11 >> 'flow work >> >> natively. I seem to recall perl and gcc both giving trouble, for >> example. At >> >> KAT, we do run Ubuntu, but the 'flow executes in a chroot RHEL >> environment >> >> to keep their old libraries and executables. I've been led to >> believe that >> >> this won't be necessary with the v13 'flow but I haven't >> actually got it >> >> running yet so can't vouch for that. And I don't recommend you >> start with 13 >> >> because you have to manually copy deprecated cores from v11 to >> make it work. >> >> >> >> Many find Redhat annoying but if you're getting started, I >> advise you use >> >> rather bite the bullet and use it. You can always install it as >> a virtual >> >> machine initially if you don't want to disturb your primary OS. >> Also, don't >> >> install all the latest RHEL updates. >> >> >> >> Jason >> >> >> >> >> >> >> >> On 15 Feb 2012, at 09:40, Alec Rust wrote: >> >> >> >> > Hi Laura, here are instructions for setting up 12.4 labtools, >> the same >> >> > procedure will work for setting up the full version. >> >> > >> >> > Install Xilinx in /opt/Xilinx >> >> > • Download Xilinx 12.4 Labtools. This can be downloaded >> from >> >> > http://www.xilinx.com >> >> > • Untar (tar -xvf Xilinx_LabTools_12.4_M.81d.2.**0.tar) >> and install >> >> > by running “sudo ./xsetup” in the Xilinx directory. >> >> > • Generate a webpack licence on the website, a lic file >> will be >> >> > emailed to you. During installation select the webpack licence >> and follow >> >> > instructions. >> >> > • To run Xilinx Impact type the following in a terminal >> (source >> >> > runs a pearl script that sets up the Xilinx paths): >> >> > source /opt/Xilinx/12.4/LabTools/**settings64.sh >> >> > impact >> >> > >> >> > >> >> > Regards >> >> > Alec >> >> > >> >> > >> >> > On Wed, Feb 15, 2012 at 12:36 AM, Laura Vertatschitsch >> >> > <[email protected] <mailto:[email protected]>> wrote: >> >> > Hi guys, first post. >> >> > >> >> > We are setting up a machine from scratch. The 2011 tutorials >> section >> >> > seems to indicate the all the machines were set up with Xilinx >> 11.5 on >> >> > machines running 64 bit Ubuntu. Are there instructions on how >> this set up >> >> > was achieved? Everything I read on the wiki seems to say that >> deviating >> >> > from the xilinx-blessed operating systems will result in bad >> news. We got >> >> > everything set up using the latest Ubuntu 11.10, Matlab 2009a, >> Xilinx 11.5, >> >> > by following the LINUX XPS page and introducing the simple >> case statement in >> >> > bee_xps to allow 11.5. We are getting some errors at the end >> of the compile >> >> > of tutorial 1 - but wanted to check if there was further >> documentation on >> >> > the setup that we could read first. >> >> > >> >> > Laura Vertatschitsch >> >> > Electrical Engineering >> >> > University of Washington >> >> > >> >> >> > >> >> >> >
