coreboot May 2019

coreboot@coreboot.org

49 participants
56 discussions

Ballot results
by Patrick Georgi 22 May '19

22 May '19

Hi everybody, thanks to all contributors who voted on the issues brought up by the coreboot leadership team. We had 119 eligible voters and three questions. I'll now summarize the results: # How to handle copyright notices https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_9e4f5ea789b9ceb9 59 of 119 eligible contributors voted The options to choose from were: - Create an authors file and remove all existing copyright lines - Create an authors file but leave existing copyright lines - Don't create an authors file or change existing copyright lines "Create an authors file and remove all existing copyright lines" won over both other options. # Line length https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4707336f38d21793 68 of 119 eligible contributors voted The options to choose from were: - 96 characters - 80 characters - 88 characters - 120 characters - 132 characters - no length limit "96 characters" won over all other options. # Automatic code formatting https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_47ad51b336de3a6b 61 of 119 eligible contributors voted The options to choose from were: - Submitters should run clang-format before submitting a patch and it should be rejected in gerrit if it’s not formatted properly with an error telling them how to format it. - coreboot should stick with manual formatting. - Code should just get automatically reformatted on a regular basis. "Submitters should run clang-format ..." won over both other options. There's a coreboot leadership meeting today where I'll present the results to leadership in detail and decisions will be finalized there, but the long and short of it is that out of the options presented, contributors (overall) prefer automatically formatted code that aims for 96 characters and without individual copyright lines in the file headers over all other options. There will be work to be done before these are implemented however. I'll happily answer any questions on the election, its methodology and the outcome. Thanks, Patrick // election supervisor -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Asus M5A88-V (EVO?) Status
by Robin C 22 May '19

22 May '19

Hi all, On coreboot status page, I can see that M5A88-V status is unknown (EVO? M5A88-V seems not referenced in asus support page) But when I search infos about it : https://github.com/DarkDefender/coreboot In coreboot official repo somes changes have been down recently. So is this mainboard officialy supported with the lastest coreboot version and what does or does not work? Best regards SkollRC

4 7

Gpg keys for coreboot distribution
by Chris Laprise 22 May '19

22 May '19

Hi all, I'm about to embark on a coreboot build+flash per Mike Banon's G505s page, but before building I want to verify signatures for the source. These appear in only one place, on the coreboot.org Downloads page, and are signed with the key: D861AB74FB933260193399696B249D77269C04E1 The only problem is there is apparently no mention of the signing key anywhere else on the coreboot website. I usually look for some explicit, official reference (preferably in multiple contexts) to a person or org's key ID before downloading it from a keyserver. Taking the key ID from an object signature doesn't satisfy that requirement. -- Chris Laprise, tasket(a)posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

5 15

Re: inteltool does not properly dump gpio values for south bridge CM238 chipset
by justidl3＠uci.edu 22 May '19

22 May '19

