Hi Bin,
On Mon, 2 Dec 2019 at 07:22, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Nov 25, 2019 at 12:12 PM Simon Glass sjg@chromium.org wrote:
The memory and silicon init parts of the FSP need support code to work. Add this for Apollo Lake.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
- Allocate the FSP-S data instead of using the stack
- Rename APOLLOLAKE_USB2_PORT_MAX
Changes in v4:
- Adjust the comment for struct dw_i2c_speed_config
- Rename arch_fsp_s_preinit() to arch_fsps_preinit()
- Switch over to use pinctrl for pad init/config
- Tidy up mixed case in FSP code
- apollolake -> Apollo Lake
Changes in v3:
- Add bootstage timing for reading vbt
- Add fspm_done() hook to handle FSP-S wierdness (it breaks SPI flash)
- Don't allow BOOT_FROM_FAST_SPI_FLASH with FSP-S
- Set boot_loader_tolum_size to 0
- Use the IRQ uclass instead of ITSS
Changes in v2: None
arch/x86/cpu/apollolake/Makefile | 6 + arch/x86/cpu/apollolake/fsp_m.c | 210 ++++++++++ arch/x86/cpu/apollolake/fsp_s.c | 667 +++++++++++++++++++++++++++++++ 3 files changed, 883 insertions(+) create mode 100644 arch/x86/cpu/apollolake/fsp_m.c create mode 100644 arch/x86/cpu/apollolake/fsp_s.c
[..]
I never imagined even using FSP, the initialization of a SoC platform could still be such complex! Either FSP was designed with something wrong, or we are not doing correctly ...
Well this is just configuration mostly, apart from the power limit stuff. Intel SoCs are pretty complex.
Regards, SImon