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

Tue Oct 11 09:45:10 PDT 2016

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
>
> >>
>
> >> >>
>
> >>
>
> >> >> >
>
> >>
>
> >> >>
>
> >>
>
> >> >
>
> >>
>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20161011/e3ec783b/attachment.html>