Half-bricking Surface 3 on 7.1 RC1?

[Kagami Rosylight]

(Note: I have no intent to require any compensation.)

I think the 7.1 RC1 has a serious problem that can half-brick Surface 3 devices, where 'half-brick' means your hardware description table will be ruined so that OSes cannot properly install the required drivers. Your DMI table will say "Manufacturer: OEMB/Product Name: OEMB" instead of "Surface 3/Microsoft", and your serial number will be erased. Initially you will see red boot screen because of the sudden disappearance of UEFI certificates, and ultimately you won't be able to install any Surface software or to run VT-dependent virtual machines (on Windows), or play any sound (on Android).

I've experienced this problem for multiple times, has anyone did yet? What would be the cause?

[Chih-Wei Huang]

2017-08-25 16:32 GMT+08:00 Kagami Rosylight <bwst...@gmail.com>:
> (Note: I have no intent to require any compensation.)
>
> I think the 7.1 RC1 has a serious problem that can half-brick Surface 3
> devices, where 'half-brick' means your hardware description table will be
> ruined so that OSes cannot properly install the required drivers. Your DMI
> table will say "Manufacturer: OEMB/Product Name: OEMB" instead of "Surface
> 3/Microsoft", and your serial number will be erased. Initially you will see
> red boot screen because of the sudden disappearance of UEFI certificates,
> and ultimately you won't be able to install any Surface software or to run
> VT-dependent virtual machines (on Windows), or play any sound (on Android).

Oh! Me too.
I encountered the exactly same issue recently
though I don't think it's caused by 7.1-rc1.
I guess it's a bug in the UEFI BIOS but
I may be wrong.

I have tried several ways to fix it includes
replacing known good DSDT tables by kernel,
restoring to factory from Windows, etc
but none works.

About the Windows issue (unable to install/update software),
I was not aware it's caused by the problem.
(I just thought it's a network problem)

About the no sound issue on Android/Linux,
I've tried Fedora 26 or Ubuntu 17.04 but none of them
works. They have exactly the same problem:
module auto detection wrongly loads the driver
snd-soc-sst-bytcr-rt5640. But even I manually loads
the driver snd-soc-sst-cht-bsw-rt5645 it still doesn't work.

However, to my surprise the iso downloaded
from Fedora Linux on Surface 3 project
still has sound:
https://stephenjust.ca/fedora-surface3.html

I need more time to figure out why/how its kernel
still can load the sound driver correctly even
the DMI table is wrong.
However I have many other tasks to do recently
(including the oreo-x86 porting) so it's low priority.

Please notify us If you have any other finding.

> I've experienced this problem for multiple times, has anyone did yet? What
> would be the cause?

What did you mean "multiple times"?
Did you have several Surface 3 that
have the same issues?
Or you fixed the issue but it happened again?


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Kagami Rosylight]

Oh, so it's not only me! Sad that you also couldn't fix it. 

Yeah, I also think it's a UEFI bug but still somehow being triggered by 7.1 RC1.

"Multiple times" means that I've seen the red boot screen multiple times (3-4 times since I started to use 7.1). All of them happened when I booted to Android.

I didn't know about DSDT table or the Fedora thing, maybe there is some hope :D

Thank you for your post! 

[Chih-Wei Huang]

2017-08-28 11:45 GMT+08:00 Kagami Rosylight <bwst...@gmail.com>:
> Oh, so it's not only me! Sad that you also couldn't fix it.
>
> Yeah, I also think it's a UEFI bug but still somehow being triggered by 7.1
> RC1.

Maybe... who knows?

> "Multiple times" means that I've seen the red boot screen multiple times
> (3-4 times since I started to use 7.1). All of them happened when I booted
> to Android.

I saw the red boot screen much earlier before
the problem happened.
I thought it's because I disabled the secure boot.

> I didn't know about DSDT table or the Fedora thing, maybe there is some hope
> :D

You can just download the iso from the Fedora Linux on Surface 3
project and make a live usb to test.

[Kagami Rosylight]

It seems AMI DMIEDIT can set the lost DMI table items but couldn't find a matching version for Surface 3. All I got is:

+---------------------------------------------------------------------------+
|                  AMIDEWINx64 Utility (Aptio)    v5.15                     |
|      Copyright (C)2014 American Megatrends Inc. All Rights Reserved.      |
+---------------------------------------------------------------------------+
Initializing the SMBIOS interface.  Please wait a moment......
d7 - Error: System doesn't support.

[Kagami Rosylight]

Couldn't find a way. I have successfully boot with AMIDEEFIx64 but it couldn't actually write any value, even asset tag. I still think there is a way to fix this...

On Saturday, November 18, 2017 at 5:20:31 PM UTC+9, Surface 3 User wrote:

Hi Kagami 

The same thing has happened to me, did you find  a way around this ?

Thank you

[Chih-Wei Huang]

2017-11-24 2:05 GMT+08:00 Surface 3 User <vonk...@gmail.com>:
> I would be happy to offer a reasonable bounty to someone who can fix this.

The audio stop working issue of bad Surface 3
has been fixed in 7.1-r1. Please update.

Welcome to donate!

[Chih-Wei Huang]

2018-02-08 0:49 GMT+08:00 vonkursor <vonk...@gmail.com>:
> Thanks for the update,
>
> I was refering to the UEFI bios bug more than the actual androidx86 sound
> issue.

This is Android-x86 project.
We only address Android-x86 issue, of course.

You need to ask Microsoft to ask its BIOS bug.

[Kagami Rosylight]

I can confirm that the audio (and video!) issue is fixed now 😄

I can deal with the firmware issue itself until I buy a new Surface.

[Chih-Wei Huang]

2018-02-16 4:14 GMT+08:00 vonkursor <vonk...@gmail.com>:
> On my surface 3 the touchscreen won't work with 7.1 r1 (using live usb).
> Previously I used a special build for s3 with 7.1 rc0. Is there a special
> build for 7.1 r1 on the the S3 ?

What special build did you mean?