coreboot-gerrit February 2020

coreboot-gerrit@coreboot.org

1 participants
1796 discussions

Change in coreboot[master]: Documentation: xx30 ThinkPads internal flashing
by Evgeny Zinoviev (Code Review) 05 Feb '20

05 Feb '20

Evgeny Zinoviev has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/36666 ) Change subject: Documentation: xx30 ThinkPads internal flashing ...................................................................... Documentation: xx30 ThinkPads internal flashing Add detailed instructions on how to unlock protected SPI ranges and flash coreboot internally on Lenovo ThinkPad Ivy Bridge series by exploiting stock BIOS security issues. Change-Id: I8d8551910c31fd2e6ff728e17dafaea45970166b Signed-off-by: Evgeny Zinoviev <me(a)ch1p.io> --- M Documentation/mainboard/index.md A Documentation/mainboard/lenovo/ivb_bios_flashing1.jpg A Documentation/mainboard/lenovo/ivb_bios_flashing2.jpg A Documentation/mainboard/lenovo/ivb_bios_legacy_only.jpg A Documentation/mainboard/lenovo/ivb_bios_uefi_only.jpg A Documentation/mainboard/lenovo/ivb_internal_flashing.md 6 files changed, 318 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/66/36666/1 diff --git a/Documentation/mainboard/index.md b/Documentation/mainboard/index.md index 8e88443..0e71add 100644 --- a/Documentation/mainboard/index.md +++ b/Documentation/mainboard/index.md @@ -90,6 +90,7 @@ - [W530](lenovo/w530.md) - [T430 / T530 / X230 / W530 common](lenovo/xx30_series.md) - [T431s](lenovo/t431s.md) +- [Internal flashing](lenovo/ivb_internal_flashing.md) ### Haswell series diff --git a/Documentation/mainboard/lenovo/ivb_bios_flashing1.jpg b/Documentation/mainboard/lenovo/ivb_bios_flashing1.jpg new file mode 100644 index 0000000..10a27b0 --- /dev/null +++ b/Documentation/mainboard/lenovo/ivb_bios_flashing1.jpg Binary files differ diff --git a/Documentation/mainboard/lenovo/ivb_bios_flashing2.jpg b/Documentation/mainboard/lenovo/ivb_bios_flashing2.jpg new file mode 100644 index 0000000..4be1101 --- /dev/null +++ b/Documentation/mainboard/lenovo/ivb_bios_flashing2.jpg Binary files differ diff --git a/Documentation/mainboard/lenovo/ivb_bios_legacy_only.jpg b/Documentation/mainboard/lenovo/ivb_bios_legacy_only.jpg new file mode 100644 index 0000000..aef9c7b --- /dev/null +++ b/Documentation/mainboard/lenovo/ivb_bios_legacy_only.jpg Binary files differ diff --git a/Documentation/mainboard/lenovo/ivb_bios_uefi_only.jpg b/Documentation/mainboard/lenovo/ivb_bios_uefi_only.jpg new file mode 100644 index 0000000..7def81e --- /dev/null +++ b/Documentation/mainboard/lenovo/ivb_bios_uefi_only.jpg Binary files differ diff --git a/Documentation/mainboard/lenovo/ivb_internal_flashing.md b/Documentation/mainboard/lenovo/ivb_internal_flashing.md new file mode 100644 index 0000000..b9a023e --- /dev/null +++ b/Documentation/mainboard/lenovo/ivb_internal_flashing.md @@ -0,0 +1,317 @@ +# Ivy Bridge Lenovo ThinkPad Internal Flashing + +## Introduction + +Old versions of stock BIOS for these models have several security issues. In order to flash coreboot internally, two of them are of interest. + +**First** is the fact the SMM_BWP and BLE are not enabled in BIOS versions released before 2014. We have tested many versions on T430 and X230 and found out that SMM_BWP=1 only since the update, the changelog of which contains following line: + +> (New) Improved the UEFI BIOS security feature. + +**Second** is [S3 Boot Script vulnerability](https://support.lenovo.com/eg/ru/product_security/s3_boot_pr…, that was discovered and fixed later. + +## Requirements + +- USB drive (in case you need to downgrade BIOS) +- Linux install that (can be) loaded in UEFI mode +- [CHIPSEC](https://github.com/chipsec/chipsec) + +## BIOS versions + +Below is a table of BIOS versions that are vulnerable enough for our goals, per model. The version number means that you need to downgrade to that or earlier version. + +```eval_rst ++------------+--------------+ +| Model | BIOS version | ++============+==============+ +| X230 | 2.60 | ++------------+--------------+ +| T430 | 2.64 | ++------------+--------------+ +| T430s | 2.59 | ++------------+--------------+ +| T530 | 2.60 | ++------------+--------------+ +| W530 | 2.58 | ++------------+--------------+ +``` + +If your BIOS version is equal or lower, skip to the **[Examining protections](#examining-protections-theory)** section. If not, go through the downgrade process, described next. + +## Downgrading BIOS + +Go to the Lenovo web site and download BIOS Update Bootable CD for your machine of needed version (see above). + +Lenovo states that BIOS has "security rollback prevention", meaning once you update it to some version X, you will not be able to downgrade it to pre-X version. That's not true. It seems that this is completely client-side restriction in flashing utilities (both Windows utility and Bootable CD). You just need to call `winflash.exe` or `dosflash.exe` directly. Therefore you need to modify the bootable CD image you just downloaded. + +Extract an El Torito image: +``` +geteltorito -o ./bios.img g1uj41us.iso +``` +Mount the partition in that image: +``` +sudo mount -t vfat ./bios.img /mnt -o loop,offset=16384 +``` +List files, find the `AUTOEXEC.BAT` file and the `FLASH` directory: +``` +ls /mnt +ls /mnt/FLASH +``` + +Inside the `FLASH` directory, there should be a directory called `G1ET93WW` or similar (exact name depends on your ThinkPad model and BIOS version). See what's inside: +``` +ls /mnt/FLASH/G1ET93WW +``` +There must be a file with `.FL1` extension called `$01D2000.FL1` or something similar. + +Now open the `AUTOEXEC.BAT` file: +``` +sudo vim /mnt/AUTOEXEC.BAT +``` +You will see a list of commands: +``` +@ECHO OFF +PROMPT $p$g +cd c:\flash +command.com +``` +Replace the last line (`command.com`) with this (change path to the `.FL1` file according to yours): +``` +dosflash.exe /sd /file G1ET93WW\$01D2000.FL1 +``` + +Save the file, then unmount the partition: +``` +sudo unmount /mnt +``` + +Write this image to a USB drive (replace `/dev/sdX` with your USB drive device name): +``` +sudo dd if=./bios.img of=/dev/sdX bs=1M +``` + +Now reboot and press F1 to enter BIOS settings. Open the **Startup** tab and set the startup mode to **Legacy** (or **Both**/**Legacy First**): + +![](ivb_bios_legacy_only.jpg) + +Press F10 to save changes and reboot. + +Now, before you process, make sure that AC adapter is connected! If your battery will die during the process, you'll likely need external programmer to recover. + +Boot from the USB drive (press F12 to select boot device), and BIOS flashing process should begin: + +![](ivb_bios_flashing1.jpg) + +![](ivb_bios_flashing2.jpg) + +It may reboot a couple of times in the process. Do not interrupt it. + +When it's completed, go back to the BIOS settings and set startup mode to **UEFI** (or **Both**/**UEFI First**). This is required for vulnerability exploitation. + +![](ivb_bios_uefi_only.jpg) + +Then boot to your system and make sure that `/sys/firmware/efi` or `/sys/firmware/efivars` exist. + +## Examining protections (theory) + +There are two main ways that Intel platform provides to protect BIOS chip: +- **BIOS_CNTL** register of LPC Interface Bridge Registers (accessible via PCI configuration space, offset 0xDC). It has: + * **SMM_BWP** (*SMM BIOS Write Protect*) bit. If set to 1, the BIOS is writable only in SMM. Once set to 1, cannot be changed anymore. + * **BLE** (*BIOS Lock Enable*) bit. If set to 1, setting BIOSWE to 1 will raise SMI. Once set to 1, cannot be changed anymore. + * **BIOSWE** (*BIOS Write Enable*) bit. Controls whether BIOS is writable. This bit is always R/W. +- SPI Protected Range Registers (**PR0**-**PR4**) of SPI Configuration Registers (SPIBAR+0x74 - SPIBAR+0x84). Each register has bits that define protected range, plus WP bit, that defines whether write protection is enabled. + + There's also **FLOCKDN** bit of HSFS register (SPIBAR+0x04) of SPI Configuration Registers. When set to 1, PR0-PR4 registers cannot be written. Once set to 1, cannot be changed anymore. + +To be able to flash, we need SMM_BWP=0, BIOSWE=1, BLE=0, FLOCKDN=0 or SPI protected ranges (PRx) to have a WP bit set to 0. + +Let's see what we have. Examine HSFS register: +``` +sudo chipsec_main -m chipsec.modules.common.spi_lock +``` +You should see that FLOCKDN=1: +``` +[x][ ======================================================================= +[x][ Module: SPI Flash Controller Configuration Locks +[x][ ======================================================================= +[*] HSFS = 0xE009 << Hardware Sequencing Flash Status Register (SPIBAR + 0x4) + [00] FDONE = 1 << Flash Cycle Done + [01] FCERR = 0 << Flash Cycle Error + [02] AEL = 0 << Access Error Log + [03] BERASE = 1 << Block/Sector Erase Size + [05] SCIP = 0 << SPI cycle in progress + [13] FDOPSS = 1 << Flash Descriptor Override Pin-Strap Status + [14] FDV = 1 << Flash Descriptor Valid + [15] FLOCKDN = 1 << Flash Configuration Lock-Down +``` + +Then check BIOS_CNTL and PR0-PR4: +``` +sudo chipsec_main -m common.bios_wp +``` +Good news: on old BIOS versions, SMM_BWP=0 and BLE=0. + +Bad news: there are 4 write protected SPI ranges: + +``` +[x][ ======================================================================= +[x][ Module: BIOS Region Write Protection +[x][ ======================================================================= +[*] BC = 0x 8 << BIOS Control (b:d.f 00:31.0 + 0xDC) + [00] BIOSWE = 0 << BIOS Write Enable + [01] BLE = 0 << BIOS Lock Enable + [02] SRC = 2 << SPI Read Configuration + [04] TSS = 0 << Top Swap Status + [05] SMM_BWP = 0 << SMM BIOS Write Protection +[-] BIOS region write protection is disabled! + +[*] BIOS Region: Base = 0x00500000, Limit = 0x00BFFFFF +SPI Protected Ranges +------------------------------------------------------------ +PRx (offset) | Value | Base | Limit | WP? | RP? +------------------------------------------------------------ +PR0 (74) | 00000000 | 00000000 | 00000000 | 0 | 0 +PR1 (78) | 8BFF0B40 | 00B40000 | 00BFFFFF | 1 | 0 +PR2 (7C) | 8B100B10 | 00B10000 | 00B10FFF | 1 | 0 +PR3 (80) | 8ADE0AD0 | 00AD0000 | 00ADEFFF | 1 | 0 +PR4 (84) | 8AAF0800 | 00800000 | 00AAFFFF | 1 | 0 +``` + +Other way to examine SPI configuration registers is to just dump SPIBAR: +``` +sudo chipsec_util mmio dump SPIBAR +``` +You will see SPIBAR address (0xFED1F800) and registers (for example, 00000004 is HSFS): +``` +[mmio] MMIO register range [0x00000000FED1F800:0x00000000FED1F800+00000200]: ++00000000: 0BFF0500 ++00000004: 0004E009 +... +``` +As you can see, the only thing we need is to unset WP bit on PR0-PR4. But that cannot be done once FLOCKDN is set to 1. + +Now the fun part! + +FLOCKDN may only be cleared by a hardware reset, which includes S3 state. On S3 resume boot path, the chipset configuration has to be restored and it's done by executing so-called S3 Boot Scripts. You can dump these scripts by executing: +``` +sudo chipsec_util uefi s3bootscript +``` +There are many entries. Along them, you can find instructions to write to HSFS (remember, we know that SPIBAR is 0xFED1F800): +``` +Entry at offset 0x2B8F (len = 0x17, header len = 0x0): +Data: +02 00 17 02 00 00 00 01 00 00 00 04 f8 d1 fe 00 | +00 00 00 09 e0 04 00 | +Decoded: + Opcode : S3_BOOTSCRIPT_MEM_WRITE (0x0002) + Width : 0x02 (4 bytes) + Address: 0xFED1F804 + Count : 0x1 + Values : 0x0004E009 +``` +These scripts are stored in memory. The vulnerability is that we can overwrite this memory, change these instructions and they will be executed on S3 resume. Once we patch that instruction to not set FLOCKDN bit, we will be able to write to PR0-PR4 registers. + +## Creating a backup + +Before you proceed, please create a backup of the `bios` region. Then, in case something goes wrong, you'll be able to flash it back externally. + +The `me` region is locked, so an attempt to create a full dump will fail. But you can back up the `bios`: +``` +sudo flashrom -p internal -r bios_backup.rom --ifd -i bios +``` + +If you will even need to flash it back, use `--ifd -i bios` as well: +``` +sudo flashrom -p <YOUR_PROGRAMMER> -w bios_backup.rom --ifd -i bios +``` +**Caution:** if you will omit `--ifd -i bios` for flashing, you will brick your machine, because your backup has `FF`s in place of `fd` and `me` regions. Flash only `bios` region! + +## Removing protections (practice) + +The original boot script writes 0xE009 to HSFS. FLOCKDN is 15th bit, so let's write 0x6009 instead: +``` +sudo chipsec_main -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xFED1F804,0x6009,0x2 +``` +You will get a lot of output and in the end you should see something like this: +``` +[*] Modifying S3 boot script entry at address 0x00000000DAF49B8F.. +[mem] 0x00000000DAF49B8F +[*] Original entry: + 2 0 17 2 0 0 0 1 0 0 0 4 f8 d1 fe 0 | + 0 0 0 9 e0 4 0 | +[mem] buffer len = 0x17 to PA = 0x00000000DAF49B8F + 2 0 17 2 0 0 0 1 0 0 0 4 f8 d1 fe 0 | + 0 0 0 9 60 0 0 | ` +[mem] 0x00000000DAF49B8F +[*] Modified entry: + 2 0 17 2 0 0 0 1 0 0 0 4 f8 d1 fe 0 | + 0 0 0 9 60 0 0 | ` +[*] After sleep/resume, check the value of register 0xFED1F804 is 0x6009 +[+] PASSED: The script has been modified. Go to sleep.. +``` +Now go to S3, then resume and check FLOCKDN. It should be 0: +``` +sudo chipsec_main -m chipsec.modules.common.spi_lock +``` +``` +... +[x][ ======================================================================= +[x][ Module: SPI Flash Controller Configuration Locks +[x][ ======================================================================= +[*] HSFS = 0x6008 << Hardware Sequencing Flash Status Register (SPIBAR + 0x4) + [00] FDONE = 0 << Flash Cycle Done + [01] FCERR = 0 << Flash Cycle Error + [02] AEL = 0 << Access Error Log + [03] BERASE = 1 << Block/Sector Erase Size + [05] SCIP = 0 << SPI cycle in progress + [13] FDOPSS = 1 << Flash Descriptor Override Pin-Strap Status + [14] FDV = 1 << Flash Descriptor Valid + [15] FLOCKDN = 0 << Flash Configuration Lock-Down +[-] SPI Flash Controller configuration is not locked +[-] FAILED: SPI Flash Controller not locked correctly. +... +``` +Set BIOSWE: +``` +sudo setpci -s 00:1f.0 dc.b=09 +``` +Remove WP from protected ranges: +``` +sudo chipsec_util mmio write SPIBAR 0x74 0x4 0xAAF0800 +sudo chipsec_util mmio write SPIBAR 0x78 0x4 0xADE0AD0 +sudo chipsec_util mmio write SPIBAR 0x7C 0x4 0xB100B10 +sudo chipsec_util mmio write SPIBAR 0x80 0x4 0xBFF0B40 +``` +Verify that it worked: +``` +sudo chipsec_main -m common.bios_wp +``` +``` +[x][ ======================================================================= +[x][ Module: BIOS Region Write Protection +[x][ ======================================================================= +[*] BC = 0x 9 << BIOS Control (b:d.f 00:31.0 + 0xDC) + [00] BIOSWE = 1 << BIOS Write Enable + [01] BLE = 0 << BIOS Lock Enable + [02] SRC = 2 << SPI Read Configuration + [04] TSS = 0 << Top Swap Status + [05] SMM_BWP = 0 << SMM BIOS Write Protection +[-] BIOS region write protection is disabled! + +[*] BIOS Region: Base = 0x00500000, Limit = 0x00BFFFFF +SPI Protected Ranges +------------------------------------------------------------ +PRx (offset) | Value | Base | Limit | WP? | RP? +------------------------------------------------------------ +PR0 (74) | 0AAF0800 | 00800000 | 00AAF000 | 0 | 0 +PR1 (78) | 0ADE0AD0 | 00AD0000 | 00ADE000 | 0 | 0 +PR2 (7C) | 0B100B10 | 00B10000 | 00B10000 | 0 | 0 +PR3 (80) | 0BFF0B40 | 00B40000 | 00BFF000 | 0 | 0 +PR4 (84) | 00000000 | 00000000 | 00000000 | 0 | 0 +``` + +Bingo! + +Now you can [flash internally](/flash_tutorial/int_flashrom.md). Remember to flash only the `bios` region (use `--ifd -i bios -N` flashrom arguments). `fd` and `me` are still locked. + +Note that you should have an external SPI programmer as a backup method. It will help you recover if you flash non-working ROM by mistake. -- To view, visit https://review.coreboot.org/c/coreboot/+/36666 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I8d8551910c31fd2e6ff728e17dafaea45970166b Gerrit-Change-Number: 36666 Gerrit-PatchSet: 1 Gerrit-Owner: Evgeny Zinoviev <me(a)ch1p.io> Gerrit-MessageType: newchange

