coreboot May 2020

coreboot@coreboot.org

43 participants
45 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

1 year, 2 months

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

1 year, 3 months

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

1 year, 3 months

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

1 year, 3 months

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…

1 year, 3 months

[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

1 year, 3 months

Re: libgfxinit quick starter guide

by Nico Huber

Hi Michal, hi Matt, On 15.03.20 06:41, Matt B wrote: > You probably want to speak with Nico. He's a libgfxinit expert afaik. thanks for the heads up :) > On Wed, Mar 11, 2020 at 9:45 AM Michal Zygowski <michal.zygowski(a)3mdeb.com> > wrote: > >> Particularly I would like to implement Braswell support for native >> graphics init with libgfxinit. Angel is also looking forward to Braswell support. He mentioned it as a possible summer-of-code stretch goal (after Bay Trail support), IIRC. But applications are not written yet (start tomorrow). > I see the programming manuals from Intel >> are in place: >> https://01.org/linuxgraphics/documentation/hardware-specification-prms Alas, this is a pitfall for Braswell. The only part that matters for libgfxinit (information about the display engine) is 100% scrubbed away. If you look into the `Display` chapter, it only contains legacy VGA registers and audio verbs, nothing about display at all. And if you search for any of "hdmi", "lvds", "mipi", "dsi", or "lane" in the `Register` chapter: nothing :-/ So for Braswell, the only public information source I know is the Linux driver i915. It's the one exception btw. All other chips have a proper `Display` chapter. Hence also the idea to add Bay Trail support first. Even if it turns out to be much different, we could at least tell if Brasswell is closer to Bay Trail or the newer Haswell/Apollo Lake engine. >> What do I need to implement a new microarchitecture in libgfxinit? Where >> to start and what should I focus on? This may get a little longer... but I knew I'll have to write it down eventually. In Ada, the code is organized in so called `packages`. In the way they are used in libgfxinit, one can simply see them as compilation units. Each package has a specification (.ads) file with declarations and a body (.adb) with code. Much like a header and a c file. Packages form a hierarchy and the name of the file has to reflect the package name, including its parents (stupid, imho). Libgfxinit has two major mechanisms in place to support different hardware generations: 1. Alternative implementations of packages. These are organized in sub-directories (also because every alternative package body has to have the same file name). For instance, we have different implementations for the package `HW.GFX.GMA.Connectors` in g45/, ironlake/, haswell_shared/ (the latter is shared with all newer generations since Haswell). Having alternative implementations of packages also means we can't build one binary that supports all generations. Luckily, we don't have to, so far :) 2. Configuration flags that are tested in shared code. Much like we have `if (CONFIG(FOO_BAR))` in coreboot, we have `if Config.Foo_Bar then` in libgfxinit. All these flags are gathered in a single package `HW.GFX.GMA.Config` which keeps conditions on specific hardware generations in a central place. The file, `hw-gfx-gma-config.ads.template`, is pre-processed with some sed-foo (see `common/Makefile.inc`). The comment from `hw-gfx-gma-config.ads.template:99` on explains some of the rea- soning. How much code sharing makes sense depends on the similarity to other hardware generations. I wouldn't be surprised if Bay Trail and Braswell end up using the g45/ code (no PCH and probably pre DDI which was intro- duced with Haswell), but I don't know that yet. Some more about the central packages: HW.GFX* (excluding HW.GFX.GMA*) =============================== There's some vendor-agnostic code around. Mostly for DP training and EDID interpretation. HW.GFX.GMA ========== This exposes the primary interface (procedure Update_Outputs()) and contains the overall control flow for setting up displays. Update_Outputs() takes a list of configurations for each graphics pipeline (up to three) and will try to set things up according to the configuration. Assuming a pipe is unconfigured, roughly the following steps are performed (by procedure Enable_Output()): * Optionally select a link configuration (e.g. for DP, how many lanes at what rate). * Allocate a PLL for the pixel/DP clock. * Try to train the selected link configuration (if there is none, the loops simply run once): - Prepare output connectors (Pre_On) - Enable the graphics pipeline (On) - Finalize the output-connector configuration (Post_On) This usually doesn't need changes for new hardware. HW.GFX.GMA.Pipe_Setup* (formerly Display_Controller) ==================================================== At the heart of the display engine is the pipe setup. Here we configure the framebuffer format (how to interpret bytes from DRAM), image pro- cessing (e.g. scaling) and the `Transcoders` that turn the image into a continuous stream of bits (including blank times) for a given pixel clock. IOW, everything from the framebuffer to a modeline. This was called `Display_Controller` earlier (probably for historical Linux reasons) and is still inside `hw-gfx-gma.adb` (easy to fix, but I didn't care to so far). It's mostly configured by flags from the `Config` package. Configu- ration of scalers is often implemented very differently, but most of it didn't change much over the years. HW.GFX.GMA.Connectors ===================== The `Connectors` package dispatches the Pre_On() and Post_On() calls (before and after configuring the graphics pipeline) to sub-packages for the individual connector types. This is a bit subtle. In a sense, `Connectors` reflect the outputs of the CPU package. In the first generations with a PCH (Ironlake including Sandy and Ivy Bridge) the CPU didn't have actual display outputs (like VGA, LVDS, HDMI etc.) but only links to the PCH which contained the final outputs. Later, the final outputs went back onto the CPU die. So we have three very different versions of this package: * g45/ outputs are in the GMCH (or CPU if one would add Bay Trail, it shouldn't matter). * ironlake/ FDI links in the CPU and (most) outputs in the PCH. * haswell_shared/ newer outputs (DDI) in the CPU (no legacy interfaces like VGA/LVDS, and HDMI/DP configuration changed since g45/). If none of these match the hardware to be added, one would have to write a new one. HW.GFX.GMA.PLLs =============== Usually there are some similarities but often changes between hardware generations. HW.GFX.GMA.Power_And_Clocks =========================== This started with some setup for generation specific things that didn't find another place. Newer generations have configurable clocks and can turn individual parts of the display engine on and off. Older ones often just have to report a pre-set Core Display Clock (CDClk). To wrap it up, `Power_And_Clocks` and `PLLs` most often need changes for new hardware. Followed by `Connectors` if these changed significantly, but most often one can add some code controlled by `Config` flags here. And, not to forget, all flags in the `Config` package need to be checked how they should be set for the new hardware. >> >> tl;dr; >> Haven't written anything in SPARK/Ada yet. It will be a new adventure >> for me. Can be fun but can also be exhausting ;) Depends much on how you can cope with nagging compilers and related tools. Nico

