I'm Eric Anderson. This is session 504, FireWire. Thank you all for coming. We have no fewer than six demos today, so we have a lot of stuff to go through. I hope you'll enjoy it. Okay. In past years we've used this session to talk about how FireWire works in Mac OS X or even in Mac OS 9.

This year, Tiger's recently shipped, as Steve explained, lots of people are quickly adopting it. We already told you last year about FireWire and Tiger. Eric Anderson So this year we will have a quick recap, but we're going to spend most of the time in this session talking about technique. If you are developing for FireWire drivers, devices, applications, we have a lot of tools and ideas that you can use to speed up your work.

In fact, we even have some technique that you can use FireWire to debug other things. Even if you don't have any FireWire at all in what you're doing, you can use FireWire to help you debug. Eric Anderson And having gone through a bunch of demos of how that all works, then we'll wind up with a quick look at resources and where you can get this stuff. And we'll leave plenty of time for questions.

If you'd like to follow along in the session today, in some of the six demos, these are things you can run on your PowerBooks or iBooks. Our SDK 20 just went live on the web yesterday. You can download it. There's no access required. As long as you can get on the internet, you can go to Apple and download the SDK. So you'll have plenty of time to do that as I go through the overview and get ready for the sessions later. When you install SDK 20, it does not modify your system in any way. It puts everything in /developer/sdk20.

It will put some things there that if you run them, they may modify your system, but the SDK itself is harmless. So go ahead and install that, and then you can use it during these sessions. If you have a FireWire device with you, an iSight camera, an iPod, or your own device that you brought, that may be useful to you during the session if you want to follow along in some of the demos. So you could pull that out and get it ready.

You could even plug two Macs in. You could plug two Macs together with the IP over FireWire if you don't have any device. But two of the tools are useful even with no device at all. So even if you don't have something in hand, you may still want to get the SDK ready.

Some of the tools in the SDK are not completely safe. So if you've just done an hour worth of brilliant code writing, please save your work before you run the tool. But I'm going to run them all live. I'm going to do all six demos, and I don't think they're going to crash. So they're pretty good.

Okay, so while you're downloading the SDK, let's do a quick review of the basics. FireWire products have been shipping to consumers for 10 years. It's a mainstream technology. Sometimes people forget what's cool about it. How can anything be cool after 10 years? So let's just quickly look at the strengths. If you compare the FireWire port to any other port on your Mac, or most any other kind of digital device, FireWire often comes out on top. In at least one category, usually most of these categories, sometimes all of them. Power.

The Mac provides at least 6 watts, up to 15 watts of power on the FireWire cable. So you can run a high performance device like an iSight or an iPod. You can power a hard drive. You can power several hubs, repeaters, so you can go long distance. Power is useful. No other connector provides anywhere near that much power.

Speed. FireWire can move 800 megabits per second, and it does so very efficiently. Most other IOs can't go that fast, and the ones that do have very different characteristics than FireWire. Distance. You can go 100 meters on simple category 5 cable or on optical cable like we've shown several years with 1394B. And it's interoperable with 1394A and devices we've sold before.

So customers can hook your product up over long distances. You can wire stuff up around the home, wire up a lab or a classroom, use it for a music studio, a television studio, or even a medical or scientific or industrial application. Or maybe for safety reasons you need to put some distance between yourself and whatever's at the end of that wire. Distance, power, speed, these open up tremendous opportunities for really innovative devices.

Lots of them. Like USB, FireWire can hook up more devices than your customer's ever going to have. So that's a lot of utility you get out of that one port. Plus, on FireWire we have a lot of powerful tools to really help you understand what you're doing and move forward, and a lot of helpful source code and documentation too, and that's what we'll spend the bulk of the time on today. So here's like all of last year's presentation crammed into one slide.

Customer using a Mac might have several FireWire devices. Here we've pictured an iPod, a Mini actually, a DV camera, an EyeSight camera, and a Mac Mini. We'll come back to that one. They're all plugged into the Mac. The Mac has only one FireWire controller, so you see all those apps up there. All those devices and apps have to share that one controller. They're going to have to play nice.

They don't want to. They just want to do their own thing. IO FireWire family is a service in the kernel that makes everyone share. It lets them each do their own thing. It routes packets. It loads drivers, so they don't have to know about each other. Everyone can cooperatively use that single interface.

Sometimes an application talks directly to IO FireWire family, as shown on the left. Some of the tools that we'll show later today do just that. We also provide with the family a series of protocols, services, and drivers for common classes of device to help them talk to FireWire so you don't have to reinvent the wheel. So moving left to right, first we see SBP2, the Serial Bus Protocol.

This is a protocol used by hard drives, printers, scanners, cameras, anything that is a storage or storage-like kind of device is likely to use this. So here iTunes is loaded using the SBP2 layer in order to talk to the iPod that was plugged in and synchronize your music.

Next over is AVC. This is a totally different protocol for audio/video devices, either consumer devices or professional devices. So here iMovie has loaded. It's using AVC to talk to that DV camera. The next one over is a driver called IIDC, the Industrial and Instrumentation Digital Camera. It's a spec from the 1394 Trade Association for a raw video camera like the EyeSight, where there's no compression. That has a fairly different need than a consumer electronics device, so there's a different kind of driver for it, and we provide that built in. So that's talking to the EyeSight so that iChat can show live video. Finally, on the right, the Internet Protocol.

