July 2020 - coreboot - mail.coreboot.org

I7-7600U(KabyLake) with Vxworks
by lionkang70＠naver.com July 22, 2020

July 22, 2020

Hi I'd like to make coreboot.rom for I7-7600U(KabyLake) to boot Vxwork with coreboot. Payload will be Vxworks 7. I've succeed to boot by using ApolloLake (Up Squared). At that time, tried Tianocore(EFI/Vxworks) and ELF Boot(Vxworks) and succeed. because I used coreboot V4.12 and it's supported for UP squared. I've got bios.bin and descriptor.bin from AMI BIOS by using ifdtool. and then added cpu_microcode_blob.bin, fspm.bin and fsps.bin and so on. can see message like below. 1. Boolblock stage 2. Rom Stage 3. Postcar Stage 4. Ram Stage 5. Vxworks Prompt. but When I make coreboot.rom for KabyLake, I can't see any message by Hiperterminal. I just can use intel / kblrvp... and added descriptor.bin and me.bin and so on. but.... not success yet... Have you ever made this chip? Do you have any kindly documentation? or I 'd like to hear exactly informations for more details. Please help me.

1 0

Intel® FSP External Architecture Specification v2.2 Has Been Released
by Desimone, Nathaniel L July 22, 2020

July 22, 2020

Hi Everyone, We are pleased to announce that the FSP External Architecture Specification v2.2 has been posted to https://www.intel.com/fsp! Highlights * Multi-Phase Silicon Initialization – A new optional API has been added to FSP-S to address some of the ongoing community feedback surrounding FSP-S. In general, the feedback has been that FSP-S is too monolithic. FspSiliconInit() does a large amount of initialization in one API call; so much that it has made integration difficult in some cases. For example, firmware update/recovery flows. To address this, a new FspMultiPhaseSiInit() API has been added which splits FSP-S into multiple parts. This allows the bootloader to add board specific code throughout the SiliconInit flow as needed. The breakdown of silicon initialization steps may vary per product and will be detailed in the Integration Guide. FspMultiPhaseSiInit() is only used in API mode. In dispatch mode, equivalent functionality can be achieved using PPIs with less complexity. * FSP Event Handlers – This new feature enables FSP to generate events messages to aid in the debugging of firmware issues. This eliminates the need for FSP to directly write debug messages to the UART. Instead FSP signals the bootloader to inform it of a new debug message. This allows the bootloader to provide board specific methods of reporting debug messages beyond the UART. This brings feature parity between dispatch mode and API mode as FSP 2.1 defined a similar method for dispatch mode. Roadmap TigerLakeFspBinPkg provides the first implementation of FSP 2.2. Tiger Lake FSP implements 2 phases for FSP-S: FspSiliconInit() will return after TCSS (“Type-C Sub System” – Integrated USB-C & Thunderbolt 4) initialization is complete. The second phase, invoked by FspMultiPhaseSiInit(), will initialize the graphics framebuffer and lock SAI/SPI writes. This allows board specific USB-C programming to be done before FSP attempts to start early video, and also provides a potentially convenient location for firmware update flows. Looking forward, our upcoming Alder Lake platform will also have FSP 2.2 support. Does Anything Need to Change in coreboot? In the strictest sense, no. FSP will only use Multi-Phase Silicon Initialization and FSP Event Handlers if the bootloader explicitly enables them. By default, they are disabled which makes the flow is fully backwards compatible with FSP 2.1. However, in order to leverage these new features coreboot will need to implement support for them. These changes were driven by community feedback and we are optimistic that they are welcome improvements.

1 0

Re: F2A85-M - amdgpu fails, integrated GPU works fine
by Mike Banon July 21, 2020

July 21, 2020

