coreboot January 2016

coreboot@coreboot.org

38 participants
74 discussions

HPET: Minimum Clock Ticks and HPET_MIN_TICKS
by Paul Menzel 30 Jan '16

30 Jan '16

Dear coreboot folks, thanks to Timothy Pearson’s patch set #13159 (southbridge/amd/sb700: Set HPET min tick value to RPR recommendation) [1] I became aware of the Kconfig option `HPET_MIN_TICKS`. It looks like quite some boards (southbridges) don’t set it and it then gets set to 0 in `src/arch/x86/acpi.c`. ``` 509 void acpi_create_hpet(acpi_hpet_t *hpet) 510 { 511 acpi_header_t *header = &(hpet->header); 512 acpi_addr_t *addr = &(hpet->addr); 513 514 memset((void *)hpet, 0, sizeof(acpi_hpet_t)); 515 516 /* Fill out header fields. */ 517 memcpy(header->signature, "HPET", 4); 518 memcpy(header->oem_id, OEM_ID, 6); 519 memcpy(header->oem_table_id, ACPI_TABLE_CREATOR, 8); 520 memcpy(header->asl_compiler_id, ASLC, 4); 521 522 header->length = sizeof(acpi_hpet_t); 523 header->revision = 1; /* Currently 1. Table added in ACPI 2.0. */ 524 525 /* Fill out HPET address. */ 526 addr->space_id = 0; /* Memory */ 527 addr->bit_width = 64; 528 addr->bit_offset = 0; 529 addr->addrl = CONFIG_HPET_ADDRESS & 0xffffffff; 530 addr->addrh = ((unsigned long long)CONFIG_HPET_ADDRESS) >> 32; 531 532 hpet->id = *(unsigned int*)CONFIG_HPET_ADDRESS; 533 hpet->number = 0; 534 hpet->min_tick = CONFIG_HPET_MIN_TICKS; 535 536 header->checksum = acpi_checksum((void *)hpet, sizeof(acpi_hpet_t)); 537 } ``` That’s the case on the ASRock E350M1. ``` $ more /tmp/hpet.dsl /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20160108-32 * Copyright (c) 2000 - 2016 Intel Corporation * * Disassembly of hpet.dat, Sat Jan 30 12:37:21 2016 * * ACPI Data Table [HPET] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "HPET" [High Precision Event Timer table] [004h 0004 4] Table Length : 00000038 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : 71 [00Ah 0010 6] Oem ID : "CORE " [010h 0016 8] Oem Table ID : "COREBOOT" [018h 0024 4] Oem Revision : 00000000 [01Ch 0028 4] Asl Compiler ID : "CORE" [020h 0032 4] Asl Compiler Revision : 00000000 [024h 0036 4] Hardware Block ID : 43538210 [028h 0040 12] Timer Block Register : [Generic Address Structure] [028h 0040 1] Space ID : 00 [SystemMemory] [029h 0041 1] Bit Width : 40 [02Ah 0042 1] Bit Offset : 00 [02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy] [02Ch 0044 8] Address : 00000000FED00000 [034h 0052 1] Sequence Number : 00 [035h 0053 2] Minimum Clock Ticks : 0000 [037h 0055 1] Flags (decoded below) : 00 4K Page Protect : 0 64K Page Protect : 0 Raw Table Data: Length 56 (0x38) 0000: 48 50 45 54 38 00 00 00 01 71 43 4F 52 45 20 20 // HPET8....qCORE 0010: 43 4F 52 45 42 4F 4F 54 00 00 00 00 43 4F 52 45 // COREBOOT....CORE 0020: 00 00 00 00 10 82 53 43 00 40 00 00 00 00 D0 FE // ......SC.@...... 0030: 00 00 00 00 00 00 00 00 // ........ ``` As Timothy did, I guess this should be fixed. How should that be done? 1. Define a default value in `src/arch/x86/Kconfig` similar to `HPET_ADDRESS` and allow an override `HPET_MIN_TICKS_OVERRIDE`? 2. Or does this need to be set in every southbridge? Thanks, Paul [1] https://review.coreboot.org/13159

1 0

New on blogs.coreboot.org: Announcing coreboot 4.3
by WordPress 29 Jan '16

