coreboot May 2020

coreboot@coreboot.org

43 participants
45 discussions

Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5 protection bits?
by Alan K.L. Mok 31 May '20

31 May '20

Hi all, Can someone give me some hints or point me to some instructions please? Machine: Lenovo X1 Carbon 1st Gen (2012, no Boot Guard) Flashing tool: CH341A USB programmer + Debian Linux I am trying to replace the OEM firmware with Coreboot 4.12 and then install OpenBSD into the machine and set it up as an internet facing firewall. I ran me_cleaner against the dumped SPI image already. 1. Can anyone please tell let me know how can I achieve the captioned objectives? I looked into ifdtool & uefitool but found nothing related to my goal. I also tried the "lock ME/TXE" option during make menuconfig but Intel chipsec is still reporting the captioned bits not set on my Coreboot-flashed X1 Carbon 2. Is it correct to say that once the PR0-5 bits are set and Coreboot flashed into the machine, the values of the PR registers will be configured accordingly after machine boot up (when OS is having control)? Thank you very much for looking into my questions!

2 2

Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5 protection bits?
by alanmok1＠gmail.com 30 May '20

30 May '20

Hi all, Machine: Lenovo X1 Carbon 1st Gen (2012, no Boot Guard) Flashing tool: CH341A USB programmer + Debian Linux I am trying to replace the OEM firmware with Coreboot 4.12 and then install OpenBSD into the machine and set it up as an internet facing firewall. I ran me_cleaner against the dumped SPI image already. 1. Can anyone please tell let me know how I can achieve the captioned objectives? I looked into ifdtool & uefitool but found nothing related to my goal. I also tried the "lock ME/TXE" option during make menuconfig but Intel chipsec is still reporting the captioned bits not set on my Coreboot-flashed X1 Carbon. 2. Is it correct to say that once the PR0-5 bits are set and Coreboot flashed into the machine, the values of the PR registers will be configured accordingly after machine boot up (when OS is having control)? Thank you for looking into my questions!

1 0

P3B-F's ACPI dilemma... Should I go further?
by Keith Hui 29 May '20

29 May '20

Hi Peter, > Keith, > > Keith Hui wrote: > > I had to upgrade the kernel from 4.4.14 to 5.4.42 for the i2c-scmi driver > > to catch on. Then I was getting a shitload of invalid parameter errors > > which eventually boils down to _SBW being expected to return a package of > > one integer, instead of just an integer. Oops. I fixed that, but somehow > > it's still not showing my devices. Gotta try harder. > > Just a note that it's interesting, fun and exciting to follow your progress! > > Keep up the good work. You'll get there. Thanks for your encouragement! *** Hi all, After another 2 days I now have a working SCMI implementation on P3B-F and can get readings from lm-sensors using i2c-scmi, with all relevant vendor code connected to SCMI. I spent another few hours refactoring so that it can be more easily extended to other southbridges. At this point my use case is solved and I can submit and updated patch. Now that I think more about it... SCMI is sufficient for getting hwmon working on Linux, but for Windows I don't know if eg. Speedfan can use it, or if it's even necessary. The next step in the evolution of ACPI-based hardware monitoring on ASUS mainboards would be ATK0110. It's an all-ACPI wrapper around whatever hardware monitor chip is on the actual board. I could figure out what methods I need to implement, and if I can make SCMI work, I can make ATK0110 work too, but is it worth the effort? Pros: - Forget i2c-scmi and all the i2c crap, just load asus_atk0110 and go - I can debug my work by overriding DSDT in Linux instead of flashing - Possibility of wider adoption (use asus-atk0110 for all corebooted [asus] boards) Cons: - My use case has been solved already - May have to do scaling math that I don't fully understand. As it is, some values (eg. 12V rail reading) don't make sense - More hours, more grey hair falling off (:-P - Who's using this board anyway? Regards Keith

1 0

Unit tests are now live on our build infrastructure
by Patrick Georgi 29 May '20

29 May '20

Hi everybody, Just a quick heads up: the unit tests in tests/ are now built and run on every commit pushed to review.coreboot.org. Consider this a good opportunity to improve our stability by contributing tests! Jan is writing a tutorial on writing tests that you can find for now at review.coreboot.org/41727. If anything is unclear with the tutorial, don't hesitate to comment on the change. Regards, Patrick

1 0

Re: coreboot Digest, Vol 183, Issue 35
by Keith Hui 27 May '20

27 May '20

Hi Paul, Thanks for filing the bug for me. Yes, I found out how. It is reflected in my WIP patch now. Hi Tim, iasl is even stricter with EISAID - it exactly requires the format SMB0001, so doing what you said still throws an error. I had to upgrade the kernel from 4.4.14 to 5.4.42 for the i2c-scmi driver to catch on. Then I was getting a shitload of invalid parameter errors which eventually boils down to _SBW being expected to return a package of one integer, instead of just an integer. Oops. I fixed that, but somehow it's still not showing my devices. Gotta try harder. Thanks Keith > ---------- Forwarded message ---------- > From: Tim Wawrzynczak <twawrzynczak(a)google.com> > To: Paul Menzel <pmenzel(a)molgen.mpg.de> > Cc: coreboot(a)coreboot.org > Bcc: > Date: Tue, 26 May 2020 16:59:31 -0600 > Subject: [coreboot] Re: Please solve this ACPI dilemma > Hi Keith, > > Many ACPI devices use an EISAID for their _HID, and I believe that Linux's > ACPICPA converts an EISAID to a string for _HID matching. > You could try something like this instead (you can see in the Linux > sources there are 3 ACPI _HID matches, and this is one of them). > `Name(_HID, EISAID("SMBUS01")) `. > > Cheers, > -Tim > > > On Mon, May 25, 2020 at 5:39 AM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > >> Dear Keith, >> >> >> Am 25.05.20 um 02:05 schrieb Keith Hui: >> > I am attempting to build SCMI [1] support for the DSDT for asus/p3b-f >> > to get around a PCI<->ACPI resource conflict that renders the whole >> > SMBus and the hardware monitor inoperative. The board has ACPI AML >> > hooks that run before and after suspend and resume, so my plan is to >> > have Linux access the SMBus exclusively through ACPI, using the driver >> > i2c-scmi. >> > >> > The spec calls for methods _SBI, _SBR, _SBW, _SBT, _SBA. I don't need >> > the last two for my purpose so I'll skip them. During build iasl warns >> > that they are unrecognized reserved methods and **our build process >> > treats all warning as errors** so my build broke. >> >> I created a bug report for iasl [1]. >> >> What is the error number? Please look into `IGNORED_IASL_WARNINGS` in >> `Makefile.inc` how certain iasl warnings can be ignored. >> >> > The driver knows that some IBM bioses implementing the methods without >> > the leading underscores, but it only expects this on devices with an >> > _HID of "SMBUSIBM". If I use this _HID, iasl errors out: "_HID suffix >> > must be all hex digits (SIBM)", so I have to use SMB0001, for which >> > i2c-scmi would only look for the _SB? methods, that from what I can >> > see is the correct way. So either my build breaks, or I can expect a >> > build that is not going to work. >> >> Please contact the Linux maintainers. >> >> > I cannot proceed unless I hack the build process (I send in a patch to >> > Makefile.inc to make an exception for p3b-f) to disregard iasl >> > warnings. >> >> Ah, looks like you found my suggestion already. >> >> > And if I resolve the conflict by removing all ASL code for SMBus >> > access, I would have no working suspend, even S1. >> > >> > What am I supposed to do? >> >> >> Kind regards, >> >> Paul >> >> >> > [1] http://smbus.org/specs/smbus_cmi10.pdf >> [2]: https://bugs.acpica.org/show_bug.cgi?id=1530 >> "Add _SBI, _SBR, _SBW, _SBT, _SBA to reserved methods" >> >

2 1

Please solve this ACPI dilemma
by Keith Hui 27 May '20

27 May '20

I am attempting to build SCMI [1] support for the DSDT for asus/p3b-f to get around a PCI<->ACPI resource conflict that renders the whole SMBus and the hardware monitor inoperative. The board has ACPI AML hooks that run before and after suspend and resume, so my plan is to have Linux access the SMBus exclusively through ACPI, using the driver i2c-scmi. The spec calls for methods _SBI, _SBR, _SBW, _SBT, _SBA. I don't need the last two for my purpose so I'll skip them. During build iasl warns that they are unrecognized reserved methods and **our build process treats all warning as errors** so my build broke. The driver knows that some IBM bioses implementing the methods without the leading underscores, but it only expects this on devices with an _HID of "SMBUSIBM". If I use this _HID, iasl errors out: "_HID suffix must be all hex digits (SIBM)", so I have to use SMB0001, for which i2c-scmi would only look for the _SB? methods, that from what I can see is the correct way. So either my build breaks, or I can expect a build that is not going to work. I cannot proceed unless I hack the build process (I send in a patch to Makefile.inc to make an exception for p3b-f) to disregard iasl warnings. And if I resolve the conflict by removing all ASL code for SMBus access, I would have no working suspend, even S1. What am I supposed to do? Thanks Keith [1] http://smbus.org/specs/smbus_cmi10.pdf

3 2

Can you find faults in this SMBus CMI implementation?
by Keith Hui 26 May '20

26 May '20

Hi all, This is my next attempt to get around the ACPI resource conflict on p3b-f: https://review.coreboot.org/c/coreboot/+/41735 Done up to the SCMI spec here: http://smbus.org/specs/smbus_cmi10.pdf The standard device _HID should have been SMBUS01, but our iasl will not accept that, insisting the last 4 letters be hex digits. I left off _SBT and _SBA because the hardware doesn't do alerts and the only device doing block transfers is the clock chip, which is not accessible without further tricks. If I call the methods directly, they seem to work. But Linux 4.4.14 isn't picking up the device. Manually load the driver and I still don't get the PIIX4 SMBus. Also it doesn't seem to write properly - I could no longer get my message and power LEDs to blink after this upgrade. Can you see any faults in my work just by looking at it? Thanks Keith

1 0

Hiccups bringing ACPI support to p3b-f
by Keith Hui 24 May '20

24 May '20

I just sent in this patch to bring ACPI to p3b-f, after way too long: https://review.coreboot.org/c/coreboot/+/41098 I've run into two problems with this work and hoping for insights. First, Linux kernel is throwing a warning. Full dmesg (from kernel start to prompt) attached, but it's these lines in particular: [ 5.977786] ACPI Warning: SystemIO range 0x0000000000000F00-0x0000000000000F07 conflicts with OpRegion 0x0000000000000F00-0x0000000000000F06 (\SM00) (20150930/utaddress-254) [ 5.978202] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver It is probably related to some SMBus manipulation I imported from OEM firmware that is going to be needed for S3 suspend - It actually has code to talk to an onboard proprietary ASIC over SMBus to blink the power LED and turn off the fan among other things. I later dumped the coreboot SSDT and found that it wrote a device claiming the PIIX4 PM/SMBus ports, so I revised my other patch to completely drop mine, but the conflict remains. Now I can't pinpoint where the conflict comes from. Second, the command I needed to run to enable flashrom no longer works. i2cset simply said "Write failed". I have to completely disable ACPI to be able to flash. The two problems may be related, but I can't tell for sure. One thing I could do for the second problem is to do the sequence in mainboard ramstage init, but it depends on the southbridge GPO setting to put that chip into the right state. How are these device enable hooks ordered? Does all southbridge hooks get run first before mainboard hooks? Thanks for your help Keith

4 6

T420s white screen
by Jason Andryuk 22 May '20

22 May '20

Hi, I've been running coreboot on my T420s for a year or so. It was working fine, but today it isn't booting. When I hit the power button, I just get a white screen. Well, maybe grey and not white, but not the black background with white text like I usually see for my seabios payload. I tried blindly booting and getting past the disk encryption, but I didn't see the laptop DHCP to the router. I might have botched that though... Once or twice earlier I had this white screen. In those cases, I just powered off and tried again and it worked. Has anyone seen something like this before? One thought is the RTC battery may be old and have lost its charge. But would a dead battery exhibit this behavior? Thanks, Jason

2 3

Updating the BIOS from the OS on a custom motherboard (Intel Atom С3538 Denverton_ns).
by dponamorev＠gmail.com 21 May '20

21 May '20

Hi! I can’t update the BIOS on our custom motherboard (Intel Atom С3538 Denverton_ns SOC) when using a bunch of coreboot + siabios. (When processing BIOS, the Intel Hurcuvar motherboard is taken as a source). The BIOS chip is located on the SPI bus. The BIOS chip size is 16 megabytes. I need to update the BIOS region (bottom 8 MB). The study of the issue led to the BIOS_CNTL registry (SPIBAR_BIOS_CONTROL 0xdc) which is responsible for protection against unauthorized overwriting. At the very beginning of the coreboot start, memory testing and training is performed and the parameters are writed to the BIOS chip (MRC). For this, the BIOS chip becomes available for writing. I found this code in the fast_spi.c file. But further, at the end of loading the FSP, the BIOS chip is locket down (As I understand by FSP). I found these lines in the booting log: Fsp PchFspOnEndOfDxe() Start Common PchOnEndOfDxe() Start GC = 0xFDCF000C Value = 0x00000002 Protected range 0: 0x80000000 Protected range 1: 0x80000000 Protected range 2: 0x80000000 Protected range 3: 0x80000000 Protected range 4: 0x80000000 Set LPC EISS Set SPI EISS Set LPC bios lock Set SPI bios lock PM_CFG = 0xFE000018 Value = 0x29C0002C I tried to rewrite SPIBAR_BIOS_CONTROL=0xdc after that: fast_spi_init; bios_cntl = pci_read_config8(dev, SPIBAR_BIOS_CONTROL); bios_cntl: 0xab fast_spi_init; bios_cntl &= ~SPIBAR_BIOS_CONTROL_EISS; bios_cntl: 0x8b fast_spi_init; bios_cntl |= SPIBAR_BIOS_CONTROL_WPD bios_cntl: 0x8b fast_spi_init; bios_cntl |= SPIBAR_BIOS_CONTROL_PREFETCH_ENABLE bios_cntl: 0x8b fast_spi_init; bios_cntl &= ~SPIBAR_BIOS_CONTROL_CACHE_DISABLE bios_cntl: 0x8b fast_spi_init; READ bios_cntl: 0x8b But in Linux I still get 0xDC register value 0xA2. The bit[0] is equal to zero, which means write is not possible. (Write Protect Disable (WPD): When set, access to the BIOS space is enabled for both read and write cycles to BIOS. When cleared, only read cycles are permitted to the FWH or SPI flash. When this bit is written from a '0' to a '1' and the LE bit is also set, an SMI# is generated. This ensures that only SMM code can update BIOS.) Is it possible to somehow tell the FSP not to “Set SPI bios lock”? What to do to access the possibility of updating the bios region from operating systems? Why I do not see the SPI bus in the /dev/? Using inteltool –s utility, I got the following output: ./inteltool -s CPU: ID 0x506f1, Processor Type 0x0, Family 0x6, Model 0x5f, Stepping 0x1 Northbridge: 8086:1980 (unknown) Southbridge: 8086:19dc (Denverton) ============= SPI / BIOS CNTL ============= SB devive ID: 0x19dc BIOS_CNTL = 0x00a2 (IO) 0x0000 = BIOSWE - write enable 0x0001 = BLE - lock enable 0x0000 = SPI Read configuration 0x0000 = TopSwapStatus 0x0001 = SMM Bios Write Protect Disable 0x0002 = reserved ============= SPI Bar ============== rcba_phys: 0x0 rcba: 0x6d16b000 0xf000ff53 = BFPR - BIOS Flash primary region 0x0000ff53 = HSFSTS - Hardware Sequencing Flash Status 0x0000f000 = HSFCTL - Hardware Sequencing Flash Control 0xf000e2c3 = FADDR - Flash Address 0xf000ff53 = Reserved 0xf000ff53 = FDATA0 0xf000e739 = FRACC - Flash Region Access Permissions 0xf000f859 = Flash Region 0 0xf000e82e = Flash Region 1 0xf000efd2 = Flash Region 2 0xf000d44f = Flash Region 3 0xf000e6f2 = Flash Region 4 0xf000ff53 = FPR0 Flash Protected Range 0 0xf000665c = FPR0 Flash Protected Range 1 0xc000503b = FPR0 Flash Protected Range 2 0xf000ff53 = FPR0 Flash Protected Range 3 0xf000ff53 = FPR0 Flash Protected Range 4 0x00000053 = SSFSTS - Software Sequencing Flash Status 0x0000ff53 = PREOP - Prefix opcode Configuration 0x0000f000 = OPTYPE - Opcode Type Configuration 0xf000ff53f000ff53 = OPMENU - Opcode Menu Configuration 0x00000053 = BBAR - BIOS Base Address Configuration 0xf000ff53 = FDOC - Flash Descriptor Observability Control 0xf000ff53 = Reserved 0xf000ff53 = AFC - Additional Flash Control 0xf000ff53 = LVSCC - Host Lower Vendor Specific Component Capabilities 0xf000ff53 = UVSCC - Host Upper Vendor Specific Component Capabilities 0xf000ff53 = FPB - Flash Partition Boundary

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2020