OperationRegion GNVS

Hm. This is interesting. The address of the OperationRegion (GNVS, SystemMemory, 0xDC227C18, 0xNNNN) in my vanilla factory DSDT changes when I boot from a USB memory stick. It is normally 0xDC227C18, but if I boot from a USB memory stick then it is 0xDC226C18. Odd. Isn’t it.

The reason for this 4 KB difference is unknown to me. Do you know why? If yes, then please let me know. Thanks!

Edit: I re-wrote a feature that I added to RevoBoot some time ago, which I lost with the SSD failure, but the new one should be fine. It is a bit different, but the new source code is already committed from dads computer. This way other developers – think Chameleon and Chimera devs – can use it for their boot loader. With a few changes of course 😉

SSD Failure

Just to let you know. One of my main SSD’s (OCZ brand) failed a few days ago and I am trying to get everything back on-line. Yup. I also lost a lot of time (lost password issues among others) but more importantly… some of my best work for the boot loaders that I am working on went down the drain. Need to start over again from scratch. Right. Sh*t happens. What else is new. But I’ll be back soon 😉

Edit: I am still having difficulties with my Paypal account access (lost password) but I am trying to solve this with Marcos from Paypal. I would advise anyone to not make any donation until this issue is fixed. Thank you! Lost password issue resolved!

Edit-2: I decided to pay dad a visit and ask for help. Sort of a last resort thing. Made some progress. Can now boot from the SSD, but it stops prematurely. Just before entering single-user mode and thus I cannot repair the drive. Looks like a HFS file system failure. Presumably cause by a drive-hardware failure.

GA-Z87M-D3H USB keyboard/mouse wake problem

I have helped someone I know setting up a GA-Z87M-D3H (F11 BIOS) as hack and noticed a couple of oddities. First we had to solve the USB stutter and random hangs but USB keyboard/mouse wake events only worked after a restart. A warm boot. We now also solved this problem, and we did that by altering this UEFI BIOS setting

Without Erp enabled in the BIOS it simply didn’t work. And for your info. USB 3.0 on this motherboard works without any kind of DSDT edits. We only added a _DSM method for additional power.

            Device (XHC1)
            {
                Name (_ADR, 0x00140000)  // _ADR: Address
                Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
                {
                   0x0D, 
                   0x04
                })

                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If (LEqual (Arg2, Zero))
                    {
                        Return (Buffer (One)
                        {
                            0x03
                        })
                    }

                    Return (Package (0x09)
                    {
                        "AAPL,current-available", 
                        0x0834, 
                        "AAPL,current-extra", 
                        0x0A8C, 
                        "AAPL,current-extra-in-sleep", 
                        0x0A8C, 
                        "AAPL,max-port-current-in-sleep", 
                        0x0834, 
                        Buffer (One)
                        {
                             0x00
                        }
                    })
                }

                Device (RHUB)
                {
                    Name (_ADR, Zero)  // _ADR: Address
                }

                Method (MBSD, 0, NotSerialized)
                {
                    Return (0x01)
                }
            }

That’s it.

The stripped DSDT for the Gigabyte Z87M-D3H blog post also includes a link to my Github repository where you can download this DSDT.

Have fun!

Stripped DSDT for Gigabyte Z87M-D3H

Yesterday I blogged about the USB stutter and random hangs that I was trying to resolve, and one of the things that I did was to strip the DSDT. Not that it was that much smaller, and thus I asked my father for a bit of help. After just 30 minutes… it suddenly went down from 52365 bytes to only 5922 bytes. I tell you. That is a lot less than what I had.

Too bad that the thirty minutes dried up so quick, and that dad had to leave to catch his flight back home. Luckily, he gave me some tips and today I had another stab at it. The computer that we used, which is actually a GA-Z87MX-D3H but the DSDT is for a GA-Z87M-D3H, still boots from the USB 2.0 memory stick, which is painfully slow by the way, but now it does it with just 3292 bytes. This instead of the 5922 bytes I started with.

The new static DSDT appears to be working. Sleep/wake works properly. Reboot and shutdown too. Audio works, and the Ethernet port and WiFi/Bluetooth module are still fine. Power management is also ok with a ssdtPRGen.sh generated SSDT. USB 2.0 and USB 3.0 is also functional, be it with the same annoying mouse stutter at startup. The good news is that I received the source code, be it the USB only bits and pieces, and thus the hunt for the error will start tomorrow…

Anyway. You can find my (example of a) stripped down DSDT in my Github repository but please be aware that it may not work, most likely not, on other hardware. With a different BIOS version, or with a different IGPU memory setting, and more/less memory than the two 4GB memory modules that I have installed on this motherboard.

Also. Do not change your _CRS object data. Not without knowing what you are doing!

Have fun!!!

Edit: To me American Megatrends, Inc. is a serious company, with dozens of BIOS developers, and they write BIOS code for all kinds of motherboard… but they do this without having a single target motherboard. All testing is done by the vendor itself. Not by AMI. So much for fake facts from you know who…

USB stutter and random hangs

I spent some time with my father, during our Christmas holiday, on ACPI table stripping. We did this because someone we know has issues with a Gigabyte motherboard that I sold to her, where USB stalls (mouse stutter) during the first few second of OS X boot time. Another person, Lars from Germany, is also experiencing random hangs on the same Gigabyte GA-Z87M-D3H. So two people with the same motherboard, with different processors, are having issues with the latest BIOS (F11b).