5 8

Change in coreboot[master]: mb/google/drallion: Use GPP_D15 as touch reset pin
by EricR Lai (Code Review) 05 Feb '20

05 Feb '20

EricR Lai has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/38665 ) Change subject: mb/google/drallion: Use GPP_D15 as touch reset pin ...................................................................... mb/google/drallion: Use GPP_D15 as touch reset pin Follow HW change to use GPP_D15 as TS_RST. BUG=b:143733039 TEST=Check touch screen is functional in s0 and resume from s0ix Signed-off-by: Eric Lai <ericr_lai(a)compal.corp-partner.google.com> Change-Id: Ieec7eb78a05e653f271e348ed11f7e31c08bd5dc --- M src/mainboard/google/drallion/variants/drallion/devicetree.cb M src/mainboard/google/drallion/variants/drallion/gpio.c 2 files changed, 14 insertions(+), 4 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/65/38665/1 diff --git a/src/mainboard/google/drallion/variants/drallion/devicetree.cb b/src/mainboard/google/drallion/variants/drallion/devicetree.cb index 97860f4..ff5942b 100644 --- a/src/mainboard/google/drallion/variants/drallion/devicetree.cb +++ b/src/mainboard/google/drallion/variants/drallion/devicetree.cb @@ -336,9 +336,14 @@ register "generic.desc" = ""Wacom Touchscreen"" register "generic.irq" = "ACPI_IRQ_LEVEL_LOW(GPP_C23_IRQ)" register "generic.probed" = "1" - register "generic.stop_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_E7)" - register "generic.stop_delay_ms" = "20" - register "generic.enable_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_B21)" + register "generic.reset_gpio" = + "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_D15)" + register "generic.reset_delay_ms" = "10" + register "generic.stop_gpio" = + "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_E7)" + register "generic.stop_delay_ms" = "10" + register "generic.enable_gpio" = + "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_B21)" register "generic.enable_delay_ms" = "55" register "generic.has_power_resource" = "1" register "generic.disable_gpio_export_in_crs" = "1" @@ -352,6 +357,9 @@ register "generic.desc" = ""ELAN Touchscreen"" register "generic.irq" = "ACPI_IRQ_EDGE_LOW(GPP_C23_IRQ)" register "generic.probed" = "1" + register "generic.reset_gpio" = + "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_D15)" + register "generic.reset_delay_ms" = "10" register "generic.stop_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_E7)" register "generic.stop_delay_ms" = "10" @@ -369,6 +377,8 @@ register "desc" = ""Melfas Touchscreen"" register "irq" = "ACPI_IRQ_EDGE_LOW(GPP_C23_IRQ)" register "probed" = "1" + register "reset_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_D15)" + register "reset_delay_ms" = "10" register "stop_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_E7)" register "stop_delay_ms" = "10" register "enable_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_B21)" diff --git a/src/mainboard/google/drallion/variants/drallion/gpio.c b/src/mainboard/google/drallion/variants/drallion/gpio.c index f2b7079..9666c2d 100644 --- a/src/mainboard/google/drallion/variants/drallion/gpio.c +++ b/src/mainboard/google/drallion/variants/drallion/gpio.c @@ -124,7 +124,7 @@ /* ISH_UART0_RXD */ PAD_CFG_NF(GPP_D13, UP_20K, DEEP, NF1), /* ISH_CPU_UART0_TX */ /* ISH_UART0_TXD */ PAD_CFG_NF(GPP_D14, NONE, DEEP, NF1), -/* ISH_UART0_RTS# */ PAD_NC(GPP_D15, NONE), +/* ISH_UART0_RTS# */ PAD_CFG_GPO(GPP_D15, 0, DEEP), /* TS_RST */ /* ISH_UART0_CTS# */ PAD_CFG_GPI(GPP_D16, NONE, PLTRST), /* DMIC_CLK1 */ PAD_CFG_GPI(GPP_D17, NONE, PLTRST), /* KB_DET# */ /* DMIC_DATA1 */ PAD_CFG_GPI_APIC(GPP_D18, NONE, PLTRST, -- To view, visit https://review.coreboot.org/c/coreboot/+/38665 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ieec7eb78a05e653f271e348ed11f7e31c08bd5dc Gerrit-Change-Number: 38665 Gerrit-PatchSet: 1 Gerrit-Owner: EricR Lai <ericr_lai(a)compal.corp-partner.google.com> Gerrit-MessageType: newchange

4 10

Change in coreboot[master]: libpayload/xhci: Fix MPS handling in set_address
by Patrick Georgi (Code Review) 05 Feb '20

05 Feb '20

Patrick Georgi has submitted this change. ( https://review.coreboot.org/c/coreboot/+/38556 ) Change subject: libpayload/xhci: Fix MPS handling in set_address ...................................................................... libpayload/xhci: Fix MPS handling in set_address We set MPS to speed_to_default_mps(speed) initially but later compare maxpacketsize with 8 to change mps. So compare with speed_to_default_mps(speed) to determine if we need to change settings here. BUG=b:147783572 BRANCH=none TEST=works with 12Mbps/8MPS USB device Signed-off-by: Kangheui Won <khwon(a)chromium.org> Change-Id: I32455483fceec56f14af6118b77615c14b3f9f39 Reviewed-on: https://review.coreboot.org/c/coreboot/+/38556 Reviewed-by: Edward O'Callaghan <quasisec(a)chromium.org> Reviewed-by: Patrick Georgi <pgeorgi(a)google.com> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- M payloads/libpayload/drivers/usb/xhci_devconf.c 1 file changed, 1 insertion(+), 1 deletion(-) Approvals: build bot (Jenkins): Verified Patrick Georgi: Looks good to me, approved Edward O'Callaghan: Looks good to me, approved diff --git a/payloads/libpayload/drivers/usb/xhci_devconf.c b/payloads/libpayload/drivers/usb/xhci_devconf.c index 3f50caa..51ff29f 100644 --- a/payloads/libpayload/drivers/usb/xhci_devconf.c +++ b/payloads/libpayload/drivers/usb/xhci_devconf.c @@ -227,7 +227,7 @@ } dev->endpoints[0].maxpacketsize = usb_decode_mps0(speed, buf[7]); - if (dev->endpoints[0].maxpacketsize != 8) { + if (dev->endpoints[0].maxpacketsize != speed_to_default_mps(speed)) { memset((void *)ic->dev.ep0, 0x00, ctxsize); *ic->add = (1 << 1); /* EP0 Context */ EC_SET(MPS, ic->dev.ep0, dev->endpoints[0].maxpacketsize); -- To view, visit https://review.coreboot.org/c/coreboot/+/38556 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I32455483fceec56f14af6118b77615c14b3f9f39 Gerrit-Change-Number: 38556 Gerrit-PatchSet: 4 Gerrit-Owner: Kangheui Won <khwon(a)chromium.org> Gerrit-Reviewer: Edward O'Callaghan <quasisec(a)chromium.org> Gerrit-Reviewer: Kangheui Won <khwon(a)chromium.org> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Sam McNally <sammc(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Julius Werner <jwerner(a)chromium.org> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-MessageType: merged

1 0

Change in coreboot[master]: libpayload/xhci: Fix MPS handling in set_address
by Patrick Georgi (Code Review) 05 Feb '20

05 Feb '20

Patrick Georgi has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38556 ) Change subject: libpayload/xhci: Fix MPS handling in set_address ...................................................................... Patch Set 3: Code-Review+2 -- To view, visit https://review.coreboot.org/c/coreboot/+/38556 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I32455483fceec56f14af6118b77615c14b3f9f39 Gerrit-Change-Number: 38556 Gerrit-PatchSet: 3 Gerrit-Owner: Kangheui Won <khwon(a)chromium.org> Gerrit-Reviewer: Edward O'Callaghan <quasisec(a)chromium.org> Gerrit-Reviewer: Kangheui Won <khwon(a)chromium.org> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Sam McNally <sammc(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Julius Werner <jwerner(a)chromium.org> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Comment-Date: Wed, 05 Feb 2020 09:56:22 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: mb/google/hatch: modify PCIe ports setting for mushu
by Amanda Hwang (Code Review) 05 Feb '20

05 Feb '20

Amanda Hwang has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/38399 ) Change subject: mb/google/hatch: modify PCIe ports setting for mushu ...................................................................... mb/google/hatch: modify PCIe ports setting for mushu 1. Enabled PCIe port for dGPU 2. Change WLAN PCIe port from port 14 to prot 7 3. Enabled PCIe port for GPU REFCLK BUG=b:147249494 TEST=Ensure dGPU and WLAN shows up with lspci. Change-Id: Iea3292be7d8029c35847118228bbb773418632a1 --- M src/mainboard/google/hatch/variants/mushu/overridetree.cb 1 file changed, 22 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/99/38399/1 diff --git a/src/mainboard/google/hatch/variants/mushu/overridetree.cb b/src/mainboard/google/hatch/variants/mushu/overridetree.cb index c623fde..c584515 100644 --- a/src/mainboard/google/hatch/variants/mushu/overridetree.cb +++ b/src/mainboard/google/hatch/variants/mushu/overridetree.cb @@ -63,6 +63,28 @@ .fall_time_ns = 120, }, }" + + # Enable Root port 13(x4) for dGPU. + register "PcieRpEnable[12]" = "1" + register "PcieRpLtrEnable[12]" = "1" + # RP 13 uses CLK SRC 5 + register "PcieClkSrcUsage[5]" = "12" + # ClkReq-to-ClkSrc mapping for CLK SRC 5 + register "PcieClkSrcClkReq[5]" = "5" + + # PCIe port 3 reserve for GPU REFCLK + register "PcieRpEnable[2]" = "1" + register "PcieRpLtrEnable[2]" = "1" + # RP 3 uses CLK SRC 2 + register "PcieClkSrcUsage[2]" = "2" + register "PcieClkSrcClkReq[2]" = "2" + + # PCIe port 7 for M.2 E-key WLAN + register "PcieRpEnable[6]" = "1" + register "PcieRpLtrEnable[6]" = "1" + # RP 7 uses CLK SRC 3 + register "PcieClkSrcUsage[3]" = "6" + register "PcieClkSrcClkReq[3]" = "3" # GPIO for SD card detect register "sdcard_cd_gpio" = "vSD3_CD_B" -- To view, visit https://review.coreboot.org/c/coreboot/+/38399 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Iea3292be7d8029c35847118228bbb773418632a1 Gerrit-Change-Number: 38399 Gerrit-PatchSet: 1 Gerrit-Owner: Amanda Hwang <amanda_hwang(a)compal.corp-partner.google.com> Gerrit-MessageType: newchange

7 23

Change in coreboot[master]: mb/intel/tglrvp: pin mux for ISH
by Wonkyu Kim (Code Review) 05 Feb '20

05 Feb '20

Wonkyu Kim has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/38622 ) Change subject: mb/intel/tglrvp: pin mux for ISH ...................................................................... mb/intel/tglrvp: pin mux for ISH pin mux for ISHUART0, ISHI2C0, ISHGPIO0-7 BUG=none BRANCH=none TEST=Build and boot to OS and check pinctl driver to check pin mux Signed-off-by: Wonkyu Kim <wonkyu.kim(a)intel.com> Change-Id: I1a9ba3a713527f5ce962659960418cd0f37dd262 --- M src/mainboard/intel/tglrvp/variants/tglrvp_up3/gpio.c 1 file changed, 18 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/22/38622/1 diff --git a/src/mainboard/intel/tglrvp/variants/tglrvp_up3/gpio.c b/src/mainboard/intel/tglrvp/variants/tglrvp_up3/gpio.c index 69bb931..5806b3c 100644 --- a/src/mainboard/intel/tglrvp/variants/tglrvp_up3/gpio.c +++ b/src/mainboard/intel/tglrvp/variants/tglrvp_up3/gpio.c @@ -28,6 +28,24 @@ PAD_CFG_GPO(GPP_C15, 0, PLTRST), PAD_CFG_GPO(GPP_R6, 0, PLTRST), PAD_CFG_GPO(GPP_H12, 0, PLTRST), + + /* ISH UART0 RX/TX */ + PAD_CFG_NF(GPP_D13, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_D14, NONE, PLTRST, NF1), + + /* ISH I2C0 */ + PAD_CFG_NF(GPP_B5, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_B6, NONE, PLTRST, NF1), + + /* ISH GPI 0-6 */ + PAD_CFG_NF(GPP_D0, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_D1, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_D2, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_D3, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_D17, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_D18, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_E15, NONE, PLTRST, NF1), + PAD_CFG_NF(GPP_E16, NONE, PLTRST, NF1), }; /* Early pad configuration in bootblock */ -- To view, visit https://review.coreboot.org/c/coreboot/+/38622 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I1a9ba3a713527f5ce962659960418cd0f37dd262 Gerrit-Change-Number: 38622 Gerrit-PatchSet: 1 Gerrit-Owner: Wonkyu Kim <wonkyu.kim(a)intel.com> Gerrit-MessageType: newchange