FireWire is a first-class network interface on Mac OS X, and in Tiger it's turned on by default. You can get IPv4, IPv6, any internet protocol that's been invented over the past two, three decades can run over FireWire. And that's what the Mac Mini is doing there. I'm not quite sure what it's serving up, but we're getting to it from Safari at the top. And whatever it's doing, it's using Bonjour for configuration and service discovery. Again, FireWire is a first-class interface, so all the Bonjour services are naturally available. You can just plug two Macs together and set up Apple Share or any other internet-based service that you want.

Notably, the Mac Mini has 100 megabit ethernet and 400 megabit FireWire. So if you want to run an internet protocol and you're in a hurry, FireWire is the fastest way to get in or out of the Mini or the iBook or other products. So there's a lot of potential there to leverage decades' worth of internet-based protocols on FireWire.

There's a couple things that wouldn't fit in that slide, and which are fairly new. In our SDK 20, We have something called the AVC Video Services, or AVS. This is a rich framework of services for writing applications that are going to talk to, discover, control, stream to or from AV devices. This is usable for writing applications. It supports both MPEG-2 and DV, both in and out, and also the higher end formats like DVC Pro HD and HDV.

It discovers, controls devices in a uniform way, and also it maintains connections to devices. So when you've started streaming in or out of various devices, even if the bus is reconfigured or other changes happen, AVS will keep track of that and make sure your device keeps streaming the way it's supposed to. That's done with standard protocols. There's no reason you should have to reinvent that in your app, so we do that in AVS.

It also provides support for virtual devices. We've got another slide on that that's pretty exciting. AVS is used by our own apps, Final Cut, iMovie, iDVD, as a way of moving stuff in and out. So it's very robust, it's production ready. Take a look at it if you are considering this kind of app. Now, you should also consider QuickTime. Especially if you're moving video in or out, that's what QuickTime's good at. It's your choice. If you choose QuickTime, it's a bit higher level.

You won't be tied to FireWire. That may be good. If you choose AVS, you may have more precise control over what you're doing on FireWire. So take a look at both, consider your needs, and pick the one that's best for you. AVS is available in SDK 20 as sample code.

AVS enables virtual devices. This is an idea like target disk mode. When you put your Mac in target disk mode, it is pretending to be a FireWire hard drive. It's using software and its own FireWire interface to pose as something else, and that's useful, because you connect a second Mac and access it like a hard drive. Well, you can do that with things other than hard drives. If you go out today and buy a high-def TV, there's a good chance you'll find a FireWire port. It may be marked iLink or DTVLink or 1394, but they're all the same.

These TVs want to discover and control FireWire devices, at least the devices that a TV expects to find, such as a digital VHS deck or an AV hard drive. So the TVs provide user interfaces for doing this. The TV will also control a Mac if the Mac is posing as one of these things. And that opens up a lot of possibility. So let's walk through how that would work.

Here's your shiny new HDTV. And here's your shiny new Mac. So on the Mac, you run an application. You don't need to reboot like with target disk mode. In target disk mode, only one thing can talk to the disk, so we have to get the OS out of the way so the TDM can use the disk.

Here, there's no need for that, so you can just run an app in the finder. The app will pose as something, and we will provide the app with some content. In this case it's going to be a virtual digital VHS deck. So we'll give the app a folder full of movies representing what's on the tape.

Plug the two together by FireWire. What happens? You can go to the TV now and press the input select button. The TV has discovered the Mac over FireWire and asked it a few questions, and for all the TV knows, it's a DVHS, so it's listed there in the input select menu. Pick that. Now the TV is all ready to play a virtual DVHS. It doesn't know it's virtual. It's all ready to control and play a digital VHS.

Take the remote for the TV, point it at the TV, press play. What happens? The TV knows it's controlling a VHS, so it sends that command over FireWire into the Mac. The application on the Mac understands what play means, takes the movie, and starts streaming it back to the TV. Now you're watching content from the Mac on the TV. Hopefully you've recorded some iTunes or iPod commercials on your tape.

Notably, you didn't have to touch the Mac. You can run this thing once, and then you can drive from the TV. You could drive a lot of things from the TV. There's all sorts of creative things you can do through a TV or through another device by implementing virtual devices in the Mac.

You can prototype something that doesn't exist, you can experiment to learn what the TV can do, all kinds of stuff. This is in our SDK, so try it out. You wanted to buy a new HDTV anyway, right? Try this out, I think you'll have a lot of fun with it.

In AVS there is a generic virtual tape subunit, it's format independent. What does it do? It runs as an app. It asks, well you can call it from an app, it asks the Mac to publish an AVC config ROM so that tells anyone who's looking, like the TV, hey, I speak the AVC protocol. Furthermore, it tells the Mac to respond to subunit info that says, why, yes, I have a DVHS subunit, or a tape recorder subunit, whatever the format is.

As commands come in from outside, FireWire routes those back up to your app, and the app can interpret play, stop, record, rewind, whatever. The virtual tape subunit is generic, but there's also a virtual MPEG tape player that wraps that up with AVS's capability to stream MPEG in and out, and that works a lot like what you saw on the last slide. For example, when you press fast forward from the TV, the app skips ahead 30 seconds in the stream and finds a frame boundary and starts streaming from that point. So it acts like a very responsive VHS deck, or maybe more like a TiVo.

Also in AVS is a virtual music subunit. A music subunit is not actually a sound device, it's a sound processing device. So it's a way for a device like a mixing console or a synthesizer to express over FireWire all of its internal capabilities. It has a filter, a chorus, a reverb, a mixer, whatever. You can route those and plug them together and discover them through the AVC music subunit.

