coreboot October 2019

coreboot@coreboot.org

67 participants
59 discussions

X230 + Coreboot + Hackintosh
by Armin Pournaki 31 Oct '19

31 Oct '19

Hello everyone, I am trying to get my Thinkpad X230 to work with Coreboot and the latest version of macOS. I found this entry in the mailing list archives which had already tackled the topic: https://coreboot.coreboot.narkive.com/KVx0CdqD/coreboot-with-an-uefi-payloa… <https://coreboot.coreboot.narkive.com/KVx0CdqD/coreboot-with-an-uefi-payloa…> However, I cannot reproduce a working hackintosh environment with either Tianocore or SeaBIOS. I was hoping that the original authors were still out there and could give me a hint! Best, Armin

1 0

X230 + Coreboot + Hackintosh
by Armin Pournaki 31 Oct '19

31 Oct '19

1 0

How to access the PCIE device registers at an early stage of coreboot booting?
by dponamorev＠gmail.com 29 Oct '19

29 Oct '19

Hello to all! Need quick help! I am poorly versed in the question so detailed answers are welcome :) ! As a result of the motherboard developers laziness the hard straps for ASPEED AST2510 chip were not properly prescribed. Now I need to write register 0x1e6e2070 with necessary bits [5][15] to '1' at an early stage of coreboot booting. Motherboard based on Intel Atom SOC Processor C3758 (DENVERTON_NS). The AST2510 chip is always located on (B3:D0:F0) [0x1a03:0x2000] after aspeed bridge (B2:D0:F0) [1a03/1150]: PCI: 00:09.0 scanning... do_pci_scan_bridge for PCI: 00:09.0 PCI: pci_scan_bus for bus 02 PCI: 02:00.0 subordinate PCI PCI: 02:00.0 [1a03/1150] enabled PCI: 02:00.0 scanning... do_pci_scan_bridge for PCI: 02:00.0 PCI: pci_scan_bus for bus 03 PCI: 03:00.0 [1a03/2000] ops PCI: 03:00.0 [1a03/2000] enabled The code below located in romstage.c file successfully finds the device: pci_devfn_t dev; /* ASPEED AST2510 Graphics (B3:D0:F0). */ dev = PCI_DEV(3, 0, 0); uint32_t id = pci_read_config32(dev, 0); // id = (0x1a03<<16) | 0x2000 => Aspeed graphics! What to do next, I do not quite understand. Based on the Aspeed driver from /src/driver/aspeed/common/ast_main.c (int ast_driver_load) I compiled the code, but I need to somehow get the filled "struct device* dev". 1. Please tell me how get the filled "struct device" in my case? Something like this could be: pcidev_path_on_root(PCI_DEV(3, 0, 0)); ? 2. Do I need to make the device "enable" before access at its registers? Maybe I something else forgot? 3. Is it necessary to somehow release the resources allocated? Release the assigned base addresses maybe? Estimated Code: #define AST_IO_MM_OFFSET (0x380) struct device *dev; struct resource *res; void __iomem *regs; void __iomem *ioregs; bool io_space_uses_mmap; /* PCI BAR 1 */ res = find_resource(dev, 0x14); regs = res2mmio(res, 0, 0); /* PCI BAR 2 */ io_space_uses_mmap = false; res = find_resource(dev, 0x18); /* If we don't have IO space at all, use MMIO now and assume the chip has MMIO enabled by default (rev 0x20 and higher).*/ if (!(res->flags & IORESOURCE_IO)) { printk("platform has no IO space, trying MMIO\n"); ioregs = regs + AST_IO_MM_OFFSET; io_space_uses_mmap = true; } /* "map" IO regs if the above hasn't done so already */ if (!ioregs) { ioregs = res2mmio(res, 0, 0); if (!ioregs) { ret = -EIO; goto out_free; } /* Adjust the I/O space location to match expectations (the code expects offset 0x0 to be I/O location 0x380) */ ioregs = (void *)AST_IO_MM_OFFSET; } iowrite32(0x1e6e0000, regs + 0xf004); // Re-mapping Base address register iowrite32(0x1, regs + 0xf000); // Enable P-Bus to AHB bridge iowrite32(0x1688a8a8, regs + 0x12000); // Unprotect SCU Registers, if read 0x1 - Unprotected! iowrite32(0xf900d2e6, 0x12070); // Write ASPEED SCU70 (0x1e6e2070) register with new straps bits.

