* [U-Boot] [PATCH v1 0/1] rockchip: rk3399: spl: make SPL boot-order configurable via /chosen @ 2017-03-28 9:02 Philipp Tomsich 2017-03-28 9:03 ` [U-Boot] [PATCH v1] " Philipp Tomsich 0 siblings, 1 reply; 4+ messages in thread From: Philipp Tomsich @ 2017-03-28 9:02 UTC (permalink / raw) To: u-boot For chips that don't have any meaningful boot-selection pins that directly change the Boot ROM's boot-order (e.g. Rockchip RK3399, Allwinner A64, Allwinner A80), a probing of devices in a predefined (and board-specfic) boot-order is desirable for the SPL to mimic the ROM's behaviour and allow overrides of the sequence according to user-defined policies. To get the ball rolling, this has been implemented for the RK3399 in the board's SPL support, but I fully expect this to be generalised for other boards in the common SPL code (in a code-path dependent on DM, OF_CONTROL and BLK): unlike the current selection of a limited number of boot-devices (e.g. only a single BOOT_DEVICE_SPI), a more flexible approach (e.g. multiple SPI flashes to be probed in sequence) could then be realised. These changes should be used in conjunction with FIT images (and all legacy image formats disabled via Kconfig). Philipp Tomsich (1): rockchip: rk3399: spl: make SPL boot-order configurable via /chosen arch/arm/mach-rockchip/rk3399-board-spl.c | 99 +++++++++++++++++++++++++++++++ doc/device-tree-bindings/chosen.txt | 22 +++++++ 2 files changed, 121 insertions(+) -- 1.9.1 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] [PATCH v1] rockchip: rk3399: spl: make SPL boot-order configurable via /chosen 2017-03-28 9:02 [U-Boot] [PATCH v1 0/1] rockchip: rk3399: spl: make SPL boot-order configurable via /chosen Philipp Tomsich @ 2017-03-28 9:03 ` Philipp Tomsich 2017-04-01 4:23 ` Simon Glass 0 siblings, 1 reply; 4+ messages in thread From: Philipp Tomsich @ 2017-03-28 9:03 UTC (permalink / raw) To: u-boot The RK3399 does not have any boot selection pins and the BootROM probes the boot interfaces using the following boot-order: 1. SPI 2. eMMC (sdhci in DTS) 3. SD card (sdmmc in DTS) 4. USB loader For ease of deployment, the SPL stage should mirror the boot order of the ROM and use the same probing order (assuming that valid images can be detected by SPL) unless instructed otherwise. The boot-order can then be configured via the 'u-boot,spl-boot-order' property in the chosen-node of the DTS. While this approach is easily extensible to other boards, it is only implemented for the RK3399 for now, as the large SRAM on the RK3399 makes this easy to fit the needed infrastructure into SPL and our production setup already runs with DM, OF_CONTROL and BLK in SPL. The new boot-order property is expected to be used in conjunction with FIT images (and all legacy image formats disabled via Kconfig). A boot-sequence with probing and fallthroughs from SPI via eMMC to SD card (i.e. &spiflash, &sdhci, &sdmmc) has been validated on the RK3399-Q7. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com> Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> --- arch/arm/mach-rockchip/rk3399-board-spl.c | 99 +++++++++++++++++++++++++++++++ doc/device-tree-bindings/chosen.txt | 22 +++++++ 2 files changed, 121 insertions(+) diff --git a/arch/arm/mach-rockchip/rk3399-board-spl.c b/arch/arm/mach-rockchip/rk3399-board-spl.c index c212143..3bfc2d9 100644 --- a/arch/arm/mach-rockchip/rk3399-board-spl.c +++ b/arch/arm/mach-rockchip/rk3399-board-spl.c @@ -10,6 +10,7 @@ #include <fdtdec.h> #include <led.h> #include <malloc.h> +#include <mmc.h> #include <ram.h> #include <spl.h> #include <asm/gpio.h> @@ -27,6 +28,104 @@ DECLARE_GLOBAL_DATA_PTR; +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_OF_CONTROL) +static int spl_node_to_boot_device(int node) +{ + struct udevice *parent; + + /* + * This should eventually move into the SPL code, once SPL becomes + * aware of the block-device layer. Until then (and to avoid unneeded + * delays in getting this feature out, it lives at the board-level). + */ + if (!uclass_get_device_by_of_offset(UCLASS_MMC, node, &parent)) { + struct udevice *dev; + struct blk_desc *desc = NULL; + + for (device_find_first_child(parent, &dev); + dev; + device_find_next_child(&dev)) { + if (device_get_uclass_id(dev) == UCLASS_BLK) { + desc = dev_get_uclass_platdata(dev); + break; + } + } + + if (!desc) + return -ENOENT; + + switch (desc->devnum) { + case 0: + return BOOT_DEVICE_MMC1; + case 1: + return BOOT_DEVICE_MMC2; + default: + return -ENOSYS; + } + } + + /* + * SPL doesn't differentiate SPI flashes, so we keep the detection + * brief and inaccurate... hopefully, the common SPL layer can be + * extended with awareness of the BLK layer (and matching OF_CONTROL) + * soon. + */ + if (!uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node, &parent)) + return BOOT_DEVICE_SPI; + + return -1; +} + +void board_boot_order(u32 *spl_boot_list) +{ + const void *blob = gd->fdt_blob; + int chosen_node = fdt_path_offset(blob, "/chosen"); + int idx = 0; + int elem; + int boot_device; + int node; + const char *conf; + + if (chosen_node < 0) { + debug("%s: /chosen not found, using spl_boot_device()\n", + __func__); + spl_boot_list[0] = spl_boot_device(); + return; + } + + for (elem = 0; + (conf = fdt_stringlist_get(blob, chosen_node, + "u-boot,spl-boot-order", elem, NULL)); + elem++) { + /* First check if the list element is an alias */ + const char *alias = fdt_get_alias(blob, conf); + if (alias) + conf = alias; + + /* Try to resolve the config item (or alias) as a path */ + node = fdt_path_offset(blob, conf); + if (node < 0) { + debug("%s: could not find %s in FDT", __func__, conf); + continue; + } + + /* Try to map this back onto SPL boot devices */ + boot_device = spl_node_to_boot_device(node); + if (boot_device < 0) { + debug("%s: could not map node @%x to a boot-device\n", + __func__, node); + continue; + } + + spl_boot_list[idx++] = boot_device; + } + + /* If we had no matches, fall back to spl_boot_device */ + if (idx == 0) + spl_boot_list[0] = spl_boot_device(); +} +#endif + u32 spl_boot_device(void) { return BOOT_DEVICE_MMC1; diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-tree-bindings/chosen.txt index bf9a30a..5625d21 100644 --- a/doc/device-tree-bindings/chosen.txt +++ b/doc/device-tree-bindings/chosen.txt @@ -41,3 +41,25 @@ Example reg = <0xf00 0x10>; }; }; + +u-boot,spl-boot-order property +------------------------------ + +In a system using an SPL stage and having multiple boot sources +(e.g. SPI NOR flash, on-board eMMC and a removable SD-card), the boot +device may be probed by reading the image and verifying an image +signature. + +If the SPL is configured through the device-tree, the boot-order can +be configured with the spl-boot-order property under the /chosen node. +Each list element of the property should specify a device to be probed +in the order they are listed: references (i.e. implicit paths), a full +path or an alias is expected for each entry. + +Example +------- +/ { + chosen { + u-boot,spl-boot-order = &sdmmc, "/sdhci at fe330000"; + }; +}; -- 1.9.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [U-Boot] [PATCH v1] rockchip: rk3399: spl: make SPL boot-order configurable via /chosen 2017-03-28 9:03 ` [U-Boot] [PATCH v1] " Philipp Tomsich @ 2017-04-01 4:23 ` Simon Glass 2017-04-05 1:05 ` Simon Glass 0 siblings, 1 reply; 4+ messages in thread From: Simon Glass @ 2017-04-01 4:23 UTC (permalink / raw) To: u-boot On 28 March 2017 at 03:03, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > The RK3399 does not have any boot selection pins and the BootROM probes > the boot interfaces using the following boot-order: > 1. SPI > 2. eMMC (sdhci in DTS) > 3. SD card (sdmmc in DTS) > 4. USB loader > For ease of deployment, the SPL stage should mirror the boot order of > the ROM and use the same probing order (assuming that valid images can > be detected by SPL) unless instructed otherwise. The boot-order can > then be configured via the 'u-boot,spl-boot-order' property in the > chosen-node of the DTS. > > While this approach is easily extensible to other boards, it is only > implemented for the RK3399 for now, as the large SRAM on the RK3399 > makes this easy to fit the needed infrastructure into SPL and our > production setup already runs with DM, OF_CONTROL and BLK in SPL. > > The new boot-order property is expected to be used in conjunction with > FIT images (and all legacy image formats disabled via Kconfig). > > A boot-sequence with probing and fallthroughs from SPI via eMMC to SD > card (i.e. &spiflash, &sdhci, &sdmmc) has been validated on the RK3399-Q7. > > Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> > Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com> > Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> > --- > > arch/arm/mach-rockchip/rk3399-board-spl.c | 99 +++++++++++++++++++++++++++++++ > doc/device-tree-bindings/chosen.txt | 22 +++++++ > 2 files changed, 121 insertions(+) Acked-by: Simon Glass <sjg@chromium.org> ^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] [PATCH v1] rockchip: rk3399: spl: make SPL boot-order configurable via /chosen 2017-04-01 4:23 ` Simon Glass @ 2017-04-05 1:05 ` Simon Glass 0 siblings, 0 replies; 4+ messages in thread From: Simon Glass @ 2017-04-05 1:05 UTC (permalink / raw) To: u-boot On 31 March 2017 at 22:23, Simon Glass <sjg@chromium.org> wrote: > On 28 March 2017 at 03:03, Philipp Tomsich > <philipp.tomsich@theobroma-systems.com> wrote: >> The RK3399 does not have any boot selection pins and the BootROM probes >> the boot interfaces using the following boot-order: >> 1. SPI >> 2. eMMC (sdhci in DTS) >> 3. SD card (sdmmc in DTS) >> 4. USB loader >> For ease of deployment, the SPL stage should mirror the boot order of >> the ROM and use the same probing order (assuming that valid images can >> be detected by SPL) unless instructed otherwise. The boot-order can >> then be configured via the 'u-boot,spl-boot-order' property in the >> chosen-node of the DTS. >> >> While this approach is easily extensible to other boards, it is only >> implemented for the RK3399 for now, as the large SRAM on the RK3399 >> makes this easy to fit the needed infrastructure into SPL and our >> production setup already runs with DM, OF_CONTROL and BLK in SPL. >> >> The new boot-order property is expected to be used in conjunction with >> FIT images (and all legacy image formats disabled via Kconfig). >> >> A boot-sequence with probing and fallthroughs from SPI via eMMC to SD >> card (i.e. &spiflash, &sdhci, &sdmmc) has been validated on the RK3399-Q7. >> >> Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> >> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com> >> Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> >> --- >> >> arch/arm/mach-rockchip/rk3399-board-spl.c | 99 +++++++++++++++++++++++++++++++ >> doc/device-tree-bindings/chosen.txt | 22 +++++++ >> 2 files changed, 121 insertions(+) > > Acked-by: Simon Glass <sjg@chromium.org> Applied to u-boot-rockchip, thanks! ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-04-05 1:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-28 9:02 [U-Boot] [PATCH v1 0/1] rockchip: rk3399: spl: make SPL boot-order configurable via /chosen Philipp Tomsich 2017-03-28 9:03 ` [U-Boot] [PATCH v1] " Philipp Tomsich 2017-04-01 4:23 ` Simon Glass 2017-04-05 1:05 ` Simon Glass
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.