4 10

Change in coreboot[master]: WIP: Move SA _CRS to runtime SSDT generator
by Furquan Shaikh (Code Review) 05 Feb '20

05 Feb '20

Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38608 ) Change subject: WIP: Move SA _CRS to runtime SSDT generator ...................................................................... Patch Set 2: (1 comment) https://review.coreboot.org/c/coreboot/+/38608/2/src/soc/intel/common/block… File src/soc/intel/common/block/systemagent/systemagent.c: https://review.coreboot.org/c/coreboot/+/38608/2/src/soc/intel/common/block… PS2, Line 285: 0xfee00000 > LOCAL_APIC_ADDR Ah yes! I will change that. -- To view, visit https://review.coreboot.org/c/coreboot/+/38608 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I58fbc5c99dcdb9463da9f2ace3423294af614abf Gerrit-Change-Number: 38608 Gerrit-PatchSet: 2 Gerrit-Owner: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Duncan Laurie <dlaurie(a)chromium.org> Gerrit-CC: Subrata Banik <subrata.banik(a)intel.com> Gerrit-Comment-Date: Wed, 05 Feb 2020 08:19:44 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Duncan Laurie <dlaurie(a)chromium.org> Gerrit-MessageType: comment

1 0

Change in coreboot[master]: src/ec/google/chromeec: Get Type-C Mux info from EC (TCPM)
by Tim Wawrzynczak (Code Review) 05 Feb '20