3 3

Disable a PCI device
by Jorge Fernandez Monteagudo 29 Oct '19

29 Oct '19

Hi, Is there some way to disable a PCI device in coreboot using code to avoid to be listed once linux kernel is running? I want the device '00:01.0 Class 0300: Device 1002:9874 (rev 84)' to dissapear from the lspci command if some condition is met in the coreboot. I don't want to do it modifying the devicetree.cb... Now I'm using 'dev_set_enabled(vga_onboard, 0);' and is working ok avoiding the vgabios load but still apears the device in lspci. Thanks! Jorge

2 2

Debugging EHCI - but Pre-CBMEM romstage/ramstage console overflowed, log truncated
by Mike Banon 27 Oct '19

27 Oct '19

Good day, I'm researching if it's possible to support a cheaper FT232BL-based EHCI usbdebug dongle like the already-supported FT232H -- to make EHCI debugging more accessible to the newcoming coreboot'ers -- and need the detailed logs (i.e. CONFIG_DEBUG_CONSOLE_INIT) to figure this out. However, there's a major obstacle: because of "Pre-CBMEM romstage/ramstage console overflowed, log truncated", I couldn't get a complete EHCI initialization log. Increasing CONFIG_CONSOLE_CBMEM_BUFFER_SIZE doesn't help, because it is Pre-CBMEM. I've already replaced its' dprintk messages with various acronyms (listed below), which has helped me to get more log, but this is not enough. Any ideas? Could not reset EHCI controller.\n = RSTF! EHCI controller reset successfully.\n = RSTO. No device found in debug port %d\n = NDVP %d. EHCI controller halted successfully.\n = HLTS. EHCI controller is not halted. Reset may fail.\n = HLTF! EHCI could not be started.\n = SF! EHCI started.\n = SO. EHCI done waiting for port.\n = DWT. No device in EHCI debug port.\n = NDV. EHCI debug port enabled.\n = DPE. Could not probe gadget on debug port.\n = CPG. PORTSC #%d: %08x\n === P%d=%04x. debug_port: %d\n === dp=%d. n_ports: %d\n === np=%d. Best regards, Mike Banon

2 3

How to configure ECC memory through FSP 1.0 (Baytrail)
by Alexey Borovikov 27 Oct '19

27 Oct '19

I have is board on Soc Baytrail processor with ECC memory. After setting the correct memory parameters through the FSP, the board started. But when I try to set the “BakerSport Platform (ECC) Type” parameter, the board stops booting with post code 2a. There are no more parameters in FSP for ECC memory. What other options can I try? What am I doing wrong?

1 0

FOSDEM 2020 CfP
by Carl-Daniel Hailfinger 26 Oct '19

26 Oct '19

Hi, we want to participate again in FOSDEM 2020. Location: Brussels. Date: 1&2 February. Deadlines: Own developer room: Expired... Stand: 1 November Main track talk: first batch 11 October, second batch 8 November Lightning talk: 22 November Talk/Demo in foreign devroom: probably end of October If you want me to submit a stand request for a combine coreboot/flashrom/LinuxBoot stand, please have someone volunteer as backup organizer. We also need stand volunteers. Side note: Should we reach out to the OpenBMC/u-bmc communities? https://fosdem.org/2020/news/2019-08-13-call-for-participation/ Regards, Carl-Daniel

1 1

Coreboot with multiple gpu
by Jorge Fernandez Monteagudo 25 Oct '19

25 Oct '19

