Category: General Computing


Linux setup nightmares

So in that last post, I hinted that getting the user-programmable joystick working properly on Raspberry Pi’s Linux OS was, well, less than ideal.  Here’s just how non-ideal it was:

Windows:

  1. Download and install tools.
  2. Run tools and play around to your heart’s content.
  3. Walk around with a silly glow on your face.

Linux:

  1. Linux joystick configuration utility has a link on the manufacturer’s download page.
  2. Tool must be compiled on the Pi’s particular Linux release. (This is pretty common since Linux runs on all kinds of different processors, and this tool is not part of the “standard” OS.)
  3. Tool requires libhid library to compile.  Locate and download libhid library source.  Account must be created on a Debian archive site before download is possible.
  4. Libhid requires libusb and lib-usbcompat libraries to compile.  Locate and download libusb/lib-usbcompat sources.
  5. Libhid needs to be manually patched before it will compile properly.  Locate blog post from other unlucky user who, luckily for me, has already endured and documented all this pain, with the appropriate fixes.
  6. With libraries compiled and installed, now the joystick utility can be compiled.
  7. Discover another recommended manual patch, this one to the joystick utility’s source code, apply patch and compile again.
  8. Running the utility to reconfigure the joystick works successfully, except the joystick is dropped by the Linux kernel’s USB HID driver after reconfiguration, leaving it inoperative.
  9. Follow instructions from previous blogger to create manual scripts to allow manual re-binding of the stick to the HID driver after uploading revised configurations.
  10. Discover that the Linux kernel driver also filters out half of the valid joystick location values with any of the customized configurations.  Anonymous comment on previous blog indicates a line in the kernel HID driver that can be commented out to disable overzealous validation of stick’s output values.
  11. Download entire RPi Raspbian Linux kernel source.
  12. Modify 3 lines of code.
  13. Recompile entire Linux kernel with Adafruit’s virtual-machine kernel-o-matic. (A breath of fresh air, something easy in a tedious process).
  14. Install new kernel and cross fingers.  Luckily, it boots correctly and doesn’t brick the device. (If you’re attempting to reproduce my pain, make sure you choose the branch that matches your existing kernel!)
  15. Validate that joystick now functions properly.
  16. Discover that during some bootups, Joystick is detected as “second” joystick rather than first, causing failure to detect stick in rickety old emulator program.
  17. Research and create “udev rules” which allow particular devices to be forced to have specific names in the OS, so as not to make the rickety old emulator grumpy.

Linux:  It’s the way of the future, you know.

Advertisements

I’m late to the party, but I started building a retro arcade machine using a $35 Raspberry Pi as the computer. The various buttons, joysticks, and other bits of control hardware will likely cost at least 5-6x times that amount by the time the whole thing is done.

I’m doing the Linux setup and prototyping control layouts (more about that tomorrow) but I’m hoping my buddy Raman with the awesome wood shop will help build a real cabinet for it when we’re ready. The thing I want to do that’s different from most of the emulator builds people usually do is that I want the control panel to lift out like a fridge shelf and be replaceable. That way when you want to play a game like Tempest or Centipede that needed a spinner or trackball, you just replace the controls. The rest of the time you can have a typical one or two stick-and-buttons setup, but this way the cabinet doesn’t need to be a mile wide to accommodate all the controls at once.

At the moment, though, it looks more like, well, “3rdWorldCade.” But it works great. Thanks to Amazon for the flexible and sturdy “building materials framework!”

IMG_1101

IMG_1103

Today I received an antique in the mail.  A rather ancient SCSI CD-ROM drive, in an external enclosure, and an equally crusty 50-pin to DB-25 “Mac style” SCSI cable from SamplerZone.com.  It takes me back to the good old days of somewhere around 1993-1995, when I had boatloads of external hard drives in cases a lot like this one. But the good news: After hooking it up to my Ensoniq keyboard with the SCSI board I described in the last post, success! I can load lots of different sounds from CD-ROMs now.  It’s nice when things work the first time. OK, there was one little glitch – the memory expansion I installed a month or so ago turned out to be faulty.  After loading up sampled sounds I was hearing pops and clicks where I was sure there weren’t supposed to be any.  I was a little panicky at first that somehow the SCSI interface was corrupting the data or there was a noisy signal, but then I remembered that I’d never really tested the sample RAM after installing it.  I popped the factory SIMMs back in and all the noise problems immediately went away.  So it’s just bad memory from eBay. Phew.  Time to go see if I can get the seller to exchange it for a different set.

I needed to add some new storage to my server at home, which I recently upgraded to Windows Server 2012. The chassis has no room for new drives but it had several open PCIe slots, so I thought I’d just add a USB3 controller and a couple of external drives, shouldn’t be too hard?

As with most things PC it’s never as easy as it’s supposed to be. I Newegg’d a controller from SIIG that claimed to have a TI chipset, and a few 2TB external drives from Fantom, who I have a nice ESata drive from already. Things went well until the second day, when I realized that the drives were failing to show up only after warm reboots. If I’d power cycle them after the system was already up, or if it was cold booted, everything would be fine, but warm boot no dice. This was clearly a deal breaker for a largely unattended and remote managed system.

I tried everything. Bios settings, obscure registry flags, nada.

Today I decided to try the cheapest potential fix, a different controller. I made a quick run to the local retail hardware place, and found a Vantec card that did the same thing but with a NEC/Renesas chip. Went home, made the swap, powered up, and……

New problem! Yellow bang on the controller in Device Manager. Seriously? Hit the interwebs… It turns out that there is firmware in the controller chip that’s upgradable and a quick download from some random French website (why doesn’t the manufacturer post this stuff?) and luckily the problem was solved rapidly.

Thankfully, this was the end of the story- the drives now work normally under all conditions. I’ll be RMA’ing the TI controller back to newegg.

Now I have them set up with the new Storage Spaces feature as multiple virtual drives- some mirrored for safety, some striped for speed, and one with the ReFS file system for ultimate reliability. And all thin-provisioned: when the space starts running out, you just add more physical space to the pool and the space seamlessly grows to take advantage of it. Now that’s cool!

%d bloggers like this: