| Message ID | A1484485FD99714DB2AB2C5EF81E7AC2AA746889@ORSMSX116.amr.corp.intel.com |
|---|---|
| State | Superseded |
| Delegated to: | Bin Meng |
| Headers | show |
| Series | x86: Add basic Slim Bootloader payload support | expand |
On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden <aiden.park@intel.com> wrote: > > Add slimbootloader board to run U-boot as a Slim Bootloader payload > - Add new board/intel/slimbootloader directory with minimum codes > - Add slimbootloader configuration files > - Add README in board/intel/slimbootloader > board/intel/slimbootloader/README | 133 ++++++++++++++++++++ Shouldn't become reST one? > +Stitch IFWI: > + Refer to https://slimbootloader.github.io/supported-hardware/apollo-lake-crb.html#stitching. > + > python Platform/ApollolakeBoardPkg/Script/StitchLoader.py -i <Existing IFWI> -s Outputs/apl/Stitch_Components.zip -o <Output IFWI> It reminds me that DnX protocol. > +Flash IFWI: > + Use DediProg to flash IFWI. > + Now, you should reach at U-Boot serial console. Can't it be done via DFU? > +int board_early_init_r(void) > +{ > + /* > + * Make sure PCI bus is enumerated so that peripherals on the PCI bus > + * can be discovered by their drivers > + */ > + pci_init(); I'm not sure this is how U-Boot is designed with DM. At least my expectations that bus gets initialized followed by the certain driver in a lazy way. Isn't it the case? Bin? > + > + return 0; > +} > +++ b/board/intel/slimbootloader/start.S > @@ -0,0 +1,9 @@ > +/* board early initialization */ > +.globl early_board_init > +early_board_init: > + jmp early_board_init_ret Do you need this stub at all? How other CPUs work without it? > +++ b/include/configs/slimbootloader.h > @@ -0,0 +1,59 @@ > +#undef CONFIG_NFSBOOTCOMMAND > +#undef CONFIG_RAMBOOTCOMMAND > +#undef CONFIG_EXTRA_ENV_SETTINGS > +#undef CONFIG_BOOTCOMMAND Do we really need all these in the header? Can't some at least be done via configuration? > +#ifdef CONFIG_SYS_NS16550_MEM32 > +#undef CONFIG_SYS_NS16550_PORT_MAPPED > +#endif
Hi Andy, On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden <aiden.park@intel.com> wrote: > > > > Add slimbootloader board to run U-boot as a Slim Bootloader payload > > - Add new board/intel/slimbootloader directory with minimum codes > > - Add slimbootloader configuration files > > - Add README in board/intel/slimbootloader > > > board/intel/slimbootloader/README | 133 ++++++++++++++++++++ > > Shouldn't become reST one? I think this will need be converted to reST after my doc series are applied. > > > +Stitch IFWI: > > + Refer to https://slimbootloader.github.io/supported-hardware/apollo-lake-crb.html#stitching. > > + > python Platform/ApollolakeBoardPkg/Script/StitchLoader.py -i <Existing IFWI> -s Outputs/apl/Stitch_Components.zip -o <Output IFWI> > > It reminds me that DnX protocol. > > > +Flash IFWI: > > + Use DediProg to flash IFWI. > > + Now, you should reach at U-Boot serial console. > > Can't it be done via DFU? > > > +int board_early_init_r(void) > > +{ > > + /* > > + * Make sure PCI bus is enumerated so that peripherals on the PCI bus > > + * can be discovered by their drivers > > + */ > > + pci_init(); > > I'm not sure this is how U-Boot is designed with DM. > At least my expectations that bus gets initialized followed by the > certain driver in a lazy way. > Isn't it the case? Bin? For most x86 board, yes, PCI gets enumerated automatically if some PCI APIs are called in the early initialization codes: eg: pci_{read, write}_config(). But for boards like coreboot/slimbootloader, if there is no touch to any PCI config register on that board in the early phase, PCI bus remains not probed. > > > + > > + return 0; > > +} > > > > +++ b/board/intel/slimbootloader/start.S > > @@ -0,0 +1,9 @@ > > > +/* board early initialization */ > > +.globl early_board_init > > +early_board_init: > > + jmp early_board_init_ret > > Do you need this stub at all? How other CPUs work without it? This hook is currently needed by every board. > > > +++ b/include/configs/slimbootloader.h > > @@ -0,0 +1,59 @@ > > > +#undef CONFIG_NFSBOOTCOMMAND > > +#undef CONFIG_RAMBOOTCOMMAND > > +#undef CONFIG_EXTRA_ENV_SETTINGS > > +#undef CONFIG_BOOTCOMMAND > > Do we really need all these in the header? > Can't some at least be done via configuration? I suspect not all of these are converted to Kconfig yet. Regards, Bin
On Tue, Jul 23, 2019 at 9:15 AM Bin Meng <bmeng.cn@gmail.com> wrote: > On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden <aiden.park@intel.com> wrote: > > > board/intel/slimbootloader/README | 133 ++++++++++++++++++++ > > > > Shouldn't become reST one? > > I think this will need be converted to reST after my doc series are applied. I had an impression that reST conversion is targeting 2019.10. It means in your branch you will have it applied earlier. > > > +int board_early_init_r(void) > > > +{ > > > + /* > > > + * Make sure PCI bus is enumerated so that peripherals on the PCI bus > > > + * can be discovered by their drivers > > > + */ > > > + pci_init(); > > > > I'm not sure this is how U-Boot is designed with DM. > > At least my expectations that bus gets initialized followed by the > > certain driver in a lazy way. > > Isn't it the case? Bin? > > For most x86 board, yes, PCI gets enumerated automatically if some PCI > APIs are called in the early initialization codes: eg: pci_{read, > write}_config(). > > But for boards like coreboot/slimbootloader, if there is no touch to > any PCI config register on that board in the early phase, PCI bus > remains not probed. Thanks for explanation! Perhaps this needs a comment in the code.
Hi Andy, > -----Original Message----- > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > Sent: Tuesday, July 23, 2019 5:27 AM > To: Bin Meng <bmeng.cn@gmail.com> > Cc: Park, Aiden <aiden.park@intel.com>; U-Boot Mailing List <u- > boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > Subject: Re: [PATCH v5 7/8] board: intel: Add new slimbootloader board > > On Tue, Jul 23, 2019 at 9:15 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden <aiden.park@intel.com> wrote: > > > > > board/intel/slimbootloader/README | 133 ++++++++++++++++++++ > > > > > > Shouldn't become reST one? > > > > I think this will need be converted to reST after my doc series are applied. > > I had an impression that reST conversion is targeting 2019.10. It means in your > branch you will have it applied earlier. > Let me change this to reST if necessary. Hi Bin, do you want me to change this one to reST or later? Let me know. > > > > +int board_early_init_r(void) > > > > +{ > > > > + /* > > > > + * Make sure PCI bus is enumerated so that peripherals on the PCI bus > > > > + * can be discovered by their drivers > > > > + */ > > > > + pci_init(); > > > > > > I'm not sure this is how U-Boot is designed with DM. > > > At least my expectations that bus gets initialized followed by the > > > certain driver in a lazy way. > > > Isn't it the case? Bin? > > > > For most x86 board, yes, PCI gets enumerated automatically if some PCI > > APIs are called in the early initialization codes: eg: pci_{read, > > write}_config(). > > > > But for boards like coreboot/slimbootloader, if there is no touch to > > any PCI config register on that board in the early phase, PCI bus > > remains not probed. > > Thanks for explanation! > Perhaps this needs a comment in the code. > Thanks Bin for your explanation. Slim Bootloader have done PCI config space setup and PCI device enumeration in Slim Bootloader stages. > -- > With Best Regards, > Andy Shevchenko Best Regards, Aiden
Hi Aiden, On Wed, Jul 24, 2019 at 11:18 AM Park, Aiden <aiden.park@intel.com> wrote: > > Hi Andy, > > > -----Original Message----- > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > > Sent: Tuesday, July 23, 2019 5:27 AM > > To: Bin Meng <bmeng.cn@gmail.com> > > Cc: Park, Aiden <aiden.park@intel.com>; U-Boot Mailing List <u- > > boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > > Subject: Re: [PATCH v5 7/8] board: intel: Add new slimbootloader board > > > > On Tue, Jul 23, 2019 at 9:15 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko > > > <andy.shevchenko@gmail.com> wrote: > > > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden <aiden.park@intel.com> wrote: > > > > > > > board/intel/slimbootloader/README | 133 ++++++++++++++++++++ > > > > > > > > Shouldn't become reST one? > > > > > > I think this will need be converted to reST after my doc series are applied. > > > > I had an impression that reST conversion is targeting 2019.10. It means in your > > branch you will have it applied earlier. > > > Let me change this to reST if necessary. > Hi Bin, do you want me to change this one to reST or later? Let me know. I have no preference. You can either convert to reST later, or rebase on top of this series to get it converted to reST now: http://patchwork.ozlabs.org/project/uboot/list/?series=120139 > > > > > > +int board_early_init_r(void) > > > > > +{ > > > > > + /* > > > > > + * Make sure PCI bus is enumerated so that peripherals on the PCI bus > > > > > + * can be discovered by their drivers > > > > > + */ > > > > > + pci_init(); > > > > > > > > I'm not sure this is how U-Boot is designed with DM. > > > > At least my expectations that bus gets initialized followed by the > > > > certain driver in a lazy way. > > > > Isn't it the case? Bin? > > > > > > For most x86 board, yes, PCI gets enumerated automatically if some PCI > > > APIs are called in the early initialization codes: eg: pci_{read, > > > write}_config(). > > > > > > But for boards like coreboot/slimbootloader, if there is no touch to > > > any PCI config register on that board in the early phase, PCI bus > > > remains not probed. > > > > Thanks for explanation! > > Perhaps this needs a comment in the code. > > > Thanks Bin for your explanation. Slim Bootloader have done PCI config space setup > and PCI device enumeration in Slim Bootloader stages. > Yes, and we should not re-program registers like BARs in U-Boot to avoid mismatch, so that's why in coreboot/slimbootloader defconfig we have: # CONFIG_PCI_PNP is not set Regards, Bin
On Wed, Jul 24, 2019 at 1:13 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Aiden, > > On Wed, Jul 24, 2019 at 11:18 AM Park, Aiden <aiden.park@intel.com> wrote: > > > > Hi Andy, > > > > > -----Original Message----- > > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > > > Sent: Tuesday, July 23, 2019 5:27 AM > > > To: Bin Meng <bmeng.cn@gmail.com> > > > Cc: Park, Aiden <aiden.park@intel.com>; U-Boot Mailing List <u- > > > boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > > > Subject: Re: [PATCH v5 7/8] board: intel: Add new slimbootloader board > > > > > > On Tue, Jul 23, 2019 at 9:15 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko > > > > <andy.shevchenko@gmail.com> wrote: > > > > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden <aiden.park@intel.com> wrote: > > > > > > > > > board/intel/slimbootloader/README | 133 ++++++++++++++++++++ > > > > > > > > > > Shouldn't become reST one? > > > > > > > > I think this will need be converted to reST after my doc series are applied. > > > > > > I had an impression that reST conversion is targeting 2019.10. It means in your > > > branch you will have it applied earlier. > > > > > Let me change this to reST if necessary. > > Hi Bin, do you want me to change this one to reST or later? Let me know. > > I have no preference. You can either convert to reST later, or rebase > on top of this series to get it converted to reST now: > http://patchwork.ozlabs.org/project/uboot/list/?series=120139 Now the doc series lands in mainline, so please rebase this series on top of u-boot-x86/master. Thanks! [snip] Regards, Bin
Hi Bin, > -----Original Message----- > From: Bin Meng [mailto:bmeng.cn@gmail.com] > Sent: Thursday, July 25, 2019 11:44 PM > To: Park, Aiden <aiden.park@intel.com> > Cc: Andy Shevchenko <andy.shevchenko@gmail.com>; U-Boot Mailing List <u- > boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > Subject: Re: [PATCH v5 7/8] board: intel: Add new slimbootloader board > > On Wed, Jul 24, 2019 at 1:13 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Aiden, > > > > On Wed, Jul 24, 2019 at 11:18 AM Park, Aiden <aiden.park@intel.com> wrote: > > > > > > Hi Andy, > > > > > > > -----Original Message----- > > > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > > > > Sent: Tuesday, July 23, 2019 5:27 AM > > > > To: Bin Meng <bmeng.cn@gmail.com> > > > > Cc: Park, Aiden <aiden.park@intel.com>; U-Boot Mailing List <u- > > > > boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > > > > Subject: Re: [PATCH v5 7/8] board: intel: Add new slimbootloader > > > > board > > > > > > > > On Tue, Jul 23, 2019 at 9:15 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko > > > > > <andy.shevchenko@gmail.com> wrote: > > > > > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden <aiden.park@intel.com> > wrote: > > > > > > > > > > > board/intel/slimbootloader/README | 133 > ++++++++++++++++++++ > > > > > > > > > > > > Shouldn't become reST one? > > > > > > > > > > I think this will need be converted to reST after my doc series are applied. > > > > > > > > I had an impression that reST conversion is targeting 2019.10. It > > > > means in your branch you will have it applied earlier. > > > > > > > Let me change this to reST if necessary. > > > Hi Bin, do you want me to change this one to reST or later? Let me know. > > > > I have no preference. You can either convert to reST later, or rebase > > on top of this series to get it converted to reST now: > > http://patchwork.ozlabs.org/project/uboot/list/?series=120139 > > Now the doc series lands in mainline, so please rebase this series on top of u- > boot-x86/master. Thanks! > Thanks Bin. Let me rebase this series on top of latest u-boot-x86 and I will do reST. > [snip] > > Regards, > Bin Best Regards, Aiden
diff --git a/board/intel/Kconfig b/board/intel/Kconfig index 5131836cb0..01702ae502 100644 --- a/board/intel/Kconfig +++ b/board/intel/Kconfig @@ -73,6 +73,19 @@ config TARGET_MINNOWMAX Note that PCIE_ECAM_BASE is set up by the FSP so the value used by U-Boot matches that value. +config TARGET_SLIMBOOTLOADER + bool "slimbootloader" + help + This target is used for running U-Boot on top of Slim Bootloader + boot firmware as a payload. Slim Bootloader does memory initialization + and silicon initialization, and it passes necessary information in + HOB(Hand Off Block) to a payload. The payload consumes HOB data + which is generated by Slim Bootloader for its driver initialization. + Slim Bootloader consumes FSP and its HOB, but FSP HOB is cleared + Before launching a payload. Instead, Slim Bootloader generates its + HOB data such as memory info, serial port info and so on. + Refer to board/intel/slimbootloader/README for the details. + endchoice source "board/intel/bayleybay/Kconfig" @@ -82,5 +95,6 @@ source "board/intel/crownbay/Kconfig" source "board/intel/edison/Kconfig" source "board/intel/galileo/Kconfig" source "board/intel/minnowmax/Kconfig" +source "board/intel/slimbootloader/Kconfig" endif diff --git a/board/intel/slimbootloader/Kconfig b/board/intel/slimbootloader/Kconfig new file mode 100644 index 0000000000..b0c15f4ba2 --- /dev/null +++ b/board/intel/slimbootloader/Kconfig @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (C) 2019 Intel Corporation <www.intel.com> + +if TARGET_SLIMBOOTLOADER + +config SYS_BOARD + default "slimbootloader" + +config SYS_VENDOR + default "intel" + +config SYS_SOC + default "slimbootloader" + +config SYS_TEXT_BASE + default 0x00100000 + +comment "slimbootloader-specific options" + +config SYS_CONFIG_NAME + string "Board configuration file" + default "slimbootloader" + help + This option selects the board configuration file in include/configs/ + directory to be used to build U-Boot for Slim Bootloader. + +config DEFAULT_DEVICE_TREE + string "Board Device Tree Source (dts) file" + default "slimbootloader" + help + This option selects the board Device Tree Source (dts) file in + arch/x86/dts/ directory to be used to build U-Boot for Slim Bootloader. + +config SYS_CAR_ADDR + hex "Board specific Cache-As-RAM (CAR) address" + default 0x00000000 + help + This option specifies the board specific Cache-As-RAM (CAR) address. + But, CAR is not required for Slim Bootloader environment since it + has already initialized memory and launched u-boot as a payload. + +config SYS_CAR_SIZE + hex "Board specific Cache-As-RAM (CAR) size" + default 0x0000 + help + This option specifies the board specific Cache-As-RAM (CAR) size. + But, CAR is not required for Slim Bootloader environment since it + has already initialized memory and launched u-boot as a payload. + +endif diff --git a/board/intel/slimbootloader/Makefile b/board/intel/slimbootloader/Makefile new file mode 100644 index 0000000000..fd8fa98a8d --- /dev/null +++ b/board/intel/slimbootloader/Makefile @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (C) 2019 Intel Corporation <www.intel.com> + +obj-y += start.o slimbootloader.o diff --git a/board/intel/slimbootloader/README b/board/intel/slimbootloader/README new file mode 100644 index 0000000000..d1c5108a75 --- /dev/null +++ b/board/intel/slimbootloader/README @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (C) 2019 Intel Corporation <www.intel.com> + +Introduction +============ +This target is to enable U-Boot as a payload of Slim Bootloader(a.k.a SBL) +boot firmware(https://github.com/slimbootloader) which currently supports +QEMU, Apollolake, Whiskeylake, Coffeelake-R platforms. + +The Slim Bootloader is designed with multi-stages(Stage1A/B, Stage2, Payload) +architecture to cover from reset vector to OS booting and it consumes Intel FSP +(https://github.com/IntelFsp) for silicon initialization. +* Stage1A: Reset vector, CAR init with FSP-T +* Stage1B: Memory init with FSP-M, CAR teardown, Continue execution in memory +* Stage2 : Rest of Silicon init with FSP-S, Create HOB, Hand-off to Payload +* Payload: Payload init with HOB, Load OS from media, Booting OS + + + +Here is the step-by-step to launch U-Boot on Slim Bootloader. + +Compile U-Boot +============== + + > make distclean + > make slimbootloader_defconfig + > make all + + + +Prepare Slim Bootloader with u-boot-dtb.bin +=================================================== + +For build environment: + https://slimbootloader.github.io/getting-started + +Get source code: + > git clone https://github.com/slimbootloader/slimbootloader.git + +Copy the built u-boot-dtb.bin to Slim Bootloader source tree: + > mkdir -p <slimbootloader_home>/PayloadPkg/PayloadBins/ + > cp <u-boot_home>/u-boot-dtb.bin <slimbootloader_home>/PayloadPkg/PayloadBins/u-boot-dtb.bin + + + +Compile Slim Bootloader with U-Boot for QEMU target +=================================================== + +Update default payload to U-Boot (PayloadId is 4 Bytes): + Any 4 Bytes PayloadId is okay, but use 'U-BT' as an example. + > vi Platform/QemuBoardPkg/CfgData/CfgDataExt_Brd1.dlt + -GEN_CFG_DATA.PayloadId | 'AUTO' + +GEN_CFG_DATA.PayloadId | 'U-BT' + +Update payload text base in QEMU BoardConfig.py: + PAYLOAD_EXE_BASE must be the same as u-boot text base in board/intel/slimbootloader/Kconfig. + PAYLOAD_LOAD_HIGH must be 0. + > vi Platform/QemuBoardPkg/BoardConfig.py + + self.PAYLOAD_LOAD_HIGH = 0 + + self.PAYLOAD_EXE_BASE = 0x00100000 + +Compile for QEMU target: + Make sure u-boot-dtb.bin and U-BT PayloadId in build command. + > python BuildLoader.py build qemu -p "OsLoader.efi:LLDR:Lz4;u-boot-dtb.bin:U-BT:Lzma" + The output is Outputs/qemu/SlimBootloader.bin + +Launch Slim Bootloader on QEMU: + > qemu-system-x86_64 -machine q35 -m 256 -nographic -serial mon:stdio + -pflash Outputs/qemu/SlimBootloader.bin + Now, you should reach at U-Boot serial console. + + + +Compile Slim Bootloader with U-Boot for LeafHill(APL) target +============================================================ + +Compile U-Boot with CONFIG_SYS_NS16550_MEM32: + LeafHill has PCI UART2 MMIO32 serial port. Set CONFIG_SYS_NS16550_MEM32. + > vi include/configs/slimbootloader.h + +#define CONFIG_SYS_NS16550_MEM32 + #ifdef CONFIG_SYS_NS16550_MEM3 + > make disclean + > make slimbootloader_defconfig + > make all + +Copy the built u-boot-dtb.bin to Slim Bootloader source tree: + > mkdir -p <slimbootloader_home>/PayloadPkg/PayloadBins/ + > cp <u-boot_home>/u-boot-dtb.bin <slimbootloader_home>/PayloadPkg/PayloadBins/u-boot-dtb.bin + +Update default payload to U-Boot (PayloadId is 4 Bytes): + Any 4 Bytes PayloadId is okay, but use 'U-BT' as an example. + > vi Platform/ApollolakeBoardPkg/CfgData/CfgData_Int_LeafHill.dlt + -GEN_CFG_DATA.PayloadId | 'AUTO' + +GEN_CFG_DATA.PayloadId | 'U-BT' + +Update payload text base in APL BoardConfig.py: + PAYLOAD_EXE_BASE must be the same as u-boot text base in board/intel/slimbootloader/Kconfig. + PAYLOAD_LOAD_HIGH must be 0. + > vi Platform/ApollolakeBoardPkg/BoardConfig.py + + self.PAYLOAD_LOAD_HIGH = 0 + + self.PAYLOAD_EXE_BASE = 0x00100000 + +Compile for APL target: + Make sure u-boot-dtb.bin and U-BT PayloadId in build command. + > python BuildLoader.py build apl -p "OsLoader.efi:LLDR:Lz4;u-boot-dtb.bin:U-BT:Lzma" + The output is Outputs/apl/Stitch_Components.zip + +Stitch IFWI: + Refer to https://slimbootloader.github.io/supported-hardware/apollo-lake-crb.html#stitching. + > python Platform/ApollolakeBoardPkg/Script/StitchLoader.py -i <Existing IFWI> -s Outputs/apl/Stitch_Components.zip -o <Output IFWI> + +Flash IFWI: + Use DediProg to flash IFWI. + Now, you should reach at U-Boot serial console. + + + +To use ELF U-Boot +================= + +Compile U-Boot with CONFIG_OF_EMBED: + > vi configs/slimbootloader_defconfig + +CONFIG_OF_EMBED=y + > make distclean + > make slimbootloader_defconfig + > make all + > strip u-boot (To reduce image size by removing symbol) + +Do the same steps as above: + Copy u-boot to PayloadBins directory + Use u-boot in build command instead of u-boot-dtb.bin + No need to set PAYLOAD_LOAD_HIGH and PAYLOAD_EXE_BASE diff --git a/board/intel/slimbootloader/slimbootloader.c b/board/intel/slimbootloader/slimbootloader.c new file mode 100644 index 0000000000..d88aa622a0 --- /dev/null +++ b/board/intel/slimbootloader/slimbootloader.c @@ -0,0 +1,17 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019 Intel Corporation <www.intel.com> + */ + +#include <common.h> + +int board_early_init_r(void) +{ + /* + * Make sure PCI bus is enumerated so that peripherals on the PCI bus + * can be discovered by their drivers + */ + pci_init(); + + return 0; +} diff --git a/board/intel/slimbootloader/start.S b/board/intel/slimbootloader/start.S new file mode 100644 index 0000000000..5c3f3df09e --- /dev/null +++ b/board/intel/slimbootloader/start.S @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2019 Intel Corporation <www.intel.com> + */ + +/* board early initialization */ +.globl early_board_init +early_board_init: + jmp early_board_init_ret diff --git a/configs/slimbootloader_defconfig b/configs/slimbootloader_defconfig new file mode 100644 index 0000000000..a2acdb22da --- /dev/null +++ b/configs/slimbootloader_defconfig @@ -0,0 +1,21 @@ +CONFIG_X86=y +CONFIG_VENDOR_INTEL=y +CONFIG_TARGET_SLIMBOOTLOADER=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_LAST_STAGE_INIT=y +CONFIG_HUSH_PARSER=y +CONFIG_CMD_MMC=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_FAT=y +CONFIG_CMD_USB=y +CONFIG_DOS_PARTITION=y +CONFIG_EFI_PARTITION=y +CONFIG_OF_CONTROL=y +CONFIG_BOOTSTAGE=y +CONFIG_BOOTSTAGE_REPORT=y +CONFIG_BOOTDELAY=10 +CONFIG_CONSOLE_SCROLL_LINES=5 +# CONFIG_PCI_PNP is not set diff --git a/include/configs/slimbootloader.h b/include/configs/slimbootloader.h new file mode 100644 index 0000000000..f79e456414 --- /dev/null +++ b/include/configs/slimbootloader.h @@ -0,0 +1,59 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2019 Intel Corporation <www.intel.com> + */ + +#ifndef __SLIMBOOTLOADER_CONFIG_H__ +#define __SLIMBOOTLOADER_CONFIG_H__ + +#include <configs/x86-common.h> + +#undef CONFIG_NFSBOOTCOMMAND +#undef CONFIG_RAMBOOTCOMMAND +#undef CONFIG_EXTRA_ENV_SETTINGS +#undef CONFIG_BOOTCOMMAND + +/* + * By default, CONFIG_SYS_NS16550_PORT_MAPPED is enabled for port io serial. + * To use mmio base serial, enable CONFIG_SYS_NS16550_MEM32 and disable + * CONFIG_SYS_NS16550_PORT_MAPPED until ns16550 driver supports serial port + * configuration in run-time. + * + * #define CONFIG_SYS_NS16550_MEM32 + * #undef CONFIG_SYS_NS16550_PORT_MAPPED + */ +#ifdef CONFIG_SYS_NS16550_MEM32 +#undef CONFIG_SYS_NS16550_PORT_MAPPED +#endif + +#define CONFIG_STD_DEVICES_SETTINGS \ + "stdin=serial,i8042-kbd,usbkbd\0" \ + "stdout=serial\0" \ + "stderr=serial\0" + +#define CONFIG_EXTRA_ENV_SETTINGS \ + CONFIG_STD_DEVICES_SETTINGS \ + "netdev=eth0\0" \ + "consoledev=ttyS0\0" \ + "ramdiskaddr=0x4000000\0" \ + "ramdiskfile=initrd\0" \ + "bootdev=usb\0" \ + "bootdevnum=0\0" \ + "bootdevpart=0\0" \ + "bootfsload=fatload\0" \ + "bootusb=setenv bootdev usb; boot\0" \ + "bootscsi=setenv bootdev scsi; boot\0" \ + "bootmmc=setenv bootdev mmc; boot\0" \ + "bootargs=console=ttyS0,115200 console=tty0\0" + +#define CONFIG_BOOTCOMMAND \ + "if test ${bootdev} = \"usb\"; then ${bootdev} start; fi; " \ + "if test ${bootdev} = \"scsi\"; then ${bootdev} scan; fi; " \ + "${bootdev} info; " \ + "${bootfsload} ${bootdev} ${bootdevnum}:${bootdevpart} " \ + "${loadaddr} ${bootfile}; " \ + "${bootfsload} ${bootdev} ${bootdevnum}:${bootdevpart} " \ + "${ramdiskaddr} ${ramdiskfile}; " \ + "zboot ${loadaddr} 0 ${ramdiskaddr} ${filesize}" + +#endif /* __SLIMBOOTLOADER_CONFIG_H__ */