Hi all, In my current board (AMD Bettong) I have a GPU integrated in the SOC and is working ok. Also has two PCI connectors and in one of this I've connected a NVidia graphic card. Running a debian distribution with both GPUs connected to two monitors hangs the system with coreboot and with the original amibios one. With amibios is possible to disable the onboard GPU then the system works ok. With the coreboot I've tried to do the same using the next code in OemCustomize.c 'OemPostParams()' method with no luck (Maybe this policy is not compiled in the Agesa black-box): // Disable iGPU if any PCIe/PCI graphics card present. PostParams->GnbPostConfig.IgpuEnableDisablePolicy = IGPU_DISABLE_ANY_PCIE; ///< Disable iGPU if any PCI or PCIE graphics card is present A more drastic approach is to disable the PCI related to the AMD onboard GPU in devicetree.cb device pci 1.0 off end # Internal Graphics P2P bridge 0x9804 and set 'CONFIG_NO_GFX_INIT=y' to build the rom. Then, until grub menu I don't have any console. Disabling the pci entry in devicetree.cb but with the GFX enabled I get the next error: Timestamp - Option ROM initialization: 13568077860 CBFS @ 200 size 7ffe00 CBFS: 'Master Header Locator' located CBFS at [200:800000) CBFS: Locating 'pci10de,1d01.rom' CBFS: 'pci10de,1d01.rom' not found. Option ROM address for PCI: 02:00.0 = f3000000 PCI expansion ROM, signature 0xaa55, INIT size 0xec00, data ptr 0x01a0 PCI ROM image, vendor ID 10de, device ID 1d01, PCI ROM image, Class Code 030000, Code Type 00 Copying VGA ROM Image from f3000000 to 0xc0000, 0xec00 bytes Timestamp - Option ROM copy done: 13719240943 Real mode stub @00000600: 889 bytes Calling Option ROM... ... Option ROM returned. VBE: Getting information about VESA mode 4122 VBE: Function call failed! Error: In vbe_get_mode_info function My questions: Is it possible to have the console redirected to the PCI graphic card? Is it possible to disable automatically the onboard GPU when a PCI graphic card is detected? Mainly don't relaying in Agesa code only coreboot PCI code... Thanks!

1 0

Intel Saddlebrook FSP 2.0 migration
by Michael Niewöhner 22 Oct '19

22 Oct '19

Hi folks, I've migrated Intel Saddlebrook to FSP 2.0 in https://review.coreboot.org/c/coreboot/+/35923. Would be great if there are people willing to test and review this. Thanks! Regards Michael

1 0

Bootblock and Romstage logs getting skipped on first boot and boot continues from ramstage instead
by Naveen Chaudhary 22 Oct '19

22 Oct '19

Hi, The title seems pretty stupid but that's what I am observing on my MinnowMax. When I have built coreboot and flashed and the moment I connect the power cable back, I see the following logs (no romstage beginning logs, no console_init logs): romstage_main_continue status: 0 hob_list_ptr: 7ae20000 FSP Status: 0x0 PM1_STS = 0x2000 PM1_CNT = 0x0 GEN_PMCON1 = 0x1001808 romstage_main_continue: prev_sleep_state = S0 Baytrail Chip Variant: Bay Trail-I (ISG/embedded) MRC v0.102 1 channels of DDR3 @ 1066MHz CBMEM: IMD: root @ 7adff000 254 entries. IMD: root @ 7adfec00 62 entries. FMAP: Found "FLASH" version 1.1 at 500000. FMAP: base = ff800000 size = 800000 #areas = 3 SMM Memory Map SMRAM : 0x7b000000 0x800000 Subregion 0: 0x7b000000 0x700000 Subregion 1: 0x7b700000 0x100000 Subregion 2: 0x7b800000 0x0 CBFS: 'Master Header Locator' located CBFS at [500200:800000) CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 2ca80 size ef16 coreboot-4.10-984-gdd4c625469-dirty Mon Oct 14 18:32:09 UTC 2019 ramstage starting (log level: 7)... Moving GDT to 7adfe900...ok BS: BS_PRE_DEVICE times (us): entry 0 run 2 exit 0 CBFS: 'Master Header Locator' located CBFS at [500200:800000) CBFS: Locating 'cpu_microcode_blob.bin' CBFS: Found @ offset 1fe00 size cc00 microcode: sig=0x30679 pf=0x1 revision=0x90c CPUID: 00030679 Cores: 2 However, when there is a hard reset by the SeaBIOS when there is no bootable device found, I get the complete logs since the romstage. No bootable device. Retrying in 60 seconds. Rebooting. In resume (status=0) In 32bit resume Attempting a hard reboot ACPI hard reset 1:cf9 (6) coreboot-4.10-984-gdd4c625469-dirty Mon Oct 14 18:32:09 UTC 2019 romstage starting (log level: 7)... <--- This logs does not appear in the first case. Can someone please help understand this behaviour as why on the first boot, no ramstage log appears and then each successive reset I get the romstage logs, but not in the first boot. Previous sleep state reported in the logs in both the cases is S0. Am I just missing the logs or there is indeed something happening under the hood? Regards, Naveen

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2019