Hi Simon,
On 05/28 10:30, Simon Glass wrote:
Hi Andrew,
On 27 May 2015 at 08:39, Andrew Bradford andrew@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-archit...
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