coreboot January 2018

coreboot@coreboot.org

60 participants
155 discussions

[off topic] Opteron CPU missing chips on the bottom
by Taiidan＠gmx.com 30 Jan '18

30 Jan '18

I purchased a used g34 opteron off of fleabay (sold as working with no mention of this) and I noticed that it is missing some of the bits on the bottom and that most of them are crooked, I haven't tried it in my system yet and I am wondering should return it? or if there isn't any much risk of it damaging my (expensive kgpe-d16) motherboard and I should see if it works? I got it for half the usual price....guess I should have asked for photos. I noticed many CPU's sold on ebay have this issue (in those cases they mentioned it) but I can't understand how it happens, for instance I noticed a 6386 for sale where they mentioned that it was missing a few and because of that it doesn't work in a dual socket configuration.

1 0

Re: [coreboot] [ haswell i7-4600] Why does accessing data in MCHBAR hang the boar?
by Zheng Bao 30 Jan '18

30 Jan '18

I keep debugging and find out the MCHBAR+0x5400 - MCHBAR+0x7FFC can be accessed. The address below 0x5400 can cause hang. Zheng ________________________________ From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zheng Bao <fishbaoz(a)hotmail.com> Sent: Monday, January 29, 2018 11:03 AM To: coreboot(a)coreboot.org; Matt DeVillier; Nico Huber Subject: [coreboot] [ haswell i7-4600] Why does accessing data in MCHBAR hang the boar? After the MRC.bin is loaded and run, the board hang at accessing data in MCHBAR32. If I move MCHBAR32 backward before the MRC.bin runs, it still hangs. It seems has nothing to do with MRC.bin, does it? /* For reference print the System Agent version * after executing the UEFI PEI stage. */ post_code(0xb1); u32 version = MCHBAR32(0x5034); //<-------hang here post_code(0x1b); printk(BIOS_DEBUG, "System Agent Version %d.%d.%d Build %d\n", version >> 24 , (version >> 16) & 0xff, (version >> 8) & 0xff, version & 0xff); Zheng ------------------ coreboot-4.6-894-ga26344d-dirty Wed Jan 24 05:38:45 UTC 2018 romstage starting... Disabling Watchdog reboot... done. SMBus controller enabled. dimm: 00.0: 50 00: 92 10 0b 03 03 19 00 01 03 52 01 08 0c 00 3e 00 10: 69 78 69 30 69 11 20 89 00 05 3c 3c 00 f0 83 81 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 11 21 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 01 98 04 11 41 4f 1a 2d f8 85 10 80: 48 50 35 37 32 32 39 33 2d 44 38 38 2d 45 4c 43 90: 57 47 00 20 02 fe 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5a b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Setting up static northbridge registers... done. Initializing Graphics... Back from haswell_early_initialization() CPU id(40651) ucode:0000001c Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz AES supported, TXT supported, VT supported PCH type: LP Premium, device id: 9c43, rev id 4 Starting UEFI PEI System Agent ___ CBFS: 'Master Header Locator' located CBFS at [300100:3fffc0) CBFS: Locating 'mrc.bin' CBFS: Found @ offset 9fec0 size 2e6e4 System Agent: Starting up... System Agent: Initializing PCH install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845} install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276} System Agent: Initializing PCH (SMBUS) System Agent: Initializing PCH (USB) System Agent: Initializing PCH (SA Init) System Agent: Initializing PCH (Me UMA) System Agent: Initializing Memory System Agent: Done. Sanity checking heap.

1 0

Re: [coreboot] Power off in Coreboot?
by David Hendricks 29 Jan '18

29 Jan '18

On Mon, Jan 29, 2018 at 1:59 PM, Julius Werner <jwerner(a)chromium.org> wrote: > In grepping the sources I see the API is provided and only used in a >> handful of cases, mainly x86. >> >> On an ARMv8 target is there a power-off use-case for Coreboot? >> This is strictly from Coreboot perspective, not Depthcharge. >> > > You're right, there is no globally standardized power off API in coreboot, > it's only implemented internally by select chipsets. There is no ARM target > that implements something like this at the moment, because they don't > really need to. > Indeed, hlt() is just an infinite loop as currently implemented on aarch64 and that's only used if CONFIG_FATAL_ASSERTS is set as a debug option. I think the prevailing wisdom is that coreboot always has to try to load the payload. An error path that shuts down the machine isn't very helpful to a user, though perhaps that is not always true if we can log an error (e.g. to RW_ELOG on boot ROM) and the user can retrieve it out-of-band (systems with a BMC, etc).

