coreboot December 2018

coreboot@coreboot.org

52 participants
62 discussions

T430s cannot compile coreboot.rom, it was fine a month ago
by Kyle K 20 Dec '18

20 Dec '18

Hello, I cannot compile git coreboot anymore for T430s, my last successful compile is from Nov 12, that is the last time that I flashed my laptop with fresh git coreboot. Since then I have not changed anything on my end except usual 'git pull; git submodule update --init --checkout; make nconfig (I would simply save to update my .config file); make' This is the error I'm getting (it is actually after running 'make' for 2nd time since it prints less info) [kyle@ROG ~/coreboot (master)]$ make Skipping submodule '3rdparty/blobs' Skipping submodule '3rdparty/fsp' GEN generated/bootblock.ld CP bootblock/arch/x86/bootblock.ld LINK cbfs/fallback/bootblock.debug OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin CREATE build/mainboard/lenovo/t430s/cbfs-file.CkOxZB.out (from /home/kyle/coreboot/.config) make: *** No rule to make target 'src/mainboard/lenovo/t430s/data.vbt', needed by 'build/coreboot.pre'. Stop. [kyle@ROG ~/coreboot (master)]$ find src/mainboard/lenovo/t430s -name data.vbt src/mainboard/lenovo/t430s/variants/t430s/data.vbt src/mainboard/lenovo/t430s/variants/t431s/data.vbt Is the data.vbt in wrong place by any chance? I was looking at output of 'git log src/mainboard/lenovo/t430s' and noticed that on Nov 29 support for T431s was added. Maybe this has to do something with it? Thank you.

1 1

coreboot for Advantech SOM-4461
by junaid saleem 19 Dec '18

19 Dec '18

Hello , I have been trying to port coreboot on advantech SOM 4461, with the following specifications. Processor: Intel ® Atom N270 Chipset : Intel 945GSE/ ICH7M Memory: DDR2 (2GB) i was not able to find the board in the list of supported hardware as given in link https://www.coreboot.org/Category:Tutorials. Can anybody suggest which board should i select in make menuconfig ? Thanks. Regards, --Jun

2 3

Maintainer for FSP broadwell DE
by Patrick Rudolph 18 Dec '18

18 Dec '18

Hi folks, it looks like York Yang doesn't work at Intel any more and thus isn't maintaining the FSP broadwell DE platform. Is there somebody at Intel who can take care of that platform and review and test patches ? Regards, -- Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudolph(a)9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207 Geschäftsführung: Eray Basar, Sebastian Deutsch

3 4

Re: [coreboot] coreboot on ASRock H81M-HDS cannot load a payload
by Tristan Corrick 17 Dec '18

17 Dec '18