With a virtual one, the Mac can do all these things. And so here too, you can implement a lot of creative things without actually making any hardware, just by coding them up on the Mac. You've got a multi-gigahertz G5 to work with. You can do a lot of things with audio. And this plays together with Apple's FireWire audio driver to actually move audio in or out of the box.

Okay, that's a recap of where we are, what FireWire basically does in Mac OS X, and some highlights of recent new stuff in AVS. Now we're going to totally change gears and look at a bunch of techniques and demo for using FireWire and working with FireWire devices. First, we'll start with real FireWire devices and drivers, and then we'll move on to everything else.

The first is FireBug. Many of you have used this. If you have a Unix background, you may know EtherPeak, which is a decades-old command that takes Ethernet packets and prints them out in the terminal in a sort of engineer-readable format. FireBug is similar. It runs in a minimal GUI, but it takes every FireWire packet and prints it out in a format that should be readable.

This is very helpful when you're trying to debug a device or find out what's happening on the bus, because you can see all the traffic in order with timestamps all explained. It has various capabilities to filter and display selective packets. It has triggers. It has a general capability to decode common protocols. So if you plug in an iPod, for example, FireBug will decode the SPP2 commands, the logins, the orbs, the page tables, and show you what each packet means.

So you're not just confronted with pages and pages of hex. You have pages and pages of hex with notes. FireBUG can decode the internet protocol, at least to some extent, and AVC commands, like subunit inquiry, and those various different subunit types, and a lot of the tape player commands.

FireBug can display the bus topology, can poke around in the PHY, we'll cover that more later. And it has some basic ability to try some hands-on debugging, to send simple packets. Finally, it runs in real time. Most analyzers are sort of capture-based. Something happens, you capture it, then you go back later and look at it. FireBug has a long history buffer, so you can do that, but it runs in real time, so you can get a human-time feeling for what's happening, in what order, and how fast. So I'd like to demonstrate some of the things you can do with Firebug.

So let's go to demo one. FireBUG requires a special PCI controller. Unless you have a blue and white G3 Mac, you'll need to find a PCI card or Cardbus card with the right hardware on it. And there's information in the SDK about what kind of hardware is suitable.

So FireBUG runs in this sort of minimal GUI window. What's on top is a bunch of counters showing the kinds of packets and their number. The center area decodes the packets as they go by, and the bottom area is for typing in commands. The first thing I'm going to do is ask FireBUG to color the packets it sees according to the packet type, whether it's a read or write, quad lit or block or whatever. I'm going to type TCODE, sorry, color. T-code.

You can't do this on your PowerBooks unless you happen to bring a FireBug card, which if you're lucky, good for you. The next demo you'll be able to follow along. Now nothing's happening yet, so I'm going to take the FireWire cable from the The Mac's normal FireWire interface, and plug that in, and then you'll see some things happening.

know if you can read that but the highlights are, there were a couple of bus resets as the bus reconfigured. Firebug drew a simple ASCII picture of the bus topology so we can know who's on there and then it showed the packets that were being sent on the bus.

And just from the color you can see they were all pretty much the same. What happened is on this bus there's one Mac, one hub, and Firebug. The hub and Firebug are both passive but the Mac is active and the Mac is sending out packets to the other two saying, "Who Who are you? What do you do? Are you a HDTV? Neither FireBUG nor the hub is answering, so all we see are these pale yellow packets that indicate the MAC center request, and there was no response. I'm going to plug in this camera and it will respond so you'll see things play out a little differently.

Okay, now there's two colors of packets going by. The Mac is sending out requests, and the camera is responding to them. Not all of the requests went to the camera, though, so it's not perfectly matched. And toward the end, you see a third color has appeared. These are write packets.

The Mac has discovered the camera and has loaded our iIDC driver. And now that driver's configuring the camera by poking values into its registers, telling it to get ready in case we want to use iSight, which is, in fact, already running. So by coloring the packets, you can very easily get the gist of what's happening, and that can help you focus in on what specifically you want to look at.

So I'm going to ask EyeSight now to show the video from the camera, and there were some more commands to tell the camera to fire up. And it's now doing that. And like every year, you're all sitting in the dark, so you can't really see yourselves. I'll just point the camera down there at the Mac, so you can see what's going on.

Now, by default, FireBUG does not show the isochronous packets, the real-time video packets from the camera, because there's a lot of them. We can turn that on. This says to add that T code to the list of ones that are being displayed, T code on A. And now the display is flooded with these isochronous packets. FireBuG can snoop 8,000 packets per second and it's trying to display them, but it's a bit much to look at, so that's off by default, so we'll turn it back off.

Okay, so we used FireBUG to see the camera get discovered and to see its basic operation, but we can do considerably more. I've done some homework on this particular camera, and I know what its internal registers are like. It has a lot of registers for doing various things.

I'm going to ask FireBug to show me a recap of the bus topology, and from this I can see that the camera is node zero. I happen to know that there's a register in the camera at a specific address, so I'm going to use FireBug to read that register by typing qread for quadlet read, and then the address,

So it says that the value in that register is 82000040. And that means something to me. This is the one I'm looking for. Having confirmed that it's there and I can access it, now I can stuff a new value in there.

This register is the zoom register in the camera. The camera actually has a motorized zoom. So as soon as I send this packet, hopefully, you'll see the camera zoom in tightly on the display, which should go totally out of focus. There we go. Now, normally you'd write a driver to do that. You'd put a slider in iChat or something.

But before you go to all that effort, you'd like to know that it works. Maybe you think it doesn't. FireBug lets you go straight to the device, talk to it on your own terms without any layers of stuff in the way, and poke around. So you can try stuff like this out really easily and conveniently.

