coreboot

coreboot@coreboot.org

6 participants
39686 discussions

I may have misconfigured my Coreboot ROM, what did I do wrong?
by Tristan Young 15 Jul '22

15 Jul '22

Today, I internally flashed a Coreboot ROM that I partially built myself to the motherboard of my ThinkPad T440p. But when I restarted my computer, it started constantly beeping, and turning it off and on didn't change that result. Luckily, I fixed it by flashing my previous Coreboot BIOS (SeaBIOS) to the top 4 MiB chip externally using my Raspberry Pi. But there are some things that were different in the build configuration for the newer BIOS, such as trying to use a bootorder file to make SeaBIOS try to boot from my HDD first instead of my CD/DVD drive, as well as setting the options to clear the DRAM on each boot. I also didn't use the cleanbuild option after different build attempts for the newer BIOS. Should I send my .config file so that you can tell if any of the config settings or combinations of them that I chose wouldn't work on my specific model of ThinkPad? And should I also send over an actual 4MiB binary of the BIOS I flashed that didn't work?

3 2

Measured boot and TPM standards
by Krystian Hebel 13 Jul '22

13 Jul '22

TL;DR: why doesn't vboot follow existing standards and tries to create its own instead? [XKCD] During our adventures with enabling coreboot port for Talos 2 we got to the point of enabling TPM, and with it, measured boot. coreboot's part worked without too many issues other than those resulting from assumptions about endianness, Skiboot's (payload) - not so much, at least it seemed that way. Hardware access worked after adding a driver implementation for new module, but it failed to parse event log and in result disabled TPM. Skiboot (payload) expects Agile format [TPM20] of event log, while vboot provides its own format [VBOOT], compatible with neither Agile nor legacy format used by TPM 1.2 [TPM12]. Even worse, address of this log is written to TCPA ACPI table, from which it is read and parsed (or at least tried) by kernel as TPM 1.2 format [LINUX]. At first I thought custom format was developed to add support for SHA-256, but only TPM 2.0 uses it, and it already has new format, capable of storing bigger hashes. Which brings up the question: why use own format that nothing else knows how to parse? Are there any reasons against switching to Agile format? AFAICT only cbmem can parse the current form. Another problem is PCR assignments: on one hand, [VBOOT] says that "coreboot uses the SHA-1 or SHA-256 hash algorithm depending on the _TPM specification_ for measurements", and then doesn't follow any existing specification, even though both families have predefined and mostly compatible with each other uses for PCRs (section 3.3.3 in [TPM12] and 3.3.4 in [TPM20]). Measuring GBB flags to PCR0 is dubious since PCR0 is usually used for code at or near RTM. Speaking of RTM, what the heck with those SRTM/DRTM definitions? When reading it, I got the feeling that there was misunderstanding and someone thought that S stands for software, D - discrete, although expansions of those abbreviations in the vboot documentation are correct. [DRTM] definitely isn't able to start from IBB, as is suggested in that documentation. We would like to work on mentioned issues, both implementation and documentation. Before we invest time in it, we would like to know whether there are any reasons that would require keeping current form, any caveats or design decisions we've missed. [XKCD] https://xkcd.com/927/ [TPM20] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… [VBOOT] https://doc.coreboot.org/security/vboot/measured_boot.html#tcpa-eventlog [TPM12] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [LINUX] https://github.com/torvalds/linux/blob/master/drivers/char/tpm/eventlog/acp… [DRTM] https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture… -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com

2 1

