[meta-xilinx] SPL Method on ZCU102 - Missing files?
Giordon Stark
kratsg at gmail.com
Tue Mar 7 08:55:01 PST 2017
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 <nathan at nathanrossi.com> wrote:
> On 8 March 2017 at 01:33, Giordon Stark <kratsg at gmail.com> wrote:
> > Thanks for the response. Short followups.
> >
> > On Tue, Mar 7, 2017 at 9:04 AM Nathan Rossi <nathan at nathanrossi.com>
> wrote:
> >>
> >> On 7 March 2017 at 15:40, Giordon Stark <kratsg at 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 <oleg at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20170307/c2a169c9/attachment.html>
More information about the meta-xilinx
mailing list