High Sierra DP/Beta 10.13.1 Build(17B46a) seeded…

Apple today seeded the fifth beta of an upcoming macOS High Sierra update to developers. Three days after seeding the fourth macOS High Sierra 10.13.1 beta.

Build Information

The seeded build is: 17B46a

SMC versions

All the same. Nothing updated.

EFI versions

There’s a new firmware update for one of the Mac mini’s – see snippet below from EFIVer.py.

—————————————————————————
EFIver.py v2.6 Copyright (c) 2017 by Dr. Pike R. Alpha
—————————————————————————
Mac-35C5E08120C7EEAF | Macmini7,1 | MM71.88Z.0226.B00.1709290808
—————————————————————————

Apple SSD Firmware

There are new firmware updates for the SSD in three Mac models:

Mac-4B682C642B45593E / iMac18,1
Mac-77F17D7DA9285301 / iMac18,2
Mac-BE088AF8C5EB4FA2 / iMac18,3

USBC Firmware Updates

Mac-473D31EABEB93F9B / MacBookPro13,1
Mac-4B682C642B45593E / iMac18,1
Mac-551B86E5744E2388 / MacBookPro14,3
Mac-66E35819EE2D0D05 / MacBookPro13,2
Mac-77F17D7DA9285301 / iMac18,2
Mac-9AE82516C7C6B903 / MacBook9,1
Mac-A5C67F76ED83108C / MacBookPro13,3
Mac-B4831CEBD52A0C4C / MacBookPro14,1
Mac-BE088AF8C5EB4FA2 / iMac18,3
Mac-BE0E8AC46FE800CC / MacBook8,1
Mac-CAD6701F7CEA0921 / MacBookPro14,2
Mac-EE2EBD4B90B839A8 / MacBook10,1

Nothing really exiting. Looks more like the GM.

Unused Bits in Processor Model Check…

I blogged about checks for two unused processor models when Sierra DP-4 was released and there are still a couple of unused bits – in High Sierra as well – that Apple could use for two Coffee Lake processors and the new Mac Pro. Here’s the data:

bit-10 (0x0400) possibly reserved for Coffee Lake Mobile
bit-11 (0x0800) possibly reserved for Coffee Lake DT
bit-15 (0x8000) possibly reserved for Scalable Xeon

Currently there is no processor model check that selects 0x400, 0x800 or 0x8000 in _xcpm_bootstrap, but they are checked in two other routines. Being _xcpm_init_complete and _xcpm_monitor_init. The bits corresponding to 0x400, 0x800 and 0x8000 are also set in most of the programmed MSR’s (Model Specific Registers).

We know what Apple did in the past for Skylake and Kaby Lake processors, and this combined with the two new Coffee Lake CPUID’s, that makes it the third piece of evidence pointing to refreshed hardware.

Please note that Apple may choose to update certain Mac models, silently. Like they do more often. Or at a later date, but I don’t believe that Apple will skip Coffee Lake processors altogether. To me it’s the most obvious processor for the next MacBook Pro, iMac and Mac mini.

That leaves us with bit-15 (0x8000). This value can also only be used for an Intel processor with a CPUID that isn’t already supported by the XNU kernel. And since there is only one bit reserved, this could mean that it won’t be used for a combination of desktop and mobile processors. Like Skylake, Kaby Lake and Coffee Lake processors.

It is also highly unlikely that it will be used for another processor in the Xeon W serie. Leaving one processor serie that isn’t used yet. And in case you didn’t know this already. I found references to the Intel® Xeon® Scalable Processors in the leaked firmware for the iMac Pro. This processor serie uses the FCLGA3647 socket, and could be used in the new Mac Pro. That is. If Intel isn’t releasing yet another new Xeon processor serie. Anyway. For now. Two possible candidates for the new Mac Pro are:

