Re: [coreboot] ACPI error booting Windows

[Matt DeVillier]

you can take a look at all my configs as as well as all the patches in my
tree in my github there.  They aren't all fully up to date, but should be
useful.  Check Caroline, Cave, Chell, Sentry for Skylake CrOS devices,
which should all be the same ACPI-wise as kblrvp3.  I haven't pushed the
config for the KabyLake CrOS device yet since it's not yet released, but it
it doesn't require any additional patches from what's in my tree now.

On Wed, Apr 25, 2018 at 9:02 PM Alex Feinman 
wrote:

> That unfortunately did not help. Would it be possible to take a look at
> your .config? Perhaps I'll be able to spot something
> --
> *From:* Matt DeVillier 
> *Sent:* Wednesday, April 25, 2018 4:14 PM
> *To:* alexfein...@hotmail.com
> *Cc:* coreboot
> *Subject:* Re: [coreboot] ACPI error booting Windows
>
> I have Windows booting on a KBL CrOS device, and looking at my tree,
> pretty sure the only change I have that would potentially address that
> error is adding the pcon value to the IGD ACPI OpRegion header:
>
> https://github.com/MattDevo/coreboot/commit/3349065354709c85276168272469797dd3f6
>
> there were a few others but they've all since been merged upstream
>
>
> On Wed, Apr 25, 2018 at 6:00 PM Alex Feinman 
> wrote:
>
> I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board.
> The build uses Chrome EC and is based on kblrvp3 mainboard configuration.
> Linux runs fine, but when I attempt to install Windows 10 (or boot a
> preinstalled Windows image from USB) I instantly get ACPI_BIOS_ERROR
> (0xC0A5). There is a Microsoft document that provides a large amount of
> possible reasons for this error, however I can't even narrow it down
> because cleverly Windows 10 no longer prints the bug check parameters, at
> least not in this case.
>
> I would appreciate some pointers if possible.
>
> Thank you
> Alex
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ACPI error booting Windows

[Alex Feinman]

That unfortunately did not help. Would it be possible to take a look at your 
.config? Perhaps I'll be able to spot something

From: Matt DeVillier 
Sent: Wednesday, April 25, 2018 4:14 PM
To: alexfein...@hotmail.com
Cc: coreboot
Subject: Re: [coreboot] ACPI error booting Windows

I have Windows booting on a KBL CrOS device, and looking at my tree, pretty 
sure the only change I have that would potentially address that error is adding 
the pcon value to the IGD ACPI OpRegion header:
https://github.com/MattDevo/coreboot/commit/3349065354709c85276168272469797dd3f6

there were a few others but they've all since been merged upstream


On Wed, Apr 25, 2018 at 6:00 PM Alex Feinman 
> wrote:
I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board. The 
build uses Chrome EC and is based on kblrvp3 mainboard configuration. Linux 
runs fine, but when I attempt to install Windows 10 (or boot a preinstalled 
Windows image from USB) I instantly get ACPI_BIOS_ERROR (0xC0A5). There is 
a Microsoft document that provides a large amount of possible reasons for this 
error, however I can't even narrow it down because cleverly Windows 10 no 
longer prints the bug check parameters, at least not in this case.

I would appreciate some pointers if possible.

Thank you
Alex
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ACPI error booting Windows

[Andrey Korolyov]

On Thu, Apr 26, 2018 at 1:59 AM, Alex Feinman  wrote:
> I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board.
> The build uses Chrome EC and is based on kblrvp3 mainboard configuration.
> Linux runs fine, but when I attempt to install Windows 10 (or boot a
> preinstalled Windows image from USB) I instantly get ACPI_BIOS_ERROR
> (0xC0A5). There is a Microsoft document that provides a large amount of
> possible reasons for this error, however I can't even narrow it down because
> cleverly Windows 10 no longer prints the bug check parameters, at least not
> in this case.
>
> I would appreciate some pointers if possible.
>

If you are able to obtain debug build of the failing O/S (or earlier
version, if it runs on KBL), it would be possible to find a clue why
exactly Windows ACPI parser is nagging.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ACPI error booting Windows

[Matt DeVillier]

I have Windows booting on a KBL CrOS device, and looking at my tree, pretty
sure the only change I have that would potentially address that error is
adding the pcon value to the IGD ACPI OpRegion header:
https://github.com/MattDevo/coreboot/commit/3349065354709c85276168272469797dd3f6

there were a few others but they've all since been merged upstream


On Wed, Apr 25, 2018 at 6:00 PM Alex Feinman 
wrote:

> I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board.
> The build uses Chrome EC and is based on kblrvp3 mainboard configuration.
> Linux runs fine, but when I attempt to install Windows 10 (or boot a
> preinstalled Windows image from USB) I instantly get ACPI_BIOS_ERROR
> (0xC0A5). There is a Microsoft document that provides a large amount of
> possible reasons for this error, however I can't even narrow it down
> because cleverly Windows 10 no longer prints the bug check parameters, at
> least not in this case.
>
> I would appreciate some pointers if possible.
>
> Thank you
> Alex
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] ACPI error booting Windows

[Alex Feinman]

I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board. The 
build uses Chrome EC and is based on kblrvp3 mainboard configuration. Linux 
runs fine, but when I attempt to install Windows 10 (or boot a preinstalled 
Windows image from USB) I instantly get ACPI_BIOS_ERROR (0xC0A5). There is 
a Microsoft document that provides a large amount of possible reasons for this 
error, however I can't even narrow it down because cleverly Windows 10 no 
longer prints the bug check parameters, at least not in this case.

I would appreciate some pointers if possible.

Thank you
Alex
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re : Re: When does AMD release the fam15 spectre microcode updates?

[echelon]

Hello Rudolf,
First thank your for finding these blobs and the hack to use them, and for 
testing and validating them.
But please could you tell us what was the setup for your tests :
 - what was your hardware : cpu + mobo (chipset)?
 - what was your linux kernel version?
Thank you beforehand.
Best regards,
 Florentin

- Mail d'origine -
De: Rudolf Marek 
À: coreboot@coreboot.org
Envoyé: Tue, 17 Apr 2018 09:30:57 +0200 (CEST)
Objet: Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

Hi,

I found new microcode here [1], I used 
cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my Trinity 
family15h CPU.
I hacked together a new microcode header which contains the equivalence table 
etc to be able to load this microcode into the CPU from Linux.

dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84 
of=header.bin
cat header.bin cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin > 
microcode_amd_fam15h.bin

copy the file to same location and trigger update:

echo 1 >  /sys/devices/system/cpu/microcode/reload

[ 6032.948243] microcode: CPU0: new patch_level=0x0600111f
[ 6032.964913] microcode: CPU2: new patch_level=0x0600111f

Please note that the header.bin does contain a size of the microcode blob, but 
it happens to be the same, so it works. Normally the container
may contain more microcode blobs. But in my case I use just "right" one for my 
CPU.

The new microcode seems to be adding the IBPB feature.

Thanks
Rudolf


[1] https://github.com/platomav/CPUMicrocodes

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Status of the Lenovo X201

[Nicola Corna]

April 18, 2018 3:54 PM, "Kyösti Mälkki"  wrote:

> Having romstage stack smashed seems irrelevant for the no-boot issue.
> That nehalem raminit code, struct raminfo, seems to eat a lot of stack
> and an error message for that case was added with commit 2c3fd49. You
> could try parent of that commit, but rumour is lenovo/x201 was a
> no-boot case long time before that.

I'll do some tests to find which commit caused the no-boot.

> I can see int15h messages interleaved with SMP init, that looks odd to
> me. Also, did the log really end inside 0:1f.0 PCI finalize or was
> usbdebug logging just interrupted for some reason at that point?

The log really ends there.

> Try current master with default config instead of a one derived from
> last reported board_status. There has been lot of changes on
> framebuffer kconfig settings. And we probably need the .config you
> used to assess what's happening there.

I've tried with the current master on a fresh config, but the result is
the same. Attached you can find the log and the .config.

If needed I can do some tests on this PC.

Nicola


x201_config
Description: Binary data


x201_log
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Ivan Ivanov]

If I understood all this correctly, the updated microcodes should be
forcing the CPU to do these MSR writes (or the low level action which
stands behind them) by default. So that, when you got this updated
microcode on your CPU, its already fixed and no further operations are
necessary!

At the moment both me and Mike have sent many letters to AMD (example
provided below, you could use its parts as well). Have not received
any good reply yet (only one reply, with a stupid link to spectre v2
description page and without any files attached) - but we are trying
hard and hope to eventually reach a smart person at AMD who could help
us...

By the way, these microcodes from platomav github page - are from
february/march, and I believe they do not contain a spectre v2 fix. So
we hope to either eventually get these microcodes from AMD, or to
somehow extract them from a super bloated Win10 update, or to try to
extract them from the updated BIOSes of other companies when they come
out

===
1) go to amd support page and open a ticket form
2) set company as "coreboot" or "coreboot BIOS"
Subject: Updated microcode for coreboot BIOS devs
We, the coreboot BIOS developers, have not received any microcode
updates from AMD (aimed towards patching the spectre v2
vulnerability). AMD sent these updated microcode binaries to many
motherboard and BIOS development companies, but forgot to send these
files to us at coreboot! Could you please provide a standalone
download of your updated microcode binaries, to make it possible for
us to include them to our coreboot BIOS running on AMD platforms ? We
will appreciate if you will share these updated microcode binaries
with us - maybe together with SHA-256 or SHA-512 hashes of these files
or GnuPG signatures to ensure the security of transaction Best
regards, Ivan Ivanov, coreboot BIOS firmware engineer

P.S. Although, ideally these new updated microcodes should be
committed tokernel/git/firmware/linux-firmware.git repository -->
directory called
"amd-ucode" .Currently it contains the following files:
microcode_amd.bin ,microcode_amd.bin.asc , microcode_amd_fam15h.bin
,microcode_amd_fam15h.bin.asc , microcode_amd_fam16h.bin
,microcode_amd_fam16h.bin.asc .They have been last updated at 2015/16
year, and we would like to see them updated again

2018-04-25 4:02 GMT+03:00 awokd via coreboot :
> On Tue, April 24, 2018 11:31 pm, Nico Huber wrote:
>> On 25.04.2018 00:18, taii...@gmx.com wrote:
>
>>> I can't believe everyone else is so nonchalant about all this
>>> considering how important it is I still haven't figured out how to update
>>> the microcode on any of my computers - no guides I have found actually
>>> work and no distros have the new microcode for intel or amd despite it
>>> having been months.
>
> I'm not nonchalant, but I'm not entirely sure what to do with those patch
> files and was hoping to see a new amd microcode 15h bin with them
> incorporated.
>
>> I can't believe everybody is so nonchalant about Rowhammer but many
>> people make a big thing out of the comparatively tiny Spectre problem.
>>
>>>
>>> For the best security one should have both the new microcode and the
>>> lfence msr?
>>
>> Not for the best but for any security, you have to understand first that
>> both options only change something if your software is prepared to uti-
>> lize them. First update your software, then check what it needs / what the
>> developers expect (the new microcode I'd guess).
>
> If I remember the earlier discussion right on that lfence msr, the OS can
> also set it so although it would be nice if coreboot did as well, it's not
> required?
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot