coreboot February 2018

coreboot@coreboot.org

49 participants
79 discussions

Re: [coreboot] Postcode at Lenovo x230
by Kyösti Mälkki 16 Feb '18

16 Feb '18

Hi Rafael On Fri, Feb 16, 2018 at 2:03 PM, Rafael Machado <rafaelrodrigues.machado(a)gmail.com> wrote: > The problem is that this time, with this x230, after I connected the > postcard and turned the system on, the system stopped to boot. And the post > card does not stop at a specific post code. These cheap POST80 displays do not use PCI-e signalling. Looking at Wistron Dasher-2 schematics that to my knowledge is (a/the) x230 mainboard, required LPC signals are not routed to either of the mini-PCI-e slots. There is a separate (unpopulated) connector CN14 and card-edge GF1 to use for post80 display. > What happens now, is that every time I turn the system on, the battery led > blinks 3 times, being two blinks followed by a 1 second stop and after that > the last blink, and the system reboots. :( > The post card I'm using is this: > https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnost… I have one these as well. That mini-PCI-e card-edge is not so great, it is missing pads for pins 1 and 2. It also appears to be narrower what the specs says, so you need to be very careful with proper alignment on installation. Also have laptop battery removed while doing so! > > So my questions are: > > -Does someone believe this postcard could have bricked the system? (Why?) > -Any idea about how to solve that? I would measure the 3.3V power rail on the mainboard (VCC3WLAN) . If you had installed the postcard improperly/skewed to the socket you could have caused some shortcut to GND and damaged the on-board power circuitry. Other than that, I don't see how this post card could harm a x230. Hope this helps, Kyösti

1 0

[RFC] Fix undefined behavior with left shifts in whole code base
by Paul Menzel 16 Feb '18

16 Feb '18

Dear coreboot folks, TLDR; If coreboot wants to *make use of the undefined baviour sanitizer (UBSAN)* a solution needs to be found for left shift errors like in `1 << 31`, where the sign bit is ignored. The proposal is to adapt the code accordingly, that means `1U << 31`, although it’s not so pretty. === Longer version === Trying an image built with the undefined behavior sanitizer (UBSAN) for the ASRock E350M1, it stops with the error below. ``` runtime error: left shift of 255 by 24 places cannot be represented in type 'int' ``` Please find the code below. ``` $ nl -ba ./src/southbridge/amd/cimx/sb800/ramtop.c | tail -11 41 { 42 u32 xdata = 0; 43 int xnvram_pos = 0xf8, xi; 44 for (xi = 0; xi < 4; xi++) { 45 outb(xnvram_pos, BIOSRAM_INDEX); 46 xdata &= ~(0xff << (xi * 8)); 47 xdata |= inb(BIOSRAM_DATA) << (xi *8); 48 xnvram_pos++; 49 } 50 return xdata; 51 } ``` The reason is, that the integer is not big enough to hold the left shift in `~(0xff << (xi * 8)) with `xi = 3``. That caused me to look more into such things, and GCC and Clang are able to find quite some of these issues during compile time. GCC needs `-Wshift-overflow=2` [1][2]. Right now, that warning is disabled for Clang for example. Please find the documentation from GCC (`man gcc`) below. > -Wshift-overflow > -Wshift-overflow=n > Warn about left shift overflows. This warning is enabled by default in C99 and C++11 modes (and newer). > > -Wshift-overflow=1 > This is the warning level of -Wshift-overflow and is enabled by default in C99 and C++11 modes (and newer). This warning level does not warn about left-shifting 1 into the sign bit. > (However, in C, such an overflow is still rejected in contexts where an integer constant expression is required.) > > -Wshift-overflow=2 > This warning level also warns about left-shifting 1 into the sign bit, unless C++14 mode is active. That brings up a lot of problems mostly for `1 << 31` used quite a lot in the coreboot code base. The question is, how to deal with these. Julius commented quite pointedly [2]. > Everyone likes to write (1 << x), and having to change them all to > (1U << x) would not be that great for readability. But making this > different based on whether it touches bit 31 or not is also super > inconsistent. I think if this warning is benign, I'd be more inclined > to just disable it. I’d really like to *enable as much warnings* as possible to let the build tools *catch as much errors as possible*, and having to adapt the code to work with this is in my opinion worth the effort. If we wanted to work around it by for example ignoring constant shift errors, we would probably need to adapt the UBSAN for GCC and Clang, and add a new switch also. So, I propose to only add the type specifier in the cases, where an error is thrown. That’s stylistically not so pretty, but would be easy to implement, as the build tools would find the affected places without problems, and those can be changed then. In addtion to the already pushed change-sets, I would submit a patch fixing all `1 << 31` and `3 << 30` occurrences, and separate change- sets for the rest. After that, the warning can be enabled for the whole code base. What do you think, and what other options do you see? Kind regards, Paul [1] https://review.coreboot.org/#/c/coreboot/+/23360/ [2] https://review.coreboot.org/#/c/coreboot/+/23361/

2 1

Re: [coreboot] Postcode at Lenovo x230
by Elisenda Cuadros 16 Feb '18

16 Feb '18

Hi Rafael, I have a X230, but this has never happened to me before. Sorry :-( . Have you tried unplugging, waiting 10 seconds and plugging the CMOS battery cable and trying to boot afterwards? Also disconnect the laptop battery during this procedure. Regards, - Eli On 16/02/18 13:03, Rafael Machado wrote: > Hi everyone > > Since here are the most skilled professions I've seeing I believe > someone can help me. > > I have a Lenovo x230, and I'll would like to install coreboot in it to > start to understand how it works, and in future start to help the > community, as soon as I have the knowledge for that. > > Last week I did a test that makes my progress stop. > > Just for fun, and to check how the commercial bios works, I connected > a postcard on the wireless slot (as far as I know this is a pcie slot). > I already did that with other notebooks I have and nothing wrong happened. > > The problem is that this time, with this x230, after I connected the > postcard and turned the system on, the system stopped to boot. And the > post card does not stop at a specific post code. > What happens now, is that every time I turn the system on, the battery > led blinks 3 times, being two blinks followed by a 1 second stop and > after that the last blink, and the system reboots. > > The post card I'm using is this: > https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnost… > > So my questions are: > > -Does someone believe this postcard could have bricked the system? (Why?) > -Any idea about how to solve that? > > My next test will be to write a coreboot build at this system using > buspirate, but since I'll only have time for this next week, I would > like to have some things to think about, this is why I sent this > e-mail before doing the coreboot flash test. > > Any comment will be helpful. > > Thanks and Regards > Rafael R. Machado > >

2 1

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware
by Paul Kocialkowski 16 Feb '18

16 Feb '18

Hi, Le vendredi 09 février 2018 à 14:33 -0500, Youness Alaoui a écrit : > On Tue, Feb 6, 2018 at 4:41 AM, Mike Banon <mikebdp2(a)gmail.com> > wrote: > > Thank you very much for telling about EC-1.75 project! > > http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1 > > Maybe some of its' elements could be borrowed for Origami > > if the hardware is similar? (haven't compared the datasheets) > > There will probably be some things in common. I don't know how much > of > ec-1.75 is good enough to be reused though, or if it's maintainable, > etc.. but yes, it could be a good starting point. There is indeed a lot in common with that code, but the code itself is not structured and organized at all so reusing the codebase makes very little sense. I mostly use this code for reference and it has already proven useful (e.g. for special trickery that has to be implemented when going to low power mode). > > @ Youness and Marty : > > > > Proprietary firmware of KB9012 explicitly disables EDI - ENE Debug > > Interface > > (the protocol used to access the internal memory of KB9012) unless > > pin > > 42 is grounded > > _before_ powering the KB9012 controller ! Maybe its the same with > > your > > another KB ? > > If you ground that pin (not necessarily 42, your KB's pin number > > could > > be different) > > to put your EC into debug mode, maybe then you could successfully > > read/write it ? > > > > Here is the full description of my successful KB9012 hardware > > flashing setup > > through the keyboard port using a flex cable with soldered wires: > > 0.5mm pitch > > makes it hard to solder directly to keyboard port, and also I like > > flex cable solution > > because its much faster to remove/insert a cable than to > > solder/desolder the wires > > > > http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate > > > > ^^^ Had to unite three grounds ( programmer's, mainboard's and > > KB9012's 42 pin ) > > to make it work > > > > Currently we are actively working on the inclusion of KB9012 > > flashing support > > to the official flashrom - but its already possible via the > > unofficial patches. > > Changes 23258 - 23263 at the https://review.coreboot.org/#/q/projec > > t:flashrom Note that the patches have been merged at this point, so ENE EDI support in flashrom is now ready. I am also wondering about using libflashrom to write an EDI debugger (since, after all, EDI has access to the whole external memory). > > I haven't compared the datasheets of KB9012 and your KB, so I don't > > know > > if they are using exactly the same debug interface or it is > > slightly different > > (please check if there are differences, maybe you'll have to write > > some code) > > > > I trust hardware flashing more than the software, especially your > > current AMI BIOS setup > > which isn't free software. Maybe the direct hardware flashing is > > also > > possible for you > > Sure, you can trust hardware flashing more than software flashing, > but > I really need software flashing. If it was just for me, yeah, I could > fiddle with it to flash it by hardware for my personal needs, but > when > it's about deploying it to all our customer base, that's another > story, the only solution is software flashing. Obviously, it would > have to work in coreboot, so whatever coreboot is doing wrong (or AMI > is doing right.. my guess is that it's probably something with the EC > ACPI code), we'd have to figure that out first in order to get the > read/write support. Either way, since the EC firmware resides in the SPI flash, it'll be no issue to reflash it both by software and hardware. > > Latest status update for Origami-EC firmware: > > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html > > Thanks! Good to see the status update on that. In order to kickstart the development of the Origami-EC firmware, I am designing evaluation boards for both the KB9012 and the KB3930 that will expose most of the I/O ports with headers, LEDs, buttons, connectors, etc. The design is done with KiCAD and will be released under the GPLv3+ as part of the Origami-EC project. I am also preparing a debug board to reflash the EC on the G505s from the keyboard connector. There is also ongoing work on the emulator and the SerialICE-like library for relatying and tracing I/O on the device via UART. Also, note that the emulator can now emulate a virtual console so it's already possible to build and interract with the firmware! Cheers, Paul > > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui > > <kakaroto(a)kakaroto.homelinux.net> wrote: > > > Hi Marty, > > > > > > Unfortunately, the EC firmware on the Librems is not open and we > > > have > > > someone working on that aspect, but with everything we have to > > > handle, > > > I think it's only being done part time. > > > We found something similar to you with the private submodule for > > > the > > > PS/2 module on the OLPC code. > > > More specifically : > > > http://lists.laptop.org/pipermail/openec/2011-January/000158.html > > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A > > > 1 > > > > > > I had opened a ticket a while ago here : > > > https://tracker.pureos.net/T178 which mentions Origami-EC. I > > > don't > > > know the status of that project, maybe you can contact the > > > developer > > > (Paul Kocialkowski) and see where he's at with his development of > > > that > > > project (which, I need to mention, hasn't been publicly launched > > > yet, > > > as far as I know) and he might benefit from your help if you are > > > interested in doing that. > > > The last time we spoke he said : > > > "The OLPC code is nowhere close to usable on any other platform. > > > Additionally, it is so poorly written that I don't think it is a > > > suitable codebase for any future development. On the other hand, > > > my > > > Origami-EC project (that I will publicly launch soon) should > > > provide a > > > flexible codebase to add support for new devices." > > > > > > Note that the tracker ticket above is quite outdated, we know how > > > to > > > dump the EC (the problem was that it can't be done via hardware > > > because the EC is on the same power rail as the 64KB flash chip, > > > so > > > when we power the flash via hardware, the EC boots and takes > > > control > > > of the SPI lines) but for some reason, we could only dump it via > > > software (using ectool) through the AMI BIOS firmware, with > > > coreboot, > > > we only get 0xFF returned, I don't believe we had time to > > > investigate > > > the cause for that. > > > > > > Sorry for not having any better news for you, but I hope this > > > helps a > > > little you at least. > > > > > > Good luck, > > > Youness. > > > > > > > > > On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer > > > <hanetzer(a)startmail.com> wrote: > > > > Greetings, > > > > > > > > Currently working on a port for the hp g7-2247us laptop, which > > > > features > > > > an ene kb3940q ec, which hopefully should be very similar to > > > > the kb3930 > > > > ec, which has a datasheet available to the public in a few > > > > places. > > > > > > > > Said similar ec is used in some OLPC devices, as well as some > > > > purism > > > > devices, and I was hoping someone in the list would have some > > > > contacts > > > > with those guys so as to be able to use their ec firmware as a > > > > bit of a > > > > reference design, but the OLPC ec firmware repo has a 'private' > > > > submodule which I cannot access and I simply cannot find a repo > > > > for the > > > > purism ec firmware to reference. > > > > > > > > Any assistance you could provide on this matter would be > > > > greatly > > > > appreciated. > > > > > > > > Marty E. Plummer > > > > > > > > -- > > > > coreboot mailing list: coreboot(a)coreboot.org > > > > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > > > -- > > > coreboot mailing list: coreboot(a)coreboot.org > > > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

2 1

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

16 Feb '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 15 new defect(s) introduced to coreboot found with Coverity Scan. 29 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 15 of 15 defect(s) ** CID 1386126: Null pointer dereferences (REVERSE_INULL) /src/mainboard/siemens/mc_bdx1/mainboard.c: 266 in pca9538_get_dev() ________________________________________________________________________________________________________ *** CID 1386126: Null pointer dereferences (REVERSE_INULL) /src/mainboard/siemens/mc_bdx1/mainboard.c: 266 in pca9538_get_dev() 260 { 261 struct device *dev = NULL; 262 do { 263 dev = dev_find_path(dev, DEVICE_PATH_I2C); 264 if (dev->path.i2c.device == PCA9538_SLAVE_ADR) 265 break; >>> CID 1386126: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "dev" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 266 } while (dev); 267 return dev; 268 } 269 270 271 BOOT_STATE_INIT_ENTRY(BS_DEV_ENUMERATE, BS_ON_ENTRY, wait_for_legacy_dev, NULL); ** CID 1384426: (FORWARD_NULL) /dev/cb-build/coreboot-coverity.0/PCENGINES_APU5/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/PCENGINES_APU4/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/PCENGINES_APU3/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/ODE_E21XX/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/GOOGLE_GRUNT/libagesa/amdlib.c: 489 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/GOOGLE_KAHLEE/libagesa/amdlib.c: 489 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_LAMAR/libagesa/amdlib.c: 492 in LibAmdCLFlush() /src/vendorcode/amd/agesa/common/amdlib.c: 444 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_BETTONG/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_GARDENIA/libagesa/amdlib.c: 489 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/PCENGINES_APU2/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/libagesa/amdlib.c: 492 in LibAmdCLFlush() ________________________________________________________________________________________________________ *** CID 1384426: (FORWARD_NULL) /dev/cb-build/coreboot-coverity.0/PCENGINES_APU5/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/PCENGINES_APU4/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/PCENGINES_APU3/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/ODE_E21XX/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/GOOGLE_GRUNT/libagesa/amdlib.c: 489 in LibAmdCLFlush() 483 UINT8 *address32; 484 UINTN Index; 485 address32 = 0; 486 hwcrSave = SetFsBase (Address); 487 for (Index = 0; Index < Count; Index++){ 488 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 489 _mm_clflush_fs (&address32 [Index * 64]); 490 } 491 RestoreHwcr (hwcrSave); 492 } 493 494 /dev/cb-build/coreboot-coverity.0/GOOGLE_KAHLEE/libagesa/amdlib.c: 489 in LibAmdCLFlush() 483 UINT8 *address32; 484 UINTN Index; 485 address32 = 0; 486 hwcrSave = SetFsBase (Address); 487 for (Index = 0; Index < Count; Index++){ 488 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 489 _mm_clflush_fs (&address32 [Index * 64]); 490 } 491 RestoreHwcr (hwcrSave); 492 } 493 494 /dev/cb-build/coreboot-coverity.0/AMD_LAMAR/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /src/vendorcode/amd/agesa/common/amdlib.c: 444 in LibAmdCLFlush() 438 UINT8 *address32; 439 UINTN Index; 440 address32 = 0; 441 hwcrSave = SetFsBase (Address); 442 for (Index = 0; Index < Count; Index++){ 443 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 444 _mm_clflush_fs (&address32 [Index * 64]); 445 } 446 RestoreHwcr (hwcrSave); 447 } 448 #endif //__SSE3__ 449 /dev/cb-build/coreboot-coverity.0/AMD_BETTONG/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/AMD_GARDENIA/libagesa/amdlib.c: 489 in LibAmdCLFlush() 483 UINT8 *address32; 484 UINTN Index; 485 address32 = 0; 486 hwcrSave = SetFsBase (Address); 487 for (Index = 0; Index < Count; Index++){ 488 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 489 _mm_clflush_fs (&address32 [Index * 64]); 490 } 491 RestoreHwcr (hwcrSave); 492 } 493 494 /dev/cb-build/coreboot-coverity.0/PCENGINES_APU2/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 ** CID 1384425: Control flow issues (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 371 in clear_gpe_status() ________________________________________________________________________________________________________ *** CID 1384425: Control flow issues (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 371 in clear_gpe_status() 365 return gpe0_sts; 366 } 367 368 /* Clear all GPE status and return "standard" GPE event status */ 369 u32 clear_gpe_status(void) 370 { >>> CID 1384425: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_3_bits[gpe0_sts_3_...". 371 const char *gpe0_sts_3_bits[] = { 372 [1] = "HOTPLUG", 373 [2] = "SWGPE", 374 [6] = "TCO_SCI", 375 [7] = "SMB_WAK", 376 [9] = "PCI_EXP", ** CID 1384424: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 329 in gpio_input() ________________________________________________________________________________________________________ *** CID 1384424: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 329 in gpio_input() 323 struct pad_config cfg = PAD_CFG_GPI(gpio, UP_20K, DEEP); 324 gpio_configure_pad(&cfg); 325 } 326 327 void gpio_input(gpio_t gpio) 328 { >>> CID 1384424: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 329 struct pad_config cfg = PAD_CFG_GPI(gpio, NONE, DEEP); 330 gpio_configure_pad(&cfg); 331 } 332 333 void gpio_output(gpio_t gpio, int value) 334 { ** CID 1384423: Insecure data handling (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 192 in te_relocate() ________________________________________________________________________________________________________ *** CID 1384423: Insecure data handling (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 192 in te_relocate() 186 187 if (type == EFI_IMAGE_REL_BASED_HIGHLOW) { 188 uint32_t *reloc_addr; 189 uint32_t val; 190 191 offset += rva_offset; >>> CID 1384423: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "offset" as an index to pointer "te_base". 192 reloc_addr = (void *)&te_base[offset]; 193 val = read_le32(reloc_addr); 194 195 printk(FSP_DBG_LVL, "Adjusting %p %x -> %x\n", 196 reloc_addr, val, val + adj); 197 write_le32(reloc_addr, val + adj); ** CID 1384422: (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 151 in print_smi_status() /src/southbridge/intel/lynxpoint/pmutil.c: 158 in print_smi_status() ________________________________________________________________________________________________________ *** CID 1384422: (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 151 in print_smi_status() 145 return smi_sts; 146 } 147 148 /* Print SMI status bits */ 149 static u32 print_smi_status(u32 smi_sts) 150 { >>> CID 1384422: (DEADCODE) >>> Execution cannot reach this statement: "smi_sts_bits[smi_sts_bits@d...". 151 const char *smi_sts_bits[] = { 152 [2] = "BIOS", 153 [3] = "LEGACY_USB", 154 [4] = "SLP_SMI", 155 [5] = "APM", 156 [6] = "SWSMI_TMR", /src/southbridge/intel/lynxpoint/pmutil.c: 158 in print_smi_status() 152 return smi_sts; 153 } 154 155 /* Print SMI status bits */ 156 static u32 print_smi_status(u32 smi_sts) 157 { >>> CID 1384422: (DEADCODE) >>> Execution cannot reach this statement: "smi_sts_bits[smi_sts_bits@d...". 158 const char *smi_sts_bits[] = { 159 [2] = "BIOS", 160 [3] = "LEGACY_USB", 161 [4] = "SLP_SMI", 162 [5] = "APM", 163 [6] = "SWSMI_TMR", ** CID 1384421: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 338 in print_tco_status() /src/soc/intel/broadwell/pmutil.c: 282 in print_tco_status() ________________________________________________________________________________________________________ *** CID 1384421: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 338 in print_tco_status() 332 return tco_sts & tco_en; 333 } 334 335 /* Print TCO status bits */ 336 static u32 print_tco_status(u32 tco_sts) 337 { >>> CID 1384421: (DEADCODE) >>> Execution cannot reach this statement: "tco_sts_bits[tco_sts_bits@d...". 338 const char *tco_sts_bits[] = { 339 [0] = "NMI2SMI", 340 [1] = "SW_TCO", 341 [2] = "TCO_INT", 342 [3] = "TIMEOUT", 343 [7] = "NEWCENTURY", /src/soc/intel/broadwell/pmutil.c: 282 in print_tco_status() 276 return tco_sts & tco_en; 277 } 278 279 /* Print TCO status bits */ 280 static u32 print_tco_status(u32 tco_sts) 281 { >>> CID 1384421: (DEADCODE) >>> Execution cannot reach this statement: "tco_sts_bits[tco_sts_bits@d...". 282 const char *tco_sts_bits[] = { 283 [0] = "NMI2SMI", 284 [1] = "SW_TCO", 285 [2] = "TCO_INT", 286 [3] = "TIMEOUT", 287 [7] = "NEWCENTURY", ** CID 1384420: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 335 in gpio_output() ________________________________________________________________________________________________________ *** CID 1384420: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 335 in gpio_output() 329 struct pad_config cfg = PAD_CFG_GPI(gpio, NONE, DEEP); 330 gpio_configure_pad(&cfg); 331 } 332 333 void gpio_output(gpio_t gpio, int value) 334 { >>> CID 1384420: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 335 struct pad_config cfg = PAD_CFG_GPO(gpio, value, DEEP); 336 gpio_configure_pad(&cfg); 337 } 338 339 int gpio_get(gpio_t gpio_num) 340 { ** CID 1384419: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 323 in gpio_input_pullup() ________________________________________________________________________________________________________ *** CID 1384419: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 323 in gpio_input_pullup() 317 struct pad_config cfg = PAD_CFG_GPI(gpio, DN_20K, DEEP); 318 gpio_configure_pad(&cfg); 319 } 320 321 void gpio_input_pullup(gpio_t gpio) 322 { >>> CID 1384419: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 323 struct pad_config cfg = PAD_CFG_GPI(gpio, UP_20K, DEEP); 324 gpio_configure_pad(&cfg); 325 } 326 327 void gpio_input(gpio_t gpio) 328 { ** CID 1384418: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1384418: Memory - corruptions (OVERRUN) /src/soc/mediatek/mt8173/i2c.c: 327 in platform_i2c_transfer() 321 { 322 int ret = 0; 323 int i; 324 int read; 325 326 for (i = 0; i < seg_count; i++) { >>> CID 1384418: Memory - corruptions (OVERRUN) >>> Overrunning struct type i2c_msg of 16 bytes by passing it to a function which accesses it at byte offset 16. 327 if (mtk_i2c_should_combine(&segments[i], seg_count - i)) { 328 read = I2C_WRITE_READ_MODE; 329 } else { 330 read = (segments[i].flags & I2C_M_RD) ? 331 I2C_READ_MODE : I2C_WRITE_MODE; 332 } ** CID 1384417: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 429 in clear_lpt_gpe_status() /src/southbridge/intel/lynxpoint/pmutil.c: 456 in clear_lpt_gpe_status() ________________________________________________________________________________________________________ *** CID 1384417: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 429 in clear_lpt_gpe_status() 423 return gpe0_sts; 424 } 425 426 /* Print, clear, and return LynxPoint-H GPE0 status */ 427 static u32 clear_lpt_gpe_status(void) 428 { >>> CID 1384417: (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_bits_low[gpe0_sts_...". 429 const char *gpe0_sts_bits_low[] = { 430 [1] = "HOTPLUG", 431 [2] = "SWGPE", 432 [6] = "TCO_SCI", 433 [7] = "SMB_WAK", 434 [8] = "RI", /src/southbridge/intel/lynxpoint/pmutil.c: 456 in clear_lpt_gpe_status() 450 [27] = "GPIO11", 451 [28] = "GPIO12", 452 [29] = "GPIO13", 453 [30] = "GPIO14", 454 [31] = "GPIO15", 455 }; >>> CID 1384417: (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_bits_high[gpe0_sts...". 456 const char *gpe0_sts_bits_high[] = { 457 [3] = "GPIO27", 458 [6] = "WADT", 459 [24] = "GPIO17", 460 [25] = "GPIO19", 461 [26] = "GPIO21", ** CID 1384416: (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 102 in print_pm1_status() /src/southbridge/intel/lynxpoint/pmutil.c: 109 in print_pm1_status() ________________________________________________________________________________________________________ *** CID 1384416: (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 102 in print_pm1_status() 96 return pm1_sts; 97 } 98 99 /* Print PM1 status bits */ 100 static u16 print_pm1_status(u16 pm1_sts) 101 { >>> CID 1384416: (DEADCODE) >>> Execution cannot reach this statement: "pm1_sts_bits[pm1_sts_bits@d...". 102 const char *pm1_sts_bits[] = { 103 [0] = "TMROF", 104 [4] = "BM", 105 [5] = "GBL", 106 [8] = "PWRBTN", 107 [10] = "RTC", /src/southbridge/intel/lynxpoint/pmutil.c: 109 in print_pm1_status() 103 return pm1_sts; 104 } 105 106 /* Print PM1 status bits */ 107 static u16 print_pm1_status(u16 pm1_sts) 108 { >>> CID 1384416: (DEADCODE) >>> Execution cannot reach this statement: "pm1_sts_bits[pm1_sts_bits@d...". 109 const char *pm1_sts_bits[] = { 110 [0] = "TMROF", 111 [4] = "BM", 112 [5] = "GBL", 113 [8] = "PWRBTN", 114 [10] = "RTC", ** CID 1384415: Control flow issues (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 481 in clear_lpt_lp_gpe_status() ________________________________________________________________________________________________________ *** CID 1384415: Control flow issues (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 481 in clear_lpt_lp_gpe_status() 475 gpe0_sts_bits_low); 476 } 477 478 /* Print, clear, and return LynxPoint-LP GPE0 status */ 479 static u32 clear_lpt_lp_gpe_status(void) 480 { >>> CID 1384415: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_4_bits[gpe0_sts_4_...". 481 const char *gpe0_sts_4_bits[] = { 482 [1] = "HOTPLUG", 483 [2] = "SWGPE", 484 [6] = "TCO_SCI", 485 [7] = "SMB_WAK", 486 [9] = "PCI_EXP", ** CID 1384414: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 317 in gpio_input_pulldown() ________________________________________________________________________________________________________ *** CID 1384414: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 317 in gpio_input_pulldown() 311 const struct pad_community *comm = gpio_get_community(pad); 312 return comm->port; 313 } 314 315 void gpio_input_pulldown(gpio_t gpio) 316 { >>> CID 1384414: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 317 struct pad_config cfg = PAD_CFG_GPI(gpio, DN_20K, DEEP); 318 gpio_configure_pad(&cfg); 319 } 320 321 void gpio_input_pullup(gpio_t gpio) 322 { ** CID 1260798: Incorrect expression (IDENTICAL_BRANCHES) /src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/cpuF15Utilities.c: 1038 in F15HtPhyOverrideDllCompensation() ________________________________________________________________________________________________________ *** CID 1260798: Incorrect expression (IDENTICAL_BRANCHES) /src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/cpuF15Utilities.c: 1038 in F15HtPhyOverrideDllCompensation() 1032 1033 if (!IsEarlyRevProcessor || IsHardwareReportingComp) { 1034 // Process all the sublink 0's and then all the sublink 1's that are at HT3 frequency. 1035 for (Sublink = 0; Sublink < 2; Sublink++) { 1036 CapabilitySet = StartingCapabilitySet; 1037 Link = 0; >>> CID 1260798: Incorrect expression (IDENTICAL_BRANCHES) >>> Ternary expression on condition "Sublink == 0UL" has identical then and else expressions: "1ULL". Should one of the expressions be modified, or the entire ternary expression replaced? 1038 DesiredLinkFeats.HtPhyLinkValue = ((Sublink == 0) ? HTPHY_LINKTYPE_SL0_HT3 : HTPHY_LINKTYPE_SL0_HT3); 1039 while (FamilySpecificServices->NextLinkHasHtPhyFeats ( 1040 FamilySpecificServices, 1041 &CapabilitySet, 1042 &Link, 1043 &DesiredLinkFeats, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Postcode at Lenovo x230
by Rafael Machado 16 Feb '18

16 Feb '18

Hi everyone Since here are the most skilled professions I've seeing I believe someone can help me. I have a Lenovo x230, and I'll would like to install coreboot in it to start to understand how it works, and in future start to help the community, as soon as I have the knowledge for that. Last week I did a test that makes my progress stop. Just for fun, and to check how the commercial bios works, I connected a postcard on the wireless slot (as far as I know this is a pcie slot). I already did that with other notebooks I have and nothing wrong happened. The problem is that this time, with this x230, after I connected the postcard and turned the system on, the system stopped to boot. And the post card does not stop at a specific post code. What happens now, is that every time I turn the system on, the battery led blinks 3 times, being two blinks followed by a 1 second stop and after that the last blink, and the system reboots. The post card I'm using is this: https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnost… So my questions are: -Does someone believe this postcard could have bricked the system? (Why?) -Any idea about how to solve that? My next test will be to write a coreboot build at this system using buspirate, but since I'll only have time for this next week, I would like to have some things to think about, this is why I sent this e-mail before doing the coreboot flash test. Any comment will be helpful. Thanks and Regards Rafael R. Machado

1 0

Serial input / output with SeaBIOS 1.11.0
by Piotr Kubaj 15 Feb '18

15 Feb '18

Hi, I've upgraded my coreboot to tag 4.7. As a payload I use SeaBIOS. I want to use the new feature of serial communication from SeaBIOS. The issue I have is that there's only serial output (meaning I can see the SeaBIOS menu on serial), but pressing any key on keyboard via serial doesn't do anything - I can only control SeaBIOS via keyboard plugged directly to the board, not via serial. Does anyone have the same issue? I use AsRock E350M1 board. I didn't create a custum SeaBIOS config, I just use the default one. -- ________________________ / Accordion, n.: \ | | \ A bagpipe with pleats. / ------------------------ \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

2 2

External flashing PCI-e RAID card firmware
by Taiidan＠gmx.com 14 Feb '18

14 Feb '18

I am contemplating the purchase of an ASUS PIKE for my KGPE-D16 and I was wondering if anyone here knows if it is possible to externally re-flash them. I notice a SOIC-8 chip on the front of the card and I imagine the firmware is there, does it entail simply hooking up a test clip and using flashrom as one would with a motherboard? ....20% chance the manufacturers utility performs some type of secret sauce that is required for it to function.

2 1

inteltool and sys/io.h
by Trammell Hudson 14 Feb '18

14 Feb '18

When cross compiling inteltool with musl-libc the <sys/io.h> header is not included due to this test in inteltool.h: #if defined(__GLIBC__) #include <sys/io.h> #endif Unfortunately I'm not sure what the right test is here, since the musl libc team is opposed to having a __MUSL__ define: http://openwall.com/lists/musl/2013/03/29/13 -- Trammell

4 3

Re: [coreboot] Asus AM1I-A
by Taiidan＠gmx.com 14 Feb '18

14 Feb '18

On 02/14/2018 01:40 AM, Gergely Kiss wrote: > Maybe the best way to see this is to try virtualizing some hardware? Coreboot AGESA used on AM1 doesn't support IOMMU :[ and of course the default bios doesn't either. There is no IOMMU device in lspci/dmesg so passing hardware doesn't work. I know other coreboot AGESA fam16 platforms support it so I imagine it can't be that difficult for someone to add, but I do not have the skills to do this especially without the documentation. This would be a nice little embedded server board if it had IOMMU. Thanks for your information!

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