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