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. > 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. > >>+} > >>diff --git a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti.inc > >>b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti.inc > >>index f3285c23..5292517b 100644 > >>--- a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti.inc > >>+++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti.inc > >>@@ -7,6 +7,7 @@ SPL_BINARY ?= "MLO" > >> require ${COREBASE}/meta/recipes-bsp/u-boot/u-boot-common.inc > >> require ${COREBASE}/meta/recipes-bsp/u-boot/u-boot.inc > >>+require u-boot-mergeconfig.inc > >> FILESEXTRAPATHS:prepend := "${THISDIR}/u-boot:" > >>-- > >>2.34.1
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16967): https://lists.yoctoproject.org/g/meta-ti/message/16967 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]] -=-=-=-=-=-=-=-=-=-=-=-
