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!

Advertisements

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

  1. Hi Piker, im using now 10.13.1 (17B35A)
    Still not able to boot with 0x050654 (Thats my native CPUID of 7900x)
    (It hangs on Aptiofix… Nvram…)
    Just for the Info 🙂

    Cheers 🙂

      • yes, 0x0506E4
        Everything else I tried so far, doesn’t boot… doesn’t pass nvram… or kernel init?
        Something at the very beginning of booting…

        Cheers 🙂

      • Your i9-7900X does not support Intel® Speed Shift Technology aka HWP, but that will be set to enabled for processors with CPUID 0x05065X. Look here:

        loc_ffffff80003a6a3c:
        ffffff80003a6a3c         mov        dword [_xcpm_cpu_model], 0x4000             ; case 25, CODE XREF=_xcpm_bootstrap+124
        ffffff80003a6a46         mov        dword [_xcpm_config+204], 0x0
        ffffff80003a6a50         mov        qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b         mov        dword [_xcpm_config+560], 0x1
        ffffff80003a6a65         mov        dword [_xcpm_hwp_enabled], 0x1
        ffffff80003a6a6f         jmp        loc_ffffff80003a6a85
        

        Try NOP’ing out that last move, or use 0.

      • Piker, you mean to replace that in the kernel?
        Like:

        Name: _xcpm_hwp_enabled (disable)
        Find: ffffff80003a6a65
        Replace: ffffff8000909090

        Do i understood you right?

        If yes, i will test later and report 🙂
        Thank you very much!

      • Hi again,
        I can pass OsxAptioFixDrv (Nvram),
        which I normally can’t with 0x050654

        But it hangs on:
        Macos is not supported on this System, Reason:
        Mac-7BA5B2D9E42DDD94

        So I can’t boot with iMacPro SMBIOS… on 10.13.1 Update 2

        With the HWP,
        I don’t get you, why do I need to NOP out, if its supported on 7900x?
        I need to look inside the bios files of the rampage with amibcp for speed shift and CSR 0xE2 entrys…

        The other thing is, ive searched in the Kernel for ffffff80003a6a65…
        I can’t find the entry in the 10.13.1 kernel…
        The only thing I found is at offset 11654232 (_xcpm_hwp_enabled) the text only…

        Cheers Piker 🙂

      • Ah ok so you are using an unsupported board-id (Mac-7BA5B2D9E42DDD94). That won’t work. Not yet. For now. Install with a different board-id.

        About the HWP issue. I didn’t know the exact board-id/model that you were using, and the former turns out to be a problem for the actual installation – not for HWP.

        Now. The problem, for certain board-id’s, is that HWP is also enabled by a setting in the Mac-XXXXXXXXXXXXXXXX.plist and since HWP may only be enabled once, you should not use a board-id that also enables HWP. The one you are using is fine.

        p.s. The latter can be checked with help of: sudo freqVectorsEdit.sh -d 1

      • Thanks Piker for the tip.
        Ive tryed now different board ids with and without HWP, doesnt matter i cant boot with 0x050654…
        The whole idea for me was in first place to get rid of voodootscsync kext and in second place, to get a more similar cpuid for the Skylake-X CPUs.
        The 0x0506E4 works good, especially if you enable HWP, you get the same performance as in windows.

        With HWP i get in cinebench r15 for the 7900x 2420-2450 points and 183-185 single core points.
        Without HWP, i get 1700-1900 and ~160 points.
        (All cores synched and 4,5ghz oc)

        As far i can tell, the difference comes not from HWP itself.
        If HWP is disabled, my CPU gets max ~82 degrees and throttle.
        With HWP, my CPU reach 95 degrees and doesn’t throttle.

        However, seems like we are stuck with 0x0506E4 and voodootsc…

        Thanks piker:-)
        Cheers 🙂

      • The fact that you get a lower Geekbench score. Well. That is a power management related SSDT problem. It has nothing to do with HWP. Both should work.

        Also. I did actually test an engineering sample of the Intel i9-7900X with RevoBoot, and never used a fake CPUID so something strange is going on. I’ll have another look at my notes and will report back to you when I find something, but I received tho new processors that I like to test before I will need to return them.

  2. Pingback: Nuovi iMac Pro, primi indizi sui processori Intel Xeon ideali per Apple - Macitynet.it

  3. Pike, we found it out.
    Or better to say, one other guy in the tonymac forums… (TheOfficialGypsy)

    We need the XCPM Bootstrap Patch, then we are able to boot with 0x050654…
    Or any other cpuid that we want…

    That means in 10.13.1 17B35a, there is no kernel or xcpm support for Xeon-W or Skylake-X.
    or at least not for the iMac17,1 smbios…

    That means for me, there is nothing more to experiment.

    Cheers.

      • Thanks, but that basically does the same thing as using a fake CPUID. A stupid work around to just not a fake CPUID. Not good.

        What you really want is to look at this snippet in _xcpm_bootstrp:
        ffffff80003a6a3c mov dword [_xcpm_cpu_model], 0x4000
        ffffff80003a6a46 mov dword [_xcpm_config+204], 0x0
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        ffffff80003a6a65 mov dword [_xcpm_hwp_enabled], 0x1

        now look at this line:
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        That line is used to select the MSR to write to (IA32_HWP_REQUEST_PKG or IA32_HWP_REQUEST) but that MSR may not be supported by your processor. What I would do is change it to zero (0). And if that still doesn’t work, then take a look at this line:
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        Change that to 0x7a120 or nop it our completely.

      • Piker, you are giving me good advices, the problem is, you are looking in to the disassembled kernel and I am looking into the working/compiled kernel.

        I don’t know how to disassemble the kernel, or where to look in the running kernel with your infos.
        Cheers Pike.

      • 1.) Open the kernel in Hopper
        2.) Search for “_xcpm_bootstrap”.
        3.) Click on “_xcpm_bootstrap” in the symbols and string panel (at the left).
        4.) Scroll down to loc_ffffff80003a6a3c.

        There you have it. It’s there right in front of you 😉

        You can then open the kernel in a Hex Editor and search for the address or pattern and path it (in Clover if you like).

      • Ive disassembled the kernel and found the entrys!!!

        Thank you very much!

        Now I need just to find out how to translate that code into the compiled kernel, for clover patching… xD

        Cheers 🙂

      • Example: mov dword [_xcpm_config+560], 0x1

        That is (in hex code)..: C7 05 13 96 68 00 01 00 00 00
        You want to change I to: C7 05 13 96 68 00 00 00 00 00

        I don’t know if Clover wants it in reverse, but that is easy for you to find out. If not. Then you can use this:

        echo -n “C7051396680001000000″|xxd -r -p|base64
        echo -n “C7051396680000000000″|xxd -r -p|base64

        Otherwise just flip the bytes 😉

      • awesome!

        I’ve got it!
        I understand now your infos xD

        Thank you very much!
        Now I know what I need to look for, where, and how to translate that!

        Going to try now! Thanks!!!

        Cheers!

      • Nothing works:-)
        Ive tryed
        _xcpm_config+560 (with changing to 0)
        _xcpm_config+120 (to 0x7a120 and 0x000000)
        _xcpm_hwp_enabled (with changing to 0)
        Nothing of them or any combination of them worked.

        And ive tryed 0x050654, 0x050652 and 0x050650 as cpuid…

        Cheers pike:-)

      • You should first patch the kernel file and verify the changes in Hopper. Only use Clover patches afterwards, when everything works. Also. don’t use a fake CPUID.

        You should also make a combination of all patches. Also change 0x4000 to 0x2000 or any other value that is used. Like 0x1000 and 0x200.

      • Piker, is there a way to verify the cpuid?
        Because without fake cpuid i think clover injects automatically 0x0506E4…
        Tools like geekbench, cinebench, your appleintelinfo kext reports 0x050654, even if i set the xeon fake id…

        Had no time yesterday to patch the kernel directly… Because im upgrading my pc… And this can take a bit longer, because im working very much in my company 😦

        And i didnt got what you meant with combination of patches. 0x4000… 0x2000…

        Cheers:-)

      • 1.) You need to take the fake CPUID injection thing up with slice and other Clover coders/users.

        2.) Let’s take a look at that snippet:

        ffffff80003a6a3c mov dword [_xcpm_cpu_model], 0x4000
        ffffff80003a6a46 mov dword [_xcpm_config+204], 0x0
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        ffffff80003a6a65 mov dword [_xcpm_hwp_enabled], 0x1

        There you have the 0x4000. It’s another value for other CPU models. Hence the suggested use of 0x2000 and the other values. Look at the values in: xnu/osfmk/i386/cpuid.h:

        0x3c => 0x4.   (CPU_MODEL_HASWELL)
        0x3d => 0x80.  (CPU_MODEL_BROADWELL/CPU_MODEL_BROADWELL_ULX/CPU_MODEL_BROADWELL_ULT)
        0x45 => 0x10   (CPU_MODEL_HASWELL_ULT)
        0x46 => 0x8.   (CPU_MODEL_CRYSTALWELL)
        0x47 => 0x40   (CPU_MODEL_BROADWELL_H)
        0x4e => 0x200  (CPU_MODEL_SKYLAKE/CPU_MODEL_SKYLAKE_ULT/CPU_MODEL_SKYLAKE_ULX)
        0x55 => 0x4000 (CPU_MODEL_SKYLAKE_W)
        0x5e => 0x2000 (CPU_MODEL_SKYLAKE_DT)
        0x5d => 0x0    (not there)
        0x8e => 0x200  (CPU_MODEL_KABYLAKE/CPU_MODEL_KABYLAKE_ULT/CPU_MODEL_KABYLAKE_ULX)
        0x9e => 0x1000 (CPU_MODEL_KABYLAKE_DT)
        0x9e => 0x2000 (CPU_MODEL_KABYLAKE_DT)
        

        Only two processor models (0x3d and 0x45) set this to one:
        mov dword [_xcpm_config+204], 0x1
        You don’t want that. But that’s ok for your processor model (CPUID).

        Only one processor models (0x55) set this to one:
        mov dword [_xcpm_hwp_enabled], 0x1
        That will match with your processor (CPUID). And that may be a problem as the bit in this MSR can only be set once. Like I said earlier. Some resource plist will also try to enable it. That won’t work. Hence the tip to NOP it out. Ot at least make sure that the plist that matches with your board-id won’t also try to enable HWP. Or Clover!

        What I would do is use 0x1000 or 0x2000 instead of the 0x4000 and NOP this block out:
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        ffffff80003a6a65 mov dword [_xcpm_hwp_enabled], 0x1

        If that works, then you know where to look for the problem.

      • Piker, thank you very much, I’ve pointed it out…
        Its exactly how you have it sayed…

        I’ve just always tried wrong combinations 🙂

        Its working if you don’t inject any Fakecpuid at all with imac17 smbios.
        If you inject, even the same Cpuid as you actual CPU have, its not working (thats curious, I don’t understand why)
        And if you don’t inject any at all, its booting… without any problem…

        The other thing is, if you try the same with the imac18 smbios, its not booting…

        So it boots only without fakecpuid on imac17 smbios…

        Dunno why i was so stupid…
        But In any cases I still need the Crappy VoodooTSC…

        So it doesn’t made anything better or different at the end 🙂

        Thank you Piker very much!!!!

      • Should work with 10.13.1 (release) but Night Shift is now also supported in 10.13.2 (Beta) so I would use that. Despite the possible hiccups. A new Beta is looming already so whatever 😉

  4. I have tried using the iMacPro1,1 SMBios data on both 10.13.1 and 10.13.2 dp 2 using the latest clover rev 4293 with no luck, I get an error saying the board ID is not supported. Any ideas on how to get the system booting?

    • Piker, the Gypsy have right,

      At the moment with board id of
      Mac-7BA5B2D9E42DDD94

      We can’t boot.

      On 10.13.1: You get that not supported logo… (So seems its not implemented in that build)
      On 10.13.2 d2 I can’t pass OsxAptio. (But it seems for me like not supported too)

      In the meantime I found out, why I had previously that many problems… (With the Fakecpuid thing)
      There is a clover bug, if you have more as one config.plist and you switch the configs…
      For example, if in your main config.plist stays FakeCPUID: 0x0506e4 and in your second (for example) config18.plist is no FakeCpuID defined, and you load config18, you have still 0x0506e4 as FakeCPUID…
      Because new configs only overrides values, but if a value is missing in the new config18.plist, the default value from config.plist is still there…

      Thats a bug, I think no one noticed till now…

      Thats why I had so much problems and strange issues…
      i have more as one config.plist for experimenting… 🙂

      Thanks Pike, we need to see further, with 10.13.2 D3 / or PB1?

      Cheers 🙂

      • Hmmm no matter what I try I just cannot get the iMacPro1,1 loading, as Ramalama said I am stuck on the prohibited sign. I have tried with and without VoodooTSCSync, with and without CPUID 0x050654 with no luck.

        I have a feeling I have incorrectly setup the SMBIOS section in clover.
        Could you detail which iMacPro1,1 SMBIOS data to include in clover?
        Currently I have:

        Product name: iMacPro1,1
        Family: iMacPro1,1
        Manufacturer: Apple Inc.
        Bios Version: IMP11.88Z.0058.B00.1705091711
        Bios Release Date: 08/08/2017
        Bios Vendor: Apple Inc.

        Chassis Manufacturer: Apple Inc.
        Location in Chassis: Part Component
        Chassis Asset Tag: iMac-Aluminum
        Chassis Type: 0x09
        Board Type: 10
        Board Serial Number: Irrelevant?

        Serial Number: Irrelevant?
        SmUUID: Randomly generated
        Mobile: Unchecked
        Trust: Checked

        Firmware Features: 0xFC0FE136
        Firmware Features Mask: 0xFF1FFF3F
        Platform Features: 0x00
        Version: 1.0

        Any ideas?

      • The family should be “iMac” since that’s what Apple is usings in their ACPI tables but it’s more likely boot.efi or Clover related. I’m not pointing a finger here. Just trying to be helpful.

        What you could do is replace one one of the supported board-id’s in boot.efi and see if that helps.

        p.s. Software updates will fail with the iMacPro1,1 SMBIOS. You can work around this by using a different SMBIOS and switch back after the installation is done.

      • I have no idea how to “replace one one of the supported board-id’s in boot.efi” but no matter to configuration I just cannot get past the prohibited sign.

        Should I be trying without VoodooTSCSync and the FakeCPUID? Also should the “Kernel to Patch” field be empty or which patches should be enabled?

      • I think on the next dev preview we have more information on the smbios.

        Im waiting for the next one.

        Bootefi should be located under
        /.IABootFiles/boot.efi

        I think what piker means is replacing with hex editor, one of the working board ids like from imac 17 or 18 with the new one from imacpro.
        I havent looked into bootefi, had no time, but there should be somewhere the board ids, maybe in reverse order.
        Maybe you can get it easyer if you decompile the boot efi and check where you need to replace the hex code.

        Like piker described already in previous comments here…

        I will check today later, after my work, what we need to replace.
        I Had no time last days for good testings, so im sry:-(

        Piker, i have another question about revoboot. You are using it for your hackintoshes?
        And if yes, do you have nvram working?
        Because the last working nvram (without emulation) i have is with skylake on z170.

        Just wondering about revoboot, because ive never tried and now its get more and more interesting 🙂

        Cheers

      • You cannot boot the installer with the iMacPro SMBIOS. You need to use another board-id. For now.

        Yup. Replacing one of the board-id’s in boot.efi might work, but only if it isn’t Clover trowing the error.

        Yes I use RevoBoot but no NVRAM is not working. Last time I checked was years ago already. I am only using my hack for fun and testing so I don’t care about it.

      • Pike, we dont want to boot the installer, we have already osx 10.13.2 d2 running perfectly with smbios 17 or smbios18.
        We want just switch the smbios to imacpro… For experimenting…

        Im going to wait for 10.13.2 d3… Maybe we can boot on that version.

        Ok, than revoboot doesnt seems that interesting as i thinked:-)

        Thank you very much Piker for all your efforts.

        Cheers:-)

  5. Oddly enough I managed to get my build to boot with iMac19,1 and Mac-CF21D135A7D34AA6.
    I also managed to boot without VoodooTSCSync or FakeCPUID, however I still have to use the usual ‘KernelToPatchs”. Hopefully with 10.13.2 B3 we’ll have more luck

    • If you get a good cpu Performance without Voodootsc, its a good indicator that our cpus will be supported.
      Thanks for your reply gypsy.

      By the way, which kernel patches do you use?

      Cheers:-)

      • That’s exactly what I’m hoping for.
        I was pretty shocked that it worked without the kext.
        I am using the 3 patches from KGPs guide, without them I can’t boot.
        – Pike’s xcpm_core_scope_msrs
        – Pike’s xcpm_bootstrap
        – 10.13 Installer / Updater essential

        I have no idea why the iMacPro1,1 SMBios doesn’t want to work along with the board ID of Mac-7BA5B2D9E42DDD94

        Regards

    • Does iMacPro1,1 with Mac-CF21D135A7D34AA6 work for you?

      What happens when you use iMac19,1 and Mac-7BA5B2D9E42DDD94?

      Can the error message be found in the Clover source code?
      What is the exact error that you get?

      Edit: The problem is that Apple’s is using both iMacPro1,1 and iMac19,1 in combination with board-id Mac-7BA5B2D9E42DDD94. One example is: Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBXHCIPCI.kext/Contents/Info.plist where iMac19,1 refers to board-id Mac-7BA5B2D9E42DDD94

      Apple may use iMac19,1 now, to hide it for the prying public eyes, and later rename it to iMacPro1,1 After all. The did add a new entry for Nigh Shift, where they check for 1,1 and thus that has to be a new product – since there is already one for the iMac.

      • I can confirm iMacPro1,1 with Mac-CF21D135A7D34AA6 does work, without VoodooTSCSync and FakeCPUID. However I am still forced to use the 3 patches:
        – Pike’s xcpm_core_scope_msrs
        – Pike’s xcpm_bootstrap
        – 10.13 Installer / Updater essential

        Anything that uses Mac-7BA5B2D9E42DDD94 fails to get past the prohibited sign.
        When booting with -v flag nothing gets displayed.

      • Ok that is one step closer for Clover users, because here it works, but I don’t use Clover but RevoBoot.

        Edit: I don’t think that it is boot.efi related, since you can also use board-id’s that cannot even be found in boot.efi

      • Sry for the late answer, in the meantime ive tested the tips from gypsy…

        If we use bootstrap patch, its same as we would use fakecpuid, its just another workaround…

        I can boot too without voodootsc, but the pc is slow as shit, so no improvements at all.
        The Mac-CF21D135A7D34AA6 boardid works with imacpro1,1, but i see no benefits at all.

        And the 7BA5B2D9E42DDD94 board id still doesnt work on newest beta 17c79a… (the latest at this post dont remember if 17c79a is right)

        So there is nothing new.

        @Gypsy
        Are you sure that you booted with out voodootsc? Maybe you had it in cache?
        Or if its working, what do you use in bios? I mean “sync all cores” and did you have hwp in bios enabled/auto/or disabled?

        Cheers

  6. To boot 10.13.1 with iMac19,1 & Mac-7BA5B2D9E42DDD94 just use -no_compat_check in boot args.
    I’m using Clover and custom dsdt table with my Core i9-7900X.
    I dropped all OEM ssdt tables (and the one which is CpuPm). I don’t use any CPU-related ssdt at all. I don’t use Clover’s feature which generates P-states (and C-states as well). No kext and kernel patches related to CPU are in Clover config.
    For CPU I only added into dsdt a _DSM with ‘”plugin-type”, One’ to enable X86PlatfomPlugin and I see in my boot log “XCPM mode” string.
    Intel Power Gadget indicates that idle freqs are 1-2Ghz, and max boost is 4.5GHz. Geekbench 4 score is 42526.

      • I have no luck getting this to boot, im just stuck at the apple boot screen in clover.
        Also do you boot with these patches? The only way I can get it to boot is by using these patches:
        – Pike’s xcpm_core_scope_msrs
        – Pike’s xcpm_bootstrap
        – 10.13 Installer / Updater essential
        and also VoodooTSCSync
        Could you link your EFI folder?

      • Yes, I do use VoodooTSCSync.kext.
        PowerNap is available in prefs, but I disabled it so far. Actually, it’s still work in progress, for example, sleep mode doesn’t work properly yet.

      • Thanks joe!
        Uff your dsdt is so clean, dunno how much time you spend to merge it so beatifull together.

        Great job!

        Need to check your smbios part on my board, if i can boot with it.

        Thank you! Cheers

      • Nope, ive tryed Smbios section and even the complete config (with modifications), cant boot with that board id of imac pro…

        Still the “No Sign” because of wrong board id… lol… with 10.13.2 (17c79a)
        There must be sth bios related or sth different…

        By the way, the only known difference that i know with the asus vs gigabyte board, is that you can disable MSR 0xe2 or (CSR lock) on the gigabyte… on asus boards its not possible…

        Cheers 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s