Hi Iru, It looks like the PCI ID of the Xeon E3 DRAM controller is missing. Try adding `0c08` to `mc_pci_device_ids` in src/northbridge/intel/haswell/ northbridge.c and see if that works. Kind regards, Tristan On Mon, Dec 17, 2018 at 12:14:29PM +0800, Iru Cai wrote: > Hi, > > I'm trying to run coreboot on ASRock H81M-HDS with a Xeon E3 and 8G*2 RAM. > I chose to use my GRUB payload, but coreboot cannot load it with the > following error (full log in attachment): > > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'fallback/payload' > CBFS: Found @ offset 2fb80 size 1929bd > Checking segment from ROM address 0xffdcfbb8 > Payload being loaded at below 1MiB without region being marked as RAM > usable. > Checking segment from ROM address 0xffdcfbd4 > SELF segment doesn't target RAM: 0x00100000, 5203948 bytes > 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES > 1. 000000007f751000-000000007f78efff: CONFIGURATION TABLES > 2. 000000007f78f000-000000007f7ccfff: RAMSTAGE > 3. 000000007f7cd000-000000007f7fffff: CONFIGURATION TABLES > Payload not loaded. > > If I use SeaBIOS as payload, SeaBIOS can run, but it can't allocate > resources for SATA, EHCI and XHCI and can't find any boot devices. > > What is the problem in it? > > Iru > > -- > My website: https://vimacs.lcpu.club > > Please do not send me Microsoft Office/Apple iWork documents. Send > OpenDocument instead! http://fsf.org/campaigns/opendocument/ > coreboot-4.8-2526-gad8478f643-dirty Sun Dec 16 16:50:38 UTC 2018 romstage starting... > Disabling Watchdog reboot... done. > SMBus controller enabled. > Setting up static northbridge registers... done. > Initializing Graphics... > Back from haswell_early_initialization() > CPU id(306c3) ucode:00000024 Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz > AES supported, TXT supported, VT supported > PCH type: H81, device id: 8c5c, rev id 5 > Starting UEFI PEI System Agent > FMAP: Found "FLASH" version 1.1 at 180000. > FMAP: base = ffc00000 size = 400000 #areas = 4 > FMAP: area RW_MRC_CACHE found @ 190000 (65536 bytes) > MRC: no data in 'RW_MRC_CACHE' > FMAP: area COREBOOT found @ 1a0000 (2490368 bytes) > CBFS: Locating 'mrc.bin' > CBFS: Found @ offset 1fffc0 size 2e6e4 > System Agent: Starting up... > System Agent: Initializing PCH > install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845} > install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276} > System Agent: Initializing PCH (SMBUS) > System Agent: Initializing PCH (USB) > System Agent: Initializing PCH (SA Init) > System Agent: Initializing PCH (Me UMA) > System Agent: Initializing Memory > System Agent: Done. > Sanity checking heap. > System Agent Version 1.6.1 Build 2 > memcfg DDR3 clock 1600 MHz > memcfg channel assignment: A: 0, B 1, C 2 > memcfg channel[0] config (00620020): > ECC inactive > enhanced interleave mode on > rank interleave on > DIMMA 8192 MB width x8 or x32 dual rank, selected > DIMMB 0 MB width x8 or x32 single rank > memcfg channel[1] config (00620020): > ECC inactive > enhanced interleave mode on > rank interleave on > DIMMA 8192 MB width x8 or x32 dual rank, selected > DIMMB 0 MB width x8 or x32 single rank > ME: FW Partition Table : OK > ME: Bringup Loader Failure : NO > ME: Firmware Init Complete : NO > ME: Manufacturing Mode : NO > ME: Boot Options Present : NO > ME: Update In Progress : NO > ME: Current Working State : Normal > ME: Current Operation State : M0 with UMA > ME: Current Operation Mode : Normal > ME: Error Code : No Error > ME: Progress Phase : uKernel Phase > ME: Power Management Event : Clean Moff->Mx wake > ME: Progress Phase State : Unknown phase: 0x02 sate: 0x00 > CBMEM: > IMD: root @ 7f7ff000 254 entries. > IMD: root @ 7f7fec00 62 entries. > External stage cache: > IMD: root @ 7fbff000 254 entries. > IMD: root @ 7fbfec00 62 entries. > MTRR Range: Start=ffc00000 End=0 (Size 400000) > MTRR Range: Start=0 End=1000000 (Size 1000000) > MTRR Range: Start=7f000000 End=80000000 (Size 1000000) > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'fallback/postcar' > CBFS: Found @ offset 28900 size 4364 > Decompressing stage fallback/postcar @ 0x7f7cdfc0 (33808 bytes) > Loading module at 7f7ce000 with entry 7f7ce000. filesize: 0x4110 memsize: 0x83d0 > Processing 126 relocs. Offset value of 0x7d7ce000 > > > coreboot-4.8-2526-gad8478f643-dirty Sun Dec 16 16:50:38 UTC 2018 postcar starting... > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'fallback/ramstage' > CBFS: Found @ offset 14100 size 13e4a > Decompressing stage fallback/ramstage @ 0x7f78efc0 (252344 bytes) > Loading module at 7f78f000 with entry 7f78f000. filesize: 0x29d70 memsize: 0x3d978 > Processing 2823 relocs. Offset value of 0x7e98f000 > > > coreboot-4.8-2526-gad8478f643-dirty Sun Dec 16 16:50:38 UTC 2018 ramstage starting... > Normal boot. > BS: BS_PRE_DEVICE times (us): entry 0 run 0 exit 0 > BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 1 exit 0 > Enumerating buses... > CPU_CLUSTER: 0 enabled > DOMAIN: 0000 enabled > PCI: pci_scan_bus for bus 00 > PCI: 00:00.0 [8086/0c08] enabled > PCI: Static device PCI: 00:01.0 not found, disabling it. > PCI: Static device PCI: 00:02.0 not found, disabling it. > PCI: Static device PCI: 00:03.0 not found, disabling it. > PCI: 00:14.0 [8086/8c31] enabled > PCI: 00:16.0 [8086/8c3a] enabled > PCI: 00:16.1: Disabling device > PCI: 00:16.2: Disabling device > PCI: 00:16.3: Disabling device > PCI: 00:19.0: Disabling device > PCI: 00:1a.0 [8086/8c2d] enabled > PCI: 00:1b.0 [8086/8c20] enabled > PCIe Root Port 1 ASPM is disabled > PCI: 00:1c.0 [8086/8c10] enabled > PCI: 00:1c.1 [8086/8c12] disabled > PCI: 00:1c.2 [8086/8c14] disabled > PCIe Root Port 4 ASPM is disabled > PCI: 00:1c.3 [8086/8c16] enabled > PCIe Root Port 5 ASPM is disabled > PCI: 00:1c.4 [8086/8c18] enabled > PCIe Root Port 6 ASPM is disabled > PCI: 00:1c.5 [8086/8c1a] enabled > PCI: 00:1d.0 [8086/8c26] enabled > PCI: 00:1f.0 [8086/8c5c] enabled > PCI: 00:1f.2 [8086/8c02] enabled > PCI: 00:1f.3 [8086/8c22] enabled > PCI: 00:1f.5: Disabling device > PCI: 00:1f.6: Disabling device > PCI: pci_scan_bus for bus 01 > scan_bus: scanning of bus PCI: 00:1c.0 took 2646 usecs > PCI: pci_scan_bus for bus 02 > PCI: 02:00.0 [10ec/8168] enabled > Enabling Common Clock Configuration > ASPM: Enabled L1 > scan_bus: scanning of bus PCI: 00:1c.3 took 10596 usecs > PCI: pci_scan_bus for bus 03 > PCI: 03:00.0 [1b21/1142] enabled > Enabling Common Clock Configuration > ASPM: Enabled None > Failed to enable LTR for dev = PCI: 03:00.0 > scan_bus: scanning of bus PCI: 00:1c.4 took 14643 usecs > PCI: pci_scan_bus for bus 04 > PCI: 04:00.0 [168c/0030] enabled > Enabling Common Clock Configuration > ASPM: Enabled None > Failed to enable LTR for dev = PCI: 04:00.0 > scan_bus: scanning of bus PCI: 00:1c.5 took 14625 usecs > PNP: 002e.0 disabled > PNP: 002e.1 enabled > PNP: 002e.2 enabled > PNP: 002e.3 enabled > PNP: 002e.5 enabled > PNP: 002e.6 disabled > PNP: 002e.7 disabled > PNP: 002e.107 disabled > PNP: 002e.8 disabled > PNP: 002e.108 disabled > PNP: 002e.208 disabled > PNP: 002e.308 disabled > PNP: 002e.109 disabled > PNP: 002e.209 disabled > PNP: 002e.309 disabled > PNP: 002e.409 disabled > PNP: 002e.509 disabled > PNP: 002e.609 disabled > PNP: 002e.709 disabled > PNP: 002e.a disabled > PNP: 002e.b enabled > PNP: 002e.d disabled > PNP: 002e.e disabled > PNP: 002e.f disabled > PNP: 002e.14 disabled > PNP: 002e.16 disabled > PNP: 002e.17 disabled > scan_bus: scanning of bus PCI: 00:1f.0 took 54169 usecs > scan_bus: scanning of bus PCI: 00:1f.3 took 2 usecs > scan_bus: scanning of bus DOMAIN: 0000 took 217465 usecs > scan_bus: scanning of bus Root Device took 226566 usecs > done > FMAP: area RW_MRC_CACHE found @ 190000 (65536 bytes) > MRC: Checking cached data update for 'RW_MRC_CACHE'. > Manufacturer: ef > SF: Detected W25Q32 with sector size 0x1000, total 0x400000 > MRC: no data in 'RW_MRC_CACHE' > MRC: cache data 'RW_MRC_CACHE' needs update. > BS: BS_DEV_ENUMERATE times (us): entry 0 run 234019 exit 36682 > Allocating resources... > Reading resources... > Done reading resources. > skipping PNP: 002e.1@f0 fixed resource, size=0! > Setting resources... > PCI: 00:14.0 10 <- [0x00feb00000 - 0x00feb0ffff] size 0x00010000 gran 0x10 mem64 > PCI: 00:16.0 10 <- [0x00feb18000 - 0x00feb1800f] size 0x00000010 gran 0x04 mem64 > PCI: 00:1a.0 10 <- [0x00feb15000 - 0x00feb153ff] size 0x00000400 gran 0x0a mem > PCI: 00:1b.0 10 <- [0x00feb10000 - 0x00feb13fff] size 0x00004000 gran 0x0e mem64 > PCI: 00:1c.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 01 io > PCI: 00:1c.0 24 <- [0x00febfffff - 0x00febffffe] size 0x00000000 gran 0x14 bus 01 prefmem > PCI: 00:1c.0 20 <- [0x00febfffff - 0x00febffffe] size 0x00000000 gran 0x14 bus 01 mem > PCI: 00:1c.3 1c <- [0x0000001000 - 0x0000001fff] size 0x00001000 gran 0x0c bus 02 io > PCI: 00:1c.3 24 <- [0x00fe700000 - 0x00fe7fffff] size 0x00100000 gran 0x14 bus 02 prefmem > PCI: 00:1c.3 20 <- [0x00fe800000 - 0x00fe8fffff] size 0x00100000 gran 0x14 bus 02 mem > PCI: 02:00.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io > PCI: 02:00.0 18 <- [0x00fe800000 - 0x00fe800fff] size 0x00001000 gran 0x0c mem64 > PCI: 02:00.0 20 <- [0x00fe700000 - 0x00fe703fff] size 0x00004000 gran 0x0e prefmem64 > PCI: 00:1c.4 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 03 io > PCI: 00:1c.4 24 <- [0x00febfffff - 0x00febffffe] size 0x00000000 gran 0x14 bus 03 prefmem > PCI: 00:1c.4 20 <- [0x00fe900000 - 0x00fe9fffff] size 0x00100000 gran 0x14 bus 03 mem > PCI: 03:00.0 10 <- [0x00fe900000 - 0x00fe907fff] size 0x00008000 gran 0x0f mem64 > PCI: 00:1c.5 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 04 io > PCI: 00:1c.5 24 <- [0x00febfffff - 0x00febffffe] size 0x00000000 gran 0x14 bus 04 prefmem > PCI: 00:1c.5 20 <- [0x00fea00000 - 0x00feafffff] size 0x00100000 gran 0x14 bus 04 mem > PCI: 04:00.0 10 <- [0x00fea00000 - 0x00fea1ffff] size 0x00020000 gran 0x11 mem64 > PCI: 04:00.0 30 <- [0x00fea20000 - 0x00fea2ffff] size 0x00010000 gran 0x10 romem > PCI: 00:1d.0 10 <- [0x00feb16000 - 0x00feb163ff] size 0x00000400 gran 0x0a mem > PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] size 0x00000008 gran 0x03 io > PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] size 0x00000001 gran 0x00 irq > PNP: 002e.1 74 <- [0x0000000004 - 0x0000000004] size 0x00000001 gran 0x00 drq > PNP: 002e.1 f0 <- [0x000000003c - 0x000000003b] size 0x00000000 gran 0x00 irq > PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] size 0x00000008 gran 0x03 io > PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] size 0x00000001 gran 0x00 irq > PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] size 0x00000008 gran 0x03 io > PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] size 0x00000001 gran 0x00 irq > PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] size 0x00000001 gran 0x00 io > PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] size 0x00000001 gran 0x00 io > PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] size 0x00000001 gran 0x00 irq > PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] size 0x00000001 gran 0x00 irq > PNP: 002e.b 60 <- [0x0000000290 - 0x0000000291] size 0x00000002 gran 0x01 io > PNP: 002e.b 62 <- [0x0000000000 - 0x0000000001] size 0x00000002 gran 0x01 io > PNP: 002e.b 70 <- [0x0000000000 - 0x0000000000] size 0x00000001 gran 0x00 irq > PCI: 00:1f.2 10 <- [0x0000002020 - 0x0000002027] size 0x00000008 gran 0x03 io > PCI: 00:1f.2 14 <- [0x0000002030 - 0x0000002033] size 0x00000004 gran 0x02 io > PCI: 00:1f.2 18 <- [0x0000002028 - 0x000000202f] size 0x00000008 gran 0x03 io > PCI: 00:1f.2 1c <- [0x0000002034 - 0x0000002037] size 0x00000004 gran 0x02 io > PCI: 00:1f.2 20 <- [0x0000002000 - 0x000000201f] size 0x00000020 gran 0x05 io > PCI: 00:1f.2 24 <- [0x00feb14000 - 0x00feb147ff] size 0x00000800 gran 0x0b mem > PCI: 00:1f.3 10 <- [0x00feb17000 - 0x00feb170ff] size 0x00000100 gran 0x08 mem64 > Done setting resources. > Done allocating resources. > BS: BS_DEV_RESOURCES times (us): entry 0 run 338864 exit 0 > Enabling resources... > PCI: 00:00.0 subsystem <- 1849/0c00 > PCI: 00:00.0 cmd <- 06 > PCI: 00:14.0 subsystem <- 1849/8c31 > PCI: 00:14.0 cmd <- 102 > PCI: 00:16.0 subsystem <- 1849/8c3a > PCI: 00:16.0 cmd <- 02 > PCI: 00:1a.0 subsystem <- 1849/8c2d > PCI: 00:1a.0 cmd <- 102 > PCI: 00:1b.0 subsystem <- 1849/7662 > PCI: 00:1b.0 cmd <- 102 > PCI: 00:1c.0 bridge ctrl <- 0003 > PCI: 00:1c.0 subsystem <- 1849/8c10 > PCI: 00:1c.0 cmd <- 00 > PCI: 00:1c.3 bridge ctrl <- 0003 > PCI: 00:1c.3 subsystem <- 1849/8c16 > PCI: 00:1c.3 cmd <- 07 > PCI: 00:1c.4 bridge ctrl <- 0003 > PCI: 00:1c.4 subsystem <- 1849/8c18 > PCI: 00:1c.4 cmd <- 06 > PCI: 00:1c.5 bridge ctrl <- 0003 > PCI: 00:1c.5 subsystem <- 1849/8c1a > PCI: 00:1c.5 cmd <- 06 > PCI: 00:1d.0 subsystem <- 1849/8c26 > PCI: 00:1d.0 cmd <- 102 > PCI: 00:1f.0 subsystem <- 1849/8c5c > PCI: 00:1f.0 cmd <- 107 > PCI: 00:1f.2 subsystem <- 1849/8c02 > PCI: 00:1f.2 cmd <- 103 > PCI: 00:1f.3 subsystem <- 1849/8c22 > PCI: 00:1f.3 cmd <- 103 > PCI: 02:00.0 cmd <- 03 > PCI: 03:00.0 subsystem <- 1849/1042 > PCI: 03:00.0 cmd <- 102 > PCI: 04:00.0 cmd <- 02 > done. > BS: BS_DEV_ENABLE times (us): entry 0 run 93919 exit 0 > Initializing devices... > Root Device init ... > Root Device init finished in 1974 usecs > CPU_CLUSTER: 0 init ... > MTRR: Physical address space: > 0x00000000fe700000 - 0x0000000100000000 size 0x01900000 type 0 > MTRR: Fixed MSR 0x250 0x0000000000000000 > MTRR: Fixed MSR 0x258 0x0000000000000000 > MTRR: Fixed MSR 0x259 0x0000000000000000 > MTRR: Fixed MSR 0x268 0x0000000000000000 > MTRR: Fixed MSR 0x269 0x0000000000000000 > MTRR: Fixed MSR 0x26a 0x0000000000000000 > MTRR: Fixed MSR 0x26b 0x0000000000000000 > MTRR: Fixed MSR 0x26c 0x0000000000000000 > MTRR: Fixed MSR 0x26d 0x0000000000000000 > MTRR: Fixed MSR 0x26e 0x0000000000000000 > MTRR: Fixed MSR 0x26f 0x0000000000000000 > CPU physical address size: 39 bits > MTRR: default type WB/UC MTRR counts: 3/0. > MTRR: UC selected as default type. > > MTRR check > Fixed MTRRs : Enabled > Variable MTRRs: Enabled > > Initializing VR config. > CPU has 4 cores, 8 threads enabled. > Setting up SMI for CPU > Will perform SMM setup. > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'cpu_microcode_blob.bin' > CBFS: Found @ offset 9080 size b000 > microcode: sig=0x306c3 pf=0x2 revision=0x24 > CPU: Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz. > Loading module at 00030000 with entry 00030000. filesize: 0x170 memsize: 0x170 > Processing 16 relocs. Offset value of 0x00030000 > Attempting to start 7 APs > Waiting for 10ms after sending INIT. > Waiting for 1st SIPI to complete...AP: slot 2 apic_id 1. > AP: slot 6 apic_id 7. > AP: slot 1 apic_id 2. > AP: slot 3 apic_id 3. > AP: slot 5 apic_id 5. > AP: slot 7 apic_id 6. > done. > AP: slot 4 apic_id 4. > Waiting for 2nd SIPI to complete...done. > Loading module at 00038000 with entry 00038000. filesize: 0x1a8 memsize: 0x1a8 > Processing 13 relocs. Offset value of 0x00038000 > SMM Module: stub loaded at 00038000. Will call 7f7a4b5d(00000000) > Installing SMM handler to 0x7f800000 > Loading module at 7f810000 with entry 7f810419. filesize: 0x1950 memsize: 0x5978 > Processing 58 relocs. Offset value of 0x7f810000 > Loading module at 7f808000 with entry 7f808000. filesize: 0x1a8 memsize: 0x1a8 > Processing 13 relocs. Offset value of 0x7f808000 > SMM Module: placing jmp sequence at 7f807c00 rel16 0x03fd > SMM Module: placing jmp sequence at 7f807800 rel16 0x07fd > SMM Module: placing jmp sequence at 7f807400 rel16 0x0bfd > SMM Module: placing jmp sequence at 7f807000 rel16 0x0ffd > SMM Module: placing jmp sequence at 7f806c00 rel16 0x13fd > SMM Module: placing jmp sequence at 7f806800 rel16 0x17fd > SMM Module: placing jmp sequence at 7f806400 rel16 0x1bfd > SMM Module: stub loaded at 7f808000. Will call 7f810419(00000000) > Initializing Southbridge SMI... > SMI_STS: PM1 > TMROF New SMBASE 0x7f800000 > In relocation handler: cpu 0 > New SMBASE=0x7f800000 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > New SMBASE 0x7f7ff800 > In relocation handler: cpu 2 > New SMBASE=0x7f7ff800 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > New SMBASE 0x7f7fe800 > In relocation handler: cpu 6 > New SMBASE=0x7f7fe800 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > New SMBASE 0x7f7fec00 > In relocation handler: cpu 5 > New SMBASE=0x7f7fec00 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > New SMBASE 0x7f7ff000 > In relocation handler: cpu 4 > New SMBASE=0x7f7ff000 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > New SMBASE 0x7f7fe400 > In relocation handler: cpu 7 > New SMBASE=0x7f7fe400 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > New SMBASE 0x7f7ff400 > In relocation handler: cpu 3 > New SMBASE=0x7f7ff400 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > New SMBASE 0x7f7ffc00 > In relocation handler: cpu 1 > New SMBASE=0x7f7ffc00 IEDBASE=0x7fc00000 > Writing SMRR. base = 0x7f800006, mask=0xff800800 > Relocation complete. > Initializing CPU #0 > CPU: vendor Intel device 306c3 > CPU: family 06, model 3c, stepping 03 > Setting up local APIC... apic_id: 0x00 done. > VMX status: enabled, locked > haswell: energy policy set to 6 > haswell: frequency set to 3600 > Turbo is available but hidden > Turbo has been enabled > CPU #0 initialized > Initializing CPU #2 > Initializing CPU #1 > CPU: vendor Intel device 306c3 > Initializing CPU #4 > CPU: family 06, model 3c, stepping 03 > CPU: vendor Intel device 306c3 > CPU: vendor Intel device 306c3 > Setting up local APIC...CPU: family 06, model 3c, stepping 03 > apic_id: 0x01 Initializing CPU #3 > done. > Setting up local APIC...Initializing CPU #5 > VMX status: enabled, locked > Initializing CPU #6 > haswell: energy policy set to 6 > Initializing CPU #7 > CPU: vendor Intel device 306c3 > haswell: frequency set to 3600 > CPU: family 06, model 3c, stepping 03 > CPU #2 initialized > apic_id: 0x02 CPU: family 06, model 3c, stepping 03 > Setting up local APIC...Setting up local APIC...CPU: vendor Intel device 306c3 > CPU: vendor Intel device 306c3 > done. > CPU: vendor Intel device 306c3 > apic_id: 0x04 apic_id: 0x05 CPU: family 06, model 3c, stepping 03 > CPU: family 06, model 3c, stepping 03 > CPU: family 06, model 3c, stepping 03 > Setting up local APIC...Setting up local APIC...Setting up local APIC...done. > apic_id: 0x03 VMX status: enabled, locked > VMX status: enabled, locked > done. > haswell: energy policy set to 6 > done. > haswell: energy policy set to 6 > VMX status: enabled, locked > haswell: frequency set to 3600 > haswell: frequency set to 3600 > VMX status: enabled, locked > CPU #5 initialized > apic_id: 0x07 apic_id: 0x06 CPU #1 initialized > done. > haswell: energy policy set to 6 > VMX status: enabled, locked > done. > haswell: energy policy set to 6 > haswell: frequency set to 3600 > haswell: frequency set to 3600 > CPU #4 initialized > VMX status: enabled, locked > CPU #6 initialized > haswell: energy policy set to 6 > haswell: energy policy set to 6 > haswell: frequency set to 3600 > haswell: frequency set to 3600 > CPU #7 initialized > CPU #3 initialized > bsp_do_flight_plan done after 484 msecs. > Enabling SMIs. > Locking SMM. > CPU_CLUSTER: 0 init finished in 661544 usecs > PCI: 00:00.0 init ... > PCI: 00:00.0 init finished in 2736 usecs > PCI: 00:14.0 init ... > IOBP: set 0xe5004001 to 0x000000ce > PCI: 00:14.0 init finished in 7516 usecs > PCI: 00:16.0 init ... > ME: FW Partition Table : OK > ME: Bringup Loader Failure : NO > ME: Firmware Init Complete : YES > ME: Manufacturing Mode : NO > ME: Boot Options Present : NO > ME: Update In Progress : NO > ME: Current Working State : Normal > ME: Current Operation State : M0 with UMA > ME: Current Operation Mode : Normal > ME: Error Code : No Error > ME: Progress Phase : Host Communication > ME: Power Management Event : Clean Moff->Mx wake > ME: Progress Phase State : Host communication established > ME: BIOS path: Normal > ME: Extend SHA-256: 53d07b5984ce080dbe27b6128243f8752927e05c4627b43d79c11693df819db5 > ME MBP: Header: items: 8, size dw: 35 > ME: found version 9.0.30.1482 > ME: Wake Event to ME Reset: 0 ms > ME: ME Reset to Platform Reset: 0 ms > ME: Platform Reset to CPU Reset: 40 ms > PCI: 00:16.0 init finished in 86133 usecs > PCI: 00:1a.0 init ... > EHCI: Setting up controller.. IOBP: set 0xe5004001 to 0x000000ce > done. > PCI: 00:1a.0 init finished in 10345 usecs > PCI: 00:1b.0 init ... > Azalia: base = feb10000 > Azalia: codec_mask = 01 > HDA: Initializing codec #0 > HDA: codec viddid: 10ec0662 > HDA: verb not loaded > PCI: 00:1b.0 init finished in 18831 usecs > PCI: 00:1c.0 init ... > Initializing PCH PCIe bridge. > PCI: 00:1c.0 init finished in 6204 usecs > PCI: 00:1c.3 init ... > Initializing PCH PCIe bridge. > PCI: 00:1c.3 init finished in 6213 usecs > PCI: 00:1c.4 init ... > Initializing PCH PCIe bridge. > PCI: 00:1c.4 init finished in 6272 usecs > PCI: 00:1c.5 init ... > Initializing PCH PCIe bridge. > PCI: 00:1c.5 init finished in 6300 usecs > PCI: 00:1d.0 init ... > EHCI: Setting up controller.. IOBP: set 0xe5004001 to 0x000000ce > done. > PCI: 00:1d.0 init finished in 10377 usecs > PCI: 00:1f.0 init ... > pch: lpc_init > IOAPIC: Initializing IOAPIC at 0xfec00000 > IOAPIC: Bootstrap Processor Local APIC = 0x00 > IOAPIC: ID = 0x02 > FMAP: area COREBOOT found @ 1a0000 (2490368 bytes) > CBFS: Locating 'cmos_layout.bin' > CBFS: Found @ offset 28600 size 29c > Set power state keep after power failure. > FMAP: area COREBOOT found @ 1a0000 (2490368 bytes) > CBFS: Locating 'cmos_layout.bin' > CBFS: Found @ offset 28600 size 29c > NMI sources enabled. > LynxPoint PM init > RTC: failed = 0x0 > RTC Init > Disabling ACPI via APMC: > done. > PCI: 00:1f.0 init finished in 64310 usecs > PCI: 00:1f.2 init ... > SATA: Initializing... > SATA: Controller in AHCI mode. > ABAR: feb14000 > PCI: 00:1f.2 init finished in 11793 usecs > PCI: 00:1f.3 init ... > PCI: 00:1f.3 init finished in 2930 usecs > PCI: 02:00.0 init ... > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'rt8168-macaddress' > CBFS: Found @ offset 28440 size 11 > r8168: Resetting NIC...done > r8168: Programming MAC Address...done > r8168: Customized LED 0x824 > r8168: read back LED setting as 0x824 > PCI: 02:00.0 init finished in 31916 usecs > PCI: 03:00.0 init ... > PCI: 03:00.0 init finished in 2775 usecs > PCI: 04:00.0 init ... > PCI: 04:00.0 init finished in 2763 usecs > PNP: 002e.1 init ... > PNP: 002e.1 init finished in 2620 usecs > PNP: 002e.2 init ... > PNP: 002e.2 init finished in 2620 usecs > PNP: 002e.3 init ... > PNP: 002e.3 init finished in 2621 usecs > PNP: 002e.5 init ... > PNP: 002e.5 init finished in 2598 usecs > PNP: 002e.b init ... > PNP: 002e.b init finished in 2621 usecs > Devices initialized > BS: BS_DEV_INIT times (us): entry 7 run 1065844 exit 42 > Finalize devices... > PCI: 00:1f.0 final > Devices finalized > BS: BS_POST_DEVICE times (us): entry 41 run 13140 exit 41 > BS: BS_OS_RESUME_CHECK times (us): entry 41 run 77 exit 42 > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'fallback/dsdt.aml' > CBFS: Found @ offset 2ccc0 size 2e49 > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'fallback/slic' > CBFS: 'fallback/slic' not found. > ACPI: Writing ACPI tables at 7f751000. > ACPI: * FACS > ACPI: * DSDT > ACPI: * FADT > ACPI: added table 1/32, length now 40 > ACPI: * SSDT > Generating ACPI PIRQ entries > ACPI: added table 2/32, length now 44 > ACPI: * MCFG > ACPI: added table 3/32, length now 48 > ACPI: * MADT > ACPI: added table 4/32, length now 52 > current = 7f754570 > ACPI: * DMAR > ACPI: added table 5/32, length now 56 > ACPI: * HPET > ACPI: added table 6/32, length now 60 > ACPI: * SSDT2 > ACPI: added table 7/32, length now 64 > current = 7f7546a0 > ACPI: done. > ACPI tables: 13984 bytes. > Writing table forward entry at 0x00000500 > Wrote coreboot table at: 00000500, 0x10 bytes, checksum 3067 > Writing coreboot table at 0x7f775000 > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'cmos_layout.bin' > CBFS: Found @ offset 28600 size 29c > 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES > 1. 000000007f751000-000000007f78efff: CONFIGURATION TABLES > 2. 000000007f78f000-000000007f7ccfff: RAMSTAGE > 3. 000000007f7cd000-000000007f7fffff: CONFIGURATION TABLES > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > Wrote coreboot table at: 7f775000, 0x564 bytes, checksum 7fe6 > coreboot table: 1404 bytes. > IMD ROOT 0. 7f7ff000 00001000 > IMD SMALL 1. 7f7fe000 00001000 > CONSOLE 2. 7f7de000 00020000 > TIME STAMP 3. 7f7dd000 00000910 > MRC DATA 4. 7f7dc000 00000fe4 > ROMSTG STCK 5. 7f7d7000 00005000 > AFTER CAR 6. 7f7cd000 0000a000 > RAMSTAGE 7. 7f78e000 0003f000 > ACPI GNVS 8. 7f78d000 00001000 > SMM BACKUP 9. 7f77d000 00010000 > COREBOOT 10. 7f775000 00008000 > ACPI 11. 7f751000 00024000 > IMD small region: > IMD ROOT 0. 7f7fec00 00000400 > MEM INFO 1. 7f7fea40 000001a9 > ROMSTAGE 2. 7f7fea20 00000004 > COREBOOTFWD 3. 7f7fe9e0 00000028 > BS: BS_WRITE_TABLES times (us): entry 42 run 302936 exit 42 > CBFS: 'Master Header Locator' located CBFS at [1a0000:400000) > CBFS: Locating 'fallback/payload' > CBFS: Found @ offset 2fb80 size 1929bd > Checking segment from ROM address 0xffdcfbb8 > Payload being loaded at below 1MiB without region being marked as RAM usable. > Checking segment from ROM address 0xffdcfbd4 > SELF segment doesn't target RAM: 0x00100000, 5203948 bytes > 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES > 1. 000000007f751000-000000007f78efff: CONFIGURATION TABLES > 2. 000000007f78f000-000000007f7ccfff: RAMSTAGE > 3. 000000007f7cd000-000000007f7fffff: CONFIGURATION TABLES > Payload not loaded. > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

