[coreboot] Re: Yangling/ FW6C board with different SUPERIO CHIP, I found the problem

[Michal Zygowski]

> 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:

Hi,

On Fri, May 14, 2021 at 7:38 PM lain via coreboot  wrote:

Probing for ITE Super I/O (init=standard) at 0x2e...
   Failed. Returned data: id=0x8613, rev=0x8

superiotool doesn't know about the IT8613E, but looks like there's one.
Too old coreboot revision probably to get superiotool detect it, because 
we have been adding IT8613E support: 
https://review.coreboot.org/c/coreboot/+/31620


Best regards,
Angel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Best regards,

--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Resource allocator v3

[Michal Zygowski]

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/00660F01 (already removed)
> * northbridge/amd/agesa/family14
> * northbridge/amd/agesa/family15tn
> * northbridge/amd/agesa/family16kb
>
> Any progress or any interest to get these fixed?
Working on northbridge/amd/pi/00630F01 and
northbridge/amd/agesa/family14 in particular right now. Hope to upload
the patches soon. Struggling with the SeaBIOS right now which doesn't
seem to see any content behind BARs of peripheral controllers and PCIe
devices after switching to allocator v4. Any hints?

If I find what is wrong, then the rest of the families should be easier
and I can get them fixed too.
>
> Regards,
> Kyösti
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Dropping the "cbfs master header" file

[Michal Zygowski]

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 FMAP region pointing to it.
>
> Currently this file is only used as an anchor point to use cbfs with
> walkcbfs_asm on X86 to access cbfs in assembly (before any C code).
> There are 2 uses for this at the moment:
> 1) updating microcode on Intel systems that don't feature FIT before
> setting up CAR
> 2) finding FSP-T (if FSP_CAR is used) before jumping to it
> Both the cbfstool and the C coreboot code don't rely on it anymore, so
> it is a legacy feature. Other cbfs FMAP region like FW_MAIN_A/B in a
> VBOOT setup don't feature it.
The SeaBIOS payload still relies on this pointer at the 0xFFFC to
find the CBFS master header. If we remove it, we will break the CBFS
driver in SeaBIOS and thus lose many functionalities there, which I
would like to avoid.
>
> Accessing cbfs with walkcbfs_asm breaks hardware based root of trust
> security mechanisms like Intel bootguard/TXT/CBnT, because no
> verification or measurement whatsoever happens on either " cbfs master
> header" of "fsp-t" files. So for instance even if TXT/Bootguard
> measured or verified FSP-T as an IBB so that it is trusted, an
> attacker could insert a new cbfs file with the same name, "fsp-t" at a
> lower address and coreboot will run it anyway.  So a static pointer to
> fsp-t is required. Sidenote/Rant: FSP-T continuously causes such
> integration problems... Blobs that set up the execution environment
> are just a very bad idea.
>
> So I propose to drop the legacy "cbfs master header" file and adapt
> the 2 current use cases in the following way:
> - Reuse the Intel FIT table and implement FIT microcode updates in
> assembly/software. (I had this working on some point, before I decided
> to use walkcbfs_asm)
Agree on that, walkcbfs_asm should be removed. But why to implement
microcode updates since CPU comes out of reset with microcode loaded
from FIT? Platforms from pre-FIT era should be a concern? There is no
pre-reset ROT for the firmware.
> - Either fix the location of FSP-T via for instance a Kconfig option
> or add a pointer to "fsp-t" at a fixed location in the bootblock and
> have the tooling update the pointer during the build process. I think
> the Kconfig option is the least amount of work and cbfstool is already
> overloaded with options and flags, so my preference goes to this.
FSP-T is not automatically relocated by cbfstool IIRC, so a Kconfig
option with fixed address (set to default per microarchitecture/FSP in
the SoC Kconfig) should be good. In such way we ensure FSP-T is always
at the right address.
>
> Let me know what you think.
>
> Kind regards
>
> Arthur Heymans
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,
-- 

Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Protectli FW6C HAP bit

[Michal Zygowski]

Hi Iain,


On 23.03.2021 13:31, lain via coreboot wrote:
> Thank you for your Anwser Michail,
> do you know if  these Devices support Full Image internal flashing (
> means with an HAP bit set ME image) when they come preinstalled with
> the factory UEFI ?

By default they 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: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 we
>> confirm it works.
>>
>>
>> Best regards,
>>
>> --
>> Michał Żygowski
>> Firmware Engineer
>> https://3mdeb.com | @3mdeb_com
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
>
>  
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Protectli FW6C HAP bit

[Michal Zygowski]

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 we
confirm it works.


Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: TigerLake RVP TCSS init failure

[Michal Zygowski]

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
> 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_FSP_MP_INIT (without MP PPI service).
>
> When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is
> selected, then the FSP-S returns smoothly (at least from one of the
> phases I guess) and resets after clearing MCEs in coreboot's CPU init:
>
> CPU: vendor Intel device 806c0
> CPU: family 06, model 8c, stepping 00
> Clearing out pending MCEs
> Setting up local APIC...
> apic_id: 0x00 done.
> Turbo is available but hidden
> Turbo is available and visible
> CPU #0 initialized
> Initializing CPU #2
> Initializing CPU #6
> Initializing CPU #7
> CPU: vendor Intel device 806c0
> CPU: family 06, model 8c, stepping 00
> CPU: vendor Intel device 806c0
> CPU: family 06, model 8c, stepping 00
> Clearing out pending MCEs
> Cl (tutaj następuje reset)
>
>
> Any ideas what may cause these issues? When I clean this up, I will
> upstream the DDR4 variant of TGL UP3 RVP.
>
> -- 
> Michał Żygowski
> Firmware Engineer
> https://3mdeb.com | @3mdeb_com
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Michal Zygowski]

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: https://review.coreboot.org/c/coreboot/+/43403
- Hook manifest creation into build system:
https://review.coreboot.org/c/coreboot/+/43404

The manifests layout is implemented in the tool. Although it creates the
v1.0 manifests and AFAIK CBnT required v2.1 format, but this tool can be
a good base, isn't it?


Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Michal Zygowski]

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 
> BPM)
> and a Boot Policy Manifest (signed binary, has a digest of IBBs,
> Initial Boot Blocks).
> At the moment these are included as binaries by the build system.
>
> Obviously this only works if the IBB hasn't changed. If it changed, you'd
> need to regenerate the BPM. 9elements has written some open source tooling
> (BSD-3 clause) to generate both KM and BPM. The code for this tool is not yet
> public as it was written using NDA documentation. Intel is currently reviewing
> this to allow us to make it public, but this takes time. It will be
> part of the 3rdparty/intel-sec-tools
> submodule.

What is the diff between BtG and CBnT manifests format? Is the work that
we (3mdeb) did, not usable?

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] TigerLake RVP TCSS init failure

[Michal Zygowski]

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_FSP_MP_INIT
(without MP PPI service).

When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is
selected, then the FSP-S returns smoothly (at least from one of the
phases I guess) and resets after clearing MCEs in coreboot's CPU init:

CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping 00
Clearing out pending MCEs
Setting up local APIC...
apic_id: 0x00 done.
Turbo is available but hidden
Turbo is available and visible
CPU #0 initialized
Initializing CPU #2
Initializing CPU #6
Initializing CPU #7
CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping 00
CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping 00
Clearing out pending MCEs
Cl (tutaj następuje reset)


Any ideas what may cause these issues? When I clean this up, I will
upstream the DDR4 variant of TGL UP3 RVP.

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Problems with CAR setup on Tiger Lake

[Michal Zygowski]

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, it looks like you need
>> 0x56 or newer microcode for enhanced NEM to work.
>>
>> A quick way to verify if it is the microcode version issue: Select
>> INTEL_CAR_NEM instead of INTEL_CAR_NEM_ENHANCED for your board and see
>> if it gets any further in the boot.
>>
> I have tried a few microcodes:
> - the one shipped originally with RVP platform is CpuSignature:
> 000806C0h, Revision: 0064h, Date: 02.03.2020 so the revision is
> newer that 0x56.
> - also tried from TGL_BIOS_ww51_2020 BIOS images which has 4 blobs:
>     CpuSignature: 000806D1h, Revision: 0008h, Date: 30.11.2020
>     CpuSignature: 000806D0h, Revision: 004Eh, Date: 01.12.2020
>     CpuSignature: 000806C1h, Revision: 0072h, Date: 20.11.2020
>     CpuSignature: 000806C2h, Revision: 0002h, Date: 04.12.2020
>
> It seems it have different steppings, so don't know if it really works.
>
> I will try to select INTEL_CAR_NEM with any of these. Thank you for the
> insights.
>
> Best regards,
Selecting INTEL_CAR_NEM did the trick. However, I am facing an issue
with FSP memory training now. TGL UP3 RVP has 2 DIMMs, but the memory
FSP params are set for LPDDR4. Is it intentional?

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: General fan question

[Michal Zygowski]

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 do my day.
> When the coreboot.org wiki was online it was possible to download the
> logo files and see the logo license terms.
>
> That way, you could order some stickers yourself. I don't know if
> that wiki page is still reachable somehow. I couldn't find it on
> coreboot.org. Does anyone know?
>
>
> Thanks
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

[Michal Zygowski]

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 devicetree file.
15.2 is a PCIe root port, so it is natural that there is no init for it,
if the endpoint device isn't detected. There won't be PCIe root port
because AGESA hides it, if endpoint is not detected.
> Another thought - have you compared PCI bus numbers and addresses
> between vendor BIOS and coreboot? They can change around, certainly
> bus numbers but wasn't there a thread a while back with addresses
> being confused too?
This is another thing that can be customized. Each mainboard has an
OemCustomize.c file which defines an array of type
PCIe_PORT_DESCRIPTOR., the 3rd (and 4th on some families) parameter in
PCIE_PORT_DATA_INITIALIZER indicate the device number that will be
assigned to the PCIe engines (lanes). So you can freely route the ports
to device numbers.
> Sorry I can't suggest anything more concrete
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to debug open-source AGESA with serial console?

[Michal Zygowski]

Hi Paul,

I think I got it... It is pretty easy to enable the serial output. Just
define IDSOPT_TRACING_ENABLED to TRUE in
src/mainbaord/MAINBAORDDIR/OptionsIds.h . It will link the coreboot's
printk (debug level 7) to AGESA console. So if you enable serial port in
coreboot's Kconfig it will work 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 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 Purpose Ports lane
>>>> configuration of the FCH.
>>>>
>>>> I’d like to print some variables in
>>>>
>>>>  src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c
>>>>
>>>> over the serial console. It looks like
>>>>
>>>>  #include 
>>>>
>>>> and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent over
>>>> serial console. Is that expected?
>>>>
>>>> Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and enable
>>>> the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`?
>
> I got it once working for apu1 (agesa f14) but it took a lot to fix
> (printf formats, etc.). Yes it is compiled with IDS settings in the
> mainboard directory. I have to look if I have a branch with the code still.
>
>> I don't know if AGESA is compiled into a different stage, which would
>> be called `libagesa`. I've just seen some mentions of this in the
>> coreboot code. I suspect logging there might need to be handled
>> differently (similar to how we handle logging in SMM, which is
>> disabled by default).
>>
>> I'd be surprised if any of the IDS stuff still builds fine. No one
>> bothered to migrate the IDS controls in OptionsIds.h to Kconfig.
>> Should you want to do so, please add various config files in configs/
>> to ensure the IDS code gets build-tested.
>>
>>
> Angel,
>
> The basic IDS which are required to build are fine, but if you enable
> something additional, well... probably you will need to fix few more
> things in vendorcode :) Yes, it is compiled as libagesa, but it doesn't
> make any difference, since it is linked to each stage IIRC. The macros
> AGESA is using to print debug info (IDS_HTD_CONSOLE) is linked to
> coreboot's printk so it ends up in the same console.
>
> I don't think it is necessary to port IDS to Kconfig. i f you include
> config.h in the ids.h in the mainboard and bind the correct defines, it
> should work?
>
> Best regards,
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to debug open-source AGESA with serial console?

[Michal Zygowski]

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 Purpose Ports lane
>>> configuration of the FCH.
>>>
>>> I’d like to print some variables in
>>>
>>>  src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c
>>>
>>> over the serial console. It looks like
>>>
>>>  #include 
>>>
>>> and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent over
>>> serial console. Is that expected?
>>>
>>> Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and enable
>>> the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`?


I got it once working for apu1 (agesa f14) but it took a lot to fix
(printf formats, etc.). Yes it is compiled with IDS settings in the
mainboard directory. I have to look if I have a branch with the code still.

> I don't know if AGESA is compiled into a different stage, which would
> be called `libagesa`. I've just seen some mentions of this in the
> coreboot code. I suspect logging there might need to be handled
> differently (similar to how we handle logging in SMM, which is
> disabled by default).
>
> I'd be surprised if any of the IDS stuff still builds fine. No one
> bothered to migrate the IDS controls in OptionsIds.h to Kconfig.
> Should you want to do so, please add various config files in configs/
> to ensure the IDS code gets build-tested.
>
>
Angel,

The basic IDS which are required to build are fine, but if you enable
something additional, well... probably you will need to fix few more
things in vendorcode :) Yes, it is compiled as libagesa, but it doesn't
make any difference, since it is linked to each stage IIRC. The macros
AGESA is using to print debug info (IDS_HTD_CONSOLE) is linked to
coreboot's printk so it ends up in the same console.

I don't think it is necessary to port IDS to Kconfig. i f you include
config.h in the ids.h in the mainboard and bind the correct defines, it
should work?

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Firmware Descriptor

[Michal Zygowski]

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 may still flash the
coreboot on your laptop, but you have to remember to leave the IFD
region (and ME region too) untouched. If you are using flashrom,
you should pass the "--ifd -i bios" options to the flashrom command when
flashing. It will instruct flashrom to overwrite the BIOS region only in
flash, where coreboot is supposed to be placed.

You may always extract the IFD for the original firmware of your laptop
and include it in your coreboot build. Creating own IFD is not recommended.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 18.09.2020 16:09, Andy Pont wrote:
> 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 flash chip! You can use flashrom's IFD or layout
> parameters to flash only to the BIOS region.
>
> What is an IFD and how do I create one?
>
> -Andy.
>
>
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Optiplex 9010 ACPI bug

[Michal Zygowski]

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 Linux kacpid is constantly using 100% CPU and ACPI
> interrupt is firing at ~10k/s.
>
> My test environment is Optiplex 9010 with i5-3470 with dual channel DDR3
> and an Nvidia GTX1650 installed as DGPU, running Fedora 32.
>
> Coreboot logs and Linux dmesg is attached below. Captured with a build
> of earlier master but still reproducible on the latest master.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Question about PR

