[meta-xilinx] FSBL.elf and BOOT.BIN using bitbake and SDCard booting

Tue Oct 11 10:59:44 PDT 2016

u-boot-xlnx/spl/ or u-boot-spl-xlnx/spl/

kratsg at dc:~/d4/poky/build/tmp/work/gfex_prototype2-poky-linux-gnueabi$ find
> -name u-boot-spl.cfg

Define it in *include/configs/zynq_zc70x.h* before zynq-common.h gets
included:

> #define CONFIG_ZYNQ_SDHCI
> #include <configs/zynq-common.h>

On 11 October 2016 at 11:41, Giordon Stark <kratsg at gmail.com> wrote:

> Hi Oleg,
>
> still looking for it?
>
> kratsg at dc:~/d4/poky/build/tmp/work/gfex_prototype2-poky-linux-gnueabi$ ls
> base-files     device-tree linux-xlnx    packagegroup-core-boot
>  sysvinit-inittab  u-boot-xlnx
> depmodwrapper-cross  fsbl-platform-init  packagegroup-base
>  shadow-securetty    u-boot-spl-xlnx   zynq-base
> kratsg at dc:~/d4/poky/build/tmp/work/gfex_prototype2-poky-linux-gnueabi$ pwd
> /users/kratsg/d4/poky/build/tmp/work/gfex_prototype2-poky-linux-gnueabi
>
> also, where would I define it, if I needed to?
>
> On Tue, Oct 11, 2016 at 12:32 PM Oleg K Dzhimiev <oleg at elphel.com> wrote:
>
>> It could be that FAT support is off in SPL. Check
>> poky/build/tmp/work/......../spl/u-boot-spl.cfg - it should have at
>> least:
>>
>> #define CONFIG_ZYNQ_SDHCI
>>
>> #define CONFIG_SPL_MMC_SUPPORT
>>
>> #define CONFIG_SPL_FAT_SUPPORT
>>
>>
>> Attaching a copy of mine.
>>
>> Based on zynq_zc70x.h
>> <https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq_zc70x.h> and
>> zynq-common.h
>> <https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq-common.h> -
>> you need to have CONFIG_ZYNQ_SDHCI defined.
>>
>> On 11 October 2016 at 10:45, Giordon Stark <kratsg at gmail.com> wrote:
>>
>> While we're at it, let me summarize the situation:
>>
>> Using the FSBL method I've documented here (https://github.com/kratsg/
>> meta-l1calo/wiki/Prepare-and-Boot-Hardware#fsbl-method) -- bitbake to
>> generate uImage, uramdisk.image.gz, devicetree.dtb, and u-boot.elf. Then I
>> create fsbl and then boot image using Xilinx SDK, put all these files on
>> the SD card and the SD card boots.
>>
>> If I use the SPL method, I am unable to boot this way with the following
>> error message:
>>
>> U-Boot SPL 2015.04 (Oct 05 2016 - 13:12:31)
>> mmc boot
>> reading fpga.bin
>> spl_load_image_fat: error reading image fpga.bin, err - -1
>> spl: error reading image fpga.bin, err - 1
>> reading system.dtb
>> spl_load_image_fat_os: error reading image system.dtb, err - -1
>> reading u-boot-dtb.img
>> spl_load_image_fat: error reading image u-boot-dtb.img, err - -1
>> ### ERROR ### Please RESET the board ###
>>
>>
>> So at least I know it works via the FSBL method but not the SPL method.
>> My second question is related to a comment you made. Let's say I have a
>> custom ELF that is written to set up / configure the clocks and I need this
>> to run as well. How do I add this in for the FSBL method and for the SPL
>> method? I assume for the FSBL method, I just add this in my boot image and
>> it will load this for me.
>>
>> Giordon
>>
>> On Tue, Oct 11, 2016 at 8:56 AM Giordon Stark <kratsg at gmail.com> wrote:
>>
>> Hi,
>>
>> Adding u-boot-dtb.img changes nothing according to the engineers working
>> on the board. They still see the same error message previously quoted.
>>
>> Something else must be off?
>>
>> Giordon
>>
>> On Tue, Oct 11, 2016 at 12:00 AM Nathan Rossi <nathan at nathanrossi.com>
>> wrote:
>>
>> On Tue, Oct 11, 2016 at 1:17 PM, Giordon Stark <kratsg at gmail.com> wrote:
>>
>> > On Mon, Oct 10, 2016 at 9:59 PM Nathan Rossi <nathan at nathanrossi.com>
>> wrote:
>>
>> >>
>>
>> >> On Tue, Oct 11, 2016 at 12:15 PM, Giordon Stark <kratsg at gmail.com>
>> wrote:
>>
>> >>
>>
>> >> > Thanks, some elaboration below!
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > On Mon, Oct 10, 2016 at 8:58 PM Nathan Rossi <nathan at nathanrossi.com
>> >
>>
>> >> > wrote:
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> On Tue, Oct 11, 2016 at 9:49 AM, Giordon Stark <kratsg at gmail.com>
>>
>> >> >> wrote:
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > Hi,
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > I am using bitbake to build on top of a custom machine [eg: using
>> my
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > devicetree] and then generating the following files which I
>> renamed
>>
>> >> >> > into
>>
>> >>
>>
>> >> >> > a
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > format appropriate for meta-xilinx
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > -rwxr-xr-x 1 kratsg  59K Oct  5 17:31 BOOT.BIN
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > -rw-r--r-- 1 kratsg  22K Oct  5 17:30 devicetree.dtb
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > -rw-r--r-- 1 kratsg 3.2M Oct  5 17:30 uImage
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > -rw-r--r-- 1 kratsg  26M Oct  5 17:15 uramdisk.image.gz
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > -rwxr-xr-x 1 kratsg 2.4M Oct  5 17:30 u-boot.elf
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > The machine is defined here:
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >> >
>>
>> >> >> > https://github.com/kratsg/meta-l1calo/blob/master/conf/
>> machine/gfex-prototype2.conf
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > The image I make (bitbake zynq-base) is defined here:
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >> >
>>
>> >> >> > https://github.com/kratsg/meta-l1calo/blob/master/
>> recipes-core/images/zynq-base.bb
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > So i'm hoping this is relatively straightforward. Now I get a
>> little
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > confused about actually booting this on the board using the SD
>> Card.
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > According to the docs
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > (https://github.com/Xilinx/meta-xilinx/blob/master/docs/
>> BOOT.sdcard)
>>
>> >> >> > it
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > seems that I need to only use four files generated from bitbake:
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > devicetree.dtb, uImage, uramdisk.image.gz, and u-boot.elf; and
>> then
>>
>> >> >> > use
>>
>> >>
>>
>> >> >> > the
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > Xilinx SDK to create an FSBL.elf, use the u-boot.elf from bitbake,
>>
>> >> >> > and
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > create a boot image (BOOT.BIN). Why isn't this able to be done
>> using
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > bitbake? When I try everything without using the Xilinx SDK, I see
>>
>> >> >> > the
>>
>> >>
>>
>> >> >> > error
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > message [1].
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> Those docs are a bit old, for the last release I re-wrote the
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> documentation as README.booting.md in the root of meta-xilinx.
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >> >> https://github.com/Xilinx/meta-xilinx/blob/master/
>> README.booting.md#loading-via-sd
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Awesome, I was not aware that the docs were rewritten. I didn't even
>>
>> >> > realize
>>
>> >>
>>
>> >> > there was a README.booting.md at the top level. Perhaps that can be
>>
>> >>
>>
>> >> > clarified somewhere?
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> It is mentioned in the README, maybe removing the old docs will remove
>>
>> >>
>>
>> >> any confusion?
>>
>> >
>>
>> >
>>
>> > That might be best! Or perhaps move that new README.booting into the
>> docs
>>
>> > directory to replace?
>>
>> >
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> Also I am not sure about your question regarding boot.bin
>> generation.
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> But if you machine provides the ps7_init_gpl* files (your machine is
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> including zc706, so they are available) it is able to build
>> u-boot-spl
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> (which does the same job as FSBL) and wrap that in the boot.bin
>> format
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> for use. If you need FSBL specifically then that is a separate
>> issue.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > For right now, we are using a custom board with a ZC706. We'll move
>> to
>>
>> >> > the
>>
>> >>
>>
>> >> > Zynq+ in the next generation (as well as bump up versions of
>> everything
>>
>> >> > from
>>
>> >>
>>
>> >> > Jethro). So I imagine we will always have these ps7_init_gpl
>> available
>>
>> >> > (I
>>
>> >>
>>
>> >> > imagine you refer to these:
>>
>> >>
>>
>> >> >
>>
>> >> > https://github.com/Xilinx/meta-xilinx/tree/master/
>> recipes-bsp/platform-init/platform-init/picozed-zynq7).
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> So ZynqMP is a bit different, there is U-Boot SPL support. However
>>
>> >>
>>
>> >> this is not exposed yet in meta-xilinx, but will be in the future.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> The directory you linked has the ps7_init_gpl* files which are
>>
>> >>
>>
>> >> specific for the picozed board. The platform-init recipe though would
>>
>> >>
>>
>> >> be one of the ways you can supply the ps7_init for your machine should
>>
>> >>
>>
>> >> you need to. For zc706 the ps7_init_gpl* files are actually in the
>>
>> >>
>>
>> >> U-Boot source tree
>>
>> >>
>>
>> >>
>>
>> >> (http://git.denx.de/?p=u-boot.git;a=tree;f=board/xilinx/zynq;h=
>> 2fc205e4e97071b73a16c00dec1d6804e418343f;hb=HEAD).
>>
>> >>
>>
>> >>
>>
>> >
>>
>> > I see. Interesting I didn't realize this was in the U-Boot source tree.
>> A
>>
>> > bit confusing where some files are located, but ok.
>>
>> >
>>
>> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > I do not totally understand how/why this can replace the FSBL
>> entirely?
>>
>> >>
>>
>> >> >
>>
>> >> > http://www.wiki.xilinx.com/U-Boot+Secondary+Program+Loader#
>> Task%20Description-Build%20U-Boot%20SPL
>>
>> >>
>>
>> >> > seems to indicate it is not fully supported by Xilinx. In fact, I
>> never
>>
>> >>
>>
>> >> > understood how the FSBL normally worked because I understood the
>> process
>>
>> >> > as
>>
>> >>
>>
>> >> > ROM Code -> SPL -> U-BOOT -> Kernel.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> That is the boot flow yes. And correct it is not "supported" by
>>
>> >>
>>
>> >> Xilinx, so you cannot expect to contact Xilinx support channels with
>>
>> >>
>>
>> >> regards to SPL. But support for SPL is definitely available in the
>>
>> >>
>>
>> >> community whether it be here on meta-xilinx or with U-Boot itself.
>>
>> >>
>>
>> >
>>
>> > Ok, so it should be possible to boot up boards with Xilinx processors
>> via
>>
>> > this method, not strictly relying on FSBL, but using SPL.
>>
>> >
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> FSBL is actually not a very complex program, all of the complex
>>
>> >>
>>
>> >> register initialization done for DDR, PLL, etc setup is actually
>>
>> >>
>>
>> >> contained in the ps7_init_gpl* code files generated by Vivado (in the
>>
>> >>
>>
>> >> HDF).
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> If you are interested you can actually see the source for FSBL here
>>
>> >>
>>
>> >>
>>
>> >> https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_
>> apps/zynq_fsbl/src.
>>
>> >>
>>
>> >> However it is important to note that FSBL is licensed under a
>>
>> >>
>>
>> >> restrictive Xilinx only use license.
>>
>> >>
>>
>> >>
>>
>> >
>>
>> > So FSBL technically contains SPL, but Xilinx generates a BOOT.BIN that
>>
>> > points to it when you try and do this from the SDK (say using
>> PetaLinux?).
>>
>>
>>
>> No FSBL is separate from SPL. There is no common code between them.
>>
>>
>>
>> When using the Xilinx SDK and bootgen you will be generating a
>>
>> boot.bin with FSBL as the initial image loader, with FSBL the boot.bin
>>
>> also includes an image table and additional images (e.g. u-boot).
>>
>>
>>
>> When using U-Boot SPL (with or without meta-xilinx) you will be
>>
>> generating a boot.bin with u-boot-spl as the initial image loader.
>>
>> There are no other images in the boot.bin, and any additional images
>>
>> are loaded by SPL directly from their source (e.g. SD, Flash, etc).
>>
>>
>>
>> >
>>
>> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > We do not necessarily require FSBL so this is fine. Looking at the
>> files
>>
>> >>
>>
>> >> > generated
>>
>> >> > (https://gist.github.com/kratsg/ba23d69a84db769cf8183b3dbc37c2f3)
>>
>> >>
>>
>> >> > with my attached local.conf there -- I do not see this. I'm guessing
>>
>> >> > this is
>>
>> >>
>>
>> >> > in a later release of poky. I can certainly update later to move to
>> this
>>
>> >>
>>
>> >> > workflow soon... unless you suggest I do it now over FSBL?
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Not sure what you mean by "I do not see this". I believe you might be
>>
>> >>
>>
>> >> confused as to what the boot.bin file is that is produced from the
>>
>> >>
>>
>> >> meta-xilinx build. This is actually u-boot-spl packed into a boot.bin
>>
>> >>
>>
>> >> for booting on Zynq. See my comment below where you are querying how
>>
>> >>
>>
>> >> it is booting.
>>
>> >
>>
>> >
>>
>> > I see, that is exactly what I was confused about. I thought you meant
>> there
>>
>> > was a u-boot and a u-boot-spl pair of files that I should be using. This
>>
>> > part is definitely not obvious at all. Is there documentation for
>>
>> > meta-Xilinx as to the output files it produces and what each one is?
>>
>>
>>
>> There is at the moment no documentation covering what files are what,
>>
>> at least not in the meta-xilinx documentation itself.
>>
>>
>>
>> >
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > My second (less important) question is how to get bitbake to
>> generate
>>
>> >>
>>
>> >> >> > the
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > filesystem in the right format? Right now, I have to run
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > mkimage -A arm -T ramdisk -C gzip -d
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > zynq-base-gfex-prototype2.cpio.gz.u-boot uramdisk.image.gz
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> *.cpio.gz.u-boot == uramdisk.image.gz. They are the same format
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> (except that i think the default Xilinx images are "ext.gz.u-boot"),
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> so there is no need to double wrap the ramdisk with two u-boot
>> mkimage
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> headers :).
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > The default appears to be cpio.gz.u-boot. If I didn't wrap it this
>> way,
>>
>> >> > I
>>
>> >>
>>
>> >> > could not get the filesystem loaded using that file. It needed the
>>
>> >> > mkimage
>>
>> >>
>>
>> >> > command.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Interesting, could you provide the commands/setup you are using in
>>
>> >>
>>
>> >> U-Boot to load the ramdisk? Because it should be able to load the
>>
>> >>
>>
>> >> cpio.gz.u-boot file directly from the bootm command.
>>
>> >
>>
>> >
>>
>> > I don't use any commands right now, everything is out of the box and we
>> just
>>
>> > plug in the SD card, and let the auto-boot take over.
>>
>>
>>
>> Ah ok, so you are just using the default u-boot environment. Which
>>
>> expects the name of the ramdisk file to be "uramdisk.image.gz", have
>>
>> you tried just renaming the *.cpio.gz.u-boot file to
>>
>> uramdisk.image.gz?
>>
>>
>>
>> >
>>
>> > In an older version, I had:
>>
>> > - console=ttyPS0,115200 earlyprintk devtmpfs.mount=1
>>
>> >
>>
>> > Now, I have:
>>
>> > - console=ttyPS0,115200
>>
>> >
>>
>> > For my bootargs. The reason for the early version is to try and get my
>> SD
>>
>> > card mounted as an external drive in the OS.... but I think I need to
>> set
>>
>> > that as "broken-cd" in the device tree to make it work [this was the
>>
>> > solution that came about from a previous email I sent to this group
>> about a
>>
>> > year ago].
>>
>> >
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > in order to get the correct uramdisk.image.gz . Is there a way to
>>
>> >> >> > make
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > bitbake generate the right image so I don't need to run this
>> command
>>
>> >> >> > so
>>
>> >>
>>
>> >> >> > that
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > u-boot understands my image when booting?
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > Giordon
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > [1]
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > U-Boot SPL 2015.04 (Oct 05 2016 - 13:12:31)
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> It looks like you are using the jethro version of OE/meta-xilinx? If
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> so, the new documentation might not exactly match the process (e.g.
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> "u-boot-dtb.img" instead of "u-boot.img").
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Noted. I do have u-boot-dtb.img instead of u-boot.img
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > mmc boot
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > reading fpga.bin
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > spl_load_image_fat: error reading image fpga.bin, err - -1
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > spl: error reading image fpga.bin, err - 1
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > reading system.dtb
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > spl_load_image_fat_os: error reading image system.dtb, err - -1
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > reading u-boot-dtb.img
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > spl_load_image_fat: error reading image u-boot-dtb.img, err - -1
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > ### ERROR ### Please RESET the board ###
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> If you follow the documentation I linked above it will mentioned
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> adding the "u-boot-dtb.img" file to your SD card. This is what you
>> are
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> missing here, which is why you get the error.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Really? But as it stands, there is no FSBL or SPL in my list of
>> files.
>>
>> >> > So
>>
>> >>
>>
>> >> > how is it able to boot otherwise?
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Right so the default build of meta-xilinx will produce a "boot.bin"
>>
>> >>
>>
>> >> file. This is the boot.bin file you have loaded on your target.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Currently the only boot.bin that meta-xilinx can produce is one which
>>
>> >>
>>
>> >> has U-Boot SPL packed into it. Note the log message you are getting on
>>
>> >>
>>
>> >> boot that says "U-Boot SPL 2015.04...".
>>
>> >
>>
>> >
>>
>> > This makes sense. So I guess I'm a little confused by the rest of the
>> log
>>
>> > message?
>>
>> >
>>
>> > U-Boot SPL 2015.04 (Oct 05 2016 - 13:12:31)
>>
>> > mmc boot
>>
>> > reading fpga.bin
>>
>> > spl_load_image_fat: error reading image fpga.bin, err - -1
>>
>> > spl: error reading image fpga.bin, err - 1
>>
>> > reading system.dtb
>>
>> > spl_load_image_fat_os: error reading image system.dtb, err - -1
>>
>> > reading u-boot-dtb.img
>>
>> > spl_load_image_fat: error reading image u-boot-dtb.img, err - -1
>>
>> > ### ERROR ### Please RESET the board ###
>>
>> >
>>
>> > Specifically, why/how is it trying to read fpga.bin and so on?
>> Shouldn't it
>>
>> > just be BOOT.BIN? Or this is after BOOT.BIN has been loaded (hence the
>>
>> > U-Boot SPL message). In which case, I don't understand what fpga.bin is
>>
>> > supposed to be. Similarly, it is looking for system.dtb [instead of
>>
>> > devicetree.dtb?] and it is missing u-boot-dtb.img which I should add on
>> as
>>
>> > well. So that I have 6 files:
>>
>>
>>
>> Ok so to add to the confusion, u-boot spl is capable of loading the
>>
>> fpga bitstream and the kernel itself without needing full U-Boot. It
>>
>> tries to load those first (for faster booting) before falling back to
>>
>> loading the full u-boot (u-boot-dtb.img). You can ignore the errors
>>
>> for fpga.bin and system.dtb, etc. if you are using full u-boot.
>>
>>
>>
>> Regards,
>>
>> Nathan
>>
>>
>>
>> >
>>
>> > - BOOT.BIN [u-boot-spl wrapped]
>>
>> > - devicetree.dtb -> system.dtb
>>
>> > - uImage
>>
>> > - uramdisk.image.gz
>>
>> > - u-boot.elf
>>
>> > - [add] u-boot-dtb.img
>>
>> >
>>
>> > Giordon
>>
>> >
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Regards,
>>
>> >>
>>
>> >> Nathan
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> Regards,
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> Nathan
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > --
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > _______________________________________________
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > meta-xilinx mailing list
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > meta-xilinx at yoctoproject.org
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> > https://lists.yoctoproject.org/listinfo/meta-xilinx
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >> >
>>
>> >>
>>
>> >> >>
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >
>>
>>
>> --
>> _______________________________________________
>> meta-xilinx mailing list
>> meta-xilinx at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>
>>
>>
>>
>> --
>> Best regards,
>> Oleg Dzhimiev
>> Electronics Engineer
>> phone: +1 801 783 5555 x124 <(801)%20783-5555>
>> Elphel, Inc.
>>
>

-- 
Best regards,
Oleg Dzhimiev
Electronics Engineer
phone: +1 801 783 5555 x124
Elphel, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20161011/735ddc31/attachment.html>