Hi Patrick,
The distribution permissions granted in section 2.1 (b) and (c) are only granted for internal distribution. So, they can only be used to distribute the FSP binary to other people that are within the same legal entity (such as a corporation, partnership, agency, etc.) that you are in. The only external distribution rights are those granted by section 2.1 (e) and (f), both of which require that FSP has already been embedded into the final coreboot ROM binary. Since the coreboot blobs repo is publicly accessible it would count as external distribution, which is disallowed by the FSP license.
However, there is nothing in the license that prevents you from providing links to github.com/IntelFsp. It might not be exactly what you were hoping for but would adding a git submodule in coreboot blobs that points to github.com/IntelFsp suffice? Alternatively, I suspect it is feasible to setup the repo tool to pull github.com/IntelFsp at the same time it pulls the coreboot repo.
Thanks,
Nate
From: Patrick Georgi <pgeorgi(a)google.com>
Date: Tuesday, July 10, 2018 at 11:38 PM
To: "Desimone, Nathaniel L" <nathaniel.l.desimone(a)intel.com>
Cc: coreboot <coreboot(a)coreboot.org>
Subject: Re: [coreboot] Kaby Lake FSP
Nate, thank you for getting these things out and for the public update!
Could you please ask the lawyers if they consider 2.1 (b) and (c) of the license sufficient for unmodified redistribution (eg in the coreboot blobs repo: paths change, the files remain unmodified)? It seems like that should be possible, but since I'm just a software developer and they're the lawyers who wrote the license they ought to know.
That would make it easier to create FSP based configurations that build out of the box with the coreboot tree.
Thanks,
Patrick
Am Mi., 11. Juli 2018 um 03:06 Uhr schrieb Desimone, Nathaniel L <mailto:nathaniel.l.desimone@intel.com>:
Hi All,
I am a UEFI firmware architect working for Intel Corp. One of my focus areas is FSP. There was some prior discussion here regarding the lack of public updates for Kaby Lake FSP binaries and headers and questions regarding specialized FSP binaries being built for specific boards. I would like to clear up some of these questions and concerns. We just pushed all of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be forks of Kaby Lake FSP, they are actually just snapshots at different points in time. For example, there is one commit labelled as "Gold release for Kaby Lake FSP" that appears to be special fork for IoT devices... this commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT specific modifications. Apologies for the confusing commit messages and for the temporary lapse in updates.
With Best Regards,
Nate
--
coreboot mailing list: mailto:coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Hi all
See [1]
> terpstraWesley W. TerpstraVerified SiFive Account
> 2d
>
> I saw a few posts on the internet, which misrepresented what I was expressing. I never suggested reverse engineering our partner’s IP!
>
> SiFive is committed to supporting the open-source community. We are pleased to report that after discussions with our IP partners, we are now able to make available all the source code required to initialize the HiFive Unleashed board. The board’s boot sequence is described in the manual. The assembly code in the initial reset ROM is listed in the manual Chapter 6.1 “Reset Vector”. The firmware in the ZSBL mask ROM is directly readable by software on the chip, and we will be making the full source code available shortly. The source code for FSBL including the DDR initialization will also be available shortly. We can attest there is no other firmware run by the system during boot.
And yes there is at least a chapter 20.3 Reset and Initialization in [2], which boils down of taking stuff out of reset, programming clocks and sets all values.
Thanks
Rudolf
[1] https://forums.sifive.com/t/ddr-controller-configuration-register-values-...
[2] https://static.dev.sifive.com/FU540-C000-v1.0.pdf now.
My system Baytrail E3845:
DisplayPort audio in Linux works fine but in Windows is not detected.
I am sure that the OS has the proper graphics drivers because DP Audio works with original BIOS in the same HDD Windows OS.
Anyone could give me a hint?
Thank you,
J. Trujillo.
I am try to read the code that cache-as-ram of bootblock stage. And found that just cleared the memory and did not initialize the data segment code.
So, I want to ask : "Whether coreboot has restrictions on the bootblock program, cannot use static variables with initial values."
Looking forward to your reply！Thank you!
XiangWang
Nate, thank you for getting these things out and for the public update!
Could you please ask the lawyers if they consider 2.1 (b) and (c) of the
license sufficient for unmodified redistribution (eg in the coreboot blobs
repo: paths change, the files remain unmodified)? It seems like that should
be possible, but since I'm just a software developer and they're the
lawyers who wrote the license they ought to know.
That would make it easier to create FSP based configurations that build out
of the box with the coreboot tree.
Thanks,
Patrick
Am Mi., 11. Juli 2018 um 03:06 Uhr schrieb Desimone, Nathaniel L <
nathaniel.l.desimone(a)intel.com>:
> Hi All,
>
> I am a UEFI firmware architect working for Intel Corp. One of my focus
> areas is FSP. There was some prior discussion here regarding the lack of
> public updates for Kaby Lake FSP binaries and headers and questions
> regarding specialized FSP binaries being built for specific boards. I would
> like to clear up some of these questions and concerns. We just pushed all
> of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to
> https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear
> to be forks of Kaby Lake FSP, they are actually just snapshots at different
> points in time. For example, there is one commit labelled as "Gold release
> for Kaby Lake FSP" that appears to be special fork for IoT devices... this
> commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT
> specific modifications. Apologies for the confusing commit messages and for
> the temporary lapse in updates.
>
> With Best Regards,
>
> Nate
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Awesome Thanks!
Can you tell me what the state is with vboot for a x220 is (as an example)?
I did ask in the IRC and someone told me, that there is some work done
on this topic. Also that no code contribution are necessary, but rather
review (and testing I guess).
>From what I have seen in the code only google based laptop are supported
for vboot. More might be possible, but I wasn't able to quickly identify
them all.
>From what I have seen on the review pages, most changes there for vboot
should not affect the x220, or do I get it wrong?
Thank you everyone for reading, best regards
akendo
On 06/29/2018 08:20 PM, David Hendricks wrote:
> On Fri, Jun 29, 2018 at 8:34 AM, Akendo <akendo(a)akendo.eu> wrote:
>>
>> Hey everyone,
>>
>> I'm reading through the source code and found vboot. It should standing
>> for verified boot. However I can't find any documentation(except the
>> source code). Can anyone provide me with some explanation how to get it
>> going or to make a little more sense of it?
>>
>> As far as I understand it needs to verify the signature against a
>> Key/CA. This key should be located within the TPM. But how should the
>> key/CA look like? Will be a classic x509 be enough?
>
>
> Hi Akendo,
> Here is some more background on vboot:
> https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
> https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot...
>
> In this schema usually the public key is stored in a write-protected
> region of the firmware ROM. You can store it anywhere you want so long
> as you can guarantee that it can't be tampered with in an undesirable
> way.
>
Hi All,
I am a UEFI firmware architect working for Intel Corp. One of my focus areas is FSP. There was some prior discussion here regarding the lack of public updates for Kaby Lake FSP binaries and headers and questions regarding specialized FSP binaries being built for specific boards. I would like to clear up some of these questions and concerns. We just pushed all of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be forks of Kaby Lake FSP, they are actually just snapshots at different points in time. For example, there is one commit labelled as "Gold release for Kaby Lake FSP" that appears to be special fork for IoT devices... this commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT specific modifications. Apologies for the confusing commit messages and for the temporary lapse in updates.
With Best Regards,
Nate
Jorge Fernandez Monteagudo wrote:
> !!!! X64 Exception Type - 00(#DE - Divide Error) CPU Apic ID - 00000010 !!!!
So there is probably a division by zero..
> RIP - 000000008F5D4FCB
> !!!! Find PE image /mnt/develop/bettong/coreboot/master/coreboot_tpm2/payloads/external/tianocore/tianocore/Build/CorebootPayloadPkgX64/RELEASE_COREBOOT/X64/CorebootPayloadPkg/FbGop/FbGop/DEBUG/FbGop.dll
> (ImageBase=000000008F5D4000, EntryPoint=000000008F5D5F7D) !!!!
..at byte 0xfcb=4043 in FbGop.dll.
> When configured with 800x600 32k-color (1:5:5:5) or 800x600 64k-color (5:6:5)
> boots ok.
Look for assumptions (all assumptions are bad) about frame buffer size or
structure in the code. I guess some code tries to compute number of bytes
per pixel but doesn't always get correct results.
//Peter