And this should put it back. There we go. Okay, so that's the basics. You can do a lot of stuff like this. It's worth tracking down the hardware so that you can do this. All of our key developers are using this. Okay, let's go back to the slides.

So that was Firebug. The next topic is Firewire Busy Bus. There's a saying, it is better to give than to receive. Firebug receives. Busy Bus gives. Busy Bus generates packets on the bus. By default, it generates random packets. That may sound kind of useless. Your device probably isn't going to respond to them.

That's okay. What it does is it simulates activity. If your device has been plugged in with other devices that you never thought of, they might cause packets like this. If your device, your driver, your app works properly with all this extra traffic, that's good. That's customer calls you probably won't get.

But it's not always random. You can adjust it in a variety of ways. You can make it very specific. Also notably, Busy Bus can run on any Mac that we sell today. It uses the ordinary OHCI interface. This is a tool that you can run here. You're not likely to see anything interesting happen, but you can try out the controls.

This tool, however, could be unsafe. It touches the hardware directly. You'll see it should work here, but please do save your work if you're going to run it. So let's go to a demo of Busy Bus and see the kind of things that it can do. And that demo is on number two.

Okay, there's Busy Bus. You can see on the left is a quick summary of the FireWire connection on the Mac, which interface is being used, some information about the PHY, we'll talk more about that later, and the connection status for each of the ports. Here we can see that we have an 800-capable Mac with three ports. Eric Anderson On the right are controls for the kind of traffic that's going to be generated, and selections for address ranges, and speeds, and packet types, and so on.

Okay, so I'm going to press the run button. And Busy Bus gives a small synopsis down there in the bottom of what it's doing. It's sending various different kinds of packets. To really see what's going on, though, we should connect FireBook. So let's switch over to demo one on the display, and FireBuG's still running there.

Here you can see what Busy Bus is really doing on the bus. I left the color on deliberately. You can see it's sending quite a variety of packets. In fact, it's doing so with ever increasing intensity. Busy Bus ramps up and down over time to try to create the most interesting mixed traffic on the bus. Now while you're watching in FireBUG, I'm going to turn off some of Busy Bus's options, and you'll see that the colors start to decrease.

Okay, I've turned off everything except quadlet read requests. So now the display is all these pale yellow packets for quadlet reads heading out to random addresses on the bus. But you can see there's a few bright yellow packets in there. This demonstrates how the color feature can be really useful. Those might be quite hard to see without being colorized. So what's going on? Let's actually stop the test and take a look.

Okay, there's one. I left the camera connected. Busy Bus sends requests to random addresses, and from time to time it manages to hit the camera as its destination with this read. The read goes into a 48-bit address space, which is also randomly chosen. The camera has a lot of registers, but it doesn't have 2 to the 48 registers.

So most packets won't make any sense to the camera. And in FireBUG, you probably can't read it, it says, response address error. The camera responded to a packet, and the response means, I understand you're talking to me, I have no idea what you want. FireBUG shows that. If that happened when running iChat, that might be a good clue that something's wrong with this camera. Here, in the case of BusyBus, we sent it a random request. It's not surprising it couldn't handle it.

Maybe we want to stress the camera and see how well it can deal with these things. Let's switch back to demo two and I'll show you how to do that. I'm going to tell Busy Bus to send packets only at the 200 megabit rate, and I'm going to narrow down the range in which it's sending.

The camera happens to be node 3 at the moment, so we'll tell it to send all packets from a range of low of 3 to high of 3, meaning only 3. And we'll narrow down the destination address from an almost 48-bit range down to a single address. This address is the high 32 bits of the serial number in the camera.

Okay, so let's switch back to demo one and we'll see what's happening in FireBUG. Now you can see every packet's going to the camera and the camera is responding to every packet, because I've narrowed the range down. You can also see that every response is the same, 001124FF, which is the high 32 bits of the camera's serial number.

As this test runs, as Busy Bus steps up the intensity of the test, Well, the camera's doing great today. Usually the camera falls behind and starts responding to only some of the requests that you send it. Today it's having a good day. This is a technique that you can use to stress your device.

Maybe your customers aren't normally going to hammer your device with this many incessant requests, but you can adjust Busy Bus until you find the point where your device starts to struggle. And then when you know what that is, you can compare it to your expected user scenario and find out how close you are.

Are you really running at the edge of your limits, or do you have lots of margin to spare? Eric Anderson So it's a good tool for exploring what your device does in both normal and stressful situations, and finding where the boundary between those is. Okay, so that's Busy Bus. Let's go back to the podium machine.

Next up is FireCracker. If you've got the SDK ready and you've found FireCracker, this one's completely safe. It cannot crash your machine, so go ahead and open it up. I promise. FireCracker is a configuration ROM viewer. It's like the P-list viewer. It's a specialized viewer for specialized kind of information. Every FireWire device has a configuration ROM that says what that device does. It says what protocols it speaks, like it speaks SPP2 or AVC.

When you plug in a new FireWire device, the first thing we do is look at the configuration ROM to try to figure out what driver should we load for your device. And when you're on day one with a new device, that's often the first problem people run into is, the Mac doesn't seem to recognize my device. Well, use FireCracker to take a look at your configuration ROM and find out what we think your device is. This is a good starting point to see if your ROM makes any sense and to see if it's something we're going to understand.

FireCracker uses normal user space APIs. It does not touch the FireWire hardware directly. It's completely safe. Even if your device isn't having any problems, please try it out with FireCracker to see if FireCracker has comments about your ROM that might represent problems you'll run into in the future. So let's look at a demo of FireCracker. And that's going to be on demo one.

