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