4 6

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
by Nico Huber 17 Dec '18

17 Dec '18

Hi Pete, On 01.12.18 17:21, petecb via coreboot wrote: > I'm wondering if my problem is related to not having any SATA drives > installed? (I just have a PCI-E SSD). It may be the case that the logic > to disable combined mode is not getting triggered in my scenario, yet it > would do if there was a SATA drive present. it's a configuration issue. If you have nvram settings enabled (CONFIG_ USE_OPTION_TABLE), you can enable `sata_ahci_mode` with nvramtool. No idea why combined mode is the default, it's only useful for OSes from the '90s. It's not about the type of drives (SATA vs PATA) connected but how the SATA controller identifies itself to the OS. Hope that helps, Nico

6 7

Re: [coreboot] coreboot Digest, Vol 166, Issue 16
by claudio T 17 Dec '18

17 Dec '18

Il 16/dic/2018 12:01 PM, <coreboot-request(a)coreboot.org> ha scritto: Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.coreboot.org/mailman/listinfo/coreboot or, via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. Re: Rowhammer mitigation: RH activation probability (Taiidan(a)gmx.com) 2. Re: Rowhammer mitigation: RH activation probability (Carl-Daniel Hailfinger) 3. coreboot 4.9 release scheduled for Dec 20th (Patrick Georgi) ---------------------------------------------------------------------- Message: 1 Date: Fri, 14 Dec 2018 17:36:57 -0500 From: "Taiidan(a)gmx.com" <Taiidan(a)gmx.com> To: coreboot(a)coreboot.org Subject: Re: [coreboot] Rowhammer mitigation: RH activation probability Message-ID: <279ff836-2525-798d-985f-dc3b122e78e7(a)gmx.com> Content-Type: text/plain; charset=utf-8 Upon doing more research I am noting in regards to my previous post about vendors who claimed to solve the problem by doubling the RAM refresh rate in their firmware that according to [1] it only postpones the problem rather than eliminating it. [1] https://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug… On 12/14/2018 03:20 AM, Nico Huber wrote:> On 07.12.18 22:46, Taiidan(a)gmx.com wrote: >> rowhammer is almost entirely a laptop problem or for that matter >> anything that uses SODIMM's due to their high density. > > That doesn't seem right. Can you give any examples of chips commonly > used on SO-DIMMs that can't be found on DIMMs? Ahhh good point commodity parts. > I had the feeling you find the same chips on both. SO-DIMMs often host 16 chips. If you'd > want the same capacity on a DIMM with less chip density, you'd need > 32 chips (or physically bigger chips). Never seen that (though didn't > look for it either). I had read it somewhere awhile back when the problem first appeared stating that it didn't appear as much in desktops and servers due to lower density RAM which made sense to me considering the size difference I also tested my various home computers and only my laptops had a problem not the desktops/servers (all have ecc but it didn't show any errors) so I figured that it was an accurate statement. This shows the value of going back to quickly research something before providing the statement (and having others who aren't me to review!) On 12/14/2018 12:21 PM, ron minnich wrote: > So, at first we have a non-specific ad-hominem attack: I want people to get the best advice possible (hence my list of alternative sources) and while I can cite examples I am prohibited from potentially starting arguments about them so I do not want to. To me providing good advice is important since someone reading it could be facing a life or death situation such as a journalist in a hostile country and why I always apologize and note a correction if I give wrong advice. I am also a better sysadmin than I am a programmer so I concentrate on my strong points. > > On Fri, Dec 7, 2018 at 1:53 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >> I would like to note that company has provided poor security advice on a >> variety of occasions > > followed by poor security advice: > >> rowhammer is almost entirely a laptop problem or for that matter >> anything that uses SODIMM's due to their high density. > > which is immediately disproven with a 3 term search on google: > https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervi… > > "The Google Project Zero team led the way in discovering practical > Rowhammer attacks against client platforms. Google production machines > use double refresh rate to reduce errors, and ECC RAM that detects and > corrects Rowhammer-induced errors." > > so, please all, no ad-hominem attacks, and if you're going to make a > technical claim, please be ready to provide justification. I had read it in a whitepaper somewhere and I am attempting to find out where. That is a good idea to have a citation on hand for claims like this and I will do so from now on as if I were editing the wiki. > > thanks > > ron If a post of mine is not acceptable then I encourage you or others to exorcise your right to deny it as sometimes I do not realize what is and what isn't considered okay. ------------------------------ Message: 2 Date: Sun, 16 Dec 2018 01:02:28 +0100 From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> To: "Taiidan(a)gmx.com" <Taiidan(a)gmx.com>, coreboot(a)coreboot.org Subject: Re: [coreboot] Rowhammer mitigation: RH activation probability Message-ID: <cb7658dd-dc3c-1e91-5bef-046e4beb150a(a)gmx.net> Content-Type: text/plain; charset=UTF-8 Actually, the latest Rowhammer attack is harder to exploit on laptops due to the power saving features for row activation. Servers use a different row activation strategy which has better performance, but also enables one-location hammering. See Gruss, Lipp, Schwarz, Genkin et al.: Another Flip in the Wall of Rowhammer Defenses 2018 IEEE Symposium on Security and Privacy Regards, Carl-Daniel On 14.12.2018 23:36, Taiidan(a)gmx.com wrote: > Upon doing more research I am noting in regards to my previous post > about vendors who claimed to solve the problem by doubling the RAM > refresh rate in their firmware that according to [1] it only postpones > the problem rather than eliminating it. > > [1] > https://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug… > > On 12/14/2018 03:20 AM, Nico Huber wrote:> On 07.12.18 22:46, > Taiidan(a)gmx.com wrote: >>> rowhammer is almost entirely a laptop problem or for that matter >>> anything that uses SODIMM's due to their high density. >> That doesn't seem right. Can you give any examples of chips commonly >> used on SO-DIMMs that can't be found on DIMMs? > Ahhh good point commodity parts. > >> I had the feeling you find the same chips on both. SO-DIMMs often host > 16 chips. If you'd >> want the same capacity on a DIMM with less chip density, you'd need >> 32 chips (or physically bigger chips). Never seen that (though didn't >> look for it either). > I had read it somewhere awhile back when the problem first appeared > stating that it didn't appear as much in desktops and servers due to > lower density RAM which made sense to me considering the size difference > I also tested my various home computers and only my laptops had a > problem not the desktops/servers (all have ecc but it didn't show any > errors) so I figured that it was an accurate statement. This shows the > value of going back to quickly research something before providing the > statement (and having others who aren't me to review!) > > > On 12/14/2018 12:21 PM, ron minnich wrote: > >> So, at first we have a non-specific ad-hominem attack: > I want people to get the best advice possible (hence my list of > alternative sources) and while I can cite examples I am prohibited from > potentially starting arguments about them so I do not want to. > > To me providing good advice is important since someone reading it could > be facing a life or death situation such as a journalist in a hostile > country and why I always apologize and note a correction if I give wrong > advice. I am also a better sysadmin than I am a programmer so I > concentrate on my strong points. > >> On Fri, Dec 7, 2018 at 1:53 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >>> I would like to note that company has provided poor security advice on a >>> variety of occasions >> followed by poor security advice: >> >>> rowhammer is almost entirely a laptop problem or for that matter >>> anything that uses SODIMM's due to their high density. >> which is immediately disproven with a 3 term search on google: >> https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervi… >> >> "The Google Project Zero team led the way in discovering practical >> Rowhammer attacks against client platforms. Google production machines >> use double refresh rate to reduce errors, and ECC RAM that detects and >> corrects Rowhammer-induced errors." >> >> so, please all, no ad-hominem attacks, and if you're going to make a >> technical claim, please be ready to provide justification. > I had read it in a whitepaper somewhere and I am attempting to find out > where. > > That is a good idea to have a citation on hand for claims like this and > I will do so from now on as if I were editing the wiki. > >> thanks >> >> ron > If a post of mine is not acceptable then I encourage you or others to > exorcise your right to deny it as sometimes I do not realize what is and > what isn't considered okay. > ------------------------------ Message: 3 Date: Sun, 16 Dec 2018 10:09:28 +0100 From: Patrick Georgi <pgeorgi(a)google.com> To: coreboot <coreboot(a)coreboot.org> Subject: [coreboot] coreboot 4.9 release scheduled for Dec 20th Message-ID: <CAE-gjdVkT-YZEiZwSykUAby9wQ+xy-9Zs6HvJWG5H4_vxKhjNg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi everybody, just a friendly reminder that I plan to do the coreboot 4.9 release on Dec 20th, which is next Thursday! Please test master, report or fix issues and be considerate with what you're merging (ie. maybe don't land the Rewrite Of Everything before the release). I'd like to avoid the need to spin a 4.9.1 release :-) Also take a look at the tentative release notes at https://piratenpad.de/p/S8slYOeag and add the changes of the last ~8 months that you think warrant a shout-out. 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

