[meta-xilinx] Kernel Panic: SD Boot on zcu102-zynqmp

Giordon Stark kratsg at gmail.com
Mon Mar 27 14:00:42 PDT 2017


Hi,

I attempted to get ATF included. I ran `bitbake arm-trusted-firmware` and
then included the generated ELF in the boot image. Unfortunately, now the
board doesn't even seem to boot at all (no messages come up in the serial
console).

I've tried looking through the documentation that Xilinx provides for ATF
and where to include it, but there isn't any. My best guess is that it
needs to come after the bitstream but before the u-boot. Unfortunately, I'm
at a loss and I can't seem to do (what was much simpler and straightforward
with Zynq-7000 series) an FSBL boot to the OS.

Any tips or links to the full set of steps would be helpful.

Giordon

On Wed, Mar 22, 2017 at 5:46 AM Jason Wu <jason.wu.misc at gmail.com> wrote:

>
>
> On 22/03/2017 3:00 PM, Giordon Stark wrote:
> > Thanks for the response!
> >
> > inline comments/questions
> >
> > On Tue, Mar 21, 2017 at 11:44 PM Jason Wu <jason.wu.misc at gmail.com
> > <mailto:jason.wu.misc at gmail.com>> wrote:
> >
> >
> >
> >     On 22/03/2017 2:42 PM, Jason Wu wrote:
> >     >
> >     >
> >     > On 22/03/2017 2:19 AM, Giordon Stark wrote:
> >     >> Hi all,
> >     >>
> >     >> We've got a rev 1.0 board (HW-Z1-ZCU102) which we're trying to do
> an
> >     >> FSBL boot (seeing the lack of success with SPL at the moment in
> the
> >     >> meta-xilinx mailing list). There are a few issues:
> >     >>
> >     >> - uEnv.txt variables set for the device tree file as well as the
> >     kernel
> >     >> image do not seem to be understood by u-boot at all [it keeps
> >     asking for
> >     >> system.dtb or "Image" even if we set the variable correctly). For
> >     now,
> >     >> we just renamed the files to get things working.
> >     >>
> >     >> - a kernel panic occurs after we manage to change the bootargs.
> >     Here is
> >     >> the kernel
> >     >> panic:
> >     https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70.
> >     >> This looks highly similar
> >     >> to
> >
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html
> >     but
> >     >> I'm not sure if there was a solution?
> >     >>
> >     >> The uEnv.txt looks
> >     >> like:
> https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37
> >     >> for us right now.
> >     >>
> >     >> I used the evaluation board bitstream, with Xilinx SDK (2016.4) to
> >     >> create an FSBL.elf file (named fsbl.elf) as well as a boot image
> that
> >     >> contains the u-boot.elf generated from bitbake (as a datafile in
> the
> >     >> third slot).
> >     > You need to make sure your FSBL matches the dts/dtb you are used.
> >     > I am using hybrid images. I use FSBL + PMU from the system I
> generated
> >     > and  ATF + U-boot + kernel + rootfs + dtb from meta-xilinx. I
> >     create the
> >     > vivado design base on the DTS. I did have some changes to u-boot
> and
> >     > kernel dts. This will give full working system. IRC, MMC + sata is
> not
> >     > working for me with SPL.
> >
> >
> > How do we make sure the FSBL matches the dts/dtb we are using? As far as
> > I can tell, it is built based on the bitstream file given, and I just
> > hoped (right now) that the evaluation board's bitstream file provided by
> > Vivado SDK matched the DTS file provided by meta-xilinx [this might be
> > the case]. In the future, not sure how to do this if I'm given just the
> > DTS/DTB.
> One way to do it is to generate the dts with the HDF, just to be sure
> the system is not far different between two dts/dtb.
> >
> >
> >     >
> >     >>
> >     >> *Some side notes:*
> >     >> - the boot from SD Card was not possible until we set the
> switches to
> >     >> SW[4:1] = 0001 (the switch at "1" is flipped to "ON" side)
> instead of
> >     >> the suggested 0x5 or 0xE (neither of which worked).
> >     > IRC 0xE is 0001 on the sw[4:1].
> >
> >
> > This may be because it's upside-down a bit. It's been very confusing
> > trying to figure out what is 1/0 for the switches.
> :). IRC, i was checking it in the xsdb. You can read the mode in xsdb.
> "puts [mrd 0xFF5E0200]" should give you E.
>
> >
> >
> >     >> - our bootargs initially set to "root=/dev/mmcblk0p2 rw rootwait"
> but
> >     >> everything hung at the "Starting kernel..." stage
> >     >>   - changing the bootargs to
> "earlycon=cdns,mmio,0xFF000000,115200n8
> >     >> root=/dev/mmcblk0p2 rw rootwait cma=256M" gets us past the hanging
> >     >> "Starting kernel..." stage, but leads to the kernel panic above
> >     >> - we are using "morty" everywhere. Should I change to master for
> >     >> meta-xilinx?
> >     > I think the best is for you to post your kernel panic message.
> >     my bad, i did not see you have post the kernel panic log. The problem
> >     you have is because you did not have the ATF loaded. You need to
> create
> >     your boot.bin with atf.
> >
> >
> > How do we create the boot.bin with ATF (ARM trusted firmware)? How do
> > you know it's because we do not have ATF loaded?
> because your u-boot is showing running at EL3. You need to check bif
> format and see how to include the atf. IRC, it is part of the zynq
> ultrascale SW development doc.
>
> Regards,
>
> Jason
> >
> > Thanks,
> >
> > Giordon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20170327/9704fbc1/attachment.html>


More information about the meta-xilinx mailing list