January 2020 - coreboot - mail.coreboot.org

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

July 22, 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

Extended IvyBridge CPU configuration
by Lars Hochstetter July 16, 2020

July 16, 2020

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

6 31

Booting Linux kernel with nosmp required on Lenovo T60 (ATI/AMD)
by Paul Menzel July 7, 2020

July 7, 2020

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

3 5

OpenBSD won't install on an x220 Thinkpad with Coreboot
by Robert Milton April 12, 2020

April 12, 2020

I'm trying to get OpenBSD to install on an x220 Thinkpad with Coreboot/SeaBIOS but I'm running into two problems: the ethernet device doesn't work and OpenBSD doesn't detect my HDD. dmesg said em0 wouldn't load because the EEPROM had an invalid signature. I have no idea why OpenBSD doesn't see my HDD though. It's strange because everything works fine under Linux. And I cannot seem to mount a usb drive under the OpenBSD installer to attach dmesg errors. I originally posted this as a bug report to bug report mailing list but Theo said it would be better suited for Coreboot's and wasn't a bug in OpenBSD.

4 4

Mainboard porting assistance
by Benjamin Doron April 10, 2020

April 10, 2020

Hi all, I own an Acer Aspire VN7-572G and have not been impressed with its OEM firmware. After discovering that it does not utilise Intel's Boot Guard technology, that several Skylake and Kabylake laptops (it has a Skylake chip, but I read that the platforms are similar) have received successful coreboot ports and reading the porting guide on the wiki, I figured that I could give porting coreboot to my laptop a shot. When I was done, I figured that I had an image that might boot so I flashed it to my laptop with a Raspberry Pi and a SOIC clip. However, here's what it does: a) It powers on quietly, as expected; b) The backlight and power LED light up; c) The fans spin up to high and then it stays that way. It does nothing else. The display is dark too. After 15 minutes and a second attempt, I figured that I could no longer blame anything on a long first boot-up and gave up and flashed back to stock. Now, in all honesty I should have tried first without cleaning Intel ME but I find it so much more likely that I did something wrong than that cleaning ME was the sole problem. Can anyone advise me on how to continue? My code is here: https://github.com/benjamindoron/coreboot

7 42

Discussing Controversial Upstreaming
by Nico Huber Jan. 30, 2020

Jan. 30, 2020

Hello coreboot fellows, we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run. With that in mind, shouldn't additions to coreboot that have high chances to suffer the same fate be discussed in advance? It seems a huge burden for the community to add proprietary support for a platform, and all related effort is wasted if support can't be maintained. There are currently two new platforms in development that seem to have trouble with public binaries (which would be necessary to make the code useful to the coreboot community). Namely, AMD/Picasso and Intel/Skylake-SP. Support for the former is already partially rotting on our master branch. Shouldn't we discuss their fate before more resources are wasted? Nico

8 25

Proposal of tasks to update coreboot's documentation
by Patrick Rudolph Jan. 30, 2020

Jan. 30, 2020

Hi, this is a proposal of task that should be done in order to improve coreboot's documentation. It's focused on better user support, debugging and coding. Updating main-board specific or vendor specific documentation is always welcome, but on purpose not part of this list. Tasks that should be done by coreboot admin beforehand: - Add markdown linting - Build test sphinx (to find unreferenced docs) - Gerrit integration - Add rules for diagrams (SVG/ ASCII-Art) - - SVGs are preferred - - ASCII art seems common but needs java - Make Java dependency optional, ASCII art can be viewed without it - Restructure coreboot documentation structure (see below) 1. Updating the landing page (moving topics and adding new): * Add a user guide ** Toolchain building ** Improve Payloads description *** Kconfig Options *** Architectures *** Add tutorial how to build and run it (on qemu) *** Add more links ** Move existing payloads chapter to user guide * Add a developer guide ** Move the following chapters from main page into developer guide: *** Coding style *** Project Ideas *** Technotes *** ACPI *** native gfx init *** Display *** GPIO *** Everything coreboot src related (Soc/NB,SB, …) *Add a coreboot community guide ** Move the following chapters from main page into community guide *** Code of Conduct *** Community forums *** Project services *** coreboot at conferences *** What are the benefits of using coreboot? *** FAQ like, To be created 2. Topics that should receive good documentation by a technical writer (high priority topics first): * What are the benefits of using coreboot? * For Developers/Users: Toolchain building * For Developers/Users: Logging/debugging ** What logging capabilities does coreboot have? ** CBMEM, serial ,EHCI-debug, SPIconsole, flash console * For developers/Users: Timestamps * For Users: VBOOT guide ** Add USER Tutorial, how to use it on qemu ** Resign your firmware ** FAQ * More Developers guides ** CBMEM ** Region API ** What should be done in which stage? *** For example SMBUS init in romstage *** Minimize bootblock ** GDB in ramstage using stub (does it work?) ** Intel DCI for debugging firmware ** External JTAG debugging * Developer Specific: HOWTO Board Support? First steps on new boards and retrofitted boards... ** GPIO dump ** PCI dump ** ACPI dump ** dmidecode ** i2cdump ** Creating a device tree ** Adding Kconfigs for device drivers ** Configure FSP/raminit ** ... * Developer Specific: CBFS ** minimal documentation ** single linked list ** attributes ** compression ** CBFSv2 with hashes and metadata cache * Improve Payload descriptions ** See above * Developer Specific: TPM support ** A list of supported TPM * Improved utils documentation ** cbfstool * For developers: SELF loader ** Related to payloads * Build environment ** Building on Windows *** Minimal disclaimer: Not officially supported *** Working in WSL if ... ** Building on clang ** Minimal disclaimer: Not officially supported Please comment and give feedback. Kind Regards, Patrick Rudolph 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudolph(a)9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207 Geschäftsführung: Eray Basar, Sebastian Deutsch

