Thanks a lot! We've got a board over here in our e-shop so I'll poke at this and get back to you soon. It's been somewhat difficult to debug issues with booting because nothing shows up on the serial when trying to load the SD Card (presumably because the boot.bin isn't working right).
Giordon On Tue, Mar 7, 2017 at 10:49 AM Nathan Rossi <nat...@nathanrossi.com> wrote: > On 8 March 2017 at 01:33, Giordon Stark <kra...@gmail.com> wrote: > > Thanks for the response. Short followups. > > > > On Tue, Mar 7, 2017 at 9:04 AM Nathan Rossi <nat...@nathanrossi.com> > wrote: > >> > >> On 7 March 2017 at 15:40, Giordon Stark <kra...@gmail.com> wrote: > >> > I re-ran on the latest distro (I was on kogoroth and switched to > morty). > >> > Here's what I see in the list of files: > >> > https://gist.github.com/kratsg/04abfb458ae95a8e167dc08cc1250e37 > >> > > >> > On Mon, Mar 6, 2017 at 6:14 PM Oleg K Dzhimiev <o...@elphel.com> > wrote: > >> >> > >> >> Hello, > >> >> > >> >>> I have a few questions based on this: > >> >>> - where is boot.bin? > >> >>> - where is u-boot.img / u-boot-dtb.img? > >> >> > >> >> > >> >> Check with the poky/meta/recipes-bsp/u-boot/u-boot.inc look for > >> >> "deploy" > >> >> function. > >> >> Also, boot.bin should be the smallest in size. > >> > > >> > > >> > I see the deploy function: > >> > > >> > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc#n203 > >> > but this looks really confusing and hard to read. Comparing to what I > >> > see > >> > here > >> > > >> > ( > https://github.com/Xilinx/meta-xilinx/blob/morty/conf/machine/include/machine-xilinx-default.inc > ), > >> > it looks like "SPL_BINARY" is not set and would need to be set to get > >> > this > >> > working. I don't know where to set this. It also looks like, > similarly, > >> > UBOOT_ENV is not set as well. So uEnv.txt does not get made. > >> > >> Currently ZCU102 does not have boot.bin generated by default, for > >> couple reasons. > >> > >> 1. No one has sent patches for it, and I don't have hardware so I > >> haven't tested or been able to look at getting it working > >> 2. u-boot-xlnx has a few different 'zcu102' configs/psu_init setups > >> > >> To get it working, SPL_BINARY = "spl/boot.bin" should be enough (you > >> can set this in conf/local.conf or in the machine.conf) as the > >> boot.bin should be being built regardless. > > > > > > How do you know that this needs to be set to spl/boot.bin instead of > > boot.bin? Where does this point to? > > It is just pointing to the file that is copied/deployed from the > u-boot build output. > > https://github.com/Xilinx/u-boot-xlnx/blob/master/scripts/Makefile.spl#L156 > > And for the xilinx boot.bin files, they always get built to spl/. > > > > >> > >> But you will need to use > >> u-boot-xlnx, and you will likely need to select a psu_init* that works > >> for your board > >> (https://github.com/Xilinx/u-boot-xlnx/tree/master/board/xilinx/zynqmp > >> there is a few for zcu102). > > > > > > How do you select one? I don't see many options in > > > https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc > > Source modification, you need to change the defconfig for the board. > You would need to do it via a patch. > > > . > > > >> > >> > >> Additionally for custom psu_init files, the platform-init recipe > >> provider setup is not there just yet. There are some patches on my > >> nrossi/wip branch > >> (https://github.com/nathanrossi/meta-xilinx/tree/nrossi/wip) for it if > >> interested. > > > > > > For now, i think the default will work fine as we want to boot the zynqmp > > via the SPL method. After this, we'll probably want to add custom > psu_init > > files that configure power for external FPGAs later. > > > >> > >> > >> > > >> >> > >> >> > >> >>> > >> >>> - where is the root filesystem (eg: to populate the second > partition)? > >> >>> I > >> >>> only see a ramdisk which goes in the first partition (*cpio.gz) > >> >> > >> >> > >> >> a. convert cpio.gz to tar.gz > >> >> b. in the rootfs recipe (zynq-base.bb?) specify: > >> >>> > >> >>> IMAGE_FSTYPES = "tar.gz" > >> > > >> > > >> > Looks like this is getting made. I'm not sure why it wasn't before! > >> > > >> >> > >> >> > >> >> Then don't forget about bootargs. > >> > > >> > > >> > Don't forget about it? Right now, I manually create the uEnv.txt file > >> > and > >> > fill it in myself (including the bootargs and uenvcmd myself > manually). > >> > Is > >> > there a more automated way to set this? > >> > >> You can set bootargs in the chosen node of the device tree if you > >> want. But u-boot will overwrite that anyway if you set bootargs within > >> the u-boot environment. > >> > >> > > >> >> > >> >> > >> >>> - where is uImage? is it just "Image"? > >> >> > >> >> Most likely. > >> > > >> > > >> > How can I confirm? > >> > >> Image is the kernel, should be in your machine's deploy/images > directory. > >> > >> The kernel does not make uImage for arm64, 'Image' is a special type > >> that is new for arm64 that is a binary image packed with a info > >> header. U-Boot can read them with the booti command. > > > > > > Right, I knew Image was the generic linux kernel image. It just wasn't > clear > > to me at all if u-boot was able to read a kernel image without the u-boot > > wrapper (eg: via mkimage). I know bootm and bootz exist, but wasn't aware > > booti was a thing. > > > > So then we would change > > > > uenvcmd=fatload mmc 0 0x3000000 ${kernel_image} && fatload mmc 0 > 0x2A00000 > > ${devicetree_image} && bootm 0x3000000 - 0x2A00000 > > > > which has a bootm command to > > > > uenvcmd=fatload mmc 0 0x3000000 ${kernel_image} && fatload mmc 0 > 0x2A00000 > > ${devicetree_image} && booti 0x3000000 - 0x2A00000 > > > > equivalently for the kernel image, correct? > > Yep that is all you need to change. > > Regards, > Nathan >
-- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
