Lower Strata
2017-02-25
Restart of blog, in a different space and time!
I'm sorry for having had abandoned this blog, I forgot all about it. Didn't really have much time to work on stuff either, until now.
Please come and visit the new Lower Strata, at https://lowerstrata.net . Future articles planned are mostly about embedded / baremetal stuff.
br,
ak.
2010-09-01
Altera Quartus II Web Edition 10.0 with Lucid 64-bit, part 2
- sudo mount --bind /dev/bus /proc/bus
- sudo ln -s /sys/kernel/debug/usb/devices /proc/bus/usb/devices
czr@igor:~/altera/10.0/quartus/bin$ bash ./jtagconfig
/home/czr/altera/10.0/quartus/adm/qenv.sh: line 109: warning: setlocale: LC_CTYPE: cannot change locale (en_US): No such file or directory
1) USB-Blaster [USB 2-1.2]
020B30DD EP2C15/20
2010-08-23
Altera Quartus II Web Edition 10.0 with Lucid 64-bit
Had some spare time at hand and decided to revisit the idea of doing something with an FPGA devkit that I have (Altera Cyclone II, basic devkit). Last time, Altera didn't really support Linux in any way and using windows to run the huge blob of software (Quartus II v7.0) didn't seem like a good idea.
So, congratulations to Altera on their first Linux version of Quartus. Things are looking up finally.
As is common with other commercial/closed softwares, Quartus only supports a limited set of target distributions (the RPM -based usual suspects), so getting stuff running on Lucid on 64-bit contained some surprises (however, not as many as I feared when I started).
The main problem is in the installer itself. It wants to use a version of libXi (X input client library) that contains a function ( XESetWireToEventCookie ) which isn't available in 6.1 version of the library anymore (one that Lucid uses). Also, the installer is a 32-bit binary (which is to be expected).
Here's the exact error that happens when running the installer directly:
./altera_installer_gui: symbol lookup error: /usr/lib32/libXi.so: undefined symbol: XESetWireToEventCookie
So, step by step guide to getting the blob to work on Lucid 64-bit:
- Download the installer from Altera website (it's a shell script containing a compressed binary installer). Do not yet execute the script.
- Download the Karmic version of libXi for 32-bit. Do not install the deb.
- Extract the deb:
mkdir deb-extract && dpkg -x libxi6_1.2.1-2ubuntu1_i386.deb deb-extract
- Now, switch to the directory where you downloaded the Altera installer script. It needs to be extracted, but not yet run. Execute the following:
sh altera_installer.external.sh --confirm
- The script will ask whether it's ok to extract stuff, answer yes.
- Then, the script will ask whether it's ok to run the installer ("OK to execute: ./altera_installer_gui --gui?"). Answer No.
cd bin
cp ../deb-extract/usr/lib/libXi.so.6 libXi.so
LD_LIBRARY_PATH=$PWD ./altera_installer_gui --gui
- Enter
~/altera
as the install directory and/tmp
to hold the temp files. - The installer will take a lot of time downloading the stuff (at least it did for me, and it wasn't for the lack of bandwidth at my side). Sometimes it will also abort the download (because "it failed") and ask you to restart the install. The partial downloads are kept in /tmp so eventually your installation should complete.
- Once the installer has downloaded everything, you have the option to start Quartus. You might want to check that it will run.
The program can be now run like this: ~/altera/10.0/quartus/bin/quartus
(you may want to create a symlink or a menu entry, since those are not created on Lucid).
Interestingly enough, I was expecting to have to do a similar library copy for the installed Quartus, but it seems that it doesn't actually have the problem at all. Looks like only the installer has the issue. The software does run as a 32-bit process (verified via cat /proc/`pgrep quartus`/maps), but oddly, the installed directories contain a subdirectory with a name 'linux64
' with 64-bit versions of "stuff". I haven't had the time to investigate whether it would be possible to get a 64-bit version running as well (seems that Altera wants extra money for the 64-bit Linux version, while a 64-bit Windows version is still available as Web Edition. Sheesh).
Now, you have to understand that I know pretty little of FPGAs and even less about Quartus. So, while I can definitely say that the main program will start with the above instructions, I have no idea whether all the pieces actually work (like ModelSim and all that). I'll continue this post once I have some time to actually learn something about the huge beast.
2010-08-20
intel, linux and hardware monitoring
2010-07-25
Canon P-150 scanning timings
2010-07-24
Canon P-150 and Linux
- Linux drivers
- Support duplex scanning (a lot of paper invoices in Finland are printed on both sides)
- Support multiple page feeding without operator intervention
- Take as little space on the desktop as possible.
- Be not too expensive.
- Be relatively easy to find in Finland
- Using a gloss finished black plastic parts is bad. While it definitely adds to the wow-factor, having your fingerprints all over the device does not.
- The guides on the device are all plastic. While this won't be a problem for stationary device use, it might become a problem if you lug the device around or decide to pack it away from the desktop. This will probably end up breaking the guides in the end.
- You might need two USB ports to power the device. I've only used on USB port so far and haven't tested whether the scanning is any faster with more power over the USB.
- The deb and RPM files are for 32-bit mode only. While the 64-bit Linux distros support running mixed binaries easily nowadays, having only 32-bit drivers is an issue for SANE backends. The backend will be loaded via dlopen (as an .so file), so it can't be used in a 64-bit program (utilizing SANE). This means that you can't use the binary packages if you're running a 64-bit Linux (without doing all kinds of irritating operations first).
- The Debian packaging control file is done wrong. It uses temporary paths as the file members, and the end result is dpkg -L spewing out paths that just aren't there (most of the files are placed under /opt/Canon/ at install time).
- The source tarball is also interesting. It is a mixture of proprietary binary only code, pre-built binary components and source code. How nice.
- Retrieve the source tarball for sane-backends-1.0.19. This is the version that is mentioned in the somewhat terse README from Canon.
- Extract it in parallel directory with "cndrvsane-p150-1.00-0.2". Yes, it needs to be parallel, since the makefile rules within the cndrvsane use a relative path addressing (../../sane-backends-1.0.19).. How nice.
- configure and make the sane-backends first. Do not install. Also, my build din't actually even finish, but it doesn't seem to matter. The only thing that is necessary from this step is the sane backends config.h and the dependency files (courtesy of libtool, our "helper").
- Switch to the cndrvsane source directory
- run configure
- fakeroot make -f debian/rules binary
- This should result in the proper deb file that can be installed. The file list will still be wrong as per the original deb, but at least the architecture is mostly correct. Most of the files will install under /opt/Canon.
- Make a symlink from /usr/local/lib/canondr to /opt/Canon/lib/canondr . Based on stracing (with -f) scanimage, this is the path under which the backends are accessed for some reason and the symlink is not otherwise made properly (I was too lazy to fix the deb control files, and it shouldn't be my job).
- scanbuttond, which uses libusb to poll the button states using its own backend code which has been reverse engineered from USB traffic dumps. The project seems dead, or at least in deep hibernation. Needless to say it doesn't support P-150.
- kscannerbuttons, which uses --wait-for-button functions in existing SANE backends. Since the proprietary P-150 backend doesn't support this option, kscannerbuttons can't be used.