From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Frager, Neal" <neal.frager@amd.com>
Cc: "Simek, Michal" <michal.simek@amd.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
"buildroot@buildroot.org" <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH v2 1/1] configs/zynq_zc702_defconfig: new defconfig
Date: Tue, 31 Oct 2023 13:34:15 +0100 [thread overview]
Message-ID: <20231031133415.1d89db5a@windsurf> (raw)
In-Reply-To: <CH2PR12MB50042DEEED0FC5E7D3BBCA99F0A0A@CH2PR12MB5004.namprd12.prod.outlook.com>
Hello Neal,
On Tue, 31 Oct 2023 12:12:47 +0000
"Frager, Neal" <neal.frager@amd.com> wrote:
> I do understand your point. From this perspective, we can say the
> same thing about the zynq_zed_defconfig and the
> zynq_microzed_defconfig as well. For all 4 of these zynq boards, the
> DTS definition is all that changes from one defconfig to another.
> And in all 4 cases, the only differences in the dts files are things
> like gpio LEDs, switches and whether or not there is a CAN peripheral
> on board. So you could potentially boot the same images across these
> boards. You would just lose a peripheral or two that is included in
> one dts file but not another.
I think the discussion is not being specific enough here, so let me
provide some more background.
If the only differences between the zc706 and zc702 defconfigs is the
Linux kernel Device Tree (and I insist on Linux kernel Device Tree, not
Device Tree for the bootloaders/firmware), then you can have a single
configuration that builds multiple Device Trees, and the bootloader
selects the right one depending on which board we're booting on. This
is exactly what happens in beaglebone_defconfig:
BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-evm am335x-bone am335x-boneblack am335x-bonegreen am335x-evmsk am335x-boneblue am335x-boneblack-wireless am335x-bonegreen-wireless"
We build multiple Linux kernel Device Trees, and the U-Boot bootloader
detects which board we boot on, and selects the right Device Tree.
If you are in this situation, then yes we want a single defconfig.
However, if the bootloader needs to be different on ZCU702 vs ZCU706,
and this difference is not detected at boot-time/run-time, but is
handled as a different build-time configuration, then you have no other
choice but to have 2 separate defconfigs.
Now I see this:
+BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,u-boot-xlnx,xlnx_rebase_v2023.01_2023.2)/xlnx_rebase_v2023.01_2023.2.tar.gz"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="xilinx_zynq_virt"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc702"
in the ZCU702 defconfig, vs.
BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,u-boot-xlnx,xlnx_rebase_v2023.01_2023.2)/xlnx_rebase_v2023.01_2023.2.tar.gz"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="xilinx_zynq_virt"
BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc706"
Which means you need to have a different build-time configuration of
U-Boot, and therefore it's not possible to support both platforms in
the same Buildroot defconfig.
Best regards,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2023-10-31 12:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 11:13 [Buildroot] [PATCH v2 1/1] configs/zynq_zc702_defconfig: new defconfig Neal Frager via buildroot
2023-10-31 11:12 ` Luca Ceresoli via buildroot
2023-10-31 12:12 ` Frager, Neal via buildroot
2023-10-31 12:34 ` Thomas Petazzoni via buildroot [this message]
[not found] ` <8a0d97bb-2fe5-4e09-8e95-b928a431ce1e@amd.com>
2023-10-31 13:30 ` Frager, Neal via buildroot
2023-10-31 16:39 ` Peter Korsgaard
2023-11-13 17:10 ` Luca Ceresoli via buildroot
2023-11-13 21:42 ` Peter Korsgaard
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=20231031133415.1d89db5a@windsurf \
--to=buildroot@buildroot.org \
--cc=luca.ceresoli@bootlin.com \
--cc=michal.simek@amd.com \
--cc=neal.frager@amd.com \
--cc=thomas.petazzoni@bootlin.com \
/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