1 year, 3 months

Regarding Intel CPU frequency.

by nitin.ramesh.singh＠gmail.com

Hi, I am using coreboot to boot Denverton cpu (CPU C3558) based board. I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" under the coreboot logs. . " CPU #3 initialized bsp_do_flight_plan done after 146 msecs. cpu: frequency set to 2200 " Later when I check the frequency reading under linux (kernel version 4.19) , It comes out as 800 Mz: model name : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz stepping : 1 microcode : 0x24 cpu MHz : 800.000 When I reprogram the board with BIOS, the cpu frequency gets reflected correctly (i.e. 2200 MHz) with the same kernel image. I have also tried out the different Grub command line options like disabling the pstate, and idle state e.t.c, but the end result remains same. Can anyone please provide me some suggestions. Is there is any cpu specific settings which needs to enabled under coreboot or with Intel-FSP ? Thanks, Nitin.

1 year, 4 months

Status of Supermicro X11 series?

by Stéphane Delaunay

Hi all, I just wanted to ask about the current status of the Supermicro X11-series of boards. I read on a German magazine that it should be supported by joint efforts of 9elements and Mullvad. Link (auto-translated): https://translate.google.com/translate?hl=&sl=de&tl=en&u=https%3A%2F%2Fwww.… Apparently there was a presentation planned at the OSFC 2019, but I can't find anything on it and the boards-list still shows them as status "Unknown", which seems odd. Does somebody have any infos on the current development with these boards? Kind regards!

1 year, 4 months

Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5 protection bits?

by Alan K.L. Mok

Hi all, Can someone give me some hints or point me to some instructions please? Machine: Lenovo X1 Carbon 1st Gen (2012, no Boot Guard) Flashing tool: CH341A USB programmer + Debian Linux I am trying to replace the OEM firmware with Coreboot 4.12 and then install OpenBSD into the machine and set it up as an internet facing firewall. I ran me_cleaner against the dumped SPI image already. 1. Can anyone please tell let me know how can I achieve the captioned objectives? I looked into ifdtool & uefitool but found nothing related to my goal. I also tried the "lock ME/TXE" option during make menuconfig but Intel chipsec is still reporting the captioned bits not set on my Coreboot-flashed X1 Carbon 2. Is it correct to say that once the PR0-5 bits are set and Coreboot flashed into the machine, the values of the PR registers will be configured accordingly after machine boot up (when OS is having control)? Thank you very much for looking into my questions!

1 year, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2020