From: Michal Simek <michal.simek@xilinx.com>
To: u-boot@lists.denx.de
Subject: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs
Date: Wed, 11 Dec 2019 14:52:12 +0100 [thread overview]
Message-ID: <0da82fa3-a0c3-940f-e796-bf276afb5853@xilinx.com> (raw)
In-Reply-To: <20191210153012.GW9549@bill-the-cat>
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
next prev parent reply other threads:[~2019-12-11 13:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 15:19 [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs Michal Simek
2019-12-09 15:19 ` [PATCH 1/2] arm64: zynqmp: Add missing Kconfig options to zynqmp_virt platform Michal Simek
2019-12-09 15:19 ` [PATCH 2/2] arm64: zynqmp: Use " Michal Simek
2019-12-10 12:40 ` [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs Michal Simek
2019-12-10 13:56 ` Tom Rini
2019-12-10 15:24 ` Michal Simek
2019-12-10 15:30 ` Tom Rini
2019-12-11 13:52 ` Michal Simek [this message]
2020-01-16 7:16 ` Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0da82fa3-a0c3-940f-e796-bf276afb5853@xilinx.com \
--to=michal.simek@xilinx.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox