Booting your iBook G4 from a USB stick

So I spent the better half of the night trying to figure out how to make my iBook G4 boot from a USB stick. I have the Leopard ISO, but none of my DVD drives will burn Dual Layer, so I needed to use the USB route.

However, none of the nonsense I found on the Internet could give me proper instructions. The system itself doesn't directly support it (holding down option during power-on doesn't show it either).

So I had to dig into my OpenFirmware roots and do it the old fashion way. So here's the quick tip for the rest of you out there (hopefully Google will eventually pull this up in page ranks so it gets hit first and saves people time).

1. Plug in the USB device where you have copied your bootable system to (I do not cover this part since it's well covered already, google is your friend).
2. Power on your iBook and hold down Command+Option+O+F. This will take you into the OpenFirmware. Scary looking if your not a computer type person.
3. Once you see the screen go white with some text on it, you can release the keys in the previous step.
4. Type "boot ud:,\\:tbxi" and if you're lucky, it will start booting from your USB device. If not, continue on.
5. Type "dev usb0" at the little ">" prompt and hit return.
6. Type "ls". If you see something like "/disk@1", continue, else go to the previous step and use "usb1" instead.
7. If you get here and you haven't seen something like "/disk@1", then you're likely screwed, sorry.
8. Type "dev disk@1" and hit return, and then "pwd" and hit return again. You should see something that looks like "/pci@f2000000/usb1b,1/disk@1". You will use this in the next step.
9. Type "boot /pci@f2000000/usb1b,1/disk@1:,\\:tbxi". This is the device part you got in the last step after typing "pwd" with ":,\\:tbxi" added to the end.
10. Moment of truth, hit enter. You should now be booting into your USB drive. IT WILL BE SLOW SO BE PATIENT

This should also work on other PPC Mac's that don't normally boot from USB, such as G3s.

Cross compiling the Linux kernel from Mac OS X

So I picked up a 13" MacBook and have been fiddling around with it. I like it, sue me.

One of the first things I did (as any Linux developer would) was to install darwin ports. I noticed some interesting things in there. A few that I needed (git) and a few that completely surprised me (dpkg and apt).

One thing that was missing was a Linux cross-compiler. So I did what any self-respecting Linux developer on a Mac would do: I built one.

Don't get too excited. I've only built one worthy of compiling a kernel (which means no C library, no userspace, etc).

The result of my work is here (built on 10.6.3):

• http://www.swissdisk.com/~bcollins/macosx/gcc-4.3.3-x86_64-linux-gnu.tar.bz2
• http://www.swissdisk.com/~bcollins/macosx/binutils-2.20.1-x86_64-linux-gnu.tar.bz2
• http://www.swissdisk.com/~bcollins/macosx/elf.h

You may notice the extra elf.h file, which is needed in /usr/include/elf.h for some programs in the kernel to compile natively on the host (e.g. modpost). The gcc and binutils will unpack in /opt/local/.

In order to cross-compile, you will need to add a few things to your kernel make command line:

make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- ...

You may notice, like I did, scripts/genksyms/parse.c has a #include for malloc.h which is not on Darwin. You may safely delete that line.

Note that you must already have /opt/local/bin in your PATH. Using ARCH=i386 will also work and compile 32-bit kernels. One last point, the sources for gcc/binutils came from Ubuntu's Jaunty.

Happy hacking...

Oldies but goodies: libugci

So I went digging around my old software, and ran across some interesting stuff that doesn't get a lot of attention. I've picked out one in particular that I haven't heard much about in a long time, but I consider it very useful for people who love MAME: libugci

I had built an arcade cabinet a long time ago that was making use of a USB control interface called Happ UGCI. It allows you to directly interface real video game style controls (buttons, joysticks, trackball, coin door, etc) with a PC.

It was perfect for that I was doing, except that it sucked on Linux. Back then, I actually had to write some patches for the kernel to get it all working correctly (firmware bugs in the UGCI). In addition, much of it was not accessible via USB input layer, and so I wrote a library called libugci that took advantage of the HID interface to the board.

The board allows you to connect a real coin-door, and libugci+mame will convert that to coin-door events in the software. I always wanted to complete my MAME cabinet with a coin-door so I could make money off my friends :)