> Jan 12, 2020, 14:43 by mikebdp2(a)gmail.com: > > Solution for your coreboot + discrete GPU problems like > > amdgpu kernel bo map failed [...] error -22 > amdgpu_vram_scratch_init failed [...] error -22 > fatal error in GPU initialization > > It turned out that a fix like > https://review.coreboot.org/c/coreboot/+/38215 ( /* Set to 0xD0 > instead of 0xE0 to avoid the PCI resource allocation problems. */ > InitPost->MemConfig.BottomIo = 0xD0; // at the beginning of > board_BeforeInitPost function at board's OemCustomize.c ) that worked > for HD6670, is not enough for a huge RX590 - which is huge in all > relations, but most importantly the memory ranges! > > To get RX590 working with ASUS A88XM-E, I had to decrease a BottomIo > even further - to 0xC0 - and also to reduce the > BLDCFG_UMA_ALLOCATION_SIZE at board's buildOpts.c from 0x2000 (512MB) > to 0x1000 (256MB), - to get this extra "0xD0-0xC0"=0x10000000 room. > And then it worked perfectly, at least with DRI_PRIME=1 ./Supertuxkart > GPU offloading: ultra settings on integrated - 4 or 5 fps, with > offloading - 60 fps. I'm sure this fix will work for your other RX 5** > as well, but don't know if I should be trying to commit it to master, > since it lowers the integrated GPU's shared memory. > > RX590 is the most powerful AMD GPU which does not contain a Platform > Security Processor aka PSP (yes, they've started adding this crap to > the GPUs as well, and newer Vega / RX 5*** are all contaminated - see > for yourself at freedesktop drm/amdgpu sources) . That's why it was > really important to get RX590 working. So happy it was possible, > thanks to you all ;-) > > On Mon, Jan 13, 2020 at 2:21 AM Grzegorz Bogdał <bogdal.grzegorz(a)tutanota.com> wrote: > Great job!: ) So, A10-6800k/FX-8xxx combined with RX 590 is probably the strongest x86 desktop without PSP/ME that we'll get in this reality? Yes, if you meant x86 desktop "supported by coreboot master" - regarding the CPUs ;-) Otherwise there is a supported-by-coreboot-4.11 M5A88-V motherboard with AM3+ (maybe can put FX-9590 there, if coreboot supports and without frying it?) and KGPE-D16 with its' two Opterons 6386 SE for a large desktop. Also, PDF [link 1] at page 12 says Carrizo is the "1st ARM Trustzone Capable Performance APU", that means Kaveri and its' refresh Godavari (i.e. A10-7890K) doesn't have a PSP. A88XM-E motherboard is FM2+ socket, so theoretically it could support Godavari A10-7890K. However Balazs wrote that AGESA of Kaveri is a blob (not good!) and there's uncertainty if could get it working without getting this APU for trying. As you see, there are CPUs more powerful than A10-6800K which don't have a PSP crap but their coreboot master support is questionable. And don't want to be without coreboot, since UEFI could have many holes and stuff like Computrace which doesn't need to rely on ME/PSP to function. So yes, A10-6800K seems to be the best at the moment. I got A10-6700 only because its' quite hard to find a new A10-6800K for a reasonable price and I read about bad overclockers who played too much with core voltages and cores deteriorate, becoming unstable even at stock speeds (so one needs to underclock then). A10-6700 is the most powerful with a locked multiplier, so less attractive to overclockers and may be safer to buy used. GPUs: yes, RX590 is the most powerful GPU without PSP ! (not considering NVidia at all because of their proprietary driver tricks and hostility towards the opensource) . Although there is RX600 series [link 2], they are hard to buy and lower performance. Unlike the majority of people (who don't care about performance), I actually hoped there would be another refresh of Polaris architecture - simply because no PSP, but doesn't seem there would be more Polaris high end GPUs at the moment. As for the most powerful RX590, I suggest those which have 8400MHz memory by default - i.e. Sapphire Nitro+ parts. For myself I got a cute [link 3] SKU 11289-07-20G aka "Sapphire Nitro+ RX 590 8GB AMD 50th Anniversary Gold Edition" (golden shroud) for about 250 USD. Aside from being an AMD fanboy collector's item, it's nearly identical to 11289-01-20G aka "Special Edition" (blue shroud) - however, there were multiple hardware revisions of a Special Edition card (could be distinguished by looking at their advanced P/N product number also printed), while this Gold Edition came much later and with it I think you're guaranteed to get the latest hardware revision. Now they are sold out at many countries, but if you're lucky you could find some - although maybe for the really inflated prices like [link 4] - that's ~320, about 30% more than I paid. If you know another RX590 which is more powerful out of the box, please tell - maybe I'd get a second one! In example, here's a pretty [link 5] PowerColor Red Devil RX 590 8GB, with a neat pentagram on its' back plate ;-) But its' memory is 8000MHz by default. [1] https://github.com/mikebdp2/coreboot-related/blob/master/PHILIPPINES_PS-DBM… [2] https://en.wikipedia.org/wiki/Radeon_600_series [3] https://www.sapphiretech.com/en/consumer/nitro-rx-590-8g-g5_gold_edition [4] 133178207205 - https://www.ebay.com/itm/SAPPHIRE-AMD-RADEON-RX-590-NITRO-AMD50-GOLD-EDITIO… [5] https://www.powercolor.com/product?id=1542008942

2 6

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com July 21, 2020

July 21, 2020

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 1 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 1 of 1 defect(s) ** CID 1430549: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1430549: Null pointer dereferences (NULL_RETURNS) /src/drivers/amd/i2s_machine_dev/i2s_machine_dev.c: 34 in i2s_machine_dev_fill_ssdt() 28 29 if (dmic_select_gpio->pin_count == 0) { 30 printk(BIOS_ERR, "%s: ERROR: DMIC select GPIO required\n", dev_path(dev)); 31 return; 32 } 33 >>> CID 1430549: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "scope" when calling "acpigen_write_scope". 34 acpigen_write_scope(scope); /* Scope */ 35 acpigen_write_device(acpi_device_name(dev)); /* Device */ 36 acpigen_write_name_string("_HID", cfg->hid); 37 acpigen_write_name_integer("_UID", cfg->uid); 38 acpigen_write_name_string("_DDN", AMD_I2S_ACPI_DESC); 39 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Instruction to verify emulation on GEM5
by Vivek Gupta July 20, 2020

July 20, 2020

I am currently looking to setup AARCH64 platform simulation verification of coreboot on Gem5 simulation environment. Do we have any document/wikipage to understand the compilation and configuration process? -- Best regards, Vivek Gupta

2 3

Thinkpad X230t + Windows 7 x64 UEFI-CSM Int 10h
by psauxww＠pm.me July 20, 2020

July 20, 2020