Thanks, I was actually able to get it up and running on coreboot 4.9. The main issue was that i am on fedora, and CONFIG_STRICT_DEVMEM is enabled by default. adding GRUB_CMDLINE_LINUX"iomem=relaxed" while also adding the proper defines in gpio.c and gpio_group.c seemed to fix the issue. my output is now ============= GPIOS ============= ------- GPIO Community 0 ------- PCR Port ID: 0xaf0000 ------- GPIO Group GPP_A ------- 0x0400: 0x0000301844000502 GPP_A0 RCIN# 0x0408: 0x0000001944000402 GPP_A1 LAD0 0x0410: 0x0000001a44000402 GPP_A2 LAD1 0x0418: 0x0000001b44000402 GPP_A3 LAD2 0x0420: 0x0000001c44000402 GPP_A4 LAD3 0x0428: 0x0000001d44000600 GPP_A5 LFRAME# 0x0430: 0x0000241e44000402 GPP_A6 SERIRQ 0x0438: 0x0000001f44000900 GPP_A7 n/a 0x0440: 0x0000002044000500 GPP_A8 CLKRUN# 0x0448: 0x0000002144000600 GPP_A9 CLKOUT_LPC0 0x0450: 0x0000002244000600 GPP_A10 CLKOUT_LPC1 0x0458: 0x0000002344100102 GPP_A11 GPIO 0x0460: 0x0000002444000102 GPP_A12 GPIO 0x0468: 0x0000002544000600 GPP_A13 SUSWARN#/SUSPWRDNACK 0x0470: 0x0000302644000600 GPP_A14 SUS_STAT# 0x0478: 0x0000002744000502 GPP_A15 SUS_ACK# 0x0480: 0x0000002844000201 GPP_A16 GPIO 0x0488: 0x0000002944000201 GPP_A17 GPIO 0x0490: 0x0000002a44000402 GPP_A18 ISH_GP0 0x0498: 0x0000002b44000402 GPP_A19 ISH_GP1 0x04a0: 0x0000002c44000402 GPP_A20 ISH_GP2 0x04a8: 0x0000002d44000502 GPP_A21 ISH_GP3 0x04b0: 0x0000002e44000201 GPP_A22 GPIO 0x04b8: 0x0000002f44100102 GPP_A23 GPIO ------- GPIO Group GPP_B ------- 0x04c0: 0x0000003044000101 GPP_B0 GPIO 0x04c8: 0x0000003144000201 GPP_B1 GPIO 0x04d0: 0x0000003244000300 GPP_B2 GPIO 0x04d8: 0x0000003344000201 GPP_B3 GPIO 0x04e0: 0x0000003444000502 GPP_B4 CPU_GP3 0x04e8: 0x0000003504000102 GPP_B5 GPIO 0x04f0: 0x0000003644000700 GPP_B6 SRCCLKREQ1# 0x04f8: 0x0000003744000700 GPP_B7 SRCCLKREQ2# 0x0500: 0x0000003844000700 GPP_B8 SRCCLKREQ3# 0x0508: 0x0000003944000700 GPP_B9 SRCCLKREQ4# 0x0510: 0x0000003a44000700 GPP_B10 SRCCLKREQ5# 0x0518: 0x0000003b44000601 GPP_B11 n/a 0x0520: 0x0000003c44000601 GPP_B12 SLP_S0# 0x0528: 0x0000003d44000601 GPP_B13 PLTRST# 0x0530: 0x0000003e42840101 GPP_B14 GPIO 0x0538: 0x0000003f44000300 GPP_B15 GPIO 0x0540: 0x0000004084800102 GPP_B16 GPIO 0x0548: 0x0000004144000201 GPP_B17 GPIO 0x0550: 0x0000004244000200 GPP_B18 GPIO 0x0558: 0x0000004344000200 GPP_B19 GPIO 0x0560: 0x0000004444000600 GPP_B20 GSPI1_CLK 0x0568: 0x0000004544000502 GPP_B21 GSPI1_MISO 0x0570: 0x0000004644000600 GPP_B22 GSPIO_MOSI 0x0578: 0x0000004744000201 GPP_B23 GPIO ------- GPIO Community 1 ------- PCR Port ID: 0xae0000 ------- GPIO Group GPP_C ------- 0x0400: 0x0000004844000602 GPP_C0 SMBCLK 0x0408: 0x0000004944000402 GPP_C1 SMBDATA 0x0410: 0x0000104a44000502 GPP_C2 SMBALERT# 0x0418: 0x0000304b44000602 GPP_C3 SML0CLK 0x0420: 0x0000304c44000402 GPP_C4 SML0DATA 0x0428: 0x0000004d44000200 GPP_C5 GPIO 0x0430: 0xffffffffffffffff GPP_C6 RESERVED 0x0438: 0xffffffffffffffff GPP_C7 RESERVED 0x0440: 0x0000005044000502 GPP_C8 UART0_RXD 0x0448: 0x0000005144000600 GPP_C9 UART0_TXD 0x0450: 0x0000005244000600 GPP_C10 UART0_RTS# 0x0458: 0x0000005344000502 GPP_C11 UART0_CTS# 0x0460: 0x0000005444000502 GPP_C12 UART1_RXD 0x0468: 0x0000005544000600 GPP_C13 UART1_TXD 0x0470: 0x0000005644000600 GPP_C14 UART1_RTS# 0x0478: 0x0000005744000502 GPP_C15 UART1_CTS# 0x0480: 0x0000305844000402 GPP_C16 I2C0_SDA 0x0488: 0x0000305944000602 GPP_C17 I2C0_SCL 0x0490: 0x0000305a44000402 GPP_C18 I2C1_SDA 0x0498: 0x0000305b44000602 GPP_C19 I2C1_SCL 0x04a0: 0x0000005c44000502 GPP_C20 UART2_RXD 0x04a8: 0x0000005d44000600 GPP_C21 UART2_TXD 0x04b0: 0x0000005e44000600 GPP_C22 UART2_RTS# 0x04b8: 0x0000005f44000502 GPP_C23 UART2_CTS# ------- GPIO Group GPP_D ------- 0x04c0: 0x0000006044000600 GPP_D0 n/a 0x04c8: 0x0000006144000600 GPP_D1 n/a 0x04d0: 0x0000006244000500 GPP_D2 n/a 0x04d8: 0x0000006344000600 GPP_D3 n/a 0x04e0: 0x0000306444000402 GPP_D4 ISH_I2C2_SDA 0x04e8: 0x0000006544000600 GPP_D5 I2S_SFRM 0x04f0: 0x0000006644000600 GPP_D6 I2S_TXD 0x04f8: 0x0000006744000500 GPP_D7 I2S_RXD 0x0500: 0x0000006844000602 GPP_D8 I2S_SCLK 0x0508: 0x0000006944000300 GPP_D9 GPIO 0x0510: 0x0000006a44000201 GPP_D10 GPIO 0x0518: 0x0000006b44000300 GPP_D11 GPIO 0x0520: 0x0000006c44000300 GPP_D12 GPIO 0x0528: 0x0200006d44000502 GPP_D13 ISH_UART0_RXD 0x0530: 0x0200006e44000600 GPP_D14 ISH_UART0_TXD 0x0538: 0x0000006f44000600 GPP_D15 ISH_UART0_RTS# 0x0540: 0x0200007044000502 GPP_D16 ISH_UART0_CTS# 0x0548: 0x0000007144000600 GPP_D17 DMIC_CLK1 0x0550: 0x0000107244000400 GPP_D18 DMIC_DATA1 0x0558: 0x0000007344000600 GPP_D19 DMIC_CLK0 0x0560: 0x0000107444000400 GPP_D20 DMIC_DATA0 0x0568: 0x0000007544000400 GPP_D21 n/a 0x0570: 0x0000007644000400 GPP_D22 n/a 0x0578: 0x0000307744000602 GPP_D23 ISH_I2C2_SCL ------- GPIO Group GPP_E ------- 0x0580: 0x0000001844000502 GPP_E0 SATAXPCIE0 0x0588: 0x0000001944000f00 GPP_E1 n/a 0x0590: 0x0000001a44000f00 GPP_E2 n/a 0x0598: 0x0000001b44000500 GPP_E3 CPU_GP0 0x05a0: 0x0000001c04000600 GPP_E4 SATA_DEVSLP0 0x05a8: 0x0000001d44000300 GPP_E5 GPIO 0x05b0: 0x0000001e80880102 GPP_E6 GPIO 0x05b8: 0x0000001f44000300 GPP_E7 GPIO 0x05c0: 0x0000002044000600 GPP_E8 SATA_LED# 0x05c8: 0x0000302144000503 GPP_E9 USB_OC0# 0x05d0: 0x0000302244000503 GPP_E10 USB_OC1# 0x05d8: 0x0000302344000503 GPP_E11 USB_OC2# 0x05e0: 0x0000302444000503 GPP_E12 USB_OC3# ------- GPIO Group GPP_F ------- 0x05e8: 0x0000002544000502 GPP_F0 SATAXPCIE3 0x05f0: 0x0000002644000502 GPP_F1 SATAXPCIE4 0x05f8: 0x0000002744000200 GPP_F2 GPIO 0x0600: 0x0000002844000201 GPP_F3 GPIO 0x0608: 0x0000002944000200 GPP_F4 GPIO 0x0610: 0x0000002a44100102 GPP_F5 GPIO 0x0618: 0x0000002b04000600 GPP_F6 SATA_DEVSLP4 0x0620: 0x0000002c44000200 GPP_F7 GPIO 0x0628: 0x0000002d44000102 GPP_F8 GPIO 0x0630: 0x0000002e84000102 GPP_F9 GPIO 0x0638: 0x0000002f44000300 GPP_F10 GPIO 0x0640: 0x0000003044000102 GPP_F11 GPIO 0x0648: 0x0000003184800100 GPP_F12 GPIO 0x0650: 0x0000003244000102 GPP_F13 GPIO 0x0658: 0x0000003344000102 GPP_F14 GPIO 0x0660: 0x0000303444000502 GPP_F15 USB_OC4# 0x0668: 0x0000303544000502 GPP_F16 USB_OC5# 0x0670: 0x0000003644000201 GPP_F17 GPIO 0x0678: 0x0000003744000201 GPP_F18 GPIO 0x0680: 0x0000003844000600 GPP_F19 eDP_VDDEN 0x0688: 0x0000003944000600 GPP_F20 eDP_BKLTEN 0x0690: 0x0000003a44000600 GPP_F21 eDP_BKLTCTL 0x0698: 0x0000003b84000201 GPP_F22 GPIO 0x06a0: 0x0000003c44000300 GPP_F23 GPIO ------- GPIO Group GPP_G ------- 0x06a8: 0x0000103d44800100 GPP_G0 GPIO 0x06b0: 0x0000003e44000201 GPP_G1 GPIO 0x06b8: 0x0000003f44000702 GPP_G2 FAN_TACH_2 0x06c0: 0x0000004080880100 GPP_G3 GPIO 0x06c8: 0x0000004144000200 GPP_G4 GPIO 0x06d0: 0x0000004244000200 GPP_G5 GPIO 0x06d8: 0x0000004344000201 GPP_G6 GPIO 0x06e0: 0x0000004444000102 GPP_G7 GPIO 0x06e8: 0x0000004544000201 GPP_G8 GPIO 0x06f0: 0x0000004644000201 GPP_G9 GPIO 0x06f8: 0x0000004744000200 GPP_G10 GPIO 0x0700: 0x0000004844000201 GPP_G11 GPIO 0x0708: 0x0000104984800100 GPP_G12 GPIO 0x0710: 0x0000004a44000201 GPP_G13 GPIO 0x0718: 0x0000004b44000300 GPP_G14 GPIO 0x0720: 0x0000004c44000201 GPP_G15 GPIO 0x0728: 0x0000104d84000200 GPP_G16 GPIO 0x0730: 0x0000004e44000201 GPP_G17 GPIO 0x0738: 0x0000004f84800100 GPP_G18 GPIO 0x0740: 0x0000005044000300 GPP_G19 GPIO 0x0748: 0x0000005144000201 GPP_G20 GPIO 0x0750: 0x0000105244000100 GPP_G21 GPIO 0x0758: 0x0000005384000201 GPP_G22 GPIO 0x0760: 0x0000005444000201 GPP_G23 GPIO ------- GPIO Group GPP_H ------- 0x0768: 0x0000005584000702 GPP_H0 SRCCLKREQ6# 0x0770: 0x0000005644000702 GPP_H1 SRCCLKREQ7# 0x0778: 0x0000005784000500 GPP_H2 SRCCLKREQ8# 0x0780: 0x0000005844000700 GPP_H3 SRCCLKREQ9# 0x0788: 0x0000005944000200 GPP_H4 GPIO 0x0790: 0x0000005a84000700 GPP_H5 SRCCLKREQ11# 0x0798: 0x0000005b44000201 GPP_H6 GPIO 0x07a0: 0x0000005c44000201 GPP_H7 GPIO 0x07a8: 0x0000005d44000201 GPP_H8 GPIO 0x07b0: 0x0000005e44000201 GPP_H9 GPIO 0x07b8: 0x0000005f44000201 GPP_H10 GPIO 0x07c0: 0x0000006044000201 GPP_H11 GPIO 0x07c8: 0x0000006144000200 GPP_H12 GPIO 0x07d0: 0x0000006244000102 GPP_H13 GPIO 0x07d8: 0x0000006344000100 GPP_H14 GPIO 0x07e0: 0x0000006444000102 GPP_H15 GPIO 0x07e8: 0x0000006544000201 GPP_H16 GPIO 0x07f0: 0x0000006644000201 GPP_H17 GPIO 0x07f8: 0x0000006744000201 GPP_H18 GPIO 0x0800: 0x0000306844000402 GPP_H19 ISH_I2C0_SDA 0x0808: 0x0000306944000602 GPP_H20 ISH_I2C0_SCL 0x0810: 0x0000306a44000402 GPP_H21 ISH_I2C1_SDA 0x0818: 0x0000306b44000602 GPP_H22 ISH_I2C1_SCL 0x0820: 0x0000006c44000200 GPP_H23 GPIO ------- GPIO Community 2 ------- PCR Port ID: 0xad0000 -------- GPIO Group GPD -------- 0x0400: 0x0000001844000502 GPD0 BATLOW# 0x0408: 0x0000001944000502 GPD1 ACPRESENT 0x0410: 0x00003c1a04000602 GPD2 LAN_WAKE# 0x0418: 0x0000001b44000502 GPD3 PWRBTN# 0x0420: 0x0000001c44000600 GPD4 SLP_S3# 0x0428: 0x0000001d44000600 GPD5 SLP_S4# 0x0430: 0x0000001e44000600 GPD6 SLP_A# 0x0438: 0x0000001f44000201 GPD7 GPIO 0x0440: 0x0000002044000600 GPD8 SUSCLK 0x0448: 0x0000002144000600 GPD9 SLP_WLAN# 0x0450: 0x0000002244000600 GPD10 SLP_S5# 0x0458: 0x0000002344000600 GPD11 LANPHYPC ------- GPIO Community 3 ------- PCR Port ID: 0xac0000 ------- GPIO Group GPP_I ------- 0x0400: 0x0000006d44000500 GPP_I0 DDPB_HPD0 0x0408: 0x0000006e44000500 GPP_I1 DDPC_HPD1 0x0410: 0x0000106f44000500 GPP_I2 DDPD_HPD2 0x0418: 0x0000107044000500 GPP_I3 DDPE_HPD3 0x0420: 0x0000007144000502 GPP_I4 EDP_HPD 0x0428: 0x0000007244000602 GPP_I5 DDPB_CTRLCLK 0x0430: 0x0000007344000402 GPP_I6 DDPB_CTRLDATA 0x0438: 0x0000007444000600 GPP_I7 DDPC_CTRLCLK 0x0440: 0x0000007544000400 GPP_I8 DDPC_CTRLDATA 0x0448: 0x0000007644000600 GPP_I9 DDPD_CTRLCLK 0x0450: 0x0000007744000400 GPP_I10 DDPD_CTRLDATA