The MAME code has support for libugci built-in (thanks to my patches submitted all those years ago). Installing libugci, and recompiling MAME with this support enabled will make use of it. There are also some programs for accessing the EEPROM on the board, as well as mapping events from UGCI to HID keyboard strokes (in cases where you would want that as opposed to real joy/mouse events).

So if you're a MAME junky like I am, and need that extra bit of features that only the UGCI can offer, you can download the library from:

• Tarball
• git://github.com/benmcollins/libugci.git

Good luck and happy gaming!

Why Linux will (has?) hit a wall in popularity with normal users...

So this is one of the few times I decide to get political and/or rational. Most of my career has been spent on Linux. And while the gettin's good, I don't subscribe to the notion that Linux, as a desktop, will take over the World.

Let me make one thing clear. I do believe Linux, as a core, will succeed in many forms. On the server, on mobile products (where it is the core and not exposed directly to the user, a la Android).

So here's the problem as I see it. Too many choices. Yes, this has been beaten to death, and to some extent, many Linux vendors have taken note. Debian used to be a free-for-all where all of the choices were exposed to the user. People who used Debian loved the choices, but the fact isn't that they loved the choices, they just loved that their choice was among them.

If you didn't have a preference, for example with a Desktop environment, then choices are bad for a user. They didn't know how to pick one. So now, there is a default. That's great, but across many Linux distributions, even if the default is Gnome, the little nuances of each system will overwhelmingly differentiate the entire thing so that no Gnome desktop is truly the same as another distribution.

So why are choices bad? I want to take an example from a book I was reading recently called The 4-Hour Workweek. It tells of a watch company that wanted to advertise in a magazine. The watch company had many different styles of watches and wanted to put a full page ad that showed off 6 of them. The advertising executive said they should pick one watch and show off that one. To settle the dispute, they had two full page ads: one with the 6 watch layout, and the other with a single watch. Don't you know that the single watch ad out-performed the 6-watch ad by a factor of 6? Interesting...