Hello, I own a Thinkpad X230t and I encountered Coreboot project on the Internet. I enjoy FOSS stuff, and also I would like to change my WWAN/WLAN cards in my computer so I decided to switch from proprietary Lenovo UEFI firmware to Coreboot. By the way I found that those Thinkpads are well supported by the project and it is favorable model to use with Coreboot firmware. I use Windows 7 x64 in UEFI-CSM mode as my main OS. My disk is partitioned with GPT. By the way, unfortunately Windows 7 x64 only allows only these configurations: - BIOS or UEFI Legacy Mode firmware + MBR partition table and bootloader in MBR of the disk drive and/or VBR of the system partition - UEFI CSM (non-GOP, Int 10h) firmware + GPT partition table and bootloader in seperate EFI System Partition So I cannot get for example BIOS/UEFI-Legacy + GPT partition table + bootloader in Protective MBR with Windows 7. I started my experience with Coreboot building like 15 different image's using different parameters in 'make menuconfig' so I can find out what is well-suited for me. By the way I also bricked my laptop like 3 times, but that wasn't a problem because I have access to external programmer. All these builds I've made using SeaBIOS primary payload and like 1 with Tianocore. I used SeaBIOS at first because I recognized it simpler than Tianocore so first I can distinguish Coreboot features from primary payload features, and then switch to Tianocore. I got problems with libgfxinit on Xubuntu 20.04 LTS Installer (MBR SYSLINUX+grub) and also with Windows 7 x64 MBR installer, so I extracted VGA BIOS from proprietary Lenovo UEFI, included it as an Option ROM and it solved my problems. However, with SeaBIOS I couldn't access my Windows 7 x64 UEFI-CSM Int 10h HDD installation. It got stuck on Booting from Hard Drive probably because there is like NOP loop in the Protective MBR of GPT-partitioned drive. I made 3 different MBR/BIOS images on thumbdrives in order to test the SeaBIOS: - Xubuntu 20.04 Installer+LiveCD with SYSLINUX+GRUB - installed Xubuntu 20.04 LTS with GRUB - Windows 7 x64 Installer in MBR mode I got all of these running well, but I still have problem with my main OS on the HDD. Of course, with standard SeaBIOS I am not able to boot my Windows installation because it's GPT/ESP-enabled and it cannot boot from the MBR. So I changed my primary payload to Tianocore and chose to boot up the BOOTX64.EFI from Windows 7 ESP partition and it resulted with black screen having some different artifacts like few color strips. I guess that's because Tianocore is only supporting UEFI Level 3 (UEFI non-CSM) and thus it doesn't initialize Int 10h vector and assumes that the operating system will initialize graphics using UEFI GOP, which is not the case with Windows 7. In my earlier experiments, I had exactly the same artifacts when I tried to switch UEFI-CSM to UEFI-non CSM on Desktop Gigabyte motherboard with stock proprietary firmware and I gave it up, because I found out that it's impossible to have Windows 7 support UEFI Level 3 with GOP initialization. Before I found out about Coreboot I didn't even realize that BIOS/UEFI firmware can be split in 2 stages like it is in Coreboot + SeaBIOS/Tianocore. I'm looking for a solution so I can boot up my UEFI-CSM Int 10h Windows 7 x64 installation. I don't know what architecture should I be looking for: - run SeaBIOS as primary payload so it properly initializes the Int 10h along with Intel HD Graphics Option ROM, then run some sort of UEFI secondary payload - run Tianocore as primary load and force it to initialize the Int 10h using some hidden flags during compilation, or just run SeaBIOS somehow as an secondary payload By the way, how it's solved in usual proprietary UEFI-CSM firmware? Regarding first option, I found something such as DuetPkg from Tianocore/EDK-II project which allows to boot this stuff using BIOS from MBR thumbdrive/disk or even as secondary payload of SeaBIOS. Unfortunately I found out that this project was abandoned by Tianocore community like 2 years ago. I also found out patched version of Duet for Coreboot on https://www.notabs.org/coreboot/duet-payload/ , but it hasn't been maintained since 2014 and I don't know if I can trust these patches. I guess that would be the case for me, but since it hasn't been maintained for few years, maybe there's a more modern solution for my problem? As I understand Tianocore is something more than DuetPkg so I cannot use it as SeaBIOS secondary payload because some parts of it would double their responsibility with SeaBIOS routines? Regarding second option, I found on the Internet information that SeaBIOS can be compiled with option to be the CSM payload of something what is called OVMF which I understand to be Tianocore firmware for virtual machines such as qemu. Could some more experienced users (perhaps developers) give me a hint which solution I should be looking for, and maybe give some more advise about particular packages and tools which I could solve my problem by? Best regards, geekyTPuser

2 1

Resource allocator: Getting v4 back in
by Nico Huber July 19, 2020

July 19, 2020

Hello together, Furquan has landed his revert series of the new resource allocator. A little sad, but this allows us to take a deep breath and fix things without further breakage. There is already one change series on Gerrit to bring it back [1]. This one goes the most conservative way: It moves the old allocator code aside, so we can have two versions in the tree and decide per chipset/ board which one to use. I told people that I had something similar in mind. But actually, I don't like it very much. I fear, if we move things aside, they can be left behind and we might soon have to discuss platform deprecation again. It would also be harder to make changes in generic code like device/pci_device when one has to be sure that both allocators work fine. So I want to propose alternatives. The obvious one, but also slowest, is to move all chipset code forward and to test and patch all the code before we merge the new allocator again. I might underestimate the pro- blems, but I still think we could get this going within a week. Another option: we could identify the differences in the new allocator that had a part in the breakage and only provide a backward compatible implementation for those. Actually, I think it's only one: the resource constraining strategy for the domain. To make this compatible, we could a) drop all but the biggest memrange below 4G for the domain, and b) assign/steal resources from the end of the memrange at the domain level. It would closely mimic what the old code tried to achieve, so seems safe, somehow. I can write patches for the latter, if we want to try this way. Nico [1] https://review.coreboot.org/c/coreboot/+/41442/ PS. Had some random thoughts I don't want to forget but didn't know where to put them down: * Debug messages. There is a lot of BIOS_SPEW (was already like this in the old code). Things that are only printed once per pass per bridge shouldn't be considered SPEW, IMO. * The above-4G memrange should be aligned to a power of 2 for better MTRR usage (if that isn't the case already?).

3 4

HD Scania: I’m on a Sony laptop, but there isn’t an vendor option for Sony mainboards
by hdscania＠firemail.cc July 19, 2020

July 19, 2020