– dual Intel® Xeon® Gold 6144 Processor (3.5GHz/4.2GHz Max Turbo, with 16 cores and 32 threads.
– dual Intel® Xeon® Gold 6146 Processor (3.2GHz/4.5GHz Max Turbo) with 24 cores and 48 threads.

Note that I used these two, specifically, because of its high base frequency and maximum turbo frequency. Next to that. There is still a thread limit. Even in High Sierra, so either that has to change – which is pretty easy for Apple to fix – or the next Mac Pro won’t support more than 24 cores (and 48 threads).

The only problem that I see right now is that the processors cost an arm and a leg, and that would limit it to a much smaller group. The so called ‘pro-users’. Or people with deep pockets. For the rest of us. Ordinary people. It’s just too expensive.

But hold on. The iMac Pro might be too expensive for some of us, but it will also be good enough for the majority of pro users, and that is probably also the main reason why we are still waiting for a new Mac Pro. I think that Apple isn’t buying the complaints of the small pro-user group.

Historically we had two possible desktop Macs that could fit the need for pro-users:

1.) Mac mini
2.) Mac Pro

But that could change to this:

1.) Mac mini
2.) iMac Pro
2.) Mac Pro

But without a new Mac mini and Mac Pro update, we’re pretty much toast…

What do you think?

Coffee Lake CPUID’s…

There is a lot of buzz around the next Mac mini, and we all knew that it is coming. Now even Tim Cook seem to have confirmed it, but what you haven’t seen, yet, is evidence that Apple is actually working on new/updated products with Coffee Lake processors:
Image snippet of Intel Microcode for Coffee Lake CPU
The above snippet is for a product with a Coffee Lake processor with CPUID 0x0906E9 (EDIT: This looks more like a CPUID of a Kaby Lake processor) and the snippet below is for a product with a Coffee Lake processor with CPUID 0x0906EB.
Image snippet of Intel Microcode for Coffee Lake CPU
There you have it. And the stepping information (0xb/11) is particularly interesting, because even I haven’t seen any public reference to it. Other than some Geekbench results with the Intel i3-8100 and Intel i3-8350K (EDIT: Coffee Lake processors use stepping 10 and 11, but the eight core models will use stepping 12)

What does this mean?

Nothing really. Anyone could have guessed that Apple is working on updates or new products. The reality is that we don’t know anything. All we can say now is that there seem to be some kind of development going on, for at least six months already (April / May timeframe) for some product with a Coffee Lake processor in it. That’s not a lot. In fact. It’s about as close to zero as it could get.

Where did you find this?

I cannot reveal my sources, but what I can tell you is that I didn’t get it from Intel.

Note: I modified the checksums and references to the size of the actual Intel microcode, because I really don’t want anyone to get burned over this.

Sharing Code Snippets at GithubGist…

Sometimes something bad has to happen before you realise that something need to change. It’s stupid. I know. But for me that light bulb moment came after my last drive failure. You know. Losing stuff is such a waste of time and energy, so let me introduce you to my new GithubGist where I will share code snippets. So that nothing gets lost anymore.

It’s only two four for now, but more goodies are on its way to you.

Happy hacking!

Grr. Another Backup Drive Failure…

I don’t know what it is, but the backup drives that I use, from various vendors, on different motherboards, they all end up giving me IO errors, and some time after that, then they are gone. They won’t show up in the BIOS anymore. Even DiskWarrior can’t fix them anymore.

Lots of work gone. Again. I need to think this over. I need a break. Enough is enough…

Where are the i7-8800(K) processors?

So far I have seen over fifteen motherboards, from various brands, with the Intel Z-370 chipset, but not one of them is what I need. No. Sorry about this, but I want a motherboard without old tech on it. And two of the things I certainly don’t want to see on my next motherboard is:

1.) A D-SUB (DE-9) VGA connector.
2.) PS/2 connectors.

USB 3.1 Gen 2

What I need is proper USB 3.1 Gen 2 support. Not the slower USB 3.1 Gen 1 counterpart. I would also like to see at least two type C ports. Possibly four of them.

Note: the Z-370 chipset only supports USB 3.1 Gen 1. As in. Vendors will have to make use of the Asmedia chip for full Gen 2 support.

Thunderbolt

