public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs
Date: Tue, 10 Dec 2019 10:30:12 -0500	[thread overview]
Message-ID: <20191210153012.GW9549@bill-the-cat> (raw)
In-Reply-To: <74473878-5d7d-e112-3179-0731318cf551@xilinx.com>

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191210/d74e4f4b/attachment.sig>

  reply	other threads:[~2019-12-10 15:30 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 [this message]
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=20191210153012.GW9549@bill-the-cat \
    --to=trini@konsulko.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