coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Lenovo Thinkpad Yoga 11e (1st Gen, Win10 variant)
by Christopher Grossarth 20 Mar '17

20 Mar '17

Hello All, I have been exploring coreboot, and have successfully built and flashed it on a MacBook 2,1. Initially I was using Libreboot, but wanted more control over the end result. I bought a Lenovo ChromeBook Yoga 11e 1st Gen), but swiftly returned it after I realized the product description on Lenovo's page mislabeled it as having SSD and RAM modules. The ChromeBook version has eMMC and soldered on RAM. The Windows 10 version of the same variety (Intel Celeron N2930) has a SSD and a replaceable/upgradeable RAM module. The ChromeBook variant is codenamed Glimmer. I would like to know what steps would be necessary to build and flash coreboot onto the Win10 board. Most importantly, how would I go about extracting the information so that I can edit the Glimmer config overlays to reflect the hardware config in the Win10 variant? Many Thanks in advance, C Grossarth.

1 0

Re: [coreboot] Lenovo Thinkpad X201: recipe for target 'add_intel_firmware' failed
by Sam Kuper 19 Mar '17

19 Mar '17

On 19/03/2017, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > I am trying to build Coreboot for the X201, and to improve the > Coreboot wiki's X201 page as I go along. > > I am presently following the instructions at this permalink: > https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24764#Meth… > > [...] > > Everything went fine, so far, until this step: > https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24764#Comp… I tracked down the source of the error. The instructions here ( https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24764#Extr… ) specify that the "descriptor" and "Management Engine" regions should be extracted to the following directory: coreboot/3rdparty/mainboard/lenovo/x201/ However, the Coreboot build process instead expects to find those extracts in this directory: coreboot/3rdparty/blobs/mainboard/lenovo/x201/ After moving the extracted files from the former directory to the latter, the build proceeds without errors. I will amend the instructions in the wiki's X201 page to specify extraction of those regions to the latter directory, instead of the former.

1 0

Lenovo Thinkpad X201: recipe for target 'add_intel_firmware' failed
by Sam Kuper 19 Mar '17

19 Mar '17

I am trying to build Coreboot for the X201, and to improve the Coreboot wiki's X201 page as I go along. I am presently following the instructions at this permalink: https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24764#Meth… (I decided to skip the step to neuter the ME: https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24764#Neut… . Maybe I will try neutering the X201's ME another day, but first of all I would like to at least achieve Coreboot running on the X201.) Everything went fine, so far, until this step: https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24764#Comp… Let me describe how I attempted to implement that step. I ran `make distclean`. I ran `make nconfig`, and selected: - "Lenovo" under Mainboard > Mainboard vendor - "ThinkPad X201 / X201s / X201t" under Mainboard > Mainboard model - "Add Intel descriptor.bin file" under Chipset - "Add Intel ME/TXE firmware" under Chipset Then I pressed F9 ("Exit") and saved the config to the default location ( coreboot/.config ). Then I ran `make`, which seemed to be going fine until the following output: Compile IFDTOOL HOSTCC util/ifdfake/ifdfake DD Adding Intel Firmware Descriptor src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for target 'add_intel_firmware' failed make: *** [add_intel_firmware] Error 1 Can anyone suggest how to overcome this error? I have attached the .config generated by `make nconfig`, and the full output of `make`, in case that is useful. Many thanks!

1 0

Re: [coreboot] iPXE as payload?
by Piotr Król 19 Mar '17

19 Mar '17

On 03/19/2017 01:46 AM, Idwer Vollering wrote: > 2017-03-19 1:24 GMT+01:00 Gert Menke <gert(a)menke.ac>: >> Hi Martin, Hi Idwer, >> >> thanks for your reply. >> >> On 2017-03-19 00:59, Martin Roth wrote: >>> >>> This will build iPXE option rom into the coreboot.rom file. >> >> >> Which is exactly what I do not want. >> It consumes a few seconds on every boot, which is totally unnecessary, >> because I very rarely want to boot over network. That's why I'd rather have >> iPXE as a payload than as an option rom. I think this *should* be possible, >> because you can apparently run iPXE from GRUB, too. But it would be nicer to >> have it in flash than on disk. We solved that for PC Engines APU2 SeaBIOS some time ago. IIRC What you have to do is not run init_optionrom in optionroms.c for iPXE. This not run option rom at boot but makes it still visible in SeaBIOS menu. We have external switch to enable/disable that behavior. I believe this was the change: https://github.com/pcengines/seabios/commit/ac6d3e213a3867bd586b62924b8255d… Best Regards, -- Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com

2 2

checkpatch: Question regarding asmlinkage and storage class
by Paul Menzel 19 Mar '17

19 Mar '17

Dear checkpatch developers, The coreboot project started using checkpatch.pl, and now some effort is going into fixing issues pointed out by `checkpatch.pl`. The file `src/arch/x86/acpi_s3.c` in coreboot contains the code below. ``` 205 void (*acpi_do_wakeup)(uintptr_t vector, u32 backup_source, u32 backup_target, 206 u32 backup_size) asmlinkage = (void *)WAKEUP_BASE; ``` The warning is > WARNING: storage class should be at the beginning of the declaration which raised the question below [2]. > And I am waiting for someone to answer why checkpatch.pl claims > asmlinkage as a storage-class in the first place. In coreboot the macro is defined similarly to Linux. ``` #define asmlinkage __attribute__((regparm(0))) #define alwaysinline inline __attribute__((always_inline)) ``` In Linux, commit 9c0ca6f9 (update checkpatch.pl to version 0.10) seems to have introduced the check. The commit message contains “asmlinkage is also a storage type”. Furthermore, `checkpatch.pl` doesn’t seem to warn about the code below. ``` void __attribute__((weak)) mainboard_suspend_resume(void) ``` This raises the question below. > It appears coreboot proper mostly followed this placement for > function attributes before. It would be nice if we were consistent, > specially if checkpatch starts to complaint about these. Is there another reason, besides not having that implemented? I am looking forward to your answers. Kind regards, Paul [1] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@205 [2] https://review.coreboot.org/18865/ [3] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@244

2 2

Re: [coreboot] Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom
by Gailu Singh 19 Mar '17

19 Mar '17

Failing grub code ------------------------------------------ static void init_cbfsdisk (void) { grub_uint32_t ptr; struct cbfs_header *head; ptr = *(grub_uint32_t *) 0xfffffffc; head = (struct cbfs_header *) (grub_addr_t) ptr; grub_dprintf ("cbfs", "head=%p\n", head); /* coreboot current supports only ROMs <= 16 MiB. Bigger ROMs will have problems as RCBA is 18 MiB below end of 32-bit typically, so either memory map would have to be rearranged or we'd need to support reading ROMs through controller directly. */ if (ptr < 0xff000000 || 0xffffffff - ptr < (grub_uint32_t) sizeof (*head) + 0xf || !validate_head (head)) return; ------------------------------------------ On Sun, Mar 19, 2017 at 11:47 AM, Gailu Singh <gailu96(a)gmail.com> wrote: > Hi Experts, > > On Intel Leafhill board grub fails to find cbfsdisk. We tried to debug and > found that cbfs header address validation fails. > > According to https://github.com/mrnuke/coreboot/blob/master/ > documentation/cbfs.txt, > "A pointer to the location of the header will be located at offset -4 from > the end of the ROM. This translates to address 0xFFFFFFFC on a normal x86 > system. The pointer will be to physical memory somewhere between - > 0xFFFFB000 and 0xFFFFFFF0". > > > We checked the coreboot.rom in hex editor and address in last 4 bytes is > all ones (FFFFFFFF) as a result grub is not able to find cbfs header. > > > We have earlier used coreboot on baytrail and in the coreboot.rom cbfs > header address in last 4 byte was a valid pointer. > > > What is the location grub can find cbfs header on this board? > >

1 0

Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom
by Gailu Singh 19 Mar '17

19 Mar '17

Hi Experts, On Intel Leafhill board grub fails to find cbfsdisk. We tried to debug and found that cbfs header address validation fails. According to https://github.com/mrnuke/coreboot/blob/master/documentation/cbfs.txt, "A pointer to the location of the header will be located at offset -4 from the end of the ROM. This translates to address 0xFFFFFFFC on a normal x86 system. The pointer will be to physical memory somewhere between - 0xFFFFB000 and 0xFFFFFFF0". We checked the coreboot.rom in hex editor and address in last 4 bytes is all ones (FFFFFFFF) as a result grub is not able to find cbfs header. We have earlier used coreboot on baytrail and in the coreboot.rom cbfs header address in last 4 byte was a valid pointer. What is the location grub can find cbfs header on this board?

1 0

Re: [coreboot] iPXE as payload?
by Gert Menke 19 Mar '17

19 Mar '17

Hi Martin, thanks for your reply. On 2017-03-19 00:59, Martin Roth wrote: > This will build iPXE option rom into the coreboot.rom file. Which is exactly what I do not want. It consumes a few seconds on every boot, which is totally unnecessary, because I very rarely want to boot over network. That's why I'd rather have iPXE as a payload than as an option rom. I think this *should* be possible, because you can apparently run iPXE from GRUB, too. But it would be nicer to have it in flash than on disk. Gert

2 1

Re: [coreboot] Conventions for describing flash memory layouts
by Patrick 'P. J.' McDermott 19 Mar '17

19 Mar '17

On 2017-03-18 at 18:00, Sam Kuper wrote: > The page https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24709#Flas… > says: > > > The flash memory in the X201 is divided into roughly 4 parts: > > > > - Descriptor (12K) > > - ME firmware (5M-12K) > > - Rewriteable flash (3M-96K) > > - Locked bootblock (96K) > > I guess that "K" refers to kibibytes and that "M" refers to mebibytes. Correct. > I also guess that the values in parentheses refer to the sizes of the > corresponding occupants of the flash memory, with the "-" symbol > representing "minus". This was not my first guess, but is the one that > seems to make the most sense. I'm not familiar with Ibex Peak's standard flash layout, but this sounds correct. The 12-KiB "Descriptor" should contain both the Intel Flash Descriptor and the Gigabit Ethernet Region. And the region sizes by that math add up to 8 MiB, which sounds right. -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/

2 1

iPXE as payload?
by Gert Menke 18 Mar '17

18 Mar '17

Hi, I would like to use iPXE as a secondary payload (rather than as option rom). The advantage would be that iPXE would not need to be loaded on every boot, but I could still choose it in the SeaBIOS boot menu when I want to use it. Is this possible? If so, how? Thanks Gert

2 1

← Newer
1
...
13
14
15
16
17
18
19
...
27
Older →

Jump to page:

2025

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 2017