Re: [coreboot] [RFC] Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7

[Iru Cai]

Hi all,

I found that ACPICA released version 20170929 yesterday, and it's more
strict than previous versions. I can't even use it to build qemu-i440fx
because many dsdt files have methods that are not used, which will make
iasl warn about this.

Iru

On Tue, Oct 3, 2017 at 11:50 AM, Matt DeVillier 
wrote:

> hi Paul,
>
> I took a look at this, and the error appears to be the result of a change
> in IASL 20170531:
>
> "Improved the behavior of the iASL compiler and disassembler to detect
> improper use of external declarations"
>
> According to the ACPI 6.2 spec, "The External directive informs the ASL
> compiler that the object is declared external to this table.."  This reads
> to me that if an object is declared External in one table (eg, the DSDT),
> then its declaration must be in another table, not in the table in which
> contains the External reference.  As _SB.DPTF.TEVT is declared in the DSDT
> (in SoC .asl code), then the External declaration in the
> chromeec/acpi/ec.asl is invalid.
>
> To test this, I removed the External declaration in ec.asl, and the
> previously failing boards now build properly with iASL 20170831.  I also
> retested using the current iASL version (20161222), and the aforementioned
> boards still build correctly.
>
> If someone wants to corroborate my analysis, then I'm happy to submit a
> patch to correct the issue
>
> cheers,
> Matt
>
> On Mon, Oct 2, 2017 at 1:56 AM, Paul Menzel  sourceforge.net> wrote:
>
>> Dear coreboot folks,
>>
>>
>> Am Mittwoch, den 20.09.2017, 08:17 +0200 schrieb Paul Menzel:
>>
>> > I’d like to propose the following goal for the upcoming coreboot 4.7
>> > release.
>> >
>> > All boards have to build with GCC 7.2 [1] and IASL 20170831 [2].
>> >
>> > For the latter, several Intel boards fail to build [3]. It’d be great
>> > if the maintainers looked into it.
>>
>> Unfortunately, there was no reply yet. Patrick already blocked the
>> change-set, and commented that it’ll only go in after the coreboot 4.7
>> release, which is fine. But the boards should still build in my
>> opinion.
>>
>> The boards below are affected by the IASL update.
>>
>> ```
>> $ git grep TEVT
>> src/ec/google/chromeec/acpi/ec.asl:External (\_SB.DPTF.TEVT, MethodObj)
>> src/ec/google/chromeec/acpi/ec.asl: If (CondRefOf
>> (\_SB.DPTF.TEVT)) {
>> src/ec/google/chromeec/acpi/ec.asl:
>>  \_SB.DPTF.TEVT (Local0)
>> src/mainboard/google/cyan/variants/terra/include/variant/acpi/thermal.asl:Method
>> (TEVT, 1, NotSerialized)
>> src/soc/intel/baytrail/acpi/dptf/thermal.asl:Method (TEVT, 1,
>> NotSerialized)
>> src/soc/intel/braswell/acpi/dptf/thermal.asl:Method (TEVT, 1,
>> NotSerialized)
>> src/soc/intel/common/acpi/dptf/thermal.asl:Method (TEVT, 1,
>> NotSerialized)
>> src/soc/intel/skylake/acpi/dptf/thermal.asl:Method (TEVT, 1,
>> NotSerialized)
>> ```
>>
>> What is the process for this? Are the maintainers of the board that
>> fail to build subscribed on this mailing list?
>>
>>
>> Kind regards,
>>
>> Paul
>>
>>
>> > [1] https://review.coreboot.org/20809/
>> > [2] https://review.coreboot.org/21156/
>> > [3] https://ticket.coreboot.org/issues/138
>>
>> --
>> 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
>



-- 
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7

[Matt DeVillier]

hi Paul,

I took a look at this, and the error appears to be the result of a change
in IASL 20170531:

"Improved the behavior of the iASL compiler and disassembler to detect
improper use of external declarations"

According to the ACPI 6.2 spec, "The External directive informs the ASL
compiler that the object is declared external to this table.."  This reads
to me that if an object is declared External in one table (eg, the DSDT),
then its declaration must be in another table, not in the table in which
contains the External reference.  As _SB.DPTF.TEVT is declared in the DSDT
(in SoC .asl code), then the External declaration in the
chromeec/acpi/ec.asl is invalid.

To test this, I removed the External declaration in ec.asl, and the
previously failing boards now build properly with iASL 20170831.  I also
retested using the current iASL version (20161222), and the aforementioned
boards still build correctly.

