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

Tue Oct 11 06:56:17 PDT 2016

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/2f286cc2/attachment.html>