Hello Tom,
On 2023-01-26 20:17, Tom Rini wrote:
This breaks a lot of platforms, as it only covers a few of the cases
where BOOT_DEVICE_NOR is listed. I would also really like to see how
this ends up being used in the board specific case as I do wonder if we
can't solve this some other way that won't have impact so many other
platforms. Thanks!
Hm, I did a grep through the source code and that were the only places
where the new value is used as part of an enum. BOOT_DEVICE_NOR is used
in more places but they also #define this themselves - if I did not
miss something.
Furthermore, BOOT_DEVICE_NOR2 will not be used by default. A board has
to define its own board_boot_order() function like this to use the new
BOOT_DEVICE_NOR2 value:
void board_boot_order(u32 *spl_boot_list)
{
spl_boot_list[0] = BOOT_DEVICE_NOR;
spl_boot_list[1] = BOOT_DEVICE_NOR2;
}
If they do not explicitly add BOOT_DEVICE_NOR2, they should not be
affected by this patch, as far as I understood the code. I tried to
model this similar to the BOOT_DEVICE_MMC1 and _MMC2 values.
Then, they can also define an own spl_nor_get_uboot_base() like the
following that should return an address where U-Boot tries to load
a valid image:
unsigned long spl_nor_get_uboot_base(struct spl_boot_device *bootdev)
{
if (bootdev->boot_device == BOOT_DEVICE_NOR) {
/* first address that is tried */
return UBOOT_PARTITION_1_IN_NOR;
else if (bootdev->boot_device == BOOT_DEVICE_NOR2) {
/*
* if loading of the first image failed for whatever
* reason, try this address as well:
*/
return UBOOT_PARTITION_2_IN_NOR;
}
}
With this patch, it is possible to provide a fallback U-Boot image like
above or to use an A/B slot scheme in case a bootloader update could be
necessary in the field in the future.
Best regards,
Mario
