coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Re: [coreboot] Easier accessibility for coreboot/flashrom wikipedias? What do you think?
by Denis 'GNUtoo' Carikli 22 May '17

22 May '17

On Fri, 19 May 2017 11:20:27 +0300 qma ster <qmastery16(a)gmail.com> wrote: > Dear coreboot/flashrom mailing list members, Hi, > As you may have noticed it is not that easy or straightforward to > gain the edit rights for coreboot/flashrom wikipedias so the people > are mass migrating to the unofficial wikis. Having already an account, I cound't notice it. Having good quality and extensive documentation is really important, so fixing that is important. > My proposal is to give the edit rights to all the subscribers of the > coreboot/flashrom mailing lists, or at least to all those who have > been the subscribers for at least a day / a week / or a month. Having a human review the subscription would probably be a better idea, if done correctly: - Humans could review if the request seems legit. - The subscribers could have that human as a reference, to ask questions if needed. - The reviewers could help the subscriber if they whish. However to work correctly: - The review process would need to be fast for both the reviewer and the subscriber. An idea would not to have to go trough something that looks like a job interview, as it was mentioned, but rather explain why the subscriber wants wiki access. It should then be explained what kind of description is expected. - It would be nice if a welcome page is created on the user account space, like on wikipedia. This would permit to refer to some general guidelines for the wikis. For instance, some of my edits on the flashrom wiki were reverted or moved to my user page, because I didn't properly understand what level of anti-bricking safety was required[1]. There are also lot of tutorials on the Internet which uses improper voltages (like 5V instead of 3.3V) for the flash chip, and as I was told, it accidentally works probably because the wire setup is so bad that the voltage drops on the wires, due to the resistance. Good guidelines/explanation pages would probably be sufficent to avoid such issues in the flashrom wiki. References: ----------- [1] I explained how to reflash the option rom of an old nvidia GPU by explaining how to bypass the read-only safety in flashrom, and making several writes attempt to flash the (sgabios) image. Since the method used always succedded for me, I thought that it was fine at the time of writing. Denis.

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 22 May '17

22 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit 746aa054e2633e3c328631ea0d50bec31460f9e7 The following tests failed: BOOT_FAILURE Commits since last successful test: 746aa05 drivers/intel/gma: Drop unused INTEL_DP 0df9a01 nb/intel/haswell: Fix up C NGI remnants 10326ba mb/intel/wtm2: Drop unsupported native graphics init bb72852 sb/via/k8t890: Clean up CONFIG_VGA usage 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.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] Asus M2N-E: Waiting for 1 CPUS to stop
by Timothy Pearson 21 May '17

21 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/2017 03:45 AM, Martin A wrote: > > > Hi there, > > > In my bunch of motherboards, the only one supported by Coreboot is my > old Asus M2N-E with Dual-Core AMD Opteron(tm) Processor 1216 HE and 4x > 2Go Ram (2@667 and 2@800). > > > So I tried to run it with Coreboot an Seabios but nothing happened on > screen and at the end of the boot log: > > Waiting for 1 CPUS to stop > > > And a bit sooner in boot log > > CPU ID 0x80000001: 40f33 > CPU is Fam 0Fh rev.F or later. We can use TOM2WB for any memory above 4GB > > Any advice to solve it please ? > Thank you. > Can you post the full boot log please? The modern Opterons occasionally hang at that same location when the debug level is set to SPEW; something you could try is to reduce the debug level to WARNING and see if the board boots. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJZHyQwAAoJEK+E3vEXDOFbylkH/jnSBLmHnRt0wZAusjIBxQX5 578UF/GxZ6kDKtkGbHvwg/+TIABC8X7CEqIG49u1KDhJfQb8+jDyQ4/oEULVWyIB DC0GEyJHOen8JJpKhTksfk5yf+qkiEIUPNCENdmM8pOUXZzryM34Ng30yHEL8nqE v2qHMgWaAjFHC5GuQGIoXk9B7afeQbvFPA8rxOztN/7NJPOf2+xzljetquxk+rRl Kugf8I9carM/Dod2rjX/rzO3QMpl9Wg3Ob/CvqBU0JKONjNxRcJU7UVeaOcRmNr1 neO8hdL5lCw2rRA6cR61HELC9fYNC61HkbmSX0JlcQw2XXCJd8CgTKncXMqDQ0k= =1zxc -----END PGP SIGNATURE-----

