WWDC2004 Session 501

Transcript

Kind: captions Language: en hello welcome to session 501 firewire thank you okay every year we see new firewire products and applications all sorts of areas the technology just keeps going further the main reason is because of you are developers you keep innovating with this technology finding new ways to use it and that's great that's exactly why we're here so we're trying to keep up with you we've got a lot of new services new features new API s new sample code new tools even a few bug fixes this year we're back at dub dub DC just like every year to bring all that to you for those of you who are already developing with firewire we have a lot of new material this year especially as relates to tiger and for everybody we have a quick introduction to the hardware and the software so that you'll all get the complete big picture so we're going to start by recapping where the firewire ports are and why they're there because that's where your device plugs in that's where the opportunities exist then we'll quickly look at the software how that works from drivers up to application again where can you hook in what's your part going to do the bulk of the presentation is on what's new what's new and tiger and what's new since last year and then we'll wrap up with a quick look at some of the great resources that we have for you as developers to help you develop on fire wire so first the hardware where are the firewire ports with this parts easy because they're pretty much everywhere every product that we make every CPU from the ibook up to the xserve has firewire ports built in we've been doing it for years every ipod that we make has firewire ports and there's two more products that have firewire one is the isight camera used with ichat AV and the other only introduced yesterday is our new line of flat panel monitors which have built in firewire hubs so there are lots and lots of ports for your customer to plug your device into why why do we have so many firewire ports what's so great about firewire in years past we could get up here and say well it's hot pluggable Auto configuring note terminators no scuzzy IDs thin friendly cables these days that's true pretty much every I owe anything left and firewire that makes it special where's a few things firewire is really fast firewire 800 800 megabits per second that's 100 megabytes per second it's the fastest general-purpose interface on the box you want to get data in or out in a hurry we've got the speed for you multi-speed firewire devices shipped starting at 100 megabits and then moved up to 800 you can freely mix and match these on a firewire buff the slow devices go flow the fast devices go fast but firewire can change speed on a packet by packet basis so the fast devices don't get slowed down by having to speak at a common slower speed firewire can cover really long distances longer than the other general-purpose iOS firewire can go up to 100 meters that's longer than a football field you want to get your device really far away from the user firewires the way to do it firewire provides a lot more power than any other bus to maybe that's why you want to get the device far away firewire can provide 45 watts of power our machines provide less but plenty to run an eye sight or an iPod but if you have a custom application the cables the sockets are all rated for 45 watts you can do some really innovative things with that and customers love it there's no extra power supply for the isight camera the ipod charges when it's plugged in on firewire and charges quickly a big advantage for firewire isochronous some other interfaces have this but i shock but firewire does this really well isochronous moves streaming data audio video data that has to go in real time firewire has very low latency and guaranteed bandwidth for isochronous it works very well for delivering your media data firewire is peer-to-peer firewire has been peer-to-peer from day one the very first firewire product was a digital video camcorder in 1995 there was only one other thing you could plug into it on fire wire another digital I am quarter you can't get more peer to peer than that but it worked you could copy one tape from one camera to another you could edit DV kind of cumbersome didn't have final cut back then but you could do it peer-to-peer between those two cameras everything about firewires peer-to-peer the host the devices from day one some other interfaces this may be cobbled on years later it may kind of work especially if you only have two peers may work some of the time not in firewires been there from day one it gives you tremendous flexibility and all those together that's really what firewire is about flexible if you choose firewire as the interface for your product you won't get boxed in by design constraints as your product grows as you add new features capabilities speed performance firewire can take you there firewire has so many different ways of meeting your product needs its open-ended you won't get stuck on the limitations of the buff and it's efficient when you have lots of devices on a firewire bus the bus can run nearly a hundred percent there's no collisions in firewire there's no back off there's no lost packet firewire operates very efficiently even under stress so let's take a closer look at some of these key concepts one thing that makes firewire really fast is the physical DMA this is a feature in our products in the host controller that allows a firewire device to directly read and write memory without getting the CPU involved that speeds things up a lot let's look at how that works suppose we have a Power Mac g5 tower and the new ipod mini of course it's plugged in by firewire let's look inside the g5 tower and look at just a high-level view some of the system parts in there on the left you see the CPU in the center is the Northbridge and it connects the CPU to the memory which is on the right and the i/o controller down below the firewire interface is in that IO controller when the ipod has been directed to move data it's going to copy data into or out of the system so let's have a buffer here in memory the ipod requests the transfer is initiated by the ipod it tells the mac i want to read the buffer or i want to right the buffer here here here and here this transfer goes through the i/o controller which receives the requests over firewire and goes directly to DRAM to service them the CPU is simply not involved there are no interrupt there's no polling no Pio no handshake nothing it goes as fast as it possibly can and the CPU is available to do other important work of course when the transfer is done we send a special packet that does cause an interrupt because we do want to know the data made it where it's trying to go but this makes firewire extremely fast also the pacing is under control of the ipod this is a very unequal system the ipod has a very small disk it's just not quite as fast as the g5s memory system the ipod controls the pacing I want to read data now now now everything goes exactly at its speed so this little need for flow control or congestion with the ipod driving it can do absolutely the best that it can another important feature is the guaranteed isochronous bandwidth this is for real time services if you want to connect a camera or microphone a device that streams media firewire gives it guaranteed access to the bus it's packets will get to they'll get to on time even if someone else is trying to drive the bus to 100% let's take a look at how that works we'll start with the isight camera this camera made by apple sends video and audio / firewire into a mac and is commonly used with ichat AV if we look at a graph of the activity on a FireWire bus from an iChat from an isight camera it's very flat let's suppose the camera is set to a very high resolution high quality video mode the camera might be using fifty percent of the firewire buff if it's the only device on there nothing magic is happening of course it can get fifty percent of the buff but let's consider a more complicated case let's take a non real-time device like a hard drive a hard drive has a lot of moving parts and so the rate at which it can transfer data is going to vary over time especially if you're doing complex transfers like directory copies so if we look at the access pattern of a hard drive on fire wire we'll see it's all over them app if it gets going it may go up to a hundred percent and saturate the firewire bus but then it may drop off while it waits for the media to rotate around and grab some new sectors so the access pattern is fairly unpredictable what happens when you put these two together on the same firewire bus well the bandwidth for the eyesight is guaranteed the eyesight's going to get its fifty percent all across time perfectly smoothly and the hard drive is going to get everything that's left over the hard drive doesn't have to back off or moderate its requests it can go out and say I want to move data and I want to move it now and the hardware in firewire make sure that as soon as the eyesight is done moving its isochronous data the hard drives can get every little bit that's left over so in this combination the bus efficiency can be pushed basically to 100% the hard drive can just go full bore it'll take a little longer because the eyesight is also on the bus but there's no impact at all on the eyesight the audio and video keep flowing completely smoothly this guarantee is provided and hardware so you can't mess it up finally I said firewire can go really long distances but you may have noticed that we don't have long distance ports on our product why is this does this really work well most of the devices our customers connect are things they want to use nearby because they're probably interacting with the device as well as with the mec such as an isight camera and ipod a DV camera where they may be changing the tape but there are some kinds of devices that are very interesting at long distances such as a security camera or music studio application or an industrial application where you want to put some distance between yourself in the device so we can do that what you do is get a 1394 be hub this is a very simple device because it's just one piece of silicon the hub has regular firewire 400 ports on one side which you can connect today to our I bloke is shown here and it has long haul 1394 be ports on the other side such as plastic optical fiber glass optical fiber or category 5 unshielded twisted-pair you can choose the media that's most it to your application this way we don't have to pick between those three for the port on our computer and you can still get the long distance now if your device is something that's always going to be used or often going to be used at long distance it may make sense for you to incorporate the long-haul connector directly then the customer doesn't need two hubs they only need one other important thing to note about this picture the two devices at either end the ibook the isight camera those are not 1394 be devices they're firewire 400 can they work with this long distance sure 1394 b is completely backwards compatible the hubs understand how to talk to the firewire 400 device and how to talk to the long-haul connection and the data flows seamlessly through from one end to another so this means if you want to put some distance between the devices you're not limited to our latest models like the g5 and the powerbook that have firewire 800 your customers can use this with all of our products that ever had firewire ports going back many years so this is very flexible technology let's move on into the software you've seen where the ports are why they present unique opportunities where do you hook in if you're writing software consider the Macintosh suppose you have some firewire devices that you'd like to use you're going to have some applications that launch when you want to use these devices now as I explained earlier in the diagram with the ipod every McIntosh has one built in firewire controller it's the industry standard 1394 open HCI open host controller interface all of these devices are going to have to share they all want to use it at once someone's going to have to mediate this so you've got different applications different drivers different devices each doing their own different thing on a single controller that's the main job for the firewire family the family steps in takes ownership of the controller and moderates so that everybody can do their thing without even worrying about what else is going on that's the main function that the family provides now may not see it but consider the two devices on the left the still camera the ipod mini they actually have a lot in common they both use a mass storage oriented protocol they use the firewire transport called SBP to serial bus protocol too and they communicate using a scuzzy architecture on top of that so we provide a standard software layer that they can share so their drivers don't have to re-implement this protocol from scratch similarly the camcorder and the guitar look pretty different but they both use a protocol known as a vc audio video command or control here too we have a common layer of services for speaking this protocol so the individual drivers don't have to re-implement it so in a nutshell firewire software shares one interface and provides common services that multiple drivers can leverage to simplify driver writing and ensure uniform common behavior now everything about firewire here is in the kernel because some firewire devices provide services to other layers of the kernel for example a mass storage device can provide a file system or a io5 r.i.p can provide networking services those are both colonel services so firewire has to be in the kernel to make those possible but we've gone out of our way to make everything in firewire available in user space as well as in the kernel so odds are you can write an application or a plug-in for an application you can run it and debug it in user space which is much more pleasant than trying to do your development in the colonel now that you've seen the basics let's look a little more at the details of the layers here's the items from before at the bottom we have the hardware interface apple fw ohci is a system kernel extension that effectively is the device driver for that interface and it has sole control sole direct access to the hardware above it is io firewire family also a kernel extension and it has sole ownership of the ohci driver above the family first we find protocols such as you saw in the previous slide such as ABC or SBP to above protocols we have drivers for particular devices or classes of devices for example a mass storage device uses the i/o firewire serial bus protocol transport driver as its gateway up into mass storage and the file system whereas the DV camera uses I OFW DV components as its gateway up into QuickTime other drivers are more specific like Apple eyesight or IO firewire IP in fact these drivers don't use a separate protocol layer they really are a protocol and driver all wrapped up in one so drivers can also hook in directly to the firewire family above this layer we have what I call everything else once you move above this layer you're not in firewire anymore you're in quick time you're in Final Cut you're in the file system somewhere else not my problem so say I tuned Final Cut Pro QuickTime they're good places to be there above firewire these could be applications or they could be additional Colonel layers so this is the basics of how the firewire software hooks together I mentioned that in applications you can access all the fire wire services so of course applications can talk directly to drivers but there's two other paths as well we provide what's formally known as a device interface and is often called a user client this is a library API that lets you talk directly to a protocol or even directly to the firewire family itself from an application so we're very flexible you can hook in anywhere you need in the kernel in application space we provide lots of ways to do it now I mentioned I Oh firewire IP what's that doing here in firewire IP is a protocol that's designed to span the globe it works well on slow comparatively slow unreliable links doesn't sound like firewire well turns out it works great on fire wire doesn't depend on anybody dropping packets but a lot of devices already have IP in them for one reason or another generally because it's ubiquitous a lot of printers today have a little web server inside that lets you browse the status or configure the device even if the main data is sent over some more native protocol say SBP too so if you already have IP capabilities in your device you can carry these into your firewire device and the user will have full access to D services in Mac OS 10 we implement ipv4 and ipv6 in firewire it fully supports rendezvous if you have a surfable device you can get to it to firewire no special effort is needed so we're very flexible there please think about taking advantage of that the firewire family this was the master control layer that provides all the services just what are those services first and most important when your device gets plugged in we have to find it the family knows how to notice that a new device is on the bus and the family will ask the device hey what are you why are you here the family takes these answers and puts them in the IO registry which is not a FireWire structure it's a general I okay at service io kid then comes along and matches drivers or protocols to your fat to your device based on the information that firewire provided and this process may be iterative your device might say well I speak the AVC protocol so we would match the ABC layer which would then ask your device further questions saying okay what kind of sub units do you have your device might say I have a tape subunit and audio sub unit we put that information in the io registry as well and then match further so we can get just the right driver for your device on a firewire bus the node IDs may change their assigned randomly as devices come and go they may change the last thing your driver wants to deal with no problem every firewire device that we can talk to has a unique serial number called a good global unique ID the family will track this down and it'll follow it around the bus so the family always knows what node ID your device is on it will automatically send your drivers packets to your device so you don't have to worry about this on a firewire bus I mentioned you can have mixed speeds maybe your device does firewire 800 but your customer plugged it into an iBook that has firewire 400 we don't want your driver to have to figure that out the family figure set out the family looks at who's connected to who finds the fastest path between devices automatically routes your traffic at the best speed that it can do also the family having looked at the bus topology can perform an optimization to tune the bus to make it operate as fast as possible again something your driver won't have to worry about okay so your device has been discovered it's on the bus keep keeping track of it now you want to talk to your device the most basic communication on fire wire is an asynchronous request a read or a right directed at a memory location in your device the family will do this for you it'll send the packet to your device and if your device is so kind as to respond the family will fish the response out from all the traffic on the bus and hand just that response back up to your driver so you don't have to worry about the other devices that are on the bus you may want to do the reverse maybe your device will initiate the communication if so it needs an address that it can talk to in the Macintosh so the family will allocate an address space for you and as packets come in to that address space it will hand them to your driver and say here do something with this so you can go either way you may want to communicate in real time we'll get to that in a moment the family also publishes a configuration rom this is the structure that tells every device on the bus what you do for a device like an iPod or a nice site that functions probably locked in at the factory so this may truly be a rom but for a device like a Macintosh its capabilities may change as new applications are loaded new drivers are installed so that's why I put quotes around rom on the Macintosh the configuration rom really comes out of RAM and is managed by the firewire family for example when I Oh firewire our IP load it says please tell everybody that IP services are now available on this node so the family put that information in its configuration and announces it on the bus if you want to communicate in real time to send or receive streaming data the family manages that for you and we'll go into a lot more detail about how that works additionally the family can get you your reservations on the bus if you want to reserve band for your real-time communication just ask the family it will get the reservation and it'll keep the reservation valid for as long as you're using it now there's a second completely input independent implementation of firewire in the Macintosh and that's in the bootrom why well you can boot the computer from a firewire disk so somebody has to load Mac OS 10 from the disk over firewire can't load itself the bootrom does that you may not do this every day I do but this is very helpful you might need to install mac OS 10 on a lot of different computers say in a laboratory or classroom environment installing from a hard drives a lot faster than installing from optical media or you may need to install mac OS 10 over and over and over again if you're testing or debugging or checking different versions and you only have one system firewire booting is great for this it really speeds things up the other thing that the bootrom can do is a service called target disk mode this is where firewires peer-to-peer capability really shines in target disk mode the Macintosh will emulate a firewire hard drive completely in software you can then plug it into a second Macintosh and it will show up on the desktop as a firewire hard drive here to you may be wondering why would I do this well it's a real easy way to move data quickly between systems it's also a great way to fix up the system if it's not booting properly if you're developing Colonel drivers and you've installed a new text and rebooted the system there is a chance the system will crash in your text well that makes it very hard to get your system working again because you can't boot to find her and get rid of that text no problem with the system in target disk mode plug it into your other Mac go delete the offending text take it out of target disk mode now it'll boot fine very quick recovery it's a lot better than reinstalling the OS so two capabilities in the boot rom that you may find useful we also have a third completely independent implementation of firewire and that's called the firewire reference platform you may recall that we purchased a company called zion.t a few years ago and they had a product called tnf 1394 that's what this is this is software that's designed for pretty much anything except a computer a peripheral device a multifunction device it's a rich modular software stack designed to run within the limitations of a real-time operating system or an embedded operating system you can download the entire TNF sources from our website they're posted for everyone to use if you want to incorporate the source in your product you need to sign a license from Apple but it's free no problem tnf has very rich services it has lots of examples what it calls applications which is sort of the heart of whatever your product does it especially has good AVC services so if you're doing an audio or video device using the ABC command set there's really rich capabilities here that could give you a huge head start it's available on the web you can take a look at it and see if it meets your needs ok now that everyone's well versed and firewire let's move on to what's new first most importantly what's new you guys have been great you shipped a ton of products this year all sorts of innovative things so big thank you to our developers really happy with all the stuff we've seen new product I'm sure you've seen is the ipod mini but maybe you didn't know it has SBP 3 what is that it's the same SBP to that we use for match towards mass storage devices but it has a new feature that makes it go faster let's look at what happens with an older ipod and a powermac as we try to read 2k of data from the device using an operation that has a page table here's the two devices there's going to be seven packets exchanged on the firewire bus to complete this operation to signal it to move the data and to indicate that it's done the packets are very efficient so this isn't bad we get good performance from this but fast start makes it a little bit better with new ipod mini that same operation takes just three packets fifty-seven percent improvement this gave us a good performance improvement we were very happy to have fast start in stp three has been supported since mac OS 10.2 point five we encourage you to try it out in your products if you use SBP to ABC the audio/video command set we've had support from ABC since day one because that first product was a camcorder but there's one thing we've never done quite right and that's a kind of command called notify the notify command an ABC is something that may complete later it may complete a lot later you're telling the device I expect something to happen in the future please tell me when it does but our API for sending this kind of command is synchronous so you call this API saying hey tell me what's going to happen it may be days later before it returns and says okay it happened that doesn't really work so we still have the old API no change at all there ABC command lets you send a device out to them their command out to your device but we have a new service that's also available you can create an ABC asynchronous command and assign to it a call back when you submit the command it returns right away later when the device completes the notifier sends the status your callback will be called so this is perfect for use with the notified command you can also use this with other types of command but they'll generally complete right away if you're familiar with our software development kit you may have seen our MPEG framework it's a pretty rich collection of services that allow you to stream MPEG on fire wire on a macintosh well we've taken that a lot further that was in sdk 19 we've extended it and renamed it and now it's the AVC video services framework what we've done is added DV the completely second video format and we've integrated all of the AVC commands and control that are necessary to set up discover and maintain these streaming connections so your device your driver doesn't have to worry with these details all in all it provides better support than our older api's like this awkwardness data handler for example only with the new framework can you do dvcpro HD in writing your applications keep in mind this is still a very low level way of talking to your devices depending on what you're doing this may be appropriate however application software may want to use higher level api's such as quicktime if you use quicktime you can talk to any kind video device without worrying about whether it's on fire wire or something else but if it's appropriate you can use this framework we know several developers are already shipping products based on the framework that's in the SDK now in tiger this will be a private framework but it will continue to be in the SDK and you can pick it up there and build it into your products we would like to consider making it a public framework so you can just count on it being there we need to hear from you we want to hear how you're going to use it how it's going to help your product and what you're doing with it that kind of feedback will help us to take this into a public framework so please take a look at this evaluated for your needs and then let us know isochronous data we've talked about sending real-time data on the bus how do you receive this data in your driver we have a new capability called buffer fill a sock received but I haven't really described how to receive any data or even really said what isochronous is let's do all three isochronous literally means equal time so if we take a timeline and divide it up into equal chunks that's isochronous then we send the packets on the bus in these equally spaced cycles here's six packets going across the bus at regular intervals the firewire bus provides these cycles 8,000 times per second if you're receiving isochronous data you probably don't want us calling you a thousand times per second to say hey a new packet arrived quick better do something because there's another one coming in 100 microseconds isochronous whether you're sending or receiving it's about planning ahead what you do is you make a list of instructions for us in memory using an abstract structure called a data stream control lift you give this list to firewire and say here's a plan I want to receive the next hundred packets as so it might look like this a series of instructions each of which says receive one packet and here's a little buffer to put the packet into then when you run this program and start the isochronous stream the packets flow into the buffers just like you'd expect this is what we've had all along this can serve any kind of isochronous reception neat but this is not always what you want the particular stream shown here has packets that are not all the same size this depends on your kind of device some devices all we send a single size of packet others may be all over the map in the later case you may waste a lot of memory a lot of buffer space because if you don't know which packet is going to come when every but has to be big enough to hold the largest possible packet the hardware in the industry standard ohci provides a way to pack the packets together neatly and this may be what you want depending on the kind of data that you have so while maintaining the existing services and tiger we're adding a new way to receive isochronous data called buffer fill which is simpler here we simply have a list of buffer pointers and some significantly larger buffers as the packets come in from firewire the hardware will neatly pack them into the buffers using up every last bite you can see on packets for it didn't completely fit in the first buffer so the hardware just split it in half and put the remainder in the second buffer you can choose whichever of these is more suitable to the kind of data that you are receiving but some future services such as receiving from two channels at the same time may require the buffer film mode because that's the only way the underlying hardware can do it speaking of dcl which is the data stream control language for sending or receiving packets we've made some improvements in tiger we've cleaned up what happens when the computer sleeps isochronous means real-time but if you're sending packets and the computer goes to sleep that's not real time anymore when the computer wakes up any packets that you had prepared our way out of date nobody's listening nobody cares so we used to try to keep sending and that was a mistake we've cleaned it up now we stopped your program when the computer wakes up we send you a message saying hey your program stopped because the computer went to sleep you want to start it up again go right ahead you should check and see if your device is still on the bus see if there's anyone listening but then go ahead and start your program up every dcl has a callback known as the force stop proc it gets called if your program is opted against your will for some reason such as the computer went to sleep or such as you lost your isochronous reservation which is very rare but this is a special case where it can happen so be sure you hook up this callback pay attention to the hardware slept message then just call stop and start to get your stream going again you don't have to tear down your dcl just make sure it makes sense fill it in with fresh data and get it started again some kinds of isochronous since it's real time the system may be trying to meet various real time deadlines especially in the case of receiving audio and firewire there may be very high priority threads running trying to do everything with the lowest possible latency this may work at cross-purposes to firewire because it may hold off the execution of firewires processing of your packets that are going in or out so we've added a method you can call that will directly force the update of your program regardless of the priority so if you are running on a high priority thread and you want firewire up-to-date call this method firewire will run even if it's being held off otherwise and your data will be up to date the typical case to do this is with audio we've made further changes if you have a transmit program it's common to make changes to the program while it's running you can change the size of the packets on the fly you can change the buffers the packets come from on the fly you can even rearrange the program order on the fly this is often done because the programs typically run either in a loop or in a sort of open loop that's constantly being refreshed with additional data previously if you changed either the length or the pointer to a buffer it was very inefficient as we went through an updated debt and we've greatly streamlined that so it's much more practical now especially if you have a big program to use this technique I mentioned that the callbacks for audio processing you can have priority problems in addition to the direct service method you saw on the last slide we have a new capability to assign a dedicated thread to you're dcl if you have multiple DCL this will let you prioritize them or prevent deadlox between them if you're running in the kernel you can allocate and create the thread of your choosing and set all the parameters just the way you like then assign it to your dcl on the other hand if you're running in user space you can simply set a flag saying that your dcl should be processed on a separate thread so it doesn't depend on anybody else more isochronous in a way the isight camera it sends audio and video on fire wire but no one really knows how the audio works because that's not in the spec that it otherwise complies with the camera complies with the 1394 trade association hi IDC camera specification Apple extended that a little so this camera would work well with ichat AV we added some video formats that work well with Internet chat and we added an audio capability we have prepared a developer technical note that explains how these work and some of the other subtleties of the device like how to find out if the shutter is open and what's in the config ROM and what all those unit directories mean this tech notes about ninety percent done we hope to have it out to you in the SDK or post it on apples developer support site in the very near future let's talk about some changes to tool color Firebug you may be saying hey I like color that sounds good but what's Firebug Firebug is Apple's packet analyzer it's a Snooper it requires a special pci card or card bus card but it lets you see every packet on the firewire buff and this can be tremendously useful in trying to debug your device Firebug is the poster child for crude but effective you can see the user interface is somewhat lacking but it shows you every packet on the bus and has lots of options for how to arrange the data here if you're a Firebug Wiz you can see that it's showing operations to an iPod as we read and write data from the disk but some of you may still not really see that so clearly does that help color Firebug can colorize the packets based on various different criteria the goal is to help you quickly identify what you're looking for here the packets are colored based on their type reads writes block squad let's requests responses each one has a different color you can color based on the packet speed based on the sender ID the target ID the isochronous channel the acknowledged code depending what you're looking for this may make it jump out if you've got one packet that's at the wrong speed it's real easy to spot one red line in a field of blue then it go through trying to read all of the digits in the speed code so if you use Firebug download the latest SDK this is in Firebug 1.9 try it out we've also enhanced our fire starter tool this is a tool that was designed primarily for firewire plugfest or anywhere that you have a lot of firewire devices connected together on one firewire buff it uses the same code as Firebug for displaying the bus topology there on the right hand side in a simple ASCII rendition showing what's connected to what this is based on receiving the self IDs and no special hardware is required for that so this tool can run on any of our products firestarter also sorts all the self IDs and tells you things like how many nodes are running at each speed firestarter 1.4 has some improvements in particular there's an options menu that lets you select several different things you can configure some subtle details about the role firestarter will play on the bus in bus management you can ask firestarter to announce itself to Firebug by sending a packet after every bus reset to say hey I'm here I'm on node 7 you can even ask firestarter to play the system beep sound on every bus reset if you need to know these are happening and finally there's a new display mode that shows the raw self IDs when would you use this well if you have a really low level problem in firewire the self ID sequence may not complete properly a defective hub or an out of spec cable may cause some kind of problem where the self IDs get messed up in which case firestarter can't make sense of them and it won't even try to draw the tree it'll just show you a blank page so select this new option and the page changes to show the hex values of all the self ID packets exactly as they came in this will help you figure out what's going on also we like colors in like to added some here too if there's a bus reset firestarter will tell you about that too just like that some other tool updates we have a tool called Phi tool that we described in great detail last year it lets you view and edit the registers in the thigh and the Macintosh and you can view these registers on other nodes on the firewire buff Phi tool 1.7 has some important new features among other things it properly supports Panther and tiger there's no user interface problems and it has some important bug fixes especially if you were changing five registers the earlier versions would change a little bit too much so you might get confused it won't break anything but you might really wonder what's going on if you're using fights who will please be sure to get version 1.7 vigilante is a new tool in our SDK it really doesn't have anything to do with firewire but it tracks memory allocations for objects in the kernel and we used it recently to track down a big memory leak in the tiger version firewire it was so effective we said hey this is great let's put it in the SDK will let everybody use it so give this a try it's another good tool another capability we've never talked about before is the ability to put debug information in the i/o registry when you're working with firewire what is this this is kind of like a dynamic printf rather than logging out information constantly you can arrange to grab information from your driver at exactly the moment of interest this is really flexible although it's a little complicated to set up if you get firewire SDK 19 and you install it you can then navigate down through the folders as shown here and for the different versions of firewire there are installer packages that will install new firewire texts into your system choose the package that has debug in the name and it has a few special tricks after you've installed this package and rebooted you'll be running with a slightly different version of firewire look in the Applications folder in the SDK and you'll find a tool called mr. registry this is a browser that our team produced that can look at properties in the i/o registry if you look down towards the bottom is marked in orange you find the firewire controller pick that and show the property and you'll notice something new marked in orange on the right is a property called debug info that's not usually there that's added by the debug build of the extension so open that up it has some information about the isochronous DMA context this is pretty low level stuff why would you use this suppose you're transmitting isochronous on fire wire it's pretty easy to use Firebug to see the packets are going out across the bus you know your transmitters working receive is another story your device may be sending packets in Firebug shows them but they don't seem to be making it to your driver you don't even know if the mac is listening here's a technique that can give you a bit of a clue I just happen to know that my receiver is running on to context too but this only eight so it shouldn't take you too long to find open up context to and you can see direct information about the ohci controller it's command pointer and its command state if you refer to the ohc i spec you can see that that state 843 one indicates the DMA is running its active and it records event complete meaning is has received at least one Packer so that's a good sign we're getting somewhere but maybe that's all that happened it received one packet it stopped and now your applications not getting anything what more can we learn look at the part marked in orange that's the command pointer this shows where in the DMA program the DMA is executing well press the refresh button and it changed another good sign this means the DMA right now is still running it's receiving packets it's doing something with them so everything looks very good at this point this is pretty esoteric stuff not everybody's going to need to dig down in here to see if their dma is running or not but the point is this gave you a real-time printf rather than constantly logging information about what it's doing you were able to reach in and look just when you want to do and see a key piece of information the way this works is that the property that's created in i/o registry has a call back that says when you need the value for this just call me and I'll tell you when I our registry when mr. registry asked up-to-date information is provided you can do this in your driver to see almost any kind of information there's examples in our source code get the SDK and look in the source code for the IP driver or the SBP to service layer and you can see how to do this another capability we haven't talked about before debugging with fire log this is not new but we never explained how it works and we'd like you to give it a try this is one of the oldest techniques in the book you take two systems you run on one of them you use the other to look into you what's going on so your driver is running on the g5 fire log creates a buffer in memory where your driver can log some messages the other system is connected by firewire and it runs an application that can view these messages so your driver runs along recording information this all shows up in the other mac pretty basic stuff you could do this with a serial port you could do this with ethernet why do this with firewire well there's a difference this system uses the physical VMA just like the ipod that you saw before what does that mean when your driver logs and message it's nothing but a sprint f into memory there's no I oh you don't have to call the ethernet driver the serial port driver no interrupts no context switches it's extremely lightweight going through other iOS could add variables to what's happening on the system that you're trying to debug this is not likely to change very much on the system you're debugging suppose your drivers in the kernel suppose your driver panics it happens even worse the potion driver hang and doesn't have the good grace to panic well you may not be able to get the very last message that it wanted to log if you're logging in the system log or on a serial port or Ethernet you may have panicked before that message really got all the way out no problem with fire log the physical DMA does not depend on the cpu even if the machine is panicked the remote machine can reach in look at the buffer and see what's there and get the very last message that your driver logged before it died and odds are that's the one you want to see so this is a really unique capability on firewire give this a try this is a bit tricky to set up there's two ways to do it you can rebuild the firewire family to turn on fire log or you can install the debug package like you saw on the previous slide where this should already be turned on but we're trying to make this easier we hope to provide a text that you can drop into any version of firewire that will automatically make fire log available take a look in the SDK there's instructions for how to get this set up okay let's quickly review firewire resources we've got a lot of great stuff for your developers in addition to the tools and code that you saw here I keep mentioning the SDK our software development kit it's available on the web for free download we've made 19 of these since we started on Mac OS 10 and of course we're hard at work on number 20 SDK has lots of source code sample code application stuff colonel stuff great place to get started often the SDK has advanced versions of firewire software if we've made some fixes or added some features we can use the SDK to get those out to you so you can try them out before your customers do you can let us know if they work you can let us know what we need to change all of the tools that you saw are all built into the SDK and as various notes and documentation there's a lot of stuff we've had 19 spins on it we've really put a lot in there pick this up it's on our SDK website it's real easy to get we have some public mailing list there's a main list for firewire any kind of Mac os10 firewire development questions are welcome we will try to answer and often developer to answer each other's questions which is great there's a second mailing list for the reference platform where there's some very specific discussion about porting to specific real-time operating systems specific Hardware interfaces that's another active list there's a third list a lot of you may want to visit which is the ATA and scuzzy list why would you go there a lot of firewire devices that use SBP to have a scuzzy architecture in their command set even though they may have no actual fuzzy hardware if you're talking to that kind of device most likely the easiest way to do it is through discuss eat ask user client provided by our mass storage team support for that interface is discussed on this mailing list for all of these you can subscribe 1 common place on apples developer site it's very easy to do apple owns the firewire trademark but we're not very selfish about it use this on your products your customer wants to know the product has firewire put this on the product put this on the box put this in the marketing on the web page go nuts just license it from us and do be sure to use it correctly if you license it from us should get high-quality artwork so you won't mess it up there's another logo that shows your product has passed the compliance testing from the 1394 trade association this one you can't get from Apple because we don't run those tests attend one of the 1394 ta events or send your products into one of their vendors and have them tested you can get tremendously useful information about your product from this testing and we send a lot of our products in we always learn something new this is a really good program ok a little bit more if you'd like to talk to Apple about firewire Craig Keithley who will be up here for Q&A our main contact or if you're located in Asia you're welcome to contact stephen chick in our japan office or if you're not sure who to talk to just write to firewire at apple.com and we'll find somebody in the reference library on apple's ADC website firewire itself we have some basic information about the technology there's a substantial document for working with firewire device interfaces this is the user client I talked about earlier that lets you talk to firewire from an application or from a plug-in that's running in the context of an application Apple publishes developer notes for each of our CPU platforms they're quite detailed they will tell you how many firewire ports there are if it's firewire 400 or 800 how much power is survived it is provided what's the internal architecture of that system lots of valuable information there so please take a look finally if you do have to write in the colonel there's a starter document device driver fundamentals not specific to firewire take a look at that that should get you up and running we have a good techno Tandy CL program if you're going to be sending or receiving isochronous data take a look at this technical out for sample code there's some basic sample code for firewire scuzzy and general mastered posted on the ADC website to independently and then there's a good deal more in our fire our SDK as I discussed before since you're here at dub dub DC there's two more things you should know about tomorrow and Thursday we will have firewire engineers in the i/o technology lab if you go out these doors turn left it's right down the hall at the end we'll be happy to take your walk-in questions we can demonstrate the tools we'll try to debug your code come on by and see us tomorrow we'll be there from 9am to 630 except during the firewire feedback form in the afternoon and on Thursday will be there from nine a.m. to five and then we'll all leave for the other event which is the ADC plugfest at the apple campus bash so on Thursday we will have a bunch of firewire devices that you all brought and we'll connect them together in one big buff and you'll get to see for example firestarter in operation and see what happens when there's lots of devices all sharing the bus a lot of the devices we already have but you're still welcome to walk in with more and we'll plug them in and see what happens we'll have more engineers more opportunity to try the tools or ask questions that Thursday evening from the start of the campus bash until the close