> Even the "support" Team from the seller things it shold come with an
ITE8772, very mysterious..
> Did you ever seen one of those devices coming in from the OEM with
variation in onboard ICs ?
I haven't seen/heard about such a case so I am also surprised.
On 14.05.2021 21:42, Angel Pons
Hi Kyösti,
On 28.04.2021 12:33, Kyösti Mälkki wrote:
> Hi
>
> According to Documentation/releases/coreboot-4.14-relnotes.md we are
> expecting following chipset deprecations due to RESOURCE_ALLOCATOR_V3:
>
> * northbridge/amd/pi/00630F01
> * northbridge/amd/pi/00730F01
> *
Hi Arthur,
On 28.04.2021 08:41, Arthur Heymans wrote:
> Hi
>
> Currently the "COREBOOT" FMAP cbfs region has a file named "cbfs
> master header" at the bottom of this fmap region and the X86 bootblock
> has a pointer at 0xFFFC to it. Other ARCH have a "header pointer"
> file at the top of
come with ME in manufacturing mode and descriptor
unlocked, so whole image reflash is possible.
Best regards,
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
> On Tuesday, March 16, 2021 10:25 CET, Michal Zygowski
> wrote:
>
>> Hi,
>>
>> On 14.03.2021 05
Hi,
On 14.03.2021 05:32, lain via coreboot wrote:
> Does somebody successfully operates this Platform with HAP bit set ?
We are offering the FW6C in out shop:
https://3mdeb.com/shop/vaults/vaults-protectli/protectli-vault-fw6-c/
We also offer an option for neutering the ME (HAP bit included).
Any ideas what may be wrong?
I can share more details/logs if needed.
On 01.02.2021 16:48, Michal Zygowski wrote:
>
> Dear coreboot community,
>
> I have encountered problem with silicon init on Tiger Lake RVP
> platform. I managed to resolve previous issues with memory
> init
Hi Christian,
On 09.02.2021 11:58, Christian Walter wrote:
> Hi Michal,
>
> mind pointing me to the tooling you make for *creating* these manifests?
>
There is a whole intel_bootguard topic:
https://review.coreboot.org/q/topic:intel_bootguard
In particular have a look at these patches:
- Tool:
Hi,
On 09.02.2021 11:02, Arthur Heymans wrote:
> Hi
>
> To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some
> tooling is required to generate both a Key Manifest (A signed binary,
> that is checked
> against a key fused into the ME, holding keys that OEM can use to sign the
Dear coreboot community,
I have encountered problem with silicon init on Tiger Lake RVP platform.
I managed to resolve previous issues with memory initialization and now
hitting an error with TCSS init. The FSP asserts on IOM ready check,
which is 0. The configuration has selected
Hi Furquan, Tim,
On 20.01.2021 10:38, Michał Żygowski wrote:
> Hi Furquan,
>> Do you know the microcode version that you are using? There was an
>> issue with the older versions that caused a hang during NEM setup. As
>> per the commit message in
>> https://review.coreboot.org/c/coreboot/+/45094,
Of course it is reachable. Here's the license:
https://www.coreboot.org/Logo#coreboot_Logo_License
On 16.10.2020 17:46, Peter Stuge wrote:
> Vegetable Lasagna via coreboot wrote:
>> I really want to show my fan for you so if you have some stickers
>> for my laptop so I could brag it :) that will
Hi Peter,
> ..
>> PCI: 00:15.0 init
>> PCI: 00:15.0 init finished in 0 msecs
>> PCI: 00:15.1 init
>> PCI: 00:15.1 init finished in 0 msecs
>> PCI: 00:18.1 init
>> PCI: 00:18.1 init finished in 0 msecs
> Note that there is no init for 15.2 above. I don't know why, if it's
> enabled in the mainboard
out-of-the-box. But expect fixing the
vendorcode to get it compiled. In the end you should have full output
from AGESA.
Best regards,
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
On 16.10.2020 10:19, Michal Zygowski wrote:
> Hi Paul,
>
> See inline
Hi Paul,
See inline repsonses.
On 15.10.2020 20:04, Angel Pons wrote:
>
>> Clay
>>
>>
>> On Thu, Oct 15, 2020 at 3:54 AM Paul Menzel wrote:
>>> Dear coreboot folks,
>>>
>>>
>>> To get PCI bridge 0:15.2 enabled for the network device on the Asus
>>> F2A85-M PRO, I want to debug the PCIe General
Hi Andy,
Intel Firmware Descriptor is a 4KB big binary structure that describes
the layout of the SPI flash in the Intel firmware. Besides the layout it
contains various straps for CPU and chipset configuration which is
sampled at power-on.
There is nothing to worry about the lack of IFD. You
Hi,
Thanks for catching this. I will look into it. Most of the ACPI however
is not mainboard specific. My setup contains a RADEON GPU and i7-3770 CPU.
Best regards,
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
On 17.09.2020 17:33, Henkaku wrote:
> After booting into
Hi,
Please check out also this guide:
https://www.coreboot.org/Git#Pushing_changes
you need to tell git where to push: `HEAD:refs/for/master`. It seems the
guide on https://doc.coreboot.org/tutorial/part2.html is missing one
crucial step:
`git config remote.origin.push HEAD:refs/for/master`
Hi SenK,
If you are using the UEFI Payload you need to ensure that:
1. Your payload DSC file contains
"MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf" in the
[Components.] section (where is one from X64 or
IA32).
2. Your payload FDF file contains "INF
Hi SenK,
1. Check the flash descriptor straps for GPIO settings related to
SATAXPCIE pins. These are used for autodetection of SATA or NVMe disks
in M.2 slots, based on the PIN state processor exposes SATA or PCIe
lanes to M.2 slot.
2. Configure the Port9 and 3 next ports. The bifurcation will
d code did the job
>
> Have a great day.
> Jose Trujillo.
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, September 1, 2020 10:02 AM, Michal Zygowski
> wrote:
>
>> Hi Jose,
>>
>>> and I do similar to you under romstage.c -> mainboard_early_ini
Hi Jose,
>
> and I do similar to you under romstage.c -> mainboard_early_init:
>
> outb(0x55, 0x2e);
> outb(0x05, 0x0a3f); /* GP50= RI_2 : in */
> outb(0x05, 0x0a40); /* GP51= DCD_2 : in */
> outb(0x05, 0x0a41); /* GP52= RXD_2 : in */
> outb(0x04, 0x0a42); /* GP53= TXD_2 : out */
> outb(0x05,
Hi Jose,
I have worked on a port of SMSC SCH5545 on a Dell machine. These chips
are quite different than others. What I have learnt is that despite you
configure the SIO LDNs well, it may not be sufficient. I suggest you to
look at table 13-1 of the datasheet of SCH3114:
Hi Lenny,
There is a support for Carrizo processor using CarrizoPI AGESA blob. If
I am not mistaken the CPUID of this processor will be 660F01, so related
southbridge and northbridge support is there under
src/nortbridge/amd/pi/00660F01
and src/soutbridge/amd/pi/00660F01. But what I am concerned
Hi Nico, Peter,
On 6/24/20 8:50 PM, Nico Huber wrote:
> On 24.06.20 15:25, Peter Stuge wrote:
>> Michal Zygowski wrote:
>>> when VGA option rom is used, SeaBIOS finds the mode it fits the bootsplash
>>> resolution and bpp. Additionaly the display area is adjusted to
Hi Nico,
On 6/23/20 7:55 PM, Nico Huber wrote:
> On 23.06.20 16:51, Michal Zygowski wrote:
>>>> Now the only thing that comes to my mind are the VGA interrupts, because
>>>> SeaBIOS has more complete interrupt services than coreboot. Any comments
>>>> or su
Hi Nico,
On 22.06.2020 23:40, Nico Huber wrote:
> Hi Michal,
>
> On 22.06.20 10:29, Michal Zygowski wrote:
>> 3. Used VGA option rom to initialize graphics and display the bootsplash
>> in coreboot and SeaBIOS as well. What surprised me is that coreboot
>> displayed
on that? I think my next step would be to trace all INT
10h and compare the differences and fix it possibly in SeaVGABIOS.
Thanks in advance.
Regards,
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
On 3/30/20 10:21 AM, Michal Zygowski wrote:
> On 3/29/20 1:54 AM, Nico Huber wr
Patrick,
It looks like the same issue I had before, when I logged with different
authorization method...
Regards,
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
On 6/5/20 10:59 AM, Zheng Bao wrote:
>
> Hi, admin of gerrit,
>
> I tried to add my working mail address
Hi,
3mdeb office has two of these KGPE-D16 boards. We also experience some
issues with booting. Built an image from 4.11 branch using stable
SeaBIOS and enabled console over serial port. Using 1x Kingston
KVR16R11D4/16 16GB ECC RAM and booting without issues.
2. Secondary payloads may require
Hi JPT,
The --no-verify-all option is useful when you are flashing an image on
Intel platform that has ME and IFD regions locked/read-only. Even if
using --ifd -i bios, flashrom will verify whole image against the binary
file you passed to flashrom. --no-verify-all option tells flashrom
"please
Dear coreboot community,
What are the requirements for working PCIe hotplug support on
Intel-based platforms using FSP 2.0?
I see there are FSP configuration options for PCIe root ports hotplug,
but setting the bit alone and enabling PCIe hotplug in coreboot is
sufficient?
Typically there should
Hello coreboot community,
On the recent coreboot leadership a discussion arose around the patches
touching USE_BLOBS option:
https://review.coreboot.org/c/coreboot/+/39884
https://review.coreboot.org/c/coreboot/+/37972
A lot of items have been pointed to be solved:
1. A global policy about
On 3/29/20 1:54 AM, Nico Huber wrote:
> On 28.03.20 11:43, Michal Zygowski wrote:
>> I used the same picture laoding code and the same image. The only thing
>> that changed was the graphics initialization: VGA ROM vs libgfxinit.
> If you want to change the encoding (I never tri
and displays the
boot splash. The image was a JPG 1024x768 pixels (32bpp I guess).
On 3/27/20 9:35 PM, Nico Huber wrote:
> Hi Michal,
>
> On 27.03.20 15:49, Michal Zygowski wrote:
>> Another question about libgfxinit.
>>
>> Up till Skylake the libgfxinit worked great for me
are BGR (the same
image is not displayed in same way). Do you possibly know what may the
cause?
Michał
On 3/17/20 8:34 PM, Nico Huber wrote:
> Hi,
>
> On 16.03.20 13:01, Michal Zygowski wrote:
>> Regarding the registers description, maybe EDS or other documents have
>> bet
it is so I can get it myself.
Thanks again.
Best regards,
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
On 16.03.2020 00:15, Nico Huber wrote:
> On 15.03.20 20:37, Nico Huber wrote:
>>> On Wed, Mar 11, 2020 at 9:45 AM Michal Zygowski
>>> wrote:
>>>
Hi,
it may also be a Cedarview chipset. According to my knowledge there is
no support for Cedarview chipset in coreboot. However coreboot has
slightly older (1 year older) chipset support - Pineview.
My experience is very little when it comes to older chipsets, but
judging by how sanydbridge and
Hi coreboot folks,
For some time I have been interested in libgfxinit and I wondered how it
works (like in developer details).
Particularly I would like to implement Braswell support for native
graphics init with libgfxinit. I see the programming manuals from Intel
are in place:
The mainboards has been merged thanks to your help.
Additional thanks to: Patrick Georgi and Maxim Polyakov. Thank you for
contribution and reviews.
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
On 09.03.2020 23:30, Piotr Król wrote:
>
> On 3/9/20 11:19 PM,
/+/33839
https://review.coreboot.org/c/coreboot/+/30360
On 3/6/20 12:14 PM, Piotr Król wrote:
>
> On 3/3/20 4:33 PM, Michal Zygowski wrote:
>> Dear coreboot community,
> Hi Michal,
>
> (...)
>
>> The first two patches are solid and all issues documented. All of them
>>
Hello,
USB 3.0 device after reboot fails at address phase:
|7f247000| xhci_alloc_pipe: address device: failed (cc -1)
I have encountered many of such problems with USB 3.0 devices and my
conclusion is: no fix.
For example see:
Dear coreboot community,
I have been trying to merge few mainboard for some time, however I find
it difficult to get reviews (and lead it towards merging), despite
fulfilling all requests like Documentation entry.
Example:
Hello,
Mainboard porting can be difficult, depending on what components are on
the mainboard and what processor family is used. However this site:
https://www.coreboot.org/Motherboard_Porting_Guide
is a good starter.
Regards,
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
On 13.02.2020 11:27, Mogens Jensen via coreboot wrote:
> Thanks everyone for pointing me in the right direction, I didn't know about
> configuration data in ME.
>
> I did a quick comparison of the ICC profiles in the two ME images and found
> multiple differences.
>
> FCIM/BTM Specific ICC
Hi,
The ME often holds data about clock configuration for given mainboard.
It is not easy to figure out how to configure those clocks without the
proprietary Intel tools. That thing is called Integrated Clock
Controller - ICC (or something like that).
Also the vendor's firmware probably has "the
On 04.02.2020 12:17, Valentin wrote:
> Hello,
Hi,
>
> I've built coreboot for a asrock e350m1 mainboard before the weekend
> and with the current version SATA disks were not detected. Neither by
> SeaBIOS nor in a current Linux system booted from USB.
>
> As previos versions worked just fine i
Hi,
As Kyösti pointed, MP tables and IRQ is broken on AGESA boards. Most of
the mainboards have mindlessly copy-pasted code that generates MP tables
and IRQ tables. Those often contain entries of non-existing devices as a
result. Since the most preferred way of IRQ routing is ACPI and most
Hi,
Looking at harcuvar board and denverton_ns SoC sources it looks like the
GPIO controller is not defined in ACPI. It may be causing the probe to
fail for pinctrl in Linux. There is simply no GPIO ASL code for
denverton_ns. For example refer to soc/intel/skylake/acpi/gpio.asl.
Regards,
--
Hi coreboot community,
Is anybody aware if Boot Guard feature is supported on following processors:
Intel Celeron 3865U,
Intel Core i3-7100U,
Intel Core i5-7200U?
Are ACMs different across processor variants
(mobile/desktop/U/Y/H/etc.)? If I would take Boot GuardACM from another
6th or 7th Gen
I have taken a look on the irq_tables files for almost all AMD boards
and what I noticed is that the tables define a bridge device 14.4 as a
router and old SBXXX device/vendor ID. To me it looks like a copy-paste
from very old code base. I am going to look into that soon if I find
some spare time.
Hi Mike,
XHCI is muxed with EHCI on binaryPI 16h, so it might be teh same for
fam16kb. When XHCI dev 10.0 is disabled, one has to flip bits in the PM
registers additionally. If the board has no IRQ config for EHCI
(probably because XHCI is the default supported option) you probably
have to add
On 09.12.2019 05:36, Matt B wrote:
> Hi,
Hi Matt,
>
> Thanks for the pointer.
>
> I need a bit more context here, being completely unfamiliar with how
> coreboot works.
> I've never done any non-userspace programming, and this is the first
> time I've gotten a freshly-compiled coreboot to actually
On 05.12.2019 10:13, Jorge Fernandez Monteagudo wrote:
> Hi all,
>
> I've been able to make it work the Bettong board again with the commit before
> a0a50775
> as Kyösti Mälkki pointed. I've had to remove the next commit to make it work
> again.
>
> bfb5c807e720761f4457d5106bb919f2aacb5535
On 04.12.2019 16:15, Kyösti Mälkki wrote:
> On Wed, Dec 4, 2019 at 4:48 PM Michal Zygowski
> wrote:
>> On 03.12.2019 18:29, Kyösti Mälkki wrote:
>>> Hi
>>>
>>> Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
>>>
>>&
On 03.12.2019 18:29, Kyösti Mälkki wrote:
> Hi
>
> Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
>
> As of 3rd December there is active development, while not much testing
> yet, only for the following AGESA platform boards:
>
> * asrock/imb-a180
> * lenovo/g505s
> *
First of all there is not even a single board status entry for bettong.
Please upload one from the commit Kyösti pointed.
Regarding the AMD_S3_SAVE, see
coreboot/src/vendorcode/amd/pi/00660F01/AMD.h line 129 and later:
/* When AMD rolled out CarrizoPI, they made a bad choice of removing
* an
Here is a short guide how to upload board status:
https://github.com/coreboot/coreboot/blob/master/util/board_status/README
The system you are going to boot has to have cbmem installed.
On 27.11.2019 12:05, Jorge Fernandez Monteagudo wrote:
> Hi Michal,
>
>> I have initially wanted to send
Hi,
I have initially wanted to send patches with migration to postcar and C
bootblock for other platforms.
When I finish the work on apu2 I may setup a patch for testing, I would
appreciate if you could flash it on your board and provide results.
Be prepared to have:
- external programmer for
Only 7 days remain for submitting a talk proposals for @fosdem Open
Source Firmware, BMC and Bootloader Devroom! The Deadline is set to
Saturday, 1st December 2019 23:59:59 UTC. Don't miss it! Visit:
https://penta.fosdem.org/submission/FOSDEM20
Details:
Just in case somebody doesn't know yet..
https://edk2.groups.io/g/devel/message/50920
https://edk2.groups.io/g/devel/message/50921
--
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To
On 20.11.2019 16:38, awokd via coreboot wrote:
> Michal Zygowski:
>
>> I will soon update my patches with C_ENVIRONMENT_BOOTBLOCK for binaryPI
>> which will be rebased on top of postcar patches (easier for CAR teardown).
> Does https://review.coreboot.org/c/coreboot
On 14.11.2019 16:02, Jorge Fernandez Monteagudo wrote:
> Hi Mikal,
>
>
> >> - If I don't have CONFIG_VPD and CONFIG_SMMSTORE enabled, the
> entries RW_VPD(PRESERVE) and SMMSTORE(PRESERVE) are needed?
> >No, not needed. You may remove them. My FMD was just an example.
> >> - The RW_UNUSED@0x0
On 14.11.2019 15:28, Jorge Fernandez Monteagudo wrote:
>> Ohh I see the problem. Quotes are problematic in these cbfstool calls:
>>
>> agesa_binary := $(call strip_quotes,$(CONFIG_AGESA_CBFS_NAME))
>> cbfs-files-$(CONFIG_CPU_AMD_AGESA_BINARY_PI) += $(agesa_binary)
>> $(agesa_binary)-file :=
Ohh I see the problem. Quotes are problematic in these cbfstool calls:
"AGESA" but should be AGESA
Go to src/vendorcode/amd/pi/Makefile.inc and at the end of file replace the
code that adds AGESA to CBFS with:
agesa_binary := $(call strip_quotes,$(CONFIG_AGESA_CBFS_NAME))
I haven't provided the RW CBFS size, so it may be automatically
determining its size based on components size. Setting fixed size may
lead to the presence of some empty space.
And the RO_REGION_ONLY should be 'AGESA' not 'AGESA.bin', since we pass
CBFS names there, not filenames of binaries on
On 14.11.2019 08:48, Jorge Fernandez Monteagudo wrote:
> Hi Michal!
>
>> Under config VBOOT. And define the CMOS offset for vboot in Kconfig as
>> in the patch linked earlier. AGESA binary typically have to reside under
>> certain offset in the binary, so you have to pass the AGESA name to be
>>
Most likely you will need also this:
select VBOOT_VBNV_CMOS
select VBOOT_NO_BOARD_SUPPORT
select GBB_FLAG_DISABLE_LID_SHUTDOWN
select GBB_FLAG_DISABLE_PD_SOFTWARE_SYNC
select GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC
select GBB_FLAG_DISABLE_FWMP
select RTC
select
Hi Jorge,
I see you have AMD platform, so things may look differently than in the
linked patch. The example FMD file that could work for you (1 RW
partition only):
FLASH@0xff80 0x80 {
RW_UNUSED@0x0 0x2
AMDFW(PRESERVE)@0x2 0x9
SI_BIOS@0xb 0x75 {
Hi Dmitry,
Which FSP version do you have? 1.0, 1.1, 2.0, 2.1?
Typically post codes are described in the integration guides for FSP.
You can find one for your particular FSP and platform here:
https://github.com/IntelFsp/FSP
For example
Typically these are the options that one has to select in menuconfig.
But in order to have them work as expected you need few other things. As
a reference please heave a look at:
https://review.coreboot.org/c/coreboot/+/35998
You need to reserve some CMOS memory for vboot context, set default
Hi,
If you have a board with TPM just simply go with vboot + measured boot.
It will automatically extend the loaded parts of coreboot before execution.
Regards,
Michał
On 12.11.2019 11:10, Jorge Fernandez Monteagudo wrote:
> Hi all,
>
> I would like to extend to TPM PCR register the differents
On 10.11.2019 17:13, Kyösti Mälkki wrote:
> On Sun, Nov 10, 2019 at 12:35 PM Mike Banon wrote:
>> Thank you, I've sent the reports for Lenovo G505S (AMD Fam15h) and
>> ASUS AM1I-A (AMD Fam16h). Hope this helps, especially AM1I-A since
>> its' previous report was from early 2018.
>>
> I do not
On 31.10.2019 03:13, Desimone, Nathaniel L wrote:
> On 10/30/2019 3:11 AM, Michal Zygowski wrote:
>> Unfortunately it doesn't imply that. Vendor BIOS != FSP. The BIOS vendor
>> could obtain different memory initialization code from Intel with some
>> bug fixes
On 30.10.2019 08:31, Naveen Chaudhary wrote:
> Thanks David.
>
> Since some proprietary BIOS already works on this motherboard, this
> implies that I can use a different set of settings (timings, latency,
> etc) to make it work, as you suggested.
Unfortunately it doesn't imply that. Vendor BIOS
Hi Naveen,
If you had the built-in serial enablement option off, it was the FSP
which enabled the port instead of coreboot. Since FSP is called in the
middle of romstage, the logs started from after-FSP part of romstage.
When built coreboot with the built-in serial port enablement, the serial
Hi,
Search your devicetree.cb for UART PCI devices like:
device pci 19.2 on end # UART #2
device pci 1e.0 on end # UART #0
device pci 1e.1 off end # UART #1
As you can see above these entries describe the device.function of the
UART and the on/off switch. Try to turn them on and see what
Hi and welcome to coreboot,
First of all please use coreboot container:
https://hub.docker.com/r/coreboot/coreboot-sdk/
You are guaranteed to have no errors during compilation.
DVMT... this terminology is so confusing. I think it refers to the UMA
memory which is configured here for x220:
On 16.09.2019 14:20, Angel Pons wrote:
> Hello,
>
> On Mon, Sep 16, 2019 at 12:56 PM Michal Zygowski
> wrote:
>> On 14.09.2019 17:16, Андрей Карелин wrote:
>>> Hello
>>>
>> Hi,
>>> First of all thank you for your great work, I mean cor
On 14.09.2019 17:16, Андрей Карелин wrote:
> Hello
>
Hi,
> First of all thank you for your great work, I mean coreboot, it's
> really cool
>
> I have mainboad Supermicro X11SSM-F rev 1.01, which almost the same as
> supported X11SSH-TF. Any chance that it will work fine with ROM for
> X11SSH-TF?
in a document format like white paper or similar.
Regards,
Michał
On 13.09.2019 23:08, Matt B wrote:
> Hello,
>
> Are there any up-to-date references you're aware of, for those interested?
>
> -Matt
>
> On Fri, Sep 13, 2019 at 8:44 AM Michal Zygowski
> mailto:michal.zy
Thank you for response. I already got that working actually yesterdays
evening :)
If you mean the white paper A Tour Beyond BIOS with the UEFI TPM2
Support in EDKII and the wiki on GitHub, I have also encountered these
guides. They have removed TrEE protocol and rewritten whole TCG2 stack.
So
Hello,
Is anybody aware what would be the effort to include TPM measurements in
UefiPayloadPkg?
The drivers for TPM seem to be already present for DXE in SecurityPkg
and a function to measure the data with TPM and logging. However it does
not seem the payload package uses them.
Also I assume
On 8/21/19 8:59 AM, Kyösti Mälkki wrote:
> On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski
> wrote:
>> Hello Kyösti,
>>
>> Giving such a "credit" to give a little more time to bring the platform
>> to release requirements sounds like a good idea.
>&
Hello Kyösti,
Giving such a "credit" to give a little more time to bring the platform
to release requirements sounds like a good idea.
3mdeb will surely approach to implement those changes based on family
14h apu1, as well as for binary PI familty 16h based on apu2 (postcar
support already
ble
> CBFS_SIZE which actually stands for the size of SI_BIOS section, and
> sizes of SI_DESC, SI_GBE and SI_ME section can be inspected from the
> IFD file via ifdtool.
That would be very useful. Contributions welcome.
>
> On Thursday, August 8, 2019 8:12 AM, Michal Zygowski
>
On 08.08.2019 08:28, Persmule wrote:
> Hi Michal,
>
>
>
> On Wednesday, August 7, 2019 10:06 AM, Michal Zygowski
> wrote:
>
>> Here is an
>> example:https://github.com/coreboot/coreboot/blob/master/src/mainboard/lenovo/x220/vboot-rwa.fmd
>>
>>
>
Hello Persmule,
On 07.08.2019 06:23, Persmule wrote:
> Hi all,
> I found the typical fmap for a coreboot build using vboot (e.g. those
> for chromeos) is quite complex, at least with two RW sections
> containing CBFS, but I only want to use vboot to perform TPM
> measurement (like what head does
On 03.07.2019 15:13, awokd via coreboot wrote:
> Michal Zygowski:
>> On 03.07.2019 04:30, awokd via coreboot wrote:
>>> Michal Zygowski:
>>>> On 01.07.2019 14:53, Andriy Gapon wrote:
>>>>> It appears that HPET MSI support
>>>>> is disab
On 03.07.2019 04:30, awokd via coreboot wrote:
> Michal Zygowski:
>>
>> On 01.07.2019 14:53, Andriy Gapon wrote:
>
>>> It appears that HPET MSI support
>>> is disabled on some platforms by default:
>>>
>>> src/vendorcode/amd/agesa/f
On 01.07.2019 14:53, Andriy Gapon wrote:
> I am using a PCEngines APU2 system and I noticed that its HPET timers do not
> advertise FSB (MSI) interrupt delivery capability.
Any logs pointing to the statement?
> That is despite the fact that BKDG for family 16h models 30h - 3Fh says that
> those
In case it would have any meaning:
https://mail.coreboot.org/pipermail/seabios/2018-November/012553.html
My colleague discovered some inconsistence between coreboot tables and
e820 in SeaBIOS. However the patch has been forgotten on the mailing list.
Best regards,
Michał
On 11.06.2019 07:28,
Hello Kevin,
Thank You for interesting in the coreboot project. Feel free to submit
the patch via gerrit.
Please include the reasoning You have written here in a commit message
and push the patch. You will get Your review from coreboot developers
there and they will decide whether the patch is
Hello Peter,
I have experienced the same issue recently. It looks like Gerrit no
longer accepts the old push target branch.
Some days ago Gerrit accepted the 'refs/publish/master', but now it only
accepts 'refs/for/master'.
According to https://www.coreboot.org/Git 'refs/for/master' is the right
nitely look at platform design guide You have mentioned.
Thank You for help Alex.
Best regards,
Michał
>
>
> From: Nico Huber
> Sent: Friday, March 29, 2019 10:03 AM
> To: Michal Zygowski; coreboot@coreboot.org
> Subject: [coreboot] Re:
On 29.03.2019 18:03, Nico Huber wrote:
> Hi Michal,
Hi Nico,
>
> On 29.03.19 16:49, Michal Zygowski wrote:
>> I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M
>> configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM
>> (correc
Hi,
I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M
configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM
(correct me if I'm wrong) for DDR4 for example. But the DQ map is an
2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My
questions
ards,
Michał Żygowski
>
> -Original Message-
> From: Nico Huber [mailto:nic...@gmx.de]
> Sent: donderdag 28 februari 2019 10:49
> To: Michal Zygowski ; coreboot@coreboot.org
> Subject: [coreboot] Re: Intel Braswell uploads
>
> Hi Michal,
>
> On 28.02.19 10:
From: Patrick Rudolph [mailto:patrick.rudo...@9elements.com
> <mailto:patrick.rudo...@9elements.com>]
> Sent: donderdag 28 februari 2019 09:20
> To: Michal Zygowski <mailto:michal.zygow...@3mdeb.com>>; coreboot@coreboot.org
> <mailto:coreboot@coreb
On 28.02.2019 09:20, Patrick Rudolph wrote:
> On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote:
>> I would like to submit my candidacy for Braswell SoC maintainership
>> along with Piotr Król. Since we have 3 Braswell SoC platforms on
>> hand, we are willing to test
Hello,
I am going to push a new Braswell mainboard for review soon too and I
will be in the same situation as Frans. Without his patches, the boards
will not operate as they should.
Maybe we should think of transferring the maintainership of Braswell SoC?
Regarding the review, I have tested the
1 - 100 of 112 matches
Mail list logo
