coreboot March 2015

coreboot@coreboot.org

62 participants
166 discussions

[Mohon Peak] Console output on external UARTs behind PCIe
by Patrick Agrain 18 Mar '15

18 Mar '15

Hello Kyösti, I tried what you suggested below: - Enabled EARLY_PCI_BRIDGE - Set Bridge at D:1 F:0 - Enabled OXI PCIe952 and disabled SERIAL_PORT_ON_SUPERIO. Reboot Mohon Peak CRB: failed. No output. POST code at 0xA9. Will try to get further. If anybody has an idea... Regards, Patrick Agrain On Fri, 2015-03-06 at 17:25 +0100, Patrick Agrain wrote: >/ Hello everybody, />/ />/ Do you think that it would be possible to output the console messages />/ from coreboot (seabios) on another UART port (strapped to be visible on />/ Memory-based space or IO Space) connected on a PCIe slot ? />/ / Yes, it has been done before. I should have a hack for SeaBIOS to support memory-mapped UART somewhere, I will go and look. If I remember correctly SeaBIOS boot media selection only works from local keyboard, not over serial. >/ I've purchased a StarTech UART board with an OXPCIe952 chip, with the />/ same IDs as visible in ./src/drivers/uart/oxpcie.c. />/ />/ On />/ http://www.coreboot.org/Serial_console#PCIe.2FMini_PCIe_based_serial_cards, />/ what is behind the sentence: />/ "In order to use the card for romstage debugging, minimal setup of the />/ PCIe bridge and the MPEX2S952 have to be added to romstage.c" ? />/ / You need to enable OxPCIe support and set EARLY_PCI_BRIDGE_* variables in menuconfig. If you can boot to OS with that plaform, with the serial card installed, get the location of PCIe rootport (aka. parent bridge) for OxPCIe card with lspci -vv command. Once you have OS shell, both coreboot and SeaBIOS console messages are available from CBMEM console using 'cbmem -c' command. >/ Thanks in advance. />/ Best regards, />/ Patrick Agrain />/ / HTH, Kyösti

2 8

[Intel Atom C2000 Rangeley] SPI Descriptor issue related to coreboot
by 郭佳 18 Mar '15

18 Mar '15

Hi buddies, I'm porting coreboot to Intel Atom C2000 board provided from ADI. I've retrieved the source code released by ADI from github. ADI's coreboot source code requires SegaBIOS SDK to build, since I don't have one, I've modified the Makefile to use toolchain provided by original coreboot(xgcc). When building done, there is a coreboot.rom(8M) under coreboot/build directory, and flashing this file to boot rom doesn't bring the system up, even no serial outputs. I found that there is no descriptor segment at the beginning of coreboot.rom. And in Makefile, there are following lines: "dd if=../intel/mainboard/intel/mohon_peak/unlocked_descriptor/descriptor.bin of= build/coreboot.pre conv=notrunc > /dev/null 2>&1;" Unfortunately, ADI doesn't release descriptor.bin. So, I use ifdtool to dump the descriptor from ADI's coreboot binary file. Firstly, I unlock the descriptor, then extract descriptor.bin, and after that, reassembly my own coreboot.rom file, but still fail to bring system up (no serial output, cpu core seems to fall into some infinite loop, when debugging with SourcePoint) I don't know if I've made my question clear, I'm new to x86/coreboot. Can someone help me? Thank you in advance. Regards, Hook Guo

1 0

[Intel Atom C2000 Rangeley] SPI Descriptor issue related to coreboot
by 郭佳 18 Mar '15

18 Mar '15

1 0

Coreboot + GRUB2 + xhci (baytrail_fsp)
by dgim 17 Mar '15

17 Mar '15

Hello! I try to startup linux from usb stick on my board (SoC e38xx, fsp_baytrail) via "Coreboot + GRUB2". Can GRUB2 work with xhci device? libpayload can work with xhci. How can i configure GRUB2 to use custom libpayload? Many thank's for help. Best regards, Jim

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Stefan Reinauer 17 Mar '15

17 Mar '15

* Aaron Durbin <adurbin(a)chromium.org> [150316 22:44]: > A quick hack is add ALIGN(32) to the linker script before > _bs_init_begin: src/arch/x86/ramstage.ld > > But I think we'll need to store pointers to the structures in order to > properly handle the situation where the compiler is effectively making > alignment/size decisions for some reason. I suggest trying to enforce alignment / size instead of adding another layer of indirection. Stefan

