First of all, let me make something very clear. I am NOT endorsing that you prevent installation based on EFI revisions. That's something you should discuss with DTS proper, and probably some EFI-savvy engineers inside Apple.
I would hate to have your product preventing people from getting EFI updates.
I also worry about Apple releasing a new EFI revision and people updating, and then your product breaks. You need to be working with DTS.
THAT BEING SAID, finding the EFI version is pretty simple, and here's what Apple has done recently. If you looked through some software updates posted, you'd be able to find this info yourself.
1) Before you check the EFI version, check the hardware model property and disallow install on unsupported machines. In a distribution file, it's like this: var hwModel = system.sysctl("hw.model"); This will return a string like "iMac9,1"
2) Get the EFI revision, and disallow on known bad versions: var EFIRevision = system.ioregistry.fromPath("IODeviceTree:/rom@0");
This will return a string like "IM91.88Z.008D.B00.0901142258"
If either of these returns an empty string or null object, you should disallow installation.
For model property, you probably want to have an array of strings of known good models, and block install if the model is not in the list.
For EFI, you probably want to have an array of strings of known bad EFI versions, and block install if the revision is on the list. (I am going to urge you to consult DTS and some hardware engineers to discuss the format of the EFI revision and how to block install.)
IN ANY CASE, I hope you are working with DTS to make sure your product and Apple's EFI revisions don't break peoples' computers.
On Aug 21, 2009, at 8:29 AM, Greg Neagle wrote: This sounds like you should be tracking/checking EFI firmware versions...
On Aug 21, 2009, at 8:01 AM, Freeman, Andrei wrote: We've seen some core level changes on the Unibody Mac Book and Air that causes some strange behaviour when we try legacy Bios level restarts. Since this functionality is essential to us, we need to have an idea where the lines of separation occur to properly throttle installation on unsupported or untested machines. This will also help our dev team with a plan of attack when sent to Apple's Compat testing lab. -A From: Bill Coderre [mailto:email@hidden] Sent: Thursday, August 20, 2009 4:30 PM To: Freeman, Andrei Cc: 'email@hidden' Subject: Re: API For the install target device's Model Number On Aug 20, 2009, at 9:00 AM, Freeman, Andrei wrote: The more I dive into this target the more conflicting information I find: I have a preflight installer tool that validates the model of the machine we are installing on. (E.G. We don't install on XServe's) We've discovered however that little nuances that change from model to model can affect our behaviour so I've needed finer granulation on checking the hardware we're installing on. sysctl -A can be parsed for hw.model which will give me the Model Identifier (i.e. MacBookPro4,2) Using the identifier presents a few problems: -The identifier however can encompass multiple Model Numbers and multiple CPU configurations. - There doesn't seem to be any one good repository of which identifier goes to which machine. The model itself is horridly unusable: "iMac" as that can be any of the models. Unfortunately, I've been unable to find any method to discover the Model Number (i.e. MB402LL/A vs /B) This may seem like minutia; but we've had issues crop up where bugs only exist on certain models and we have no way of running an API to say, "Yes, we can't install on this machine. We are aware of the issue." The Apple compat labs list thier machines by both "Marketing Model": '13.3 " MacBook (Early 2008)' {is there an API?} as well as "Partial model number": 'MB402' {Is there an API is that a LL/A or LL/B and would that be a MacBook4,1; 4,2; or something else} This also completely makes setting up a test array or a test plan very difficult for us. This list seemed to be the best place to start as the only hardware list on l.a.c is for driver dev. Any advice, suggestions welcomed.
Apple's advice, since about 1985, has been "do not rely on machine model numbers, instead test for specific capabilities" -- but this advice has always been intended to be used by programmers for things like "Does this particular Mac have a certain capability? (ie., graphic acceleration, or a DVD drive)" In those cases, deciding, "Ah, this is a Mac Pro, it must have a superdrive" was foolish. So the question becomes, "What exactly are you protecting against?" and then see if there are gestalts, sysctl, or IO Registry entries that do precisely what you need. Note that it is a BAD idea to look for, say, an Intel processor and then decide that it must have, say, a certain kind of graphics hardware. Note that IO Registry is the newest repository, but Gestalt is still useful for many things, even though it's been part of Mac OS for almost twenty years. You say that MacBookPro4,2 isn't specific enough, which is not too surprising to me -- there were a LOT of machines shipped with that designation. There's probably some other property that DOES tell you what you need to know, and it'll be a lot more reliable than a "Marketing Model" which can be hard to determine and might be incorrect. What, precisely, are you trying to test for? If it's something Apple has tested for in the past, I see no reason you should not use the same tests.
|