Hello Everyone,
As a result of incoming 4.7 release many boards are going to be
deprecated. We would like to support alix platforms which are based on
Geode LX and yet not EARLY_CBMEM_INIT enabled. We have all hardware at
hand and would gladly bring these platforms up to current standards.
We saw
Hello Duncan,
There was a SeaBIOS upgrade from 1.10.x to 1.11.x some time ago.
As You maybe already figured out, SeaBIOS needs to be configured to use
serial
console from now on. Try adding the following file to CBFS image by doing:
cbfstool coreboot.rom add-int -i -n etc/sercon-port
The serial
Hello Christian,
You are right, mentioned SoC is supporting PSP, however we are not using
it. We were not reached by any urge needs to enable it on apu2 series
platforms on the fork repository [0]. Do You have any special needs if I
may ask?
I am also adding Piotr Król on CC as he is also PC Engi
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,
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 CONFIG_USE_INTEL
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
>
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: ht
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,
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). So
e 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 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 that
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
> * northbridge/amd/pi/00660
> 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 wrote
Hello coreboot community,
It seems like recent changes to PCI introduced regression. Building
coreboot for PC Engines apu2 results in unbootable image halting at:
get_pbus: dev is NULL!
occuring in dev_finalize_chips during boot state machine write_table
entry. I suspect it may be related to dev
Thank You Kyösti for Your immediate response and help.
Your patch fixes the issue. Many thanks.
Best regards,
Michał
On 21.01.2019 13:32, Kyösti Mälkki wrote:
>
>
> On Mon, Jan 21, 2019 at 1:49 PM Michal Zygowski
> mailto:michal.zygow...@3mdeb.com>> wrote:
>
>
Dear coreboot community,
I am experiencing problems with FSP Memory Init on Braswell SoCs. FSP
Memory Init is not returning. I have following processors that fail:
Celeron J3060 and Celeron J3160; both have the same issue.
The platform has 1 SODIMM module on channel 0. I am feeding the UPD
header
MemorySpdPtr
0x01: PcdIgdDvmt50PreAlloc
0x02: PcdApertureSize
0x01: PcdGttSize
0x00: PcdLegacySegDecode
0x01 --> 0x00: PcdDvfsEnable
Calling FspMemoryInit: 0xfff6780f
0x: NvsBufferPtr
0xfef01de4: RtBufferPtr
0xfef01d8c: HobListPtr
POST: 0x92
After the post code 0x
ng any further. The
dump is from serial port on SuperIO.
Thank You in advance.
Best regards,
Michał
On 29.01.2019 10:12, Frans Hendriks wrote:
> Hi Michal,
>
> We have implemented coreboot on Braswell SoC (Pentium N3170) using SPD.
>
> Did you verify the UDP fields: PcdMemoryTypeEnab
ion of FSP.
>
> Best regards,
> Frans
>
> -Original Message-
> From: Michal Zygowski [mailto:michal.zygow...@3mdeb.com]
> Sent: dinsdag 29 januari 2019 11:22
> To: coreboot@coreboot.org
> Subject: [coreboot] Re: Braswell FPS memory init problems
>
> H
On 18.02.2019 20:28, Zvi Vered wrote:
> Hello,
Hi Zvika,
>
> I suspect the RAM on my bay-trail module has no SPD interface.
> Can Intel's FSP work without SPD ?
>
> I tried to run decode-dimms with vendor's bios and got:
> No EEPROM found, try loading the eeprom or at24 module
>
It looks like You
On 2/19/19 7:50 PM, Zvi Vered wrote:
> Hi Michal,
>
> Thank you very much for your reply.
>
> You are right. I have soldered down memory. No dimm slot.
> In what routine should I configure RAM ? Where can I see a sample code ?
coreboot has everything prepared for that. What I would do is to lo
d/or Generic Drivers
menu. There You can enable inclusion of microcode and FSP binary. When
enabled, the base addresses for the blobs pop up in one or both menus.
Some platforms have their minimal configs in the configs directory, but
some unfortunately not and one have to go through whole conf
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
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
sage-
> 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
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:38,
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 are
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
>> (correct me
definitely 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]
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
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 el
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, Ky
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 ca
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 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
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 w
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
>>
>>
>
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
>
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 slowly
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,
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 tha
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 most
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:mich
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?
I
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
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:
https:
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 happe
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
por
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 !=
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 and it
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 pla
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 p
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
vboo
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
https://github.com/IntelFsp/FSP/blob/master/KabylakeFspBinP
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 {
RW_S
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 VBOOT_STAR
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
>>
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 the
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))
cbfs-files-$(CONFIG_CP
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 := $(CO
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 0x200
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
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
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: https://lists.fosdem.org/pipermail/fosdem
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 re
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 patch
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 ent
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
> * pcengine
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 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 binar
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
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 the
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 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
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,
--
Mic
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
systems
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 nar
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 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 Regis
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
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:
https://review.coreboot.org/c/coreboot/+/30360/13#message-7720bf7ed3f447a8
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:
https://github.com/pcengines/apu2-documentation/blob/master/docs/debug
/+/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
>>
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,
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:
https://01.org/li
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
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:
>>>
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
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
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
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 buildi
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
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 ve
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 som
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 zhen
ns 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 Hub
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
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, 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 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 a
1 - 100 of 112 matches
Mail list logo
