U-Boot Preloader: Yocto build output vs Preloader Generator

Boot
1

Hi all,

I’m working with an Arria V kit and have successfully booted Linux using the binaries supplied in the GSRD 14.1. From my understanding, the U-Boot preloader supplied in this is generated by the EDS Preloader Generator. (Is this correct?)

I’m now looking to start developing a custom build via Yocto, using meta-altera, but have found that the U-Boot preloader (u-boot-spl-arria5.bin) it generates does not seem to boot. I see that it’s significantly smaller (44KiB) than the preloader supplied in the GSRD (256 KiB).

Could someone comment on the differences between these files, and perhaps comment about the intended workflow with respect to where the EDS tools and Yocto overlap with building U-Boot.

2

After a little more reading, my guess is that the U-Boot SPL from meta-altera does not have the boot ROM header on it.

According to this document (pg 7), this header include a Validation Word at offset 0x40 of 0x31305341 (“AS01” in ASCII). I see this in the preloader from the GSRD, but not in the one built by Yocto.

So… is it simply the case that the Yocto recipe doesn’t run mkpimage?

3

I was searching for meta-altera documentation and workflow for a long time. I have even contacted Altera support. But nothing has succeed.

To understand this you can explore certain recipe. Also don’t forget to look into included and inherited files.

4

From a cursory review of the meta-altera U-Boot recipes, I don’t see anything along the lines of fetching, building, and running mkpimage.

Yesterday I got Quartus 15 and the SoC EDS setup. I ran mkpimage on the U-Boot SPL built from my Yocto build:

$ ./mkpimage -h
mkpimage version 15.0 (build 145)

Description: This tool creates an Altera BootROM-compatible image of Second
Stage Boot Loader (SSBL). The input and output files are in binary format.
It can also decode and check the validity of previously generated image.

Usage:
 Create quad image:
     mkpimage [options] -hv <num> -o <outfile> <infile> <infile> <infile> <infile>
 Create single image:
     mkpimage [options] -hv <num> -o <outfile> <infile>
 Decode single/quad image:
     mkpimage -d [-a <num>] <infile>

Options:
 -a (--alignment) <num>       : Address alignment in kilobytes, valid value
                                starts from 64, 128, 256 etc, default to 64 for
                                header version 0 and 256 for header version 1,
                                override if the NAND flash has a larger block
                                size
 -d (--decode)                : Flag to decode the header information from
                                input file and display it
 -f (--force)                 : Flag to force decoding even if the input file
                                is an unpadded image
 -h (--help)                  : Display this help message and exit
 -hv (--header-version) <num> : Header version to be created (Arria/Cyclone V =
                                0, Arria 10 = 1)
 -o (--output) <outfile>      : Output file, relative and absolute path
                                supported
 -off (--offset) <num>        : Program entry offset relative to start of
                                header (0x40), default to 0x14. Used for header
                                version 1 only
 -v (--version)               : Display version and exit

$ ./mkpimage -hv 0 -o u-boot-spl-arria5.bin.bootrom u-boot-spl-arria5.bin

I now see the SPL booting, per the following UART output:

U-Boot SPL 2013.01.01-00121-g32c1d91 (Aug 25 2015 - 10:20:11)
BOARD : Altera SOCFPGA Arria V Board
CLOCK: EOSC1 clock 25000 KHz
CLOCK: EOSC2 clock 0 KHz
CLOCK: F2S_SDR_REF clock 0 KHz
CLOCK: F2S_PER_REF clock 0 KHz
CLOCK: MPU clock 1050 MHz
CLOCK: DDR clock 533 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 50000 KHz
CLOCK: QSPI clock 350000 KHz
RESET: COLD
INFO : Watchdog enabled
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 1024 MiB
ALTERA DWMMC: 0
reading u-boot.img
spl: error reading image u-boot.img, err - -1
### ERROR ### Please RESET the board ###

So, there’s where I’ve left off. More digging required, I guess. Thoughts on this and my original question about the workflow are appreciated.

5

It appears that error message is printed by U-Boot’s drivers/mmc/spl_mmc.c (in the mmc_load_image_fat function). So… apparently this is looking for a u-boot.img file on the FAT partition where we plop our kernel, dtb, etc instead of on the RAW (type A2) partition that mkimage.py

I confirmed this by plopping my u-boot.img onto said partition. It boots successfully.

And thus, I’ve come full circle to my original question – what are the reasons for these differences between the EDS-based workflow used to create the GSRD, and the U-Boot recipes in meta-altera?

Could someone with experience with a custom Altera SoC-based platform comment on this?

It seems to me that automating as much as possible via Yocto is the “right” thing to do. I envision that what I’ll end up doing is using the EDS’s Second Stage Bootloader Support Package Generator to develop the platform-specific patches I’ll need to apply to the upstream socfpga U-Boot, and then apply those via a .bbappend for the U-Boot recipe.

Thanks!