So I'll open up FireCracker. And I left several things on the bus, and the first one it found is a hub that didn't respond, so it says timeout. I will switch that over to something else. Okay, now FireCracker is looking at the Mac itself. This is the configuration ROM that the Mac is publishing to any other device that wants to look. And so you can see, if your eyes are good, that the config ROM says it's a Macintosh, it's made by Apple Computer, it's got various subunits.

Here's the bus information block. Every device has this. That's where the serial number is. Here's the root directory. This says it's a Mac. It's made by Apple. And below that are unit directories. For example, on this Mac there's two, because it's running Tiger. These two unit directories indicate that the Mac supports the internet protocol, IPv4 and IPv6. And FireCracker knows what they are, so in the lower right you can see it's decoded that and even called it out in bold to get your attention.

FireCracker has three ways of looking at config ROMs. The first way, what we're doing here, is we're sending quadlet reads to a device just like the family would. And we read the ROM a quadlet at a time, hierarchically, and parse it out. That should work for any device.

But the family already does that, and it puts all that information in the I.O. registry. So another thing we can do is view config ROMs from the I.O. registry. This should give you the same answer. If they don't, it's a good sign that either you or we have a bug.

So now we're looking at the Mac through the I/O registry. This generates no traffic at all on the FireWire bus. We're just looking over the shoulder of the FireWire family to see what it sees. And here, fortunately, we saw the same thing we were expecting. The third choice is to decode a file.

If you're making a new FireWire device, you probably have the config ROM in a .c file somewhere and you flash it into the device. Well, if you're doing a trial and error process trying to get something that the Mac can understand, this may be time consuming. Flashing a device may involve plugging and unplugging lots of special debug cables.

Just take your file and put it in FireCracker and see if we can make sense of it. So for example, I have a simple config ROM here just expressed as a static and C as a bunch of hex quadlets. I'll take that file and drag it onto FireCracker. FireCracker will pick out the quadlets, decode those as a config ROM.

Here we can see FireCracker actually found something to comment on. It says that the checksum is not correct in this config ROM. Mac would actually let that slide, but this might cause an interoperability problem in the future, so this might be something you want to know about. Otherwise, we can see the config ROM has a normal bus info block, a root directory, and a single unit directory that says it's an AVC device. This is the TA standard AVC config ROM as a starting point, so that's why I had it lying around in a file.

You can decode other kinds of information as files in FireCracker. For example, when we get a trouble report from someone who's not nearby, we often ask them to do this, to say, "IoReg -lx w0" and send us this file, which can be fairly large. There's a lot of info in here, but there's also a config ROM in here. I'll ask Terminal to find it by knowing that it has device ROM in it. There it is.

So we can just pick this. Oops. We can just take that config ROM and drag that into FireCracker, and it will decode that. - This is actually the Mac's own config ROM that was found in IRWedge, so it's the same one that you saw before. So we've tried to make this really easy, convenient to use. You can plug devices in, decode them, or just take it from text files. There's also some built-in config ROMs. So if you have it running on your machine in front of you,

Okay, that is FireCracker. So we'll go back to the podium.

Next is FireWire Plug-O-Matic. One of the most challenging things in a device is correctly hot plugging and unplugging, and not crashing, or leaking memory, or failing to load, or having a race condition. But sitting there and plugging and unplugging a device can be kind of tedious, and it also wears out your device. We have an application that's a skeleton key tool, so this one could crash if you run it. It touches the hardware directly, and it turns the PHY ports on and off to simulate plugging and unplugging a device.

It does not turn off the cable power. There's no way to do that in software. So it's not exactly the same as plugging and unplugging, but from the Mac's point of view, it's very close. The Mac sees the device come and go. The device, if it remains powered, may not have quite the same experience. So let's do a quick demo of that and see what you can do with that. And that's on demo two.

Despite the fact that I'm getting demo one ready over here. Okay, I'm going to run Plug-O-Matic. Like the other tools, Plugomatic gives a summary of which FireWire interface you're using. So if you've added a PCI card or a CardBus card, you can pick to use that one here.

And a summary of the port status. Now I'm going to have to plug a few things together to make this work. I'm going to use the EyeSight camera and have it be plugged and unplugged from the other Mac so that we can see I chat reacting to the camera's appearance and disappearance.

I believe I've got it. Okay. Plug-o-matic says it's not ready to run yet because it sees multiple things plugged in and it's not sure which port it should be plugging and unplugging. So we'll just configure that. - We'll turn on expert mode. And we'll tell that it should plug and unplug port one, 'cause we can see on the left, the port one has a connection at S400, so that's one of the active ports.

Turn off a few checks here so that it doesn't complain too much. : I'm going to click run, and it immediately disabled port one, which had the effect of unplugging this camera from the other Mac. After a period of time it will re-enable it. Let's switch over to demo one and we'll see what's going on.

Here on demo one, we're running iChat and it's getting live video from the camera. There, it stopped. The Windows says no camera. As far as the Mac is concerned, the camera was unplugged. Now it's back again. Plug-o-matic can do this all day long. So you can see iChat's doing just fine with this.

But we might be leaking memory after a few hours. Maybe it will crash for some reason. I hope not. But you should try this with your devices. What could be more painless than to just leave this running and go get lunch? So, it's another tool that allows you to experiment with your FireWire devices, stress them out in ways you might not have tried before, and see if they're really robust. Okay, let's go back to the podium.

That's plug-o-matic. We're doing pretty well now for these tools that I said might crash, right? What a segue. These tools, except for Firecracker, are based on something called the skeleton key. It's an ability that allows an application to push aside the FireWire services and touch the FireWire hardware directly. Normally this is really bad. Remember what I said about all the drivers, apps, and devices having to play nice and share? This is the opposite of that. It pushes them all aside and takes over.

Why? The family doesn't do these kinds of things. The family doesn't turn off ports. The family doesn't send junk on the bus. The family doesn't snoop the bus. These things can be done most easily if an app can just get control and do what it wants. That's enabled us to spin out lots and lots of these useful tools quickly. This is powerful, but it's dangerous.

It's like dropping a running kernel into GDB, right? That's not something you'd do if you hadn't saved two hours of work, but it's an incredibly useful technique for debugging certain kernel problems. They have their strengths. This is not suitable for customers. Please don't direct customers to do anything like this. This is for you as developers. As you can see, there's a lot of powerful things you can do based on this.

Generally speaking, the tool wants to put the family aside because the tool just can't coexist with the family. The family may be trying to scan the bus, optimize the bus, load drivers. In many of these cases I had a tool running on one Mac and FireWire running normally, like iChat, on another Mac. If both Macs were trying to talk to the camera, that's different from what you're trying to test. So the tool puts it all aside, the tool becomes very passive. So you probably want a dedicated Mac or a dedicated PCI card in the Mac to run this tool.

Another one, FireStarter, uses the same decoding display as FireBug to show the bus topology, but it can run on any Mac we sell today, so you don't need to get special hardware. That's in the SDK. I'm not going to demo it here, but you can come Thursday to our PlugFest and see it there. Hopefully you'll see lots of well-behaved FireWire devices all coexisting on one bus, and a big full display in FireStarter.

First of all, I mentioned the PHY earlier. What exactly is the PHY? I talk about this every year, I've never managed to get this slide in, finally it's here so I can explain this. A FireWire device like the Mac has its FireWire separated into two parts in the interface.

On the left we have the link. The link is the bigger of the two. It's more complicated. The link is what sends and receives packets. The link knows what a packet means. It has the host bus interface, the PCI controller, it's got DMA and FIFOs for moving packets around. The link understands addresses. When you send a packet, a request to a config ROM, the link says, oh, I know what that is, I know how to respond. The link does packet checksums.

The link acknowledges packets, like response address error that we saw earlier. It said, I don't know what you're talking about, even though I know it's for me. That was the link. The link is where the notion of isochronous is. The link has a timer, the link keeps track of time, it says now is the time to send a real-time packet, so iSight, send your packet.

The link is primarily software driven. It's not going to do much until software comes along, turns it on, configures it, gives it some programs to execute. That being done, the link is somewhat autonomous, but software still has to get it going. In comparison, on the right you have the PHY. It's the smaller of the two.

The PHY is where you actually have serial bus. The PHY has the clock, say 400 megahertz on FireWire 400. The PHY serializes and deserializes packets. It has a little private interface to the link called the PHY link interface. That's a parallel interface. As packets come down from the link, the PHY streams it out bit by bit, or as they come back in, the PHY reverses that. The PHY is where the low voltage differential signaling is. The PHY actually wiggles the wires up and down to say this is a 1 and this is a 0.

The PHY performs arbitration. When the link wants to send a packet on the bus, it taps the PHY and says, "Could I please send a packet?" The PHYs all talk amongst themselves and decide who gets to send the packet. When it's finally our turn, the PHY tells the link, "Okay, go ahead, send your packet. Everyone's listening.

Now's a good time." And the PHY acts as a repeater. A packet comes in on port 1, the PHY will repeat that packet out port 2 and port 3 in most cases, and all the way to the address and decide if it cares. The PHY just repeats. There's no routing, no switching, no buffering, things just flow right through the PHY.

These two can be integrated into one piece of silicon, like is done in the EyeSight camera, but they're still separate functions. By the way, in a hub, you'd have only the PHY. So any device will have a link except a hub. The hub just has the PHY, because all it has to do is repeat packets. There's no one there to talk to.

The PHY is almost completely autonomous because what it's doing is basic. It just repeats stuff and arbitrates. Still, it has a few registers, it can be configured, and the registers also give some clue of what it's doing. So, for debugging and bring up, you may want to see what's inside the PHY. So we have a tool for that, PHYTool. Just like FireCracker is a specialized browser for config ROMs, PHYTool is a specialized browser and editor for PHY registers.

This is most useful for debugging port connections. If you plug in a device, and not only do we not load your driver, but FireCracker says, I don't even see the device, you may want to go to PHYTool to try to figure out what's going on. And it has a built-in copy of the 1394 specification for these PHY register fields, which can be pretty cryptic to help you figure out what you're doing and what you're clicking on. So, let's take a look at that. And that's going to be on demo two.

When I run PHYTool, you can see it looks similar to the others. On the left, there's a summary of what controller, PHY, and ports we're looking at. And on the right, there's a matrix of registers that looks just like what's in the spec, including these binary numbers. If you don't like those, just click on them, they'll change into decimal. Each register in the PHY is 8 bits wide. Some of them are read-only, like our node ID, which is called physical ID in the spec. We're node 0 right now.

We're not the root. The root bit is zero. But PS is one. I don't remember what PS is, but I'll move the mouse over it. And then at the bottom in the panel we see it says cable power active. So the PHY is telling us that as far as it's concerned, the cable power is okay on FireWire right now.

Some fields are writable. For example, the IBR causes a bus reset. Oh, this is a good demo. This PHYTool is still connected to this Mac where the family is running. You can see the second field in register one here is gap count. That's a tuning parameter for the bus. Every time there's a bus reset, that goes back to 63 as a safety net in case new devices were added.

