Hi Simon, On 05/28 10:30, Simon Glass wrote: > Hi Andrew, > > On 27 May 2015 at 08:39, Andrew Bradford <and...@bradfordembedded.com> wrote: > > On 05/27 13:19, Bin Meng wrote: > >> Hi Simon,
------------->8-------------- > >> I just noticed that Intel has released FSP specification v1.1 [1] in > >> April. After a rough read of the 1.1 spec, it looks to me that Intel > >> changed the fsp_init() design by breaking it down into 3 sub-routines: > >> FspMemoryInit(), TempRamExit() and FspSiliconInit(). I feel this might > >> be more logical to adapt U-Boot, but again I am not sure if the stack > >> migration stuff is still there. So far I don't see any new FSP > >> releases using the 1.1 spec. > >> > >> [1] > >> https://www-ssl.intel.com/content/www/us/en/embedded/software/fsp/fsp-architecture-spec-v1-1.html > > > > There's also a very good overview of how to use an FSP v1.1 firmware at > > [1]. It states that the problem in v1.0 for bootloaders was that when > > you call FspInit() that temporary ram was torn down unconditionally. > > Now, in v1.1, it says after calling FspMemoryInit() that control will be > > given back to the bootloader running in the temporary ram (CAR?). Then > > the bootloader is responsible for migrating to main memory and to call > > TempRamExit() so that temporary memory can be cleaned up. > > > > This sounds like what u-boot would want and what Simon described above, > > for u-boot to be in charge of relocating from CAR to main memory, right? > > If so, likely things will be much easier once there's a v1.1 FSP for > > baytrail... > > > > Indeed, care to ping them to find out when this might happen? It seems like there are no current plans to implement an FSP v1.1 compliant firmware release for Bay Trail [1], which is unfortunate. [1]:https://embedded.communities.intel.com/thread/8218 I will continue to pester my contacts at Intel. Thanks, Andrew _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot