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

Mon Mar 27 17:22:21 PDT 2017

I seem to have forgotten PMUFW. So I've added that in, and I manage to get
further.

https://gist.github.com/kratsg/932ca6ff01fb489ee190ea3902c3fc73

>From what I can tell, it's not mounting the rootfs correctly (error -2) but
it seems to be hinting that I should give it an `init=` command.... but
that feels like something else is wrong.

Giordon

On Mon, Mar 27, 2017 at 6:00 PM Giordon Stark <kratsg at gmail.com> wrote:

> In particular, this is all I see now:
>
> Xilinx Zynq MP First Stage Boot Loader
> Release 2016.4   Mar 27 2017  -  17:50:52
> Platform: Silicon (3.0), Running on A53-0 (64-bit) Processor, Device Name:
> XCZU9EG
> SD1 with level shifter Boot Mode
> Bitstream download to start now
> PL Configuration done successfully
>   ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000
> NOTICE:  BL31: Secure code at 0x0
> NOTICE:  BL31: Non secure code at 0x0
> NOTICE:  BL31: v1.2(release):a9e3716
> NOTICE:  BL31: Built : 14:06:27, Mar  7 2017
>
> When I have:
> - FSBL.elf
> - top.bit
> - ATF.elf
> - u-boot.elf
>
> It seems like it hangs at ATF stage.
>
> On Mon, Mar 27, 2017 at 4:00 PM Giordon Stark <kratsg at gmail.com> wrote:
>
> 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/20170328/67c06338/attachment.html>