2 1

Re: [coreboot] GCC update broke AMD Fam10h boot
by Timothy Pearson 16 Mar '15

16 Mar '15

On 03/16/2015 04:44 PM, Aaron Durbin wrote: > On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson > <tpearson(a)raptorengineeringinc.com> wrote: >> On 03/16/2015 09:23 AM, Aaron Durbin wrote: >>> >>> On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson >>> <tpearson(a)raptorengineeringinc.com> wrote: >>>> >>>> All, >>>> >>>> Just a heads up as there is no bugtracker for this project. GIT commit >>>> 53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2, >>>> breaks >>>> ramstage on AMD Fam10h systems (ramstage loads, sends its 0x39 POST code, >>>> but then goes into an infinite loop). Downgrading the GCC version >>>> repairs >>>> the boot failure. >>>> >>>> Not sure if you want to revert that commit until someone can figure out >>>> what >>>> changed to cause the problem. >>> >>> >>> Could post ramstage.elf from the two different builds somewhere? I'd >>> like to take a peak at what is in there. >> >> >> Sure: >> https://raptorengineeringinc.com/coreboot/built.tar.bz2 >> >> Other oddities: >> GCC 4.8.3: >> normal/romstage 0x7ff80 stage 97345 >> normal/ramstage 0x97c40 stage 154869 >> >> GCC 4.9.2: >> normal/romstage 0x7ff80 stage 94773 >> normal/ramstage 0x97240 stage 173942 >> >> Note in particular, judging from the file sizes, that something seems to >> have been relocated from romstage to ramstage by the new gcc version. >> > > I noticed you had CONFIG_COVERAGE selected in both the builds. Could > you try not having that selected? I wonder if something changed in the > compiler on that front. But... I think I found a bigger issue. That shouldn't be a problem. For reference, should CONFIG_COVERAGE be on or off for board status report builds? > $ nm ./gcc4.8.3/ramstage.debug | sort | grep -C 4 _bs_init_ > 00146fc4 r pch_intel_wifi > 00146fd0 R cpu_drivers > 00146fd0 R epci_drivers > 00146fd0 r model_10xxx > 00146fdc R _bs_init_begin > 00146fdc r cbmem_bscb > 00146fdc R ecpu_drivers > 00146ff0 r gcov_bscb > 0014702c R _bs_init_end > 0014702c R pnp_conf_mode_870155_aa > 00147034 R pnp_conf_mode_a0a0_aa > 0014703c R pnp_conf_mode_8787_aa > 00147044 R pnp_conf_mode_7777_aa > > $ nm ./gcc4.9.2/ramstage.debug | sort | grep -C 4 _bs_init_ > 001465c4 r pch_intel_wifi > 001465d0 R cpu_drivers > 001465d0 R epci_drivers > 001465d0 r model_10xxx > 001465dc R _bs_init_begin > 001465dc R ecpu_drivers > 001465e0 r cbmem_bscb > 00146600 r gcov_bscb > 0014663c R _bs_init_end > 00146640 R pnp_conf_mode_870155_aa > 00146648 R pnp_conf_mode_a0a0_aa > 00146650 R pnp_conf_mode_8787_aa > 00146658 R pnp_conf_mode_7777_a > > The boot state callbacks place the whole structure for each entry > between _bs_init_begin and _bs_init_end. For both binaries the size of > 0x14. > For the 4.8.3 compiled ramstage I see: > (gdb) p/x 0x0014702c - 0x00146fdc > $12 = 0x50 > For the 4.9.2 compiled ramstage I see: > (gdb) p/x 0x014663c - 0x01465dc > $14 = 0x60 > > 0x60 is not a multiple of 0x14 -- which is means things aren't cool. This makes perfect sense--whenever coreboot didn't hang outright it started infinitely spewing some message regarding a boot state callback already being complete. > Looking at the symbols it appears the compiler is aligning those > structures to 32-bytes for some reason... > > A quick hack is add ALIGN(32) to the linker script before > _bs_init_begin: src/arch/x86/ramstage.ld So I wonder if this is unique to AMD Fam10h or if a whole lot of other boards broke with the gcc update. I wouldn't have even caught this if I hadn't checked out a new coreboot tree instead of copying over the existing tree with the prebuilt crossgcc, so we might be looking at a ticking timebomb that will go off as people start upgrading their crossgcc versions... > But I think we'll need to store pointers to the structures in order to > properly handle the situation where the compiler is effectively making > alignment/size decisions for some reason. I am not at all familiar with the code in question, so all I can do is offer to test. Thanks for analysing the problem! > -Aaron -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 1