2 1

X200s: Are the WXGA+ (1440x900) screens supported?
by Daniel Kulesz 21 May '17

21 May '17

Hi, is someone running a (recent) version of coreboot on a X200s with the 1440x900 screen? If yes: Does native graphics init work? Cheers, Daniel

2 2

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 21 May '17

21 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit cfa2eaa4cc268e9ed23c5a8635bb8125d985c94e The following tests failed: BOOT_FAILURE Commits since last successful test: cfa2eaa nb/intel/x4x: Make raminit less verbose with CONFIG_DEBUG_RAM_SETUP 3db82be mb/gigabyte/ga-g41m-es2l: Enable IO decode range for LPT and FDD 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.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

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

19 May '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 6 new defect(s) introduced to coreboot found with Coverity Scan. 5 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 6 of 6 defect(s) ** CID 1375445: Uninitialized variables (UNINIT) /src/soc/rockchip/rk3399/mipi.c: 159 in rk_mipi_dsi_phy_init() ________________________________________________________________________________________________________ *** CID 1375445: Uninitialized variables (UNINIT) /src/soc/rockchip/rk3399/mipi.c: 159 in rk_mipi_dsi_phy_init() 153 TER_RESISTOR_HIGH | LEVEL_SHIFTERS_ON | 154 SETRD_MAX | POWER_MANAGE | 155 TER_RESISTORS_ON); 156 157 write32(&mipi_regs->dsi_phy_rstz, PHY_ENFORCEPLL | PHY_ENABLECLK | 158 PHY_UNRSTZ | PHY_UNSHUTDOWNZ); >>> CID 1375445: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 159 return ret; 160 } 161 162 static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt) 163 { 164 switch (fmt) { ** CID 1375444: Integer handling issues (REVERSE_NEGATIVE) /src/soc/intel/common/block/i2c/i2c.c: 101 in lpss_i2c_dev_init() ________________________________________________________________________________________________________ *** CID 1375444: Integer handling issues (REVERSE_NEGATIVE) /src/soc/intel/common/block/i2c/i2c.c: 101 in lpss_i2c_dev_init() 95 { 96 const struct lpss_i2c_bus_config *config; 97 int bus = lpss_i2c_dev_to_bus(dev); 98 99 config = i2c_get_soc_cfg(bus, dev); 100 >>> CID 1375444: Integer handling issues (REVERSE_NEGATIVE) >>> You might be using variable "bus" before verifying that it is >= 0. 101 if (!config || bus < 0) 102 return; 103 104 lpss_i2c_init(bus, config); 105 } 106 ** CID 1375443: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/rockchip/rk3399/mipi.c: 194 in rk_mipi_dsi_get_lane_bps() ________________________________________________________________________________________________________ *** CID 1375443: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/rockchip/rk3399/mipi.c: 194 in rk_mipi_dsi_get_lane_bps() 188 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format); 189 if (bpp < 0) { 190 printk(BIOS_DEBUG, "failed to get bpp for pixel format %d\n", 191 dsi->format); 192 return bpp; 193 } >>> CID 1375443: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "edid->mode.pixel_clock * 1000U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "u64" (64 bits, unsigned). 194 pclk = edid->mode.pixel_clock * MSECS_PER_SEC; 195 /* take 1 / 0.8, since mbps must bigger than bandwidth of RGB */ 196 target_bps = pclk / dsi->lanes * bpp / 8 * 10; 197 if (target_bps >= max_bps) { 198 printk(BIOS_DEBUG, "DPHY clock frequency is out of range\n"); 199 return -1; ** CID 1375442: Control flow issues (NO_EFFECT) /src/soc/intel/apollolake/i2c.c: 47 in i2c_soc_bus_to_devfn() ________________________________________________________________________________________________________ *** CID 1375442: Control flow issues (NO_EFFECT) /src/soc/intel/apollolake/i2c.c: 47 in i2c_soc_bus_to_devfn() 41 return PRERAM_I2C_BASE_ADDRESS(bus); 42 } 43 44 /* Convert I2C bus number to PCI device and function */ 45 int i2c_soc_bus_to_devfn(unsigned int bus) 46 { >>> CID 1375442: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "bus >= 0U". 47 if (bus >= 0 && bus <= 3) 48 return PCI_DEVFN(PCH_DEV_SLOT_SIO1, bus); 49 else if (bus >= 4 && bus <= 7) 50 return PCI_DEVFN(PCH_DEV_SLOT_SIO2, (bus - 4)); 51 else 52 return -1; ** CID 1375441: Integer handling issues (NEGATIVE_RETURNS) /src/soc/intel/common/block/i2c/i2c.c: 122 in lpss_i2c_acpi_fill_ssdt() ________________________________________________________________________________________________________ *** CID 1375441: Integer handling issues (NEGATIVE_RETURNS) /src/soc/intel/common/block/i2c/i2c.c: 122 in lpss_i2c_acpi_fill_ssdt() 116 enum i2c_speed speeds[LPSS_I2C_SPEED_CONFIG_COUNT] = { 117 I2C_SPEED_STANDARD, 118 I2C_SPEED_FAST, 119 I2C_SPEED_FAST_PLUS, 120 I2C_SPEED_HIGH, 121 }; >>> CID 1375441: Integer handling issues (NEGATIVE_RETURNS) >>> Assigning: signed variable "bus" = "lpss_i2c_dev_to_bus". 122 int i, bus = lpss_i2c_dev_to_bus(dev); 123 124 bcfg = i2c_get_soc_cfg(bus, dev); 125 126 if (!bcfg) 127 return; ** CID 1375440: Integer handling issues (NEGATIVE_RETURNS) /src/soc/intel/common/block/i2c/i2c.c: 97 in lpss_i2c_dev_init() ________________________________________________________________________________________________________ *** CID 1375440: Integer handling issues (NEGATIVE_RETURNS) /src/soc/intel/common/block/i2c/i2c.c: 97 in lpss_i2c_dev_init() 91 * The device should already be enabled and out of reset, 92 * either from early init in coreboot or SiliconInit in FSP. 93 */ 94 static void lpss_i2c_dev_init(struct device *dev) 95 { 96 const struct lpss_i2c_bus_config *config; >>> CID 1375440: Integer handling issues (NEGATIVE_RETURNS) >>> Assigning: signed variable "bus" = "lpss_i2c_dev_to_bus". 97 int bus = lpss_i2c_dev_to_bus(dev); 98 99 config = i2c_get_soc_cfg(bus, dev); 100 101 if (!config || bus < 0) 102 return; ________________________________________________________________________________________________________ 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