[Michal Zygowski]

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`

You don't need any particular rights to push. You have two options to
authorize:

1. SSH key (add SSH key to gerrit account and configure git remote for
SSH or simply clone with SSH like here
https://www.coreboot.org/Git#Accessing_the_repository)
2. HTTP password. If you cloned the repo by HTTP(S) then you should be
asked for password. You can generate it on your gerrit account.

Even if you skip the git config commands, `git push origin
HEAD:refs/for/master` should push your commit(s) you have added on top
of your local master branch to gerrit. They will be public. if you
append %private at the end of the command, it will be private. If you
append %wip it will be marked as work in progress.

Of course we can't see it if it is private. You would have to add
reviewers or people on CC.

Who to add as reviewer? It depends what the patch does. You may suggest
reviewers by looking at MAINTAINERS file in the repo which contains the
people who are more familiar with given part of coreboot source and can
provide good reviews.

How to add reviewer? If your press reply button above the commit message
on gerrit (when displaying your patch) a window will pop up. You may
skip writing any message. Just click in the row with reviewers (where
Add reviewer is written) and start typing. Auto completion should give
you some results. Type by name, nick or email of the reviewer.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 17.09.2020 16:36, bzt wrote:
> Hi,
>
> I'd like to commit a patch to coreboot. I've followed the tutorials on
> https://doc.coreboot.org/tutorial/part2.html
>
> I've set up gerrit account, etc. created a local repo, configured git
> for submit, set up change-id hook, etc. etc. etc. However at step 4a,
> "git push", I got an error message from the server about missing
> "Push" rights and to contact the administrator. How can I do that?
>
> I was able to push the commit as a private patch:
> https://review.coreboot.org/c/coreboot/+/45480
>
> I'm not sure if you can see this url, or is this for my user only.
> I guess now I should add a reviewer, but how and who? Or how can I get
> a "Push" right?
>
> Thanks for your help,
> bzt
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: NVME is not detecting.

[Michal Zygowski]

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
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf" in [FV.DXEFV] section

Yes, the NVMe disk should be detected during PCI enumeration in
coreboot. If it does, that means you lack the above in your UEFI
payload. Otherwise there is something wrong in your coreboot port.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 14.09.2020 17:06, techmindam...@gmail.com wrote:
> Hi Michal,
>
>
> Thanks for your response.
>
> I have verified your Point 1, 2 and 3. Clock is going to NVME device. I have 
> not checked it with Sea Bios as i am using binary UEFI payload.
>
> Is NVME device will get detected as PCI device during PCI enumeration in 
> coreboot?
>
> Regards,
> SenK
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: NVME is not detecting.

[Michal Zygowski]

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 make the
port x4, so you need the Port 9-12 to be enabled.
3. You may also need to check the CLKSRC and CLKREQ signals routing and
configure it correctly in FSP.
4. SeaBIOS should detect the NVMe disk if the above are satisfied.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 9/12/20 3:07 PM, techmindam...@gmail.com wrote:
> I have ported coreboot on Coffeelake architecture. Coreboot is up and during 
> PCI scan M.2 NVME is not detecting in the scan. I have enabled the root port 
> (Port 9) in the device tree and root port is shown in enumeration but not 
> NVME device under it.
>
> Is there any configuration to be done in coreboot to detect NVME.
>
> Regards,
> SenK.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org




signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [coreboot]: Help request with SMSC SCH3114 superio.

[Michal Zygowski]

Dear Jose,

I felt that you are very close to resolving it and it is some minor
issue not exactly in the Super I/O init code.

Great job and good luck with future challenges.

And of course enjoy coreboot!

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 02.09.2020 16:12, Jose Trujillo via coreboot wrote:
> Dear Michal:
>
> Thank you very much for all your guidance.
> The problem was resolved.
>
> The code was OK but was not executed at the right time (was executed before 
> LPC and SIO were initialized).
>
> The attached 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_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, 0x0a43); / GP54= DSR_2 : in /
>>> outb(0x04, 0x0a44); / GP55= RTS_2 : out /
>>> outb(0x05, 0x0a45); / GP56= CTS_2 : in /
>>> outb(0x04, 0x0a46); / GP57= DTR_2 : out */outb(0xaa, 0x2e);
>>> but It doesn't work.
>>> Also I set the same code under mainboard.c -> mainboard_init but
>>> neither work.
>> You should not copy my code for the two major reasons:
>>
>> 1.  SCH5545 and SCH3114 are very different.
>> 2.  GPIO configuration on SCH5545 is not accessible from SuperIO. The
>> code I have written communicates with Environmental Controller (ARC
>> coprocessor) which resides inside the SCH5545, because only the EC had
>> access to those registers. The SCH5545 did not have GPIO config
>> registers in the Runtime Registers block.
>>
>> This will obviously not work.
>>
>>
>>> Any advice on this? because I cannot find any information on the
>>> datasheet on how to set those registers and I suppose I just have to
>>> set to the 0xa00 base address + register.
>> I suggest to look at TABLE 26-3 in the datasheet of your part
>> http://ww1.microchip.com/downloads/en/DeviceDoc/1872A.pdf
>> and using these runtime registers definitions, write the right code that
>> will set the GPIOs up for UARTs.  Just use the appropriate 0xa00 base +
>> REG OFFSET from the table and you should be allright. For simplicity you
>> may also compare these registers to reference values from original
>> firmware (but with care! sometimes firmware vendors tend to make stupid
>> mistakes).
>>
>>> Thank you,
>>> Jose Trujillo.
>> Best regards,
>>
>> 
>>
>> Michał Żygowski
>> Firmware Engineer
>> https://3mdeb.com | @3mdeb_com
>>
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [coreboot]: Help request with SMSC SCH3114 superio.

[Michal Zygowski]

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, 0x0a43); /* GP54= DSR_2 : in */
> outb(0x04, 0x0a44); /* GP55= RTS_2 : out */
> outb(0x05, 0x0a45); /* GP56= CTS_2 : in */
> outb(0x04, 0x0a46); /* GP57= DTR_2 : out */
> outb(0xaa, 0x2e);
>
> but It doesn't work.
>
> Also I set the same code under mainboard.c -> mainboard_init but
> neither work.


You should not copy my code for the two major reasons:

1. SCH5545 and SCH3114 are very different.
2. GPIO configuration on SCH5545 is not accessible from SuperIO. The
code I have written communicates with Environmental Controller (ARC
coprocessor) which resides inside the SCH5545, because only the EC had
access to those registers. The SCH5545 did not have GPIO config
registers in the Runtime Registers block.

This will obviously not work.

>
> Any advice on this? because I cannot find any information on the
> datasheet on how to set those registers and I suppose I just have to
> set to the 0xa00 base address + register.

I suggest to look at TABLE 26-3 in the datasheet of your part
http://ww1.microchip.com/downloads/en/DeviceDoc/1872A.pdf
and using these runtime registers definitions, write the right code that
will set the GPIOs up for UARTs.  Just use the appropriate 0xa00 base +
REG OFFSET from the table and you should be allright. For simplicity you
may also compare these registers to reference values from original
firmware (but with care! sometimes firmware vendors tend to make stupid
mistakes).

>
> Thank you,
> Jose Trujillo.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Help request with SMSC SCH3114 superio.

[Michal Zygowski]

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:
http://ww1.microchip.com/downloads/en/DeviceDoc/1872A.pdf

You may need to configure the GPIOs alternate functions to work as
serial port pins. From what I can see, the defautl configuration is not
set for serial port 3 and 4 for GPIOs: GP10, GP11, GP64 and GP65. At a
minimum, you should configure these to see anything on oscilloscope. I
had similar issue with SCH5545 and had to configure the GPIOs for serial
port as well.

The files you have attached seem to be well written, so I would have a
look at GPIO configuration only.

Good luck.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 24.08.2020 19:29, Jose Trujillo via coreboot wrote:
> Dear coreboot engineers & enthusiasts:
>
> Doing dmesg:
> [X@localhost ~]$ dmesg | grep "tty"
> [    0.336779] printk: console [tty0] enabled
> [    1.521090] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200)
> is a 16550A
> [    1.542192] 00:05: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200)
> is a 16550A
> [    1.563264] 00:08: ttyS2 at I/O 0x3e8 (irq = 5, base_baud = 115200)
> is a 16550A
> [    1.584268] 00:09: ttyS4 at I/O 0x2e0 (irq = 6, base_baud = 115200)
> is a 16550A
>
> The problem I have is that only ttyS0 works (the communication with
> other PC).
>
> Attached files:
> superio.c    Slightly modified to initialize 2 more serial ports from
> 2 to 4.
> devicetree.cb    Shows the forwarding of the I/O ranges for  ttyS2 and
> ttyS4 also the smscsuperio tree with addresses and IRQs.
> superio.asl    The ACPI code.
>
> I suspect is an IRQ issue.
> Using minicom trying to send a byte out there is no signal shown on
> the oscilloscope. 
> I asked (on #coreboot) if is required to route IRQs for the serial
> ports but nico answered "no but you need to tell the OS if the
> interrupt is level or edge" but I don't know how to do that.
> Anybody had experience making this kind of superio to work please give
> me a hint on how to resolve this.
> What additional work do I need to do?
>
> Thank you,
> Jose Trujillo
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How does coreboot support AMD X3421 (Carrizo)?

[Michal Zygowski]

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 about is
that Opteron is a server processor, while the AGESA in coreboot was
designed to work with mobile processor lines (Merlin Falcon - Embedded
R-series). I think the hardware initialization will lack certain things
for server SKU.

AFUWIN will probably expect some AMI format of the BIOS image, so I
suspect it may not work.

Sincerely,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 7/9/20 5:57 PM, Lenny wrote:
> Dear Madam or Sir,
> coreboot is so great!
> I have a HP MicroServer Gen10 with AMD Opteron X3421 (Carrizo) and 
> 16GB ECC memory.
> Will coreboot work well with my hardware platform? Can I update to 
> coreboot with AFUWIN?
> Many thanks!
>
>
> Sincerely,
> Lenny
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

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 cover whole
>>> screen, i.e. when using 1024x768 bootsplash on 1920x1080 screen the
>>> bootsplash covers whole screen,
>> Stretching the graphic e.g. from 4:3 to 16:9 as in your example makes it
>> appear distorted - stretched wide, right? Is that really desirable?
>>
>> If yes, you would have to implement a bitmap scaler in coreboot/libgfxinit.
As Nico mentioned below, it looks like a pillarbox. Imagine GRUB
graphical menu which starts automatically at 800x600 as a tiny box
inside this pillarbox. Even more weird.
Yes it is stretched, but it doesn't look that awful. I am more concerned
about this weird resolution switches. One will have different max
resolution display and everything will fall apart and look differently.
AFAIK libgfxinit reads out the display information (EDID right?) so it
is possible to calculate the scalers. Peter could you elaborate a little
bit more about the bitmap scalers? What would it take to implement that?
> libgfxinit can have the hardware scale the image, but it won't stretch
> it. You can use
>
>   config LINEAR_FRAMEBUFFER_MAX_WIDTH and
>   config LINEAR_FRAMEBUFFER_MAX_HEIGHT
>
> to reduce the framebuffer resolution, then the image would be scaled to
> fit in height, but with a pillarbox.
Indeed this is what I have currently. I have limited the resolution with
these options to fit the bootsplash.

Libgfxinit is very cool when one has a built-in display like in a
laptop,  then the max resolution may be the same all the time. However
for desktops the user experience for desktops with varying display
types, it is not that beautiful. Personally I don't care that much about
it, because I can always rebuild the coreboot, set the framebuffer
resolution I need for my display and set GRUB gfx resolution to match my
display. However, the problem occurs when I would like to offer more
open silicon initialization by getting rid of closed VGA option rom. Of
course I also would like to preserve the user experience I had
previously (or even better).

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com




signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

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 suggestions on that? I think my next step would be to trace all INT
>>>> 10h and compare the differences and fix it possibly in SeaVGABIOS.
>>> Not sure what you are up to. Libgfxinit sets a specific mode. After that
>>> is set, SeaVGABIOS can't change it, only report the mode info. And if
>>> SeaBIOS' JPEG parser ignores the info, it doesn't matter what SeaVGABIOS
>>> reports.
>> Okay, I see. How do I know which mode is set by libgfxinit?
> The resolution will be picked according to the attached monitors
> (either native resolution or lower if another monitor has lower
> resolution). The color format is currently hardcoded: 32-bit BGRX,
> or in terms of coreboot's `struct lb_framebuffer`:
>
> bits_per_pixel   => 32,
> reserved_mask_pos=> 24,
> reserved_mask_size   =>  8,
> red_mask_pos => 16,
> red_mask_size=>  8,
> green_mask_pos   =>  8,
> green_mask_size  =>  8,
> blue_mask_pos=>  0,
> blue_mask_size   =>  8);
>
> Nico

Thank you. It looks like I can't use JPG bootsplash with libgfxinit,
because it requires 16bpp mode (according to SeaBIOS logs). A workaround
I have found is to convert it to BMP, then it uses 32bpp and everything
is allright.

But for example, when VGA option rom is used, SeaBIOS finds the mode it
fits the bootsplash resolution and bpp. Additionaly the display area is
adjusted to cover whole screen, i.e. when using 1024x768 bootsplash on
1920x1080 screen the bootsplash covers whole screen, while in libgfxinit
it is centered leaving unused bars on the both sides of the screen. Any
ideas how to improve that?

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com




signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

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 the bootsplash incorrectly (the same color issues as with
>> libgfxinit) while SeaBIOS displayed it with the expected colors.
> are you 100% sure that it's the same mode? AIUI, SeaBIOS would automati-
> cally pick one at runtime, should be visible in the log which.
I have set VESA mode 1024x768 16.8M-color (8:8:8) in coreboot when using
option ROM (the same resolution and colors as my bootsplash).
It seems that SeaBIOS picks different mode then... I will check with the
debug output as you suggest.
>
>> 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 suggestions on that? I think my next step would be to trace all INT
>> 10h and compare the differences and fix it possibly in SeaVGABIOS.
> Not sure what you are up to. Libgfxinit sets a specific mode. After that
> is set, SeaVGABIOS can't change it, only report the mode info. And if
> SeaBIOS' JPEG parser ignores the info, it doesn't matter what SeaVGABIOS
> reports.
Okay, I see. How do I know which mode is set by libgfxinit?
>
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

Hi Nico,

I found some time to get back to the topic and actually I am clueless...

What I have tried:

1. Use libgfxinit to initialize graphics in coreboot and display the
bootsplash image in JPG and BMP formats. JPG has the mentioned issue
with colors, while BMP doesn't.
2. Compared the libgfxinit provided framebuffer with the one provided by
VGA option rom and they are identical. Despite that the JPG bootsplash
is displayed differently in coreboot.
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 the bootsplash incorrectly (the same color issues as with
libgfxinit) while SeaBIOS displayed it with the expected colors.

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 suggestions 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 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 tried this) PLANE_CTL bit
>> 20 seems to do the trick. For older generations, 0xe << 26 instead of
>> 0x6 << 26 in PRI_CTL.
>>
>>> I have used SeaBIOS with the same bootsplash image. AFAIK it searches
>>> for a compatible (for given image resolution) VESA mode and displays the
>>> boot splash. The image was a JPG 1024x768 pixels (32bpp I guess).
>> Looks like SeaBIOS hard-codes the RGB encoding deep in the jpeg decoder.
>> The macro PIC_32() in `src/jpeg.c`. Would be better to take the frame-
>> buffer format into account there.
> If the framebuffer holds information about the decoding, I think this
> will be better way of handling the issue. At this point it will be quite
> trivial. IIRC coreboot has the same problem with its jpeg decoder,
> noticed same color pattern BGR. Thanks again.
>
> Michał
>> Nico
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org



signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to delete another me?

[Michal Zygowski]

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 zheng@amd.com
>  to my gerrit account. But it says it is
> used by another account.
>
> I am pretty sure that is because I tried to use this mail address to
> create an account, but can not login by authorization.
>
> I have forgot the account name and other information.
>
>  
>
> Is there any way to find out that account and delete it? Thanks.
>
>  
>
> Zheng
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Need help with getting KGPE-D16 working.

[Michal Zygowski]

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 some tuning of libpayload config, for
example to increase stack size and heap size (noticed issues with USB
when the stack or heap was too small).

3. The graphics is exposed by BMC ASPEED AST2050, it should allow to use
display. The problems may occur when GRUb is switching display mode or
something. The kernel booting problems may be related to memory training
problem.

4. If you have a discrete GPU, you may include its VGA option ROM into
CBFS using correct naming, SeaBIOS should execute it and provide
graphics output. There is also an option in Kconfig "Onboard VGA is
prmiary", try to deselect it when using discrete GPU.

5. If you do not have BMC running, the fans will keep running at full
speed IIRC. BMC was responsible for fan control. In order to utilize BMC
one needs the BMC flash chip module. The fans are spinning up to max
speed during hardware enumeration in ramstage, probably during Super IO
intialization and BMC initialization. I am not yet familiar with this
board. However maybe if you look into Winbond chip drivers used on KGPE
you may find some settings to tweak the speed, I am not sure.

The only RAM HCL I found are:

https://www.coreboot.org/Board:asus/kgpe-d16#RAM_HCL

https://libreboot.org/docs/hardware/kgpe-d16.html#memory-compatibility-with-libreboot

https://www.raptorengineering.com/coreboot/kgpe-d16-status.php

I would gladly help to resolve those issues, but we lack resources to do
it "pro publico bono". 3mdeb is trying to change it together with
Insurgo Technologies Libres, we are gathering funds for the development
and revivial of this platform:
https://github.com/osresearch/heads/issues/719

Regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 5/9/20 5:33 AM, ragna...@tenebr.is wrote:
> Recently I'm finally able to get a KGPE-D16 coreboot environment that could 
> always boot, although there are a lot of issues and questions. I'm currently 
> using the 4.11 branch as this board has been dropped in the master branch.
>
> The main issue is memory. It seems there are still issues with memory 
> initialization. The Samsung 16GB sticks I currently have (normal or VLP) do 
> not work when using all orange slots, ending in a bootloop due to DIMM 
> training failure (which is the same error I had when I was trying coreboot on 
> KCMA-D8). However, on KGPE-D16, by installing the 8 sticks to the following 
> slots: D1/D2, B1/B2, E1/E2 and G1/G2, I could always get it past the memory 
> initialization, albeit with this error:
>
> "TrainDQSRdWrPos: negative DQS recovery delay detected! Attempting to 
> continue but your system may be unstable..."
>
> This is currently the only combination that could always boot (and with all 
> 128GB recognized). Other combinations I tested either resulted in some 
> "HARDWARE FAULT: HT_EVENT_HW_SYNCHFLOOD" errors which would soft reset before 
> even reaching the DIMM training part, or it entered the DIMM training part 
> but would never complete.
>
> However, the system is currently not at a point that could properly boot to a 
> system (or even a payload) yet. As of yesterday, the only thing I could boot 
> and steadily function is a Menuet64 floppy image.
>
> 1. I'm using SeaBIOS master, and have put several floppy images into the 
> CBFS, but it seems to only list the last floppy image I added as a boot 
> option (Ramdisk). It appears multiple floppy images is not officially 
> supported in master yet and I've just located the patch regarding this. I'm 
> still new to SeaBIOS so I'm not sure how to modify configuration/bootorder 
> later on, as I currently don't have a configuration/bootorder file supplied 
> and let it use default values.
>
> 2. None of the secondary payloads work. nvramcui hangs with something like 
> "unable to init curs" (I only tried it once and couldn't remember what 
> exactly it is). coreinfo and tint hangs with this "Not enough memory creating 
> EHCI periodic frame list." error. memtest could load, but when it starts 
> testing, it hangs with a glitched screen of blinking characters, among which 
> something like "d h l p t x" could be seen. This also happened when using 
> memtest that comes with the Manjaro Linux boot USB.
>
> 3. Initially I had issues with graphical bootloaders like grub, but after 
> disabling bootsplash image as well as not building the seavgabios.bin (by 
> unchecking the "Include generated option rom that implements legacy VGA BIOS 
> compatibility"), I could get Manjaro's graphical grub to load, but still 
> cannot boot to the kernel (XZ-Compressed Data is corrupt). Maybe this is due 
> to memory, as I think the combination I previously mentioned only guaranteed 
> it to go past 

[coreboot] Re: beginner's despair ;) coreboot update via internal fails

[Michal Zygowski]

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 verify only the region I told you to flash", so it basically
reprograms BIOS region for example, and then verifies only BIOS region
against the binary.

Regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 07.05.2020 17:00, JPT wrote:
> Solved it already.
> added --noverify-all
> this sounds dangerous but it just doesn't verify the areas it did't
> write. o.O
>
> Am 07.05.20 um 16:43 schrieb JPT:
>> Hi,
>>
>> I want to contribute to the board status database.
>> For this I did a build from 4.11 branch.
>>
>> This is flashing from the OS for the first time.
>>
>> the SPI command I used was:
>> ./flashrom/flashrom -p ch341a_spi -l
>> firmware/orig/X220/x220-orig.bin.layout -i bios -w
>> coreboot/build/coreboot.rom -c
>> MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F
>>
>> For internal flash I modified this command to this:
>> sudo ./flashrom/flashrom -p internal:boardmismatch=force -l
>> firmware/orig/X220/x220-orig.bin.layout -i bios -w
>> coreboot/build/coreboot.rom -c
>> MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F
>>
>> But it doesn't work. What am I doing wrong?
>>
>> thanks
>>
>> JPT
>>
>> flashrom v1.1-rc1-125-g728062f on Linux 5.4.0-29-generic (x86_64)
>> flashrom is free software, get the source code at https://flashrom.org
>>
>> Using region: "bios".
>> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
>> coreboot table found at 0xbff6a000.
>> Found chipset "Intel QM67".
>> Enabling flash write... SPI Configuration is locked down.
>> FREG0: Flash Descriptor region (0x-0x0fff) is read-only.
>> FREG2: Management Engine region (0x3000-0x004f) is locked.
>> Not all flash regions are freely accessible by flashrom. This is most likely
>> due to an active ME. Please see https://flashrom.org/ME for details.
>> At least some flash regions are read protected. You have to use a flash
>> layout and include only accessible regions. For write operations, you'll
>> additionally need the --noverify-all switch. See manpage for more details.
>> OK.
>> Found Macronix flash chip
>> "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI)
>> mapped at physical address 0xff80.
>> This coreboot image (LENOVO:ThinkPad X220) does not appear to
>> be correct for the detected mainboard (X220:ThinkPad X220).
>> Proceeding anyway because user forced us to.
>> Reading old flash chip contents... Transaction error!
>> FAILED.
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] PCIe hotplug support with Intel FSP 2.0

[Michal Zygowski]

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 be an ACPI code or SMI handler to train the link
when the device is detected in the slot if I am not mistaken.

Anyone with PCIe hotplug experience could advise and clarify my doubts?

Thanks in advance.

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com




signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] USE_BLOBS vs AMD platforms

[Michal Zygowski]

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 building blobless images. Currently there is no
unified policy how coreboot build system should behave when building
with blobs or not. There are numerous mainbaords that require blobs in
order to obtain bootable image: FSP, AGESA, MICROCODE, PSP FW. Some of
them can be built without blobs with a warning at the end of build
process that crucial silicon initialization blobs are missing (example:
amd/gardenia), however this behavior is not consistent across whole
coreboot tree. There is already very few boards that do not require any
blobs in buld process to obtain bootable image.
2. People building coreboot may think that they are building fully open
image, but for x86 architecture in particular, it is impossible
currently, unless we make some steps to avoid it (which I will describe
below). On the second hand, if a new-to-coreboot person build an image
that is not bootable, he may be discouraged to use coreboot if his
device will be bricked. So a conclusion from the leadrship meeting is to
have USE_BLOBS enabled by default (however not selected) in order to
keep the usability of the built images.

I encourage to refer to the meeting minutes from coreboot leadership
meeting:
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#heading=h.wgnywbfqkvkj

tl;dr;
In the light of above matters I came up with an idea to build coreboot
for AMD based boards without blobs by using flashmap. The main goal is
to build a coreboot image purely from source code and update only parts
of the firmware that contain BIOS code. A mechanism similar to Intel's
flash descriptor and bios region, however not present on AMD firmware
layout. My idea is intended to be a close equivalent to the Intel's
flash descriptor. Example basic layout for AMD firmware could look like
this:

FLASH $(CONFIG_ROM_SIZE) {
    PSPFW(PRESERVE) 0x10
    COREBOOT(CBFS)
    AGESA(PRESERVE)@$(AGESA_BINARY_PI_LOCATION) 0xa
    UNUSED
    BOOTBLOCK 0x1
}

- PSPFW should contain AMD PSP firmware which lies at fixed offsets of
the SPI flash (typically is put at offset of 0x2 of the beginning of
the flash). In order to utilize the FMAP with PSP firmware one can use
AMDFW_OUTSIDE_CBFS which will `dd` the whole PSP firmware to the
coreboot image at offset 0x2. The preceding 128KiB (offsets 0x0 -
0x2) may be either sacrificed as unused or used for other purposes
(CONSOLE, SMMSTORE, VPD etc.). According to my knowledge the whole PSP
firmware is less than 1MB for family 16h and earlier, however with
"dual" PSP directory it may consume more. For family 17h and later it
also may be insufficient, but one can always adjust it for families that
need it.
- AGESA is typically a blob that must be placed at fixed offset defined
at blob build time (except open-surce AGESA). AGESA does not have any
rebase mechanism as FSP 2.0 and later have, thus a separate FMAP region
is added for the blob. Assumed 640K but may be adjusted if needed. The
interface to the binary will have to be adjusted to use FMAP to locate
it (or a Kconfig option could be used to do switch between FMAP and CBFS).
- bootblock is always placed at the bottom of SPI flash (excpet family
17h which can define the reset vector entry point to be elsewhere than
0xFFF0) so another region has been added for the entire bootblock.
Default size for the x86 bootblock is 64K.
- UNUSED is a gap between AGESA blob and the bootblock which may be used
for other purposes (CONSOLE, SMMSTORE, VPD etc.)
- the rest of the space will be occupied by coreboot CBFS

The main advantage is that if one flashes the full image with blobs
once, each next update can be built without them. Flashrom with FMAP
support would allow to flash only COREBOOT and BOOTBLOCK regions without
touching blobs. Of course appropriate warnings should be printed at the
end of build process that no blobs have been used and one must ensure
these are already present on the SPI flash. This way coreboot can be
built purely from source, since microcode is embedded into AGESA binary.
Also the situation when blobs have been enabled an waring may be
printed, that coreboot used blobs to build the image. These warnings
should be consistent for all boards that use blobs (although there may
be exceptions, for ARM I guess?).

I assume there will be many questions and I haven't covered everything
with my idea, so any suggestions and feedback are welcome.

Regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com




signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@corebo

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

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 tried this) PLANE_CTL bit
> 20 seems to do the trick. For older generations, 0xe << 26 instead of
> 0x6 << 26 in PRI_CTL.
>
>> I have used SeaBIOS with the same bootsplash image. AFAIK it searches
>> for a compatible (for given image resolution) VESA mode and displays the
>> boot splash. The image was a JPG 1024x768 pixels (32bpp I guess).
> Looks like SeaBIOS hard-codes the RGB encoding deep in the jpeg decoder.
> The macro PIC_32() in `src/jpeg.c`. Would be better to take the frame-
> buffer format into account there.
If the framebuffer holds information about the decoding, I think this
will be better way of handling the issue. At this point it will be quite
trivial. IIRC coreboot has the same problem with its jpeg decoder,
noticed same color pattern BGR. Thanks again.

Michał
>
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

Thanks for pointers Nico.

I used the same picture laoding code and the same image. The only thing
that changed was the graphics initialization: VGA ROM vs libgfxinit.

I have used SeaBIOS with the same bootsplash image. AFAIK it searches
for a compatible (for given image resolution) VESA mode 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, however after
>> enabling it on a Kaby Lake platform I noticed the colors are flipped.
>> I.e. when using VGA ROM the bootsplash image is correctly displayed in
>> RGB, but when using libgfxinit and hires FB the colors are BGR (the same
>> image is not displayed in same way). Do you possibly know what may the
>> cause?
> all I know is that with libgfxinit, so far you get the exact same pixel
> encoding for every platform (where I tested colors). I think it's BGRX.
>
> What mode do you set with the VGA ROM? In the end it should be reported
> in a `struct lb_framebuffer` so you could compare the two encodings.
> Also, the code that loads the picture should write the pixels according
> to the reported format. Unless somebody took too many shortcuts.
>
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

Another question about libgfxinit.

Up till Skylake the libgfxinit worked great for me, however after
enabling it on a Kaby Lake platform I noticed the colors are flipped.
I.e. when using VGA ROM the bootsplash image is correctly displayed in
RGB, but when using libgfxinit and hires FB the colors 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
>> better situation? I have Braswell EDS so i can check it, but if you have
>> any documents that describe display registers for Braswell, let me know
>> which ID it is so I can get it myself.
> the EDS looks the same to me as the public datasheet. Intel seems to
> have a separate document system for the graphics stuff. I never got
> access there. Though, stopped asking a few years ago, so maybe there
> is a chance. But you'd have to poke Intel directly about it, I guess.
>
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgfxinit quick starter guide

[Michal Zygowski]

Hi Nico,

Thank you for your extensive answer. That helps a lot.

Regarding the registers description, maybe EDS or other documents have
better situation? I have Braswell EDS so i can check it, but if you have
any documents that describe display registers for Braswell, let me know
which ID 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:
>>> I see the programming manuals from Intel
>>>> are in place:
>>>> https://01.org/linuxgraphics/documentation/hardware-specification-prms
>> Alas, this is a pitfall for Braswell. The only part that matters for
>> libgfxinit (information about the display engine) is 100% scrubbed
>> away. If you look into the `Display` chapter, it only contains legacy
>> VGA registers and audio verbs, nothing about display at all. And if you
>> search for any of "hdmi", "lvds", "mipi", "dsi", or "lane" in the
>> `Register` chapter: nothing :-/
> Update: There are some register descriptions in the Braswell datasheet
> vol2. Probably enough for HDMI and (e)DP support.
>
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: About support for my netbook

[Michal Zygowski]

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 ivybridge works, pineview and cedarview
should have most thing in common. That said, i would try to go out from
pineview northbridge in coreboot. The next question is which southbirdge
to choose. There are two mainboards based on pineview. Most likely you
would have to select:

    select CPU_INTEL_SOCKET_FCBGA559
    select NORTHBRIDGE_INTEL_PINEVIEW
    select SOUTHBRIDGE_INTEL_I82801GX

in your mainboard Kconfig. The CPU socket also matches according to
Intel ARK about N2600

https://ark.intel.com/content/www/us/en/ark/products/58916/intel-atom-processor-n2600-1m-cache-1-6-ghz.html

The initialization for that particular silicon is native so no FSP
required. Since it may be hard to debug, I advise to get a USB debug
dongle and enable it in coreboot menuconfig. But before that, find out
which USB port on this netbook is connected to EHCI debug port.
Typically it is the first port on the root hub. You can find it out
using lspci and lsusb in Linux (by connecting a USB-UART dongle for
example to the investigated port). The dongles supported by coreboot
are: FTDI232H/FTDI2232H, or you can use BeagleBone board.

Regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 12.03.2020 06:06, Benjamin Doron wrote:
> Hi,
> The Intel FSP (Firmware Support Package) is a required part of chipset 
> initialisation. I can't find one for Cedar View, (github.com/IntelFsp/FSP) 
> the family your CPU, an Atom N2600, is a part of.
>
> Somebody else should confirm (I don't know your platform well), but it seems 
> impossible about this. Sorry.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] libgfxinit quick starter guide

[Michal Zygowski]

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/linuxgraphics/documentation/hardware-specification-prms

What do I need to implement a new microarchitecture in libgfxinit? Where
to start and what should I focus on?

tl;dr;
Haven't written anything in SPARK/Ada yet. It will be a new adventure
for me.

Regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Initial mainboard commit - minimal requirements and completion criteria

[Michal Zygowski]

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, Michal Zygowski wrote:
>> I am glad to see Protectli FW2B/FW4B boards on master branch.
>>
>> Big thanks to: Paul Menzel, Angel Pons, Matt DeVillier and Frans
>> Hendriks (random order, not prioritizing anyone) for your time and
>> reviews. I am really grateful.
> Many thanks for your contribution.
>
> Best Regards,
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Initial mainboard commit - minimal requirements and completion criteria

[Michal Zygowski]

I am glad to see Protectli FW2B/FW4B boards on master branch.

Big thanks to: Paul Menzel, Angel Pons, Matt DeVillier and Frans
Hendriks (random order, not prioritizing anyone) for your time and
reviews. I am really grateful.

And two more still to go:
https://review.coreboot.org/c/coreboot/+/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
>> will receive an entry in MAINTAINERS file. I would very appreciate a
>> little bit of your attention on them and possibly reviews.
>>
>> I especially need the Kaby Lake board, because 3mdeb will soon begin
>> upstreaming changes to support Boot Guard and Protectli FW6 is our
>> reference platform. I don't want the mainboard patches to be a burden or
>> blocking any related efforts. So I kindly ask for a tiny bit of your
>> time to have a look at these patches. Let's improve coreboot together
>> and make it a competitive (and even better) replacement of proprietary
>> BIOS solutions.
> Thank you for this email.
>
> As the owner of 3mdeb, I would like to add $0.02. We are a small
> organization, but we have no problem to use part of our profit, for
> engineers to review code and support other community members (also those
> commercial ones). New customers often ask about our effectiveness in
> community, the number of maintained boards and the amount of code we
> have contributed. If the community keeps our reviews not merged, we
> cannot use that as proof of our engagement and quality. We always try to
> convince customers to support the upstreaming process and secure budget
> for that, but in light of no interest in merging code, customers would
> rather avoid that cost and keep forks on their repositories. This
> doesn't contribute to project health.
>
> Some of our patches got no attention for over 1.5 years.
>
> As coreboot leader, Michal can give +2, but we were hesitant to be the
> judge in our case and use that to merge our code.
> What we are asking is a decision about those patches - if anything is
> wrong we will fix that.
>
> We believe this is a little bit bigger problem that should be addressed
> by coreboot leaders since it reflects the healthiness of the community
> and agenda of participating entities.
>
> Best Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: x11ssm-f usb3.0 boot issues

[Michal Zygowski]

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/usb-debugging.md#seabios-debug-output

For some platforms SeaBIOS will work perfectly all the time, for some
you have to adjust timeouts for almost each different stick... It must
be noted that SeaBIOS has very basic implementation of threads. USB
devices are also initialized in threaded manner. Because of that it may
introduce another timing issues. And as you already pointed, usb 2.0
ports are much more error proof.

Different stick may also behave in a different way, cause different
errors. Some of them respond to commands earlier, some of them later.

If you really need to reliably boot from USB, use USB 2.0 port or change
the stick model. That's my few months long experience with USB 3.0
sticks in SeaBIOS.

Regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 09.03.2020 14:25, Valentin wrote:
> Hello,
>
> I've built coreboot with seabios for the Supermicro X11SSM-F
> motherboard and i'd like to use the internal usb3.0 port with a usb
> stick as a boot device.
>
> If power on the board and do a cold boot the usb works just fine, but
> if i reboot the system or use the reset button the usb is not
> recognized in seabios.
>
> If i use a usb2 port instead there are no issues at all.
>
> I can't figure out the reason for this... has anyone an idea on how to
> fix this issue or experienced this before?
>
> i attached the complete console debug output from a cold and warm boot
> as well as the config file, any help is appreciated.
>
> Thanks,
> Valentin
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Initial mainboard commit - minimal requirements and completion criteria

[Michal Zygowski]

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-7720bf7ed3f447a878a3c0e2fdd0c956e7430c08

I have rebased it, added Documentation entry, however nobody touched it
since I lastly updated it in November.

Following the same convention I have updated a Protectli FW6 Kaby Lake
board patch today:
https://review.coreboot.org/c/coreboot/+/33839/

Probably this week I will also update another mainboard patch with
documentation: https://review.coreboot.org/c/coreboot/+/32076

Are there any exit criteria which initial mainboard commit should fulfil
to be considered good quality and complete? I have also added changes to
MAINTAINERS file (for the FW6) to indicate that these patches will not
become a piece of unused and unmaintained code.

The first two patches are solid and all issues documented. All of them
will receive an entry in MAINTAINERS file. I would very appreciate a
little bit of your attention on them and possibly reviews.

I especially need the Kaby Lake board, because 3mdeb will soon begin
upstreaming changes to support Boot Guard and Protectli FW6 is our
reference platform. I don't want the mainboard patches to be a burden or
blocking any related efforts. So I kindly ask for a tiny bit of your
time to have a look at these patches. Let's improve coreboot together
and make it a competitive (and even better) replacement of proprietary
BIOS solutions.

With kind regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Help for porting corevoot to an unsupported device

[Michal Zygowski]

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 02.03.2020 14:19, Alif Ilhan wrote:
> Hello!I want to port coreboot to my netbook hp mini 110-4100.For now I
> can tell the cpu is atom n2600 which I want to unlock in the bios but
> I can't because the bios locks it.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Debugging undetected SATA disk?

[Michal Zygowski]

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 Registers:
> =
> Clock Source Select
> SRC Source Select
> PLL Reference Clock Select
> Divider Enable
>
> ICC Registers:
> =
> Flex Clock Source Select
> Output Clock Enable
> PI12BiasParms
>
> I need to do more research to find out what all this means, but in theory, if 
> I update the new ME with same values as the old one, then I should have a 
> working SATA disk?
Theoretically yes. But practically cannot guarantee that (it is
hardware). However, the chances are very high. I recently had an issue
with mismatched ICC configuration which caused 1 of 6 Gigabit Ethernet
Controllers to be disabled. Fixed by applying identical ICC
configuration to the new ME image.
>
>
> Regards,
> Mogens Jensen
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Debugging undetected SATA disk?

[Michal Zygowski]

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 right" ME FW udpate
procedure implemented, which uses the ME interface to perform the
update. I suspect that update is omitting the mainboard specific
configuration. I would advise to perform the vendor BIOS update process
as usually typical user does it, then dump the image and extract the ME
blob. Try this way out and see if it helps.

Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

On 12.02.2020 02:30, Mogens Jensen via coreboot wrote:
> I have installed coreboot on my CompuLab Intense PC (Ivy Bridge). Intel ME 
> blob was extracted from firmware image dump. This ME version (8.1.20.1336) 
> contains multiple security vulnerabilites, so I have downloaded latest 
> firmware update from vendor website extracted the ME (8.1.72.3002) and used 
> that to build coreboot. However, after flashing updated rom, the SATA disk is 
> no longer detected.
>
> The coreboot configuration is identical for both roms, only difference is the 
> ME version. The SATA controller is detected in both cases by coreboot and 
> Linux:
>
> SATA: Initializing...
> SATA: Controller in AHCI mode.
>
> 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port 
> SATA Controller [AHCI mode] (rev 04)
>
> With newer ME, there are no errors, it's just like the SATA disk is not 
> plugged in.
>
> I have compared output of cbmem, line by line in cronological order, from 
> system booted by USB disk with working and non working SATA, cut out blocks 
> with differences and marked them with a *. I don't know if this is a good 
> way, please let me know if I should have done otherwise.
>
> SATA disk working:
> =
> Update PCI-E configuration space:
> PCI(0, 0, 0)[a0] = 0
> PCI(0, 0, 0)[a4] = 2 *
> PCI(0, 0, 0)[bc] = 82a0
> PCI(0, 0, 0)[a8] = 7b60
> PCI(0, 0, 0)[ac] = 2 *
> PCI(0, 0, 0)[b8] = 8000
> PCI(0, 0, 0)[b0] = 80a0
> PCI(0, 0, 0)[b4] = 8080
> PCI(0, 0, 0)[7c] = 7f
> PCI(0, 0, 0)[70] = fe00
> PCI(0, 0, 0)[74] = 1 *
> PCI(0, 0, 0)[78] = fe000c00
> =
> SATA disk NOT working:
> =
> Update PCI-E configuration space:
> PCI(0, 0, 0)[a0] = 0
> PCI(0, 0, 0)[a4] = 4 *
> PCI(0, 0, 0)[bc] = 82a0
> PCI(0, 0, 0)[a8] = 7b60
> PCI(0, 0, 0)[ac] = 4 *
> PCI(0, 0, 0)[b8] = 8000
> PCI(0, 0, 0)[b0] = 80a0
> PCI(0, 0, 0)[b4] = 8080
> PCI(0, 0, 0)[7c] = 7f
> PCI(0, 0, 0)[70] = fe00
> PCI(0, 0, 0)[74] = 3 *
> PCI(0, 0, 0)[78] = fe000c00
> =
>
> SATA disk working:
> =
> ME: FWS2: 0x161f012a *
> ME:  Bist in progress: 0x0
> ME:  ICC Status  : 0x1 *
> ME:  Invoke MEBx : 0x1
> ME:  CPU replaced: 0x0
> =
> SATA disk NOT working:
> =
> ME: FWS2: 0x161f012e *
> ME:  Bist in progress: 0x0
> ME:  ICC Status  : 0x3 *
> ME:  Invoke MEBx : 0x1
> ME:  CPU replaced: 0x0
> =
>
> SATA disk working:
> =
> PASSED! Tell ME that DRAM is ready
> ME: FWS2: 0x1650012e *
> ME:  Bist in progress: 0x0
> ME:  ICC Status  : 0x3 *
> ME:  Invoke MEBx : 0x1
> ME:  CPU replaced: 0x0
> =
> SATA disk NOT working:
> =
> PASSED! Tell ME that DRAM is ready
> ME: FWS2: 0x1650012a *
> ME:  Bist in progress: 0x0
> ME:  ICC Status  : 0x1 *
> ME:  Invoke MEBx : 0x1
> ME:  CPU replaced: 0x0
> =
>
> SATA disk working:
> =
> memcfg channel assignment: A: 1, B  0, C  2 *
> memcfg channel[0] config (): *
>ECC inactive
>enhanced interleave mode off *
>rank interleave off *
>DIMMA 0 MB width x8 single rank, selected *
>DIMMB 0 MB width x8 single rank
> =
> SATA disk NOT working:
> =
> memcfg channel assignment: A: 0, B  1, C  2 *
> memcfg channel[0] config (00620020): *
>ECC inactive
>enhanced interleave mode on *
>rank interleave on *
>DIMMA 8192 MB width x8 dual rank, selected *
>DIMMB 0 MB width x8 single rank
> =
>
> SATA disk working:
> =
> PCH: Remap PCIe function 4 to 3
> PCI: 00:1c.4 [8086/1e18] enabled
> PCI: 00:1c.5: Disabling device
> PCI: 00:1c.6: Disabling device
> PCI: 00:1c.6 [8086/1e1c] disabled *
> PCI: 00:1c.7: Disabling device
> =
> SATA disk NOT working:
> =
> PCH: Remap PCIe function 4 to 3
> PCI: 00:1c.4 [8086/1e18] enabled
> PCI: 00:1c.5: Disabling device
> PCI: 00:1c.6: Disabling device
>

[coreboot] Re: Asrock e350m1: sata disks not recognized

[Michal Zygowski]

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 narrowed it down to the commit
> 94c47c0 [https://review.coreboot.org/c/coreboot/+/37703], it's the
> first commit that shows this problem.
> It seems to me that the rrot cause is that since this commit
> sb_Poweron_Init() for the sb800 isn't called anywhere, but I'm not
> sure about the right way to include it.
> Could anyone help with that?
>
sb_Poweron_Init is called in platform_BeforeInitReset in agesa family 14
state machine. Also by looking at latest board status, the SATA was working:
https://review.coreboot.org/cgit/board-status.git/tree/asrock/e350m1/4.11-903-g941c9ac074/2020-01-15T18_54_40Z/coreboot_console.txt

Line 1180:

|AHCI/0: Set transfer mode to UDMA-6 Searching bios-geometry for:
/pci@i0cf8/*@11/drive@0/disk@0 AHCI/0: registering: "AHCI/0: SanDisk
SDSSDP064G ATA-9 Hard-Disk (61057 MiBytes)"|

Don't know exactly what could cause it. I would try to build with the
same config and repo revision as in the board status.


> Thanks,
> Valentin
Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFT] Linux fails to detect devices on AGESA board with `nosmp`

[Michal Zygowski]

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 use it, the "noacpi" path wasn't thoroughly validated.

I will start working on it soon (most likely together with Kyösti), so
the situation should improve a little bit.

Regards,
Michał

On 28.01.2020 11:33, Sergej Ivanov wrote:
> Hello,
>
> adding nosmp pci=noacpi results in same behaviour - linux can't assign
> irq to usb&sata controllers(but I don't see IRQ >15 anymore). Adding
> nosmp pci=biosirq,noacpi allow system to boot.
>
> сб, 25 янв. 2020 г. в 03:14, Kyösti Mälkki  >:
>
> On Thu, Jan 16, 2020 at 5:21 PM awokd via coreboot
> mailto:coreboot@coreboot.org>> wrote:
> >
> > Sergej Ivanov:
> > > I can reproduce this bug on Biostar AM1ML. I think this bug is
> ACPI
> > > related, if i add 'nosmp acpi=off' Ubuntu boots fine.
>
> Hi
>
> Parameter 'nosmp' disables I/O APIC and enforces PIC IRQ routing. How
> about 'nosmp pci=noacpi', it's less intrusive than using 'acpi=off'.
>
> It is somewhat well-known that AGESA boards' IRQ routing is a one sick
> puppy [1] [2]. Or perhaps the entire litter, pun intended.
>
> [1] https://review.coreboot.org/c/coreboot/+/38262
> [2] https://review.coreboot.org/c/coreboot/+/38313
>
> Kyösti
> ___
> coreboot mailing list -- coreboot@coreboot.org
> 
> To unsubscribe send an email to coreboot-le...@coreboot.org
> 
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How can My linux kernel detect gpio or pinctrl on denverton platform ?

[Michal Zygowski]

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,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

On 15.01.2020 15:13, cooljason0...@gmail.com wrote:
> 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
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Boot Guard availability on Kaby Lake

[Michal Zygowski]

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 platform to one of these processors, would it work?

Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [fam16h AM1I-A] ehci-pci: can't derive routing for PCI INT B. USB 3.0 doesn't work even as USB 2.0

[Michal Zygowski]

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.

I also wonder why the boards are not using intel_irq_routing_table that
describe the devices and their corresponding IRQs instead.

Regards,
Michał

On 08.01.2020 12:16, Mike Banon wrote:
>> I think something is messed up with those USB ports on G505s too,
>> because I have to use irqpoll on them in Qubes. I have the BKDG for AMD
>> 15h. Where can I find the appropriate IRQ routings for the G505s's chipset?
> Build a coreboot for G505S with CONFIG_DEBUG_PIRQ and see the
> warning/error messages. To me, it seems that - to fix the interrupts -
> first of all we need to convert the stuff like irq_tables.c from a
> G505S "legacy style" ( i.e. pirq_info function ) to AM1I-A "new style"
> ( i.e. intel_irq_routing_table structure ). On another fam15h board
> (A88XM-E) and most likely on G505S too, if CONFIG_DEBUG_PIRQ is
> enabled, this "legacy style" code is giving bad warning like "Can't
> write PCI IRQ assignments because mainboard_pirq_data structure does
> not exist" and i.e. KolibriOS can't see the interrupt numbers at all.
> While, on fam16h AM1I-A board, "new style" code seems to work fine -
> "Finished writing PCI config space IRQ assignments" - and KolibriOS
> sees the interrupt numbers OK. Maybe using KolibriOS as an indicator
> seems irrelevant, however to me its' a sign that "new style" code for
> interrupt routing is better quality, and maybe simply converting G505S
> interrupts code from "legacy style" to "new style" alone should fix
> them.
>
> Sadly no fam15h boards have a "new style" interrupt routing code: if
> to search like " find . -type f -name "irq_tables.c" -print0 | xargs
> -0 grep -n "intel_irq_routing_table" ", only fam14h and fam16h boards
> appear. But I don't expect it to be too difficult: i.e. AM1I-A fam16h
> code is based on ASRock IMB-A180 according to d777c78 commit message,
> and the conversion went OK, also fam15h and 16h are similar enough
> except the vendorcode. I suggest doing " git reset --hard d777c78 " ,
> " kdiff3 ./src/mainboard/asrock/imb-a180/
> ./src/mainboard/biostar/am1ml/ & " , and applying the same logic while
> converting a G505S code. I don't have the time to do this conversion
> myself (spent all holidays working on coreboot and they ran out), but
> if you succeed in this I will happily review your change.
>
> Best regards,
> Mike Banon
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [fam16h AM1I-A] ehci-pci: can't derive routing for PCI INT B. USB 3.0 doesn't work even as USB 2.0

[Michal Zygowski]

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 these.

From what I see in the irq_tables.c file for this board, there is no
routing set for device 0x16.
Secondly, there is no device 0x16 in the devicetree of AM1I-A.
Moreover mainboard_{pirq,intr,picr}_data table does not contain entries
for the EHCI 0x16 device at all so IRQ is not programmed (only USB 0x12
and 0x13 devices are available from what i see). You would have to refer
to a BKDG for your processor and chipset to check whether these problems
I have listed are not copy-paste problems and EHCI 0x16 is really
available for use without XHCI (IMO it should be).

Regards,
Michał

On 06.01.2020 22:15, Mike Banon wrote:
> My AM1I-A config is similar to G505S in this relation:
>
> # CONFIG_HUDSON_XHCI_FWM is not set
> # CONFIG_HUDSON_XHCI_ENABLE is not set
>
> Since XHCI is disabled, I expect its' USB 3.0 ports to work as USB
> 2.0, just like they are working on G505S. However, on AM1I-A they
> don't work at all, and I see this at dmesg kernel log:
>
> ehci-pci :00:16.2: can't derive routing for PCI INT B
> ehci-pci :00:16:2: PCI INT B: no GSI
> ehci-pci :00:16.2: Found HC with no IRQ. Check BIOS/PCI :00:16.2 
> setup!
> ehci-pci :00:16:2: init :00:16:2 fail, -19
> ehci-platform: EHCI generic platform driver
>
> ohci-pci :00:16.0: can't derive routing for PCI INT A
> ohci-pci :00:16:0: PCI INT A: no GSI
> ohci-pci :00:16.0: Found HC with no IRQ. Check BIOS/PCI :00:16.0 
> setup!
> ohci-pci :00:16:0: init :00:16:0 fail, -19
> ohci-platform: OHCI generic platform driver
>
> I tried explicitly enabling 16.0 and 16.2 at devicetree.cb (they
> weren't mentioned here), but it doesn't help. What are my next steps?
>
> Best regards,
> Mike Banon
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AM1I-A Failing to Boot

[Michal Zygowski]

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 boot.
> I do have most of a degree in computer engineering, but that's
> unfortunately 99% theory with little-to-no hands-on experience.
>
> A) If I understand correctly, [1] is the complete change (not the last
> commit in a series for this board) to remove romcc usage from
> asrock/imb-a180.
> The same changes need to be applied to asus/am1i-a.
>
> B) If I understand correctly, the necessary family16h changes have
> been made elsewhere, so only changes to the mainboard-specific code
> need to be made.
> This would explain why there is a net removal of code, not addition.
>
> C) I can't say that I really understand the contents of this file. Can
> someone explain how
>
> /* Set LPC decode enables. */
> pci_devfn_t dev = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev, 0x44, 0xff03ffd5);
>
> and 
>
> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);
>
> and 
>
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);
>
> becomes
>
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> pm_write8(0xea, 0x1);
>
> ?
We did a lot of cleanup with Kyösti and unified implementations of LPC
decode enables and ACPIMMIO. Those instructions you point to were moved
to southbridge bootblock initialization, because it is not mainboard
specific. Also pm_write8(0xea, 0x1); does the same thing as outb(0xea,
0xcd6); and outb(0x1, 0xcd7); but in more readable form. See:
https://review.coreboot.org/c/coreboot/+/37177
https://review.coreboot.org/c/coreboot/+/37329/
https://review.coreboot.org/c/coreboot/+/37168/
>
> D) I'm a bit confused about what [2] is. Is this an earlier, unrefined
> version of the changes?
>
> I don't think that a naive transform would be wise, as there is a lot
> more stuff going on in [3] :P
> For instance:
> 1) would
>
> /* In Hudson RRG, PMIOxD2[5:4] is "Drive strength control for
> * LpcClk[1:0]".  To be consistent with Parmer, setting to 4mA
> * even though the register is not documented in the Kabini BKDG.
> * Otherwise the serial output is bad code.
> */
> outb(0xD2, 0xcd6);
> outb(0x00, 0xcd7);
>
> and
This was also moved to southbridge bootblock initialization - not
mainboard specific.
>
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xEA, 0xcd6);
> outb(0x1, 0xcd7);
>
> be transformed similarly to how
>
>  /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);
>
coreboot uses lowercase for hex values. This should be transformed to
pm_write8(0xea, 1).
> was? 
> 2) would
>
> /* Set LPC decode enables. */
> pci_devfn_t dev2 = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev2, 0x44, 0xff03ffd5);
>
> and
>
> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);
>
> completely disappear?
> what about
>
> hudson_lpc_port80();
>
> in the middle?
> 4) Would
>
> /* Configure ClkDrvStr1 settings */
> addr32 = (u32 *)0xfed80e24;
> *addr32 = 0x030800aa;
>
> /* Configure MiscClkCntl1 settings */
> addr32 = (u32 *)0xfed80e40;
> *addr32 = 0x000c4050;
> /* enable SIO LPC decode */
> dev = PCI_DEV(0, 0x14, 3);
> byte = pci_read_config8(dev, 0x48);
> byte |= 3;/* 2e, 2f & 4e, 4f */
> pci_write_config8(dev, 0x48, byte);
> ite_gpio_conf(GPIO_DEV);
> ite_evc_conf(ENVC_DEV);
> ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> ite_kill_watchdog(GPIO_DEV);
> /*
> * On Larne, after LpcClkDrvSth is set, it needs some time to be
> stable,
> * because of the buffer ICS551M
> */
> for (i = 0; i < 20; i++)
> val = inb(0xcd6);
>
> remain unchanged?
It should be something like:

/* Configure ClkDrvStr1 settings */
misc_write32(0x24, 0x030800aa);
/* Configure MiscClkCntl1 settings */
misc_write32(0x40, 0x000c4050);
ite_gpio_conf(GPIO_DEV);
ite_evc_conf(ENVC_DEV);
ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
ite_kill_watchdog(GPIO_DEV);
/*
* On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
* because of the buffer ICS551M
*/
for (i = 0; i < 20; i++)
val = inb(0xcd6);

The rest is already done in southbridge bootblock init. The file with
modifications should include
#include 

Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

>
> Sincerely,
>     -Matt
>
> [1] https://review.coreboot.org/c/coreboot/+/37453/9
> [2] https://review.coreboot.org/c/coreboot/+/37440/10
> [3] sr

[coreboot] Re: AMD Agesa Bettong board support

[Michal Zygowski]

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 binaryPI: Drop PSP Secure OS from 
> build
>
> and some minor changes. I really want to upload the board status but I'm 
> still trying to make
> the git push to work, I stil can't login. I've attached the tar.gz related to 
> the path:
>
> util/board_status/board-status/amd/bettong/4.11-128-gb64f85d/2019-12-05T09_00_28Z
>
> if could be useful...

You can try setting up SSH key on the gerrit account and change the git
remote to SSH instead of HTTPS.

Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

>
> Regards,
> Jorge
>
> Complete minor changes patch:
>
> diff --git a/src/commonlib/include/commonlib/helpers.h 
> b/src/commonlib/include/commonlib/helpers.h
> index ca3b3c5..d980827 100644
> --- a/src/commonlib/include/commonlib/helpers.h
> +++ b/src/commonlib/include/commonlib/helpers.h
> @@ -50,10 +50,10 @@
>  #endif
>  
>  #ifndef MIN
> -#define MIN(a, b) __CMP(a, b, <)
> +#define MIN(a, b) ((a) < (b) ? (a) : (b))
>  #endif
>  #ifndef MAX
> -#define MAX(a, b) __CMP(a, b, >)
> +#define MAX(a, b) ((a) > (b) ? (a) : (b))
>  #endif
>  
>  #ifndef ABS
> diff --git a/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl 
> b/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl
> index d54f985..ac44f46 100644
> --- a/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl
> +++ b/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl
> @@ -18,7 +18,7 @@ External (TOM1)
>  External (TOM2)
>  Name(_HID, EISAID("PNP0A08"))/* PCI Express Root Bridge */
>  Name(_CID, EISAID("PNP0A03"))/* PCI Root Bridge */
> -Name(_ADR, 0x0018)   /* Dev# = BSP Dev#, Func# = 0 */
> +//Name(_ADR, 0x0018) /* Dev# = BSP Dev#, Func# = 0 */
>  
>  /* Describe the Northbridge devices */
>  
> diff --git a/src/southbridge/amd/pi/hudson/Makefile.inc 
> b/src/southbridge/amd/pi/hudson/Makefile.inc
> index 0eccadb..33f59c7 100644
> --- a/src/southbridge/amd/pi/hudson/Makefile.inc
> +++ b/src/southbridge/amd/pi/hudson/Makefile.inc
> @@ -85,10 +85,10 @@ FIRMWARE_LOCATE=$(dir $(call strip_quotes, 
> $(CONFIG_AMD_PUBKEY_FILE)))
>  FIRMWARE_TYPE=
>  
>  PSPBTLDR_FILE=$(top)/$(FIRMWARE_LOCATE)/PspBootLoader.Bypass.sbin
> -#PSPRCVR_FILE=$(top)/$(FIRMWARE_LOCATE)/PspRecovery.sbin
> -#PSPSCUREOS_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureOs.sbin
> -#PSPTRUSTLETS_FILE=$(top)/$(FIRMWARE_LOCATE)/trustlets.bin
> -#TRUSTLETKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/Trustlet.tkn.cert
> +PSPRCVR_FILE=$(top)/$(FIRMWARE_LOCATE)/PspRecovery.sbin
> +PSPSCUREOS_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureOs.sbin
> +PSPTRUSTLETS_FILE=$(top)/$(FIRMWARE_LOCATE)/trustlets.bin
> +TRUSTLETKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/Trustlet.tkn.cert
>  endif
>  
>  ifeq ($(CONFIG_CPU_AMD_PI_00660F01), y)
> @@ -103,12 +103,12 @@ 
> TRUSTLETKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/TrustletKey_prod_CZ.sbin
>  SMUFIRMWARE2_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuFirmware2_prod_CZ.sbin
>  endif
>  
> -#PUBSIGNEDKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/RtmPubSigned$(FIRMWARE_TYPE).key
> -#PSPNVRAM_FILE=$(top)/$(FIRMWARE_LOCATE)/PspNvram$(FIRMWARE_TYPE).bin
> +PUBSIGNEDKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/RtmPubSigned$(FIRMWARE_TYPE).key
> +PSPNVRAM_FILE=$(top)/$(FIRMWARE_LOCATE)/PspNvram$(FIRMWARE_TYPE).bin
>  SMUFWM_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuFirmware$(FIRMWARE_TYPE).sbin
>  SMUFWM_FN_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuFirmware$(FIRMWARE_TYPE)_FN.sbin
>  SMUSCS_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuScs$(FIRMWARE_TYPE).bin
> -#PSPSECUREDEBUG_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureDebug$(FIRMWARE_TYPE).Key
> +PSPSECUREDEBUG_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureDebug$(FIRMWARE_TYPE).Key
>  
>  endif
>  
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD AGESA board removals

[Michal Zygowski]

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.
>>>
>>> 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
>>> * pcengines/apu1
>> I do not exactly understand "not much testing". While uploading patches
>> for family14 or apu1 I always build, flash, boot Linux test whether it
>> works...
> You can read this no testing at all for fam15tn and fam16kb so far,
> and testing fam14 with a single board.
>
> I believe there was a commit for apu1 where newly added bootblock.c
> file was not linked in, while the boot sequence to OS worked just
> perfect? Some super-io configuration bits are sticky and powered from
> Vbat /Vrtc or Vstb rails, these bootblock changes should be verified
> with (RTC) battery removed.
True. The NCT5104D has UARTA LDN enabled by default with
IO base 0x3f8. So Vbat wouldn't affect it at all.
>
> Kyösti
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD AGESA board removals

[Michal Zygowski]

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
> * pcengines/apu1
I do not exactly understand "not much testing". While uploading patches
for family14 or apu1 I always build, flash, boot Linux test whether it
works...
> Developers will help people who have these platforms to bring their
> board sources to current standards. The process begins by uploading a
> fresh board-status result for the board you volunteer to work on and
> announce this by replying to this thread.
>
> Using one of the above boards as a sample, it might not take more than
> 30 minutes and two boots to make the required transition. But first we
> need to have the above boards working of course.
>
> Our board-status repository has some previous results for the boards
> listed below, and we need your assistance to keep these boards in:
>
> * amd/olivehill
> * amd/persimmon
> * amd/thatcher
> * asrock/e350m1
> * asus/am1i-a
> * asus/f2a85-m
> * biostar/am1ml
> * gizmosphere/gizmo
> * hp/pavilion_m6_1035dx
> * jetway/nf81-t56n-lf
> * lippert/frontrunner-af
> * msi/ms7721
>
> Same offer and request of help as above applies to the following
> boards, for which we have no previous board-status records:
>
> * amd/inagua
> * amd/parmer
> * amd/south_station
> * amd/union_station
> * bap/ode_e20XX
> * biostar/a68n_5200
> * elmex/pcm205400
> * gizmosphere/gizmo2
> * hp/abm
> * lippert/toucan-af
>
> Any board with ROMCC_BOOTBLOCK will be disabled from automatic
> build-testing by 14th December at latest, such that ROMCC_BOOTBLOCK
> removal in common code can proceed. Boards that see no activity will
> be removed from the tree 31st December 2019.
>
> Once a board has its source removed, it will face the standard review
> process should someone want to bring it back. Reincarnations until
> next (4.12) release might not be accepted.
>
> Kind regards,
> Kyösti Mälkki
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD binaryPI board removals

[Michal Zygowski]

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 entry from the middle of the enumeration list.
 */

#if 0
  /* This was removed, shifting everything else up.*/
  AMD_S3_SAVE    = 0x0002C000,
#endif


I think Kyösti could share a little bit more details on that (commit
55fffa29c23).

Regards,
Michał

On 03.12.2019 14:57, Jorge Fernandez Monteagudo wrote:
>> 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.
> Hi Michal,
>
> Do you have already any patch to test? I've updated to the last git and 
> enabled the AMD Bettong
> board (it's disabled in Kconfig.name!) but it's not compiling. There are 
> several errors:
>
> 1) 
> src/drivers/amd/agesa/state_machine.c: In function 'ramstage_dispatch':
> src/drivers/amd/agesa/state_machine.c:216:8: error: 'AMD_S3_SAVE' undeclared 
> (first use in this function); did you mean 'AMD_INIT_LATE'?
>
> 2)
> src/mainboard/amd/bettong/OemCustomize.c:130:6: error: no previous prototype 
> for 'OemCustomizeInitEarly' [-Werror=missing-prototypes]
>  VOID OemCustomizeInitEarly (
> src/mainboard/amd/bettong/OemCustomize.c:149:6: error: no previous prototype 
> for 'OemPostParams' [-Werror=missing-prototypes]
>  void OemPostParams(AMD_POST_PARAMS *PostParams)
>
> 3)
> src/mainboard/amd/bettong/romstage.c:34:7: error: 'cpu_init_detectedx' 
> undeclared (first use in this function); did you mean 'cpu_index'?
>   if (!cpu_init_detectedx && boot_cpu()) {
> src/mainboard/amd/bettong/romstage.c:34:7: note: each undeclared identifier 
> is reported only once for each function it appears in
> src/mainboard/amd/bettong/romstage.c:51:2: error: implicit declaration of 
> function 'AGESAWRAPPER'; did you mean 'AGESA_READ_SPD'? 
> [-Werror=implicit-function-declaration]
>   AGESAWRAPPER(amdinitreset);
> src/mainboard/amd/bettong/romstage.c:51:15: error: 'amdinitreset' undeclared 
> (first use in this function); did you mean 'AmdInitReset'?
>   AGESAWRAPPER(amdinitreset);
> src/mainboard/amd/bettong/romstage.c:56:15: error: 'amdinitearly' undeclared 
> (first use in this function); did you mean 'AmdInitEarly'?
>   AGESAWRAPPER(amdinitearly);
> src/mainboard/amd/bettong/romstage.c:59:15: error: 'amdinitpost' undeclared 
> (first use in this function); did you mean 'AmdInitPost'?
>   AGESAWRAPPER(amdinitpost);
> src/mainboard/amd/bettong/romstage.c: In function 'agesa_postcar':
> src/mainboard/amd/bettong/romstage.c:65:15: error: 'amdinitenv' undeclared 
> (first use in this function); did you mean 'AmdInitEnv'?
>   AGESAWRAPPER(amdinitenv);
> src/mainboard/amd/bettong/romstage.c:28:13: error: 'romstage_main_template' 
> defined but not used [-Werror=unused-function]
>
> Regards,
> Jorge
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD binaryPI board removals

[Michal Zygowski]

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 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.
> Ok, I'll wait for your patches and I'll try to add to the bettong board.
> No problem flashing and unblocking a bricked board.
>
> Thanks!
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD binaryPI board removals

[Michal Zygowski]

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 recovery means
- post card to read post codes
- courage to brick the platform and skills to recover it with external
programmer

Regards,
Michał

On 27.11.2019 11:48, Jorge Fernandez Monteagudo wrote:
>> As of 27th November and commit [1]  platforms using AMD binaryPI blobs
>> have been disabled from automatic  build testing. The following are
>> affected:
>>
>> * amd/bettong
> Hi all,
>
> I have an AMD Bettong demoboard and I would like to remain supported by 
> coreboot.
> What can I do to help?
>
> Regards
> Jorge
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] FOSDEM Open Source Firmware devroom CFP

[Michal Zygowski]

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/2019q4/002933.html

--
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Intel ME ignition firmware becoming available

[Michal Zygowski]

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 unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Planning coreboot 4.11

[Michal Zygowski]

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/+/36914 also address
> C_ENVIRONMENT_BOOTBLOCK for classic AGESA? Besides Coverity issues, is
> that the only objection to keeping them in the tree? Thanks for your
> work on this; I can test on a Fam15h if it helps.
>
Got C bootblock working on apu2 (fam16h) just few moments ago. Aiming to
cover all possible
families (fam14h-fam16h) both AGESA and binaryPI. Will need testing for
mainboards.
have binaryPI fam16h (apu2) and AGESA fam14h (apu1) at hand, so these
will be tested and robust.
However I will need some testing for other families. Your help will be
appreciated. I will also announce the ready patches on mailing list when
I finish the work and call for testing the mainboards.

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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 0x2 could be used? Maybe is it possible to
> relocate the AMDFW to 0x0 instead of 0x2?
> >Not possible. PSP check for certain offsets in search of its own
> >firmware in SPI flash. All you cna do is to relocate it to CBFS to use
> >different base address.
> >> - CONSOLE 0x1 is needed for something?
> >It is for SPI flash console logging. You also may remove it if not
> >selected or needed.
> >> - Is is possible to only have the payload in the RO area?
> >AFAIK it's not. If you put the fallback/payload name to RO_REGION_ONLY,
> >it will probably do not launch the payload at all if executing from RW
> >partition.
>
> Thank you again for this valuable info. I think I could get a booting
> system soon.
> I'll try without the 'lib/cbfs: Add fallback to RO region to
> cbfs_boot_locate' trying
> to move the AGESA to try to fill the empty space playing with
> 'CONFIG_AGESA_BINARY_PI_LOCATION'

Hi Jorge,

You can try to play with VBOOT_ENABLE_CBFS_FALLBACK option to use the
payload from RO region, but it is under review currently (not in the
main tree).


Please do not change CONFIG_AGESA_BINARY_PI_LOCATION. The value is
fixed, because the AGESA is not relocatable code. It must be put at the
given offset, otherwise processor initialization will fail.

>
> fallback/dsdt.aml              0x30ec0    raw              6656 none
> (empty)                        0x32940    null          2042712 none 
> <--
> AGESA                          0x2254c0   raw            690436 none
> (empty)                        0x2cde40   null          1405592 none
> <-
> bootblock                      0x425100   bootblock         944 none
>
> Regards,
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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 := $(CONFIG_AGESA_BINARY_PI_FILE)
>> $(agesa_binary)-type := raw
>> $(agesa_binary)-position := $(CONFIG_AGESA_BINARY_PI_LOCATION)
>>
>> The RO_REGION_ONLY did not recognize the AGESA CBFS name due to the quotes 
>> and placed the file in both partitions still.
> Yes! you're right again, now it's only called once.
>
> Some more questions:
> - 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 0x2 could be used? Maybe is it possible to relocate 
> the AMDFW to 0x0 instead of 0x2?
Not possible. PSP check for certain offsets in search of its own
firmware in SPI flash. All you cna do is to relocate it to CBFS to use
different base address.
> - CONSOLE 0x1 is needed for something?
It is for SPI flash console logging. You also may remove it if not
selected or needed.
> - Is is possible to only have the payload in the RO area?
AFAIK it's not. If you put the fallback/payload name to RO_REGION_ONLY,
it will probably do not launch the payload at all if executing from RW
partition.
>
> Thanks
> Jorge
>
>
>
>
> Regards, Michał 
>
>
> On 14.11.2019 14:15, Jorge Fernandez Monteagudo wrote:
>
>
>
>
> 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 filenes of binaries on the root file system.
>
>
>
> Well, then there is some error some place because I've set RO_REGION_ONLY to 
> 'AGESA' and I'm still seeing
> to calls to added to CBFS. With:
>
> $ make V=1
> ...
> build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 
> 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw   -r COREBOOT  
> -b 0xFFE0 
> ...
> build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 
> 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw   -r FW_MAIN_A 
>  -b 0xFFE0 
>
> $ grep -r "RO_REGION_ONLY" 
> src/security/vboot/Makefile.inc:  $(call 
> strip_quotes,$(CONFIG_RO_REGION_ONLY)) \
> src/security/vboot/Kconfig:config RO_REGION_ONLY
> src/northbridge/intel/haswell/Kconfig:config RO_REGION_ONLY
> src/soc/intel/apollolake/Kconfig:config RO_REGION_ONLY
> src/soc/intel/broadwell/Kconfig:config RO_REGION_ONLY
> src/soc/amd/picasso/Kconfig:config RO_REGION_ONLY
> src/soc/amd/stoneyridge/Kconfig:config RO_REGION_ONLY
> .config.old:CONFIG_RO_REGION_ONLY="AGESA"
> .config:CONFIG_RO_REGION_ONLY="AGESA"
> build/auto.conf:CONFIG_RO_REGION_ONLY="AGESA"
> build/config.h:#define CONFIG_RO_REGION_ONLY "AGESA"
>
> Thanks for your help Mikal!
> Regards
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
>
-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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_CPU_AMD_AGESA_BINARY_PI) += $(agesa_binary)
$(agesa_binary)-file := $(CONFIG_AGESA_BINARY_PI_FILE)
$(agesa_binary)-type := raw
$(agesa_binary)-position := $(CONFIG_AGESA_BINARY_PI_LOCATION)
The RO_REGION_ONLY did not recognize the AGESA CBFS name due to the
quotes and placed the file in both partitions still.
Regards, Michał
On 14.11.2019 14:15, Jorge Fernandez Monteagudo wrote:
>> 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 filenes of binaries on the root file system.
> Well, then there is some error some place because I've set RO_REGION_ONLY to 
> 'AGESA' and I'm still seeing
> to calls to added to CBFS. With:
>
> $ make V=1
> ...
> build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 
> 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw   -r COREBOOT  
> -b 0xFFE0 
> ...
> build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 
> 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw   -r FW_MAIN_A 
>  -b 0xFFE0 
>
> $ grep -r "RO_REGION_ONLY" 
> src/security/vboot/Makefile.inc:  $(call 
> strip_quotes,$(CONFIG_RO_REGION_ONLY)) \
> src/security/vboot/Kconfig:config RO_REGION_ONLY
> src/northbridge/intel/haswell/Kconfig:config RO_REGION_ONLY
> src/soc/intel/apollolake/Kconfig:config RO_REGION_ONLY
> src/soc/intel/broadwell/Kconfig:config RO_REGION_ONLY
> src/soc/amd/picasso/Kconfig:config RO_REGION_ONLY
> src/soc/amd/stoneyridge/Kconfig:config RO_REGION_ONLY
> .config.old:CONFIG_RO_REGION_ONLY="AGESA"
> .config:CONFIG_RO_REGION_ONLY="AGESA"
> build/auto.conf:CONFIG_RO_REGION_ONLY="AGESA"
> build/config.h:#define CONFIG_RO_REGION_ONLY "AGESA"
>
> Thanks for your help Mikal!
> Regards
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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 root file system.

On 14.11.2019 13:07, Jorge Fernandez Monteagudo wrote:
> Hi Michal,
>
> >No, AMDFW which comprises PSP firmware and other components lies at
> >offset 0x2 from the beginning of the flash (typically). AGESA is a
> >silicon initialization code which lies on different offsets (usually
> >0xFFE0) and has to be in the RO region, because this is the range of
> >addresses it fits to (its nearly the bottom of the flash). Putting AGESA
> >in RW_A is impossible, because RW_A is not in the range of addresses
> >where AGESA should be placed, thus the previous error.
> >...
> >Not exactly. This code puts AMDFW always at offset of 0x2 from the
> >beginning of flash. It has nothing to do with CBFS if AMDFW_OUTSIDE_CBFS
> >is selected.
>
> Yes, you're right!! With AMDFW_OUTSIDE_CBFS the AMDFW file is dd to the
> fixed positionand I have to play with the AGESA blob. Then I've tried
> to set
> RO_REGION_ONLY to 'AGESA.bin' or
> '3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin'
> but the build process insist putting the file in RO and RW partition.
> I don't know why?
>
> But I have a progress. I've been able to create a coreboot.rom with
> your fmap file
> and using cbfstool to manually craft the final rom. Now, only the
> payload has no room
> in the FW_MAIN_A.
>
> build/util/cbfstool/cbfstool build/coreboot.rom print -r
> COREBOOT,FW_MAIN_A
> FMAP REGION: COREBOOT
> Name                           Offset     Type           Size   Comp
> cbfs master header             0x0        cbfs header        32 none
> fallback/romstage              0x80       stage           65316 none
> fallback/ramstage              0x10040    stage           68424 none
> cmos_layout.bin                0x20bc0    cmos_layout      1548 none
> pci1002,9874.rom               0x21240    optionrom       64512 none
> fallback/dsdt.aml              0x30ec0    raw              6656 none
> fallback/payload               0x32940    simple elf    2627360 none
> (empty)                        0x2b40c0   null           151256 none
> AGESA                          0x2d8fc0   raw            690436 none
> (empty)                        0x381940   null          1405592 none
> bootblock                      0x4d8c00   bootblock         944 none
> FMAP REGION: FW_MAIN_A
> Name                           Offset     Type           Size   Comp
> fallback/ramstage              0x0        stage           68424 none
> pci1002,9874.rom               0x10b80    optionrom       64512 none
> fallback/dsdt.aml              0x20800    raw              6656 none
>
> Now I'm able to boot and I see the VBOOT traces...
>
> I've found in 'https://doc.coreboot.org/security/vboot/index.html' the
> next configuration: *VBOOT_ENABLE_CBFS_FALLBACK*
> I think it could be an interesting option to fallback to the RO
> payload if I can't make room for him,
> but nothing in the code for this configuration! Anyone knows something?
>
> Regard,
> Jorge
> vboot - Verified Boot Support — coreboot 4.10-1302-g3e9061e27c
> documentation 
> Signing the coreboot Image¶. The following command script is an
> example of how to sign the coreboot image file. This script is used on
> the Intel Galileo board and creates the GBB area and inserts it into
> the coreboot image. It also updates the VBLOCK areas with the firmware
> signing key and the signature for the FW_MAIN firmware. More details
> are available in 3rdparty/vboot/README.
> doc.coreboot.org
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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
>> added to RO partition only in menuconfig of vboot, since it should
>> probably reside there.
> Maybe do you refer to the AMD firmware instead of AGESA? I've seen in
> src/soc/amd/stoneyridge/Makefile.inc when the AMDFW_OUTSIDE_CBFS
> the amdfw.rom is the firmware to copy in a fixed position inside ROM. In
> src/soc/amd/stoneyridge/Kconfig you can see that they define RO_REGION_ONLY
> with the default 'apu/amdfw'
No, AMDFW which comprises PSP firmware and other components lies at
offset 0x2 from the beginning of the flash (typically). AGESA is a
silicon initialization code which lies on different offsets (usually
0xFFE0) and has to be in the RO region, because this is the range of
addresses it fits to (its nearly the bottom of the flash). Putting AGESA
in RW_A is impossible, because RW_A is not in the range of addresses
where AGESA should be placed, thus the previous error.
>
> Anyway, I've tried changing the flash size to 16MB to see the component's
> distribution. I've modified your file a little:
>
> FLASH@0xff80 0x100 {
> RW_UNUSED@0x0 0x2
> AMDFW(PRESERVE)@0x2 0x9
> SI_BIOS@0xb 0xF5 {
> RW_SECTION_A 0x50 {
> VBLOCK_A 0x1
> FW_MAIN_A(CBFS)
> RW_FWID_A 0x40
> }
> CONSOLE 0x1
> SMMSTORE(PRESERVE) 0x4
> RW_VPD(PRESERVE) 0x4000
> WP_RO {
> FMAP@0x0 0x800
> RO_FRID 0x40
> RO_FRID_PAD 0x7c0
> RO_VPD(PRESERVE) 0x4000
> GBB 0x1e000
> COREBOOT(CBFS)
> }
> }
> }
If You do not have 16MB flash you won't be able to flash it with
flashrom. Secondly the base address of 0xff8 should change in such
situation.
>
> Now, the CBFS is created ok:
>
> Created CBFS (capacity = 10325976 bytes)
> Created CBFS (capacity = 5177240 bytes)
> CBFS   AGESA
> CBFS   fallback/romstage
> CBFS   fallback/ramstage
> CBFS   cmos_layout.bin
> CBFS   pci1002,9874.rom
> CBFS   fallback/dsdt.aml
> CBFS   fallback/payload
> CBFS   AGESA
> CBFS   fallback/ramstage
> CBFS   pci1002,9874.rom
> CBFS   fallback/dsdt.aml
> CBFS   fallback/payload
> DD Adding AMD Firmware
> CBFS   coreboot.rom
> CBFSLAYOUT  coreboot.rom
>
> This image contains the following sections that can be manipulated with this 
> tool:
>
> 'RW_UNUSED' (size 131072, offset 0)
> 'AMDFW' (preserve, size 589824, offset 131072)
> 'VBLOCK_A' (size 65536, offset 720896)
> 'FW_MAIN_A' (CBFS, size 5177280, offset 786432)
> 'RW_FWID_A' (size 64, offset 5963712)
> 'CONSOLE' (size 65536, offset 5963776)
> 'SMMSTORE' (preserve, size 262144, offset 6029312)
> 'RW_VPD' (preserve, size 16384, offset 6291456)
> 'RO_FRID' (size 64, offset 6309888)
> 'RO_FRID_PAD' (size 1984, offset 6309952)
> 'RO_VPD' (preserve, size 16384, offset 6311936)
> 'GBB' (size 122880, offset 6328320)
> 'COREBOOT' (CBFS, size 10326016, offset 6451200)
It doesn't mean it will work...
> It is possible to perform either the write action or the CBFS add/remove 
> actions on every section listed above.
> To see the image's read-only sections as well, rerun with the -w option.
> CBFSPRINT  coreboot.rom
>
> FMAP REGION: COREBOOT
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   65316 none
> fallback/ramstage  0x10040stage   68406 none
> cmos_layout.bin0x20bc0cmos_layout  1548 none
> pci1002,9874.rom   0x21240optionrom   64512 none
> fallback/dsdt.aml  0x30ec0raw  6656 none
> fallback/payload   0x32940simple elf2627360 none
> (empty)0x2b40c0   null  5394136 none
> AGESA  0x7d8fc0   raw690436 none
> (empty)0x881940   null  1405592 none
> bootblock  0x9d8c00   bootblock 944 none
> FMAP REGION: FW_MAIN_A
> Name   Offset Type   Size   Comp
> fallback/ramstage  0x0stage   68406 none
> pci1002,9874.rom   0x10b80optionrom   64512 none
> fallback/dsdt.aml  0x20800raw  6656 none
> fallback/payload   0x22280simple elf2627360 none
> (empty)0x2a3a00   null   312664 none
> AGESA  0x2eff80   raw690436 none
> (emp

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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_STARTS_IN_ROMSTAGE

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
added to RO partition only in menuconfig of vboot, since it should
probably reside there.

On 13.11.2019 14:37, Jorge Fernandez Monteagudo wrote:
> Hi Michal!
>
> Thanks for the info!
>
> Yes, I'm using the amd/bettong mainboard. I've changed the Kconfig adding
>
> config VBOOT
>   select VBOOT_STARTS_IN_ROMSTAGE
>   select VBOOT_NO_BOARD_SUPPORT
>   select VBOOT_MEASURED_BOOT
>   select AMDFW_OUTSIDE_CBFS
>
> config VBOOT_SLOTS_RW_A
>   default y
>
> config FMDFILE
>   string
>   default "src/mainboard/$(CONFIG_MAINBOARD_DIR)/vboot-rwa.fmd" if VBOOT
>
> Now, I get an error processing the CBFS. As you said, I suppose I need to 
> modify the sizes
> to adapt it to my requirements. Where can I found info about the fmap files? 
> This, and the
> cmos layout files are unknown areas to me, and I don't know where to begin to 
> modify it.
>
> The error I get is:
>
> Created CBFS (capacity = 5083096 bytes)
> Created CBFS (capacity = 2031512 bytes)
> CBFS   AGESA
> CBFS   fallback/romstage
> CBFS   fallback/ramstage
> CBFS   cmos_layout.bin
> CBFS   pci1002,9874.rom
> CBFS   fallback/dsdt.aml
> CBFS   fallback/payload
> CBFS   AGESA
> E: Could not add [3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin, 690436 bytes 
> (674 KB)@0x54]; too big?
> E: Failed to add '3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin' into ROM 
> image.
> E: Failed while operating on 'FW_MAIN_A' region!
> E: The image will be left unmodified.
>
> Regards,
> Jorge
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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_SECTION_A 0x20 {
            VBLOCK_A 0x1
            FW_MAIN_A(CBFS)
            RW_FWID_A 0x40
        }
        CONSOLE 0x1
        SMMSTORE(PRESERVE) 0x4
        RW_VPD(PRESERVE) 0x4000
        WP_RO {
            FMAP@0x0 0x800
            RO_FRID 0x40
            RO_FRID_PAD 0x7c0
            RO_VPD(PRESERVE) 0x4000
            GBB 0x1e000
            COREBOOT(CBFS)
        }
    }
}

Important to select AMDFW_OUTSIDE_CBFS when using this flashmap layout.
Save the content to the board.fmd file and fill the file path in the
menuconfig: General -> fmap description file in fmd format

You may want to choose different sizes of partitions etc. This is just
an example.

Regards,
Michał

On 13.11.2019 12:35, Jorge Fernandez Monteagudo wrote:
> Hi Michal!
>
>> You need to reserve some CMOS memory for vboot context, set default
>> vboot configuration in Kconfig of your platform and prepare a flashmap
>> layout file (*.fmd) - its the simplest case. Additionally you should
>> have at least one RW slot by selecting CONFIG_VBOOT_SLOTS_RW_A.
> Could you please advise how to implement the flashmap layout file to reserve
> space for the RW partition? When coreboot rom is compile without VBOOT
> I get the next info:
>
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   32260 none
> fallback/ramstage  0x7f00 stage   64238 none
> cmos_layout.bin0x17a40cmos_layout  1516 none
> fallback/dsdt.aml  0x18080raw  6656 none
> (empty)0x19b00null25240 none
> apu/amdfw  0x1fdc0raw560128 none
> pci1002,9874.rom   0xa8a00optionrom   64512 none
> fallback/payload   0xb8680simple elf2627296 none
> (empty)0x339dc0   null  2908120 none
> AGESA  0x5ffdc0   raw690436 none
> (empty)0x6a8740   null  1405592 none
> bootblock  0x7ffa00   bootblock 944 none
>
> and the default fmd map:
>
> # layout for firmware residing at top of 4GB address space
> # +-+ <-- 4GB - ROM_SIZE / start of flash
> # | unspecified |
> # +-+ <-- 4GB - BIOS_SIZE
> # | FMAP|
> # +-+ <-- 4GB - BIOS_SIZE + FMAP_SIZE
> # | CBFS|
> # +-+ <-- 4GB / end of flash
>
> FLASH@4286578688 0x80 {
> BIOS@0 8388608 {
> FMAP@0 0x200
> COREBOOT(CBFS)@512 8388096
> }
> }
>
> Thanks!
> Jorge
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Decryption of post codes that appear during Intel FSP operation?

[Michal Zygowski]

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/KabylakeFspBinPkg/Docs/Kabylake_FSP_Integration_Guide.pdf

section umber 5: FSP  POSTCODE.

Regards,
Michał

On 12.11.2019 20:18, dponamo...@gmail.com wrote:
> Hi! 
>
> Please tell me where I can get the decryption of post codes that appear 
> during Intel FSP operation?
> Codes such as 0x57, 0x59, 0x58, 0x62 ...  
> I see that they appear during testing and memory tuning, but I would like to 
> have more detailed information. 
> Maybe someone knows the number of the Intel document to download?
>
> Regards,
> Dmitry
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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
vboot configuration in Kconfig of your platform and prepare a flashmap
layout file (*.fmd) - its the simplest case. Additionally you should
have at least one RW slot by selecting CONFIG_VBOOT_SLOTS_RW_A.

If this is already done for your boards, then:

CONFIG_VBOOT
CONFIG_VBOOT_MEASURED_BOOT
CONFIG_VBOOT_SLOTS_RW_A

selected from menuconfig should be sufficient.

Regards,
Michał

On 12.11.2019 11:38, Jorge Fernandez Monteagudo wrote:
> Hi Michal,
>
>> 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.
> Which configs are needed?
>
> CONFIG_VBOOT
> CONFIG_VBOOT_MEASURED_BOOT
>
> Anything else?
>
> Thanks!
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to measure the differents parts of coreboot?

[Michal Zygowski]

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 parts of coreboot 
> once loaded.
> Is it correct to use the pointers from memlayout.h? For instance to extent 
> the romstage
> to PCR1 I do something like:
>
> extern char _romstage, _eromstage;
> tlcl_measure(1, &_romstage, &_eromstage - &_romstage);
>
> Is it correct to do the same bootblock, ramstage, verstage, etc? My goal is 
> to extend all the
> coreboot.
>
> Thanks!
> Jorge
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Planning coreboot 4.11

[Michal Zygowski]

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 plan to volunteer for C_ENVIRONMENT_BOOTBLOCK=y conversion
> for AGESA/PI platforms, so it is currently uncertain if some or any of
> them will remain on master branch after 4.11 release.
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).

Kyösti I would appreciate if you could look at
https://review.coreboot.org/c/coreboot/+/32363
Nobody tells you to volunteer, but review very welcome, since nobody
seems to be interested
to even take look at it.

Michał
>
> Kyösti
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

[Michal Zygowski]

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 is very likely that it was not propagated back into the
>> FSP. This is how this werid system works. Bugs and issues are not
>> propagated back into older trees and vendors are creating tons of
>> unmaintainable forks for the firmware.
> For the newer Intel SOCs (Kaby Lake and newer) I have mostly eliminated this 
> issue. The binaries posted on github.com/IntelFsp are up to date with same 
> version of memory code that the BIOS vendors get for Kaby Lake, Coffee Lake, 
> Amber Lake, Whiskey Lake, Comet Lake, and Ice Lake. The one exception being 
> if the BIOS vendor changes the memory code and doesn't upstream their changes 
> back to Intel. Intel obviously can't do anything about that.
>
> I'm not involved in the development for the Broadwell-DE FSP so unfortunately 
> I can't help on this specific platform.
>
> Regards,
>
> Nate
I'm not blaming Intel. As you said Nate, there is nothing you can do.
Just pointing out that "vendors are creating tons of forks" where by
vendor I had IBVs in mind (in some particular cases Intel may be an IBV,
but this time I implicitly excluded Intel as IBV, sorry I didn't clarify).

Regards,
Michał
>> Applying the same changed SPD
>> parameters may give different results of memory training with FSP and
>> vendor BIOS. The best way to go is to get the hands on the papers David
>> pointed to (if possible) and do trial-by-error. It may take time but
>> there is a chance to succeed. Good thing is you have debug output from
>> FSP so at least you know what is wrong.
>>
>> Regards,
>> Michał
>>> I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is
>>> there which I can make use of, to pass an SPD bin. I am not sure how
>>> to prepare that binary but I am assuming we can put all the 512 hex
>>> bytes of SPD as per DDR4 SPD spec into a text file and name it as
>>> spd.bin and pass along. (example :
>>> https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex)
>>> Coreboot build system will automatically pack it. Compilation passed
>>> for me and will test it now, if the SPD data is read properly.
>>> <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex>
>>> 
>>> coreboot/coreboot
>>> <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex>
>>> github mirror of coreboot.org's master repository. Contribute to
>>> coreboot/coreboot development by creating an account on GitHub.
>>> github.com
>>>
>>>
>>>
>>> In case this is not the correct way, the alternative way could be to
>>> create a UINT8 buff [512] and typecast to
>>> UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
>>> directly.
>>>
>>> While I am testing all this, anyone please correct me on the .bin
>>> part, so that it helps future contributors as well, as its not
>>> documented anywhere in coreboot.
>>>
>>> Regards,
>>> Naveen
>>> 
>>> *From:* David Hendricks 
>>> *Sent:* Wednesday, 30 October, 2019, 12:44 PM
>>> *To:* Naveen Chaudhary
>>> *Cc:* Wim Vervoorn; Nico Huber; coreboot@coreboot.org
>>> *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
>>> "Configuration not in POR table"
>>>
>>> Hi Naveen,
>>> Yes, the first sentence. The DIMMs you are using appear to have
>>> geometry or timings incompatible with Broadwell-DE, based on the SPD
>>> values that the vendor programmed. Chapter 6 of the PDG (docid 543448)
>>> should help clarify what kinds of DIMMs are supported and how they
>>> should be populated.
>>>
>>> On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary
>>> >> <mailto:naveenchaudhary2...@hotmail.com>> wrote:
>>>
>>> Sorry I didn't get the point completely. Do you mean the settings
>>> are not compatible with FSP code? Or do you mean the settings
>>> might be conflicting themselves.
>>>
>>> Since the above settings were read from SPD and the chip vendor
>>>  

[coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

[Michal Zygowski]

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 != FSP. The BIOS vendor
could obtain different memory initialization code from Intel with some
bug fixes and it is very likely that it was not propagated back into the
FSP. This is how this werid system works. Bugs and issues are not
propagated back into older trees and vendors are creating tons of
unmaintainable forks for the firmware. Applying the same changed SPD
parameters may give different results of memory training with FSP and
vendor BIOS. The best way to go is to get the hands on the papers David
pointed to (if possible) and do trial-by-error. It may take time but
there is a chance to succeed. Good thing is you have debug output from
FSP so at least you know what is wrong.

Regards,
Michał
>
> I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is
> there which I can make use of, to pass an SPD bin. I am not sure how
> to prepare that binary but I am assuming we can put all the 512 hex
> bytes of SPD as per DDR4 SPD spec into a text file and name it as
> spd.bin and pass along. (example :
> https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex)
> Coreboot build system will automatically pack it. Compilation passed
> for me and will test it now, if the SPD data is read properly.
> 
>   
> coreboot/coreboot
> 
> github mirror of coreboot.org's master repository. Contribute to
> coreboot/coreboot development by creating an account on GitHub.
> github.com
>
>
>
> In case this is not the correct way, the alternative way could be to
> create a UINT8 buff [512] and typecast to
> UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
> directly.
>
> While I am testing all this, anyone please correct me on the .bin
> part, so that it helps future contributors as well, as its not
> documented anywhere in coreboot.
>
> Regards,
> Naveen
> 
> *From:* David Hendricks 
> *Sent:* Wednesday, 30 October, 2019, 12:44 PM
> *To:* Naveen Chaudhary
> *Cc:* Wim Vervoorn; Nico Huber; coreboot@coreboot.org
> *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
> Hi Naveen,
> Yes, the first sentence. The DIMMs you are using appear to have
> geometry or timings incompatible with Broadwell-DE, based on the SPD
> values that the vendor programmed. Chapter 6 of the PDG (docid 543448)
> should help clarify what kinds of DIMMs are supported and how they
> should be populated.
>
> On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary
>  > wrote:
>
> Sorry I didn't get the point completely. Do you mean the settings
> are not compatible with FSP code? Or do you mean the settings
> might be conflicting themselves.
>
> Since the above settings were read from SPD and the chip vendor
> must have definitely set them correctly, I assume you meant first
> sentence.
>
> Please correct me.
>
> Regards,
> Naveen
>
> Get Outlook for Android 
>
> 
> *From:* Wim Vervoorn  >
> *Sent:* Tuesday, October 29, 2019 3:47:34 PM
> *To:* Naveen Chaudhary  >; Nico Huber
> mailto:nic...@gmx.de>>; David Hendricks
> mailto:david.hendri...@gmail.com>>
> *Cc:* coreboot@coreboot.org 
> mailto:coreboot@coreboot.org>>
> *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> - "Configuration not in POR table"
>  
>
> Hello Naveen,
>
>  
>
> This is the important part. This indicates the what you selected
> is not supported.
>
>  
>
> Please review your settings carefully. This isn't a single check.
> The code validates the SPD settings against the other settings you
> made.
>
> So please make sure you are passing in a DDR4 SPD when you select
> DDR4 mode. Also please make sure the SPD settings are in
>
> The list of supported configuration for the chip.
>
>  
>
> Check POR Compatibility -- Started
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> bankGroupsDDR4: 4
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> bankGroupsDDR4: 4
>
> Unknown DIMM population *
>
> Check POR Compatibility - 17ms
>
> Initialize DDR Clocks 

[coreboot] Re: Bootblock and Romstage logs getting skipped on first boot and boot continues from ramstage instead

[Michal Zygowski]

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
port gets initialized by coreboot before FSP and befor econsole is
initialized. The string:

coreboot-4.10-984-gdd4c625469-dirty Mon Oct 14 18:32:09 UTC 2019
romstage starting (log level: 7)

is actually printed by console_init(); function which is called before
FSP and after built-in serial port is enabled.

Hopefully this explanation is sufficient.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

On 20.10.2019 14:22, Naveen Chaudhary wrote:
> "Enable built-in legacy serial port"
>
> After I turn this on, I get the logs since the romstage beginning
> (including fsp_init and next).
>
> But still I am not clear much, requesting some help to explain the
> scenario.
>
>
> Regards
> Naveen
> PS : with a dream to become an expert BIOS engineer
> 
> *From:* Naveen Chaudhary 
> *Sent:* Sunday, October 20, 2019 5:16 PM
> *To:* coreboot@coreboot.org 
> *Subject:* Re: Bootblock and Romstage logs getting skipped on first
> boot and boot continues from ramstage instead
>  
> From past 5 days, I have built and flashed coreboot a 100 times and I
> could see the following line in every cold boot :
> coreboot-4.10-984-gdd4c625469-dirty Mon Oct 14 18:32:09 UTC 2019
> romstage starting (log level: 7)...
>
> Now I never see this line, but instead its always the ramstage (no
> romstage) as mentioned earlier. I have no code changes, except few
> comments as a note to myself. In both the scenarios, I boot till the
> bootloader successfully.
>
> I am surprised why I am not getting romstage logs?? I am physically
> removing the power cable for cold boot, but still no romstage logs.
> The romstage logs come only when the SeaBIOS waits for 60 seconds and
> does a hard reboot. Physically removing the power cable directly leads
> me to the ramstage.
>
> Regards,
> Naveen
> 
> *From:* Naveen Chaudhary
> *Sent:* Sunday, October 20, 2019 4:48 PM
> *To:* coreboot@coreboot.org 
> *Subject:* Bootblock and Romstage logs getting skipped on first boot
> and boot continues from ramstage instead
>  
> Hi,
>
> The title seems pretty stupid but that's what I am observing on my
> MinnowMax. When I have built coreboot and flashed and the moment I
> connect the power cable back, I see the following logs (no romstage
> beginning logs, no console_init logs):
>
> romstage_main_continue status: 0  hob_list_ptr: 7ae2
> FSP Status: 0x0
> PM1_STS = 0x2000 PM1_CNT = 0x0 GEN_PMCON1 = 0x1001808
> romstage_main_continue: prev_sleep_state = S0
> Baytrail Chip Variant: Bay Trail-I (ISG/embedded)
> MRC v0.102
> 1 channels of DDR3 @ 1066MHz
> CBMEM:
> IMD: root @ 7adff000 254 entries.
> IMD: root @ 7adfec00 62 entries.
> FMAP: Found "FLASH" version 1.1 at 50.
> FMAP: base = ff80 size = 80 #areas = 3
> SMM Memory Map
> SMRAM       : 0x7b00 0x80
>  Subregion 0: 0x7b00 0x70
>  Subregion 1: 0x7b70 0x10
>  Subregion 2: 0x7b80 0x0
> CBFS: 'Master Header Locator' located CBFS at [500200:80)
> CBFS: Locating 'fallback/ramstage'
> CBFS: Found @ offset 2ca80 size ef16
>
>
> coreboot-4.10-984-gdd4c625469-dirty Mon Oct 14 18:32:09 UTC 2019
> ramstage starting (log level: 7)...
> Moving GDT to 7adfe900...ok
> BS: BS_PRE_DEVICE times (us): entry 0 run 2 exit 0
> CBFS: 'Master Header Locator' located CBFS at [500200:80)
> CBFS: Locating 'cpu_microcode_blob.bin'
> CBFS: Found @ offset 1fe00 size cc00
> microcode: sig=0x30679 pf=0x1 revision=0x90c
> CPUID: 00030679
> Cores: 2
>
> However, when there is a hard reset by the SeaBIOS when there is no
> bootable device found, I get the complete logs since the romstage.
>
> No bootable device.  Retrying in 60 seconds.
> Rebooting.
> In resume (status=0)
> In 32bit resume
> Attempting a hard reboot
> ACPI hard reset 1:cf9 (6)
>
>
> coreboot-4.10-984-gdd4c625469-dirty Mon Oct 14 18:32:09 UTC 2019
> romstage starting (log level: 7)...    *<--- This logs does not appear
> in the first case.*
>
> Can someone please help understand this behaviour as why on the first
> boot, no ramstage log appears and then each successive reset I get the
> romstage logs, but not in the first boot.
>
> Previous sleep state reported in the logs in both the cases is S0. Am
> I just missing the logs or there is indeed something happening under
> the hood?
>
> Regards,
> Naveen
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe

[coreboot] Re: Graphics Initialization

[Michal Zygowski]

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 happens.
Additionally you will have to have an array defining SerialIO devices in
devicetree like:

    register "SerialIoDevMode" = "{
        [PchSerialIoIndexI2C0]  = PchSerialIoPci,
        [PchSerialIoIndexI2C1]  = PchSerialIoPci,
        [PchSerialIoIndexI2C2]  = PchSerialIoPci,
        [PchSerialIoIndexI2C3]  = PchSerialIoPci,
        [PchSerialIoIndexI2C4]  = PchSerialIoDisabled,
        [PchSerialIoIndexI2C5]  = PchSerialIoPci,
        [PchSerialIoIndexSPI0] = PchSerialIoPci,
        [PchSerialIoIndexSPI1] = PchSerialIoPci,
        [PchSerialIoIndexSPI2] = PchSerialIoDisabled,
        [PchSerialIoIndexUART0] = PchSerialIoSkipInit,
        [PchSerialIoIndexUART1] = PchSerialIoDisabled,
        [PchSerialIoIndexUART2] = PchSerialIoSkipInit,
    }"
So it will pass the correct parameters to FSP. You have to either choose
PchSerialIoPci or PchSerialIoAcpi, depending on your needs.

Regards,
Michał

On 04.10.2019 16:19, Senthil Kumar G via coreboot wrote:
> Hi,
>
> I have added the wrong VBT file. Corrected it and display is coming.
>
> Is there any way to configure all uart of the processor. I am getting
> only one serial controller in list of lspci. Coffeelake has three uart
> ports but only one is getting listed.
>
> Thanks for the support.
>
> rgds,
> gsen
>
> On Friday, 4 October, 2019, 12:18:49 pm IST, Senthil Kumar G via
> coreboot  wrote:
>
>
> Hi,
>
> I have added the VBT in the coreboot.
>
> CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/intel/cflrvp/VbtCfl_h.bin"
>
> On Friday, 4 October, 2019, 11:26:19 am IST, Matt DeVillier
>  wrote:
>
>
> FSP can't initialize the graphics device without a valid VBT being
> loaded. Are you supplying that and setting the associated options in
> your config? 
>
> On Fri, Oct 4, 2019, 12:32 AM Senthil Kumar G via coreboot
> mailto:coreboot@coreboot.org>> wrote:
>
> Hi,
>
> We are developing coreboot along with UEFI shell payload for
> Coffelake architecture. We are using the processor integrated
> graphics controller for display.
>
> I am getting the following error on porting the coreboot.
>
> Grahics hand-off block not found.
> FSP did not return a valid framebuffer.
>
> I checked internal graphics is enabled in FSP and graphics memory
> is set to 32 MB. Also applied a patch found in coreboot mailing
> list on device tree and gpio files for Intel graphics.
>
> Whether Coreboot can print any messages on the display (other than
> console).
>
> Coreboot came up and I got the shell prompt on Uart Console. The
> same shell prompt has to come on the display (monitor) but not
> displayed.  I suspect some graphics initialization problem.
>
> Regards,
> gsen.
>
>
>
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> 
> To unsubscribe send an email to coreboot-le...@coreboot.org
> 
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> 
> To unsubscribe send an email to coreboot-le...@coreboot.org
> 
> ___
> coreboot mailing list -- coreboot@coreboot.org
> 
> To unsubscribe send an email to coreboot-le...@coreboot.org
> 
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: graphic preallocated memory

[Michal Zygowski]

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://github.com/coreboot/coreboot/blob/master/src/northbridge/intel/sandybridge/early_init.c#L116

You can change that by changing the gfx_uma_size parameter in CMOS
configuration utility - nvramcui. It is a payload that modifies the CMOS
based runtime options.

Regards,
Michał

On 9/25/19 11:15 AM, jief wrote:
>
> Hi,
>
> I'm new to coreboot and this list, so please forgive and tell me if
> I'm doing something wrong.
>
> I've successfully compile coreboot and flash it to a Lenovo x220. I
> tried seabios and tianocore as a payload and it works. So strange
> compile errors as I'm used to when I compile an opensource project.
> So, _bravo_.
>
> What I need now is to be able to set the graphic preallocated memory.
> Usually in bios, it's "DVMT pre alloc" or something. I know it's
> possible on this platform because the unlocked bios can do it.
>
> Could anyone point me in the direction ?
>
> Thanks,
>
> Jief
>
> Mainboard : x220, i7-2640M@2.80GHz
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: supported hardware

[Michal Zygowski]

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 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?
> Somebody is working on it: https://review.coreboot.org/c/coreboot/+/35427
> I would recommend messaging him about the port status. He is also active on
> IRC, if you prefer less formal and more spontaneous communication channels.
>
>> I do not see any reason it shouldn't. BMC, chipset and supported
>> processors are the same. There are small differences in PCI Express
>> topology which should be adjusted in devicetree and/or FSP config, but
>> it should still boot. IIRC flash descriptor handles the PCI Express lane
>> configuration, so small changes in devicetree and/or  FSP config eventually.
> Please do NOT suggest running coreboot ROMs for mainboard X on something
> that is not mainboard X. If GPIO settings for the southbridge and/or SuperIO
> differ between boards X and Y, running coreboot for board X on board Y can
> result in short-circuits, and cause permanent hardware damage. And replacing
> the SuperIO, southbridge, or even the whole SoC on some board, is a very
> laborious task which requires expensive, specialized equipment and skills,
> so it is impractical to do for most people.
Yep, you are right. I was a little bit too hasty.  I have just recently
tested a coreboot on mainboards like these with just different product
suffix and it occurred to have the same GPIO configuration. It is quite
unlikely that the GPIOs will change. Like you said, replacing the
components is expensive so I doubt board vendors do that for similar
mainboards. However still significant enough to not ignore it.

Thank you for correction Angel.

Regards,
Michał
>
>> Best regards,
>> Michał
>>> Best regards
>> --
>> Michał Żygowski
>> Firmware Engineer
>> http://3mdeb.com | @3mdeb_com
> Regards,
>
> Angel
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: supported hardware

[Michal Zygowski]

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 do not see any reason it shouldn't. BMC, chipset and supported
processors are the same. There are small differences in PCI Express
topology which should be adjusted in devicetree and/or FSP config, but
it should still boot. IIRC flash descriptor handles the PCI Express lane
configuration, so small changes in devicetree and/or  FSP config eventually.

Best regards,
Michał
>
> Best regards
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: TPM measurements with UefiPayloadPkg EDK2

[Michal Zygowski]

Hi Matt,

Unfortunately not. I just have studied Git log for changes in
SecurityPkg to determine whether white paper is valid or not. The only
thing that helped me achieve the goal was the OVMF package and its
modified modules taken from SecurityPkg on the master branch. So
basically nothing 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.zygow...@3mdeb.com>> wrote:
>
> 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 of the guidelines in this white paper are useless
> unfortunately.
>
> Some modifications to included libraries and components in DSC and few
> INFs in FDF. At last few PCD fixes and done.
>
> Regards,
>
> On 13.09.2019 02:33, benjamin.doro...@gmail.com
> <mailto:benjamin.doro...@gmail.com> wrote:
> > I remember seeing a guide on Tianocore's wiki on GitHub that I
> was meaning to follow after porting coreboot to my laptop. From
> memory, it's a matter of adding some "includes" to the package you
> plan to build. Hopefully isn't much more than that.
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> <mailto:coreboot@coreboot.org>
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> <mailto:coreboot-le...@coreboot.org>
>
> -- 
> Michał Żygowski
> Firmware Engineer
> http://3mdeb.com | @3mdeb_com
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> <mailto:coreboot@coreboot.org>
> To unsubscribe send an email to coreboot-le...@coreboot.org
> <mailto:coreboot-le...@coreboot.org>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: TPM measurements with UefiPayloadPkg EDK2

[Michal Zygowski]

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 of the guidelines in this white paper are useless unfortunately.

Some modifications to included libraries and components in DSC and few
INFs in FDF. At last few PCD fixes and done.

Regards,

On 13.09.2019 02:33, benjamin.doro...@gmail.com wrote:
> I remember seeing a guide on Tianocore's wiki on GitHub that I was meaning to 
> follow after porting coreboot to my laptop. From memory, it's a matter of 
> adding some "includes" to the package you plan to build. Hopefully isn't much 
> more than that.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] TPM measurements with UefiPayloadPkg EDK2

[Michal Zygowski]

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 that PEI and DXE cannot be measured before execution with
current implementation, because drivers are available late in DXE. If my
understanding is correct, if I would use vboot+measured boot in coreboot
the whole payload is measured still, but the trust chain would be broken
after SEC. Can anybody tell if I am wrong?

Best regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[Michal Zygowski]

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.
>>
>> 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 landing to the binaryPI). Although these are
>> AGESA and binaryPI types, will the same approach be applicable here?
>>
> Nice, let's coordinate the efforts on PC Engines products.
>
> The principles are the same, move CAR init from the start of romstage
> to start of bootblock. There are some things to consider about CAR
> memory layout and stack, but nothing major there. An aspect for
> possible future deployment of verstage is that calling vendorcode or
> binaryPI blob from bootblock is discouraged. We should not need the
> binaryPI blob to setup LPC routes or any SoC PAD configurations so
> enabling console in bootblock should not be an issue for us. I can't
> remember why the initial work on amd/stoneyridge called (unverified
> but read-only) vendorcode blob already from within the bootblock.
> Maybe it was something about GPIOs.
I get the overall idea of C bootblock. The most fun is about the
assembly to setup CAR early. But what about S3 suspend/resume for APU2
for example? It is not supported by the platform and does not seem to be
needed at all there (it is just a router which should be always on).
Maybe the check for RELOCATABLE_RAMSTAGE should be omitted when
HAVE_ACPI_RESUME is not set for the platform? However the thing is all
about southbridge/northbridge code still.

That stoneyridge thing is interesting... Cannot imagine what it could be
called for such early.

Regards,
Michał Żygowski
>
> Regards,
> Kyösti Mälkki
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[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 landing to the binaryPI). Although these are
AGESA and binaryPI types, will the same approach be applicable here?

Best regards,
Michał Żygowski

On 8/21/19 5:50 AM, Kyösti Mälkki wrote:
> On Wed, Aug 21, 2019 at 5:43 AM Matt B  wrote:
>> Is a lack of C bootblock support common to all family 15h platforms? 
>> (Including the G505s and any others?)
>> In other words, would it only need to be implemented once for all of these 
>> systems?
>>
> It's not really a CPU family thing at all, but about the
> implementation otherwise. It's one fix for all AGESA, one for all
> binaryPI, and a third one for native amdfam10-15.
>
> My suggestion on moving forwards with amdfam10-15 is as follows:
>
> The next release is scheduled for Oct 2019 (?). Regardless of when
> that happens, I would introduce a flag on the October 1st that
> disables all amdfam10-15 boards from the automatic build. Then, if we
> have anyone capable and willing to have this amdfam10-15 stay on
> master branch, she/he would get to select one mainboard for which the
> build would remain enabled. The platform code then needs to go through
> the transitions of =>RELOCATABLE_RAMSTAGE, =>POSTCAR_STAGE,
> =>C_ENVIRONMENT_BOOTBLOCK. During that process, any remaining #include
> <*.c> are to be removed and regressions other amdfam10-15 boards
> __are__ allowed and will be ignored as the builds are disabled, Once
> the reference platform reaches a state where it fulfills the release
> requirements, interested parties can port the necessary changes to
> individual motherboards. Providing boot-logs is a necessity. At the
> time of next release, boards that don't build will have their source
> files removed.
>
> Regards,
> Kyösti Mälkki
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: simplest fmap for minimal vboot deployment

[Michal Zygowski]

On 08.08.2019 11:21, Persmule wrote:
> Thanks Micha,
>
> The exemplar fmd you linked is very close to the simplest scheme I
> imagine.
>
> I may be going to work on the build system, in order to generate such
> fmd automatically in the future, since there is a Kconfig variable
> 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
>  wrote:
>
>> Yes, if you are interested entirely in measured boot mode only, the
>> RO section is sufficient.
>>
>> The GBB is much greater since ChromeOS recovery bitmaps resides
>> there. For non-ChromeOS devices (like many Lenovo laptops implement
>> in coreboot) I saw min 120KiB (0x1e000). Should be sufficient.
>> Example fmap description of flash with RO section:
>> https://github.com/coreboot/coreboot/blob/master/src/mainboard/ocp/wedge100s/vboot-ro.fmd
>> (probably you would like to adjust some offsets and sizes)
>
> Best regards,
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: simplest fmap for minimal vboot deployment

[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
>>
>>
>> Vboot is responsible for firmware verification (checks firmware
>> signature blocks). The TPM measurements are only an extension to
>> Vboot logic adopted in coreboot. In order to have verified boot, at
>> least one RW partition must exists.
>
> Is it possible to omit RW sections completely, letting vboot always
> boot into "system recovery" (in the RO section) which is actually used
> for normal boot?
> (I believe that stages and payloads in the RO section will be measured
> too when booting into "system recovery". Please correct me if I am wrong.)
Yes, if you are interested entirely in measured boot mode only, the RO
section is sufficient.
>
>> for Measured boot, only single CBFS is fine. to support verified and
>> measured boot, one RW partition is sufficient. The example linked
>> above has the minimal fmap layout for verified and measured boot for
>> Lenovo x220. SMMSTORE is optional as well as RW_VPD and RO_VPD
>> (depends on use case). SI_GBE region is mandatory for vPRO platforms
>> to support Gigabit Ethernet, SI_ME and SI_DESC are Intel ME and Flash
>> descriptor regions, also mandatory.
>
> Besides, at least how many bytes should be retained for the GBB section?
The GBB is much greater since ChromeOS recovery bitmaps resides there.
For non-ChromeOS devices (like many Lenovo laptops implement in
coreboot) I saw min 120KiB (0x1e000). Should be sufficient. Example fmap
description of flash with RO section:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/ocp/wedge100s/vboot-ro.fmd
(probably you would like to adjust some offsets and sizes)
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: simplest fmap for minimal vboot deployment

[Michal Zygowski]

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 with a patched coreboot), so
>
>
> the simple scheme with a single CBFS containing all stages and
> payloads is prefered.
Here is an example:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/lenovo/x220/vboot-rwa.fmd

>
> My question is: if vboot is only used to perform TPM measurement, at
> least which sections must be added to the fmap, in addition to default
> ones (RW_MRC_CACHE and CBFS), allowing vboot to work?
Vboot is responsible for firmware verification (checks firmware
signature blocks). The TPM measurements are only an extension to Vboot
logic adopted in coreboot. In order to have verified boot, at least one
RW partition must exists. for Measured boot, only single CBFS is fine.
to support verified and measured boot, one RW partition is sufficient.
The example linked above has the minimal fmap layout for verified and
measured boot for Lenovo x220. SMMSTORE is optional as well as RW_VPD
and RO_VPD (depends on use case). SI_GBE region is mandatory for vPRO
platforms to support Gigabit Ethernet, SI_ME and SI_DESC are Intel ME
and Flash descriptor regions, also mandatory.

>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: HPET MSI/FSB on AMD 16h

[Michal Zygowski]

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 disabled on some platforms by default:
>>>>>
>>>>> src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c:
>>>>>
>>>>>    TRUE,    // HpetMsiDis
>>> FWIW, I hardcoded the above to FALSE, recompiled, and reflashed my
>>> f15tn. It caused Qubes to run about half as fast. I checked the logs
>>> and didn't see any errors to explain why. I then changed it back to
>>> TRUE and HPET itself to FALSE (and recompiled/reflashed). Normal speed
>>> came back, XEN Platform timer changed from HPET to ACPI, and MSI is
>>> still enabled for some of the PCI devices. For example, the video
>>> controller on 00:01.0 is IRQ 57 and capability [a0] is MSI: Enable+.
>> Yes, for PCI devices it can be checked by verbose lspci. However I still
>> wonder how did You determine that HPET is not using MSI?
> Apologies, omitted that part. With the original default of HPET enabled
> and HpetMsiDis TRUE, the speed was fine. Xen platform timer indicated
> HPET in this case. Devices also still seemed to be using MSI, so I'm not
> sure what that option is supposed to do except slow down my system.
If timer interrupts are not handled properly for some reason (in this
case HPET timer), it is only natural that it will dramatically slow down
the system. The MSI can be working, but may also require some IOAPIC
configuration. Can't say much without any logs from firmware/OS.
>> When You set
>> the HPET option to FALSE, it probably did not touch HPET in AGESA, that
>> is why the speed came back.  I would check whether  HPET is operable for
>> this processor family. For example on Intel Braswell platform HPET was
>> not guaranteed operable in certain conditions.
>>
>> BTW have You tried with family 16h (i.e. PC Engines APU2)?
> Don't have one of those, but wanted to give a (possibly useless) data
> point of my experience at least.
Sorry, I have mistakenly taken You as the initiator of the thread, who
stated he has an APU2 platform. Should have checked the email address first.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: HPET MSI/FSB on AMD 16h

[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 disabled on some platforms by default:
>>>
>>> src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c:
>>>
>>>    TRUE,    // HpetMsiDis
>
> FWIW, I hardcoded the above to FALSE, recompiled, and reflashed my
> f15tn. It caused Qubes to run about half as fast. I checked the logs
> and didn't see any errors to explain why. I then changed it back to
> TRUE and HPET itself to FALSE (and recompiled/reflashed). Normal speed
> came back, XEN Platform timer changed from HPET to ACPI, and MSI is
> still enabled for some of the PCI devices. For example, the video
> controller on 00:01.0 is IRQ 57 and capability [a0] is MSI: Enable+.
Yes, for PCI devices it can be checked by verbose lspci. However I still
wonder how did You determine that HPET is not using MSI? When You set
the HPET option to FALSE, it probably did not touch HPET in AGESA, that
is why the speed came back.  I would check whether  HPET is operable for
this processor family. For example on Intel Braswell platform HPET was
not guaranteed operable in certain conditions.

BTW have You tried with family 16h (i.e. PC Engines APU2)?
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: HPET MSI/FSB on AMD 16h

[Michal Zygowski]

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 capability bits are hardwired to 1.
> I took a quick look through coreboot sources (APU2 firmware is coreboot) and
> noticed something interesting.  It seems that the repository includes code for
> AGESA (src/vendorcode/amd/agesa) and there I see that the MSI capability can 
> be
> turned on / off via a special PM I/O register.  It appears that HPET MSI 
> support
> is disabled on some platforms by default:
>
> src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c:
>   TRUE,// HpetMsiDis
> src/vendorcode/amd/agesa/f16kb/Proc/Fch/Interface/Family/Yangtze/EnvDefYangtze.c:
>   TRUE,// HpetMsiDis
>
> Does anyone know what is a reason for that?
> Are there any hardware errata related to that feature?
> I think that MSI delivery is more efficient and "sexy" than the traditional
> delivery via IO-APIC (although everything is integrated).
>
> Also, is there a way to override that default in a mainboard configuration?
In the BIosCallOuts.c for the platform You could try explicitly set the
HpetMsiDis to FALSE. In function Fch_Oem_config in the AMD_INIT_ENV
try to add:

FchParams->Hpet.HpetEnable = TRUE;
FchParams->Hpet.HpetMsiDis = FALSE;

Maybe it will change anything. Regarding the reasons, it may not be any
particular reason. PC Engines apu2 is initialized with AGESA binary blob
not built from source code, so the code is not fully auditable. It is
likely that the AGESA is not initializing the MSI for HPET. Neither it
is documented in BKDG.
> Thank you.

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: e820 memory map

[Michal Zygowski]

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östi Mälkki wrote:
> On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I.  wrote:
>> Hello, Kyösti!
>> cbmem log in attachment.
>> I am rebooting and/or powering off after upgrading corboot firmware for 
>> verify. It doesn't help, as I remember.
>>
> Logs from both a cold boot and hibernation resume would be needed for
> comparison.
>
> But this pretty much sounds like the case of entering ACPI S4 from a
> boot that did memory training and wrote MRC CACHE in SPI. This is the
> known failing case described earlier.
>
> Kyösti
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: nvramtool and CONFIG_HAVE_OPTION_TABLE (or CONFIG_USE_OPTION_TABLE)

[Michal Zygowski]

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 eligible to be
submitted. Even if the change does not bring anything significant, it
can be still abandoned, so You shouldn't hesitate or be affraid of
pushing patches.

Best regards,
Michał

On 31.05.2019 02:57, ke...@trippers.org wrote:
> A coworker noticed that nvramtool (and the nvramtool man page) both refer to 
> the option CONFIG_HAVE_OPTION_TABLE as the option set to include cmos.layout 
> into the coreboot tables.
>
> nofound_msg_cmos_opt_table[] =
> "%s: Item %s not found in coreboot table.  Apparently, the "
> "coreboot installed on this system was built without specifying "
> "CONFIG_HAVE_OPTION_TABLE.\n";
>
> However, CONFIG_HAVE_OPTION_TABLE is set by the board to indicate whether the 
> board is cmos.layout capable. The actual option is CONFIG_USE_OPTION_TABLE, 
> which depends upon CONFIG_HAVE_OPTION_TABLE. The code in 
> src/lib/coreboot_table.c only adds the lb record to the coreboot tables if 
> CONFIG_USE_OPTION_TABLE is set.
>
> The other choice is to make src/lib/coreboot_table.c add the lb record if the 
> board has a cmos.layout (CONFIG_HAVE_OPTION_TABLE) but then userland will 
> have access to a layout that is ignored. I suppose this is what happens if 
> you set CONFIG_STATIC_OPTION_TABLE. This doesn't seem like the right answer 
> to me.
>
> I think this is only cosmetic, but should I submit a patch to change this so 
> that others are not also sidetracked?
>
> Thanks,
> Kevin
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com




signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: "remote: You need 'Create' rights to create new reference" when pushing to Gerrit

[Michal Zygowski]

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
branch. To fix this, run:

git config remote.origin.push HEAD:refs/for/master

git config branch..remote origin

Then everything should be ok.

Best regards,
Michał

On 27.05.2019 14:58, Peter Lemenkov wrote:
> Hello All,
> It seems that after the switch to a new UI some bits were missed in 
> transition.
>
> Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap): git review
> remote: error: branch refs/publish/master/lenovo_z61t_no_ctrl_swap:
> remote: You need 'Create' rights to create new references.
> remote: User: lemenkov
> remote: Contact an administrator to fix the permissions
> remote:
> remote: Processing changes: refs: 1
> remote: Processing changes: refs: 1, done
> To ssh://review.coreboot.org:29418/coreboot
>  ! [remote rejected]   HEAD ->
> refs/publish/master/lenovo_z61t_no_ctrl_swap (prohibited by Gerrit:
> not permitted: create)
> error: failed to push some refs to
> 'ssh://lemen...@review.coreboot.org:29418/coreboot'
> Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap):
>
> I didn't change anything - so I guess the issue is on the Gerrit's side.

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com



signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: QQ/

[Michal Zygowski]

Hi Alex,

On 30.03.2019 02:40, Alex Feinman wrote:
> DDR RComp calculation is explained in the CPU platform design guide. If you 
> are an Intel licensee, you can request this document by number - 561280 for 
> KBL. There seems to be also a whitepaper you can ask your OEM rep for. 
> The actual values are calculated based on memory topology and board layout 
> and then fine-tuned through measurement. Basically, if you are a system 
> designer, you have the documents and know how to do it, and if you are not, 
> then these values are calculated by the manufacturer/BIOS writer so your only 
> recourse is to find out from them. 

I have the means to access that document. Thank You for pointing it out,
it will be very helpful.
The calculation are probably very complex, but not something I cannot
figure out (hopefully). I would rather solve it by myself and as a last
resort contact board manufacturer when stuck in memory initialization
problems. And if possible and not restricted by NDAs, contribute the
knowledge to raise the experience of whole community.

> Similarly, DQ array is filled according to the information supplied by the 
> system designer. Intel CPUs allow certain freedom in routing the memory pins 
> to simplify the board layout task. The pin map should be filled for DQ/DQS 
> according to the physical connectivity chosen by the system designer. 
>
> Bottom line - it's not something you can figure out by looking at a 
> motherboard

Of course I am aware of that. I have the board schematics, so I know
which pins are swizzled and the reason behind that obviously. Just the
format of bytes for FSP UPD was not clear to me. Nico has pointed some
places where to look for information in coreboot tree. However, I will
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] Re: FSP2.0 DQ byte map
>
> Hi Michal,
>
> 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 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:
>>
>> 1. Why there are more bytes in array than DQ lanes?
> it's actually not an array but a rather complex structure. You can
> find some clues in the Skylake FSP Integration Guide [1] and also
> in coreboot header files [2]. I have no idea why the documentation
> was removed from future guides.
>
>> 2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
> If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that
> it's for memory-down configurations with LPDDR3 only. And, AFAIR, an
> investigation into the deep of the KBL FSP source didn't find any
> relation to DDR4.
>
>> I know about 3 Rcomp resistors of the chipset and what they are for, but
>> what RcompTarget is?
>> In the code I can see function `mainboard_fill_rcomp_strength_data` and
>> begin to wonder what rcomp strength is (not Rcomp Target?). How to
>> correctly fill RcompTarget FSP-M configuration?
> Please tell me if you find out ;) even Intel developers working on
> coreboot don't know. Some insider came back quoting identifiers from
> comments in the FSP header... identifiers nowhere to be found in
> source/documentation.
>
> My guess is that the targets are either computed or even measured by
> some very confidential tool.
>
> Nico
>
> [1]
> https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspIntegrationGuide.pdf
> [2]
> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/include/soc/pei_data.h#n236
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: FSP2.0 DQ byte map

[Michal Zygowski]

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 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:
>>
>> 1. Why there are more bytes in array than DQ lanes?
> it's actually not an array but a rather complex structure. You can
> find some clues in the Skylake FSP Integration Guide [1] and also
> in coreboot header files [2]. I have no idea why the documentation
> was removed from future guides.

I have read the KabyLake FSP Integration guide, but there is only an
information about the values' existence in FSP UPD. Definitely will look
at those files too.

>
>> 2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
> If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that
> it's for memory-down configurations with LPDDR3 only. And, AFAIR, an
> investigation into the deep of the KBL FSP source didn't find any
> relation to DDR4.
Good to know I will not have to bother with it.
>> I know about 3 Rcomp resistors of the chipset and what they are for, but
>> what RcompTarget is?
>> In the code I can see function `mainboard_fill_rcomp_strength_data` and
>> begin to wonder what rcomp strength is (not Rcomp Target?). How to
>> correctly fill RcompTarget FSP-M configuration?
> Please tell me if you find out ;) even Intel developers working on
> coreboot don't know. Some insider came back quoting identifiers from
> comments in the FSP header... identifiers nowhere to be found in
> source/documentation.

I have some clues about it actually. I have found some information after
diving into network abyss.
There is a motherboard manual[3] which gives a tiny bit of explanation
of those RcompTarget values. Here is the fragment from BIOS settings,
Memory Overclocking section, page 89:

RcompTarget[RdOdt]
Enter a value for desired Rcomptarget[RdOdt]. The default is 60.

RcompTarget[WrDS]
Enter a value for desired RcompTarget[WrDS]. The default is 26.

RcompTarget[WrDSCmd]
Enter a value for desired RcompTarget[WrDSCmd]. The default is 20.

RcompTarget[WrDSCtl]
Enter a value for desired RcompTarget[WrDSCtl]. The default is 20.

RcompTarget[WrDSClk]
Enter a value for desired RcompTarget[WrDSClk]. The default is 26.

Interestingly also 5 byte values as defined in FSP UPD. The strings in
square brackets seem to be some DDR standard terms. Maybe someone on the
mailing list would know something about it.

>
> My guess is that the targets are either computed or even measured by
> some very confidential tool.
>
> Nico
>
> [1]
> https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspIntegrationGuide.pdf
> [2]
> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/include/soc/pei_data.h#n236
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Thank You Nico.
Best regards,

[3]
https://www.supermicro.com/manuals/motherboard/X299/MNL-2001.pdf

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] FSP2.0 DQ byte map

[Michal Zygowski]

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:

1. Why there are more bytes in array than DQ lanes?
2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
3. Some FSP2.0 mainboards have values like 0x0F and 0xF0 in their
mappings which looks like 1 byte swap, but there are also 0xCC and 0x33.
What is the difference?

The DQS mapping is clear to me (rather obvious as there are only 8 DQS
which matches the 2x8 array).

I know about 3 Rcomp resistors of the chipset and what they are for, but
what RcompTarget is?
In the code I can see function `mainboard_fill_rcomp_strength_data` and
begin to wonder what rcomp strength is (not Rcomp Target?). How to
correctly fill RcompTarget FSP-M configuration?

Any tips and pointers appreciated.

Regards,

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Michal Zygowski]

On 01.03.2019 11:04, Frans Hendriks wrote:
> Hi Michal,
>
> How about adding both of us as MAINTAINERS for the Braswell patches?
Hi Frans,

Sure, would be glad to cooperate with You. I will submit a patch in a while.
>
> Best regards,
> Frans Hendriks
> Eltan B.V.

Best regards,
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, Michal Zygowski wrote:
>> AFAIK gerrit now adds the reviewers to patches based on MAINTAINERS
>> file. It would be great to be added automatically to Braswell patches.
>> Is there a way to workaround that without being Braswell maintainer?
> you can just push a patch that adds you to the MAINTAINERS file. I don't
> think there is any requirement to be a maintainer, it's just your offer
> to look into things. Please also consider removing stale entries and up-
> dating the status (e.g. from Supported to Maintained, in case you prefer
> that).
>
> You can also set up "Notifications" in Gerrit based on a search pattern.
>
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
>
>
-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Michal Zygowski]

On 28.02.2019 09:52, Matt DeVillier wrote:
> hi Frans,
>
> I'm happy to review these patches (and think I have for some already),
> but as my Braswell-based ChromeOS boards don't require them, a little
> more explanation in the commit msgs as to what issue they are
> resolving would be helpful in that regard.  Obviously I'd like to test
> them and ensure no regressions for my boards as well
Hi Matt,

I have added some comments to these patches. As ChromeOS may not require
them (and I am aware of that since I worked once with Chromebook), the
SeaBIOS payload have problems (especially with interrupts and keyboard
input) and other operating systems complain. We are awaiting for Your
review.

I have added short comments on few of these patches. Feel free to ask
questions under the patches, I will hopefully give satisfying answers.

>
> cheers,
> Matt
Best regards,
Michał
>
> On Thu, Feb 28, 2019 at 2:42 AM Frans Hendriks  <mailto:fhendr...@eltan.com>> wrote:
>
> An additional question related to this SoC and new mainboards:
> Should maintainer of Braswell SoC also take care of review/merge
> new mainboards based on this chipset?
>
> Who should merge new boards?
> (I have uploaded code for two mainboards based on this SoC, where
> 1 is waiting 3 months to be merged?)
>
> Best regards,
> Frans Hendriks
> Eltan B.V.
>
> -Original Message-
> 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@coreboot.org>
> Subject: [coreboot] Re: Intel Braswell uploads
>
> 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 any incoming patches to Braswell SoC code
> base.
> > We would be glad to become the maintainers. Would like to hear Your
> > opinions, dear coreboot developers/maintainers, what do You think
> > about the change?
>
> Hi Michal,
> I'm glad to see that you want to maintain an additional platform.
>
> I recommend to email all maintainers, that are not known to be
> active, as part of the half year release process. If you don't get
> a response or a bounce message the platform should be marked as
> unmaintained.
>
> What do you think about adding a "supporters section" to the start
> page of https://coreboot.org/ to ackknowledge companies that
> really maintain coreboot code.
>
> Regards,
> --
> Patrick Rudolph
>
> 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email:  patrick.rudo...@9elements.com
> <mailto:patrick.rudo...@9elements.com>
> Phone:  +49 234 68 94 188
>
> Sitz der Gesellschaft: Bochum
> Handelsregister: Amtsgericht Bochum, HRB 17519
> Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
> ___
> coreboot mailing list -- coreboot@coreboot.org
> <mailto:coreboot@coreboot.org> To unsubscribe send an email to
> coreboot-le...@coreboot.org <mailto:coreboot-le...@coreboot.org>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> <mailto:coreboot@coreboot.org>
> To unsubscribe send an email to coreboot-le...@coreboot.org
> <mailto:coreboot-le...@coreboot.org>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Michal Zygowski]

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 any incoming patches to Braswell SoC
>> code base. We would be glad to become the maintainers. Would like to
>> hear Your opinions, dear coreboot developers/maintainers, what do You
>> think about the change?
> Hi Michal,
> I'm glad to see that you want to maintain an additional platform.
Hi Patrick,
> I recommend to email all maintainers, that are not known to be active,
> as part of the half year release process. If you don't get a response
> or a bounce message the platform should be marked as unmaintained.
>
> What do you think about adding a "supporters section" to the start page
> of https://coreboot.org/ to ackknowledge companies that really maintain
> coreboot code.
Sounds good. Fine for me as a temporary solution.
AFAIK gerrit now adds the reviewers to patches based on MAINTAINERS
file. It would be great to be added automatically to Braswell patches.
Is there a way to workaround that without being Braswell maintainer?
>
> Regards,
Best regards,
Michał

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Michal Zygowski]

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 patches on 3 different Braswell
SoCs, so I am going to give +2. IMO it is pointless to wait for response
from maintainers, taking into consideration that they are not working in
Intel anymore.

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 any incoming patches to Braswell SoC code base.
We would be glad to become the maintainers. Would like to hear Your
opinions, dear coreboot developers/maintainers, what do You think about
the change?

Best regards,
Michał

On 27.02.2019 10:00, Lance Zhao wrote:
> She's not working at Intel any more, so I don't think there will be
> response there.
>
> On Wed, Feb 27, 2019 at 4:00 PM Frans Hendriks  > wrote:
>
> Hi,
>
> Still no  response from MAINTAINERS.
>
> Is there a way have to trigger review/merge/reply?
> Or just keep waiting?
>
> Best regards,
> Frans
>
> -Original Message-
> From: Angel Pons [mailto:th3fan...@gmail.com
> ]
> Sent: vrijdag 1 februari 2019 11:13
> To: Frans Hendriks mailto:fhendr...@eltan.com>>
> Cc: coreboot@coreboot.org ;
> hannah.willi...@intel.com 
> Subject: Re: [coreboot] Intel Braswell uploads
>
> Hello,
>
> On Fri, Feb 1, 2019 at 10:53 AM Frans Hendriks
> mailto:fhendr...@eltan.com>> wrote:
> >
> > Hi,
> >
> > I'm working on Intel Braswell implementation and uploaded
> several patches.
> >
> > It seems that the maintainer of the Intel Braswell is not active
> for review/merge/reply of the uploads.
> > Is the maintainer in MAINTAINERS document correct and still active?
> >
> > Met vriendelijke groet / Best regards,
> > Frans Hendriks
> > Eltan B.V.
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> 
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> 
>
> There are mail addresses on MAINTAINERS. I CC'd this message to the
> maintainer for braswell so that they can reply to it.
>
> Best regards,
>
> Angel Pons
>
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> 
> To unsubscribe send an email to coreboot-le...@coreboot.org
> 
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org