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?). > > > > > > 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 > > >> > > >> > [email protected] > > >> > > >> > https://lists.yoctoproject.org/listinfo/meta-xilinx > > >> > > >> > > > >> > > > > >
-- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
