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

Mon Oct 10 20:17:21 PDT 2016

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?).

>
> >
>
> > 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?

>
>
>
> >
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> >
>
> >>
>
> >> > 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.

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:

- 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/4234eb13/attachment.html>