On 9/14/2023 2:42 PM, Denys Dmytriyenko wrote:
On Thu, Sep 14, 2023 at 01:23:31PM -0500, Ryan Eatmon wrote:
On 9/14/2023 12:08 PM, Denys Dmytriyenko wrote:
On Wed, Sep 13, 2023 at 10:12:57PM +0530, Chirag Shilwant via
lists.yoctoproject.org wrote:
On 13/09/23 01:34, Denys Dmytriyenko wrote:
On Sat, Sep 09, 2023 at 02:00:04AM +0530, Chirag Shilwant wrote:
- Add a new file u-boot-mergeconfig.inc which will ensure we handle fragment
u-boot configs
using a new variable UBOOT_CONFIG_FRAGMENT which stores the name of fragment
u-boot config
to be used.
Would be nice to provide extra details here in the commit message about config
fragment support in U-boot and its recipe. E.g.:
* U-boot recipe in OE-Core supports out-of-tree config fragments that are
passed via SRC_URI and automatically merges all *.cfg files as fragments.
This makes specifying config fragments in the machine configuration a bit
difficult.
* U-boot itself supports in-tree config fragments and recently been adding
fragments with *.config extension (first in configs/ dir, but will be moving
to the corresponding board/ dir), so adding a way to specify and pass those.
Sure, will update the commit message & provide extra details in my
v2 PATCH.
- Include u-boot-mergeconfig.inc in u-boot-ti.inc
Signed-off-by: Chirag Shilwant <[email protected]>
---
meta-ti-bsp/recipes-bsp/u-boot/u-boot-mergeconfig.inc | 7 +++++++
meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti.inc | 1 +
2 files changed, 8 insertions(+)
create mode 100644 meta-ti-bsp/recipes-bsp/u-boot/u-boot-mergeconfig.inc
diff --git a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-mergeconfig.inc
b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-mergeconfig.inc
new file mode 100644
index 00000000..69db6260
--- /dev/null
+++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-mergeconfig.inc
@@ -0,0 +1,7 @@
+do_compile:prepend () {
Should be done in do_configure instead. Tasks should be self-contained and
granular. Plus, do_compile can be repeated w/o do_configure. If you are
re-configuring every time and generate a new .config file in do_compile,
that would probably trigger full re-compile due to make tracking file
timestamps...
Yes, we can update this to happen in do_configure. I believe
do_configure:append should be good & will work. Will handle this in
v2.
+ if [ -n "${UBOOT_CONFIG_FRAGMENT}" ]
Multiple fragments are supported, so maybe call it UBOOT_CONFIG_FRAGMENTS
plural?
+ then
+ oe_runmake -C ${S} O=${B} ${UBOOT_MACHINE} ${UBOOT_CONFIG_FRAGMENT}
+ oe_runmake -C ${S} O=${B} olddefconfig
+ fi
So, this basically repeats configuration done in u-boot-configure.inc in
OE-Core. But it also ignores UBOOT_CONFIG support for multiple (def-)configs.
While I realize you just want to address a single use-case, making it a bit
future-proof shouldn't be overlooked.
Think of supporting both UBOOT_CONFIG and UBOOT_CONFIG_FRAGMENTS at the same
time. Probably completely rewriting do_configure from u-boot-configure.inc
would be needed...
BTW, UBOOT_CONFIG naming is unfortunate - it has nothing to do with config
fragments. While UBOOT_MACHINE specifies a single defconfig, UBOOT_CONFIG
takes a list of defconfigs and iterates through them building each separately.
Thanks for your suggestions. I appreciate your idea to cover all use
cases with u-boot-mergeconfig.inc, but I have few concerns due to
the current release situation we are into.
As far as I know, meta-ti does not have a use case for UBOOT_CONFIG
itself.
It does:
https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/conf/machine/am335x-hs-evm.conf#n7
Which means, since your new code is added to all TI platforms, it could
potentially break AM335x HS platform.
The code is wrapped behind the setting of UBOOT_CONFIG_FRAGMENT, so
unless we set both UBOOT_CONFIG_FRAGMENT and UBOOT_CONFIG in am335
it should be ok.
Correct, that's why I phrased it as "could potentially break". Maybe not even
specific to TI's AM335x HS, but to some downstream customer platform using
meta-ti. As meta-ti is not the end product.
Excellent point. We really do need to do this the right way and not
punt this too far off into the future to do the correct implementation.
We are using UBOOT_MACHINE for handling the base defconfig,
which works well for our needs. The concept of having u-boot
fragments was introduced recently in ti-u-boot after we got a
feedback from upstream uboot as around 90% of configs were same
between am62xx-evm & am62xxsip-evm. This was a valid input and hence
we considered in ti-u-boot. In order to support that I had to find a
quick way to handle this in Yocto it with UBOOT_MACHINE along with
UBOOT_CONFIG_FRAGMENT logic, which I had also discussed with you on
the syncup call.
Actually, the support was pretty much always there in U-boot, as kconfig
framework along with support for fragments by calling merge_config.sh was
borrowed from the kernel long ago and had been periodically synced with
latest. Though U-boot didn't have own in-tree config fragments until very
recently. First few got into the main config/ directory, but going forward
those will reside in the corresponding board/ directories...
Considering that the am62xxsip-evm release is only two weeks away,
can we consider the fragments approach for now and avoid any
potential risks or delays. I will work with you in coming weeks to
make this better by handling all the cases of uboot-config and
fragments.
Sure, this can be handled in stages. A bit more checks would be needed then
to avoid breaking at least UBOOT_CONFIG use case.
Please let me know if I you agree with my views and if I can proceed
with fixing the other issues you highlighted, they are trivial I can
submit a patch tomorrow.
--
Ryan Eatmon [email protected]
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16980):
https://lists.yoctoproject.org/g/meta-ti/message/16980
Mute This Topic: https://lists.yoctoproject.org/mt/101245468/21656
Group Owner: [email protected]
Unsubscribe:
https://lists.yoctoproject.org/g/meta-ti/leave/6695321/21656/1393940836/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