Grr. This is depressing. Why is there no Thunderbolt support on the new motherboards? Not even on motherboards with a price tag of (well) over 400 euro. With stupid names like “godlike gaming“. To me the only ‘god like’ part is the price tag. Complete madness. It’s not even the fastest motherboard.

Display Port

I also want at least one DP port.

HDMI

Motherboards with one or more HDMI connectors should at least support 2.0. HDMI 1.4 is no longer good enough.

And what’s up with all the plastic (covers) and added LED (strips) on so-called “pro” motherboards?

More importantly. Intel did release the Coffee Lake S/K processors, but it has no real answer, yet, that can compete one-to-one with the AMD Ryzen. Still not.

But hold on. Did you ever wonder why there is no Intel i7-8800(K)?

There may be a good reason for this. Maybe it needs a new chipset. The Z-390 that will become available some time next year, and maybe then we will get to see Intel’s answer to AMD Ryzen. We know that the Intel 8 core/16 threads Coffee Lake models are in the pipe line, but on which chipset they will be supported… I don’t know. But one thing is for sure. It’s just a matter of time that the 8-Core Coffee Lake will be released. I can’t wait, and thus I will skip the current/new motherboards with Z-370 chipset, because it’s not what I need.

Note: while I used “i7-8800(K)”, that may well become “i9-8800(K)” next year.

p.s. The CPUID for the 8-core Coffee Lake processors is: 0x906EC

Edit: The Asus ROG STRIX boards tick a lot of the boxes, but not all of them. This midrange board is sold with a premium, for no apparent reason. With working Thunderbolt 3 it would have been almost perfect. Except maybe for the lock bit-15 on MSR(0xE2). But hey. What else is new.

SIP requirements for startosinstall –volume <path>

Did you know that there are specific SIP (System Integrity Protection) requirements for startosinstall so that you can use all of its arguments?

Some of you may think that this is bollocks, but hold on. Not so fast. Go the the High Sierra (Beta) app folder and cd into the Contents/Resources directory. Then enter:

./startosinstall --usage

You may get the following output:

Usage: startosinstall

Arguments
--applicationpath, a path to copy of the OS installer application to start the install with.
--license, prints the user license agreement only.
--agreetolicense, agree to license the license you printed with --license.
--rebootdelay, how long to delay the reboot at the end of preparing. This delay is in seconds and has a maximum of 300 (5 minutes).
--pidtosignal, Specify a PID to which to send SIGUSR1 upon completion of the prepare phase. To bypass "rebootdelay" send SIGUSR1 back to startosinstall.
--converttoapfs, specify either YES or NO on if you wish to convert to APFS.
--installpackage, the path of a package to install after the OS installation is complete; this option can be specified multiple times.
--usage, prints this message.

Example: startosinstall --converttoapfs YES

Or this output:

Usage: startosinstall --volume <target volume path>

Arguments
--applicationpath, a path to copy of the OS installer application to start the install with.
--license, prints the user license agreement only.
--agreetolicense, agree to license the license you printed with --license.
--rebootdelay, how long to delay the reboot at the end of preparing. This delay is in seconds and has a maximum of 300 (5 minutes).
--pidtosignal, Specify a PID to which to send SIGUSR1 upon completion of the prepare phase. To bypass "rebootdelay" send SIGUSR1 back to startosinstall.
--converttoapfs, specify either YES or NO on if you wish to convert to APFS.
--installpackage, the path of a package to install after the OS installation is complete; this option can be specified multiple times.
--usage, prints this message.
--volume, path to the target volume.

Example: startosinstall --volume /Volumes/Target --converttoapfs YES

You see. That’s not the same output, and it depends on your SIP settings. And here is why.

Now. Some of you may have SIP partly or completely disabled, and will not notice the difference. Unlike me. I run my Mac/Hack with SIP fully enabled. That is why I get the first output, and thus I have change the SIP settings before I can use the –volume argument, because startosinstall requires – at least – either CSR_ALLOW_UNRESTRICTED_NVRAM/0x40/64 or CSR_ALLOW_ANY_RECOVERY_OS/0x100/256. Without one of these, the –volume argument won’t be supported.

