[U-Boot] arm: mvebu: ClearFog: booting u-boot from ssd?

[Stefan Roese]

Hi Florian,

On 22.02.2018 15:52, Florian Klink wrote:
>>> According to the clearfog wiki and uboot-armada38x src tree, there
>>> are separate
>>> images for sd and sata, with the makefile there calling
>>>> $(obj)tools/marvell/doimage -T mmc -D 0x0 -E 0x0 -G
>>>> $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.mmc
>>> vs
>>>> $(obj)tools/marvell/doimage -T sata -D 0x0 -E 0x0 -G
>>>> $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.sata
>>
>> Please note that this "should" not be needed when using mainline
>> U-Boot on A38x. All necessary tools for image generation are
>> included here.
>>> […]
>>>
>>> Am I missing something completely obvious, or does this mean there
>>> need to be
>>> different image headers depending on boot medium type BootROM tries 
>>> to load
>>> u-boot from (so it might be desirable to make this configurable)?
>>
>> You are correct. The image header differs depending on the boot media.
>> You need to change the BOOT_FROM line in the .cfg file accordingly, if
>> you want to boot from SATA.
> 
> Yes, this was more to find out in which ways the sata image differs from 
> the
> sdcard image.
> Simply editing `board/solidrun/clearfog/kwbimage.cfg` and changing 
> BOOT_FROM
> from `sdio` to `sata` got BootROM into accepting the image :-)

Ufff. ;)

>>> Are there already any efforts being taken on that? Most likely we'd
>>> also need to
>>> enable SATA drivers, so u-boot is able to read the kernel, which
>>> might be on
>>> that disk.
>>
>> Correct. If the SATA driver is not enabled yet, then this has to be
>> done for this board. A38x has an AHCI compatible SATA controller, so
>> this is the controller / driver to use. I suggest to look at the
>> Marvell
>> dev-board "db-88f6820-gp" for this.
> 
> I'll have a look on that, thanks! My question also aimed into the 
> direction on
> how to make this best configurable via `.config`, instead of editing 
> this file
> by hand.
> Are there any similar places were we set such things dynamically?

You could add a Kconfig symbol and change the .cfg file upon build-time
dynamically (Makefile scripting). Or you could add a new board config
file, which selects a different .cfg file for the different boot-device.
Frankly, this does not sound promising, as new files would need to
get introduced for each boot-device. So the Kconfig option for dynamic
.cfg generation looks more elegant.

Thanks,
Stefan