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 <[email protected]> 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 <[email protected]> > wrote: > > On Tue, Oct 11, 2016 at 1:17 PM, Giordon Stark <[email protected]> wrote: > > > On Mon, Oct 10, 2016 at 9:59 PM Nathan Rossi <[email protected]> > wrote: > > >> > > >> On Tue, Oct 11, 2016 at 12:15 PM, Giordon Stark <[email protected]> > wrote: > > >> > > >> > Thanks, some elaboration below! > > >> > > >> > > > >> > > >> > On Mon, Oct 10, 2016 at 8:58 PM Nathan Rossi <[email protected]> > > >> > wrote: > > >> > > >> >> > > >> > > >> >> On Tue, Oct 11, 2016 at 9:49 AM, Giordon Stark <[email protected]> > > >> >> 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 > > >> > > >> >> > > >> > > >> >> > [email protected] > > >> > > >> >> > > >> > > >> >> > https://lists.yoctoproject.org/listinfo/meta-xilinx > > >> > > >> >> > > >> > > >> >> > > > >> > > >> >> > > >> > > >> > > > >> > > > > >
-- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