And then the Mac will notice that it needs to be tuned, and the Mac will tune it. So I can click on IBR to cause a bus reset. You see it changes to 63. Within a moment it changes back to 7 as the Mac tidies up. We could do that all day long, and the Mac's going to keep tuning it back to 7.

So you can see it's very hands-on. This is a good way to learn about the PHY. Just open this up, move the mouse over each one, find out what these things do. It's also a good way to debug. There's nothing you can do in here that's going to damage anything.

You might get your device disconnected, but you cannot harm the PHY by poking around, so feel free, give it a try. This is a skeleton key tool. You can run it on your iBook or PowerBook. If there's a remote chance it'll crash. Again, I think we're five for five now. Doing well. So let's do an example of what you might use this for to debug a real problem.

So I've been having some trouble with my FireWire disk drive. I plug it in and it doesn't seem to show up. Let's see if we can figure that out. Here it is. This is a fake demo, so no slight to the folks who make this drive if they're here.

PHYTool's showing on the left, no ports are connected. If we look under port summary over here, port zero, one, and two, they all say child, but that's just a default. They don't say connect, so nothing's plugged in. When I plug the cable into the hard drive, We see port zero now says child, connect, S400, DS, and fault. I hope you can read this.

That fault there is a good indication of what's gone wrong. A PHY to PHY communication problem has happened. This has nothing to do with configrom, or drivers, or Mac OS X, or anything. The PHYs just are not talking to each other. So I get out my oscilloscope, I poke around, I look at the spec, I figure out why they're not talking, I eventually find out that the problem is the drive is turned off. So we'll turn the drive on, and problem solved. That's the first trick in the book.

Fault has gone away, PHYTOOL says child, connect, receive OK, S400, DS. We have a data strobe, FireWire 400, connection to the drive, and it's perfectly stable. So, slightly contrived example, but very accessible, PHYTOOL is your first line of inquiry into PHY connection problems. Now we can do a little more with PHYTool. PHYTool here is showing you the PHY inside this Mac, which is a G5 tower. And so it has a three port PHY. We can see here it says it's bilingual, three ports up to S800.

We can also view the PHY registers in a remote device, like the hard drive. The PHYs can exchange a very primitive packet to access registers. So from this menu, I can see there's two PHYs on the bus. This is node 0, which is a TI-A 2-port PHY, and node 1, which is a TI-B 3-port PHY. That must be the MAC. It's also noted over here, the MAC's node ID is 1. So the drive must be node 0. So let's pick that. Now we're looking inside the drive.

And a variety of things changed. The drive has two ports rather than three. The drive is 1394A, so its PHY is missing quite a number of registers down here that were in the Mac. Let's go back to the Mac. See a bunch of additional registers appeared for FireWire 800.

Looking in the drive, they're not there. We can see that the PHY in the drive was made by Texas Instruments. We can see that it claims to be two ports, which is good. And we can actually see that we're plugged into port one. Most of the time you wouldn't care, but these aren't numbered. I didn't know which one was port one, now I do. That may be helpful.

So you can see PHYTool gives you some very low level, but very easy, access to some stuff that otherwise is quite mysterious. So give PHYTool a try, plug in your device, see if you can find out whose PHY is in it. Some really old devices like camcorters don't do this protocol, so they may not answer, but many modern devices will. Okay, that's PHYTool, so let's go back to the podium.

Okay, lots of things that you can do with FireWire to debug FireWire to try to get your device working. Here's some things you can do even if you don't care about FireWire. If you're writing an audio driver, if you're writing a USB driver, if you're writing anything in the kernel, you can use FireWire to help debug it. The simplest is FireWire K printf. If you've ever debugged in the kernel, this is the oldest debugging technique in the book, you use printf to say what you're doing. You keep doing it until it breaks, and then you look and see what happened.

Traditionally, printf in the kernel, kprintf, goes to the console. That could be a terminal window, that could be the screen itself, it could be a serial port, or it could be a FireWire port. Good luck finding a serial port on one of our Macs today. FireWire kprintf, you install a KEXT, and you set a boot arg, and all kprintfs go to FireWire automatically. You don't have to recode anything.

FireWire kprintf, you install a KEXT, and you set a boot arg, and all kprintfs go to FireWire automatically. You don't have to recode anything. So it's not going to cause real big timing differences in your driver. Hopefully it won't mess things up and make your problem go away. For the first time now, this is available in SDK 20. The instructions are a little cryptic, but if you're in the kernel, you should be able to figure them out.

Next is FireLog. Sort of a big brother to kprintf. It's actually quite different though. It also works like a serial port. You can print messages and they will come out and you'll view them on another Mac. But, It doesn't push the messages out, they get pulled out by the other Mac. So in fact, it coexists with FireWire. If you use FireWire kprintf, you can use that to debug any kernel driver except FireWire, because we get rid of FireWire to use it.

FireLog can work with FireWire, and we use it all the time, and it can work with anything else too. Let's walk through how that works. Suppose your driver's running in the kernel on this G5 tower. FireLog provides a buffer where you can print messages to. You run a viewer on another Mac and connect the two by FireWire.

As your driver runs and prints messages into the buffer, this is even more lightweight than FireWire kprintf. This is just a memory copy. You just copy a few bytes into a buffer and continue. You didn't take a context switch, you didn't program any hardware, you didn't take any interrupts, you didn't push anything out of the cache. This is ultra-lightweight as far as impacting what your driver is doing. The other Mac will come in on a polling basis and use the physical DMA to pull your message out and show it in the viewer.

