On 20.3.2017 21:29, Jean-Francois Dagenais wrote: > Hi guys, > > I am really riding the bleeding edge here... > >> On Mar 17, 2017, at 13:37, Nathan Rossi <nat...@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. Thanks, Michal -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