So anyway, choices are bad for consumers. They would rather have one choice, even if it may limit them in some way. Apple figured this out when they almost went the way of the Commodore by making so many damn types of Macintoshes (when Jobs wasn't at the helm). Microsoft also learned this when they had an extensive list of Windows variants (Full/Pro/Home/Home-Pro/Server/etc/etc), but I don't think they've recovered from that very well.

Now on to the meat of the problem. Linux, too many choices...what can be done? Well, as a developer, not much. It's not our job to make these decisions. We are the ones that give all the choices. Drivers for every device, apps that do anything you want, themes, icons, documentation, hardware support. The real issue at stake is some company needs to break out of the "We're a Linux distribution" mold.

Let's take Dell's Ubuntu Linux offering as an example (I'm not knocking this effort, I helped start it when I was working for Canonical, it's a great offering). If a normal user somehow gets to the Dell Linux page, and they say "wow, what is this Linux thing?", they will surely go to Google.com and start checking. Bad? Hell yes. The huge amount of information, choices and decisions becomes quickly apparent to them. They start asking questions like "Is Ubuntu the _right_ Linux for me?" and "Should I try other Linux's as well" and "Why does Dell only offer Ubuntu?".

Indeed, these are good questions, but for which there is no answer that is going to take the average user from "I've always used Windows/MacOS and know how it works" to "I'm going to try this thing called Linux."

In my opinion, as unfortunate as it may sound, in the end, some company will deliver a product that makes no mention of Linux other than in the copyright attributions and source code, and will call it something completely different. Maybe they will call it Chrome OS?

Using your new Bluecherry MPEG-4 codec card and driver...

Now that the dust has settled and people are taking notice of the new driver for Bluecherry's MPEG-4 codec cards, here's a quick How-To for using it.

You will notice that there are two types of v4l2 devices created for each card. One device for the display port that produces uncompressed YUV and one for each input that produces compressed video in either MPEG-4 or MJPEG.

We'll start with the display port device. When loading the driver, a display port is created as the first device for that card. You can see in dmesg output something like this:

solo6010 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
solo6010 0000:03:01.0: Enabled 2 i2c adapters
solo6010 0000:03:01.0: Initialized 4 tw28xx chips: tw2864[4]
solo6010 0000:03:01.0: Display as /dev/video0 with 16 inputs (5 extended)
solo6010 0000:03:01.0: Encoders as /dev/video1-16
solo6010 0000:03:01.0: Alsa sound card as Softlogic0

This is for a 16-port card. The output for a 4-port card would show "Encoders as /dev/video1-4" and similarly for 8-port show /dev/video1-8.

The display port allows you to view and configure what is shown on the video out port of the card. The device has several inputs and depends on which card you have installed:

• 4-port: 1 input per port and 1 virtual input for all 4 inputs in 4-up mode.
• 8-port: 1 input per port and 2 virtual inputs for 4-up on inputs 1-4 and 5-8 respectively.
• 16-port: 1 input per port and 5 virtual inputs for 4-up on inputs 1-5, 5-8, 9-12 and 13-16 and 1 virtual input for 16-up on all inputs.

You do not have to open this device for the video output of the card to work. If you open the device and set the input to input 2, and close it (without viewing any of the video) it will continue to show that input on the video out of the card. So you can simply change inputs using v4l2's ioctl's.

This is useful if you want to have live display to a CRT and use a simple program that rotates through the inputs (or multi-up virtual inputs) a few second intervals.

You can still use vlc, mplayer or whatever to view this device (you can open it multiple times).

Now for the encoder devices. There's obviously one device for each physical input on the card. The driver will allow you to record MPEG-4 and MJPEG from the same device (but you must open it twice, one for each feed). The video format cannot be configured once recording starts. So if you open the device for MPEG-4 and full D1 resultion at 30fps, that's what you're going to get if you also open a simultaneous record for MJPEG.

However, it's good to note here that MJPEG will automatically skip frames when recording. This allows you to pipe the output to a network connection (e.g. MJPEG over HTTP) with no worry of the remote connection being overloaded on bandwidth.

However, this isn't so for MPEG-4. It is possible if you are too slow at recording (not likely) to fall behind the card's internal buffer. I was not able to do this writing the full frames to disk on 44 records (4 cards of 16, 16, 8 and 4 ports).

Unlike any card before this supported by v4l2, the Bluecherry cards produce containerless MPEG-4 frames. Most v4l2 applications expect some sort of MPEG-2 stream such as program or transport. Since these programs do not expect MPEG-4 raw frames, I don't know of any that are capable of playing the encoders directly (much less being able to record from them). You can do something simple like 'cat /dev/video1' and somehow pipe it to vlc (I haven't tested this), or write a program that just writes the frames to disk (I have tested this, most programs can play the raw m4v files produced from the driver).

However, since most people will record to disk, the easiest way is to write the video frames straight out to disk.

Now on to the audio. The cards produce what is known as G.723, which is a voice codec typically found on phone systems (especially VoIP).

Since Alsa currently doesn't have a format for G.723, the driver shows it as unsigned 8-bit PCM audio. However, I can assure you that it isn't. I have sent a patch that was included in alsa-kernel (hopefully getting synced to mainline soon). But this only defines the correct format, it doesn't change the way you handle it at all.

You must convert G.723-24 (3-bit samples at 8khz) yourself. The example program I provide in my next post will show you how to do this, as well as how to convert it to MP2 audio, and record all of this to a container format on disk for later playback.