[meta-xilinx] failure : SD to u-boot SPL to u-boot on zcu102-zynqmp

Tue Mar 21 02:14:12 PDT 2017

On 21-03-17 09:59, Michal Simek wrote:
> On 20.3.2017 21:29, Jean-Francois Dagenais wrote:
>> Hi guys,
>>
>> I am really riding the bleeding edge here...
>>
>>> 

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

On Mar 17, 2017, at 13:37, Nathan Rossi <nathan at nathanrossi.com> wrote:
>>>
>>> Not alternate, since given the error you have not loaded any pmu
>>> firmware. But yes, this is only relevant because you are using
>>> u-boot-xlnx master.
>>>
>>> The commit that introduced the requirement is
>>> https://github.com/Xilinx/u-boot-xlnx/commit/e047c5ad3db3cc2fa8c53a4a663ac8a256159b0e
>>
>> I see the printf I was getting, but this is only when I populate the SDCard with
>> the "atf-uboot.ub". Without the file present, the SPL would continue on to
>> "reading u-boot.img" a couple of times. Is it that without this PMUFW part
>> happening, going along and loading u-boot.img is doomed to fail? (which is what
>> I am seeing)
>>
>
> Without pmufw fw in past this worked. Right now this is probably just
> working too but I want to disable this option to run u-boot from el3. We
> should be el2-ns or el1-ns. That's why this option is probably there but
> it is not regularly tested and it will be removed in future.
>
>>>
>>>>
>>>> And did you just misprint "xilinx-v2016.4 kernel" instead of "u-boot"?
>>>
>>> Well I was not sure if you were also using the master branch of
>>> linux-xlnx or not, but linux-xlnx master has the same requirements for
>>> PMUFW.
>>>
>>>>
>>>> Did you mean I should use u-boot (upstream) instead of u-boot-xlnx?
>>>
>>> No you will want to use u-boot-xlnx at the moment. But Michal might be
>>> able to give you a better status on using zcu102 with upstream u-boot.
>>
>> Thanks! Hope to hear from Michal soon! I think it's a good idea to provide an
>> alternate path at this point. This would help us developers move along while
>> this very low-level stuff evolves. I'll happily volunteer to test when things
>> appear on the master branches of meta-xilinx, u-boot-xlnx and linux-xlnx.
>
> You need pmufw with configuration blob in it. Or pass it. This option is
> not supported now that's why it is not working.
> Not sure what's the plan to fix this.
> Right now I can run it because I have got some internal patches to
> include configuration blob for pmufw but not sure if/when this will be
> pushed out.
>
>
>>>>
>>>> I'm no expert on u-boot (yet ;) but I think this smells trouble. Maybe not for
>>>> meta-xilinx supported builds, but for integrators such as myself and all the
>>>> other OEMs which will use meta-xilinx as a base.
>>>>
>>>> I understand about an SPL-less build. Perhaps the Makefile could inspect
>>>> CONFIG_SPL_BUILD and fail if the psu_init_gpl files aren't found. You don't get
>>>> very far with a "psu_init"-less SPL, but much better if failure occurs at build
>>>> time. I can can attempt a patch in board/xilinx/zynqmp/Makefile unless you think
>>>> its a bad idea.
>>>
>>> I think its probably a good idea to have it fail if the ps*_init files
>>> are missing, this probably would apply to zynq as well. But this is
>>> something that would best be discussed on the u-boot list? or maybe
>>> Michal can chime in here too?
>>>
>>>>
>>>> My first tries were with u-boot-xlnx (v2016.4) and the SPL almost didn't start
>>>> at all. It may be related to 7d355473f34a (mmc: sdhci: zynqmp: Add support of
>>>> SD3.0) not being there yet. I did not try exactly your idea though. I will get
>>>> to it soon if nothing else works.
>>>>
>>>> Can I not change something in the defconfig to remove the extra PMUFW dependency?
>>>
>>> You might be able to hack around it, but I wouldn't recommend going
>>> down that path.
>> Ok, so, after fooling around a bit more, here's where I am (note: at this point
>> I am improvising a bit, learning a lot, but need to converge soon on something
>> stable for the next early phases of our development...)
>>
>> I am aiming for a pmufw.bin as a binary blob for the moment. So I sourced the
>> Vivado 2016.4 settings64.sh. Then cloned
>> https://github.com/Xilinx/embeddedsw.git . Using the master branch, I generated
>> the pmufw "executable.elf". Using a MACHINE=ml605-qemu-microblazeel bitbake gcc"
>> built objcopy, I generated pmufw.bin which I injected into u-boot-xlnx-dev.bb
>> using:
>>
>> SRC_URI += "\ file://add-pmufw-to-zcu102-defconfig.patch \
>> file://pmufw.bin;subdir=git/board/xilinx/zynqmp \ "
>>
>> The .patch adds CONFIG_PMUFW_INIT_FILE="board/xilinx/zynqmp/pmufw.bin" to
>> xilinx_zynqmp_zcu102_rev1.0_defconfig . I successfully created a "boot.bin" with
>> the PMUFW! Yay!
>>
>>
>> Here's the output...
>> <debug_uart> Debug uart enabled
>>
>> U-Boot SPL 2017.01-03253-g9c9291d-dirty (Mar 20 2017 - 15:52:02)
>> EL Level:	EL3
>> Trying to boot from MMC1
>> reading u-boot.bin
>> reading atf-uboot.ub
>> reading atf-uboot.ub
>> NOTICE:  ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000, with PMU firmware
>> NOTICE:  BL31: Secure code at 0x0
>> NOTICE:  BL31: Non secure code at 0x8000000
>> NOTICE:  BL31: v1.2(release):a9e3716
>> NOTICE:  BL31: Built : 16:41:21, Mar  9 2017
>> PMUFW: PmGetApiVersion: version 0.2
>> PMUFW:	v0.2
>> PMUFW version error. Expected: v0.3
>>
>> ### ERROR ### Please RESET the board ###
>>
>> So I am happy that it's no longer my fault! ;) But not much farther in terms of
>> the boot process.
>>
>> Now the problem is... where the heck is version 0.3! I have not seen any
>> branches on the xilinx repo containing it.
>
> I am no pmufw maintainer to tell you more about it.
>
>>
>> Basically, we have incoherent repo progress here.
>>
>> So please advise, I was under the impression that I needed recent commits in
>> u-boot-xlnx related to SD for booting on it. Should I use another specific
>> version of u-boot-xlnx? Again, just want to get past all that and execute the
>> kernel so the rest of the teams can progress.
>
> It was my decision to check pmufw version because so many people were
> using older/ancient pmufw which missed a lot of important features
> that's why we enforced version checking.
>
> You should use fsbl which contain all stuff you need. SPL is not
> officially supported boot solution.

Do you have a pointer to an explanation on how to create the FSBL and the PMU 
firmware, and how to create a boot.bin that contains and loads them?

So far I was somewhat capable of booting the mpsoc with ATF, but I never got 
any PMU firmware version to work at all. All I can see from the pmufw is loads 
of useless serial output, and then the system locks and/or crashes once the 
kernel starts.