1 0

inteltool does not properly dump gpio values for south bridge CM238 chipset
by Justin Dong-Il Lee 22 May '19

22 May '19

As the subject states, whenever I run inteltool -a under root, I do not get any outputs. My dump is listed below. I am running a kaby lake 7820hq for reference. Any help would be appreciated. Is kaby lake not supported for coreboot? Best, ~Justin CPU: ID 0x906e9, Processor Type 0x0, Family 0x6, Model 0x9e, Stepping 0x9 Northbridge: 8086:5910 (unknown) Southbridge: 8086:a154 (CM238) IGD: 8086:591b (Intel(R) UHD Graphics 630) Error: Dumping GPIOs on this southbridge is not (yet) supported. ============= RCBA ============== Error: Dumping RCBA on this southbridge is not (yet) supported. ========== PMBASE/ABASE ========= Error: Dumping PMBASE on this southbridge is not (yet) supported. ============= MCHBAR ============ Error: Dumping MCHBAR on this northbridge is not (yet) supported. ============= EPBAR ============= Error: Dumping EPBAR on this northbridge is not (yet) supported. ============= DMIBAR ============ Error: Dumping DMIBAR on this northbridge is not (yet) supported. ========= PCIEXBAR ======== Error: Dumping PCIEXBAR on this northbridge is not (yet) supported. Error: Dumping MSRs on this CPU (0x0906e0) is not (yet) supported. ============= AMBs ============ Error: Dumping AMBs on this MCH is not (yet) supported. ============= SPI / BIOS CNTL ============= Error: Dumping SPI on this southbridge is not (yet) supported. ============= AHCI Registers ============== ABAR = 0xdf32b000 (MEM)