coreboot 4.9 release scheduled for Dec 20th
by Patrick Georgi 16 Dec '18

16 Dec '18

Hi everybody, just a friendly reminder that I plan to do the coreboot 4.9 release on Dec 20th, which is next Thursday! Please test master, report or fix issues and be considerate with what you're merging (ie. maybe don't land the Rewrite Of Everything before the release). I'd like to avoid the need to spin a 4.9.1 release :-) Also take a look at the tentative release notes at https://piratenpad.de/p/S8slYOeag and add the changes of the last ~8 months that you think warrant a shout-out. 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

Rowhammer mitigation: RH activation probability
by emanuele 16 Dec '18

16 Dec '18

Hello everyone, I know some system has support for a particular feature against Rowhammer attack. The "RH activation probability" settings allows to refresh a row with a tunable probability. For example some AMI BIOS version include this option: https://forums.puri.sm/t/row-hammer/793/7 I have found a trace in coreboot code here: https://github.com/siro20/coreboot/blob/master/src/vendorcode/intel/fsp/fsp… Anyone know if this option is currently available on coreboot? Thank you all!

5 5

Lenovo T410 Coreboot
by A. Veek 14 Dec '18

14 Dec '18

2 1

Re: [coreboot] Status Thinkpad T410
by kinky_nekoboi 14 Dec '18