29 Jan '16

1 0

Memory Initialization
by Simon Haynes 29 Jan '16

29 Jan '16

I am new to coreboot and would like to change some of the memory initialization code to recognize a currently unsupported 240-pin DDR3 module. The intention is to load coreboot on a Supermicro H8SCM motherboard. Can someone please help identify where the code is that performs the memory initialization. (reads the SPD, configures/trains memory, performs pattern tests and creates e820 map). Thank you Simon

1 0

Re: [coreboot] F2A85-M - Richland CPU support doesn't work.
by Loic 29 Jan '16

29 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 2016-01-29 14:19, Patrick Georgi a écrit : > 2016-01-28 14:22 GMT+01:00 Loic <hackurx(a)opensec.fr>: >> I have to apply the patch as an attachment for it to work. >> I modify the options in Kconfig because coreboot doesn't start quickly >> without this... > Thank you. > I pushed the patch to gerrit, split for CPU and mainboard: > https://review.coreboot.org/#/c/13510/ > https://review.coreboot.org/#/c/13511/ Thanks a lot. Loic -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQYcBAEBAgAGBQJWq3NUAAoJEOU2PAjT6toD1Ugv/j0d5Wj34Q5CCNWwaUtK0if6 m0zy0mwEHdy2LH5D8ZiWSw8M5Sb+URSf2H/hQiiGjk4FljyIc5V/aye0ZqrFXkvz UlkQVR54rzQ7MFuZFGi8qFqMM1eUdiiaxaYU1xP5TbM7m6bWKqGF7E3iueCWxwMD IOchIWvejRAGbDep4yL0B2seR2BqkVZlsfSV6weAjLOhe43vae2oa7BPc4VH9cFx 1RNObzrMxT2GEU7XUFWkkpCG7Hw+wkfMEARDB9YTlO86XD75lOhh82tAEg1Rj+TE c9ou3SlY5xVmKXGYImGZQ+1K6hgIgmNB/a72+r4z5OEKcU93ua7On30w2o7wa47y BQQ1peqPJHaN5sVS9qvnkrjtjbVi7+dqwKvdtgi6lYk+jkWdTUkTlfu5Kg4Ud10g 8J6ZGXrkuISLChYaAJ3kAu9gaXEYl8bOwuqWJPCVM3t19SMftJf1X/gGWFWl1ypa sCes0RF463+GMfTbJnIHJvxZda6dc8KNTalRWPLYVyXl5hM4vtoUhxH7yCATNOdq fj8N+pgDbzfYWqZyv4xxJxOBtaEZdNGl9xgx1V8pon/6u/bw7VAznixk+hf0uDL9 UrnKLMGVQAFgr3x2ExhO4hoLtPt5IJWRxUOGTKW8JFLlARkt53mfNjVjJ1tEy62Z kD2HQb7U2714dM1Id9fntvz+McgdQzbR5fx6G4CtkGycd9yYlkRvx+NvfAUczyDr jU3nmTIZX7MsgNm5hqizWHJTrJRnT5l4O4CDpaqBzMW5RghIUOTjSc1SNrpV0XQl eCRDhov0Fk32ejyA83l7/m+Nxb7thOmJYBnUVtfQegu7kRrfhu4UFa5oO21vyflq GZzqODT2l3BqqdT5Ak74C0602Eju0Vgycn0MEjj4YbLtJCG4t4tHS7xmWFmvjWh4 tnkL32WGI4UY4pGbriAEnaXY97YJBX68JjyPoAagvg8oBfzKN/WnZ1WNGceA1zfY AGcRct3hE+T7uiiueqLwPlF8N2cOND1Bc4qSBu+rm0eTX7HCgHVizYSoC3p8PJD5 xKmM6pl/qFwLXPBW23egHeiNcAE3sQ4xZbapurL1dAs9jiKdU1EzyeH7IbwKKyM6 ZAJlf2aPm4/rKqnzElGI7PNUCaj2OG6jhvOE9vqrtVWlOmx0zoshGg1XSreLe/hH m7kdR2TRVqcaiPGq7H7nX2rixfiWdB00Ev5U4bMf+svNu1H95/OMjwYggLGG8BJu ulKNZ21oIM3BVk7vbn1XLTjozPQzlU+MTv8er8mVB/2XGLAG5zinp6ACA/1zwKOH ejKk4AwsNRTUfGYb++xX7AgBRz9xY4Fn79l5GjzwlGRvvjKnBHrf+dzpenQ42+Vg yfYApeIwukIpeVWDnuFAv7AmiLhUHV/8CTeDtfaTDM+OQu8DkJorBl+h3hFEaJXu tDS30mwWopoJjqTmWIt2FfLDi/0yBtuur/tF9tiQ1atSXVoB15xJN1ph2ir5B5sT tsVdFFFAt8KvrnXhHhzMXv/tvMZ4KuQyvaJIFQCv+qDOX0BbGYLHiOKf0XWlOy/0 ejofZD6XOK2qKpWIjdYTOfsKxHk/DEnp3bT4vtsSJCTAnAi+qjfqfwmVDArojTFS D4Xs2yg9CPd1BzeMT6i6Cn4R4Ade8VAEumgZsZJkSQyeAUaCL/+GpKrSOqPmWcOj KgB9gsy1fl7ZqO92kh5RfTGMhuTHeLiAXZiLEXTQghLKbqz8RWQFii0LXI4/hutI HezS5Oy/AWWlpH+0+dt8oI9zrVEEhGeE0vkFaOQxbj/YzqxWGiUQWaukVjc+J4eO C4aDLE/Gl+rAzVT/XnbWcaaUj7HpOEKUUtyk8N9VAnhy/Eud48YlRARO3hHl9AWP yeq0Ap5I1L1ytvFH1e/m0BSuNp2kQn6SJiTx0dqs1gRluuHtSVaPRYvfPY5r0wlr HWi2FXuq9fceFo3Aus/DjP1vjbA9weKmKmm4501LGLFaIlxTljVGz/XritIfvh2b 0mC6g2x73dRtC6iolTSJId+ZRq2iq67utKKYNlGl6Q== =HRkd -----END PGP SIGNATURE-----

1 0

Re: [coreboot] F2A85-M - Richland CPU support doesn't work.
by Patrick Georgi 29 Jan '16

29 Jan '16

2016-01-28 14:22 GMT+01:00 Loic <hackurx(a)opensec.fr>: > I have to apply the patch as an attachment for it to work. > I modify the options in Kconfig because coreboot doesn't start quickly > without this... Thank you. I pushed the patch to gerrit, split for CPU and mainboard: https://review.coreboot.org/#/c/13510/ https://review.coreboot.org/#/c/13511/ > You can modify "Latest Known Good" for today in Asus F2A85-M ;) > https://www.coreboot.org/Supported_Motherboards The table on that page is auto-generated from status reports sent in via util/board_status/board_status.sh We can't modify the table without running that script on the hardware. Patrick

1 0

New on blogs.coreboot.org: coreboot changelog Jan 20 - Jan 26
by WordPress 28 Jan '16

28 Jan '16

1 0

ASUS KGPE-D16 Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 27 Jan '16

27 Jan '16

The ASUS KGPE-D16 fails verification as of commit a608969ebbc556499a20edbb25c2ef45a7434871 The following tests failed: BOOT_FAILURE Commits since last successful test: a608969 drivers/intel/fsp1_1: Enable builds without MRC cache See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

2 1

How to add an offset at the coreboot creation ?
by Jean Francois TRAP 26 Jan '16

26 Jan '16

Hello, I have a flash memory 16M. I would like coreboot position in the last 256K of memory. address : 0xFC0000 Here is my current coreboot.rom Coreboot.rom 16384 kB, bootblocksize 18487, romsize 16777216, offset 0x0 Alignment : 64 bytes Name Offset Type Size Fallback/romstage 0x0 stage 17490 Fallback/coreboot_ram 0x44c0 stage 85656 Config 0x193c0 raw 3682 (empty) 0x1a280 null 16651480 How to add an offset at the coreboot creation ? thanks for your help M. TRAP

3 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 25 Jan '16