4 4

Are AMD CPUs as researched as Intel ones (was Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS)
by Nico Huber 22 May '19

22 May '19

Hi Ivan, On 15.05.19 17:11, Ivan Ivanov wrote: > Funny vuln names! Luckily AMD (as usual?) is not affected... As > someone wrote at the forums, a hidden price for Intel higher > performance is a holey pants, just for 120 fps in games instead of 110 > :P Neglecting security for the purpose of performing slightly better > by skipping various checks inside CPU to improve the latencies, - is > both unfair competition and scamming a consumer, since eventually he's > getting significantly less performance than what he paid for I'm curious. Did you do or know somebody who did as much research on AMD processors, as was necessary to find these vulnerabilities? If not, how can you make such comparisons? Nico

4 6

Re: inteltool does not properly dump gpio values for south bridge CM238 chipset
by Justin Dong-Il Lee 22 May '19

22 May '19

Thanks. I've done that and i have gotten a gpio output. Should it look like this? gpiobase+0x0000: 0xffffffff (GPIO_USE_SEL) gpiobase+0x0004: 0xffffffff (GP_IO_SEL) gpiobase+0x0008: 0xffffffff (RESERVED) gpiobase+0x000c: 0xffffffff (GP_LVL) gpiobase+0x0010: 0xffffffff (RESERVED) gpiobase+0x0014: 0xffffffff (RESERVED) gpiobase+0x0018: 0xffffffff (GPO_BLINK) gpiobase+0x001c: 0xffffffff (GP_SER_BLINK) gpiobase+0x0020: 0xffffff03 (GP_SB_CMDSTS) gpiobase+0x0024: 0xffffff03 (GP_SB_DATA) gpiobase+0x0028: 0xff03 (GPI_NMI_EN) gpiobase+0x002a: 0xffff (GPI_NMI_STS) gpiobase+0x002c: 0xffffff03 (GPI_INV) gpiobase+0x0030: 0xffffff03 (GPIO_USE_SEL2) gpiobase+0x0034: 0xffffff03 (GP_IO_SEL2) gpiobase+0x0038: 0xffffff03 (GP_LVL2) gpiobase+0x003c: 0xffffff03 (RESERVED) gpiobase+0x0040: 0xffffffff (GPIO_USE_SEL3) gpiobase+0x0044: 0xffffffff (GP_IO_SEL3) gpiobase+0x0048: 0xffffffff (GPIO_LVL3) gpiobase+0x004c: 0x0130ffff (RESERVED) gpiobase+0x0050: 0xffffffff (RESERVED) gpiobase+0x0054: 0xffffffff (RESERVED) gpiobase+0x0058: 0xffffffff (RESERVED) gpiobase+0x005c: 0xffffffff (RESERVED) gpiobase+0x0060: 0xffffffff (GP_RST_SEL1) gpiobase+0x0064: 0xffffffff (GP_RST_SEL2) gpiobase+0x0068: 0xffffffff (GP_RST_SEL3) gpiobase+0x006c: 0xffffffff (RESERVED) gpiobase+0x0070: 0x00022600 (RESERVED) gpiobase+0x0074: 0x0002260a (RESERVED) gpiobase+0x0078: 0xffffffff (RESERVED) gpiobase+0x007c: 0xffffffff (RESERVED) On Tue, May 21, 2019 at 5:05 PM Justin Dong-Il Lee <justidl3(a)uci.edu> wrote: > Thanks. I've done that and i have gotten a gpio output. Should it look > like this? > gpiobase+0x0000: 0xffffffff (GPIO_USE_SEL) > gpiobase+0x0004: 0xffffffff (GP_IO_SEL) > gpiobase+0x0008: 0xffffffff (RESERVED) > gpiobase+0x000c: 0xffffffff (GP_LVL) > gpiobase+0x0010: 0xffffffff (RESERVED) > gpiobase+0x0014: 0xffffffff (RESERVED) > gpiobase+0x0018: 0xffffffff (GPO_BLINK) > gpiobase+0x001c: 0xffffffff (GP_SER_BLINK) > gpiobase+0x0020: 0xffffff03 (GP_SB_CMDSTS) > gpiobase+0x0024: 0xffffff03 (GP_SB_DATA) > gpiobase+0x0028: 0xff03 (GPI_NMI_EN) > gpiobase+0x002a: 0xffff (GPI_NMI_STS) > gpiobase+0x002c: 0xffffff03 (GPI_INV) > gpiobase+0x0030: 0xffffff03 (GPIO_USE_SEL2) > gpiobase+0x0034: 0xffffff03 (GP_IO_SEL2) > gpiobase+0x0038: 0xffffff03 (GP_LVL2) > gpiobase+0x003c: 0xffffff03 (RESERVED) > gpiobase+0x0040: 0xffffffff (GPIO_USE_SEL3) > gpiobase+0x0044: 0xffffffff (GP_IO_SEL3) > gpiobase+0x0048: 0xffffffff (GPIO_LVL3) > gpiobase+0x004c: 0x0130ffff (RESERVED) > gpiobase+0x0050: 0xffffffff (RESERVED) > gpiobase+0x0054: 0xffffffff (RESERVED) > gpiobase+0x0058: 0xffffffff (RESERVED) > gpiobase+0x005c: 0xffffffff (RESERVED) > gpiobase+0x0060: 0xffffffff (GP_RST_SEL1) > gpiobase+0x0064: 0xffffffff (GP_RST_SEL2) > gpiobase+0x0068: 0xffffffff (GP_RST_SEL3) > gpiobase+0x006c: 0xffffffff (RESERVED) > gpiobase+0x0070: 0x00022600 (RESERVED) > gpiobase+0x0074: 0x0002260a (RESERVED) > gpiobase+0x0078: 0xffffffff (RESERVED) > gpiobase+0x007c: 0xffffffff (RESERVED) > > On Tue, May 21, 2019 at 4:18 PM Matt DeVillier <matt.devillier(a)gmail.com> > wrote: > >> whoops, I meant inteltool, not intelmetool >> >> On Tue, May 21, 2019 at 6:14 PM Matt DeVillier <matt.devillier(a)gmail.com> >> wrote: >> >>> support already exists in intelmetool for several 7th-gen/Kabylake >>> platforms, just not KBL-H. Easiest thing to try would be to add the PCI >>> IDs into inteltool.h next to the existing ones for KBL north/south bridges >>> (ie, add: #define PCI_DEVICE_ID_INTEL_CORE_7TH_GEN_H 0x5910) then add it >>> everywhere the existing ones are referenced (inteltool.c, memory.c, pcie.c) >>> and then recompile. Actual looks like the southbridge already is, so just >>> add the northbridge as per above >>> >>> On Tue, May 21, 2019 at 5:03 PM Justin Dong-Il Lee <justidl3(a)uci.edu> >>> wrote: >>> >>>> As the subject states, whenever I run inteltool -a under root, I do not >>>> get any outputs. My dump is listed below. I am running a kaby lake 7820hq >>>> for reference. Any help would be appreciated. Is kaby lake not supported >>>> for coreboot? >>>> Best, >>>> ~Justin >>>> >>>> CPU: ID 0x906e9, Processor Type 0x0, Family 0x6, Model 0x9e, Stepping >>>> 0x9 >>>> Northbridge: 8086:5910 (unknown) >>>> Southbridge: 8086:a154 (CM238) >>>> IGD: 8086:591b (Intel(R) UHD Graphics 630) >>>> Error: Dumping GPIOs on this southbridge is not (yet) supported. >>>> >>>> >>>> >>>> ============= RCBA ============== >>>> >>>> Error: Dumping RCBA on this southbridge is not (yet) supported. >>>> >>>> >>>> >>>> ========== PMBASE/ABASE ========= >>>> >>>> Error: Dumping PMBASE on this southbridge is not (yet) supported. >>>> >>>> >>>> >>>> ============= MCHBAR ============ >>>> >>>> Error: Dumping MCHBAR on this northbridge is not (yet) supported. >>>> >>>> >>>> >>>> ============= EPBAR ============= >>>> >>>> Error: Dumping EPBAR on this northbridge is not (yet) supported. >>>> >>>> >>>> >>>> ============= DMIBAR ============ >>>> >>>> Error: Dumping DMIBAR on this northbridge is not (yet) supported. >>>> >>>> >>>> ========= PCIEXBAR ======== >>>> >>>> Error: Dumping PCIEXBAR on this northbridge is not (yet) supported. >>>> >>>> >>>> Error: Dumping MSRs on this CPU (0x0906e0) is not (yet) supported. >>>> >>>> >>>> >>>> ============= AMBs ============ >>>> >>>> Error: Dumping AMBs on this MCH is not (yet) supported. >>>> >>>> ============= SPI / BIOS CNTL ============= >>>> >>>> Error: Dumping SPI on this southbridge is not (yet) supported. >>>> >>>> ============= AHCI Registers ============== >>>> >>>> ABAR = 0xdf32b000 (MEM) >>>> >>>> >>>> _______________________________________________ >>>> coreboot mailing list -- coreboot(a)coreboot.org >>>> To unsubscribe send an email to coreboot-leave(a)coreboot.org >>>> >>>

1 0

redleaf
by ron minnich 20 May '19

20 May '19

"RedLeaf is a new operating system being developed from scratch to utilize formal verification for implementing provably secure firmware. RedLeaf is developed in a safe language, Rust, and relies on automated reasoning using satisfiability modulo theories (SMT) solvers for formal verification. RedLeaf builds on two premises: (1) Rust's linear type system enables practical language safety even for systems with tightest performance and resource budgets (e.g., firmware), and (2) a combination of SMT-based reasoning and pointer discipline enforced by linear types provides a unique way to automate and simplify verification effort scaling it to the size of a small OS kernel." https://dl.acm.org/citation.cfm?id=3321449

3 3

Votes on copyright lines, line lengths and automatic formatting
by Patrick Georgi 20 May '19

20 May '19

Hi everybody, The project leadership asked me to get the developer community's opinion on a couple of coding style related issues that were under discussion for a long time without clear resolution. To that end I just setup three elections on https://civs.cs.cornell.edu. They're ranked votes using the Condorcet method with a single winner per question. Voting ends on end of May 21 AoE (https://en.wikipedia.org/wiki/Anywhere_on_Earth). The voting population was determined by Martin and covers everybody who made 10 contributions (changes, review flags) on review.coreboot.org over the last 2 years. These eligible developers should have received an email from me last week to introduce the process and three emails today with their personalized link to the elections, one for each question. If you think you're eligible but didn't get these emails, please reach out to me directly. For reference (but there won't be a vote here on this list!), the questions posed are: # How to handle copyright notices The coreboot project has had issues with copyright notices for a long time, and we’d like to start to address it. We currently don’t have any guide on when it’s ok to add a copyright, and when it isn’t. This and other issues like refactoring patches in gerrit lead to things like: * Copyright on blank files * Adding a copyright line when deleting code * Adding a copyright line for trivial changes such as spelling fixes The copyright laws around the world differ, but it seems like most of them agree that copyright is specifically for acts of creativity. None of the above examples are creative, so that would exclude them from copyright protection. Another issue is that we’d rather not have an ever-growing list of copyright notices at the top of each file. This has been addressed in other projects by having an AUTHORS file, and it’s been suggested that coreboot should follow this. The AUTHORS file would contain the list of copyright holders, based on the existing copyright lines. # This is the list of coreboot authors for copyright purposes. # # This does not necessarily list everyone who has contributed code, since in # some cases, their employer may be the copyright holder. To see the full list # of contributors, see the revision history in source control. Ronald G. Minnich <rminnich(a)gmail.com> Kyösti Mälkki <kyosti.malkki(a)gmail.com> SUSE LINUX AG coresystems GmbH All existing copyright notices would be replaced with text “Copyright 2019 The coreboot project Authors.” Arguments for replacing existing copyright lines with the AUTHORS file: * This resolves many of the current issues with copyright notices. * Without copyright notices in each individual file, once a name is in the AUTHORS file, the copyright holder doesn’t have to update it again. * The headers won’t grow because there’s just one static line. * Copyright dates won’t have to be updated in multiple files anymore Arguments for leaving the copyright lines: * A single AUTHORS file doesn’t capture the amount of work that people have put into the codebase. The copyright line allows people to see their contributions to coreboot. Please rank these choices: * Create an authors file and remove all existing copyright lines * Create an authors file but leave existing copyright lines * Don’t create an authors file or change existing copyright lines # Line length There have been arguments recently that the line length is a bit too restrictive and we should change the coding style to allow for longer lines. We currently have line length exceptions for comments and print format strings. Arguments for longer line lengths: * We have large monitors and can easily see more than 80 characters now. * It’s better to just make the code look good than to worry about breaking the line up because it’s 81 characters long. * With long Kconfig symbol names and longer, more descriptive variable names, lines have gotten longer without changing any code complexity. Arguments for keeping 80 characters: * If the code needs to go past 80 characters, the function is probably too complex. * The linux kernel has an 80 character limit, and we should maintain that. * With the existing line length exceptions, there shouldn’t be a problem. * People already have their editors set up for 80 characters and it would be a pain to change them just for coreboot’s new settings. Argument for 96 characters: * This is intended to be a compromise between 80 characters and even longer line lengths. The idea here is that it’s 2 tabstops + 80 text characters. Argument for no strict line length: * Nobody is actually advocating for super long lines - it’s just about making the code look good without actually having to worry about the line length. * We can trust coreboot developers to be reasonable and we can catch people doing stupid things in the code reviews when they’re not. Rank these options: * 80 character lines * 88 character lines * 96 character lines * 120 character lines * 132 character lines * No strict length limit # Automatic code formatting As people have worked in other languages like Go which has strictly enforced automatic formatting, it has gained advocates. We’re trying to decide whether to require that code be formatted by clang-format before submitting to gerrit or to update the formatting automatically every once in a while. Arguments for automatic formatting * Currently most comments in gerrit are about style, not substance. If the code is automatically formatted, we can focus on the contents of the code, not the style of the code. * If manual formatting is important in a location, the section can be excluded from clang-format, so this gives us more options. Arguments against automatic formatting * Different versions of clang-format produce different output - it’s not the same every time. * Code will sometimes end up being less readable after running through clang-format. * clang-format isn’t smart enough Rank these options: * Submitters should run clang-format before submitting a patch and it should be rejected in gerrit if it’s not formatted properly with an error telling them how to format it. * Code should just get automatically reformatted on a regular basis. * coreboot should stick with manual formatting. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

3 5

reminder on upcoming deadlines: voting and release engineering
by Patrick Georgi 20 May '19

20 May '19

Hi everybody, as a reminder: The voting period for various coding style issues (where to put copyright information, line lengths, automated code formatting) ends in a bit more than 26 hours. So far the system has registered 53 to 60 votes (numbers vary per question) which, at ~120 eligible voters, is a turnout of about 50%. I also want to remind you of the plan to release coreboot 4.10 Tuesday next week (May 28). The release checklist can be found at https://piratenpad.de/p/coreboot4.10-release-checklist If you have stuff that needs to get in before then, do it ASAP so things can stabilize. If you have risky patch sets consider waiting until after the release. Test on your hardware with master, report/fix issues and report successes to board-status. Thanks, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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 2019