Re: [coreboot] Kaby Lake FSP
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:kakar...@kakaroto.homelinux.net] Sent: Wednesday, July 25, 2018 3:40 PM To: Desimone, Nathaniel L Cc: coreboot 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 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:kakar...@kakaroto.homelinux.net] > Sent: Monday, July 16, 2018 12:29 PM > To: Desimone, Nathaniel L > Cc: coreboot > 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 > 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@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
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 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:kakar...@kakaroto.homelinux.net] > Sent: Monday, July 16, 2018 12:29 PM > To: Desimone, Nathaniel L > Cc: coreboot > 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 > 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@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Doubts about link scripts
> 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. There is no data segment for bootblock/romstage on x86. You are not allowed to use global (or static local) variables. The build system will enforce this. You can see that https://review.coreboot.org/cgit/coreboot.git/tree/src/arch/x86/include/arch/memlayout.h defines ARCH_STAGE_HAS_DATA_SECTION and ARCH_STAGE_HAS_BSS_SECTION to 0, so the .data and .bss sections in https://review.coreboot.org/cgit/coreboot.git/tree/src/lib/program.ld get removed by the preprocessor. There is the special mechanism of a CAR_GLOBAL variable which needs to be marked as such in the code and only accessed through the car_get_var()/car_set_var() macros (from https://review.coreboot.org/cgit/coreboot.git/tree/src/arch/x86/include/arch/early_variables.h). They are placed in a special section that gets linked to the CAR address space by the https://review.coreboot.org/cgit/coreboot.git/tree/src/arch/x86/car.ld script. On other architectures (like Arm), we don't have any systems that execute directly from flash (yet). We always load code and data into SRAM before executing so they can be contiguous in there. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