25 Jan '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 7 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 7 of 7 defect(s) ** CID 1349857: Uninitialized variables (UNINIT) /src/soc/intel/skylake/smihandler.c: 355 in southbridge_smi_gpi() ________________________________________________________________________________________________________ *** CID 1349857: Uninitialized variables (UNINIT) /src/soc/intel/skylake/smihandler.c: 355 in southbridge_smi_gpi() 349 350 void __attribute__((weak)) 351 mainboard_smi_gpi_handler(const struct gpi_status *sts) { } 352 353 static void southbridge_smi_gpi(void) 354 { >>> CID 1349857: Uninitialized variables (UNINIT) >>> Declaring variable "smi_sts" without initializer. 355 struct gpi_status smi_sts; 356 357 gpi_clear_get_smi_status(&smi_sts); 358 mainboard_smi_gpi_handler(&smi_sts); 359 360 /* Clear again after mainboard handler */ ** CID 1349856: Uninitialized variables (UNINIT) /src/mainboard/google/cyan/spd/spd.c: 166 in set_dimm_info() ________________________________________________________________________________________________________ *** CID 1349856: Uninitialized variables (UNINIT) /src/mainboard/google/cyan/spd/spd.c: 166 in set_dimm_info() 160 break; 161 162 case 8: 163 log2_chips = 3; 164 break; 165 } >>> CID 1349856: Uninitialized variables (UNINIT) >>> Using uninitialized value "log2_chips". 166 dimm->bus_width = (uint8_t)(log2_chips + (spd[7] & 7) + 2 - 3); 167 } 168 169 void mainboard_save_dimm_info(struct romstage_params *params) 170 { 171 struct dimm_info *dimm; ** CID 1349855: Control flow issues (UNREACHABLE) /src/drivers/intel/fsp1_1/fsp_util.c: 44 in find_fsp() ________________________________________________________________________________________________________ *** CID 1349855: Control flow issues (UNREACHABLE) /src/drivers/intel/fsp1_1/fsp_util.c: 44 in find_fsp() 38 } fsp_id = { 39 .str_id = CONFIG_FSP_IMAGE_ID_STRING 40 }; 41 42 u32 *image_id; 43 >>> CID 1349855: Control flow issues (UNREACHABLE) >>> Since the loop increment is unreachable, the loop body will never execute more than once. 44 for (;;) { 45 /* Get the FSP binary base address in CBFS */ 46 fsp_ptr.u32 = fsp_base_address; 47 48 /* Check the FV signature, _FVH */ 49 if (fsp_ptr.fvh->Signature != 0x4856465F) { ** CID 1349854: Incorrect expression (UNUSED_VALUE) /src/drivers/intel/fsp1_1/fsp_util.c: 56 in find_fsp() ________________________________________________________________________________________________________ *** CID 1349854: Incorrect expression (UNUSED_VALUE) /src/drivers/intel/fsp1_1/fsp_util.c: 56 in find_fsp() 50 fsp_ptr.u8 = (u8 *)ERROR_NO_FV_SIG; 51 break; 52 } 53 54 /* Locate the file header which follows the FV header. */ 55 fsp_ptr.u8 += fsp_ptr.fvh->ExtHeaderOffset; >>> CID 1349854: Incorrect expression (UNUSED_VALUE) >>> Assigning value from "fsp_ptr.fveh->ExtHeaderSize" to "fsp_ptr.u8" here, but that stored value is overwritten before it can be used. 56 fsp_ptr.u8 += fsp_ptr.fveh->ExtHeaderSize; 57 fsp_ptr.u8 = (u8 *)ALIGN_UP(fsp_ptr.u32, 8); 58 59 /* Check the FFS GUID */ 60 if ((((u32 *)&fsp_ptr.ffh->Name)[0] != 0x912740BE) 61 || (((u32 *)&fsp_ptr.ffh->Name)[1] != 0x47342284) ** CID 1349860: Memory - corruptions (ARRAY_VS_SINGLETON) /src/soc/intel/skylake/romstage/spi.c: 34 in early_spi_read_wpsr() ________________________________________________________________________________________________________ *** CID 1349860: Memory - corruptions (ARRAY_VS_SINGLETON) /src/soc/intel/skylake/romstage/spi.c: 34 in early_spi_read_wpsr() 28 29 spi_init(); 30 31 /* sending NULL for spiflash struct parameter since we are not 32 * calling HWSEQ read_status() call via Probe. 33 */ >>> CID 1349860: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Taking address with "&rdsr" yields a singleton pointer. 34 ret = pch_hwseq_read_status(NULL, &rdsr); 35 if (ret) { 36 printk(BIOS_ERR, "SPI rdsr failed\n"); 37 return ret; 38 } 39 *sr = rdsr & WPSR_MASK_SRP0_BIT; 40 41 return 0; ** CID 1349859: Control flow issues (DEADCODE) /src/soc/intel/braswell/spi.c: 258 in spi_regs() ________________________________________________________________________________________________________ *** CID 1349859: Control flow issues (DEADCODE) /src/soc/intel/braswell/spi.c: 258 in spi_regs() 252 #if ENV_SMM 253 dev = PCI_DEV(0, LPC_DEV, LPC_FUNC); 254 #else 255 dev = dev_find_slot(0, PCI_DEVFN(LPC_DEV, LPC_FUNC)); 256 #endif 257 if (!dev) { >>> CID 1349859: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "%s: PCI device n...". 258 printk(BIOS_ERR, "%s: PCI device not found", __func__); 259 return NULL; 260 } 261 262 pci_read_config_dword(dev, SBASE, &sbase); 263 sbase &= ~0x1ff; ** CID 1349858: Memory - illegal accesses (OVERRUN) /src/soc/mediatek/mt8173/spi.c: 85 in mtk_spi_init() ________________________________________________________________________________________________________ *** CID 1349858: Memory - illegal accesses (OVERRUN) /src/soc/mediatek/mt8173/spi.c: 85 in mtk_spi_init() 79 unsigned int speed_hz) 80 { 81 u32 div, sck_ticks, cs_ticks, reg_val; 82 /* mtk spi HW just support bus 0 */ 83 assert(bus == 0); 84 struct mtk_spi_bus *slave = &spi_bus[bus]; >>> CID 1349858: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 1 48-byte elements at element index 1 (byte offset 48) by dereferencing pointer "slave". 85 struct mtk_spi_regs *regs = slave->regs; 86 87 if (speed_hz < SPI_HZ / 2) 88 div = div_round_up(SPI_HZ, speed_hz); 89 else 90 div = 1; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/coreboot?tab=overview To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&…