Asus M2N-E: Waiting for 1 CPUS to stop
by Martin A 19 May '17

19 May '17

Hi there, In my bunch of motherboards, the only one supported by Coreboot is my old Asus M2N-E with Dual-Core AMD Opteron(tm) Processor 1216 HE and 4x 2Go Ram (2@667 and 2@800). So I tried to run it with Coreboot an Seabios but nothing happened on screen and at the end of the boot log: Waiting for 1 CPUS to stop And a bit sooner in boot log CPU ID 0x80000001: 40f33 CPU is Fam 0Fh rev.F or later. We can use TOM2WB for any memory above 4GB Any advice to solve it please ? Thank you.

1 0

Easier accessibility for coreboot/flashrom wikipedias? What do you think?
by qma ster 19 May '17

19 May '17

Dear coreboot/flashrom mailing list members, As you may have noticed it is not that easy or straightforward to gain the edit rights for coreboot/flashrom wikipedias so the people are mass migrating to the unofficial wikis. For example: recently Zoran Stojsavljevic had to bring his Coreboot/VBT article to Jimmy Wales wikipedia instead of coreboot wikipedia, Mike Banon had to put his EC KB9012 chip flashing article to DangerousPrototypes wikipedia instead of flashrom wikipedia, and I could provide many other similar examples if needed Currently, to get the edit rights for coreboot/flashrom wikipedias you have to personally contact the wikipedias administration, who are the highly active open source developers with a lot of things to do and may simply forget to review your request - and you have to provide a good enough detailed explanation of what exactly you are going to write or edit, despite that your plans might change and suddenly you would like to improve another article, write your own, or maybe even want to improve the many other random articles: doing small changes like fixing the typos / replacing the broken links / updating the clearly outdated information / other fixes that are minor by nature but still are majorly improving the wikipedias quality I believe that the current administrative barriers are too high: to gain the edit rights you should not be required to go through what seems to be like a job interview, especially because this is not like a job offer and your work at these wikipedias will be unpaid My proposal is to give the edit rights to all the subscribers of the coreboot/flashrom mailing lists, or at least to all those who have been the subscribers for at least a day / a week / or a month. Could see only the positive outcome from this action, because I strongly believe that all the members of coreboot/flashrom mailing lists are responsible smart individuals and their wiki contributions will be of high quality. Alternatively, the registration could be made completely open, but with a strong registration/login captcha or maybe even per-edit captcha to prevent the automatic bots/spammers from ruining the wiki pages Please share your opinions about this proposal. It is interesting to hear your thoughts, and maybe they could influence the coreboot/flashrom projects future Best regards, qmastery

