On 10. 12. 19 16:30, Tom Rini wrote: > On Tue, Dec 10, 2019 at 04:24:09PM +0100, Michal Simek wrote: >> On 10. 12. 19 14:56, Tom Rini wrote: >>> On Tue, Dec 10, 2019 at 01:40:42PM +0100, Michal Simek wrote: >>>> Hi Tom, >>>> >>>> On 09. 12. 19 16:19, Michal Simek wrote: >>>>> Hi, >>>>> >>>>> over years a lot of new Xilinx ZynqMP board have been added to U-Boot with >>>>> corresponding defconfigs. Also a lot of drivers have been moved to DM that >>>>> we can make one generic configuration with one defconfig. >>>>> Nand still needs to be validated that's why dc2/dc3 are not moved yet. >>>>> >>>>> Boards can be build like this: >>>>> export DEVICE_TREE="avnet-ultra96-rev1" >>>>> make xilinx_zynqmp_virt_defconfig >>>>> make -j >>>>> >>>>> Series depends on patches sent before that's why here is full tree: >>>>> https://github.com/michalsimek/u-boot/tree/20191209-mainline >>>> >>>> This series will require some changes in CI loops because right now >>>> I didn't setup default device tree (CONFIG_DEFAULT_DEVICE_TREE) to >>>> "force" everybody to properly pass DEVICE_TREE via command line. >>>> I can't use OF_BOARD because then SPL is built without DT at all. >>>> >>>> How do you think I should handle it for CI loops? >>>> 1. I can remove this configuration but it will be only one at the end >>>> that's why not a good solution. >>>> 2. Add generic option to run some commands before tests like export >>>> DEVICE_TREE above >>>> 3. provide different options for SPL/full u-boot how >>>> OF_SEPARATE/OF_BOARD is handled. >>> >>> So, for CI are you wanting to test most device trees, or just one? >> >> All zynqmp dtses are built by default. > > Right, but for what I thought you're saying the real use is, you pass > just a single device tree, right? If so, do you think we should loop > over each, or just build one? > >>> Are >>> we able to run one of these device trees via QEMU? >> >> zynqmp is covered just by buildman not by pytest. I have this on my todo >> list for some time but there will be other issues with mainline qemu to >> do so. > > OK, so something to improve for the future, and after we handle this > "today" problem. > >>> If we can run the >>> virt defconfig via qemu, we should just update/extend that stanza in the >>> CI files to set DEVICE_TREE and exclude building it from the normal >>> jobs. >> >> Based on next generation Xilinx Versal where we use OF_BOARD qemu is >> generated DT for model self to ensure that only stuff which are emulated >> are provided to SW. Logic for dt selection is quite simply. >> https://github.com/Xilinx/u-boot-xlnx/blob/master/arch/arm/mach-versal/cpu.c#L112 >> But Versal is not using SPL and SPL needs initial DT. Also standard >> Xilinx boot flow on zynq/zynqmp is not using SPL and SPL is community >> driven effort. >> >> At the end of the day I would like to use the same functionality across >> boards. It means full u-boot should check one fixed location for DT >> first with priority. For this OF_SEPARATE can be also used because >> board_fdt_blob_setup can be overwritten for these cases too. >> https://gitlab.denx.de/u-boot/u-boot/blob/master/lib/fdtdec.c#L1190 >> >>> If we can't run via qemu then yes, something like option #2 and >>> we set DEVICE_TREE in one job and export it if set in the build job. >> >> It means for qemu there is no real need to build dts from source tree at >> all. >> Let me look at #2 for CI. > > OK, thanks! >
I have look at it again and there are other strange things. When you select CONFIG_SPL_FIT_GENERATOR then there is no reason to generate u-boot.img (because you want to replace this by your generator) or append dtb behind u-boot.bin (because default option is already setup in fit format). CAT u-boot-dtb.bin MKIMAGE u-boot.img MKIMAGE u-boot-dtb.img COPY u-boot.bin LD u-boot.elf MKIMAGE u-boot.itb Regarding travis. just c&p. What about just this? diff --git a/.travis.yml b/.travis.yml index 5da046ca7ed5..4cef12e18370 100644 --- a/.travis.yml +++ b/.travis.yml @@ -118,6 +118,9 @@ script: # use clang only do one configuration. - if [[ "${BUILDMAN}" != "" ]]; then ret=0; + if [[ "${ENV}" != "" ]]; then + export eval `echo ${ENV}`; + fi; tools/buildman/buildman -P -E ${BUILDMAN} ${OVERRIDE}|| ret=$?; if [[ $ret -ne 0 && $ret -ne 129 ]]; then tools/buildman/buildman -sdeP ${BUILDMAN}; And then job like this - name: "buildman ZynqMP Virt" env: - ENV="DEVICE_TREE=zynqmp-zcu100-revC" - BUILDMAN="xilinx_zynqmp_virt" Or do you see any smarter way how this can be done? Thanks, Michal