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
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
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
If you know, please tell the AGESA versions of fam15h/fam16h AMD
vendorcode. For fam14h it is v1.103 - so no questions - but for fam15h
and fam16h it says v0.001: #define AGESA_VERSION_STRING {'V', '0',
'.', '0', '.', '0', '.', '1', ' ', ' ', ' ', ' '}
Also, I wonder if there's an AGESA changelog somewhere, to learn if
any security vulnerabilities or bugs have been fixed since AMD has
shared some AGESA revision with coreboot. If these problems are
serious enough, I could try to ask AMD to share the latest AGESA code
available for these platforms.
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
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
Hey,
is there a way to get the OSFC videos more directly?
E.g. I would like to download them as a bunch. youtube is quite
limited here. I perfectly understand, why it's on youtube, however
having them as simple download similiar to https:// with index or plain
old ftp would be nice! *
Best,
lynxis
* similiar to https://media.ccc.de/
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
Hi,
Linux kernel- 4.14. confing debug gpio and pinctrl-denverton, pinctrl-intel.
Coreboot-4.10 using denverton and harcuvar.
However, linux kernel not dectect gpio and pinctrl.
Thanks.
Jason
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
