coreboot December 2018

coreboot@coreboot.org

52 participants
62 discussions

Status on Dell OptiPlex 7010 support
by Kumonie Williams 30 Dec '18

30 Dec '18

Hello there, I have a question regarding coreboot. I was wondering if work was still being done to port coreboot to the Dell OptiPlex 7010. I was looking at commit 882d3c3574cc24f1bcf16b71c5090cc71ef725a6, but it seems the board didn’t boot at that stage in time. I have also not found much information regarding 4f19f4a7ebe7783830343d5ffc917142266fabf9 either, so I was wondering if work was still being done to port coreboot to the OptiPlex 7010, given its stock firmware doesn’t really work that great (I'd be happy to elaborate), even at revision A29, so I wanted to replace it with coreboot. Thanks.

4 9

Dell R610 Support
by Ed Hau 29 Dec '18

29 Dec '18

Hello, I just started looking into adding support for the dell r610. This is mostly because you can get them really cheap and they perform well for my type of workloads. However looking at the wiki it looks like I have my work cut out for me if I am able to do this at all. From the following dump it looks like I have a currently unsupported chipset, cpu, and superIO. $ root@plex-8316f3de71:~# dmidecode -t 2 # dmidecode 3.1 Getting SMBIOS data from sysfs. SMBIOS 2.6 present. Handle 0x0200, DMI type 2, 9 bytes Base Board Information Manufacturer: Dell Inc. Product Name: 0K399H Version: A03 Serial Number: ..CN697029680164. Asset Tag: Not Specified $ root@plex-8316f3de71:~# superiotool -d superiotool r6637 Found SMSC EMC2700LPC (id=0x67, rev=0x01) at 0x2e No dump available for this Super I/O $ root@plex-8316f3de71:~# inteltool CPU: ID 0x106a5, Processor Type 0x0, Family 0x6, Model 0x1a, Stepping 0x5 Northbridge: 8086:3403 (unknown) Southbridge: 8086:2918 (ICH9) It looks like I will have to contact SMSC which was acquired by microchip in 2012 so hopefully they are still able to give me the datasheet. Additionally I will need to get the datasheet from intel for CPU north/south bridge which from the docs sounds like it might take a while if they will even give it to me at all. Does this seem like a good place to start? I wasn't able to find much outside of https://www.coreboot.org/Developer_Manual so figured I would ask for a little bit of help getting started on the mailing list first. Thanks for looking

3 8

Re: Asus Chromebox Panther: no HW RNG?
by Grant Grundler 28 Dec '18

28 Dec '18

To close off this thread: installing rng-tools5 worked for me. Per guidance in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898814#62 Though I tried, I couldn't verify the particular commit I pointed out was the culprit: with and without that commit got the "crng init done" in ~7.5 seconds repeatedly. And additional code changes in the kernel corrected this issue for most users. With rng-tools5 and debian linux-image-4.19.0-1-amd64 installed, "crng init done" message shows up in 5.9s after booting. cheers, grant On Sun, Dec 23, 2018 at 7:28 PM Grant Grundler <grantgrundler(a)gmail.com> wrote: > > On Sat, Dec 22, 2018 at 12:05 AM Angel Pons <th3fanbus(a)gmail.com> wrote: > > > > Hello, > > > > On Sat, Dec 22, 2018, 08:50 Grant Grundler <grantgrundler(a)gmail.com wrote: > >> > >> On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov <qmastery16(a)gmail.com> wrote: > >> > > >> > Sorry but I think that relying on Intel RNG is a _Terrible_ idea > >> > regarding the security and not sure you should be pursuing it. > >> > >> What I'm pursueing is a reasonable initialization time so > >> wpa_supplicant can start. 555 seconds is not reasonable: > >> [ 555.496678] random: crng init done > >> [ 555.496678] random: crng init done > >> [ 555.496684] random: 7 urandom warning(s) missed due to ratelimiting > >> [ 560.265385] wlp2s0: authenticate with xx:xx:xx:xx:xx:xx > >> [ 560.279395] wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) > >> [ 560.281981] wlp2s0: authenticated > >> > >> intel-crng was proposed elsewhere as one solution to this problem but > >> it's clear to me now that this is not an option with the panther > >> chromebox. > >> > >> I don't recall seeing this with older kernels (have been running > >> debian on this HW since early 4.x releases) and will look at the > >> driver git logs. > > And I found one commit which I believe is likely the issue (need to > confirm this still): > commit dc12baacb95f205948f64dc936a47d89ee110117 > Author: Theodore Ts'o <tytso(a)mit.edu> > Date: Wed Apr 11 14:58:27 2018 -0400 > > random: use a different mixing algorithm for add_device_randomness() > > This change _could_ cause devices that don't have input or have > wireless networking (which doesn't get initialized until > wpa_supplicants gets a value back from /dev/random) to take a very > long time for crng_init to increment and finally determine "random: > crng init done" (in crng_reseed()). > > But I need to compare v4.17 behavior (where I think this was > introduced) with v4.16 or just revert this with my own 4.18 kernel > build. > > I'm using the following git commands to compare differences in releases: > git diff v4.16..v4.17 -- drivers/char/random.c > git diff v4.17..v4.18 -- drivers/char/random.c > > (same parameters with "log" instead of "diff" to see the corresponding > commit messages) > > ... > >> I experimented with attaching just an optical mouse and that didn't > >> seem to help. > >> Attaching a keyboard and just hitting <shift> key did seem to help > >> ("crng init done" in about 10 seconds). I'm assuming the /dev/random > >> driver is not seeing enough actiivity otherwise. > > > > I have observed the same behavior on Debian Sid, I would have to smash > > my keyboard a few times to generate enough entropy. I don't see anything > > similar with Arch Linux. Maybe it has to do with distro-specific packaging? > > I haven't checked. > > Does Arch-Linux kernel include the CL above? > ie Is Arch linux offering a 4.17 (or later) kernel? > > cheers, > grant > > ps. I realize this is the wrong forum to discuss a fix ... just want > to wrap up the conversation here to confirm my theory that this might > be a coreboot issue is wrong.

1 0

Porting Qotom Q355G4 SBC (similar to Librem 13)
by John Keates 28 Dec '18

28 Dec '18

Hi, I’m new at the board porting game but I’m interested in making a port for a single board computer that is running very similar hardware to the Librem 13 laptop and the Google Pixel 2015. It seems this board is also rather close to Intel’s own Eval Kit hardware setup, both in hardware and software regard (almost bare defaults AMI Aptio firmware). Looking at the coreboot archives, this board might have been mentioned before: https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html <https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html> but that was HTML formatted in an attachment for some reason. Board specs: - CPU: i5-5250U - SuperIO: IT8784E-I - HDA: ALC662 - Flash: 8MByte Winbond SPI SOIC8 (but flashrom detects it as opaque when using internal programmer on-device, works correctly using external SPI flasher) - 4x Intel I211 Ethernet controllers more specifically, inteltool sees: CPU: ID 0x306d4, Processor Type 0x0, Family 0x6, Model 0x3d, Stepping 0x4 Northbridge: 8086:1604 (5th generation (Broadwell family) Core Processor ULT) Southbridge: 8086:9cc3 (unknown) IGD: 8086:1626 (unknown) Linux itself sees it as Wildcat Point-LP and Broadwell-U which makes sense. It has a running ME, but there is an unpopulated header (ME1) which when shorted seems to kill it or put it in manufacturing mode (soldered in a pin header and plugged in a jumper): MEI found: [8086:9cba] Wildcat Point-LP MEI Controller #1 ME Status : 0x1e040185 ME Status 2 : 0x10522106 ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : Bring up ME: Current Operation Mode : Security Override via Jumper ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : 0x52 When not using the jumper, flashrom can’t read anything using the internal programmer mode, but when plugging the jumper in, it can read it. Output is not the same as reading the SPI flash chip offline externally, so some of the flash it probably still hidden by the PCH as it always does. There are exposed pads near the Realtek ALC chip which makes it really easy to pull GPIO33 to DVDD and disable flash descriptor security. So far so good, the hardware has easy-to-reach points to get to the flash, ME jumper and PCH straps. The firmware isn’t very custom, and neither is the board (except the four ethernet controllers/ports). My next steps were: cp -R the Purism directory to Qotom, remove all the Librem15 stuff, rename the Librem13 to Q3XXG4 and remove the EC references as this board doesn’t have an EC. At this point, I’m not sure what to do next, besides the text in board_info.txt (both the vendor directory and the variant directories) I’ll probably have to make sure: - acpi_tables.c has the correct tables, unless I can use the (generic looking) contents the Librem 13 uses, which doe acpi_init_gnvs, and acpi_create_madt_lapics + acpi_create_madt_ioapic - there is fadt.c which seems rather generic as well. - gpio.h is probably depending on the PCH used? Seems to be generic for this PCH as well - hda_verb.c seems to relate to the audio system, but I don’t care about it all that much at this time. The Librem 13 uses the ALC269 which has some differences to the ALC662, configuring it wrong probably just makes the chip sad and audio pin routing not work - mainboard.c contains mainboard_enable and some calls for the GMA chip (install_intel_vga_int15_handler and some constants), probably the same accross this broadwell series - romstage.c initialises the GPIOs does some PEI data copy/memset and then romstage_common (which probably is around or before the CAR stage?) - acpi/mainboard.asl is empty, not sure what part of the existing ACPI I should dump in there I turned the board into a variant, because Qotom has a number of boards that mostly differ in i3 vs i5 and more ethernet ports vs. more serial ports models. I named the variant q3xxg4 but I think we can do better as the PCB has a revision number printed on it, indicating more variants. It looks like I’ll need to build some sort of devicetree.cb, perhaps by hand or converted from a ACPI dump from a running system? Then there is pei_data.c which seems to set the specifics for the hardware, the labels and locations. While it is pretty close to the Librem 13 there as well (USB3 ports, USB2 ports) some of the locations need to be changed, and the camera, bluetooth, and speakers removed). Not sure how this relates to what is in the device tree and any *.asl files. The old wiki and it’s porting guide isn’t up to date as far as I know, but I haven’t found a new guide or set of docs that shows how to read/source information from a running system and write it into a new mainboard definition. I’ll probably need to get the GbE region from the old firmware, ME too, but what other parts of data (ACPI tables? PEI data?)I need to get and how to fill out that data into the mainboard definition isn’t very clear to me. This device has a GPIO header, and two serial ports (one external DB9, one internal header), so getting debug data out should be possible, but just randomly building an image and flashing it in to the SPI chip probably gets me nothing until I have at least configured the serial port for coreboot to spit out debug data. I’m not sure if I need to get the FSP from Intel or if I should extract the one from the current firmware. Any guidance would be appreciated. Regards, John

6 9

mailing list changes
by Patrick Georgi 24 Dec '18

24 Dec '18

Hi everybody, I took the opportunity of the slow season to make some changes to the mail server configuration: it's moved to another server and the mailing lists are now driven by mailman3 (before: mailman2) with hyperkitty as mailing list archive system (before: pipermail). I'm still importing and otherwise handling the archives, but the mailing list should work now. For you, I hope that the only impact will be that mailman3 has a new user management concept that manages users on a per-server basis and not per mailing list like mailman2 did. This means that your mailman credentials are void and you'll have to request new ones. If you notice anything odd with the mailing list, I'd appreciate a heads-up. Thanks, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

2 1

Re: [coreboot] Asus Chromebox Panther: no HW RNG?
by Ivan Ivanov 23 Dec '18

23 Dec '18

Sorry but I think that relying on Intel RNG is a _Terrible_ idea regarding the security and not sure you should be pursuing it. If you really want a hardware RNG that is also secure, why not take a look at some USB dongles like FST-01 or Librem key? Here is a ( sadly deleted recently! ) Wikipedia comparison page - https://web.archive.org/web/20180812092012/https://en.wikipedia.org/wiki/Co… - You can check it to find the best price/performance USB TRNG dongle which is also open hardware Best regards, Ivan Ivanov вт, 27 нояб. 2018 г. в 22:50, Grant Grundler <grantgrundler(a)gmail.com>: > > On Tue, Nov 27, 2018 at 4:10 AM Nico Huber <nico.huber(a)secunet.com> wrote: > > > > Hi Grant, > > > > I don't know how it is supposed to work on Haswell, but can give you > > some pointers anyway. > > > > tl;dr I don't think you are looking for a PCI device. > > If intel-rng support is required, a PCI device will be advertised > because of how the linux kernel binds PCI devices to drivers. See > "alias" field of "modinfo intel-rng" as an example. > > One of the search results pointed at a response that said "load > intel-rng driver" as the solution to this problem... that's the only > reason I'm exploring this path. > > > Am 27.11.18 um 08:11 schrieb Grant Grundler: > > > Asus Chromebox (Panther) with Celeron 2995U processor is supposed to > > > have a HW Random Number Generator: > > > https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache… > > > > > > (Intel calls it Secure Key) > > > > > > But "modprobe intel-rng" is failing with "No such device" (Debian > > > 4.18.0-2-amd64 kernel). > > > > This driver is for very old Firmware Hub (FWH) hardware which would > > be controlled through the LPC PCI device. You have such a PCI device > > (00:1f.0) but there's no FWH to be expect with Haswell. > > Hrm. OK. But that would explain why intel-rng driver only binds with > PCI devices. > > > What you are probably looking for is the RDRAND instruction. I don't > > know if it can be controlled by the firmware, but would check first if > > your OS is prepared to make use of it. > > Linux kernel has supported RDRAND for a long time. There is even a > public debate about *excluding* RDRAND use since some people were > hypothesizing that RDRAND was "compromised" by Intel so "goverment > agencies" could break encrypted traffic which used RDRAND exclusively > to generate encryption keys. Linux kernel does NOT exclusively use > RDRAND and Ted Tyso made compelling arguments that RDRAND would still > add "entropy" to key generation. > > What I don't know is how linux figures out it can or should use > RDRAND. RDRAND appears to be a "CPU feature": > > arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND > ( 4*32+30) /* RDRAND instruction */ > > And as notedin original email, Intel says this CPU (Celeron 2995U) > supports "Secure Key" which is the new marketing name for HW RNG > support (could be only via RDRAND now). > > > > > Why do I care about HW RNG? > > > Because of this: > > > ... > > > [ 8.560270] r8169 0000:01:00.0 enp1s0: link up > > > [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready > > > [19039.712644] random: crng init done > > > [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting > > > [19044.485625] wlp2s0: authenticate with ... > > > ... > > > > > > Yes, several *hours* until the crng was initialized and then > > > wpa_supplicant could start talking on WIFI. :( > > > > > > The length of the delay varies...shortest was 7 minutes. > > > > Well, even without a hardware rng, I wouldn't expect that. > > Exactly. I didn't either. My NUC5 completes typically in 3 second from > the time the kernel is loaded. But this is a different CPU (Intel Core > i5 6260) and completely different firmware (If Coreboot was available > for this, I'd prefer Coreboot). > > > With antennas > > available, I would say after 10s for the paranoid there should be enough > > entropy available. But that's probably just how I'd do OS development > > (and depends on what the wifi driver can do). > > I don't know if the kernel has access to any radios (or antennas) > until the 80211 link is brought up... which in turn won't happen until > wpa_supplicant is running. So something else is wrong here. My > suspicion is still on Coreboot not providing something that tells the > linux kernel a quick method to generate random numbers. > > I saw Matt DeVillier's response as well and I'll follow up once I've > updated the SeaBIOS firmware, installed rng-tools5, and determined > which CPU features are advertised by both Panther and NUC CPUs. For > some reason my "phone home" (SSH) is getting rejected right now. :( > > cheers, > grant > > > Nico > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

3 4

Re: [coreboot] Asus Chromebox Panther: no HW RNG?
by Angel Pons 22 Dec '18

22 Dec '18

Hello, On Sat, Dec 22, 2018, 08:50 Grant Grundler <grantgrundler(a)gmail.com wrote: > On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov <qmastery16(a)gmail.com> wrote: > > > > Sorry but I think that relying on Intel RNG is a _Terrible_ idea > > regarding the security and not sure you should be pursuing it. > > What I'm pursueing is a reasonable initialization time so > wpa_supplicant can start. 555 seconds is not reasonable: > [ 555.496678] random: crng init done > [ 555.496678] random: crng init done > [ 555.496684] random: 7 urandom warning(s) missed due to ratelimiting > [ 560.265385] wlp2s0: authenticate with xx:xx:xx:xx:xx:xx > [ 560.279395] wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) > [ 560.281981] wlp2s0: authenticated > > intel-crng was proposed elsewhere as one solution to this problem but > it's clear to me now that this is not an option with the panther > chromebox. > > I don't recall seeing this with older kernels (have been running > debian on this HW since early 4.x releases) and will look at the > driver git logs. > > I was hoping someone in the Coreboot community would have some idea > why random driver isn't getting enough entropy and if coreboot isn't > advertising something that helps with the random crng initialization. > > I experimented with attaching just an optical mouse and that didn't > seem to help. > Attaching a keyboard and just hitting <shift> key did seem to help > ("crng init done" in about 10 seconds). I'm assuming the /dev/random > driver is not seeing enough actiivity otherwise. > I have observed the same behavior on Debian Sid, I would have to smash my keyboard a few times to generate enough entropy. I don't see anything similar with Arch Linux. Maybe it has to do with distro-specific packaging? I haven't checked. cheers, > grant > Best regards, Angel Pons >

1 0

Re: [coreboot] Asus Chromebox Panther: no HW RNG?
by Grant Grundler 21 Dec '18

21 Dec '18

On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov <qmastery16(a)gmail.com> wrote: > > Sorry but I think that relying on Intel RNG is a _Terrible_ idea > regarding the security and not sure you should be pursuing it. What I'm pursueing is a reasonable initialization time so wpa_supplicant can start. 555 seconds is not reasonable: [ 555.496678] random: crng init done [ 555.496678] random: crng init done [ 555.496684] random: 7 urandom warning(s) missed due to ratelimiting [ 560.265385] wlp2s0: authenticate with xx:xx:xx:xx:xx:xx [ 560.279395] wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) [ 560.281981] wlp2s0: authenticated intel-crng was proposed elsewhere as one solution to this problem but it's clear to me now that this is not an option with the panther chromebox. I don't recall seeing this with older kernels (have been running debian on this HW since early 4.x releases) and will look at the driver git logs. I was hoping someone in the Coreboot community would have some idea why random driver isn't getting enough entropy and if coreboot isn't advertising something that helps with the random crng initialization. I experimented with attaching just an optical mouse and that didn't seem to help. Attaching a keyboard and just hitting <shift> key did seem to help ("crng init done" in about 10 seconds). I'm assuming the /dev/random driver is not seeing enough actiivity otherwise. cheers, grant > If you > really want a hardware RNG that is also secure, why not take a look at > some USB dongles like FST-01 or Librem key? Here is a ( sadly deleted > recently! ) Wikipedia comparison page - > https://web.archive.org/web/20180812092012/https://en.wikipedia.org/wiki/Co… > - You can check it to find the best price/performance USB TRNG dongle > which is also open hardware > > Best regards, > Ivan Ivanov > вт, 27 нояб. 2018 г. в 22:50, Grant Grundler <grantgrundler(a)gmail.com>: > > > > On Tue, Nov 27, 2018 at 4:10 AM Nico Huber <nico.huber(a)secunet.com> wrote: > > > > > > Hi Grant, > > > > > > I don't know how it is supposed to work on Haswell, but can give you > > > some pointers anyway. > > > > > > tl;dr I don't think you are looking for a PCI device. > > > > If intel-rng support is required, a PCI device will be advertised > > because of how the linux kernel binds PCI devices to drivers. See > > "alias" field of "modinfo intel-rng" as an example. > > > > One of the search results pointed at a response that said "load > > intel-rng driver" as the solution to this problem... that's the only > > reason I'm exploring this path. > > > > > Am 27.11.18 um 08:11 schrieb Grant Grundler: > > > > Asus Chromebox (Panther) with Celeron 2995U processor is supposed to > > > > have a HW Random Number Generator: > > > > https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache… > > > > > > > > (Intel calls it Secure Key) > > > > > > > > But "modprobe intel-rng" is failing with "No such device" (Debian > > > > 4.18.0-2-amd64 kernel). > > > > > > This driver is for very old Firmware Hub (FWH) hardware which would > > > be controlled through the LPC PCI device. You have such a PCI device > > > (00:1f.0) but there's no FWH to be expect with Haswell. > > > > Hrm. OK. But that would explain why intel-rng driver only binds with > > PCI devices. > > > > > What you are probably looking for is the RDRAND instruction. I don't > > > know if it can be controlled by the firmware, but would check first if > > > your OS is prepared to make use of it. > > > > Linux kernel has supported RDRAND for a long time. There is even a > > public debate about *excluding* RDRAND use since some people were > > hypothesizing that RDRAND was "compromised" by Intel so "goverment > > agencies" could break encrypted traffic which used RDRAND exclusively > > to generate encryption keys. Linux kernel does NOT exclusively use > > RDRAND and Ted Tyso made compelling arguments that RDRAND would still > > add "entropy" to key generation. > > > > What I don't know is how linux figures out it can or should use > > RDRAND. RDRAND appears to be a "CPU feature": > > > > arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND > > ( 4*32+30) /* RDRAND instruction */ > > > > And as notedin original email, Intel says this CPU (Celeron 2995U) > > supports "Secure Key" which is the new marketing name for HW RNG > > support (could be only via RDRAND now). > > > > > > > > Why do I care about HW RNG? > > > > Because of this: > > > > ... > > > > [ 8.560270] r8169 0000:01:00.0 enp1s0: link up > > > > [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready > > > > [19039.712644] random: crng init done > > > > [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting > > > > [19044.485625] wlp2s0: authenticate with ... > > > > ... > > > > > > > > Yes, several *hours* until the crng was initialized and then > > > > wpa_supplicant could start talking on WIFI. :( > > > > > > > > The length of the delay varies...shortest was 7 minutes. > > > > > > Well, even without a hardware rng, I wouldn't expect that. > > > > Exactly. I didn't either. My NUC5 completes typically in 3 second from > > the time the kernel is loaded. But this is a different CPU (Intel Core > > i5 6260) and completely different firmware (If Coreboot was available > > for this, I'd prefer Coreboot). > > > > > With antennas > > > available, I would say after 10s for the paranoid there should be enough > > > entropy available. But that's probably just how I'd do OS development > > > (and depends on what the wifi driver can do). > > > > I don't know if the kernel has access to any radios (or antennas) > > until the 80211 link is brought up... which in turn won't happen until > > wpa_supplicant is running. So something else is wrong here. My > > suspicion is still on Coreboot not providing something that tells the > > linux kernel a quick method to generate random numbers. > > > > I saw Matt DeVillier's response as well and I'll follow up once I've > > updated the SeaBIOS firmware, installed rng-tools5, and determined > > which CPU features are advertised by both Panther and NUC CPUs. For > > some reason my "phone home" (SSH) is getting rejected right now. :( > > > > cheers, > > grant > > > > > Nico > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

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

21 Dec '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. 18 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 3 of 3 defect(s) ** CID 1397064: (UNINIT) /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 495 in find_gating_window() /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 501 in find_gating_window() ________________________________________________________________________________________________________ *** CID 1397064: (UNINIT) /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 495 in find_gating_window() 489 dramc_dbg("[Byte %d]First pass (%d, %d, %d)\n", 490 dqs, dly_coarse_large, 491 dly_coarse_0p5t, *dly_fine_xt); 492 } 493 494 if (pass_begin[dqs] == 1) >>> CID 1397064: (UNINIT) >>> Using uninitialized value "pass_count_1[dqs]". 495 pass_count_1[dqs]++; 496 497 if (pass_begin[dqs] == 1 && 498 pass_count_1[dqs] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) 499 dqs_high[dqs] = 0; 500 /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 501 in find_gating_window() 495 pass_count_1[dqs]++; 496 497 if (pass_begin[dqs] == 1 && 498 pass_count_1[dqs] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) 499 dqs_high[dqs] = 0; 500 >>> CID 1397064: (UNINIT) >>> Using uninitialized value "pass_count_1[0]". 501 if (pass_count_1[0] * DQS_GW_FINE_STEP > DQS_GW_FINE_END && 502 pass_count_1[1] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) { 503 dramc_dbg("All bytes gating window > 1 coarse_tune," 504 " Early break\n"); 505 *dly_fine_xt = DQS_GW_FINE_END; 506 *coarse_tune = GATING_END; ** CID 1397063: Control flow issues (MISSING_BREAK) /src/mainboard/google/poppy/variants/nami/mainboard.c: 244 in variant_devtree_update() ________________________________________________________________________________________________________ *** CID 1397063: Control flow issues (MISSING_BREAK) /src/mainboard/google/poppy/variants/nami/mainboard.c: 244 in variant_devtree_update() 238 case SKU_1_SYNDRA: 239 case SKU_2_SYNDRA: 240 case SKU_3_SYNDRA: 241 case SKU_4_SYNDRA: 242 case SKU_5_SYNDRA: 243 case SKU_6_SYNDRA: >>> CID 1397063: Control flow issues (MISSING_BREAK) >>> The case for value "441440U" is not terminated by a 'break' statement. 244 case SKU_7_SYNDRA: 245 pl2_id = PL2_ID_SONA_SYNDRA; 246 case SKU_0_VAYNE: 247 case SKU_1_VAYNE: 248 case SKU_2_VAYNE: 249 case SKU_0_PANTHEON: ** CID 1362515: Memory - corruptions (STRING_SIZE) ________________________________________________________________________________________________________ *** CID 1362515: Memory - corruptions (STRING_SIZE) /util/kconfig/conf.c: 606 in main() 600 case alldefconfig: 601 case randconfig: 602 name = getenv("KCONFIG_ALLCONFIG"); 603 if (!name) 604 break; 605 if ((strcmp(name, "") != 0) && (strcmp(name, "1") != 0)) { >>> CID 1362515: Memory - corruptions (STRING_SIZE) >>> Passing string "name" of unknown size to "conf_read_simple", which expects a string of a particular size. 606 if (conf_read_simple(name, S_DEF_USER)) { 607 fprintf(stderr, 608 _("*** Can't read seed configuration \"%s\"!\n"), 609 name); 610 exit(1); 611 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Announcing coreboot 4.9
by Patrick Georgi 20 Dec '18

20 Dec '18

coreboot 4.9 release notes ========================== The 4.9 release covers commit 532b8d5f25 to commit 7f520c8fe6 There is a pgp signed 4.9 tag in the git repository, and a branch will be created as needed. In the little more than 7 months since 4.8.1 we had 175 authors commit 2610 changes to master. The changes were, for the most part, all over the place, touching every part of the repository: chipsets, mainboards, tools, build system, documentation. In that time we also had 70 authors made their first commit to coreboot: Welcome and to many more! Finally, a big Thank You to all contributors who helped shape the coreboot project, community and code with their effort, no matter if through development, review, testing, documentation or by helping people asking questions on our venues like IRC or our mailing list. Clean up -------- If there's any topic to give to this release, "clean up" might be the most appropriate: There was lots of effort to bring the codebase into compliance with our coding style, to remove old idioms that we'd like to retire like the overloaded `device_t` data type, and to let features percolate through the entire tree to bring more uniformity to its parts. For example, during the coreboot 4.4 cycle, coreboot gained the notion of mainboard variants to avoid duplication of code in rather similar mainboards. Back then, this feature was developed and used mostly for the benefit of Chrome OS devices, but more recently the code for various Lenovo Thinkpads was deduplicated in the same way. Another part of cleaning up our tree is improving our tools that help developers follow coding style and avoid mistakes, as well as the infrastructure we have for automated build tests and we've seen quite some activity in that space as well. Documentation ------------- Since the last release we also moved the documentation into the repository. No need for a special wiki account to edit the documentation, and by colocating sources and documentation, it's easier to keep the latter in sync with the code, too. This effort is still under way, which is why we still host the old wiki (now read-only) in parallel to the [new documentation site](https://doc.coreboot.org) that is rendered from coreboot.git's Documentation/ directory. Blobs handling -------------- Another big change is in our blobs handling: Given that Intel now provides a reasonably licensed repository with FSP binaries, we were able to mirror it to coreboot.org and integrate it in the build system. This makes it easier to have working images out of the box for devices that depend on Intel's proprietary init code. As usual the blobs aren't part of the coreboot tree and only downloaded with the `USE_BLOBS` options. Deprecations ------------ One of the first changes to coreboot after the 4.8 release was to remove boards that didn't support certain new features and were apparently unmaintained, as discussed in the release notes of coreboot 4.6. We didn't follow up on all plans made back then to deprecate boards more aggressively: The board status reporting mechanism is still rather raw and therefore places quite a burden on otherwise sympathetic contributors of build results. Also, there will be no deprecations after 4.10: Due to its slipping schedule, coreboot 4.9 is released rather late, and as a result 4.10 will only see about 4 months of development. We considered that a rather short timeframe in which to bring old boards up to new standards, and so the next deprecation cycle may be announced with 4.10 to occur after 4.11 is released, in late 2019. General changes --------------- * Various code cleanups * Removed `device_t` in favor of `struct device*` in ramstage code * Removed unnecessary include directives * Improved adherence to coding style * Deduplicated boards by using the variants mechanism * Expand use of the postcar stage * Add bootblock compression capability: on systems that copy the bootblock from very slow flash to SRAM, allow adding a stub that decompresses the bootblock into SRAM to minimize the amount of flash reads * Rename the POWER8 architecture port to PPC64 to reflect that it isn't limited to POWER8 * Added support for booting FIT (uImage) payloads on arm64 * Added SPI flash write protection API * Implemented on Winbond * Implemented TCPA log for measured boot * Implemented GDB support for arm64 architecture in libpayload * Dropped support for unmaintained code paths * Measured boot support Added 56 mainboards ------------------- * ASROCK G41C-GS * ASROCK G41M-GS * ASROCK G41M-S3 * ASROCK G41M-VS3 R2.0 * ASROCK H81M-HDS * ASUS P5QC * ASUS P5QL-PRO * ASUS P5Q-PRO * ASUS P8H61-M-LX * ASUS P8H61-M-PRO * CAVIUM CN8100-SFF-EVB * FACEBOOK WATSON * FOXCONN D41S * GIGABYTE GA-H61M-S2PV * GOOGLE ALEENA * GOOGLE AMPTON * GOOGLE ARCADA * GOOGLE ASUKA * GOOGLE BOBBA * GOOGLE BUDDY * GOOGLE CAREENA * GOOGLE CAROLINE * GOOGLE CASTA * GOOGLE CAVE * GOOGLE DELAN * GOOGLE DRAGONEGG * GOOGLE FLEEX * GOOGLE HATCH * GOOGLE KARMA * GOOGLE KUKUI * GOOGLE LIARA * GOOGLE MEEP * GOOGLE RAMMUS * GOOGLE SARIEN * GOOGLE SENTRY * HEWLETT PACKARD HP COMPAQ 8200 ELITE SFF PC * INTEL COFFEELAKE RVP11 * INTEL COFFEELAKE RVP8 * INTEL COFFEELAKE RVPU * INTEL DG41WV * INTEL ICELAKE RVPU * INTEL ICELAKE RVPY * INTEL WHISKEYLAKE RVP * LENOVO T431S * LENOVO THINKCENTRE A58 * LENOVO W500 * LENOVO W530 * OPENCELLULAR ELGON * OPENCELLULAR ROTUNDU * OPENCELLULAR SUPABRCKV1 * SIEMENS MC-APL2 * SIEMENS MC-APL3 * SIEMENS MC-APL4 * SIEMENS MC-APL5 Dropped 71 mainboards --------------------- * AAEON PFM-540I REVB * AMD DB800 * AMD DBM690T * AMD F2950 * AMD MAHOGANY * AMD NORWICH * AMD PISTACHIO * AMD SERENGETI-CHEETAH * ARTECGROUP DBE61 * ASROCK 939A785GMH * ASUS A8N-E * ASUS A8N-SLI * ASUS A8V-E DELUXE * ASUS A8V-E SE * ASUS K8V-X * ASUS KFSN4-DRE K8 * ASUS M2N-E * ASUS M2V * ASUS M2V MX-SE * BACHMANN OT200 * BCOM WINNETP680 * BROADCOM BLAST * DIGITALLOGIC MSM800SEV * GIGABYTE GA-2761GXDK * GIGABYTE M57SLI * GOOGLE KAHLEE * GOOGLE MEOWTH * GOOGLE PURIN * GOOGLE ROTOR * GOOGLE ZOOMBINI * HP DL145-G1 * HP DL145-G3 * IEI PCISA LX-800 R10 * IEI PM LX2-800 R10 * IEI PM LX-800 R11 * INTEL COUGAR-CANYON2 * INTEL STARGO2 * IWILL DK8 HTX * JETWAY J7F2 * JETWAY J7F4K1G2E * JETWAY J7F4K1G5D * KONTRON KT690 * LINUTOP LINUTOP1 * LIPPERT HURRICANE LX * LIPPERT LITERUNNER LX * LIPPERT ROADRUNNER LX * LIPPERT SPACERUNNER LX * LOWRISC NEXYS4DDR * MSI MS7135 * MSI MS7260 * MSI MS9185 * MSI MS9282 * NVIDIA L1-2PVV * SIEMENS SITEMP-G1P1 * SUNW ULTRA40 * SUNW ULTRA40M2 * SUPERMICRO H8DME * SUPERMICRO H8DMR * TECHNEXION TIM5690 * TECHNEXION TIM8690 * TRAVERSE GEOS * TYAN S2912 * VIA EPIA-CN * VIA EPIA-M700 * VIA PC2500E * VIA VT8454C * WINENT MB6047 * WINENT PL6064 * WINNET G170 CPU changes ----------- * cpu/intel/model\_2065x,206ax,haswell: Switch to `POSTCAR_STAGE` * cpu/intel/slot\_1: Switch to different CAR setup * Dropped support for the FSP1.0 sandy-/ivy-bridge bootpath SoC changes ----------- * Added Cavium CN81xx, Intel Ice Lake and Mediatek MT8183 * Dropped Broadcom Cygnus, Lowrisc and Marvell mvmap2315 Northbridge changes ------------------- * Dropped AMD K8, VIA CN700, VIA CX700, VIA VX800 because they lack `EARLY_CBMEM` support * intel/e7505: Moved to `EARLY_CBMEM` * nb/intel/i945,e7505,pineview,x4x,gm45,i440bx: Moved to `POSTCAR_STAGE` * nb/intel/i440bx, e7505: Moved to `RELOCATABLE_RAMSTAGE` * intel/x4x: Add DDR3 support * nb/intel/pineview: Speed up fetching SPD * nb/intel/i945,gm45,x4x,pineview: Use TSEG in SMI Southbridge changes ------------------- * sb/intel/i82801{g,i,j}x, lynxpoint: Use the common ACPI pirq generator * sb/intel/i82801{g,i,j}x: Use common code to set up SMM and for the smihandler * Use common functions for PMBASE configuration Payload changes --------------- * Support initrd in uImage/FIT to be placed above 4GiB * Added documentation for uImage/FIT payloads Toolchain --------- * Update to gcc 8.1.0, binutils 2.30, IASL 20180810, clang 6 -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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