14 Dec '18

ok the problems start when i try to merge the patch found on https://review.coreboot.org/c/coreboot/+/11791 into a coreboot master clone ... any guide? i am not that advanced in git Am 08.11.18 um 17:40 schrieb Mike Banon: > Go to review.coreboot.org, search for the recently updated T410 > patches and apply them to your locally cloned coreboot, then build and > test it. Let us know if you have a trouble at any step > On Thu, Nov 8, 2018 at 7:35 PM kinky_nekoboi > <kinky_nekoboi(a)bluetardis.de> wrote: >> I have hardware to test, >> T410 with intel gpu + little flashing tool collection. >> i am waiting for instructions >> >> Am 8. November 2018 17:30:00 MEZ schrieb Peter Lemenkov <lemenkov(a)gmail.com>: >>> Hello! >>> >>> чт, 8 нояб. 2018 г. в 10:50, Angel Pons <th3fanbus(a)gmail.com>: >>>> >>>> Hello nekoboi, >>>> >>>> On Thu, Nov 8, 2018, 10:39 kinky_nekoboi <kinky_nekoboi(a)bluetardis.de wrote: >>>>> >>>>> is there any work going on in the T410 Port ? >>>>> >>>>> Hardware is simular to X201 >>>>> >>>>> I heard some people succesfully flashed x201 roms. >>>> >>>> >>>> I recall seeing a gerrit patch for it, though it is old. I would work on it but I don't have any Thinkpad (let alone a T410). >>> >>> Btw I've updated recently both t410 and t410s patches from gerrit >>> according to the recent coreboot changes, but I've got the same story >>> - I don't have hardware to test. >>> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2018