[U-Boot] arm: mvebu: ClearFog: booting u-boot from ssd?
Hey,
I tried getting ClearFog to load u-boot from a M.2 SSD (via SATA)
So I built u-boot-spl.kwb
make clearfog_defconfig make -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi-
dd'ed it on the SSD:
dd if=u-boot-spl.kwb of=/dev/sdX bs=512 seek=1
changed SW1 dip to 11100, and got this:
BootROM - 1.73 Booting from AHCI Probing HBA- 0 port 0 SATA device found BootROM: Bad header at offset 00000001 BootROM: Bad header at offset 00000022 BootROM: Bad header at offset 00001000 BootROM: Bad header at offset 00002000 BootROM: Bad header at offset 00003000 BootROM: Bad header at offset 00004000 BootROM: Bad header at offset 00005000 BootROM: Bad header at offset 00006000 BootROM: Bad header at offset 00007000
Trying Uart
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
According to uboot-armada38x's tools/marvell/doimage_mv/doimage.c, this seems to result in different
hdr->blockID = IBR_HDR_SATA_ID; //0x78 hdr->blockID = IBR_HDR_MMC_ID; //0xAE
and maybe another hdr->sourceAddr baked into the image header [1]
Mainline u-boot also knows about IBR_HDR_SATA_ID (tools/kwbimage.h), and has a mapping in tools/kwbimage.c (boot_modes[]), which seems to decide depending on the 'BOOT_FROM' setting in board/solidrun/clearfog/kwbimage.cfg This is currently hardcoded to 'sdio' (which will be translated to 0xAE == IBR_HDR_MMC_ID).
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)?
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.
Regards, Florian
[1]: https://github.com/coreboot/coreboot/blob/master/util/marvell/doimage_mv/doi...
Hi Florian,
On 16.02.2018 11:23, Florian Klink wrote:
Hey,
I tried getting ClearFog to load u-boot from a M.2 SSD (via SATA)
So I built u-boot-spl.kwb
make clearfog_defconfig make -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi-
dd'ed it on the SSD:
dd if=u-boot-spl.kwb of=/dev/sdX bs=512 seek=1
changed SW1 dip to 11100, and got this:
BootROM - 1.73 Booting from AHCI Probing HBA- 0 port 0 SATA device found BootROM: Bad header at offset 00000001 BootROM: Bad header at offset 00000022 BootROM: Bad header at offset 00001000 BootROM: Bad header at offset 00002000 BootROM: Bad header at offset 00003000 BootROM: Bad header at offset 00004000 BootROM: Bad header at offset 00005000 BootROM: Bad header at offset 00006000 BootROM: Bad header at offset 00007000
Trying Uart
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.
According to uboot-armada38x's tools/marvell/doimage_mv/doimage.c, this seems to result in different
hdr->blockID = IBR_HDR_SATA_ID; //0x78 hdr->blockID = IBR_HDR_MMC_ID; //0xAE
and maybe another hdr->sourceAddr baked into the image header [1]
Mainline u-boot also knows about IBR_HDR_SATA_ID (tools/kwbimage.h), and has a mapping in tools/kwbimage.c (boot_modes[]), which seems to decide depending on the 'BOOT_FROM' setting in board/solidrun/clearfog/kwbimage.cfg This is currently hardcoded to 'sdio' (which will be translated to 0xAE == IBR_HDR_MMC_ID).
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.
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.
Thanks, Stefan
Hey Stefan,
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 :-)
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?
Regards, Florian
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
participants (2)
-
Florian Klink -
Stefan Roese