1 0

No video output?
by Mogens Jensen Jan. 29, 2020

Jan. 29, 2020

I have compiled coreboot from master branch (63fd650e2e) and flashed it to a CompuLab Intense PC following this guide: https://watchmysys.com/blog/2017/12/coreboot-compulab-intense-pc-mintbox/ My problem is that video ouput is missing during POST, only after Linux kernel starts booting, video output become available. This problem is described in the guide and the solution is to include Intel VGA BIOS, which I have done, but still no video ouput before Linux kernel. The guide is two years old, maybe something has changed in coreboot since then, so more steps are required to get the video working? This is my defconfig: CONFIG_USE_BLOBS=y CONFIG_VENDOR_COMPULAB=y CONFIG_VGA_BIOS=y CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbios.rom" CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbt.rom" CONFIG_ENABLE_MSATA=y # CONFIG_DRIVERS_INTEL_WIFI is not set CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_0_flashdescriptor.bin" CONFIG_ME_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_2_intel_me.bin" CONFIG_GBE_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_3_gbe.bin" CONFIG_HAVE_IFD_BIN=y CONFIG_HAVE_ME_BIN=y CONFIG_CHECK_ME=y CONFIG_HAVE_GBE_BIN=y CONFIG_MAINBOARD_USE_LIBGFXINIT=y CONFIG_INTEL_GMA_ADD_VBT=y CONFIG_SEABIOS_BOOTORDER_FILE="bootorder.txt" Any ideas on what I could be doing wrong? Regards, Mogens Jensen

4 6

Workflows and Guidelines
by Patrick Georgi Jan. 28, 2020

Jan. 28, 2020

Hi everybody, one thing that became clear to me in the recent (and not-so-recent) discussions broadly related to coding style, code duplication, code submission strategies, documentation requirements and similar things is that there have to be many different styles of approaching coreboot development out there. As David said: > Which development model works for a particular project (or sub-project > within coreboot) depends on a lot of variables and I don't think we > can expect many people to stick around if we make unfeasible demands > of their workflow. We can only avoid making unfeasible demands on other people's workflows if we know these workflows. Developers might also benefit from guidelines telling them how to approach certain projects. On the other end, there's not really a standard on how we review things: For example some people (I belong to that crowd) tend to accept stuff that is part of active development (and for example have a long set of commits on top), even if there are minor issues left (that look like they create tons of patch handling work if fixed in the base commit of the patch train), on the understanding that people follow up on comments with later commits. Others seem, at times, to be rather close to give such a change a -2 review until it's perfect and all comments are addressed in that very commit. Which approach is right? I don't know. (And therein lies the problem) There are other points of disagreement in review style, and having unspoken assumptions be in force with some reviewer but not with others is a doubly confusing experience: we shouldn't expect things without stating them (but for the reviewer they probably appear to be natural) and the varying style means that every review can be a whole new experience full of surprises. So here's something I'd really love to do, but lack the time for: - Interview developers in all kinds of contexts (hobbyists, corporate, and so on) about how they work and what their constraints are - Interview reviewers on what they consider important, how they work and what they look for - Document all that, coalescing common pieces - Draft guidelines that bring the workflows (or variations thereof that the developers agree can be implemented on their part) in line with the review requirements and vice-versa. - Iterate on the guidelines until there's rough consensus The idea isn't to create some legal text to wield as a weapon during review ("§3 says that I can do it this way!" "but §7.a.5 says that you mustn't in this particular case!"), but to establish a baseline for common understanding when working on the code we all care for in this project. Such an effort probably takes half a year or longer (not full time, but catching up with folks, and rewriting draft after draft accumulates) and that's sadly nothing I can offer right now or in the near future. But, if there's somebody in the community wondering how they could participate, thinking that this is a useful endeavour and that it's just their cup of tea, that project is for the taking. (Or maybe this is just a stupid idea of mine) Beware though: the "Iterate" step looks short and simple in this text but it won't be since you'll have to reconcile all the forces pulling at the text. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Do we have a rule that code should be build tested?
by Nico Huber Jan. 28, 2020

Jan. 28, 2020

Hello again, so, we have Jenkins that runs build tests on our master branch. That makes working together on a huge project much easier. However, do we have a rule that all the code should be build tested? and if not, should we establish one? I've recently seen how much trouble it can cause when a whole new platform directory isn't hooked up for build tests. One has to double check every patch touching a file there. If in doubt, even run manual tests. That's a huge burden not only during development but also for reviewers. A burden that Jenkins would be happy to take if we let him. And even if people try to take care, they're just people, the untested code will break eventually. Of course, there'll always be a gap when a new platform is added. We could make it a rule, though, that no commit should be merged to the master branch, before the one that hooks the build test up is reviewed. Then, if anything goes wrong, and it's still not hooked up after 24h, revert it. How about that? Nico

3 8