If someone wants to corroborate my analysis, then I'm happy to submit a
patch to correct the issue

cheers,
Matt

On Mon, Oct 2, 2017 at 1:56 AM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:

> Dear coreboot folks,
>
>
> Am Mittwoch, den 20.09.2017, 08:17 +0200 schrieb Paul Menzel:
>
> > I’d like to propose the following goal for the upcoming coreboot 4.7
> > release.
> >
> > All boards have to build with GCC 7.2 [1] and IASL 20170831 [2].
> >
> > For the latter, several Intel boards fail to build [3]. It’d be great
> > if the maintainers looked into it.
>
> Unfortunately, there was no reply yet. Patrick already blocked the
> change-set, and commented that it’ll only go in after the coreboot 4.7
> release, which is fine. But the boards should still build in my
> opinion.
>
> The boards below are affected by the IASL update.
>
> ```
> $ git grep TEVT
> src/ec/google/chromeec/acpi/ec.asl:External (\_SB.DPTF.TEVT, MethodObj)
> src/ec/google/chromeec/acpi/ec.asl: If (CondRefOf
> (\_SB.DPTF.TEVT)) {
> src/ec/google/chromeec/acpi/ec.asl:
>  \_SB.DPTF.TEVT (Local0)
> src/mainboard/google/cyan/variants/terra/include/variant/acpi/thermal.asl:Method
> (TEVT, 1, NotSerialized)
> src/soc/intel/baytrail/acpi/dptf/thermal.asl:Method (TEVT, 1,
> NotSerialized)
> src/soc/intel/braswell/acpi/dptf/thermal.asl:Method (TEVT, 1,
> NotSerialized)
> src/soc/intel/common/acpi/dptf/thermal.asl:Method (TEVT, 1, NotSerialized)
> src/soc/intel/skylake/acpi/dptf/thermal.asl:Method (TEVT, 1,
> NotSerialized)
> ```
>
> What is the process for this? Are the maintainers of the board that
> fail to build subscribed on this mailing list?
>
>
> Kind regards,
>
> Paul
>
>
> > [1] https://review.coreboot.org/20809/
> > [2] https://review.coreboot.org/21156/
> > [3] https://ticket.coreboot.org/issues/138
>
> --
> 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] Suggestions for efficient development setup for Google Chromebooks

[Vadim Bendebury]

Yes, it will require user authorization, there will also be an RMA case
with its own authorization scheme.

-v


On Mon, Oct 2, 2017 at 5:16 PM, Trammell Hudson  wrote:

> On Mon, Oct 02, 2017 at 05:02:40PM -0700, Vadim Bendebury wrote:
> > note that this debug header is going away in new Chrome OS designs. Its
> > functionality is going to be provided by the closed case debugging (aka
> > CCD) facility, where authorized user using a special debug cable can gain
> > access to the AP and EC consoles, reprogram  AP and EC firmware, etc.
>
> Will the closed chassis debugging require user authorization of some sort
> and perhaps only be effective in developer mode?  One of the major
> concerns with the Intel SVT adapter is that it claims to work "where
> USB3-hosted DCI is unavailable", including cold-boot:
>
> https://designintools.intel.com/product_p/itpxdpsvt.htm
>
> There were talks about it at CCC and HITB:
>
> https://conference.hitb.org/hitbsecconf2017ams/materials/
> D2T4%20-%20Maxim%20Goryachy%20and%20Mark%20Ermalov%20-%
> 20Intel%20DCI%20Secrets.pdf
>
> Hopefully the Chromebook CCD doesn't turn into an evil-maid toolkit...
>
> --
> Trammell
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Suggestions for efficient development setup for Google Chromebooks

[Trammell Hudson]

On Mon, Oct 02, 2017 at 05:02:40PM -0700, Vadim Bendebury wrote:
> note that this debug header is going away in new Chrome OS designs. Its
> functionality is going to be provided by the closed case debugging (aka
> CCD) facility, where authorized user using a special debug cable can gain
> access to the AP and EC consoles, reprogram  AP and EC firmware, etc.

Will the closed chassis debugging require user authorization of some sort
and perhaps only be effective in developer mode?  One of the major
concerns with the Intel SVT adapter is that it claims to work "where
USB3-hosted DCI is unavailable", including cold-boot:

https://designintools.intel.com/product_p/itpxdpsvt.htm

There were talks about it at CCC and HITB:

https://conference.hitb.org/hitbsecconf2017ams/materials/D2T4%20-%20Maxim%20Goryachy%20and%20Mark%20Ermalov%20-%20Intel%20DCI%20Secrets.pdf

