coreboot May 2015

coreboot@coreboot.org

46 participants
117 discussions

Cbfstool compilation error with gcc 5.1
by Anatol Pomozov 31 May '15

31 May '15

Hi I am trying to compile coreboot cbfstool on Arch where gcc 5.1 is used. And I see following compilation error. I wonder if it is coreboot or gcc issue. ==> Starting build()... make: Entering directory '/home/anatol/sources/archpackages/coreboot-utils-git/src/coreboot/util/cbfstool' mkdir -p ./ cc -D_FORTIFY_SOURCE=2 -D_DEFAULT_SOURCE -D_POSIX_C_SOURCE=200809L -Iflashmap -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -g3 -std=c99 -Werror -Wall -Wextra -Wcast-qual -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -c -o rmodule.o rmodule.c rmodule.c: In function ‘rmodule_create’: rmodule.c:286:29: error: ‘phdr’ may be used uninitialized in this function [-Werror=maybe-uninitialized] (phdr->p_vaddr + phdr->p_memsz))) { ^ rmodule.c:203:14: note: ‘phdr’ was declared here Elf64_Phdr *phdr; ^ cc1: all warnings being treated as errors Makefile:55: recipe for target 'rmodule.o' failed make: *** [rmodule.o] Error 1 make: Leaving directory '/home/anatol/sources/archpackages/coreboot-utils-git/src/coreboot/util/cbfstool' ==> ERROR: A failure occurred in build().

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 30 May '15

30 May '15

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 10 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 10 of 10 defect(s) ** CID 1302458: Control flow issues (DEADCODE) /src/cpu/amd/model_10xxx/powernow_acpi.c: 75 in write_pstates_for_core() ________________________________________________________________________________________________________ *** CID 1302458: Control flow issues (DEADCODE) /src/cpu/amd/model_10xxx/powernow_acpi.c: 75 in write_pstates_for_core() 69 /* Write PPC object */ 70 acpigen_write_PPC(pstate_num); 71 72 /* Write PSD indicating coordination type */ 73 if ((single_link) && (mctGetLogicalCPUID(0) & AMD_DR_GT_Bx)) { 74 /* Revision C or greater single-link processor */ >>> CID 1302458: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cpuid1 = cpuid(-2147483640);". 75 cpuid1 = cpuid(0x80000008); 76 acpigen_write_PSD_package(0, (cpuid1.ecx & 0xff) + 1, SW_ALL); 77 } 78 else { 79 /* Find the local APIC ID for the specified core ID */ 80 struct device* cpu; ** CID 1302457: Control flow issues (MISSING_RESTORE) /util/cbfstool/flashmap/fmap.c: 452 in fmap_append_area_test() ________________________________________________________________________________________________________ *** CID 1302457: Control flow issues (MISSING_RESTORE) /util/cbfstool/flashmap/fmap.c: 452 in fmap_append_area_test() 446 if ((*fmap)->nareas != 1) { 447 printf("FAILURE: failed to increment number of areas\n"); 448 goto fmap_append_area_test_exit; 449 } 450 451 status = pass; >>> CID 1302457: Control flow issues (MISSING_RESTORE) >>> Jumped to here, skipping restore. 452 fmap_append_area_test_exit: 453 return status; 454 } 455 456 static int fmap_find_area_test(struct fmap *fmap) 457 { ** CID 1302456: Error handling issues (NEGATIVE_RETURNS) /util/cbfstool/flashmap/fmap.c: 568 in fmap_find_test() ________________________________________________________________________________________________________ *** CID 1302456: Error handling issues (NEGATIVE_RETURNS) /util/cbfstool/flashmap/fmap.c: 568 in fmap_find_test() 562 printf("FAILURE: bsearch returned false positive\n"); 563 goto fmap_find_test_exit; 564 } 565 566 /* simple test case: fmap at (total_size / 2) + 1 */ 567 offset = (total_size / 2) + 1; >>> CID 1302456: Error handling issues (NEGATIVE_RETURNS) >>> "fmap_size(fmap)" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 568 memcpy(&buf[offset], fmap, fmap_size(fmap)); 569 570 if ((unsigned)fmap_find(buf, total_size - 1) != offset) { 571 printf("FAILURE: lsearch failed to find fmap\n"); 572 goto fmap_find_test_exit; 573 } ** CID 1302455: Null pointer dereferences (NULL_RETURNS) /util/cbfstool/partitioned_file.c: 204 in partitioned_file_reopen() ________________________________________________________________________________________________________ *** CID 1302455: Null pointer dereferences (NULL_RETURNS) /util/cbfstool/partitioned_file.c: 204 in partitioned_file_reopen() 198 partitioned_file_close(file); 199 return NULL; 200 } 201 202 const struct fmap_area *fmap_fmap_entry = 203 fmap_find_area(file->fmap, SECTION_NAME_FMAP); >>> CID 1302455: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "fmap_fmap_entry". 204 if ((long)fmap_fmap_entry->offset != fmap_region_offset) { 205 ERROR("FMAP's '%s' section doesn't point back to FMAP start (did something corrupt this file?)\n", 206 SECTION_NAME_FMAP); 207 partitioned_file_close(file); 208 return NULL; 209 } ** CID 1302454: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1302454: Memory - corruptions (OVERRUN) /util/cbfstool/flashmap/fmap.c: 342 in fmap_create_test() 336 uint64_t base = 0; 337 uint32_t size = 0x100000; 338 char name[] = "test_fmap"; 339 340 status = fail; 341 >>> CID 1302454: Memory - corruptions (OVERRUN) >>> Overrunning array "name" of 10 bytes by passing it to a function which accesses it at byte offset 31. 342 fmap = fmap_create(base, size, (uint8_t *)name); 343 if (!fmap) 344 return NULL; 345 346 if (memcmp(&fmap->signature, FMAP_SIGNATURE, strlen(FMAP_SIGNATURE))) { 347 printf("FAILURE: signature is incorrect\n"); ** CID 1302453: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 530 in fmap_flags_to_string_test() ________________________________________________________________________________________________________ *** CID 1302453: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 530 in fmap_flags_to_string_test() 524 } 525 free(my_str); 526 free(str); 527 528 status = pass; 529 fmap_flags_to_string_test_exit: >>> CID 1302453: Resource leaks (RESOURCE_LEAK) >>> Variable "my_str" going out of scope leaks the storage it points to. 530 return status; 531 532 } 533 534 static int fmap_find_test(struct fmap *fmap) 535 { ** CID 1302452: (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 530 in fmap_flags_to_string_test() /util/cbfstool/flashmap/fmap.c: 530 in fmap_flags_to_string_test() ________________________________________________________________________________________________________ *** CID 1302452: (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 530 in fmap_flags_to_string_test() 524 } 525 free(my_str); 526 free(str); 527 528 status = pass; 529 fmap_flags_to_string_test_exit: >>> CID 1302452: (RESOURCE_LEAK) >>> Variable "str" going out of scope leaks the storage it points to. 530 return status; 531 532 } 533 534 static int fmap_find_test(struct fmap *fmap) 535 { /util/cbfstool/flashmap/fmap.c: 530 in fmap_flags_to_string_test() 524 } 525 free(my_str); 526 free(str); 527 528 status = pass; 529 fmap_flags_to_string_test_exit: >>> CID 1302452: (RESOURCE_LEAK) >>> Variable "str" going out of scope leaks the storage it points to. 530 return status; 531 532 } 533 534 static int fmap_find_test(struct fmap *fmap) 535 { ** CID 1302451: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 207 in fmap_print() ________________________________________________________________________________________________________ *** CID 1302451: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 207 in fmap_print() 201 kv_pair_fmt(pair, "area_flags_raw", "0x%02x", 202 fmap->areas[i].flags); 203 204 /* Print descriptive strings for flags rather than the field */ 205 flags = fmap->areas[i].flags; 206 if ((str = fmap_flags_to_string(flags)) == NULL) >>> CID 1302451: Resource leaks (RESOURCE_LEAK) >>> Variable "pair" going out of scope leaks the storage it points to. 207 return -1; 208 kv_pair_fmt(pair, "area_flags", "%s", str); 209 free(str); 210 211 kv_pair_print(pair); 212 kv_pair_free(pair); ** CID 1302450: Security best practices violations (STRING_OVERFLOW) /src/drivers/intel/gma/acpi.c: 50 in drivers_intel_gma_displays_ssdt_generate() ________________________________________________________________________________________________________ *** CID 1302450: Security best practices violations (STRING_OVERFLOW) /src/drivers/intel/gma/acpi.c: 50 in drivers_intel_gma_displays_ssdt_generate() 44 char *ptr; 45 int kind; 46 kind = (conf->did[i] >> 8) & 0xf; 47 if (kind >= ARRAY_SIZE(names)) { 48 kind = 0; 49 } >>> CID 1302450: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 10 byte fixed-size string "name" by copying "names[kind]" without checking the length. 50 strcpy(name, names[kind]); 51 for (ptr = name; *ptr; ptr++); 52 *ptr++ = counters[kind] + '0'; 53 *ptr++ = '\0'; 54 counters[kind]++; 55 acpigen_write_device(name); ** CID 1256584: Error handling issues (CHECKED_RETURN) /src/ec/google/chromeec/ec_spi.c: 52 in crosec_spi_io() ________________________________________________________________________________________________________ *** CID 1256584: Error handling issues (CHECKED_RETURN) /src/ec/google/chromeec/ec_spi.c: 52 in crosec_spi_io() 46 } 47 48 static int crosec_spi_io(size_t req_size, size_t resp_size, void *context) 49 { 50 struct spi_slave *slave = (struct spi_slave *)context; 51 >>> CID 1256584: Error handling issues (CHECKED_RETURN) >>> Calling "spi_claim_bus" without checking return value (as is done elsewhere 4 out of 5 times). 52 spi_claim_bus(slave); 53 54 /* Allow EC to ramp up clock after being awaken. 55 * See chrome-os-partner:32223 for more details. */ 56 udelay(CONFIG_EC_GOOGLE_CHROMEEC_SPI_WAKEUP_DELAY_US); 57 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/1016?tab=overview To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&… .

1 0

New post published at blog.coreboot.org on May 28, 2015 at 11:17 pm
by WordPress 29 May '15

29 May '15

1 0

Lenovo n20p Chromebook: status update?
by Giuseppe Mazzotta 28 May '15

28 May '15

Hi there, I've read this thread http://www.coreboot.org/pipermail/coreboot/2014-September/078664.html started by John Lewis and followed by Aaron Durbin; I'd like to know what is the current status. As I understand it would be needed to do some wiring and use SPI to make proficient tests? Kind regards, -- Giuseppe

1 0

Re: [coreboot] Lenovo x230 - vgabios
by Paul Menzel 28 May '15

28 May '15

Dear Michael, Am Donnerstag, den 28.05.2015, 02:39 +0200 schrieb Michael Gerlach: > I've done that for revision I used and latest HEAD for both, x201 and > x230.. Thank you very much! commit d46ebfbac6ad8bf3a38639c00f6874ebf4c563d5 Author: Michael Gerlach <n3ph(a)terminal21.de> Date: Wed May 27 03:02:55 2015 +0200 lenovo/x201/4.0-9799-g075739e/2015-05-27T23:59:53Z commit b32b539b80921c85c54d89a069c661471cb4e343 Author: Michael Gerlach <n3ph(a)terminal21.de> Date: Thu May 28 01:47:59 2015 +0200 lenovo/x230/4.0-9799-g7b399b7/2015-05-27T23:38:30Z commit b48d383f87160b47db3251ccfb37ea2eb5d798c3 Author: Michael Gerlach <n3ph(a)terminal21.de> Date: Thu May 28 01:36:57 2015 +0200 lenovo/x230/4.0-9737-gf4f43f2/2015-05-27T23:35:38Z Unfortunately, I’m unable to locate the commits you used in the upstream repository. $ git show f4f43f2 fatal: ambiguous argument 'f4f43f2': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ git show 7b399b7 fatal: ambiguous argument '7b399b7': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ git show 075739e fatal: ambiguous argument '075739e': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' What commits do you have on top? Could you please upload results from commit, present in the upstream repository. Thanks, Paul PS: Looking at your timings, you could disable the PS/2 controller initialization as it times out taking over 500 ms. $ grep DRIVERS_PS2_KEYBOARD lenovo/x201/4.0-9799-g075739e/2015-05-27T23:59:53Z/config.txt CONFIG_DRIVERS_PS2_KEYBOARD=y $ more lenovo/x201/4.0-9799-g075739e/2015-05-27T23:59:53Z/coreboot_timestamps.txt […] 60:device initialization 3,055,712 (576) 70:device setup done 3,657,942 (602,229) […] Most payloads take care of this anyway.

1 0

Re: [coreboot] Lenovo x230 - vgabios
by Michael Gerlach 27 May '15

27 May '15

Hi all! Long time since i started this topic! As Zaolin mentioned quite some posts earlier UEFITool is the way to go to get a working vbios option rom. I got exactly the same file as zaolin attached in the post before.. And this works wonderful... For debug and documentation reasons i will attach the working config, vgabios, pxe rom image (with disabled BANNER_TIMEOUT), the final cbmem boot log, the old vgabios which i've dumped via /sys/devices and the smaller one which i got from /proc/iomem... Big thx to all of you for taking time to point me in the right direction... And sorry for the noise ;) best regards, n3ph On 05/27/15 17:46, Zaolin wrote: > Hi Michael, > > again please use the UEFI Tool. Your VGA BIOS contains self modifying > code and > that's why the extraction inside the Linux does not work! > I attached the Intel VGA BIOS for the X230 as reference. > > Regards Zaolin >> Since SeaBios seems to be bothered about the checksum of the oprom i >> tried to disable the checksum_check via: >> >> ./build/cbfstool build/coreboot.rom add-int -i 0 -n >> etc/optionroms-checksum >> >> But it seems like there is sth. wrong with that vbios.. Multi-coloured >> stripes and strange distortions until kernel boots... >> >> I guess i start using UEFITool to re-extract it... >> >> >> best regards, >> >> n3ph >> >> >> On 05/27/15 16:47, Michael Gerlach wrote: >> > Here we go... >> >> > I guess cbmem.log should be enough? >> >> > Attached one boot with CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT=y set >> > and one with CONFIG_VGA_ROM_RUN=y and CONFIG_S3_VGA_ROM_RUN=y.. >> >> > MAINBOARD_DO_NATIVE_VGA_INIT does nothing - display is initialzed >> > as recently as kernel is already loaded and display driver starts >> > working. >> >> > VGA_ROM_RUN at least corectly initialize the display, but - as >> > already mentioned - no output from coreboot nor seabios is >> > displayed - just a white blinking cursor until kernel gets loaded.. >> > I guess i have no timeout in grub2 - so this might be the reason >> > why i also see no output from grub.. >> >> >> >> > best regards, >> >> >> > n3ph >> >> >> >> >> >> >> > > -- Bitte benutzt GPG: http://de.wikipedia.org/wiki/GNU_Privacy_Guard

2 1

Re: [coreboot] x230 - vgabios
by Michael Gerlach 27 May '15

27 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Patrick! Uhm - I do not explicitly compressed it. I just added it to config.. Extracted it via echo 1 > /sys/devices/pci0000\:00/0000\:00\:02.0/rom cp /sys/devices/pci0000\:00/0000\:00\:02.0/rom vgabios.bin How to check if it's compressed? Best regards, n3ph On 05/23/15 03:22, Patrick Georgi wrote: > 2015-05-23 1:06 GMT+02:00 Michael Gerlach <n3ph(a)terminal21.de>: >> GET_VBIOS: 7b46 3714 8b a2 e9 > >> printk(BIOS_DEBUG, "GET_VBIOS: %x %x %x %x %x\n", >> oprom->signature, pcir->vendor, pcir->classcode[0], >> pcir->classcode[1], pcir->classcode[2]); >> >> But Signature should be 0x55aa: > Just to double check: did you add the vgabios with or without > compression? coreboot only supports uncompressed vgabios images > (while seabios allows them compressed as well, if the name > matches) > > > Patrick > - -- Bitte benutzt GPG: http://de.wikipedia.org/wiki/GNU_Privacy_Guard -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVX+XmAAoJEE1l5S41evqaQRcH/2fBtgPODZzmDNHX03Vi8UJY bRXIg4RwGo2lbfaepxfJuyi0EH5Rv5QAOCMBB6Eh7c6Tovf+wa4kbZivc+4Qn/k2 zBb/qvURAmthHQzqVuRUBL5zI5SRL/KbcGX5l7jkjx+d1KVLlfZR+rT4KHHOVJLF FccnwT0P2OrSeyLMV31pCqkbK5Nf9lVsIRAJoQtcWwlaClTiaIUiji0TzJwjoJ5C JibGCNCRJ4yjgCTty4EwmRxrUYvBEjFg87g33HhE61Ya73Dh4xcetEC2y/stdnMs U4LV/Kzb/oDfOdmy6Em0+XnDAFTaSxkqTqU2V/zBGsZACNwj4fce4QrNi35DJpE= =DNks -----END PGP SIGNATURE-----

3 8

Report on Chrome OS upstreaming
by Patrick Georgi 26 May '15

26 May '15

In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. As a result, upstream benefits from lots of new features and hardware support that was introduced during Chrome OS development, some of which warrant a shout out: First, new hardware support: There’s MIPS support, and on the ARM side we now run on SoCs by Broadcom, Marvell, Qualcomm, and RockChip. In terms of infrastructure, the biggest single item that came up during upstreaming is probably a safe method to declare the memory map on devices. Compared to x86, most architectures that prospered in embedded applications have a more complicated view on memory, so more care is required there. Looking at files like src/soc/nvidia/tegra132/include/soc/memlayout.ld, it becomes clear what kind of memory is available for which purpose on that SoC. In addition to that, there are efforts to make Chrome OS’ verified boot available as an option in upstream coreboot, and also to update the flash image format to allow for safer incremental updates. One thing to note is that significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip. Welcome to coreboot! In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores

1 0

grub2 coreboot
by sibu 26 May '15

26 May '15

Greetings, I a attempting to build coreboot with grub2 payload. The host runs fedora linux. I used the Kconfig menu to select GRUB2 as coreboot payload and run make crossgcc succcesfully.. On runing the next etep -make grub2 from git is downloaded but the build fails on the ./configure of the downloaded grub2 as follows:- ############### configure error qemu powerpc-ieee1275 coreboot and longson ports need unifonts, ############### I checked the hosts' installation and I have unicode fonts installed. I changed host with the same fesult. Help would be appreciated sincerely Sibu incidently when running ./configure --with-platform=coreboot. grub-2.02beta2 failed also though the older Grub-2.00 built succesfully. I am unclear if the latter is too old for using as coreboot payload in the corrent instance and if not how to go abot embedding it in the downloaded coreboot distribution from the current git repo.

2 1

coreboot grub2 payload wont build
by sibu 25 May '15

25 May '15

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 2015