1 0

Power off in Coreboot?
by mturney＠codeaurora.org 29 Jan '18

29 Jan '18

Folks, We are working through the PMIC requirements for Coreboot on our hardware. I understand the need for Coreboot to command a reboot, e.g. VerStage detects FW_A is bad and wants to try FW_B. What is not clear is what is the use-case for Coreboot to command a power-off. In grepping the sources I see the API is provided and only used in a handful of cases, mainly x86. On an ARMv8 target is there a power-off use-case for Coreboot? This is strictly from Coreboot perspective, not Depthcharge. Cheers, T.mike

2 1

[ haswell i7-4600] Why does accessing data in MCHBAR hang the boar?
by Zheng Bao 29 Jan '18

29 Jan '18

After the MRC.bin is loaded and run, the board hang at accessing data in MCHBAR32. If I move MCHBAR32 backward before the MRC.bin runs, it still hangs. It seems has nothing to do with MRC.bin, does it? /* For reference print the System Agent version * after executing the UEFI PEI stage. */ post_code(0xb1); u32 version = MCHBAR32(0x5034); //<-------hang here post_code(0x1b); printk(BIOS_DEBUG, "System Agent Version %d.%d.%d Build %d\n", version >> 24 , (version >> 16) & 0xff, (version >> 8) & 0xff, version & 0xff); Zheng ------------------ coreboot-4.6-894-ga26344d-dirty Wed Jan 24 05:38:45 UTC 2018 romstage starting... Disabling Watchdog reboot... done. SMBus controller enabled. dimm: 00.0: 50 00: 92 10 0b 03 03 19 00 01 03 52 01 08 0c 00 3e 00 10: 69 78 69 30 69 11 20 89 00 05 3c 3c 00 f0 83 81 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 11 21 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 01 98 04 11 41 4f 1a 2d f8 85 10 80: 48 50 35 37 32 32 39 33 2d 44 38 38 2d 45 4c 43 90: 57 47 00 20 02 fe 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5a b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Setting up static northbridge registers... done. Initializing Graphics... Back from haswell_early_initialization() CPU id(40651) ucode:0000001c Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz AES supported, TXT supported, VT supported PCH type: LP Premium, device id: 9c43, rev id 4 Starting UEFI PEI System Agent ___ CBFS: 'Master Header Locator' located CBFS at [300100:3fffc0) CBFS: Locating 'mrc.bin' CBFS: Found @ offset 9fec0 size 2e6e4 System Agent: Starting up... System Agent: Initializing PCH install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845} install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276} System Agent: Initializing PCH (SMBUS) System Agent: Initializing PCH (USB) System Agent: Initializing PCH (SA Init) System Agent: Initializing PCH (Me UMA) System Agent: Initializing Memory System Agent: Done. Sanity checking heap.

1 0

Re: [coreboot] BDX-DE PCI init fail
by David Hendricks 27 Jan '18

27 Jan '18

On Fri, Jan 26, 2018 at 12:23 AM, Hilbert Tu(杜睿哲_Pegatron) < Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi guys, > > > > Sorry for the late. I spent some time try to use U-Boot as payload but > still get infinite reboot…maybe wrong TSC clock frequency in my dts file. > > About using the Grub2 as payload, it is now working after I modify > “–unit=1” to “—unit=0” :P That’s why it hangs… > > Thanks for all your help. > I'm happy to hear of your success! It will be great if you figure out the issue with the u-boot payload as well. >

1 0

Re: [coreboot] [flashrom] x1 Carbon 1st Gen Boots to Black Screen
by Nico Huber 27 Jan '18

27 Jan '18