Hopefully the Chromebook CCD doesn't turn into an evil-maid toolkit...

-- 
Trammell

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

Re: [coreboot] Suggestions for efficient development setup for Google Chromebooks

[Vadim Bendebury]

note that this debug header is going away in new Chrome OS designs. Its
functionality is going to be provided by the closed case debugging (aka
CCD) facility, where authorized user using a special debug cable can gain
access to the AP and EC consoles, reprogram  AP and EC firmware, etc.

-vb

On Mon, Oct 2, 2017 at 2:57 PM, Julius Werner  wrote:

> The only special thing about Chromebooks is that they have a
> standardized debug header, specified here:
> https://www.chromium.org/chromium-os/servo
>
> The header is not populated on consumer devices, but the footprint
> should still be there so you can solder it yourself. You can also just
> solder to the UART pins directly which are probably the most
> interesting ones to you. There are SPI lines on it too and it's even
> possible to hook up an EM100 over it, although I'm not 100% sure of
> the details for that (I usually find that the ROM itself flashes fast
> enough so I don't need an emulator).
>
> Feel free to ask if you have any questions about how coreboot works on
> your Jaq or Elm, happy to help!
>
> On Sun, Oct 1, 2017 at 11:31 PM, Paul Menzel
>  wrote:
> > Dear coreboot folks,
> >
> >
> > Do you have any suggestions on how to get an efficient development
> > setup for Google Chromebooks, which I’d describe as laptops with
> > soldered flash ROM chip. In my case, it’s a Medion AKOYA S2013
> > (google/veyron_jaq), and an Acer Chromebook R 13 (google/elm).
> >
> > I have access to a BeagleBone Black, a compatible clip and a Dediprog
> > EM100-Pro. As the flash ROM chip is not soldered, I guess only the
> > first two are of interest, as the chip is soldered and I am unable to
> > remove the chip, and solder a socket on it.
> >
> > I ask, because maybe I miss some unknown “feature” of the Google
> > Chromebooks, or there could be an emulator, like AMD SimNow, or
> > something similar.
> >
> >
> > Thanks,
> >
> > Paul
> > --
> > 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 mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Suggestions for efficient development setup for Google Chromebooks

[Julius Werner]

The only special thing about Chromebooks is that they have a
standardized debug header, specified here:
https://www.chromium.org/chromium-os/servo

The header is not populated on consumer devices, but the footprint
should still be there so you can solder it yourself. You can also just
solder to the UART pins directly which are probably the most
interesting ones to you. There are SPI lines on it too and it's even
possible to hook up an EM100 over it, although I'm not 100% sure of
the details for that (I usually find that the ROM itself flashes fast
enough so I don't need an emulator).

Feel free to ask if you have any questions about how coreboot works on
your Jaq or Elm, happy to help!

On Sun, Oct 1, 2017 at 11:31 PM, Paul Menzel
 wrote:
> Dear coreboot folks,
>
>
> Do you have any suggestions on how to get an efficient development
> setup for Google Chromebooks, which I’d describe as laptops with
> soldered flash ROM chip. In my case, it’s a Medion AKOYA S2013
> (google/veyron_jaq), and an Acer Chromebook R 13 (google/elm).
>
> I have access to a BeagleBone Black, a compatible clip and a Dediprog
> EM100-Pro. As the flash ROM chip is not soldered, I guess only the
> first two are of interest, as the chip is soldered and I am unable to
> remove the chip, and solder a socket on it.
>
> I ask, because maybe I miss some unknown “feature” of the Google
> Chromebooks, or there could be an emulator, like AMD SimNow, or
> something similar.
>
>
> Thanks,
>
> Paul
> --
> 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] PC Engines apu2 booting broken

[Piotr Król]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 10/02/2017 03:39 PM, Kyösti Mälkki wrote:

Hi Kyösti,

> 
> My fault, see: https://review.coreboot.org/21840

This fix booting issue. Thank you for quick reaction.
Added +2 to review hope this not issue.

(...)

> Once you have bisected to an offending commit, you can do builds
> that strips away all the revision hashes:
> 
> abuild --timeless -at pcengines/apu2 diff -qr build-ok/
> build-fail/
> 
> The list of just the .o files is still a long one, but two further 
> things you can do here: Strip debug symbols from .o files, and
> define ASSERT() without __FILE__ or __LINE__. If you know the
> commit was supposed to create a binary identical image, this is one
> way to pinpoint where the difference is.
> 
> This approach has saved the day before when AGESA includes have
> gone crazy.

Sounds like great approach. Any easy way to strip debug and redefine
ASSERT in coreboot ? Or you just doing it manually ? Would be great to
note exact steps in case anyone would need that in future. Maybe even
script.

Best Regards,
- -- 
Piotr Król
Embedded Systems Consultant
https://3mdeb.com | @3mdeb_com
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE0Fuj+LRuV2IlvAeVmPZBsjmwRrQFAlnSqzQACgkQmPZBsjmw
RrRCnw/+LHM8ZVfefHII4euhk/+espqEcoMGv4BeS82r+xB/yTumVxCz7uIptLca
bizl9v++B3cX92S22LGyIGaH7xjQIhJd3tYqn6DgWJ+9278jcjliDBxpH1b2cYjx
w50abEvK5ssD7laRPj21DnnldDKHSaZ/AnM3le7MXIyBeFgRLp0Fqlvotou08l4H
OfXl2c+eGmwdGMRjrVOMHqWz+CAQv17wXNyKYYwxAD0sTAYD6Xj8A0rSKgWTnxWd
ORANofU/Cx/lK/oBhWotPhT0n0Wp6vgQ4k84r1KHuadJyB6lO/2hgS7fk48rV3Y7
yIqAKPd4tKj33rFtjXGVyG2RHvsTXP90GRE4bjDvi5JVTCUnABF7jQ1ORJHEe7SM
qDGZx1o3g3BifXK/34SgsuPkGDJwQy/xNQFhK4P7KLji9OkRk8btpsOxBXx7MWmu
3oVfcZManM6payPpW52JUzJz5N2iUf+WjbPlZS6oOkYpnHdo5y2gZdOOf5PfIbCQ
KYGyb8qjNFeeOez1mpFUufnFDumDY9Dbf1CDC//rSUSYEIacsf/6PLQJxifkm+xD
mL2FTMNOf13yu0gjqO5zh2UiojpgvoA3vUO7fJ6/WMO6HFE0AGwCP4P7ASGUZ6qm
PW5n2nunC3vsGtKhcPsIb0l4VTUNm6UVRxINBUC2x37DpGLlUIk=
=owYc
-END PGP SIGNATURE-

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

Re: [coreboot] How to work with Chrome EC? (was: Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7)

[Vadim Bendebury]

Hi Paul,

I don't think there is an external mailing list for chromium OS EC
development.

To see the manifest which the repo utility requires you need to setup the
Chrome OS chroot environment first (aka cros SDK), I am not sure if you did
that, but this is a pretty expensive procedure, requiring a lot of disk
space and time.

You should be able to clone the EC git repository and run pre-upload checks
and push patches to the EC gerrit server, but you'd need an account on the
server for that.

To be honest with you, I don't know the exact procedure to follow to get
the account created, you could inquire at chromium-os-...@chromium.org

the entry threshold is a big high, but I am sure the Chome OS EC team would
appreciate your contributions.

--vb




On Mon, Oct 2, 2017 at 12:04 AM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:

> Dear coreboot folks,
>
>
> GCC 7.2 found several issues in the Chromium EC code base, like #770209
> [4], and I prepared  patches, but unfortunately, I do not know how to
> push them for review.
>
> 1. The instructions don’t work for me [5]. I can’t find the manifest
> file, which seems to be required by the utility `repo`.
>
> 2. Also, in the preferences menu of the Google Chromium review system,
> I cannot find a way to upload my SSH key.
>
> 3. Is there a mailing list for the Chromium Embedded Controller
> development?
>
>
> Thanks,
>
> Paul
>
>
> [4] https://bugs.chromium.org/p/chromium/issues/detail?id=770209
> [5] https://dev.chromium.org/chromium-os/ec-development
> [6] https://chromium-review.googlesource.com/admin/
> projects/chromiumos/platform/ec,access
> --
> 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] Owner-controlled POWER9 Talos II [was: Disabling Intel ME 11 via undocumented mode]

[Rene Shuster]

600-page documentation about the BCM5718 Family:
https://duckduckgo.com/?q=site:broadcom.com+5718+programmer's+reference+guide

Quote:
"This document covers the BCM5718 family of NetXtreme / NetLink Ethernet
controllers. This family of controllers includes the following devices:
• BCM5717
• BCM5718
• BCM5719
• BCM5720
The document focuses on the registers, control blocks, and software
interfaces necessary for host software programming."

Look like fantastic documentation. Is there no such thing as the EFF
starting a fundraiser/crowdfunding campaign, then hiring appropriate
firmware engineers and coming with with an open-source fw? In a perfect
world yes.

On Mon, Sep 11, 2017 at 12:30 PM, Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/08/2017 10:38 PM, taii...@gmx.com wrote:
> > Also want to add why broadcom? I heard they didn't have a good attitude
> > to open source and as a large company I imagine they have a lot of
> > institutional inertia preventing that from changing? - why not one of
> > the smaller NIC makers such as atheros, mellanox, solarflare etc?
>
> Cost was the main driver for this design.  Our focus was on getting the
> product to market at a reasonable price point, and Broadcom's NetXtreme
> series already has excellent Linux driver support, meaning that we
> didn't need to invest additional resources into driver development.
> Depending on what the uptake of Talos II is (and therefore how much
> "nice to have" development we can justify vs. simply keeping a
> functional, RYF-certifiable product on the market) we may consider
> changes to the NIC supplier in the future.
>
> As to why not Intel, in addition to the obvious issues in relation to
> sourcing a critical system component from a direct competitor, we have
> experienced issues with Intel GbE NICs in the past under Linux related
> to the on-chip firmware locking up and requiring a host reboot.  The
> NetXtreme devices appear to be quite stable, and their internal
> operation has already been partially documented, meaning development of
> a true open firmware port is at least possible.  The same cannot be said
> for the other players in this space.
>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJZtrouAAoJEK+E3vEXDOFbyGQH/37BUzE1M/P2Cc1nx9CkKTB1
> gQ8ClVGdiXcCfNIMOx6HqVRdAp6acVf+xUvDkbVY0lES9cJUJx6amJcOnedI3ohm
> QRMHylIwBUELJRtUV38kUsna7F0QHYrH/bOuoY/iFqvfbiF96i6jGBDCFzzC7ZmA
> zxOkNrfi0bE6ux7r+66JzfLslN4ysvWDIAnYxvZ1CpJGkVRUjBuUFOGsC6vnxFYY
> 8/k1HwmMiYsn7t3lDfkHpqmfLcTq/cnm/oyzQR6UGZEf/z4a17hRH6J2A1dI1b1l
> eePl6xkDXy1rFKUOZItridY1wrIHpNgE2EXgxLxRV7PnqKyP9ccEdv3LJ8w2ikE=
> =73Bg
> -END PGP SIGNATURE-
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] PC Engines apu2 booting broken

[Kyösti Mälkki]

On Sun, Oct 1, 2017 at 8:11 PM, Piotr Król  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi all,
> PC Engines apu2 (and probably apu1) not booting on recent master. I
> bisected problem to: d4955f0ade18cafde4a3ea20885eb9fbdc5b4514
>
> AGESA: Move API interface under drivers/
>

My fault, see: https://review.coreboot.org/21840

That was insufficient testing on my side, I blame too much pending
work in the review queues spanning couple branches...  I mostly test
only without BINARYPI_LEGACY_WRAPPER, and some of that work has still
not landed in gerrit.

> I'm not sure if some config options are missing. I tried to select
> DRIVERS_AMD_PI and CPU_AMD_PI in Kconfig, but those not help.

Once you have bisected to an offending commit, you can do builds that
strips away all the revision hashes:

  abuild --timeless -at pcengines/apu2
  diff -qr build-ok/ build-fail/

The list of just the .o files is still a long one, but two further
things you can do here: Strip debug symbols from .o files, and define
ASSERT() without __FILE__ or __LINE__. If you know the commit was
supposed to create a binary identical image, this is one way to
pinpoint where the difference is.

This approach has saved the day before when AGESA includes have gone crazy.

Kyösti

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

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

Hi Paul,

Those changes to the IFWI blob worked great, thanks!
I have attached the serial console log. It looks like we are in similar 
situations now.

I got a hang of around 45s at “MRC: region file invalid in 'RW_VAR_MRC_CACHE”,
and then it hangs indefinitely at the end of the log.

I tracked the MRC cache message down to this line:
https://github.com/coreboot/coreboot/blob/master/src/soc/intel/common/mrc_cache.c#L272

I’m stuck again for the moment. Thanks again Paul for getting me one step 
closer.

Cheers,
Cameron




Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:
e: cameron.cr...@exterity.com | w: www.exterity.com




From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Cameron Craig
Sent: 28 September 2017 16:51
To: 'Paul Penz'; coreboot@coreboot.org
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Paul,

Great to hear I’m not the only one in this situation ☺