Please note that this SIP requirement was first introduced in a Beta of Sierra 10.12.4, and I ran into it before, but the only reference I had were my own notes. Not exactly rocket science, but it is something that I wanted to share with you 😉

Happy Anniversary…

More than ten years ago I worked on code for VirtualBox. To get OS X 10.5 (codename Leopard) installed on it. And I can happily claim that I was the very first person to do it. That also triggered my attention to OS X.

At that time I left the Ubuntu developer community and started to work for Google Inc. And now. Ten years later. I’m still here. And I became the person who I am. A man now. A father of two great children. The husband of my beautiful wife. People who I love to pieces.

And you know what. Nobody expected me to stay this long. Many thought that I was somebody else. Because I helped my father and later my sister. As a sidekick – first public appearance as a hacker in 2012 and I started to blog in 2013. Boy what a joy that was. Fond memories.

Anyway. Even I thought that I won’t change jobs. Not ever. That is. Until I was asked for a job interview in the US of A. So I went. I listened. Got the offer for a great job, but I declined the offer.

Not that I didn’t like it, because I did, but I promised my mom to carry on her work. As a Doctor. To help people in need. Yeah mom. I made you that promise, and I am a man of my word, so I will do that. Happily.

This is also the reason why you see me using my title (Dr.) for the very first time, here, and in my scripts, and other source code. Something I have refuses to do for many years. Simply because this is not my day job.

Now what?

I am happy to announce that I am set to retire at Google next year, and do something completely different. This was a very difficult decision, and that was why, in part, we went off sailing this summer.

Also. You must have noticed that some of your comments got approved, some time before the actually reply. And you know what. There is a simple explanation for it. The approval is actually done by someone else. My very own sidekick (my wife Angélica who is working as one of the hosts in our hotel in Spain).

In other words. We will carry on with the legacy of Master Chief (Pike’s father) and Revogirl (Pike’s late sister). For as long as possible.

What about you? Will you be here up for another decade?

Thank you!

installSeed.py v4.0 released…

Update: version 4.1 includes two bug fixes and now also supports -a update (to install updates).

I still have some partitions with older versions of macOS High Sierra, and I ran installSeed.py v3.8 on one of them to get the latest beta, but all I got was the previous one. Hmm. That’s odd. That’s not the expected result. Something was wrong.

I checked the catalog data and noticed that we have two sets of updates. Hmm. An unusual situation. Which is not supported in version 3.8. I wanted to have it fixed a.s.a.p. and thus my work was committed 10 hours ago already. But I ran out of time, and energy, to blog about it so here you have it. I hope that installSeed.py v4.0 also works for you. Let’s look at the changes.

This is the output when you run: ./installSeed.py -t /

-----------------------------------------------------------
installSeed.py v4.0 Copyright (c) 2017 by Dr. Pike R. Alpha
-----------------------------------------------------------
Currently running on macOS High Sierra 10.13 Build (17A360a) 
Seed Program Enrollment: DeveloperSeed
Searching for macOS: 10.13.1

ERROR: target macOS version (10.13.1) not found. Aborting ...
       - you may need to use the -m <version> argument

Right. The target test partition is still running an older version of macOS 10.13 but the script is already checking for 10.13.1 (per default). As it should. And thus all I had to do was to add the -m 10.13 arguments. Like it says now. Fine. Let’s do that.

./installSeed.py -t / -m 10.13

This is the result.

-----------------------------------------------------------
installSeed.py v4.0 Copyright (c) 2017 by Dr. Pike R. Alpha
-----------------------------------------------------------
Currently running on macOS High Sierra 10.13 Build (17A360a) 
Seed Program Enrollment: DeveloperSeed
Searching for macOS: 10.13

[ 1 ] Found update for macOS 10.13 (17A362a) with key: 091-32527
      - seed build version is newer than macOS on this Mac (Ok)

[ 2 ] Found update for macOS 10.13 (17A405) with key: 091-36857
      - seed build version is newer than macOS on this Mac (Ok)

Select package to install [1-2]

Cool. Next I tried it with the -a update arguments and got this.

-------------------------------------------------------------
installSeed.py v4.0 Copyright (c) 2017 by Dr. Pike R. Alpha
-------------------------------------------------------------
Currently running on macOS High Sierra 10.13 Build (17A360a) 
Seed Program Enrollment: DeveloperSeed
Searching for macOS: 10.13.1

[ 1 ] Found update for macOS 10.13.1 (17B25c) with key: 091-28823
      - seed BuildID is newer than macOS on this Mac (Ok)

[ 2 ] Found update for macOS 10.13.1 (17B35a) with key: 091-35887
      - seed BuildID is newer than macOS on this Mac (Ok)

Select package to install [1-2]

Perfect. Looks like this issue is resolved in installSeed.py v4.0

Anyway. I hope that you enjoy using the latest update, and please, don’t forget to star it on Github. Thank you!

Intel to remedy heat for Apple’s new iMac Pro with special Xeon W SKU’s…

Previously I assumed that Apple was going to use one of these Xeon W models, but it turns out that I was wrong – based on new data that I found. Intel apparently makes special (OEM) SKU’s for Apple’s new iMac Pro, and here are the first two known models:

Intel Xeon W-2140B @ 3.2GHz ( 8 cores / 16 threads, CPUID 0x050654)
Intel Xeon W-2150B @ 3.0GHz (10 cores / 20 threads, CPUID 0x050654)

Both running with a lower base frequency than the W-2145 (3.7GHz) and W-2155 (3.3GHz). And there can only be one reason for this. Heat!

Source: Geekbench OpenCL Score 1 and 2
Note: Don’t you worry about the results. Apple isn’t showing it’s hand just yet – the used GPU’s were running at a lower frequency.

Additional data

The board-id that I found in the (assumed) firmware of the iMac Pro is: Mac-7BA5B2D9E42DDD94 and some of the data that I found earlier may be an indication that the new B serie processors include support for processor graphics (IGPU). Another key factor that contributes to the need for a lower base frequency.

Intel Speed Shift Technology

I disassembled the first High Sierra Beta XNU Kernel, months ago, and I found out that Intel Speed Shift Technology aka HWP is set to enabled for processors with CPUID 0x05065X. Like the Intel Xeon W-21NN series processors.

Internal Graphics

Back in June I was surprised to find a reference to “Integrated Video Controller” in the leaked firmware for the iMac Pro. Some time later I also found data in the info.plist of AppleGraphicsDevicePolicy.kext that shows us that Apple disables – note the unload key – the IGPU (the internal GPU). Look here:

<key>ConfigMap</key>
<dict>
    <key>Mac-77EB7D7DAF985301</key>
    <string>none</string>

That coupled with this snippet:

<key>Config4</key>
<dict>
    <key>GFX0</key>
    <dict>
        <key>EDID</key>
        <dict>
            <key>index</key>
            <integer>0</integer>
        </dict>
        <key>FeatureControl</key>
        <integer>12</integer>
        <key>unload</key>
        <false/>
    </dict>
    <key>IGPU</key>
    <dict>
        <key>unload</key>
        <true/>
    </dict>
    <key>display</key>
    <dict>
        <key>EDID</key>
        <dict>
            <key>index</key>
            <integer>0</integer>
        </dict>
        <key>FeatureControl</key>
        <integer>12</integer>
        <key>unload</key>
        <false/>
    </dict>
</dict>

This may well be an indication that the new Intel Xeon’s do in fact support processor graphics, but we will have to wait until the actually release of the iMac Pro, or macOS High Sierra 10.13.2 (which Apple appears to be using internally already) before we really know what is going on here.

Edit: If you use my blog article as source, then please be so kind to add a link/reference. Thank you.

Don’t be an ass. Like mac4ever.com for the lack of reference (shame on you) because seriously guys… as a die hard Googler, nobody else blogged about it before I did!