[U-Boot] [PATCH v1 1/4] spl: record boot_device into spl_image and call spl_perform_fixups

Dr. Philipp Tomsich philipp.tomsich at theobroma-systems.com
Thu May 24 23:23:07 UTC 2018


Lukasz,

> On 25 May 2018, at 00:11, Lukasz Majewski <lukma at denx.de> wrote:
> 
> Hi Philipp,
> 
>> On some boards, we want to give the board/architecture-specific code a
>> chance to look at where the next image has been loaded from and
>> perform fixups before starting the next image.  This is of particular
>> importance, when we probe multiple devices for bootable payloads and
>> boot the first one found.
>> 
>> This change adds the following:
>> - we record the boot_device used into the spl_image structure
>> - we provide an extension-point for boards/architectures that can
>>   perform late fixups depending on a fully populated spl_image
>>   structure (i.e. we'll know the final boot_device and have info
>>   on the image type and operating system to be booted).
>> 
>> Signed-off-by: Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>> Tested-by: Klaus Goger <klaus.goger at theobroma-systems.com>
>> ---
>> 
>> common/spl/spl.c | 12 +++++++++++-
>> include/spl.h    |  7 +++++++
>> 2 files changed, 18 insertions(+), 1 deletion(-)
>> 
>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>> index a09ada3..a1e7b9f 100644
>> --- a/common/spl/spl.c
>> +++ b/common/spl/spl.c
>> @@ -80,6 +80,11 @@ int __weak bootz_setup(ulong image, ulong *start,
>> ulong *end) }
>> #endif
>> 
>> +/* Weak default function for arch/board-specific fixups to the
>> spl_image_info */ +void __weak spl_perform_fixups(struct
>> spl_image_info *spl_image) +{
>> +}
>> +
>> void spl_fixup_fdt(void)
>> {
>> #if defined(CONFIG_SPL_OF_LIBFDT) &&
>> defined(CONFIG_SYS_SPL_ARGS_ADDR) @@ -445,8 +450,10 @@ static int
>> boot_from_devices(struct spl_image_info *spl_image, else
>> 			puts("SPL: Unsupported Boot Device!\n");
>> #endif
>> -		if (loader && !spl_load_image(spl_image, loader))
>> +		if (loader && !spl_load_image(spl_image, loader)) {
>> +			spl_image->boot_device = spl_boot_list[i];
>> 			return 0;
>> +		}
>> 	}
>> 
>> 	return -ENODEV;
>> @@ -498,6 +505,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>> #ifdef CONFIG_SYS_SPL_ARGS_ADDR
>> 	spl_image.arg = (void *)CONFIG_SYS_SPL_ARGS_ADDR;
>> #endif
>> +	spl_image.boot_device = BOOT_DEVICE_NONE;
>> 	board_boot_order(spl_boot_list);
>> 
>> 	if (boot_from_devices(&spl_image, spl_boot_list,
>> @@ -506,6 +514,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>> 		hang();
>> 	}
>> 
>> +	spl_perform_fixups(&spl_image);
>> +
>> #ifdef CONFIG_CPU_V7M
>> 	spl_image.entry_point |= 0x1;
>> #endif
>> diff --git a/include/spl.h b/include/spl.h
>> index 8454ea7..8628787 100644
>> --- a/include/spl.h
>> +++ b/include/spl.h
>> @@ -29,6 +29,7 @@ struct spl_image_info {
>> #if CONFIG_IS_ENABLED(LOAD_FIT)
>> 	void *fdt_addr;
>> #endif
>> +	u32 boot_device;
>> 	u32 size;
>> 	u32 flags;
>> 	void *arg;
>> @@ -296,4 +297,10 @@ void spl_invoke_atf(struct spl_image_info
>> *spl_image);
>>  * can implement 'board_return_to_bootrom'.
>>  */
>> void board_return_to_bootrom(void);
>> +
>> +/**
>> + * spl_perform_fixups() - arch/board-specific callback before
>> processing
>> + *                        the boot-payload
>> + */
>> +void spl_perform_fixups(struct spl_image_info *spl_image);
>> #endif
> 
> Have I understood correctly that after applying this patch I can define
> my own spl_perform_fixup() function in my board's spl.c and then decide
> if I want to boot kernel/u-boot proper from eMMC, even if I started the
> boot process from SPI-NOR (where SPL is placed) ?

Starting from SPI-NOR and then continuing from eMMC is already possible
using other mechanisms (e.g. we use FIT images and the boot device list
infrastructure)… so no, this is something different.

This was implemented for the full U-Boot to decide where to boot the OS from.
Our use-case is that if SPL boots the full U-Boot from external storage, we’d like
to continue booting from external storage.

Patches 3 + 4 from the series show an example implementation for our RK3399-Q7:
- patch 3 injects a property into the DTS seen by the full U-Boot stage
- patch 4 uses this to change the order of mmc0 and mmc1 in the env for distroboot

> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de <mailto:wd at denx.de>


More information about the U-Boot mailing list