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
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
Dear coreboot folks,
My coreboot test S-ATA hard disk had `nosmp` on the Linux command line
configured so that Linux boots on the Lenovo T60. Now, testing this on the
AGESA board ASRock E350M1, Linux failed to detect the disk (/dev/sda), and
was unable to boot (USB and AHCI devices got error -22). Removing `nosmp`
from the command line made it boot. Using GRUB or SeaBIOS as payload didn’t
make a difference, and the old coreboot image I had (before switching to
C environment bootblock) *does* have the *same* problem, so the bug is
there longer. It’s reproducible with Linux 4.16.x and Linux 5.4.x.
It’s not reproducible on the Lenovo T60 (other way around), and QEMU i440fx
and Q35.
It’d be great, if you could test this on your coreboot boards, and report
back. Adding `nosmp` to the Linux kernel command line, for example, by
pressing e in the GRUB menu (and then Ctrl + x or F10 to boot) should be all
that is needed.
Kind regards,
Paul
Earlier this month Paul reached out to me in private and asked me
about a few of my board status uploads. We collectively noticed the
romstage now takes significantly longer to the tune of 1.5 seconds. We
were not quite sure where the problem was because I also tried
reverting to romcc bootblock and I didn't see much improvement.
Now that I have timestamps in i440bx ram init, I ran the tests again,
and here are the results. (This time my board status is not uploading
correctly...)
With serial console:
0:1st timestamp 741
11:start of bootblock 4,763 (4,021)
12:end of bootblock 4,980 (216)
13:starting to load romstage 6,127 (1,146)
14:finished loading romstage 6,269 (142)
1:start of romstage 6,724 (454)
2:before ram initialization 500,006 (493,282)
3:after ram initialization 670,733 (170,726)
4:end of romstage 2,189,924 (1,519,190)
100:start of postcar 2,311,060 (121,136)
101:end of postcar 2,311,061 (0)
8:starting to load ramstage 2,318,690 (7,629)
15:starting LZMA decompress (ignore for x86) 2,322,877 (4,187)
16:finished LZMA decompress (ignore for x86) 2,361,147 (38,269)
9:finished loading ramstage 2,369,966 (8,818)
10:start of ramstage 2,381,486 (11,519)
30:device enumeration 2,381,490 (4)
40:device configuration 2,447,811 (66,321)
50:device enable 2,649,524 (201,713)
60:device initialization 2,672,956 (23,431)
65:Option ROM initialization 2,819,134 (146,178)
66:Option ROM copy done 2,895,605 (76,471)
67:Option ROM run done 3,249,285 (353,679)
70:device setup done 3,283,763 (34,478)
75:cbmem post 3,287,313 (3,550)
80:write tables 3,287,315 (1)
85:finalize chips 3,427,717 (140,401)
90:load payload 3,431,452 (3,735)
15:starting LZMA decompress (ignore for x86) 3,460,849 (29,396)
16:finished LZMA decompress (ignore for x86) 3,517,611 (56,762)
99:selfboot jump 3,528,778 (11,167)
Total Time: 3,528,022
Without serial console:
0:1st timestamp 742
11:start of bootblock 4,763 (4,021)
12:end of bootblock 4,980 (216)
13:starting to load romstage 6,127 (1,146)
14:finished loading romstage 6,269 (142)
1:start of romstage 6,742 (472)
2:before ram initialization 315,196 (308,454)
3:after ram initialization 486,614 (171,417)
4:end of romstage 1,650,976 (1,164,362)
100:start of postcar 1,722,827 (71,851)
101:end of postcar 1,722,828 (0)
8:starting to load ramstage 1,722,929 (101)
15:starting LZMA decompress (ignore for x86) 1,722,952 (22)
16:finished LZMA decompress (ignore for x86) 1,761,057 (38,105)
9:finished loading ramstage 1,761,177 (119)
10:start of ramstage 1,762,626 (1,449)
30:device enumeration 1,762,631 (4)
40:device configuration 1,762,816 (185)
50:device enable 1,763,445 (628)
60:device initialization 1,763,542 (97)
65:Option ROM initialization 1,764,321 (778)
66:Option ROM copy done 1,826,366 (62,045)
67:Option ROM run done 2,175,483 (349,116)
70:device setup done 2,175,535 (52)
75:cbmem post 2,175,537 (1)
80:write tables 2,175,539 (2)
85:finalize chips 2,179,763 (4,223)
90:load payload 2,179,768 (5)
15:starting LZMA decompress (ignore for x86) 2,179,995 (226)
16:finished LZMA decompress (ignore for x86) 2,236,000 (56,005)
99:selfboot jump 2,236,034 (33)
Total Time: 2,235,277
---
So much of the slowdown between after raminit and end of romstage.
romstage also spent significant time before entering i440bx raminit.
Since this is outside my area, I'll defer to the masters here.
Thanks
Keith
When compiling coreboot for my Intense PC, I used binary blobs extracted from stock firmware. The ME/TXE firmware version is 8.1.20.1336 and this contains multiple security vulnerabilities. Unfortunately, running me_cleaner on ME blob breaks SATA [1], so
next best thing is updating to latest ME blob released by CompuLab. However, this seems not so straight forward.
Latest BIOS update for Intense PC was downloaded from here:
https://fit-iot.com/files/download/intense-pc/bios/16-04-2018/ipc_2.2.400...
I unpacked and mounted the image like this:
# mount -o loop,offset=16384 ipc_2.2.400.5.img /mnt/
This is the interesting files found in /mnt/ afterwards:
81723002.ME (7843840 bytes)
BIOS_IMG.bin (16777216 bytes)
I tried to extract intel fd modules from BIOS_IMG.bin:
$ ifdtool -x BIOS_IMG.bin
File BIOS_IMG.bin is 16777216 bytes
Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
Flash Region 1 (BIOS): 00d00000 - 00ffffff
Flash Region 2 (Intel ME): 00003000 - 00cfffff
Flash Region 3 (GbE): 00001000 - 00002fff
Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused)
However flashregion_2_intel_me.bin is just an empty file and the ME data is in 81723002.ME:
$ hexdump flashregion_2_intel_me.bin
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0cfd000
$ me_cleaner.py --check 81723002.ME
ME/TXE image detected
Found FPT header at 0x10
Found 23 partition(s)
Found FTPR header: FTPR partition spans from 0x180000 to 0x24a000
ME/TXE firmware version 8.1.72.3002
Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x
Checking the FTPR RSA signature... VALID
Setting location of 81723002.ME in CONFIG_ME_BIN_PATH during configuration of coreboot seems not to work.
Another important thing I found in coreboot documentation:
"Warning: Sandybridge Chipsets need a matching ME blob and IFD ! The board won't boot at all if one of them is invalid."
So if I understand correctly, I have to compile coreboot with the following files extracted from ipc_2.2.400.5.img:
flashregion_0_flashdescriptor.bin
flashregion_2_intel_me.bin
81723002.ME
The flashregion_3_gbe.bin extracted from stock firmware, also used when compiling coreboot the first time.
Does this sound right?
Also, what is the correct way to convert 81723002.ME into the proper flashregion_2_intel_me.bin?
Thanks in advance!
Regards,
Mogens Jensen
[1]:
https://github.com/corna/me_cleaner/issues/119