Hi, the coreboot mailing list is a much better place for this, let's move it there. On 27.01.2018 11:13, realraw(a)tuta.io wrote: > Followed the coreboot wiki entry perfectly, and had no issues reading > the flash chip. That wiki page seems to mention outdated .config settings. Generally I'd advice to start with a clean config (e.g. make distclean), only select your mainboard and leave everything else at the defaults. This won't give you maximum features but is most likely to show something on the screen ;) > > The 4MB Bios chip in my x1 differs from the Wiki Entry: > > Found Micron/Numonyx/ST flash chip "N25Q032..3E" (4096 kB, SPI) on > linux_spi. > > Not sure if that impacts anything, however booting I am faced with a > Black Screen. Fan is not running at all, and appears nothing is > happening. If it's not about some misconfiguration or the VBIOS, another possible issue is that coreboot doesn't know your RAM configuration. The X1 has its RAM soldered to the mainboard instead of DIMMs. The latter would have SPD EEPROMs storing information about the RAM but with soldered- down RAM, that information has to be added to coreboot. In mainboard_get_spd() (src/mainboard/lenovo/x1_carbon_gen1/romstage.c) there are two GPIOs checked. I'd first try to find out the state of these GPIOs and see if coreboot already knows that configuration. When you reflash your backup and boot with the vendor BIOS, please run `inteltool -g` (see util/inteltool/ in the coreboot tree) and attach the output. > > I found this link as well: > http://coreboot.coreboot.narkive.com/zUOsG1zN/lenovo-x1-carbon-3460-screen-… > > Flashed the rom at the end of the suggested mailing list comment, and > still black screen. > > I have included the vbios in my build, so I'm not sure what's wrong. Many things can go wrong with a VBIOS. It's generally safer to use coreboot's native graphics init (or libgfxinit) for the first coreboot build because you can't (mis)configure anything. Nico

1 0

Re: [coreboot] [Haswell i7-4600U]: How can I decide which MRC.bin match my board
by Zheng Bao 27 Jan '18

27 Jan '18

Plus, my board uses SODIMM, from which I assume System Agent should get SPD data. Is the grabbing data from SPD in blob? I can not dump the SPD out, can I? Zheng ________________________________ From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zheng Bao <fishbaoz(a)hotmail.com> Sent: Saturday, January 27, 2018 4:47 AM To: Nico Huber; Robert Reeves Cc: Matt DeVillier; coreboot(a)coreboot.org Subject: Re: [coreboot] [Haswell i7-4600U]: How can I decide which MRC.bin match my board I traced the code more and found the accessing data in MCHBAR would hang the board. Just hang, not reboot. Even if I move the accessing backward to haswell_setup_bars, it hangs as well. Why? My board also has a superio(or EC?) IT8772, which I assume doesnt make this problem. Thanks. Zheng ________________________________ From: Nico Huber <nico.h(a)gmx.de> Sent: Friday, January 26, 2018 2:15 PM To: Zheng Bao; Robert Reeves Cc: coreboot(a)coreboot.org Subject: Re: [coreboot] [Haswell i7-4600U]: How can I decide which MRC.bin match my board Hi Zheng, On 24.01.2018 16:12, Zheng Bao wrote: > After extract the shellball of chromebook, how can I know what the > processor exactly is? I don't know the blob for Haswell very well. But here's what I know about other blobs: * Sandy/Ivy Bridge mrc.bin: This one seems to run on every CPU so far. * FSP is not built for specific SKUs. The code is supposed to work on any, I guess. But the releases are only validated for specific SKUs. So it's not unlikely that a blob you extracted from a Chromebook firm- ware "should" run with any Haswell CPU. But still it could make trouble with your CPU, if nobody tested it before in that combination. As you have very limited output from the blob about the failure. I wonder why you suspect the blob itself to be the problem? other things could go wrong as well (e.g. gathering data from SPDs). Also, I'd first check that your revision of coreboot works together with that specific blob on any board (e.g. the original Chromebook). Nico

1 0

Re: [coreboot] [Haswell i7-4600U]: How can I decide which MRC.bin match my board
by Nico Huber 27 Jan '18

27 Jan '18

Hi Zheng, On 24.01.2018 16:12, Zheng Bao wrote: > After extract the shellball of chromebook, how can I know what the > processor exactly is? I don't know the blob for Haswell very well. But here's what I know about other blobs: * Sandy/Ivy Bridge mrc.bin: This one seems to run on every CPU so far. * FSP is not built for specific SKUs. The code is supposed to work on any, I guess. But the releases are only validated for specific SKUs. So it's not unlikely that a blob you extracted from a Chromebook firm- ware "should" run with any Haswell CPU. But still it could make trouble with your CPU, if nobody tested it before in that combination. As you have very limited output from the blob about the failure. I wonder why you suspect the blob itself to be the problem? other things could go wrong as well (e.g. gathering data from SPDs). Also, I'd first check that your revision of coreboot works together with that specific blob on any board (e.g. the original Chromebook). Nico

