Thank you Ron,
Just curious, about who could be the originator of this "future OS requirement", but I guess that anyone can guess his identity.. ;-)
Anyway is good to see that common sense prevails (SMM dies) .. finally .. but I fear that the "clients" that until now were dependent of this kind of service will "migrate" to another "service provider".. (give me a "M", give me a "E", .. oh nevermind.. sorry just jocking .. lets not start another flame war.. ;-))
Florentin
----- Mail d'origine -----
De: ron minnich <rminnich(a)gmail.com>
À: coreboot <coreboot(a)coreboot.org>
Envoyé: Sun, 29 Jul 2018 23:54:19 +0200 (CEST)
Objet: [coreboot] restrict SMI
Florentin wrote this:
I just peeked inside the pdf and tumbled upon the following statement
(page4):
"The latest reasoning for replacement of SMI is driven by a future OS
requirement that
restricts the use of SMI as a means to communicate with the system
firmware."
Can someone enlighten me what this "future OS requirement" means?..
Thanks in advance,
Florentin
OK, the future OS requirement is not complicated in my view. Nobody trusts
SMM, or should ever have trusted SMM from the beginning, and many companies
have reached the decision that SMM is a monstrous security hole and must
die. SMI being the way one gets into SMM, both SMI and SMM are, we hope,
soon to be a thing of the past. Not soon enough for me ...
ron
Florentin wrote this:
I just peeked inside the pdf and tumbled upon the following statement
(page4):
"The latest reasoning for replacement of SMI is driven by a future OS
requirement that
restricts the use of SMI as a means to communicate with the system
firmware."
Can someone enlighten me what this "future OS requirement" means?..
Thanks in advance,
Florentin
OK, the future OS requirement is not complicated in my view. Nobody trusts
SMM, or should ever have trusted SMM from the beginning, and many companies
have reached the decision that SMM is a monstrous security hole and must
die. SMI being the way one gets into SMM, both SMI and SMM are, we hope,
soon to be a thing of the past. Not soon enough for me ...
ron
On 2018-07-29 06:39 PM, Alexander Couzens wrote:
> Hi Patrick,
>
> thanks for your work.
> Are there any documentation or description what Mailbox 3 support is?
> Where it come from?
>
It's documented here:
https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
> Best,
> lynxis
Dear coreboot users,
The following commit adds Mailbox 3 support for improved panel back-
light brigthness control on Intel GMA platforms.
It fixes the problem with 100% brightness on S3 resume.
Please test and review https://review.coreboot.org/#/c/coreboot/+/27711
/
Regards,
Patrick
Hi Youness,
Per your specific question, I am working through the laundry list of approvals to publish Coffee Lake binaries right now. Its "in the works." I'll post an announcement once it is up.
Thanks,
Nate
-----Original Message-----
From: Youness Alaoui [mailto:kakaroto@kakaroto.homelinux.net]
Sent: Wednesday, July 25, 2018 3:40 PM
To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com>
Cc: coreboot <coreboot(a)coreboot.org>
Subject: Re: [coreboot] Kaby Lake FSP
Great, thanks!
I understand that as platform ages, it gets less development, I was mostly asking because I saw that coffeelake FSP headers are in coreboot but there are no FSP images for coffeelake on github yet, which is basically the same/similar issue as what we complained about with regards to Kabylake, and your answer was only about Kabylake, so I was hoping other platforms are "in the works" for being kept up to date between public and "internal" releases.
Thanks,
Youness.
On Wed, Jul 18, 2018 at 8:05 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote:
>
> Hi Youness,
>
> In general yes, Intel does plan to continue developing of FSP for future platforms. We will make a good faith effort to keep the publically posted FSP binary freshly updated. I would like to caution that as a platform ages, our internal development shifts to newer ones. Accordingly, I would expect the frequency of FSP releases to lengthen as a platform ages.
>
> Thanks,
> Nate
>
> -----Original Message-----
> From: Youness Alaoui [mailto:kakaroto@kakaroto.homelinux.net]
> Sent: Monday, July 16, 2018 12:29 PM
> To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com>
> Cc: coreboot <coreboot(a)coreboot.org>
> Subject: Re: [coreboot] Kaby Lake FSP
>
> Hi Nate,
>
> Thanks a lot for listening to our request and taking care of this! I'm happy to see the binaries finally updated and the FSP headers in coreboot having a matching publicly available binary to use.
> You've only mentioned Kabylake in your email, is it safe to assume that you'll use these same practices for future platforms as well ?
>
> Thanks,
> Youness.
> On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote:
> >
> > 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
Great, thanks!
I understand that as platform ages, it gets less development, I was
mostly asking because I saw that coffeelake FSP headers are in
coreboot but there are no FSP images for coffeelake on github yet,
which is basically the same/similar issue as what we complained about
with regards to Kabylake, and your answer was only about Kabylake, so
I was hoping other platforms are "in the works" for being kept up to
date between public and "internal" releases.
Thanks,
Youness.
On Wed, Jul 18, 2018 at 8:05 PM Desimone, Nathaniel L
<nathaniel.l.desimone(a)intel.com> wrote:
>
> Hi Youness,
>
> In general yes, Intel does plan to continue developing of FSP for future platforms. We will make a good faith effort to keep the publically posted FSP binary freshly updated. I would like to caution that as a platform ages, our internal development shifts to newer ones. Accordingly, I would expect the frequency of FSP releases to lengthen as a platform ages.
>
> Thanks,
> Nate
>
> -----Original Message-----
> From: Youness Alaoui [mailto:kakaroto@kakaroto.homelinux.net]
> Sent: Monday, July 16, 2018 12:29 PM
> To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com>
> Cc: coreboot <coreboot(a)coreboot.org>
> Subject: Re: [coreboot] Kaby Lake FSP
>
> Hi Nate,
>
> Thanks a lot for listening to our request and taking care of this! I'm happy to see the binaries finally updated and the FSP headers in coreboot having a matching publicly available binary to use.
> You've only mentioned Kabylake in your email, is it safe to assume that you'll use these same practices for future platforms as well ?
>
> Thanks,
> Youness.
> On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote:
> >
> > 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
I try to read link scripts of coreboot.
In addition to the x86 platform, code segments and data segments are contiguous during the bootblock/romstage phase.
However, only CAR/SRAM can be used as memory in the bootblock/romstage stage, this should be separate from the flash where the program is located.
Why this is not reflected in the link script？
Does the machine have a special mechanism ?
Looking forward to your reply !!!
WangXiang
Hello Jose,
On Mon, Jul 23, 2018 at 5:23 AM, Jose Trujillo via coreboot
<coreboot(a)coreboot.org> wrote:
> Dear coreboot developers:
>
> I am trying to create CB firmware for Broadwell-D 1559 system using
> CamelBack Mountain CRB as mainboard selection, and the system boots Windows
> and Linux operating systems but USB keyboard and mouse doesn't work.
>
> I already enable/disabled EHCI/xHCI devices in devicetree without success.
> I tried Seabios and Tianocore without success.
>
> Anyone had experience this issue?
EHCI support may need to be enabled in FSP. What version of coreboot
are you using? I added a Kconfig option to enable the EHCI controllers
using UPD values: https://review.coreboot.org/c/coreboot/+/26042
> Any advise will be appreciated.
> Thank you,
> Jose Trujillo.
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
On Sun, Jul 22, 2018 at 11:50 PM, zahra rahimkhani
<zrahimkhani2014(a)gmail.com> wrote:
> Thank you very much.
> I compiled coreboot and seabios and got Microcode and Fsp on it.
> But I did not have output on serial port.
> Could you tell me How set menuconfig that see outpot on serial port.
> Thanks,
It would be helpful if you can upload your .config somewhere such as
paste.flashrom.org.
My guess is that you don't have CONFIG_ENABLE_BUILTIN_COM1 selected
(under "Chipset"), which is an option you have to set in addition to
the stuff under "Console."
>
> On Mon, Jul 23, 2018 at 10:58 AM David Hendricks <david.hendricks(a)gmail.com>
> wrote:
>>
>> Hi Zahra,
>>
>> On Mon, Jul 23, 2018 at 4:49 AM, zahra rahimkhani
>> <zrahimkhani2014(a)gmail.com> wrote:
>> > Dear friends
>> >
>> > I compile seaBios and coreboot for Minnowboard max .
>> > but I do not see output on Serial port .
>> >
>> > Does coreboot support USB to Serial Converters ?
>> > or how do I add this feature ?
>>
>> The Minnowboard Max serial port does not go thru a USB to serial
>> converter. However, you may need to enable some config options.
>> Compare a sample config.txt from the supported mainboards page
>> (https://coreboot.org/status/board-status.html) to your .config file
>> to see if there is anything obviously missing.
>>
>> Also, do you have the microcode files from Intel? If not, you can
>> download them from
>> https://downloadmirror.intel.com/25063/eng/Baytrail_FSP_Gold4.tgz.
>>
>>
>> >
>> > Thanks ,
>> >
>> >
>> > --
>> > coreboot mailing list: coreboot(a)coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