Re: [coreboot] GCC update broke AMD Fam10h boot
by Timothy Pearson 16 Mar '15

16 Mar '15

On 03/16/2015 09:23 AM, Aaron Durbin wrote: > On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson > <tpearson(a)raptorengineeringinc.com> wrote: >> All, >> >> Just a heads up as there is no bugtracker for this project. GIT commit >> 53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2, breaks >> ramstage on AMD Fam10h systems (ramstage loads, sends its 0x39 POST code, >> but then goes into an infinite loop). Downgrading the GCC version repairs >> the boot failure. >> >> Not sure if you want to revert that commit until someone can figure out what >> changed to cause the problem. > > Could post ramstage.elf from the two different builds somewhere? I'd > like to take a peak at what is in there. Sure: https://raptorengineeringinc.com/coreboot/built.tar.bz2 Other oddities: GCC 4.8.3: normal/romstage 0x7ff80 stage 97345 normal/ramstage 0x97c40 stage 154869 GCC 4.9.2: normal/romstage 0x7ff80 stage 94773 normal/ramstage 0x97240 stage 173942 Note in particular, judging from the file sizes, that something seems to have been relocated from romstage to ramstage by the new gcc version. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 1

Automated test system: Nominations wanted
by Carl-Daniel Hailfinger 16 Mar '15

16 Mar '15

Hi, I am currently planning to set up a test system with 5 (later up to 10) machines boot testing each new coreboot commit. This test system will be serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. Current goals for every commit: - Check if coreboot + SeaBIOS are able to boot Linux to a point where network is up and running Current goals for every work day: - Check if screen, keyboard and touchpad/mouse work - Check if USB works and has the expected transfer speed (i.e. if USB High and Super Speed both work) Future goals for every work day: - Run memtest86+ (short run) - Run GRUB2 and boot Linux - Check if USB works (see above) Once any test running once per work day can be automated with reasonable effort (i.e. not requiring robots or human interaction), it can be moved to a per-commit goal. The selection of target systems should include: 1. at least one x86 laptop without an active ME (present but inactive would be OK) 2. at least one x86 laptop which can boot x86-blob-free (except microcode) 3. at least one x86 board or laptop which needs neither blobs (except microcode) nor ME 4. at least one x86 board with reasonable (past or present) business market penetration 5. if the first two laptops use the same CPU vendor, a board using a different x86 CPU vendor 1+2 are designed to partially remove the potential for nasty surprises, 3 should remove nasty surprises completely, 4 is the one I need to show that the test system is actually relevant for our goals, 5 should give us better coverage outside the most common systems used by coreboot developers. Please nominate machines (e.g. "Thinkpad T60 with Intel graphics") and tell me to which category they belong. If a system fits into multiple categories, please specify that as well. I will try to consolidate the recommendations and buy those machines. Once the system is up and running (hopefully in May), I will add more machines suggested by the community as time permits. The time window for suggestions will close at the end of February. Fire away! Regards, Carl-Daniel

7 8

GCC update broke AMD Fam10h boot
by Timothy Pearson 16 Mar '15

16 Mar '15

All, Just a heads up as there is no bugtracker for this project. GIT commit 53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2, breaks ramstage on AMD Fam10h systems (ramstage loads, sends its 0x39 POST code, but then goes into an infinite loop). Downgrading the GCC version repairs the boot failure. Not sure if you want to revert that commit until someone can figure out what changed to cause the problem. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

3 2

coreboot GSoC 2015 student application period
by Marc Jones 15 Mar '15

15 Mar '15

The GSoC student application window opens on Monday! 16 March: 19:00 UTC - Student application period opens. 27 March: 19:00 UTC - Student application deadline. Everything you need to know about coreboot GSoC 2015 is on this page: http://www.coreboot.org/GSoC Regards, Marc

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2015