2 1

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

26 Jan '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 9 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 4 of 4 defect(s) ** CID 1385420: Null pointer dereferences (REVERSE_INULL) /3rdparty/vboot/firmware/lib/region-init.c: 45 in VbGbbReadHWID() ________________________________________________________________________________________________________ *** CID 1385420: Null pointer dereferences (REVERSE_INULL) /3rdparty/vboot/firmware/lib/region-init.c: 45 in VbGbbReadHWID() 39 struct vb2_shared_data *sd = vb2_get_sd(ctx); 40 41 if (!max_size) 42 return VBERROR_INVALID_PARAMETER; 43 *hwid = '\0'; 44 StrnAppend(hwid, "{INVALID}", max_size); >>> CID 1385420: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "ctx" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 45 if (!ctx) 46 return VBERROR_INVALID_GBB; 47 48 if (0 == sd->gbb->hwid_size) { 49 VB2_DEBUG("VbHWID(): invalid hwid size\n"); 50 return VBERROR_SUCCESS; /* oddly enough! */ ** CID 1385419: Memory - corruptions (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 1265 in cru_register_save() ________________________________________________________________________________________________________ *** CID 1385419: Memory - corruptions (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 1265 in cru_register_save() 1259 1260 void cru_register_save(void) 1261 { 1262 int i; 1263 1264 for (i = 0; i <= CRU_SDIO0_CON1; i = i + 4) >>> CID 1385419: Memory - corruptions (OVERRUN) >>> Overrunning array "store_cru" of 355 4-byte elements at element index 355 (byte offset 1420) using index "i / 4" (which evaluates to 355). 1265 store_cru[i / 4] = mmio_read_32(CRU_BASE + i); 1266 } 1267 1268 void cru_register_restore(void) 1269 { 1270 int i; ** CID 1385418: Memory - illegal accesses (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 1296 in cru_register_restore() ________________________________________________________________________________________________________ *** CID 1385418: Memory - illegal accesses (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 1296 in cru_register_restore() 1290 * CRU_GLB_CNT_TH and CRU_CLKSEL_CON97~CRU_CLKSEL_CON107 1291 * not need do high 16bit mask 1292 */ 1293 else if ((i > 0x27c && i < 0x2b0) || (i == 0x508)) 1294 mmio_write_32(CRU_BASE + i, store_cru[i / 4]); 1295 else >>> CID 1385418: Memory - illegal accesses (OVERRUN) >>> Overrunning array "store_cru" of 355 4-byte elements at element index 355 (byte offset 1420) using index "i / 4" (which evaluates to 355). 1296 mmio_write_32(CRU_BASE + i, 1297 REG_SOC_WMSK | store_cru[i / 4]); 1298 } 1299 } 1300 1301 void wdt_register_save(void) ** CID 1385417: (NO_EFFECT) /3rdparty/arm-trusted-firmware/plat/common/plat_gicv2.c: 166 in plat_ic_is_sgi() /3rdparty/arm-trusted-firmware/plat/common/plat_gicv3.c: 190 in plat_ic_is_sgi() ________________________________________________________________________________________________________ *** CID 1385417: (NO_EFFECT) /3rdparty/arm-trusted-firmware/plat/common/plat_gicv2.c: 166 in plat_ic_is_sgi() 160 { 161 return (id >= MIN_PPI_ID) && (id < MIN_SPI_ID); 162 } 163 164 int plat_ic_is_sgi(unsigned int id) 165 { >>> CID 1385417: (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "id >= 0U". 166 return (id >= MIN_SGI_ID) && (id < MIN_PPI_ID); 167 } 168 169 unsigned int plat_ic_get_interrupt_active(unsigned int id) 170 { 171 return gicv2_get_interrupt_active(id); /3rdparty/arm-trusted-firmware/plat/common/plat_gicv3.c: 190 in plat_ic_is_sgi() 184 { 185 return (id >= MIN_PPI_ID) && (id < MIN_SPI_ID); 186 } 187 188 int plat_ic_is_sgi(unsigned int id) 189 { >>> CID 1385417: (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "id >= 0U". 190 return (id >= MIN_SGI_ID) && (id < MIN_PPI_ID); 191 } 192 193 unsigned int plat_ic_get_interrupt_active(unsigned int id) 194 { 195 return gicv3_get_interrupt_active(id, plat_my_core_pos()); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

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 January 2018