05 Feb '20

Tim Wawrzynczak has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37867 ) Change subject: src/ec/google/chromeec: Get Type-C Mux info from EC (TCPM) ...................................................................... Patch Set 11: (1 comment) https://review.coreboot.org/c/coreboot/+/37867/11/src/ec/google/chromeec/ec… File src/ec/google/chromeec/ec.c: https://review.coreboot.org/c/coreboot/+/37867/11/src/ec/google/chromeec/ec… PS11, Line 1542: /** : * Check for the current mux state in EC : * Flags representing mux state : * USB_PD_MUX_USB_ENABLED BIT(0) : * USB_PD_MUX_DP_ENABLED BIT(1) : * USB_PD_MUX_POLARITY_INVERTED BIT(2) : * USB_PD_MUX_HPD_IRQ BIT(3) : * USB_PD_MUX_HPD_LVL BIT(4) : * USB_PD_MUX_SAFE_MODE BIT(5) : * : */ > this is a copy of what's in ec_commands.h, right? […] case in point: it's already out of sync from master :) -- To view, visit https://review.coreboot.org/c/coreboot/+/37867 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I96bfb6036f4340ba42a078cfd7ecaae777a3ed00 Gerrit-Change-Number: 37867 Gerrit-PatchSet: 11 Gerrit-Owner: Shaunak Saha <shaunak.saha(a)intel.com> Gerrit-Reviewer: Brandon Breitenstein <brandon.breitenstein(a)intel.com> Gerrit-Reviewer: Divya S Sasidharan <divya.s.sasidharan(a)intel.com> Gerrit-Reviewer: Keith Short <keithshort(a)chromium.org> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Reviewer: Raj Astekar <raj.astekar(a)intel.com> Gerrit-Reviewer: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Reviewer: Shaunak Saha <shaunak.saha(a)intel.com> Gerrit-Reviewer: Srinidhi N Kaushik <srinidhi.n.kaushik(a)intel.com> Gerrit-Reviewer: Tim Wawrzynczak <twawrzynczak(a)chromium.org> Gerrit-Reviewer: Wonkyu Kim <wonkyu.kim(a)intel.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Reviewer: caveh jalali <caveh(a)chromium.org> Gerrit-CC: Furquan Shaikh <furquan(a)google.com> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-CC: Pratikkumar V Prajapati <pratikkumar.v.prajapati(a)intel.com> Gerrit-CC: Subrata Banik <subrata.banik(a)intel.com> Gerrit-CC: Vijay P Hiremath <vijay.p.hiremath(a)intel.com> Gerrit-Comment-Date: Wed, 05 Feb 2020 03:44:44 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: caveh jalali <caveh(a)chromium.org> Gerrit-MessageType: comment

