Ron wrote…
>so how's it going?
Slowly! The day job has got in the way a bit but I have been struggling
to build the FSP binaries based on the instructions at [1]. I’m not
sure whether that is down to me not fully understanding the instructions
(always possible) or whether there is
Felix wrote...
>So, will you also step up as a maintainer for it?
I’m going to reserve judgement on that until I see how things go with
trying to get the existing coreboot code running on the boards. The Gen
1 should be here tomorrow (I think).
-Andy.
Thanks to the generosity of members of the list there are two Intel
Galileo boards, a Gen 1 and Gen 2, on their way to me which should
arrive towards the end of the month.
As soon as they get here I will start testing the various configs to see
what works and what is broken.
-Andy.
Vincent wrote...
> I can provide some Galileo h/w for folks if there is interest in supporting.
Looking at the configs it looks like both a Gen 1 and Gen 2 Galileo boards are
the place to start?
If you have both and can get them shipped to the UK that would be great. I
suspect I have power
Ron wrote...
> do you have a way to recover if the flash fails?
Current programming hardware includes...
Dataman 40-Pro
Dediprog EM100
Dediprog SF100
Totalphase Aardvark
Several CH341A devices
Failing that, I have a soldering iron and hot air rework station!
Hopefully one of them will work!
Karl wrote…
>Obviously a way to sidestep all this would be to simply test the board
>in question, which is a small investment of money and time.
There is still one of these boards (Intel Galileo) available on eBay
here in the UK. I can likely commit the time to test coreboot on that
board but
Nico wrote...
How about we set up some guidelines how to proceed when adding support
for a new platform that requires any blobs? My vague idea is as follows:
Before the very first commit for such a new platform can be merged, a
set of predefined, blob related questions (to be discussed)
Branden wrote...
In the first place, I think my assumption of it exposing a large rom
was wrong, it looks like they only actually only expose a small amount
as regular bios boot rom space. While that sounds annoying, it would
probably still be workable though.
…
I'm hoping that somebody
Julian wrote…
Is anyone actually actively using TianoCore EDK2 on top of coreboot or is
support experimental in general?
We have platforms that are using Matt’s UEFIPayload package to boot
either Linux or Windows. The mainboards and configs aren’t in the
upstream coreboot repo at present - I
I have an Getac B360 Laptop with these Specs:
sudo lspci -tvnn
-[:00]-+-00.0 Intel Corporation Comet Lake-U v1 4c Host
Bridge/DRAM Controller [8086:9b61]
+-02.0 Intel Corporation UHD Graphics [8086:9b41]
+-12.0 Intel Corporation Comet Lake Thermal Subsytem
Matt wrote…
you're building master, or a branch with
https://review.coreboot.org/c/coreboot/+/40520 included?
I’m running master branch at commit #f79f00991c (from 4 days ago) so
yes, it looks as though it has those changes included.
-Andy.
___
Matt wrote…
That means that the SMMSTORE / NVRAM EFI variable storage is getting
corrupted somehow. What platform is this on? I've seen some older
platforms which are problematic, especially Braswell, but newer Core
platforms seem to work reasonably well. There's also a new SMMSTOREv2
Matt wrote…
That means that the SMMSTORE / NVRAM EFI variable storage is getting
corrupted somehow. What platform is this on? I've seen some older
platforms which are problematic, especially Braswell, but newer Core
platforms seem to work reasonably well. There's also a new SMMSTOREv2
Matt wrote...
try disabling/deselecting SMMSTORE and see if that helps, assuming you
are using the default CorebootPayloadPkg target
That has fixed it, thanks.
-Andy.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to
Hello,
I have migrated my work-in-progress project, adding a new mainboard,
from coreboot v4.12 to v4.13 and now the boot using Tianocore is now
broken!
Under v4.12 it would boot into Ubuntu but under v4.13 it is just putting
me at a menu screen with three options: “Default Boot”, “Boot
Paul wrote…
What board is this and what chipset?
It is a custom laptop platform where we have been tasked to replace the
stock AMI BIOS with coreboot. It uses Intel Comet Lake.
Sorry, I do not know the exact answer, but looking at the quirk implementation
in Linux 5.10-rc5, it consists
Hello,
With the stock BIOS in the board I am working on one of the nodes for
the ALC256 CODEC is:
Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
Control: name="Headphone Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00,
Matt wrote…
exactly this. On most devices, the payload will execute ~600ms after
coreboot starts, and the image probably wouldn't start being displayed
until halfway thru that. So it would be up for ~300ms and likely just
appear as a flicker. Not to mention needing a different sized/formatted
Matt wrote…
for Tianocore, use the latter only. Needs to be a 24bpp windows BMP, no
larger than the width of the screen and 75% of the height (the image is
centered 38.2% down from top as per BGRT spec). Gimp can be used too
but likely will have a pallette shift if a non B image used
Customer
Hello,
Using the VBT route for graphics initialisation and TianoCore as the
payload gives two options within .config for splash screen:
CONFIG_BOOTSPLASH:
This option shows a graphical bootsplash screen. The graphics are loaded
from the CBFS file bootsplash.jpg.
Hello all,
When I boot my board (Intel Comet Lake based) using Coreboot I have one
too many I2C busses compared to the stock AMI BIOS. Using i2cdetect
under Ubuntu with the stock BIOS it shows:
$ i2cdetect -l
i2c-3 unknown i915 gmbus dpc N/A
i2c-1
Patrick wrote...
I'd love to see somebody pick up the bits of information they gather on
the device tree and write a doc on that in Documentation/ (which gets
rendered to doc.coreboot.org). Andy, willing to take that on? :-)
I’m happy to give it a try but it will have to wait until I’ve
Hello,
Is there an idiots guide to the definitions in devicetree.cb? Trying to
make sense of the USB and PCIe configuration stuff.
-Andy.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to
Naresh wrote…
Cbfs dump clearly shows presence of vbt.bin in COREBOOT region.
It's strange that during runtime it was not able to detect the same. I
guess you need to focus around here.
Can you enable cbfs specific debug messages(CONFIG_DEBUG_CBFS) and
provide/check logs?
If vbt.bin is
Naresh wrote…
1. Can you provide complete dump of cbfs content which is displayed at
end of make.
FMAP REGION: COREBOOT
Name Offset Type Size Comp
cbfs master header 0x0cbfs header32 none
fallback/romstage 0x80
Hello,
I’m trying to find and fit all of the pieces together to get the display
running on my custom platform (based on Intel Comet Lake). Here are the
known facts...
1. The LCD including the backlight enable and PWM signals are all
connected to the eDP interface on the SoC.
2. When I
I wrote...
static const struct cnl_mb_cfg memcfg = {
…
};
Having been back and verified against the schematics, I have found a
couple of value that were incorrect.
spd[1] and spd[3] needed to the set to NOT_EXISTING and the designed is
not interleaved so .dq_pins_interleaved needed to
Naresh wrote...
To understand the exact failure cause in FSPM, you need to get post
code from FSP. What is printed in log is Coreboot post code only.
Is it possible to get the post code from FSPM without a hardware POST
code indicator?
The hardware I am using only has an M.2 slot (used for
Angel wrote...
Well, I'd like to see your code: which memcfg parameters you're using,
among other things. Could you please put it somewhere (e.g.
review.coreboot.org) so that I can take a look?
I have basically just taken the memcfg structure from the Intel Comet
Lake reference platform and
Angel wrote...
I can’t match what is printed on the top of the Micron devices (two lines of
text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website. Is it some
kind of encoded version of the part number or is it just factory and build
information? Looking at the website I would
Naresh wrote…
Don't know how to recover SPD from UEFI but Try to read memory part
number written on chip and provide that. Look for SPD file with that
name if it's already present in coreboot.
The schematics for the platform show Samsung K4A8G165WB-BCRC devices
which are (8Gb, 2400Mbps,
Hello,
I have some life out of my Comet Lake based board but the debug output
ends with
FMAP: area RW_MRC_CACHE found @ 42 (65536 bytes)
MRC: no data in 'RW_MRC_CACHE'
PRMRR disabled by config.
WEAK:
src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params
called
Angel wrote…
This means you're going to use libgfxinit instead of a video BIOS.
libgfxinit is a graphics modesetting library written in SPARK, a
OK, so that isn’t the way I want to go (I don’t think). Using the
romheaders utility on the file I have extracted gives me:
Image 1:
PCI Expansion
Naresh wrote…
Looking at kconfig, the mainboard should select
MAINBOARD_HAS_LIBGFXINIT.
For example see "grep -rsn MAINBOARD_HAS_LIBGFXINIT src/"
I haven't used this, so not sure what else might be needed.
In order to get the build to progress I have needed to select
Naresh wrote…
2. Open file ->
vim src/drivers/intel/gma/Kconfig +90
Add like so that it looks like:
|| SOC_INTEL_WHISKEYLAKE || SOC_INTEL_COMETLAKE
So, I have made the change to src/drivers/intel/gma/Kconfig and when I
run the build it now gives the error:
warning: (BOARD_SPECIFIC_OPTIONS)
Hello,
Using the instructions in the old Wiki page [1] I have used the UEFI method and
UEFI tool to extract the video BIOS from the standard binary that comes with
the board.
I have followed the layout of some of the other Kconfig files in the mainboard
directory and added the following to
Marc wrote...
Check out the linux source for some tips. It looks like the alc256 is a
alc269 variant, so expect the register space to be similar. If you can,
dump the verbs etc from linux.
I have the datasheet for several of the ALC26x variants along with the
verb table dumped from Linux.
Hello all,
A bit of a long shot… does anyone have a datasheet for the ALC256 HDA
audio CODEC?
I know that the device exists as I have some boards with it on (that I
am working on a Coreboot port for) on my desk but a look on the Realtek
website doesn’t yield anything.
Thanks,
-Andy.
Hi Felix...
Does the EC firmware of your system reside in the IFD EC partition or in the
IFD BIOS partition? The former doesn't seem to be the case, since ifdtool
complains about nor IFD EC region being present in the IFD. For the latter have
a look at 51nb/x210 and mb/amd/mandolin where an
Duncan wrote...
I have the binary file for the original system BIOS for this platform
and so have manage to use ifdtool to extract the 4KB flash descriptor
which I am in the process of adding to the image with
CONFIG_HAVE_IFD_BIN and CONFIG_IFD_BIN_PATH. Does that save me having
to worry
Duncan wrote...
You can enable CONFIG_HAVE_EC_BIN and define CONFIG_EC_BIN_PATH
(https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/southbridge/intel/common/firmware/Kconfig#115)
to point to the EC binary and the build system will use ifdtool to
inject the binary at
Hello,
I have a binary file that is the firmware for the embedded controller on
the laptop platform that I am working on. In the regular BIOS provided
by the hardware vendor this 128KB binary is located at offset 0x40
in the BIOS image.
Is there any documentation or instructions
Hello,
I’m working on porting Coreboot to a laptop that uses Intel Comet Lake.
When the build completes it spits out the following warning:
** WARNING **
coreboot has been built without an Intel Firmware Descriptor.
Never write a complete coreboot.rom without an IFD to your
board's
Hello,
I’m trying to make sense of the information on the Intel website, and the
Coreboot source code, regarding the i3-10110u and i7-10710u processors.
If I have interpreted things correctly, these are Comet Lake U devices and that
the Comet Lake U DDR4 RVP reference board is supported as a
Hello Idwer,
Which version of python are you using here? My build box uses 2.7.6
I am using the default versions of tools that come with CentOS 6.5 so host
gcc is version 4.4.7 and Python is version 2.6.6.
I fired up my old 32bit Debian box which has Python 2.6.2 and host gcc
version and it
Hello!
Apparently CentOS installs, or will install, a really old version of
iasl; here you'll see that they (still) use
iasl-20090123-3.1.el6.x86_64:
http://mirror.centos.org/centos/6.5/os/x86_64/Packages/ while the xgcc
version is 20130626.
After doing some poking around it appears that
Hello!
I am trying to setup a build environment on 64bit CentOS 6.5 platform to be
able to build coreboot. I have cloned the coreboot sources from git and
have run the following commands:
make crossgcc -- to build the cross compilers
make menuconfig -- to create the default .config file
make
47 matches
Mail list logo