There's the messages in the viewer, and here's the physical DMA pulling them out. The link, the open HCI link that we use in the Mac, supports this remote memory access with no software. So there's no interrupts, nothing's happening that the G5 knows about as the messages are pulled out. This means your driver could run out of control and panic. I know you'd never do this.

And maybe if you were using a serial port, it would panic and kill the thing before the messages all dribbled out. The physical DMA still works after a panic. It's autonomous. There's no software to drive it. So that viewer, even if you've logged megabytes and megabytes of stuff, the viewer can patiently pull it all out and show you every last line that you logged up to the last one, which maybe has a clue for why you panicked. So that's why it's called panic proof. So this is also available in our SDK. If you install one of the FireWire packages in there, it'll have FireLog supported.

Another tool now available in SDK is called FireWire MemoryView. It's very primitive, but it's like the innards of FireLog. All you do is type in a node number and a pointer, and it reaches into that node over FireWire, pulls out the memory, and shows it in hex with continuous refresh.

It's completely passive. The node that you're doing this to is not going to know that anything's happening. So if you know where to look, it seems awfully simple, but we've used this already to debug several problems where this turned out to be exactly the tool we needed. Once we could see in real time right in front of us what the values were doing, the aha went off and problem solved. Memview is perfectly safe for the host on which you run it. It uses the normal FireWire user client API, so it's not skeleton key based. Nothing's going to go bad on the host. On the victim, you're reading from memory addresses of your choice.

Normally that's safe, but you can read from things that aren't memory. You can read from PCI registers. In the example here, we're actually reading the FireWire controller registers from the other node, because that's interesting to us. Some hardware devices have registers where if you read them they have side effects. So you can trigger those side effects with MemView, so you may need to be careful.

And on a G5 that has the Dart architecture to support 64 bits, some addresses don't exist. So if you try to read an address from a G5 machine and it's not in the Dart, that's bad. So make sure you know what you're doing if you use this tool either on a G5 or on something that's not really memory. It's in the SDK, give it a try. Okay, one last tool to go, one last demo to go. This is called FireWire Panic View, and this one pretty much speaks for itself. So let's go to demo one and see what's going on.

Okay, so I'm developing kernel drivers. I'm new at this, I'm going to make a few mistakes. I've loaded my new experimental driver onto this system. Okay, 17 inch PowerBook. And I'm going to try loading my driver, and no prize for guessing what's going to happen. Oops. I guess my driver still needs a little work.

Now, normally this is real convenient because I was expecting something, but this panic's different from all the ones I got before, so actually I'd really like to copy this down and decode it. But it's all here on the screen, and I think the battery's going to die in a few seconds, so what do I do? I'm going to run FireWire PanicView. And take a FireWire cable from this Mac and plug it into the FireWire port on this one that's panicked.

That was pretty easy. Now I can print this out, I can put it in a trouble report, I can post it on the FireWire mailing list and say, "Now what have you guys done?" No, no, don't do that. This is not a new idea. This was actually shown a few years ago at MacHack, so we're not going to take credit for this, but it's useful.

This didn't quite make it into SDK 20, needs a little fine-tuning, but we thought you'd like it, and we'll make it available in an SDK coming up soon, and please give it a try. Okay, that's the end of the demos. All six, none of the, well, one panicked, but that's good. So if you haven't tried the tools yet, hopefully you'll believe now they're pretty safe. And let's go back to the podium.

Okay, that's it. A quick recap of more information on where you can get this stuff. This is the main URL for WWDC. This is not for FireWire. This is for any session at all. If you go here and pick FireWire Session 504, you will find links to developing user client drivers for FireWire, kernel drivers, the iSight programming guide explaining all those registers.

If you get SDK 20, which is also available today on the web, you will find sample code, source code, more documentation, every tool that you just saw except Panic View, I believe. This was just posted live yesterday, so my memory's fresh on this. There's a lot there. Also in the SDK we have public mailing lists for FireWire and the reference platform. You are welcome to post questions there. No panics, please. No screenshots. Panics are okay. Developers answer each other's questions on there, which is great, but we also try to answer everything that needs an answer.

We have a whole second implementation of FireWire called the FireWire Reference Platform. This is maybe not suitable for running on Mac OS X, but it's suitable for almost anything else. If you're building a TV, or a multifunction printer, or any kind of FireWire device, especially an AVC device, the reference platform has lots and lots of source code designed for sort of embedded OS situations. Please take a look and give it a try. There's also a mailing list for discussing that. So lots of good stuff available on the web.

There's two sessions you may want to think about here this week at WWDC, both on Thursday. There is a kernel lab, not just for FireWire, but for all kernel developers. And that is right next door, it's actually in the room behind you, starting at 2 o'clock, and we'll have some of our engineers there. You can see the tools or get your code debugged.

Then later on Thursday at Apple, during the big party, we will have a plugfest. That's together with USB and Bluetooth and maybe one or two others. Bring your devices by. It's in the cafeteria on the second floor. I think everyone comes into the cafeteria anyway. So go on into the middle, get some beer, get some food, then bring your device back upstairs and we'll plug it in. You can see Busy Bus, we'll have, sorry, FireStarter. We'll have a demonstration of that virtual DVHS running with a real TV. and try out your devices there. We'll also help debug anything that goes wrong.

We'll take questions in a moment, but if you want to talk to us later, we're happy to hear from you. Most people can contact Craig Keithley, who will be up here in a moment. If you are based in Japan or in Asia, you're welcome to contact Steven Chick at Apple Japan. You can email him in English or Japanese.