1 0

Change in coreboot[master]: src/ec/google/chromeec: Get Type-C Mux info from EC (TCPM)
by caveh jalali (Code Review) 05 Feb '20

05 Feb '20

caveh jalali has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37867 ) Change subject: src/ec/google/chromeec: Get Type-C Mux info from EC (TCPM) ...................................................................... Patch Set 11: (1 comment) https://review.coreboot.org/c/coreboot/+/37867/11/src/ec/google/chromeec/ec… File src/ec/google/chromeec/ec.c: https://review.coreboot.org/c/coreboot/+/37867/11/src/ec/google/chromeec/ec… PS11, Line 1542: /** : * Check for the current mux state in EC : * Flags representing mux state : * USB_PD_MUX_USB_ENABLED BIT(0) : * USB_PD_MUX_DP_ENABLED BIT(1) : * USB_PD_MUX_POLARITY_INVERTED BIT(2) : * USB_PD_MUX_HPD_IRQ BIT(3) : * USB_PD_MUX_HPD_LVL BIT(4) : * USB_PD_MUX_SAFE_MODE BIT(5) : * : */ this is a copy of what's in ec_commands.h, right? i'd rather not replicate this here as it'll invariably get out of sync. -- To view, visit https://review.coreboot.org/c/coreboot/+/37867 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I96bfb6036f4340ba42a078cfd7ecaae777a3ed00 Gerrit-Change-Number: 37867 Gerrit-PatchSet: 11 Gerrit-Owner: Shaunak Saha <shaunak.saha(a)intel.com> Gerrit-Reviewer: Brandon Breitenstein <brandon.breitenstein(a)intel.com> Gerrit-Reviewer: Divya S Sasidharan <divya.s.sasidharan(a)intel.com> Gerrit-Reviewer: Keith Short <keithshort(a)chromium.org> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Reviewer: Raj Astekar <raj.astekar(a)intel.com> Gerrit-Reviewer: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Reviewer: Shaunak Saha <shaunak.saha(a)intel.com> Gerrit-Reviewer: Srinidhi N Kaushik <srinidhi.n.kaushik(a)intel.com> Gerrit-Reviewer: Tim Wawrzynczak <twawrzynczak(a)chromium.org> Gerrit-Reviewer: Wonkyu Kim <wonkyu.kim(a)intel.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Reviewer: caveh jalali <caveh(a)chromium.org> Gerrit-CC: Furquan Shaikh <furquan(a)google.com> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-CC: Pratikkumar V Prajapati <pratikkumar.v.prajapati(a)intel.com> Gerrit-CC: Subrata Banik <subrata.banik(a)intel.com> Gerrit-CC: Vijay P Hiremath <vijay.p.hiremath(a)intel.com> Gerrit-Comment-Date: Wed, 05 Feb 2020 03:40:51 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in coreboot[master]: soc/intel/tigerlake: Add code for early tcss
by caveh jalali (Code Review) 05 Feb '20

