[PATCH v1 1/2] arm: mvebu: correct SPL boot configs for SPI/MMC

[Joel Johnson]

On 2020-04-18 08:23, Dennis Gilmore wrote:
> On Sat, Apr 18, 2020 at 9:18 AM Dennis Gilmore
> <dgilmore at fedoraproject.org> wrote:
>> 
>> On Fri, Apr 17, 2020 at 2:19 AM Joel Johnson <mrjoel at lixil.net> wrote:
>> >
>> > Update mvebu SPL boot selection mechanism for the move to driver model
>> > usage by ensuring that the required driver support for SPI and MMC
>> > booting is available in SPL when the respective boot method is
>> > selected.
>> >
>> > Previously, all mvebu boards selected a boot method (implicitly
>> > MVEBU_SPL_BOOT_DEVICE_SPI for many) even if SPL booting wasn't used.
>> > This changes mvebu boot method selection to depend on SPL usage which
>> > resolves the issue with aarch64 boards which don't use SPL getting an
>> > implicit boot device selection resulting in unmet dependencies. The
>> > 32-bit arm boards do use SPL, but I'm led to conclude that most aren't
>> > intentionally using the MVEBU_SPL_BOOT_DEVICE selection since none have
>> > SPL_DM_SPI enabled in their defconfig even though they still implicitly
>> > select the SPI boot method.
>> >
>> > This also results in the new addition of SPL_GPIO_SUPPORT to helios4.
>> > The mainline dts for helios4 includes the cd-gpios entry for sdhci with
>> > identical addresses as the clearfog dts. I don't have a helios4 board
>> > to confirm, but based on the current source conclude that the board
>> > itself is either wired to pull the signal low for eMMC, or the default
>> > MMC boot isn't fully functional in mainline. In either case, as far as
>> > I can tell, including the GPIO support will at least cause no
>> > regression.
>> 
>> Currently, SPL does not find u-boot.bin on the helios4, I am working
>> on syncing all of the changes done to clearfog to the helios4,
>> generally speaking, any change made to clearfog needs to also, be made
>> for the helios4 as they have the same SOM. the differences being in
>> changes for the carrier board.
>> 
>> Dennis

Great, thanks for the update and confirmation!

Stefan - in this case, I'd encourage that only the first commit of this 
series be merged and drop the second patch entirely.

Joel