My LinuxQuestions.org issues asking for flashing Coreboot on Sony, that should never have been tested or even done before, but please still read them there, then reply to me here, 1. https://www.linuxquestions.org/questions/linux-hardware-18/any-official-cor… 2. https://www.linuxquestions.org/questions/linux-hardware-18/issues-flashing-… 3. https://www.linuxquestions.org/questions/linux-hardware-18/how-do-i-flash-c… As for the below mainboard choices, my Sony laptop is modelled VPCCB17FG, Intel i7-2620M cores, AMD graphics, Intel HM65 chipsets, AMI legacy BIOS, how to choose for my case? Mainboard vendor 1. 51NB (VENDOR_51NB) (NEW) 2. ADLINK (VENDOR_ADLINK) (NEW) 3. AMD (VENDOR_AMD) (NEW) 4. AOpen (VENDOR_AOPEN) (NEW) 5. Apple (VENDOR_APPLE) (NEW) 6. ASROCK (VENDOR_ASROCK) (NEW) 7. ASUS (VENDOR_ASUS) (NEW) 8. BAP (VENDOR_BAP) (NEW) 9. Biostar (VENDOR_BIOSTAR) (NEW) 10. Cavium (VENDOR_CAVIUM) (NEW) 11. CompuLab (VENDOR_COMPULAB) (NEW) 12. ELMEX (VENDOR_ELMEX) (NEW) > 13. Emulation (VENDOR_EMULATION) (NEW) 14. Facebook (VENDOR_FACEBOOK) (NEW) 15. Foxconn (VENDOR_FOXCONN) (NEW) 16. Getac (VENDOR_GETAC) (NEW) 17. GIGABYTE (VENDOR_GIGABYTE) (NEW) 18. GizmoSphere (VENDOR_GIZMOSPHERE) (NEW) 19. Google (VENDOR_GOOGLE) (NEW) 20. HP (VENDOR_HP) (NEW) 21. iBase (VENDOR_IBASE) (NEW) 22. Intel (VENDOR_INTEL) (NEW) 23. Jetway (VENDOR_JETWAY) (NEW) 24. Kontron (VENDOR_KONTRON) (NEW) 25. Lenovo (VENDOR_LENOVO) (NEW) 26. Libretrend (VENDOR_LIBRETREND) (NEW) 27. LiPPERT (VENDOR_LIPPERT) (NEW) 28. MSI (VENDOR_MSI) (NEW) 29. Open Compute Project (VENDOR_OCP) (NEW) 30. OpenCellular (VENDOR_OPENCELLULAR) (NEW) 31. Packard Bell (VENDOR_PACKARDBELL) (NEW) 32. PC Engines (VENDOR_PCENGINES) (NEW) 33. Portwell (VENDOR_PORTWELL) (NEW) 34. Protectli (VENDOR_PROTECTLI) (NEW) 35. Purism (VENDOR_PURISM) (NEW) 36. RAZER (VENDOR_RAZER) (NEW) 37. Roda (VENDOR_RODA) (NEW) 38. SAMSUNG (VENDOR_SAMSUNG) (NEW) 39. Sapphire (VENDOR_SAPPHIRE) (NEW) 40. Scaleway (VENDOR_SCALEWAY) (NEW) 41. Siemens (VENDOR_SIEMENS) (NEW) 42. SiFive (VENDOR_SIFIVE) (NEW) 43. Supermicro (VENDOR_SUPERMICRO) (NEW) 44. System76 (VENDOR_SYSTEM76) (NEW) 45. TI (VENDOR_TI) (NEW) 46. UP (VENDOR_UP) (NEW) choice[1-46]:

1 0

google/veyron: How to use emulator for development?
by Paul Menzel July 18, 2020

July 18, 2020

Dear coreboot folks, I’d like to run upstream coreboot on the MEDION AKOYA S2013 (google/veyron_jaq) [1]. As I have access to a DediProg EM100Pro [1] including a 10-Pin Split Cable with a grabber on the hold pin [2], and a clip, I was wondering if I can hook it up without soldering to boot from (like an external chip). On some boards, the wiring does not support In-system programming (ISP), as some other parts would for example be powered. I couldn’t find the schematics. It’d be great if somebody with access could check that. Kind regards, Paul [1]: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… [2]: https://www.dediprog.com/product/EM100Pro-G2 [3]: https://www.dediprog.com/product/EM-SP-CB

3 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com July 17, 2020

July 17, 2020

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 105 new defect(s) introduced to coreboot found with Coverity Scan. 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 105 defect(s) ** CID 1429780: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1429780: Uninitialized variables (UNINIT) /src/mainboard/dell/optiplex_9010/sch5545_ec.c: 618 in sch5545_ec_hwm_init() 612 613 printk(BIOS_DEBUG, "%s\n", __func__); 614 sch5545_emi_init(0x2e); 615 616 chassis_type = get_chassis_type(); 617 >>> CID 1429780: Uninitialized variables (UNINIT) >>> Using uninitialized value "val" when calling "ec_read_write_reg". 618 ec_read_write_reg(EC_HWM_LDN, 0x0048, &val, READ_OP); 619 ec_read_write_reg(EC_HWM_LDN, 0x0048, &val, WRITE_OP); 620 ec_read_write_reg(EC_HWM_LDN, 0x0042, &val, READ_OP); 621 ec_read_write_reg(EC_HWM_LDN, 0x0048, &val, READ_OP); 622 val |= 0x02; 623 ec_read_write_reg(EC_HWM_LDN, 0x0048, &val, WRITE_OP); ** CID 1429772: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1429772: Uninitialized variables (UNINIT) /src/mainboard/dell/optiplex_9010/sch5545_ec.c: 431 in sch5545_get_ec_fw_version() 425 uint16_t sch5545_get_ec_fw_version(void) 426 { 427 uint8_t val; 428 uint16_t ec_fw_version; 429 430 /* Read the FW version currently loaded used by EC */ >>> CID 1429772: Uninitialized variables (UNINIT) >>> Using uninitialized value "val" when calling "ec_read_write_reg". 431 ec_read_write_reg(EC_HWM_LDN, 0x2ad, &val, READ_OP); 432 ec_fw_version = (val << 8); 433 ec_read_write_reg(EC_HWM_LDN, 0x2ae, &val, READ_OP); 434 ec_fw_version |= val; 435 ec_read_write_reg(EC_HWM_LDN, 0x2ac, &val, READ_OP); 436 ec_read_write_reg(EC_HWM_LDN, 0x2fd, &val, READ_OP); ** CID 1429765: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1429765: Uninitialized variables (UNINIT) /src/mainboard/dell/optiplex_9010/sch5545_ec.c: 512 in sch5545_ec_hwm_early_init() 506 int i; 507 508 printk(BIOS_DEBUG, "%s\n", __func__); 509 510 ec_check_mbox_and_int_status(0x20, 0x01); 511 >>> CID 1429765: Uninitialized variables (UNINIT) >>> Using uninitialized value "val" when calling "ec_read_write_reg". 512 ec_read_write_reg(2, 0xcb, &val, READ_OP); 513 ec_read_write_reg(2, 0xb8, &val, READ_OP); 514 515 for (i = 0; i < ARRAY_SIZE(ec_hwm_init_seq); i++) { 516 val = ec_hwm_init_seq[i].val; 517 ec_read_write_reg(EC_HWM_LDN, ec_hwm_init_seq[i].reg, &val, ** CID 1428711: (OVERRUN) ________________________________________________________________________________________________________ *** CID 1428711: (OVERRUN) /src/vendorcode/eltan/security/mboot/mboot.c: 431 in mb_crtm() 425 tcgEventHdr.pcrIndex = MBOOT_PCR_INDEX_0; 426 tcgEventHdr.eventType = EV_S_CRTM_VERSION; 427 tcgEventHdr.eventSize = sizeof(crtm_version); 428 printk(BIOS_DEBUG, "%s: EventSize - %u\n", __func__, 429 tcgEventHdr.eventSize); 430 >>> CID 1428711: (OVERRUN) >>> Overrunning callee's array of size 32 by passing argument "tcgEventHdr.eventSize" (which evaluates to 67) in call to "mboot_hash_extend_log". 431 status = mboot_hash_extend_log(0, (uint8_t *)crtm_version, tcgEventHdr.eventSize, 432 &tcgEventHdr, (uint8_t *)crtm_version); 433 if (status) { 434 printk(BIOS_DEBUG, "Measure CRTM Version returned 0x%x\n", status); 435 return status; 436 } /src/mainboard/facebook/fbg1701/romstage.c: 78 in mb_crtm() 72 memset(&tcgEventHdr, 0, sizeof(tcgEventHdr)); 73 tcgEventHdr.pcrIndex = MBOOT_PCR_INDEX_0; 74 tcgEventHdr.eventType = EV_S_CRTM_VERSION; 75 tcgEventHdr.eventSize = sizeof(crtm_version); 76 printk(BIOS_DEBUG, "%s: EventSize - %u\n", __func__, tcgEventHdr.eventSize); 77 >>> CID 1428711: (OVERRUN) >>> Overrunning callee's array of size 32 by passing argument "tcgEventHdr.eventSize" (which evaluates to 67) in call to "mboot_hash_extend_log". 78 status = mboot_hash_extend_log(0, (uint8_t *)crtm_version, 79 tcgEventHdr.eventSize, &tcgEventHdr, 80 (uint8_t *)crtm_version); 81 if (status) { 82 printk(BIOS_DEBUG, "Measure CRTM Version returned 0x%x\n", status); 83 } 84 85 return status; 86 } ** CID 1419488: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1419488: Null pointer dereferences (FORWARD_NULL) /src/superio/common/generic.c: 20 in generic_set_resources() 14 15 for (res = dev->resource_list; res; res = res->next) { 16 if (!(res->flags & IORESOURCE_ASSIGNED)) 17 continue; 18 19 res->flags |= IORESOURCE_STORED; >>> CID 1419488: Null pointer dereferences (FORWARD_NULL) >>> Passing "dev" to "report_resource_stored", which dereferences null "dev->link_list". 20 report_resource_stored(dev, res, ""); 21 } 22 } 23 24 static void generic_read_resources(struct device *dev) 25 { ** CID 1419483: Memory - corruptions (OVERRUN) /src/vendorcode/eltan/security/verified_boot/vboot_check.c: 85 in verified_boot_check_manifest() ________________________________________________________________________________________________________ *** CID 1419483: Memory - corruptions (OVERRUN) /src/vendorcode/eltan/security/verified_boot/vboot_check.c: 85 in verified_boot_check_manifest() 79 pre->body_signature.data_size = CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_ITEMS * 80 DIGEST_SIZE; 81 pre->body_signature.sig_offset = sizeof(struct vb2_signature) + 82 pre->body_signature.data_size; 83 pre->body_signature.sig_size = size - pre->body_signature.data_size; 84 sd->workbuf_used += size; >>> CID 1419483: Memory - corruptions (OVERRUN) >>> Overrunning struct type vb2_signature of 24 bytes by passing it to a function which accesses it at byte offset 663 using argument "size" (which evaluates to 640). [Note: The source code implementation of the function has been overridden by a builtin model.] 85 memcpy((void *)((void *)&pre->body_signature + (long)sizeof(struct vb2_signature)), 86 (uint8_t *)CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_LOC, size); 87 88 89 if (vb2api_verify_kernel_data(ctx, (void *)CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_LOC, 90 pre->body_signature.data_size)) ** CID 1407750: Control flow issues (NO_EFFECT) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 50 in sbi_check_extension() ________________________________________________________________________________________________________ *** CID 1407750: Control flow issues (NO_EFFECT) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 50 in sbi_check_extension() 44 * by checking the feature bits of the platform. We can create a map 45 * between extension ID & feature and use a generic function to check 46 * or just use a switch case for every new extension support added 47 * TODO: Implement it. 48 */ 49 >>> CID 1407750: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "extid >= SBI_EXT_0_1_SET_TIMER". 50 if ((extid >= SBI_EXT_0_1_SET_TIMER && 51 extid <= SBI_EXT_0_1_SHUTDOWN) || (extid == SBI_EXT_BASE)) { 52 *out_val = 1; 53 } else if (extid >= SBI_EXT_VENDOR_START && 54 extid <= SBI_EXT_VENDOR_END) { 55 *out_val = sbi_platform_vendor_ext_check( ** CID 1407740: Control flow issues (DEADCODE) /3rdparty/opensbi/lib/sbi/sbi_trap.c: 131 in sbi_trap_redirect() ________________________________________________________________________________________________________ *** CID 1407740: Control flow issues (DEADCODE) /3rdparty/opensbi/lib/sbi/sbi_trap.c: 131 in sbi_trap_redirect() 125 hstatus = csr_read(CSR_HSTATUS); 126 hstatus &= ~HSTATUS_SP2P; 127 hstatus |= (regs->mstatus & MSTATUS_SPP) ? HSTATUS_SP2P : 0; 128 hstatus &= ~HSTATUS_SP2V; 129 hstatus |= (hstatus & HSTATUS_SPV) ? HSTATUS_SP2V : 0; 130 hstatus &= ~HSTATUS_SPV; >>> CID 1407740: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "0UL" inside this statement: "hstatus |= (prev_virt ? 128...". 131 hstatus |= (prev_virt) ? HSTATUS_SPV : 0; 132 hstatus &= ~HSTATUS_STL; 133 hstatus |= (prev_stage2) ? HSTATUS_STL : 0; 134 csr_write(CSR_HSTATUS, hstatus); 135 } 136 ** CID 1407737: Error handling issues (CHECKED_RETURN) /src/drivers/spi/spi_sdcard.c: 357 in spi_sdcard_do_app_command() ________________________________________________________________________________________________________ *** CID 1407737: Error handling issues (CHECKED_RETURN) /src/drivers/spi/spi_sdcard.c: 357 in spi_sdcard_do_app_command() 351 static int spi_sdcard_do_app_command(const struct spi_sdcard *card, 352 uint8_t cmd, 353 uint32_t argument, 354 uint32_t *out_register) 355 { 356 /* CMD55 */ >>> CID 1407737: Error handling issues (CHECKED_RETURN) >>> Calling "spi_sdcard_do_command" without checking return value (as is done elsewhere 15 out of 17 times). 357 spi_sdcard_do_command(card, APP_CMD, 0, NULL); 358 return spi_sdcard_do_command_help(card, 1, cmd, argument, out_register); 359 } 360 361 362 size_t spi_sdcard_size(const struct spi_sdcard *card) ** CID 1407730: (SWAPPED_ARGUMENTS) ________________________________________________________________________________________________________ *** CID 1407730: (SWAPPED_ARGUMENTS) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 217 in sbi_ecall_handler() 211 } else if (extension_id == SBI_EXT_BASE) 212 ret = sbi_ecall_base_handler(scratch, extension_id, func_id, 213 args, &out_val, 214 &out_tval, &out_tcause); 215 else if (extension_id >= SBI_EXT_VENDOR_START && 216 extension_id <= SBI_EXT_VENDOR_END) { >>> CID 1407730: (SWAPPED_ARGUMENTS) >>> The positions of arguments in the call to "sbi_ecall_vendor_ext_handler" do not match the ordering of the parameters: * "&out_tval" is passed to "out_tcause" * "&out_tcause" is passed to "out_tval" 217 ret = sbi_ecall_vendor_ext_handler(scratch, extension_id, 218 func_id, args, &out_val, 219 &out_tval, &out_tcause); 220 } else { 221 ret = SBI_ENOTSUPP; 222 } /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 212 in sbi_ecall_handler() 206 if (extension_id >= SBI_EXT_0_1_SET_TIMER && 207 extension_id <= SBI_EXT_0_1_SHUTDOWN) { 208 ret = sbi_ecall_0_1_handler(scratch, extension_id, args, 209 &out_tval, &out_tcause); 210 is_0_1_spec = 1; 211 } else if (extension_id == SBI_EXT_BASE) >>> CID 1407730: (SWAPPED_ARGUMENTS) >>> The positions of arguments in the call to "sbi_ecall_base_handler" do not match the ordering of the parameters: * "&out_tval" is passed to "out_tcause" * "&out_tcause" is passed to "out_tval" 212 ret = sbi_ecall_base_handler(scratch, extension_id, func_id, 213 args, &out_val, 214 &out_tval, &out_tcause); 215 else if (extension_id >= SBI_EXT_VENDOR_START && 216 extension_id <= SBI_EXT_VENDOR_END) { 217 ret = sbi_ecall_vendor_ext_handler(scratch, extension_id, ** CID 1407727: Control flow issues (NO_EFFECT) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 206 in sbi_ecall_handler() ________________________________________________________________________________________________________ *** CID 1407727: Control flow issues (NO_EFFECT) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 206 in sbi_ecall_handler() 200 args[1] = regs->a1; 201 args[2] = regs->a2; 202 args[3] = regs->a3; 203 args[4] = regs->a4; 204 args[5] = regs->a5; 205 >>> CID 1407727: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "extension_id >= SBI_EXT_0_1_SET_TIMER". 206 if (extension_id >= SBI_EXT_0_1_SET_TIMER && 207 extension_id <= SBI_EXT_0_1_SHUTDOWN) { 208 ret = sbi_ecall_0_1_handler(scratch, extension_id, args, 209 &out_tval, &out_tcause); 210 is_0_1_spec = 1; 211 } else if (extension_id == SBI_EXT_BASE) ** CID 1407723: Control flow issues (MISSING_BREAK) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 105 in sbi_ecall_base_handler() ________________________________________________________________________________________________________ *** CID 1407723: Control flow issues (MISSING_BREAK) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 105 in sbi_ecall_base_handler() 99 case SBI_EXT_BASE_GET_MARCHID: 100 *out_val = csr_read(CSR_MARCHID); 101 break; 102 case SBI_EXT_BASE_GET_MIMPID: 103 *out_val = csr_read(CSR_MIMPID); 104 break; >>> CID 1407723: Control flow issues (MISSING_BREAK) >>> The case for value "SBI_EXT_BASE_PROBE_EXT" is not terminated by a 'break' statement. 105 case SBI_EXT_BASE_PROBE_EXT: 106 ret = sbi_check_extension(scratch, args[0], out_val); 107 default: 108 ret = SBI_ENOTSUPP; 109 } 110 ** CID 1407720: (RESOURCE_LEAK) /src/lib/bootsplash.c: 37 in set_bootsplash() /src/lib/bootsplash.c: 40 in set_bootsplash() ________________________________________________________________________________________________________ *** CID 1407720: (RESOURCE_LEAK) /src/lib/bootsplash.c: 37 in set_bootsplash() 31 decdata = malloc(sizeof(*decdata)); 32 int ret = jpeg_decode(jpeg, framebuffer, x_resolution, y_resolution, fb_resolution, 33 decdata); 34 if (ret != 0) { 35 printk(BIOS_ERR, "Bootsplash could not be decoded. jpeg_decode returned %d.\n", 36 ret); >>> CID 1407720: (RESOURCE_LEAK) >>> Variable "decdata" going out of scope leaks the storage it points to. 37 return; 38 } 39 printk(BIOS_INFO, "Bootsplash loaded\n"); /src/lib/bootsplash.c: 40 in set_bootsplash() 34 if (ret != 0) { 35 printk(BIOS_ERR, "Bootsplash could not be decoded. jpeg_decode returned %d.\n", 36 ret); 37 return; 38 } 39 printk(BIOS_INFO, "Bootsplash loaded\n"); >>> CID 1407720: (RESOURCE_LEAK) >>> Variable "decdata" going out of scope leaks the storage it points to. ** CID 1407713: Uninitialized variables (UNINIT) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 238 in sbi_ecall_handler() ________________________________________________________________________________________________________ *** CID 1407713: Uninitialized variables (UNINIT) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 238 in sbi_ecall_handler() 232 * accordingly for now. Once fatal errors are defined, that 233 * case should be handled differently. 234 */ 235 regs->mepc += 4; 236 regs->a0 = ret; 237 if (!is_0_1_spec) >>> CID 1407713: Uninitialized variables (UNINIT) >>> Using uninitialized value "out_val". 238 regs->a1 = out_val; 239 } 240 241 return 0; ** CID 1407708: Code maintainability issues (UNUSED_VALUE) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 106 in sbi_ecall_base_handler() ________________________________________________________________________________________________________ *** CID 1407708: Code maintainability issues (UNUSED_VALUE) /3rdparty/opensbi/lib/sbi/sbi_ecall.c: 106 in sbi_ecall_base_handler() 100 *out_val = csr_read(CSR_MARCHID); 101 break; 102 case SBI_EXT_BASE_GET_MIMPID: 103 *out_val = csr_read(CSR_MIMPID); 104 break; 105 case SBI_EXT_BASE_PROBE_EXT: >>> CID 1407708: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "sbi_check_extension(scratch, args[0], out_val)" to "ret" here, but that stored value is overwritten before it can be used. 106 ret = sbi_check_extension(scratch, args[0], out_val); 107 default: 108 ret = SBI_ENOTSUPP; 109 } 110 111 return ret; ** CID 1405309: Incorrect expression (COPY_PASTE_ERROR) /src/superio/common/ssdt.c: 55 in superio_guess_function() ________________________________________________________________________________________________________ *** CID 1405309: Incorrect expression (COPY_PASTE_ERROR) /src/superio/common/ssdt.c: 55 in superio_guess_function() 49 if (!res || !res->size) 50 continue; 51 for (size_t j = 0; j < ARRAY_SIZE(superio_devs); j++) { 52 for (size_t k = 0; k < 2; k++) { 53 if (!superio_devs[j].irq[k]) 54 continue; >>> CID 1405309: Incorrect expression (COPY_PASTE_ERROR) >>> "base" in "res->base" looks like a copy-paste error. 55 if (superio_devs[j].irq[k] == res->base) 56 return &superio_devs[j]; 57 } 58 } 59 } 60 return NULL; ** CID 1402174: (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbPcieInitLibV4/PcieWrapperServicesV4.c: 201 in PcieTopologySetLinkReversalV4() /src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbPcieInitLibV4/PcieWrapperServicesV4.c: 247 in PcieTopologySetLinkReversalV4() ________________________________________________________________________________________________________ *** CID 1402174: (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbPcieInitLibV4/PcieWrapperServicesV4.c: 201 in PcieTopologySetLinkReversalV4() 195 FALSE, 196 Pcie 197 ); 198 } 199 } 200 } >>> CID 1402174: (ARRAY_VS_SINGLETON) >>> Using "EngineList" as an array. This might corrupt or misinterpret adjacent memory locations. 201 EngineList = PcieLibGetNextDescriptor (EngineList); 202 } 203 IDS_HDT_CONSOLE (GNB_TRACE, "PcieTopologySetLinkReversal Exit\n"); /src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbPcieInitLibV4/PcieWrapperServicesV4.c: 247 in PcieTopologySetLinkReversalV4() 241 FALSE, 242 Pcie 243 ); 244 } 245 } 246 } >>> CID 1402174: (ARRAY_VS_SINGLETON) >>> Using "EngineList" as an array. This might corrupt or misinterpret adjacent memory locations. 247 EngineList = PcieLibGetNextDescriptor (EngineList); 248 } 249 IDS_HDT_CONSOLE (GNB_TRACE, "PcieTopologySetLinkReversal Exit\n"); ** CID 1402170: Memory - corruptions (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/PcieConfigTN.c: 405 in PcieConfigureGppEnginesLaneAllocationTN() ________________________________________________________________________________________________________ *** CID 1402170: Memory - corruptions (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/PcieConfigTN.c: 405 in PcieConfigureGppEnginesLaneAllocationTN() 399 CoreLaneIndex = 0; 400 PortIdIndex = 0; 401 while (EnginesList != NULL) { 402 PcieConfigResetDescriptorFlags (EnginesList, DESCRIPTOR_ALLOCATED); 403 EnginesList->Type.Port.StartCoreLane = GppLaneConfigurationTable [ConfigurationId][CoreLaneIndex++]; 404 EnginesList->Type.Port.EndCoreLane = GppLaneConfigurationTable [ConfigurationId][CoreLaneIndex++]; >>> CID 1402170: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Using "EnginesList" as an array. This might corrupt or misinterpret adjacent memory locations. 405 EnginesList = PcieLibGetNextDescriptor (EnginesList); 406 } 407 return AGESA_SUCCESS; 408 } 409 410 ** CID 1402165: Memory - corruptions (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbInitKB/PcieConfigKB.c: 193 in PcieConfigurePcieEnginesLaneAllocation() ________________________________________________________________________________________________________ *** CID 1402165: Memory - corruptions (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbInitKB/PcieConfigKB.c: 193 in PcieConfigurePcieEnginesLaneAllocation() 187 while (EnginesList != NULL) { 188 if (PcieLibIsPcieEngine (EnginesList)) { 189 PcieConfigResetDescriptorFlags (EnginesList, DESCRIPTOR_ALLOCATED); 190 EnginesList->Type.Port.StartCoreLane = PcieLaneConfig->ConfigTable[CoreLaneIndex++]; 191 EnginesList->Type.Port.EndCoreLane = PcieLaneConfig->ConfigTable[CoreLaneIndex++]; 192 } >>> CID 1402165: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Using "EnginesList" as an array. This might corrupt or misinterpret adjacent memory locations. 193 EnginesList = PcieLibGetNextDescriptor (EnginesList); 194 } 195 return AGESA_SUCCESS; 196 } 197 198 /*----------------------------------------------------------------------------------------*/ ** CID 1402163: (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbPcieInitLibV1/PcieUtilityLib.c: 496 in PcieUtilGetWrapperLaneBitMap() /src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbPcieInitLibV1/PcieUtilityLib.c: 496 in PcieUtilGetWrapperLaneBitMap() ________________________________________________________________________________________________________ *** CID 1402163: (ARRAY_VS_SINGLETON) /src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbPcieInitLibV1/PcieUtilityLib.c: 496 in PcieUtilGetWrapperLaneBitMap() 490 if (ExcludeLaneType != 0) { 491 LaneBitmap &= (~PcieUtilGetWrapperLaneBitMap (ExcludeLaneType, 0, Wrapper)); 492 } 493 } else { 494 while (EngineList != NULL) { 495 LaneBitmap |= PcieUtilGetEngineLaneBitMap (IncludeLaneType, ExcludeLaneType, EngineList); >>> CID 1402163: (ARRAY_VS_SINGLETON) >>> Using "EngineList" as an array. This might corrupt or misinterpret adjacent memory locations. 496 EngineList = PcieLibGetNextDescriptor (EngineList); 497 } 498 if ((IncludeLaneType & LANE_TYPE_PCIE_PHY_NATIVE_MASTER_PLL) != 0) { 499 LaneBitmap |= PcieUtilGetMasterPllLaneBitMap (Wrapper); 500 } 501 if ((ExcludeLaneType & LANE_TYPE_PCIE_PHY_NATIVE_MASTER_PLL) != 0) { /src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbPcieInitLibV1/PcieUtilityLib.c: 496 in PcieUtilGetWrapperLaneBitMap() 490 if (ExcludeLaneType != 0) { 491 LaneBitmap &= (~PcieUtilGetWrapperLaneBitMap (ExcludeLaneType, 0, Wrapper)); 492 } 493 } else { 494 while (EngineList != NULL) { 495 LaneBitmap |= PcieUtilGetEngineLaneBitMap (IncludeLaneType, ExcludeLaneType, EngineList); >>> CID 1402163: (ARRAY_VS_SINGLETON) >>> Using "EngineList" as an array. This might corrupt or misinterpret adjacent memory locations. 496 EngineList = PcieLibGetNextDescriptor (EngineList); 497 } 498 if ((IncludeLaneType & LANE_TYPE_PCIE_PHY_NATIVE_MASTER_PLL) != 0) { 499 LaneBitmap |= PcieUtilGetMasterPllLaneBitMap (Wrapper); 500 } 501 if ((ExcludeLaneType & LANE_TYPE_PCIE_PHY_NATIVE_MASTER_PLL) != 0) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0