The first thing that I did was to take out the processor and hard drive and installed it in my Gigabyte GA-Z87MX-D3H. Here I had no issues with USB during boot time, and I also can’t remember having seen a single hang when I used this motherboard.

Then I took out the RAM and swapped it with mine. Same problem. No problem with her RAM modules on my motherboard. We ruled out the actual installation of OS X and the hard drive, by swapping the drive. The RAM modes are also fine. I kind of knew this because I used the modules myself before I sold the modules with the PC.

The next step was to go back a couple of BIOS revisions, but that didn’t help either. Then, and this is where my father came in handy with his ACPI know-how, we stripped the factory DSDT (52365 bytes) down to 5922 bytes in under 30 minutes, but the problem persists.

What I did notice was that the PC booted faster with the stripped DSDT. Presumable because it is smaller now, taking less time to load the file, and it executes quicker sans all ACPI errors. We might need to re-investigate DSDT table stripping, because it looks like that people are underrating the importance of it. Probably because they have no clue whatsoever.

Anyway. What I plan on doing today, when I can find the time for it, is to check the PSU. This to rule out that the PSU is the problem. I don’t expect it to be the cause of the problems, because then two people with different PSU’s would have a broken/unsupported PSU. No. My best guess is that the BIOS is the root cause of the USB stalls and random hangs. I know that my GA-Z87MX-D3H has no issues so I may have to extract the USB driver from the BIOS and inject it in the BIOS of the GA-Z87M-D3H.

Yes. I do have a BIOS programmer. That is not the problem, but the BIOS chips are soldered on the motherboard. And I would rather not mess with the motherboard. Yeah. I know. I am forced to do it anyway. Or am I missing something here?

This brings me back to my previous blog post. It would have been great if we could get access to the BIOS source code, because then this problem would have vanished the same day, but we all know that this is not going to happen. Nope. BIOS vendors have to protect their corporate interests, and they will keep telling you that what they do is for your own protection… You just have to life with their bugs and fake security. Or wait for people like me who don’t give a BEEP and rip their BIOS apart 🙂

Update: I installed a GPU card on a GA-Z87M-D3H v1.1 motherboard that I got from Gigabyte for my test runs, and that appears to be a good workaround. This also worked on the GA-Z87M-D3H v1.0 that I sold, and thus installing a video card solve the mouse stutter and random hangs on both versions.

Update-2: It turns out that the mouse stutter – mostly seen at boot time and after a sleep wake cycle – is much simpler to solve than I thought. First I fired up Activity Monitor and rebooted… to find out that displaypolicyd (a daemon) was taking way too long at boot time. Yes. I had indeed changed this plist:

/S*/L*/E*/AppleGraphicsControl.kext/C*/P*/AppleGraphicsDevicePolicy.kext/C*/Info.plist

Where I replaced Config2 with none (see also this blog post) for the Mac-F60DEB81FF30ACF6/MacPro6,1 setup that I used. The problem was that I forgot that they had setup their hack as Mac-42FD25EABCABB274/iMac15,1. That was the real problem, because they did not make this change for the Mac-42FD25EABCABB274/iMac15,1. This is also why it used to work for me when I used this motherboard, because I did make the change, but they did not. In short. This is their own mistake. And also my own stupid mistake, because I failed to notice the difference.

My only excuse is that I had to work remote on this particular setup, because it is no longer mine. It is now owned and controlled by someone who lives almost 2000 KM away from me. I also no longer have a GA-Z87M-D3H motherboard, because I was asked to return it. In short. This specific problem was not caused by a BIOS bug!

Happy 2015

Happy 2015 folks!

All the best to you and your family.

What do I want in 2015?

Health is key to me. I have witnessed it go bad and worse, twice, so health is my absolute number one priority. Other than that. A bit of luck from time to time.

I also hope that Apple comes out with something really innovative, because to be honest, I was rather disappointed with what Apple did in 2014. In short. For me there was too much of the same old stuff.

Next to that. Companies like: Asus, AsRock, Gigabyte and MSI – just to name some – should invest time and money to give us Thunderbolt 2 support, and out of the box. No hacks. It should just work. But no. Intel is betting on Thunderbolt and thus USB 3.1 – a cheaper/competing technology – is still missing in the enthusiast chipset (Z170) for Skylake.

Also. Where is that motherboard company with a real, and I mean 100%, compatible Mac motherboard? Not some hobby project (edit: from Quo computers) with outdated hardware and broken promises, but from a real company. I mean I understand that they won’t add SMC integration, but why can’t we have a motherboard with Broadcom BCM4360 integration for WiFi and Bluetooth v4.0, M2X4 slot for a Samsung XP941, proper audio chip with matching setup, and a frame buffer and Gigabit Ethernet that works out of the box? That would be a huge step forward wouldn’t it?

Another thing that I would love to see is a change of mind, because to me UEFI BIOS vendors should open up. Give people the source code, and all of it. Starting with older hardware, so that people can fix bugs and enhance their BIOS. Either that or UEFI should be ignored. Just my 2 cent.