05 Feb '20

caveh jalali has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37870 ) Change subject: soc/intel/tigerlake: Add code for early tcss ...................................................................... Patch Set 16: (2 comments) https://review.coreboot.org/c/coreboot/+/37870/16/src/soc/intel/tigerlake/e… File src/soc/intel/tigerlake/early_tcss.c: https://review.coreboot.org/c/coreboot/+/37870/16/src/soc/intel/tigerlake/e… PS16, Line 29: * Flags representing mux state */ : #define USB_PD_MUX_USB_ENABLED BIT(0) /* USB connected */ : #define USB_PD_MUX_DP_ENABLED BIT(1) /* DP connected */ : #define USB_PD_MUX_POLARITY_INVERTED BIT(2) /* CC line Polarity inverted */ : #define USB_PD_MUX_HPD_IRQ BIT(3) /* HPD IRQ is asserted */ : #define USB_PD_MUX_HPD_LVL BIT(4) /* HPD level is asserted */ : we can get these from ec_commands.h, right? https://review.coreboot.org/c/coreboot/+/37870/16/src/soc/intel/tigerlake/e… PS16, Line 158: mux_data.polarity = mux_flags & USB_PD_MUX_POLARITY_INVERTED; i'm a bit confused about the polarity and muxing policy. if there is no external retimer/redriver/TCPC, then TCSS has to do the muxing and it makes sense to ask the EC what the cable orientation is in order to set the mux appropriately. what happens when the muxing is potentially done externally? should we disable/prevent this by system design? my guess is that if we do have a case where muxing is done externally for some reason, the EC will still report the observed orientation and we'll end up double flipping the lanes. has this aspect of the system design been captured somewhere? -- To view, visit https://review.coreboot.org/c/coreboot/+/37870 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I45c3fe9d4a2ec2f2f51b78cca2bd7e623540c00e Gerrit-Change-Number: 37870 Gerrit-PatchSet: 16 Gerrit-Owner: Shaunak Saha <shaunak.saha(a)intel.com> Gerrit-Reviewer: Brandon Breitenstein <brandon.breitenstein(a)intel.com> Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Keith Short <keithshort(a)chromium.org> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: Raj Astekar <raj.astekar(a)intel.com> Gerrit-Reviewer: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Reviewer: Shaunak Saha <shaunak.saha(a)intel.com> Gerrit-Reviewer: Srinidhi N Kaushik <srinidhi.n.kaushik(a)intel.com> Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com> Gerrit-Reviewer: Wonkyu Kim <wonkyu.kim(a)intel.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Reviewer: caveh jalali <caveh(a)chromium.org> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-CC: Pratikkumar V Prajapati <pratikkumar.v.prajapati(a)intel.com> Gerrit-CC: Vijay P Hiremath <vijay.p.hiremath(a)intel.com> Gerrit-Comment-Date: Wed, 05 Feb 2020 03:39:10 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit February 2020