[coreboot - Bug #388] (New) denverton_ns: crash when starting postcar
by King Sumo 13 Jul '22

13 Jul '22

Issue #388 has been reported by King Sumo. ---------------------------------------- Bug #388: denverton_ns: crash when starting postcar https://ticket.coreboot.org/issues/388 * Author: King Sumo * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2022-06-15 * Affected versions: 4.17, master * Affected hardware: intel harcuvar * Affected OS: all ---------------------------------------- Postcar is crashing when using configured to teardown the CAR using FSP. Therefore the bug may occur in other platforms than denverton as well. See also the discussion here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2JC3… The bug was instroduced by the following change: * 5315e96abf arch/x86/postcar: Use a separate stack for C execution Attached is a patch with the bug fix. ---Files-------------------------------- fix-postcar-crash.patch (822 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 2

POST codes and PCI Post card
by Pedro Erencia 11 Jul '22

11 Jul '22

I've noticed that POST codes are sent very early. In x86 the first code is sent just after storing the bist. Are codes sent so early useful? They are sent ages before any PCI configuration. Is there any guarantee of them reaching a PCI POST card?

5 4

[BUG?] objcopy extracts a wrong section of cbfs_master_header.c
by Petr Cvek 11 Jul '22

11 Jul '22

Hello, It seems since version 4.17 and since commit: 75226bb879837e2e4aa710aadb27dbadb4044ed3 Makefile.inc: Generate master header and pointer as C structs The coreboot miscompiles the ROM image. At the beginning of the image there should be usually something like: "cbfs_master_header" and "ORBC" but on my setup there is no ORBC magic ID. Instead it seems a ".note.gnu.property" section has been copied by objcopy into the final image (conincidentally it is the last section in the object file too). Does anybody have the same problem? The missing header will cause seabios to fail to detect secondary payloads (ex. memtest and nvramcui) and probably the rest of CBFS stuff too. My binutils version is 2.38 (exactl version is: GNU objcopy version 2.38-slack151). But for coreboot 4.16 the image seems to be compiled correctly (so the problem would be only with a singular object file?). I was able to force the correct section copy by changing the Makefile.inc near this code: cbfs-files-processor-struct= \ $(eval $(2): $(1) $(obj)/build.h $(obj)/fmap_config.h $(KCONFIG_AUTOHEADER); \ printf " CC+STRIP $(1)\n"; \ $(CC_ramstage) -MMD $(CPPFLAGS_ramstage) $(CFLAGS_ramstage) --param asan-globals=0 $$(ramstage-c-ccopts) -include $(KCONFIG_AUTOHEADER) -MT $(2) -o $(2).tmp -c $(1) && \ - $(OBJCOPY_ramstage) -O binary --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \ + $(OBJCOPY_ramstage) -O binary --only-section=.data.* --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \ but this is most like really dirty hack. With this change the ORBC header is generated correctly, but I didn't have a chance to test if the image boots. How should I fix it correctly. best regards, Petr

2 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 08 Jul '22

08 Jul '22

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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1490493: (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/baytrail/northcluster.c: 85 in nc_read_resources() /src/soc/intel/baytrail/northcluster.c: 84 in nc_read_resources() ________________________________________________________________________________________________________ *** CID 1490493: (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/baytrail/northcluster.c: 85 in nc_read_resources() 79 /* 0 -> 0xa0000 */ 80 ram_from_to(dev, index++, 0, 0xa0000); 81 82 /* The SMMRR registers are 1MiB granularity with smmrrh being 83 * inclusive of the SMM region. */ 84 smmrrl = (iosf_bunit_read(BUNIT_SMRRL) & 0xffff) * MiB; >>> CID 1490493: (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "((iosf_bunit_read(47) & 0xffffU) + 1U) * 1048576U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 85 smmrrh = ((iosf_bunit_read(BUNIT_SMRRH) & 0xffff) + 1) * MiB; 86 87 /* 0xc0000 -> smrrl - cacheable and usable */ 88 ram_from_to(dev, index++, 0xc0000, smmrrl); 89 90 if (smmrrh > smmrrl) /src/soc/intel/baytrail/northcluster.c: 84 in nc_read_resources() 78 79 /* 0 -> 0xa0000 */ 80 ram_from_to(dev, index++, 0, 0xa0000); 81 82 /* The SMMRR registers are 1MiB granularity with smmrrh being 83 * inclusive of the SMM region. */ >>> CID 1490493: (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "(iosf_bunit_read(46) & 0xffffU) * 1048576U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 84 smmrrl = (iosf_bunit_read(BUNIT_SMRRL) & 0xffff) * MiB; 85 smmrrh = ((iosf_bunit_read(BUNIT_SMRRH) & 0xffff) + 1) * MiB; 86 87 /* 0xc0000 -> smrrl - cacheable and usable */ 88 ram_from_to(dev, index++, 0xc0000, smmrrl); 89 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

LPC 2022 System Boot and Security Microconference
by Michał Żygowski 07 Jul '22

07 Jul '22

Hi everyone, System Boot and Security Microconference will take place again at the Linux Plumbers Conference this year. The CfP deadline (10th July) is nearing... If you have an interesting firmware/bootloader project focusing on a specific aspect of "plumbing" in the Linux system, feel free to submit proposals: https://lpc.events/event/16/abstracts/ More details about the Microconference and possible topics: https://lpc.events/event/16/contributions/1157/ Best regards, -- Michał Żygowski Firmware Engineer GPG: 6B5BA214D21FCEB2 https://3mdeb.com | @3mdeb_com

1 0

[coreboot - Bug #343] Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting
by Michael Niewöhner 05 Jul '22

05 Jul '22

Issue #343 has been updated by Michael Niewöhner. Nico Huber wrote in #note-4: > I think this is related: > https://review.coreboot.org/c/coreboot/+/64235 Thanks for the hint. This fixes it ---------------------------------------- Bug #343: Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting https://ticket.coreboot.org/issues/343#change-1025 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2022-03-30 ---------------------------------------- coreboot emulation/qemu-i440fx is unable to load GRUB payload. It works with SeaBIOS. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 21944 none fallback/ramstage 0x56c0 stage 62048 LZMA (139536 decompressed) config 0x14980 raw 428 none revision 0x14b80 raw 716 none build_info 0x14e80 raw 112 none fallback/dsdt.aml 0x14f40 raw 4044 none cmos_layout.bin 0x15f40 cmos_layout 640 none fallback/postcar 0x16200 stage 23328 none fallback/payload 0x1bd80 simple elf 460906 none (empty) 0x8c640 null 3603556 none bootblock 0x3fc2c0 bootblock 15104 none ``` ``` […] [NOTE ] coreboot-4.16-415-ga84c00c9ce Wed Mar 30 01:18:14 UTC 2022 ramstage starting (log level: 7)... […] [INFO ] Timestamp - selfboot jump: 965162845 [EMERG] CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting [EMERG] Code: 0 eflags: 00010002 cr2: 00000000 [EMERG] eax: 00000000 ebx: 3ffbdc18 ecx: 0001ac27 edx: 000000ff [EMERG] edi: 3ffbdc00 esi: 3ffbdbf0 ebp: 000001e4 esp: 3ffc3fbc [EMERG] 0x00008fd0: 00 00 00 00 00 00 00 00 [EMERG] 0x00008fd8: 00 00 00 00 00 00 00 00 [EMERG] 0x00008fe0: 00 00 00 00 00 00 00 00 [EMERG] 0x00008fe8: 00 00 00 00 00 00 00 00 [EMERG] 0x00008ff0: 00 00 00 00 00 00 00 00 [EMERG] 0x00008ff8: 00 00 00 00 00 00 00 00 [EMERG] 0x00009000: 52 52 68 27 ac 01 00 6a [EMERG] 0x00009008: 0b e8 5e cd 00 00 83 c4 [EMERG] 0x00009010: 10 a0 00 00 00 00 0f 0b [EMERG] 0x00009018: 51 51 68 6a a2 01 00 6a [EMERG] 0x00009020: 0b e8 46 cd 00 00 83 c4 [EMERG] 0x00009028: 10 eb e6 90 bc f0 ff 07 [EMERG] 0x00009030: 00 e9 c7 d7 00 00 66 90 [EMERG] 0x00009038: 02 b0 ad 1b 02 00 00 00 [EMERG] 0x00009040: fc 4f 52 e4 55 57 56 53 [EMERG] 0x00009048: 83 ec 1c 8b 5c 24 30 8b [EMERG] 0x3ffc4038: 0x00000002 [EMERG] 0x3ffc4034: 0x00000003 [EMERG] 0x3ffc4030: 0x00000000 [EMERG] 0x3ffc402c: 0x00000000 [EMERG] 0x3ffc4028: 0x00000000 [EMERG] 0x3ffc4024: 0x00000000 [EMERG] 0x3ffc4020: 0x00000000 [EMERG] 0x3ffc401c: 0x00000000 [EMERG] 0x3ffc4018: 0x00000000 [EMERG] 0x3ffc4014: 0x00000000 [EMERG] 0x3ffc4010: 0x00000000 [EMERG] 0x3ffc400c: 0x00000000 [EMERG] 0x3ffc4008: 0x00000000 [EMERG] 0x3ffc4004: 0x00000000 [EMERG] 0x3ffc4000: 0x00000000 [EMERG] 0x3ffc3ffc: 0x00000000 [EMERG] 0x3ffc3ff8: 0x3ffbd4e8 [EMERG] 0x3ffc3ff4: 0xdeadbeef [EMERG] 0x3ffc3ff0: 0xdeadbeef [EMERG] 0x3ffc3fec: 0x3ff9e061 [EMERG] 0x3ffc3fe8: 0x3ffa1f19 [EMERG] 0x3ffc3fe4: 0x00018f20 [EMERG] 0x3ffc3fe0: 0x3ffdcfd4 [EMERG] 0x3ffc3fdc: 0x3ffc4000 [EMERG] 0x3ffc3fd8: 0x3ffd63ac [EMERG] 0x3ffc3fd4: 0x00000000 [EMERG] 0x3ffc3fd0: 0x3ffa1fe5 [EMERG] 0x3ffc3fcc: 0x3ffa2139 [EMERG] 0x3ffc3fc8: 0x3ffbdc24 [EMERG] 0x3ffc3fc4: 0x3ffa4303 [EMERG] 0x3ffc3fc0: 0x3ff95000 [EMERG] 0x3ffc3fbc: 0x3ffac8e4 <-esp ``` ---Files-------------------------------- coreboot.log (17.2 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #343] Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting
by Nico Huber 04 Jul '22

04 Jul '22

Issue #343 has been updated by Nico Huber. I think this is related: https://review.coreboot.org/c/coreboot/+/64235 ---------------------------------------- Bug #343: Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting https://ticket.coreboot.org/issues/343#change-1024 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2022-03-30 ---------------------------------------- coreboot emulation/qemu-i440fx is unable to load GRUB payload. It works with SeaBIOS. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 21944 none fallback/ramstage 0x56c0 stage 62048 LZMA (139536 decompressed) config 0x14980 raw 428 none revision 0x14b80 raw 716 none build_info 0x14e80 raw 112 none fallback/dsdt.aml 0x14f40 raw 4044 none cmos_layout.bin 0x15f40 cmos_layout 640 none fallback/postcar 0x16200 stage 23328 none fallback/payload 0x1bd80 simple elf 460906 none (empty) 0x8c640 null 3603556 none bootblock 0x3fc2c0 bootblock 15104 none ``` ``` […] [NOTE ] coreboot-4.16-415-ga84c00c9ce Wed Mar 30 01:18:14 UTC 2022 ramstage starting (log level: 7)... […] [INFO ] Timestamp - selfboot jump: 965162845 [EMERG] CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting [EMERG] Code: 0 eflags: 00010002 cr2: 00000000 [EMERG] eax: 00000000 ebx: 3ffbdc18 ecx: 0001ac27 edx: 000000ff [EMERG] edi: 3ffbdc00 esi: 3ffbdbf0 ebp: 000001e4 esp: 3ffc3fbc [EMERG] 0x00008fd0: 00 00 00 00 00 00 00 00 [EMERG] 0x00008fd8: 00 00 00 00 00 00 00 00 [EMERG] 0x00008fe0: 00 00 00 00 00 00 00 00 [EMERG] 0x00008fe8: 00 00 00 00 00 00 00 00 [EMERG] 0x00008ff0: 00 00 00 00 00 00 00 00 [EMERG] 0x00008ff8: 00 00 00 00 00 00 00 00 [EMERG] 0x00009000: 52 52 68 27 ac 01 00 6a [EMERG] 0x00009008: 0b e8 5e cd 00 00 83 c4 [EMERG] 0x00009010: 10 a0 00 00 00 00 0f 0b [EMERG] 0x00009018: 51 51 68 6a a2 01 00 6a [EMERG] 0x00009020: 0b e8 46 cd 00 00 83 c4 [EMERG] 0x00009028: 10 eb e6 90 bc f0 ff 07 [EMERG] 0x00009030: 00 e9 c7 d7 00 00 66 90 [EMERG] 0x00009038: 02 b0 ad 1b 02 00 00 00 [EMERG] 0x00009040: fc 4f 52 e4 55 57 56 53 [EMERG] 0x00009048: 83 ec 1c 8b 5c 24 30 8b [EMERG] 0x3ffc4038: 0x00000002 [EMERG] 0x3ffc4034: 0x00000003 [EMERG] 0x3ffc4030: 0x00000000 [EMERG] 0x3ffc402c: 0x00000000 [EMERG] 0x3ffc4028: 0x00000000 [EMERG] 0x3ffc4024: 0x00000000 [EMERG] 0x3ffc4020: 0x00000000 [EMERG] 0x3ffc401c: 0x00000000 [EMERG] 0x3ffc4018: 0x00000000 [EMERG] 0x3ffc4014: 0x00000000 [EMERG] 0x3ffc4010: 0x00000000 [EMERG] 0x3ffc400c: 0x00000000 [EMERG] 0x3ffc4008: 0x00000000 [EMERG] 0x3ffc4004: 0x00000000 [EMERG] 0x3ffc4000: 0x00000000 [EMERG] 0x3ffc3ffc: 0x00000000 [EMERG] 0x3ffc3ff8: 0x3ffbd4e8 [EMERG] 0x3ffc3ff4: 0xdeadbeef [EMERG] 0x3ffc3ff0: 0xdeadbeef [EMERG] 0x3ffc3fec: 0x3ff9e061 [EMERG] 0x3ffc3fe8: 0x3ffa1f19 [EMERG] 0x3ffc3fe4: 0x00018f20 [EMERG] 0x3ffc3fe0: 0x3ffdcfd4 [EMERG] 0x3ffc3fdc: 0x3ffc4000 [EMERG] 0x3ffc3fd8: 0x3ffd63ac [EMERG] 0x3ffc3fd4: 0x00000000 [EMERG] 0x3ffc3fd0: 0x3ffa1fe5 [EMERG] 0x3ffc3fcc: 0x3ffa2139 [EMERG] 0x3ffc3fc8: 0x3ffbdc24 [EMERG] 0x3ffc3fc4: 0x3ffa4303 [EMERG] 0x3ffc3fc0: 0x3ff95000 [EMERG] 0x3ffc3fbc: 0x3ffac8e4 <-esp ``` ---Files-------------------------------- coreboot.log (17.2 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 01 Jul '22

01 Jul '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1490371: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/nvidia/tegra124/soc.c: 23 in soc_read_resources() ________________________________________________________________________________________________________ *** CID 1490371: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/nvidia/tegra124/soc.c: 23 in soc_read_resources() 17 static void soc_read_resources(struct device *dev) 18 { 19 u32 lcdbase = fb_base_mb(); 20 unsigned long fb_size = FB_SIZE_MB; 21 22 ram_from_to(dev, 0, (uintptr_t)_dram, (sdram_max_addressable_mb() - fb_size) * MiB); >>> CID 1490371: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "lcdbase * 1048576U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 23 mmio_range(dev, 1, lcdbase * MiB, fb_size * MiB); 24 25 ram_from_to(dev, 2, sdram_max_addressable_mb() * MiB, 26 (uintptr_t)_dram + sdram_size_mb() * (uint64_t)MiB); 27 } 28 ** CID 1490370: (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-i440fx/northbridge.c: 69 in cpu_pci_domain_read_resources() /src/mainboard/emulation/qemu-i440fx/northbridge.c: 101 in cpu_pci_domain_read_resources() ________________________________________________________________________________________________________ *** CID 1490370: (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-i440fx/northbridge.c: 69 in cpu_pci_domain_read_resources() 63 case 1: /* RAM */ 64 printk(BIOS_DEBUG, "QEMU: e820/ram: 0x%08llx + 0x%08llx\n", 65 list[i].address, list[i].length); 66 if (list[i].address == 0) { 67 tomk = list[i].length / 1024; 68 ram_from_to(dev, idx++, 0, 0xa0000); >>> CID 1490370: (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "tomk * 1024UL" with type "unsigned long" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 69 ram_from_to(dev, idx++, 0xc0000, tomk * KiB); 70 } else { 71 ram_range(dev, idx++, list[i].address, list[i].length); 72 } 73 break; 74 case 2: /* reserved */ /src/mainboard/emulation/qemu-i440fx/northbridge.c: 101 in cpu_pci_domain_read_resources() 95 uint64_t high = qemu_get_high_memory_size(); 96 printk(BIOS_DEBUG, "QEMU: cmos: %lu MiB RAM below 4G.\n", tomk / 1024); 97 printk(BIOS_DEBUG, "QEMU: cmos: %llu MiB RAM above 4G.\n", high / 1024); 98 99 /* Report the memory regions. */ 100 ram_from_to(dev, idx++, 0, 0xa0000); >>> CID 1490370: (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "tomk * 1024UL" with type "unsigned long" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 101 ram_from_to(dev, idx++, 0xc0000, tomk * KiB); 102 103 if (high) 104 upper_ram_end(dev, idx++, 4ull * GiB + high * KiB); 105 } 106 ** CID 1490369: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/nvidia/tegra124/soc.c: 22 in soc_read_resources() ________________________________________________________________________________________________________ *** CID 1490369: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/nvidia/tegra124/soc.c: 22 in soc_read_resources() 16 */ 17 static void soc_read_resources(struct device *dev) 18 { 19 u32 lcdbase = fb_base_mb(); 20 unsigned long fb_size = FB_SIZE_MB; 21 >>> CID 1490369: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "(sdram_max_addressable_mb() - fb_size) * 1048576UL" with type "unsigned long" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 22 ram_from_to(dev, 0, (uintptr_t)_dram, (sdram_max_addressable_mb() - fb_size) * MiB); 23 mmio_range(dev, 1, lcdbase * MiB, fb_size * MiB); 24 25 ram_from_to(dev, 2, sdram_max_addressable_mb() * MiB, 26 (uintptr_t)_dram + sdram_size_mb() * (uint64_t)MiB); 27 } ** CID 1490368: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/nvidia/tegra124/soc.c: 25 in soc_read_resources() ________________________________________________________________________________________________________ *** CID 1490368: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/nvidia/tegra124/soc.c: 25 in soc_read_resources() 19 u32 lcdbase = fb_base_mb(); 20 unsigned long fb_size = FB_SIZE_MB; 21 22 ram_from_to(dev, 0, (uintptr_t)_dram, (sdram_max_addressable_mb() - fb_size) * MiB); 23 mmio_range(dev, 1, lcdbase * MiB, fb_size * MiB); 24 >>> CID 1490368: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "sdram_max_addressable_mb() * 1048576UL" with type "unsigned long" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 25 ram_from_to(dev, 2, sdram_max_addressable_mb() * MiB, 26 (uintptr_t)_dram + sdram_size_mb() * (uint64_t)MiB); 27 } 28 29 static void soc_init(struct device *dev) 30 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot