coreboot June 2020

coreboot@coreboot.org

36 participants
37 discussions

Re: F2A85-M - amdgpu fails, integrated GPU works fine

by Mike Banon

> 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

9 months, 3 weeks

Resource allocator: Getting v4 back in

by Nico Huber

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?).

9 months, 3 weeks

Extended IvyBridge CPU configuration

by Lars Hochstetter

Hi everyone, I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot. Is anyone currently working on something similar? Is anything planned in that regard? Kind regards lhochstetter

9 months, 4 weeks

Booting Linux kernel with nosmp required on Lenovo T60 (ATI/AMD)

by Paul Menzel

Dear coreboot folks, On the Lenovo T60 (with AMD/ATI graphics) the Linux kernel (4.9, 4.19, 5.3, 5.4) hangs after starting user space. As SeaBIOS, GRUB, payloads and FreeDOS work, I tried to limit the number of CPUs, and booting Linux with `nosmp` gave me a booting system. It worked with older coreboot versions, so I think it’s a regression. I am able to reproduce this with coreboot 4.11 and 4.11-422-g1a5c3bb7fa. Is somebody else seeing this issue? Maybe on some i945 desktop board, so it would be easier to bisect? Kind regards, Paul

10 months, 1 week

T440p Audio Out

by acaleechurn＠gmail.com

Hello, The headphone jack is documented as broken and i was wondering if someone could help following a few tests I carried out with two identical laptops, one running the stock bios and the other corebooted. When unplugged the value is always value = 0x0 and when plugged the value changes to value = 0x80000000. When docked the value on the stock bios gets updated but not in coreboot. When using the headphone it gets updated but no sound is output. STOCK BIOS - Headphone sudo hda-verb /dev/snd/hwC1D0 0x15 GET_PIN_SENSE 0 nid = 0x15, verb = 0xf09, param = 0x0 value = 0x0 = Unplugged sudo hda-verb /dev/snd/hwC1D0 0x15 GET_PIN_SENSE 0 nid = 0x15, verb = 0xf09, param = 0x0 value = 0x80000000 = Plugged **Sound Works** COREBOOT - Headphone sudo hda-verb /dev/snd/hwC1D0 0x15 GET_PIN_SENSE 0 nid = 0x15, verb = 0xf09, param = 0x0 value = 0x0 = Unplugged sudo hda-verb /dev/snd/hwC1D0 0x15 GET_PIN_SENSE 0 nid = 0x15, verb = 0xf09, param = 0x0 value = 0x80000000 = Plugged **Sound does not work** STOCK BIOS - Docked [Headphone jack on the dock] sudo hda-verb /dev/snd/hwC1D0 0x16 GET_PIN_SENSE 0 nid = 0x16, verb = 0xf09, param = 0x0 value = 0x0 = Unplugged sudo hda-verb /dev/snd/hwC1D0 0x16 GET_PIN_SENSE 0 nid = 0x16, verb = 0xf09, param = 0x0 value = 0x80000000 = Plugged COREBOOT - Docked [Headphone jack on the dock] sudo hda-verb /dev/snd/hwC1D0 0x16 GET_PIN_SENSE 0 nid = 0x16, verb = 0xf09, param = 0x0 value = 0x0 = Unplugged hda-verb /dev/snd/hwC1D0 0x16 GET_PIN_SENSE 0 nid = 0x16, verb = 0xf09, param = 0x0 value = 0x0 = Plugged but not updated!!! ONLY the MIC is detected and enabled sudo hda-verb /dev/snd/hwC1D0 0x19 GET_PIN_SENSE 0 nid = 0x19, verb = 0xf09, param = 0x0 value = 0x0 = unplugged sudo hda-verb /dev/snd/hwC1D0 0x19 GET_PIN_SENSE 0 nid = 0x19, verb = 0xf09, param = 0x0 value = 0x80000000 = Plugged and Updated!!! When docked the mic is enabled by default but headphone is not detected. Strangely if i plug another headphone in the laptop headphone jack, the dock headphones start working! Could it be that the file https://github.com/coreboot/coreboot/blob/master/src/mainboard/lenovo/t440p… is missing the info about the jack being a combo port just like in the t520 https://github.com/rockchip-linux/coreboot/blob/master/src/mainboard/lenovo…

10 months, 1 week

[PATCH v4 0/2] firmware: google: Expose coreboot tables and CBMEM

by patrick.rudolph＠9elements.com

