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.

Advertisements

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 😉