1 0

What is Intel Corporation Device 0103? (thinkpad x220)
by Taiidan＠gmx.com 19 May '17

19 May '17

On an x220 it is pci device 00:04.0 "Signal Processing Controller" from what I can gather it is something to do with thermal control - but I am curious as to why it doesn't have an actual name in lspci.

2 1

GPIO PADRSTCFG conflict in datasheet
by Youness Alaoui 18 May '17

18 May '17

Hi, I'm working on a skylake port and I've noticed something with the PADRSTCFG field of the GPIO Pad configuration. If you look at the 100-series datasheet volume 2 ( https://www-ssl.intel.com/content/www/us/en/chipsets/100-series-chipset-dat…). The Pad configuration DW0 for GPP_A, GPP_B, GPP_C, etc.. (page 1179, 1249) up to GPP_I (page 1319) has bits 31:30 (PADRSTCFG) defined like this : 00 = RSMRST# 01 = Host deep reset. 10 = PLTRST# 11 = Reserved But the Pad configuration DW0 for GPD pads (page 1296) has it defined like this : 00 = DSW_PWROK 01 = Host deep reset. 10 = PLTRST# 11 = RSMRST# The problem here is that while the DEEP and PLTRST values are the same, the RSMRST value is 0 for GPP gpio pads, and 3 for GPD gpio pads. In the skylake and apollolake gpio_defs.h file, it is defined like this (with different naming for apollolake but same values) : #define PADRSTCFG_DSW_PWROK 0 #define PADRSTCFG_DEEP 1 #define PADRSTCFG_PLTRST 2 #define PADRSTCFG_RSMRST 3 These defines are only valid for GPD pads, if someone was to use a RSMRST reset config on a GPP pad, they would be setting the pad to a 'reserved' configuration, which could have unexpected behavior. There are two possibilities here, either the datasheet is wrong (and PWROK should be 3 so the RSMRST value is consistent for both GPP and GPD), or the datasheet is correct, and in both cases, the value in coreboot is wrong. If someone from Intel is reading this list, or if someone here knows someone inside Intel who could confirm whether or not the datasheet has an error, that would be great. In the meantime, I would maybe suggest to change the defines to : #define PADRSTCFG_GPD_RSMRST 3 #define PADRSTCFG_GPP_RSMRST 0 This would affect both skylake and apollolake, and note that the only skylake+ boards that use RSMRST seem to be the kblrvp in the rvp7 variant which sets it for GPP_A12 and GPP_E3 (which means those two gpios have the wrong setting due to the wrong define). What do you think ? Thanks, Youness.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
21
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 May 2017