I’ve just been using the IWFI file from Intel with no modifications,  so I’ll 
look out the FIT tool and give that a go.

Thanks,
Cameron




Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:
e: cameron.cr...@exterity.com | w: 
www.exterity.com



From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Paul Penz
Sent: 28 September 2017 15:35
To: coreboot@coreboot.org
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Cameron,

I had the same problem.

Had you modified the intel IFWI file ?

If not, I had done this additional:

Download 522538_apl txe hf 3.0.11.1131 (th2 & rs1).zip from intel
Start fit.exe
Load the IFWI file
Change at Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00
Change at Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0
Save

Now I get output on the console and postcodes, but during FSP_M a long pause of 
ca. 45s exists and it hangs later during FSP_P initialization.

Good luck
Paul



Paul Penz
Dipl.-Ing. (FH)
Senior Hardware Engineer

ELTEC Elektronik AG, Mainz
_

Fon  +49 6131 918 335
Fax  +49 6131 918 195
Email   pp...@eltec.de
Web www.eltec.de




*
ELTEC Elektronik AG
Galileo-Galilei-Straße 11
D-55129 Mainz

Vorstand: Peter Albert
Aufsichtsratsvorsitzender: Andreas Kochhäuser

Registergericht: Amtsgericht Mainz
Registernummer: HRB 7038
Ust-ID: DE 149 049 790
*
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung 
oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Evtl. 
Anhänge dieser Nachricht wurden auf Viren überprüft!
Jede Form von Vervielfältigung, Abänderung, Verbreitung oder Veröffentlichung 
dieser E-Mail Nachricht ist untersagt! Das Verwenden von Informationen aus 
dieser Nachricht für irgendwelche Zwecke ist strengstens untersagt.
Es gelten unsere Allgemeinen Geschäftsbedingungen, zu finden unter 
www.eltec.de.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7

[Paul Menzel]

Dear coreboot folks,


Am Mittwoch, den 20.09.2017, 08:17 +0200 schrieb Paul Menzel:

> I’d like to propose the following goal for the upcoming coreboot 4.7
> release.
> 
> All boards have to build with GCC 7.2 [1] and IASL 20170831 [2].
> 
> For the latter, several Intel boards fail to build [3]. It’d be great
> if the maintainers looked into it.

Unfortunately, there was no reply yet. Patrick already blocked the
change-set, and commented that it’ll only go in after the coreboot 4.7
release, which is fine. But the boards should still build in my
opinion.

The boards below are affected by the IASL update.

```
$ git grep TEVT
src/ec/google/chromeec/acpi/ec.asl:External (\_SB.DPTF.TEVT, MethodObj)
src/ec/google/chromeec/acpi/ec.asl: If (CondRefOf 
(\_SB.DPTF.TEVT)) {
src/ec/google/chromeec/acpi/ec.asl: \_SB.DPTF.TEVT 
(Local0)
src/mainboard/google/cyan/variants/terra/include/variant/acpi/thermal.asl:Method
 (TEVT, 1, NotSerialized)
src/soc/intel/baytrail/acpi/dptf/thermal.asl:Method (TEVT, 1, NotSerialized)
src/soc/intel/braswell/acpi/dptf/thermal.asl:Method (TEVT, 1, NotSerialized)
src/soc/intel/common/acpi/dptf/thermal.asl:Method (TEVT, 1, NotSerialized)
src/soc/intel/skylake/acpi/dptf/thermal.asl:Method (TEVT, 1, NotSerialized)
```

What is the process for this? Are the maintainers of the board that
fail to build subscribed on this mailing list?


Kind regards,

Paul


> [1] https://review.coreboot.org/20809/
> [2] https://review.coreboot.org/21156/
> [3] https://ticket.coreboot.org/issues/138

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Suggestions for efficient development setup for Google Chromebooks

[Paul Menzel]

Dear coreboot folks,


Do you have any suggestions on how to get an efficient development
setup for Google Chromebooks, which I’d describe as laptops with
soldered flash ROM chip. In my case, it’s a Medion AKOYA S2013
(google/veyron_jaq), and an Acer Chromebook R 13 (google/elm).

I have access to a BeagleBone Black, a compatible clip and a Dediprog
EM100-Pro. As the flash ROM chip is not soldered, I guess only the
first two are of interest, as the chip is soldered and I am unable to
remove the chip, and solder a socket on it.

I ask, because maybe I miss some unknown “feature” of the Google
Chromebooks, or there could be an emulator, like AMD SimNow, or
something similar.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot