[PATCH v2 1/2] spl: spl_nor: add BOOT_DEVICE_NOR2 as alternative SPL_LOAD_IMAGE_METHOD

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230127/5b3a3ef7/attachment.sig>