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