All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: u-boot@lists.denx.de
Subject: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs
Date: Tue, 10 Dec 2019 16:24:09 +0100	[thread overview]
Message-ID: <74473878-5d7d-e112-3179-0731318cf551@xilinx.com> (raw)
In-Reply-To: <20191210135639.GU9549@bill-the-cat>

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.

>  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.

> 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.

Thanks,
Michal

  reply	other threads:[~2019-12-10 15:24 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 [this message]
2019-12-10 15:30       ` Tom Rini
2019-12-11 13:52         ` Michal Simek
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=74473878-5d7d-e112-3179-0731318cf551@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.