On Fri, Jan 27, 2023 at 06:55:46PM +0100, Mario Kicherer wrote: > On 2023-01-27 18:10, Tom Rini wrote: > > Yes, all of the platforms that define the value (since it roughly means > > "ROM set this value in something we can check") instead of enum'ing it > > still compile that file and now fail to build. > > Okay, I think I understand your point now. I am not sure what's the best > way to proceed here. Should I try to build all targets that contain > BOOT_DEVICE_NOR and add a #define for BOOT_DEVICE_NOR2 if my patch really > breaks the build? Or should I just add a #define BOOT_DEVICE_NOR2 to every > #define BOOT_DEVICE_NOR? > > It looks like a change would be necessary in these files then: > > arch/arm/include/asm/arch-am33xx/spl.h > arch/arm/include/asm/arch-orion5x/spl.h > arch/arm/mach-k3/include/mach/j721e_spl.h > arch/arm/mach-k3/include/mach/j721s2_spl.h > arch/microblaze/include/asm/spl.h > arch/powerpc/include/asm/spl.h > > > Ah, OK. Keep in mind that MMC1/MMC2 are for different physical MMC > > devices on a given platform. I think this is more like the case where > > you should be able to override spl_nor_get_uboot_base at the board level > > to say if you're loading A or B? > > Ah yes, it's been a while since I wrote this patch originally. > spl_nor_get_uboot_base() chooses between A and B and BOOT_DEVICE_NOR2 > signals that I should choose the other one now.
I think you should be able to solve this problem without making further changes upstream, yes. -- Tom
signature.asc
Description: PGP signature
