coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

X220 Wifi Suspend
by Tyler Cipriani 18 Nov '16

18 Nov '16

I recently flashed my Lenovo ThinkPad X220 with Coreboot and a SeaBIOS payload. I made an attempt to document the whole process[0]. Initially, everything seemed to work fine. I was able to boot to SeaBIOS which handed off to a Debian testing install (Stretch). Now that I've used this laptop a bit, I realized that wifi appears hardware-blocked after returning from suspend. I've found lots of pages online with "one weird trick" to fix this, and have tried many of those tricks to no avail :( I've tried a couple of different Coreboot configs[1][2] neither of which made any difference. After re-flashing the old proprietary ThinkPad BIOS wifi comes back from suspend just fine. I've tried both the standard intel wifi card and a card from ThinkPenguin that uses the ath9k driver[3] using the coreboot config. Any help or pointers anyone could give me would be much appreciated! -- Tyler [0]. <https://tylercipriani.com/blog/2016/11/13/coreboot-on-the-thinkpad-x220-wit…> [1]. <http://pastebin.com/Ah0fxBp5> [2]. <http://pastebin.com/1yNSTfyj> [3]. <https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-half-height-mini-…>

2 2

Re: [coreboot] Powersavings: 8W of difference between bios and coreboot
by Felix Held 18 Nov '16

18 Nov '16

Hi! > I don't know if Charlotte has added the ID of the dGPU to > src/drivers/lenovo/hybrid_graphics.c. Does the dGPU consume power > after hybrid_graphics.c disable the dGPU? OPTIMUS_ENABLE is a PCH GPIO and controls the muxes that select if the internal display is connected to the iGPU or the dGPU; that's done in hybrid_graphics.c. GFXCORE_ON_D (and another signal that controls the power supply of the VRAM) are driven by the Thinker-1 chip; those switch on/off the power supply of the GPU. So to really disable the GPU you probably have to ask the EC to make that chip turn off the voltage for the GPU and VRAM. Regards Felix

2 1

Re: [coreboot] Removing Intel ME from the X230 coreboot
by Nicola Corna 18 Nov '16

18 Nov '16

> The system did not poweroff after 30 min, but I would like to strip > down everything I can out of the intel ME. Your approach is > interesting. What is the minimal size you can presently get? > Hi, we didn't resized the resulting image, we kept it at 1.5 MB. > Using your python script on my 1.5 me.bin, I get FFs after 0x906C0 > > Can I adjust the IFD accordingly to scrape this extra space, or will > I run into problems as Tramell said the ME wants to write to its own > partition? You will probably run into the same problem, but you can still try if you feel lucky. > Have you been able to test Igor suggestions to further trim the intel > ME? Our spare X220 is dead at the moment, once it is running again we can resume all the work on ME. Nicola

1 0

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

18 Nov '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. 2 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 2 of 2 defect(s) ** CID 1365977: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/common/lpss_i2c.c: 541 in lpss_i2c_gen_config_rise_fall_time() ________________________________________________________________________________________________________ *** CID 1365977: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/common/lpss_i2c.c: 541 in lpss_i2c_gen_config_rise_fall_time() 535 printk(BIOS_ERR, "lpss_i2c: invalid bus speed %d\n", 536 config->speed); 537 return -1; 538 } 539 540 if (soc == NULL) { >>> CID 1365977: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "soc". 541 printk(BIOS_ERR, "lpss_i2c: invalid SoC clock speed %d MHz\n", 542 soc->clk_speed_mhz); 543 return -1; 544 } 545 546 /* Get the proper spike suppression count based on target speed. */ ** CID 1365976: (CONSTANT_EXPRESSION_RESULT) /src/soc/rockchip/rk3399/clock.c: 673 in rkclk_i2c_clock_for_bus() /src/soc/rockchip/rk3399/clock.c: 677 in rkclk_i2c_clock_for_bus() /src/soc/rockchip/rk3399/clock.c: 681 in rkclk_i2c_clock_for_bus() ________________________________________________________________________________________________________ *** CID 1365976: (CONSTANT_EXPRESSION_RESULT) /src/soc/rockchip/rk3399/clock.c: 673 in rkclk_i2c_clock_for_bus() 667 case 4: 668 write32(&pmucru_ptr->pmucru_clksel[3], 669 PMU_I2C_CLK_REG_VALUE(4, src_clk_div)); 670 break; 671 case 5: 672 write32(&cru_ptr->clksel_con[61], >>> CID 1365976: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (I2C_DIV_CON_MASK << CLK_I2C5_DIV_CON_SHIFT) | (CLK_I2C_PLL_SEL_MASK << CLK_I2C5_PLL_SEL_SHIFT) */) | ((src_clk_div - 1 << CLK_I2C5_DIV_CON_SHIFT) | (32768 /* CLK_I2C_PLL_SEL_GPLL << CLK_I2C5_PLL_SEL_SHIFT */))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 673 I2C_CLK_REG_VALUE(5, src_clk_div)); 674 break; 675 case 6: 676 write32(&cru_ptr->clksel_con[62], 677 I2C_CLK_REG_VALUE(6, src_clk_div)); 678 break; /src/soc/rockchip/rk3399/clock.c: 677 in rkclk_i2c_clock_for_bus() 671 case 5: 672 write32(&cru_ptr->clksel_con[61], 673 I2C_CLK_REG_VALUE(5, src_clk_div)); 674 break; 675 case 6: 676 write32(&cru_ptr->clksel_con[62], >>> CID 1365976: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (I2C_DIV_CON_MASK << CLK_I2C6_DIV_CON_SHIFT) | (CLK_I2C_PLL_SEL_MASK << CLK_I2C6_PLL_SEL_SHIFT) */) | ((src_clk_div - 1 << CLK_I2C6_DIV_CON_SHIFT) | (32768 /* CLK_I2C_PLL_SEL_GPLL << CLK_I2C6_PLL_SEL_SHIFT */))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 677 I2C_CLK_REG_VALUE(6, src_clk_div)); 678 break; 679 case 7: 680 write32(&cru_ptr->clksel_con[63], 681 I2C_CLK_REG_VALUE(7, src_clk_div)); 682 break; /src/soc/rockchip/rk3399/clock.c: 681 in rkclk_i2c_clock_for_bus() 675 case 6: 676 write32(&cru_ptr->clksel_con[62], 677 I2C_CLK_REG_VALUE(6, src_clk_div)); 678 break; 679 case 7: 680 write32(&cru_ptr->clksel_con[63], >>> CID 1365976: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (I2C_DIV_CON_MASK << CLK_I2C7_DIV_CON_SHIFT) | (CLK_I2C_PLL_SEL_MASK << CLK_I2C7_PLL_SEL_SHIFT) */) | ((src_clk_div - 1 << CLK_I2C7_DIV_CON_SHIFT) | (32768 /* CLK_I2C_PLL_SEL_GPLL << CLK_I2C7_PLL_SEL_SHIFT */))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 681 I2C_CLK_REG_VALUE(7, src_clk_div)); 682 break; 683 case 8: 684 write32(&pmucru_ptr->pmucru_clksel[2], 685 PMU_I2C_CLK_REG_VALUE(8, src_clk_div)); 686 break; ________________________________________________________________________________________________________ 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

Re: [coreboot] Powersavings: 8W of difference between bios and coreboot
by Felix Held 18 Nov '16

18 Nov '16

Hi! > BIOS: 11W Coreboot: 19W [...] Can you also measure the power consumption with the GPU enabled under the vendor firmware? > and no, the NVidia GPU was not enabled in corebooy. Both results were > on integrated GPU only Have you only disabled the nVidia GPU in devicetree.cb (that will only disable the PCIe interface on the CPU side) or have you also disabled the GPU power supply via the GFXCORE_ON_D signal? Since that signal is driven by the power management companion chip (Thinker-1), you probably have to talk to the EC to do that. Regards Felix

2 1

Re: [coreboot] native video init question
by Charlotte Plusplus 18 Nov '16

18 Nov '16

Ok, I found a way to get usable inteltool results: I ran inteltool -f on a borrowed W530 that has the exact same CPU 3940XM, the exact same integrated GPU (HD4000) and the exact same screen as my W520. Only the southbridge is different: QM77 instead of QM67 Now I will have to check the documentation of the registers to use this information to get native video init working. Is there anything else I should run before I have to give it back?? Charlotte On Wed, Nov 16, 2016 at 10:06 PM, Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > Hello > > Yes I have included this patch 17389 in my build. Unfortunately, it gave > me the raminit logs failures attached before. I will try to see what's > stored in the MRC cache. I would like to make the ram init conditional on > the boot status, which means having 2 mrc cache: one for normal, one for > fallback. This way, I flush one and debug ram issues with less fear > (because the W520 I am porting coreboot to is my main laptop) > > For native video, I have 2 memory segments: > Memory at f1400000 (64-bit, non-prefetchable) [size=4M] > Memory at e0000000 (64-bit, prefetchable) [size=256M] > > I guess I should always read from the first one. > > It seems to work, but I am always getting the same result at different > addresses > $ ./iotools mem_read32 f14C7200 > 0xf000ff53 > $ ./iotools mem_read32 f14C7201 > 0xf000ff53 > $ ./iotools mem_read32 f14C7202 > 0xf000ff53 > $ ./iotools mem_read32 f14C7203 > 0xf000ff53 > $ ./iotools mem_read32 f1400000 > 0xf000ff53 > > Here is the romstage that I tried using with non native raminit. It gave > me no video, but besides that it goes to payload and work fine. I wonder if > I should declare the HD4000 in the peidata. It seems the video was just not > initialized at all. > > For brightness in the payloads, if it cause security issues, I guess I can > do without it. > > Charlotte > > > > On Wed, Nov 16, 2016 at 7:32 AM, Nico Huber <nico.huber(a)secunet.com> > wrote: > >> On 16.11.2016 06:08, Charlotte Plusplus wrote: >> > Hello >> > >> > On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber <nico.h(a)gmx.de> wrote: >> > >> >> I've seen a garbled image, too, lately. When I built with native >> >> raminit by chance but with a completely different gfx init code >> >> (3rdparty/libgfxinit). So it might still be some problem in the >> >> raminit. This was also on an Ivy Bridge system with four DIMMs, >> >> btw. I suspected that the native raminit just wasn't tested in that >> >> configuration. >> >> >> > >> > Interesting, I noticed some patterns with raminit too. Most of my >> problems >> > with the native raminit happen with 4x 8Gb DIMMS. The more sticks I >> have, >> > the less likely native ram training is to succeed. I have logged a few >> of >> > the failed attempt in case anyone else is interested (attached). >> > >> > Basically, the training can fail several times with the exact same >> > parameters that it later succeeds with. Also, failure is a function of >> > speed. All the attempts I have done but not attached can be summed up >> like >> > this: failure of the native ram training is also more likely with a MCU >> > over 666MHz. But whenever the raminit succeed, the memory is stable in >> > memtests (I did several passes to check. >> > >> > Now that I can use Windows 10 with Coreboot, I decided to experiment a >> bit >> > more. First, I tried changing the SPD settings with Thaiphoon Burner. >> The >> > sticks I have advertise they supported both 1.35 and 1.5V profiles (SPD: >> > 006=03) which I feared might cause issue. Changing that to 1.5V only >> (SPD: >> > 006=00) did not help, even if it did help with another computer that I >> > borrowed to do some comparisons with (I was afraid my sticks were at >> fault) >> > >> > Then I tried manually filling XMP profile 1 with known to be working >> values >> > (either published, or found during native raminit training). It seemed >> to >> > help but the results were inconsistent. Between my tests for different >> > value, I was clearing the MRC cache. >> > >> > Then I had a weird idea: what if the ram training or the MRC cache >> clearing >> > was the cause of the problem? I changed my protocol to do: clear cache, >> > train after changing the SPD/MCU frequency/etc, then when it succeeds >> > disable the MRC cache clearing hook, and do a few reboots or a power off >> > before doing the memtest. And this was sufficient to get stabilility at >> > 666Mhz and frequencies above without having to tweak the SPD anymore >> (like >> > adding some latency to the detected values) >> > >> > Currently 800Mhz is validated, I haven't tested 933 MHz because ram >> > training success seems to be a probability that goes down with the >> > frequency, and pressing on the power button every time it fails quickly >> > gets boring! >> > >> > I have no way to prove that, but I believe that the ram training by >> itself >> > interferes with the stability of the RAM, or that there is some non >> > deterministic part in the code. I don't know why or how, it's a lot of >> code >> > that I haven't read in detail, but it's what my tests suggests. I would >> > love to compare these results to ones the blob raminit would give. But >> blob >> > raminit causes video issues. So I'm trying to focus on native video init >> > first, in case it helps me to use mrc.bin. >> >> I can't recall if Patrick or you mentioned this already, there's a rela- >> ted patch up for review: >> https://review.coreboot.org/#/c/17389/ >> Do you have that already applied locally? >> >> > >> > Well, I don't see any setting that could really break something. The >> >> code might just be buggy. I'll go through the settings anyway, taking >> >> src/mainboard/lenovo/t520/devicetree.cb as example: >> >> >> > >> > I used this code as a source, as I figured the screen was likely to be >> the >> > same. >> > >> > That's about ACPI, let's not care (the last appendix in the ACPI spec if >> >> you want to have a look). >> >> >> > >> > I will check that too because Fn Home and Fn end (brightness + and -) >> don't >> > work in memtest86, even if they work in linux and windows >> >> That's expected. coreboot does the brightness control through ACPI. >> And ACPI is something for bloated OSs not for payloads (it comes with >> a whole bunch of code including a byte-code interpreter). >> >> A workaround would be to do the EC event handling in SMM until ACPI >> takes over. But that's usually discouraged as SMM has security issues. >> So we want as little code as possible in SMM. >> >> > >> > >> >> Those are real register settings, you can dump the whole GMA MMIO >> >> space with `inteltool -f` (hoping that your system doesn't hang). The >> >> registers are described in [1, chapter 2.4]. >> >> >> > >> > Sorry, but it did hang. I couldn't even ssh to it. Any alternative to >> get >> > the info? >> >> Look up the base address of the gfx MMIO space: >> $ lspci -vs 00:02.0 | grep Memory >> or >> $ head -1 /sys/devices/pci0000:00/0000:00:02.0/resource >> >> Grab a copy of iotools: https://github.com/adurbin/iotools.git >> You should be able to read single registers with the mem_read32 command: >> # ./iotools mem_read32 $((base+register_offset)) >> >> Nico >> >> >

1 0

Powersavings: 8W of difference between bios and coreboot
by Charlotte Plusplus 18 Nov '16

18 Nov '16

Hello Since I started using coreboot, I have noticed my battery doesn't seem to last as long. I have a very simple linux install on a separate partition that I use to compare power consumption, so I decided to verify if my perception was true. After some quick tests, I noticed the power profile seem to have changed a whole lot, so I decided to check exactly how much by running some tests. I had saved results when running the thinkpad bios, so I decided to get more measurements to compare the thinkpad bios to coreboot on the W520. The test environment is X with just a xterm open to display powertop results. Nothing else is running: there are just 130 wakeups per seconds (with 100 coming from tick_sched_timer), and according to powertop all the cores are in mode C7-IVB between about 98 to 99% of the time. So it should be the best environment to have accurate results without software interfering. To reduce sources of error, I always start from a cold boot, with the machine cold, no previous fan activity. With normal power saving options (everything toggled in powertop), network stopped, and measurement repeated every 5 seconds during 10 min and averaged, I get: BIOS: 11W Coreboot: 19W With the powersave governor BIOS: 9W Coreboot: 17W With brightness reduced to 200 BIOS: 8W Coreboot: 16W The steps between each operation seem identical (activating powersave: -2W, reducing brightness: -1W) however the baseline is off by about 8W. This is on the exact same software environement, running the exact same linux kernel with the exact same kernel options. (and no, the NVidia GPU was not enabled in corebooy. Both results were on integrated GPU only) I found that weird, so to confirm these results I put the hard drive into a borrowed W530. It has the exact same CPU and screen as my W520, the same USB peripherals (except a colormeter) and a similar memory configuration (4 dimms): I get about the same as the bios results I got before: 11W on the minimal install, going down to 8W at maximum power saving. However, with coreboot I just can't do any better than 16W. The difference of 8W is quite a lot, as with all powersavings applied, running coreboot mean taking 2x as much power. The room temperature hasn't changed (I have a thermostat), and I don't believe a single USB peripheral can take 8W. So I think there is only one conclusion: I have a lot of work to do on my W520 port to get even close to the initial power savings So I wonder if there is anything I can do to improve power savings? What are some basic suggestions?? The full 8W difference means there should be at least a few low hanging fruits!! Thanks Charlotte

1 0

ASUS KFSN4-DRE Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 18 Nov '16

18 Nov '16

The ASUS KFSN4-DRE fails verification for branch master as of commit cd2afc0df034670a83479aded514b22b99124cf5 The following tests failed: BOOT_FAILURE Commits since last successful test: cd2afc0 google/chromeec: Add common infrastructure for boot-mode switches See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Skip CAR setup in FSP?
by Aaron Durbin 18 Nov '16

18 Nov '16

On Thu, Nov 17, 2016 at 4:32 PM, Mason M <09mmanning(a)gmail.com> wrote: > Hi coreboot people, > > I noticed the option in soc/intel/skylake/Kconfig called SKIP_FSP_CAR, which > based on the description, it sounds like the intention is to simply skip the > TempRamInit portion of FSP. However, from looking at the code in > cache_as_ram.inc, the jump to TempRamInit is still performed, but with an > additional #include of a non-existent file called "soc/car_setup.S" > beforehand. A little more confusingly, only if the option is set does the > code bother to assign the UPD values FspCarBase and FspCarSize a meaningful > value in skylake/romstage/romstage.c. Compounding on top of this, the > option is enabled by default, seeming to imply it's the preferred way to go > for Skylake FSP builds. Skylake FSP 1.1 still required TempRamInit to be called for some reason. However It used a non-zero MTRR to determine it didn't need to perform CAR initialization, IIRC. The car_setup.S was removed in https://review.coreboot.org/15784 as well as the selection of USE_GENERIC_FSP_CAR_INC which dictates if src/drivers/intel/fsp1_1/cache_as_ram.inc is employed. You can see how it was and ships on SKL chromebooks in the chromium branch: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/refs/he… The FspCarBase and FspCarSize is way to inform the MemoryInit piece of FSP where CAR actual resides. Now skylake has changed to doing CAR setup in bootblock and those flows aren't taken any more. The TempRamInit is still done, but it's called in bootblock_fsp_temp_ram_init() from bootblock_soc_init() when CONFIG_PLATFORM_USES_FSP1_1 is set. > > Can anyone explain to me what the purpose of this option is? Is it simply > old code that was accidentally left behind? > > Much appreciated, > Mason > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Skip CAR setup in FSP?
by Mason M 17 Nov '16

17 Nov '16

Hi coreboot people, I noticed the option in soc/intel/skylake/Kconfig called SKIP_FSP_CAR, which based on the description, it sounds like the intention is to simply skip the TempRamInit portion of FSP. However, from looking at the code in cache_as_ram.inc, the jump to TempRamInit is still performed, but with an additional #include of a non-existent file called "soc/car_setup.S" beforehand. A little more confusingly, only if the option is set does the code bother to assign the UPD values FspCarBase and FspCarSize a meaningful value in skylake/romstage/romstage.c. Compounding on top of this, the option is enabled by default, seeming to imply it's the preferred way to go for Skylake FSP builds. Can anyone explain to me what the purpose of this option is? Is it simply old code that was accidentally left behind? Much appreciated, Mason

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
19
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 November 2016