<div dir="ltr"><div>Thanks for the response!</div><div><br></div>inline comments/questions<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 21, 2017 at 11:44 PM Jason Wu <<a href="mailto:jason.wu.misc@gmail.com">jason.wu.misc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
On 22/03/2017 2:42 PM, Jason Wu wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> On 22/03/2017 2:19 AM, Giordon Stark wrote:<br class="gmail_msg">
>> Hi all,<br class="gmail_msg">
>><br class="gmail_msg">
>> We've got a rev 1.0 board (HW-Z1-ZCU102) which we're trying to do an<br class="gmail_msg">
>> FSBL boot (seeing the lack of success with SPL at the moment in the<br class="gmail_msg">
>> meta-xilinx mailing list). There are a few issues:<br class="gmail_msg">
>><br class="gmail_msg">
>> - uEnv.txt variables set for the device tree file as well as the kernel<br class="gmail_msg">
>> image do not seem to be understood by u-boot at all [it keeps asking for<br class="gmail_msg">
>> system.dtb or "Image" even if we set the variable correctly). For now,<br class="gmail_msg">
>> we just renamed the files to get things working.<br class="gmail_msg">
>><br class="gmail_msg">
>> - a kernel panic occurs after we manage to change the bootargs. Here is<br class="gmail_msg">
>> the kernel<br class="gmail_msg">
>> panic: <a href="https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70" rel="noreferrer" class="gmail_msg" target="_blank">https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70</a>.<br class="gmail_msg">
>> This looks highly similar<br class="gmail_msg">
>> to <a href="https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html</a> but<br class="gmail_msg">
>> I'm not sure if there was a solution?<br class="gmail_msg">
>><br class="gmail_msg">
>> The uEnv.txt looks<br class="gmail_msg">
>> like: <a href="https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37" rel="noreferrer" class="gmail_msg" target="_blank">https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37</a><br class="gmail_msg">
>> for us right now.<br class="gmail_msg">
>><br class="gmail_msg">
>> I used the evaluation board bitstream, with Xilinx SDK (2016.4) to<br class="gmail_msg">
>> create an FSBL.elf file (named fsbl.elf) as well as a boot image that<br class="gmail_msg">
>> contains the u-boot.elf generated from bitbake (as a datafile in the<br class="gmail_msg">
>> third slot).<br class="gmail_msg">
> You need to make sure your FSBL matches the dts/dtb you are used.<br class="gmail_msg">
> I am using hybrid images. I use FSBL + PMU from the system I generated<br class="gmail_msg">
> and  ATF + U-boot + kernel + rootfs + dtb from meta-xilinx. I create the<br class="gmail_msg">
> vivado design base on the DTS. I did have some changes to u-boot and<br class="gmail_msg">
> kernel dts. This will give full working system. IRC, MMC + sata is not<br class="gmail_msg">
> working for me with SPL.<br class="gmail_msg"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br class="gmail_msg">
>><br class="gmail_msg">
>> *Some side notes:*<br class="gmail_msg">
>> - the boot from SD Card was not possible until we set the switches to<br class="gmail_msg">
>> SW[4:1] = 0001 (the switch at "1" is flipped to "ON" side) instead of<br class="gmail_msg">
>> the suggested 0x5 or 0xE (neither of which worked).<br class="gmail_msg">
> IRC 0xE is 0001 on the sw[4:1].<br class="gmail_msg"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> - our bootargs initially set to "root=/dev/mmcblk0p2 rw rootwait" but<br class="gmail_msg">
>> everything hung at the "Starting kernel..." stage<br class="gmail_msg">
>>   - changing the bootargs to "earlycon=cdns,mmio,0xFF000000,115200n8<br class="gmail_msg">
>> root=/dev/mmcblk0p2 rw rootwait cma=256M" gets us past the hanging<br class="gmail_msg">
>> "Starting kernel..." stage, but leads to the kernel panic above<br class="gmail_msg">
>> - we are using "morty" everywhere. Should I change to master for<br class="gmail_msg">
>> meta-xilinx?<br class="gmail_msg">
> I think the best is for you to post your kernel panic message.<br class="gmail_msg">
my bad, i did not see you have post the kernel panic log. The problem<br class="gmail_msg">
you have is because you did not have the ATF loaded. You need to create<br class="gmail_msg">
your boot.bin with atf.<br class="gmail_msg"></blockquote><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div><br></div><div>Giordon</div></div></div>