On 2020-04-18 08:23, Dennis Gilmore wrote:
On Sat, Apr 18, 2020 at 9:18 AM Dennis Gilmore dgilmore@fedoraproject.org wrote:
On Fri, Apr 17, 2020 at 2:19 AM Joel Johnson mrjoel@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