2 1

Re: [coreboot] Linux kernel as payload?
by John Lewis 24 Jan '16

24 Jan '16

Thank Ron! If anyone's interested, you can find the Buildroot/kernel configs and Jeltka script @ https://johnlewis.ie/buildroot-2014.08-config https://johnlewis.ie/linux-3.16.6-config https://johnlewis.ie/jeltka.sh It's out of date and could use some other improvements, but I'm sure it would save someone a lot of time getting a kernel payload working in under 3.5 megs size. John. On 2016-01-21 18:39, ron minnich wrote: > I think JELTKA is a model of how it can be done. Consider talking to > John Lewis. > > Ron, Satisfied JELTKA user. > > On Thu, Jan 21, 2016 at 9:58 AM Patrick Georgi via coreboot > <coreboot(a)coreboot.org> wrote: > >> 2016-01-21 18:49 GMT+01:00 Kitestramuort >> <kitestramuort(a)autistici.org>: >>> Can I compile it 64bit? >> As long as you keep the 32bit entry point around, yes (which I >> think >> is the default configuration for x86_64 kernels). >> In kconfig/menuconfig/..., select a linux payload, and point to the >> bzImage file. That should work (and this part of coreboot is pretty >> well testable with our QEmu targets, in case you want to try it out >> first). >> >>> Is there any further documentation on this? >> Sadly documentation is not a strength in this project. >> >>> I found something on the wiki >>> https://www.coreboot.org/Board:tyan/s2891#LAB_payload [1] >> The kexec information there is probably still useful, the buildrom >> stuff is horribly outdated. >> >> Patrick >> -- >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der >> Gesellschaft: Hamburg >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot [2] > > > Links: > ------ > [1] https://www.coreboot.org/Board:tyan/s2891#LAB_payload > [2] http://www.coreboot.org/mailman/listinfo/coreboot

2 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 January 2016