From: Patrick Rudolph <patrick.rudolph(a)9elements.com> As user land tools currently use /dev/mem to access coreboot tables and CBMEM, provide a better way by using read-only sysfs attributes. Unconditionally expose all tables and buffers making future changes in coreboot possible without modifying a kernel driver. Changes in v2: - Add ABI documentation - Add 0x prefix on hex values - Remove wrong ioremap hint as found by CI Changes in v3: - Use BIN_ATTR_RO Changes in v4: - Use temporary memremap instead of persistent ioremap - Constify a struct - Get rid of unused headers - Use dev_{get|set}_drvdata - Use dev_groups to automatically handle attributes - Updated file description - Updated ABI documentation Patrick Rudolph (2): firmware: google: Expose CBMEM over sysfs firmware: google: Expose coreboot tables over sysfs Documentation/ABI/stable/sysfs-bus-coreboot | 74 +++++++++++ drivers/firmware/google/Kconfig | 9 ++ drivers/firmware/google/Makefile | 1 + drivers/firmware/google/cbmem-coreboot.c | 128 ++++++++++++++++++++ drivers/firmware/google/coreboot_table.c | 58 +++++++++ drivers/firmware/google/coreboot_table.h | 14 +++ 6 files changed, 284 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-bus-coreboot create mode 100644 drivers/firmware/google/cbmem-coreboot.c -- 2.24.1

10 months, 2 weeks

Intel Atom C2758 performance issue

by amyhre＠galleonec.com

Hi We're having some performance issues with our system using the Intel Atom C2758 processor. The CPU core clocks are reduced after a reboot and is permanently stuck at this low speed until I do a power cycle. The "cpupower" tool reports that the frequency is 2200 MHz after a power cycle and 1200 MHz after a reboot. I have dumped the MSR registers, and the only register that stood out is the is the IA32_PERF_STS register. This register is set to "0xa6000000164a" and "0xa60000000c1d" after a reboot. I have tried setting the IA32_PERF_CTL register (with acpi-cpufreq disabled), but this doesn't seem to have any effect. The mainboard is using Coreboot v4.9 as BIOS and is based on the Mohonpeak board. I have tested both Debian 9 and Red hat 7, and both have the same issue. Appreciate if anyone can help or provide any input to on what I can do. Best Regards, Andreas Myhre Software Engineer Galleon Embedded Computing Email: amyhre(a)galleonec.com

10 months, 2 weeks

Lenovo T60p: Regression in master branch (resource allocator changes?)

by Paul Menzel

Dear coreboot folks, On the Lenovo T60p (with external AMD/ATI graphics) there was unfortunately a regression in the master branch. As it is bricked now, I am only able to provide logs, and won’t be able to test or bisect for quite some time. I successfully tested 4.11-1593-g49111cd2ba [1] as the last commit, and 4.12-406-g87e36c442e [2] has issues. The first issue is, that SeaBIOS hangs in around 90 % of the time in: Running option rom at c000:0003 The only remarkable difference in the logs is: -PCI: 06:00.0 bridge ctrl <- 016b +PCI: 06:00.0 bridge ctrl <- 0143 I created ticket #266 [3] for that. To debug this further, I tried to set up fallback/normal scheme, so switched from simple to normal bootblock, and added the “normal boot files”, but now it already hangs in coreboot when decompressing the payload. (I hadn’t reset the reboot counter yet, so it still uses the formerly working fallback files.) ``` coreboot-4.12-406-g87e36c442e Mon Jun 1 19:06:28 UTC 2020 bootblock starting (log level: 8)... […] CBFS: Locating 'fallback/payload' CBFS: Found @ offset 4d3c0 size 11109 Checking segment from ROM address 0xffe4d5f8 Checking segment from ROM address 0xffe4d614 Loading segment from ROM address 0xffe4d5f8 code (compression=1) New segment dstaddr 0x000dfac0 memsize 0x20540 srcaddr 0xffe4d630 filesize 0x110d1 Loading Segment: addr: 0x000dfac0 memsz: 0x0000000000020540 filesz: 0x00000000000110d1 using LZMA ``` ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 50076 none cpu_microcode_blob.bin 0xc480 microcode 86016 none fallback/ramstage 0x21500 stage 79299 none config 0x34b00 raw 589 none revision 0x34dc0 raw 674 none fallback/dsdt.aml 0x350c0 raw 12600 none cmos.default 0x38240 cmos_default 256 none cmos_layout.bin 0x38380 cmos_layout 1664 none pci1002,7149.rom 0x38a40 optionrom 64512 none fallback/postcar 0x486c0 stage 19616 none fallback/payload 0x4d3c0 simple elf 69897 none payload_config 0x5e540 raw 1621 none payload_revision 0x5ec00 raw 222 none etc/ps2-keyboard-spinup 0x5ed40 raw 8 none (empty) 0x5ed80 null 4568 none normal/romstage 0x5ff80 stage 50076 none normal/ramstage 0x6c380 stage 79299 none normal/dsdt.aml 0x7f980 raw 12600 none normal/postcar 0x82b00 stage 19616 none normal/payload 0x87800 simple elf 47498 none (empty) 0x931c0 null 1461208 none bootblock 0x1f7dc0 bootblock 32768 none ``` I created ticket #267 [4] for that, and attached the coreboot image and full logs there. Kind regards, Paul [1]: https://review.coreboot.org/cgit/board-status.git/tree/lenovo/t60/4.12-406-… [2]: https://review.coreboot.org/cgit/board-status.git/tree/lenovo/t60/4.11-1593… [3]: https://ticket.coreboot.org/issues/266 [4]: https://ticket.coreboot.org/issues/267

10 months, 2 weeks

Online Clang static analyzer scan-build results

by Paul Menzel

Dear coreboot folks, Next to the Coverity Scan reports, sent to the list again [1], I wanted to remind everybody, that the Clang static analyzer scan-build is also checking the coreboot code, and the results are available online [2]. There are probably some false positives in there [3], but also some correct warnings. It’d be great if you keep an eye on the results, and maybe even run it yourself. It’s as easy as prepending `scan-build` to the Make call, or by selecting the option in the Kconfig menu. scan-build make -j$(nproc) Kind regards, Paul [1]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/QFJR… [2]: https://coreboot.org/scan-build/ [3]: https://review.coreboot.org/c/coreboot/+/41420/9#message-9a65b4abc04834e2fc…

10 months, 2 weeks

New Defects reported by Coverity Scan for coreboot

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 6 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1429983: Control flow issues (DEADCODE) /src/drivers/uart/acpi/acpi.c: 104 in uart_acpi_fill_ssdt() ________________________________________________________________________________________________________ *** CID 1429983: Control flow issues (DEADCODE) /src/drivers/uart/acpi/acpi.c: 104 in uart_acpi_fill_ssdt() 98 reset_gpio_index >= 0 || enable_gpio_index >= 0) { 99 struct acpi_dp *dsd = acpi_dp_new_table("_DSD"); 100 if (config->compat_string) 101 acpi_dp_add_string(dsd, "compatible", 102 config->compat_string); 103 if (irq_gpio_index >= 0) >>> CID 1429983: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "acpi_dp_add_gpio(dsd, "irq-...". 104 acpi_dp_add_gpio(dsd, "irq-gpios", path, 105 irq_gpio_index, 0, 106 config->irq_gpio.polarity); 107 if (reset_gpio_index >= 0) 108 acpi_dp_add_gpio(dsd, "reset-gpios", path, 109 reset_gpio_index, 0, ** CID 1429982: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429982: Null pointer dereferences (NULL_RETURNS) /src/drivers/intel/pmc_mux/mux.c: 16 in mux_fill_ssdt() 10 { 11 return "MUX"; 12 } 13 14 static void mux_fill_ssdt(const struct device *dev) 15 { >>> CID 1429982: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 16 acpigen_write_scope(acpi_device_scope(dev)); 17 acpigen_write_device(acpi_device_name(dev)); 18 19 acpigen_write_name_string("_HID", TGL_PMC_MUX_HID); 20 acpigen_write_name_string("_DDN", dev->chip_ops->name); 21 ** CID 1429981: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429981: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/tigerlake/pmc.c: 104 in soc_pmc_fill_ssdt() 98 res->limit = res->base + res->size - 1; 99 res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED; 100 } 101 102 static void soc_pmc_fill_ssdt(const struct device *dev) 103 { >>> CID 1429981: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 104 acpigen_write_scope(acpi_device_scope(dev)); 105 acpigen_write_device(acpi_device_name(dev)); 106 107 acpigen_write_name_string("_HID", PMC_HID); 108 acpigen_write_name_string("_DDN", "Intel(R) Tiger Lake IPC Controller"); 109 ** CID 1429980: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429980: Null pointer dereferences (NULL_RETURNS) /src/soc/amd/picasso/root_complex.c: 138 in root_complex_fill_ssdt() 132 133 /* Used by \_SB.PCI0._CRS */ 134 static void root_complex_fill_ssdt(const struct device *device) 135 { 136 msr_t msr; 137 >>> CID 1429980: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(device)" when calling "acpigen_write_scope". 138 acpigen_write_scope(acpi_device_scope(device)); 139 140 msr = rdmsr(TOP_MEM); 141 acpigen_write_name_dword("TOM1", msr.lo); 142 msr = rdmsr(TOP_MEM2); 143 /* ** CID 1429979: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429979: Null pointer dereferences (NULL_RETURNS) /src/drivers/intel/pmc_mux/con/con.c: 37 in con_fill_ssdt() 31 struct acpi_dp *dsd; 32 33 if (!dev->enabled) 34 return; 35 36 /* Reference the existing scope and write CONx device */ >>> CID 1429979: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 37 acpigen_write_scope(acpi_device_scope(dev)); 38 acpigen_write_device(acpi_device_name(dev)); 39 40 acpigen_write_name_integer("_ADR", dev->path.generic.id); 41 42 /* _DSD, Device-Specific Data */ ** CID 1420207: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1420207: Null pointer dereferences (NULL_RETURNS) /src/superio/nuvoton/npcd378/superio.c: 328 in npcd378_ssdt_pwr() 322 323 acpigen_pop_len(); /* Pop SIOS method */ 324 325 acpigen_pop_len(); /* Pop Scope */ 326 327 /* Inject into parent: */ >>> CID 1420207: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 328 acpigen_write_scope(acpi_device_scope(dev)); 329 330 acpigen_write_name_integer("MSFG", 1); 331 acpigen_write_name_integer("KBFG", 1); 332 acpigen_write_name_integer("PMFG", 0); 333 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

10 months, 2 weeks

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2020