[RFC PATCH 0/3] Minimal platform configuration

[RFC PATCH 0/3] Minimal platform configuration

[Jason Kacines]

When someone attempts to bring up a custom board using TI SoCs (am62x in
this case), it often takes several days for someone to reduce the
current configuration from the TI EVM/SK boards to a configuration that
works for their board.

The goal of these changes is to allow for a minimal boot configuration
to exist within UBoot that someone can access directly in order to
test their boards for a sign of life before beginning development. This
is all done with the hope to increase ease of use and reduce the
upbringing process from several days to a few hours.

With the use of fragments, the base defconfigs reside in configs/ and
the config fragments reside in board/../

There is still quite a lot of board specific code inside board_init_f()
that will need attention later, however this series begins the process
of splitting the am62x's configs into a separate generic defconfig
everyone can use for new board wakeups with individual board/ti/*.config
fragments for each board varient.

Jason Kacines (3):
  scripts: kconfig: Add config fragment support in board/../
  configs: Add am62x wakeup defconfigs
  board: ti: am62x: Add am62x_evm defconfig fragments

 board/ti/am62x/am62x_evm_a53.config           | 38 +++++++++++++
 board/ti/am62x/am62x_evm_r5.config            | 51 ++++++++++++++++++
 ..._evm_a53_defconfig => am62x_a53_defconfig} | 34 ++----------
 ...2x_evm_r5_defconfig => am62x_r5_defconfig} | 53 ++++---------------
 scripts/kconfig/Makefile                      |  4 +-
 5 files changed, 106 insertions(+), 74 deletions(-)
 create mode 100644 board/ti/am62x/am62x_evm_a53.config
 create mode 100644 board/ti/am62x/am62x_evm_r5.config
 rename configs/{am62x_evm_a53_defconfig => am62x_a53_defconfig} (72%)
 rename configs/{am62x_evm_r5_defconfig => am62x_r5_defconfig} (66%)

-- 
2.34.1

[RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Jason Kacines]

Add support to config fragments (.config) located in the /board
directory. This will allow only base defconfigs to live in /configs and
all fragments to live in their respective device directory in /board/..

Signed-off-by: Jason Kacines <j-kacines@ti.com>
---
 scripts/kconfig/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 12e525ee31..2d97aab8d2 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -99,7 +99,9 @@ endif
 %_config: %_defconfig
 	@:
 
-configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
+configfiles=$(wildcard $(srctree)/kernel/configs/$@ \
+		$(srctree)/arch/$(SRCARCH)/configs/$@ \
+		$(shell find $(srctree)/board -name "$@"))
 
 %.config: $(obj)/conf
 	$(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
-- 
2.34.1

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Simon Glass]

Hi Jason,

On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines@ti.com> wrote:
>
> Add support to config fragments (.config) located in the /board
> directory. This will allow only base defconfigs to live in /configs and

Does this mean defconfigs?

> all fragments to live in their respective device directory in /board/..

Why do we want this? The patch should have a motivation.

>
> Signed-off-by: Jason Kacines <j-kacines@ti.com>
> ---
>  scripts/kconfig/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 12e525ee31..2d97aab8d2 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -99,7 +99,9 @@ endif
>  %_config: %_defconfig
>         @:
>
> -configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
> +configfiles=$(wildcard $(srctree)/kernel/configs/$@ \
> +               $(srctree)/arch/$(SRCARCH)/configs/$@ \
> +               $(shell find $(srctree)/board -name "$@"))
>
>  %.config: $(obj)/conf
>         $(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
> --
> 2.34.1
>

Regards,
SImon

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> Hi Jason,
> 
> On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines@ti.com> wrote:
> >
> > Add support to config fragments (.config) located in the /board
> > directory. This will allow only base defconfigs to live in /configs and
> 
> Does this mean defconfigs?

This looks like it would cover defconfig files too, but the initial
motivation is config fragments.  See
https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamor95@gmail.com/
for another example.

> > all fragments to live in their respective device directory in /board/..
> 
> Why do we want this? The patch should have a motivation.

I've asked a few people to look in to this because we have a lot of
cases today of N _defconfig files where we could really instead have 1
_defconfig file and N config fragment files.  But I do not want them
living in the top level configs directory as that will get even more
unmanageable.

What's not in this patch (and not an ask at this point) is figuring out
how buildman could handle "foo_defconfig bar.config" as the required
config target.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Simon Glass]

Hi Tom,

On Thu, 13 Jul 2023 at 16:54, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> > Hi Jason,
> >
> > On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines@ti.com> wrote:
> > >
> > > Add support to config fragments (.config) located in the /board
> > > directory. This will allow only base defconfigs to live in /configs and
> >
> > Does this mean defconfigs?
>
> This looks like it would cover defconfig files too, but the initial
> motivation is config fragments.  See
> https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamor95@gmail.com/
> for another example.
>
> > > all fragments to live in their respective device directory in /board/..
> >
> > Why do we want this? The patch should have a motivation.
>
> I've asked a few people to look in to this because we have a lot of
> cases today of N _defconfig files where we could really instead have 1
> _defconfig file and N config fragment files.  But I do not want them
> living in the top level configs directory as that will get even more
> unmanageable.

OK I see, thank you. The patch still needs this motivation though.

>
> What's not in this patch (and not an ask at this point) is figuring out
> how buildman could handle "foo_defconfig bar.config" as the required
> config target.

Indeed. Also, should they appear in the boards.cfg list?

Regards,
Simon

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 13 Jul 2023 at 16:54, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> > > Hi Jason,
> > >
> > > On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines@ti.com> wrote:
> > > >
> > > > Add support to config fragments (.config) located in the /board
> > > > directory. This will allow only base defconfigs to live in /configs and
> > >
> > > Does this mean defconfigs?
> >
> > This looks like it would cover defconfig files too, but the initial
> > motivation is config fragments.  See
> > https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamor95@gmail.com/
> > for another example.
> >
> > > > all fragments to live in their respective device directory in /board/..
> > >
> > > Why do we want this? The patch should have a motivation.
> >
> > I've asked a few people to look in to this because we have a lot of
> > cases today of N _defconfig files where we could really instead have 1
> > _defconfig file and N config fragment files.  But I do not want them
> > living in the top level configs directory as that will get even more
> > unmanageable.
> 
> OK I see, thank you. The patch still needs this motivation though.

So you're saying you want the message re-worded?

> > What's not in this patch (and not an ask at this point) is figuring out
> > how buildman could handle "foo_defconfig bar.config" as the required
> > config target.
> 
> Indeed. Also, should they appear in the boards.cfg list?

I doubt it? I'm not sure yet how we address getting buildman to know
about valid additional combinations. Take the example of something like:
som_vendor_carrier_defconfig + som_vendor_imx7_som.config +
emmc_boot_instead.config + customer_production_tweaks.config

How would you want buildman to know about that? Does it even really need
to, on the other hand?  And that's not I think an uncommon example, it's
just splitting colibri_imx7_emmc_defconfig in to how it would be used by
someone taking that carrier+som to production, with their own
touchscreen and a few other tweaks in the dtb that needs to be passed to
linux.  Or the mnt reform with whatever SOM/COM you happen to have for
it.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Simon Glass]

Hi,

On Sun, 16 Jul 2023 at 09:12, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 13 Jul 2023 at 16:54, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> > > > Hi Jason,
> > > >
> > > > On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines@ti.com> wrote:
> > > > >
> > > > > Add support to config fragments (.config) located in the /board
> > > > > directory. This will allow only base defconfigs to live in /configs and
> > > >
> > > > Does this mean defconfigs?
> > >
> > > This looks like it would cover defconfig files too, but the initial
> > > motivation is config fragments.  See
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamor95@gmail.com/
> > > for another example.
> > >
> > > > > all fragments to live in their respective device directory in /board/..
> > > >
> > > > Why do we want this? The patch should have a motivation.
> > >
> > > I've asked a few people to look in to this because we have a lot of
> > > cases today of N _defconfig files where we could really instead have 1
> > > _defconfig file and N config fragment files.  But I do not want them
> > > living in the top level configs directory as that will get even more
> > > unmanageable.
> >
> > OK I see, thank you. The patch still needs this motivation though.
>
> So you're saying you want the message re-worded?

Yes, to explain why.

Could we also get some docs in doc/build/gcc.rst or similar?

>
> > > What's not in this patch (and not an ask at this point) is figuring out
> > > how buildman could handle "foo_defconfig bar.config" as the required
> > > config target.
> >
> > Indeed. Also, should they appear in the boards.cfg list?
>
> I doubt it? I'm not sure yet how we address getting buildman to know
> about valid additional combinations. Take the example of something like:
> som_vendor_carrier_defconfig + som_vendor_imx7_som.config +
> emmc_boot_instead.config + customer_production_tweaks.config
>
> How would you want buildman to know about that? Does it even really need
> to, on the other hand?  And that's not I think an uncommon example, it's
> just splitting colibri_imx7_emmc_defconfig in to how it would be used by
> someone taking that carrier+som to production, with their own
> touchscreen and a few other tweaks in the dtb that needs to be passed to
> linux.  Or the mnt reform with whatever SOM/COM you happen to have for
> it.

Well firstly we should only worry about things that are in-tree.

The thing is, if we don't validate that the configs at least build,
then someone could change a config (anywhere in Kconfig or in a 'base'
defconfig) and break the build for these 'add-on' configs. Also if
there is no record of what fragments can be built with what, it could
get awfully confusing.

I would suggest an interface where you can query which fragments are
available for a board, and that buildman support building them. For
that to work, we need some sort of structure. For example the config
fragment could have a line listing the defconfig / .config filename it
is intended to augment.

Regards,
Simon

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5213 bytes --]

On Tue, Jul 18, 2023 at 07:07:58PM -0600, Simon Glass wrote:
> Hi,
> 
> On Sun, 16 Jul 2023 at 09:12, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 13 Jul 2023 at 16:54, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> > > > > Hi Jason,
> > > > >
> > > > > On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines@ti.com> wrote:
> > > > > >
> > > > > > Add support to config fragments (.config) located in the /board
> > > > > > directory. This will allow only base defconfigs to live in /configs and
> > > > >
> > > > > Does this mean defconfigs?
> > > >
> > > > This looks like it would cover defconfig files too, but the initial
> > > > motivation is config fragments.  See
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamor95@gmail.com/
> > > > for another example.
> > > >
> > > > > > all fragments to live in their respective device directory in /board/..
> > > > >
> > > > > Why do we want this? The patch should have a motivation.
> > > >
> > > > I've asked a few people to look in to this because we have a lot of
> > > > cases today of N _defconfig files where we could really instead have 1
> > > > _defconfig file and N config fragment files.  But I do not want them
> > > > living in the top level configs directory as that will get even more
> > > > unmanageable.
> > >
> > > OK I see, thank you. The patch still needs this motivation though.
> >
> > So you're saying you want the message re-worded?
> 
> Yes, to explain why.

I think the message is fine as it clearly says what it does.

> Could we also get some docs in doc/build/gcc.rst or similar?

No, I don't think that makes sense yet.  And looking at that doc, we
should split that up in to compiler specifics and then a general build
doc.  Using fragments belongs in the board docs which use fragments (as
is done in the series which have boards using fragments) and as a
general "do this to make developing your board easier" that should come
later once there's more agreement and understanding of what we can and
should do with fragments, rather than meta-options in Kconfig.

> > > > What's not in this patch (and not an ask at this point) is figuring out
> > > > how buildman could handle "foo_defconfig bar.config" as the required
> > > > config target.
> > >
> > > Indeed. Also, should they appear in the boards.cfg list?
> >
> > I doubt it? I'm not sure yet how we address getting buildman to know
> > about valid additional combinations. Take the example of something like:
> > som_vendor_carrier_defconfig + som_vendor_imx7_som.config +
> > emmc_boot_instead.config + customer_production_tweaks.config
> >
> > How would you want buildman to know about that? Does it even really need
> > to, on the other hand?  And that's not I think an uncommon example, it's
> > just splitting colibri_imx7_emmc_defconfig in to how it would be used by
> > someone taking that carrier+som to production, with their own
> > touchscreen and a few other tweaks in the dtb that needs to be passed to
> > linux.  Or the mnt reform with whatever SOM/COM you happen to have for
> > it.
> 
> Well firstly we should only worry about things that are in-tree.

Well, since I'm not letting people bring in fragments until it won't
make the configs directory even more unmanageable, we have a problem.
The problem which this patch solves.  And the example I gave above is
in-tree, except for the final step of "now make this my product", which
when it's a matter of a new device tree and config, is fine for most
cases.

> The thing is, if we don't validate that the configs at least build,
> then someone could change a config (anywhere in Kconfig or in a 'base'
> defconfig) and break the build for these 'add-on' configs. Also if

I'm not worried about this at the start. If people start trying to
enable unique drivers only in fragments, we have a problem. But based on
all of the proposed uses so far, we shouldn't see unique settings there
that we need to have compile tested all the time.

> there is no record of what fragments can be built with what, it could
> get awfully confusing.

Exactly why I want these fragments to be able to live in the board
directory rather than the top level configs directory.  Honestly, this
also opens up the possibility of moving the defconfig files from
configs/ to the board directory and I think that would be really good.

> I would suggest an interface where you can query which fragments are
> available for a board, and that buildman support building them. For
> that to work, we need some sort of structure. For example the config
> fragment could have a line listing the defconfig / .config filename it
> is intended to augment.

I'm not sure how buildman will handle fragments, if at all, but that's a
secondary consideration.  Buildman isn't used by most people and in most
cases, "make" is, and that supports (and has supported for I don't know
how many years, off-hand) config fragments.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Simon Glass]

Hi Tom,

On Wed, 19 Jul 2023 at 07:34, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Jul 18, 2023 at 07:07:58PM -0600, Simon Glass wrote:
> > Hi,
> >
> > On Sun, 16 Jul 2023 at 09:12, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 13 Jul 2023 at 16:54, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> > > > > > Hi Jason,
> > > > > >
> > > > > > On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines@ti.com> wrote:
> > > > > > >
> > > > > > > Add support to config fragments (.config) located in the /board
> > > > > > > directory. This will allow only base defconfigs to live in /configs and
> > > > > >
> > > > > > Does this mean defconfigs?
> > > > >
> > > > > This looks like it would cover defconfig files too, but the initial
> > > > > motivation is config fragments.  See
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamor95@gmail.com/
> > > > > for another example.
> > > > >
> > > > > > > all fragments to live in their respective device directory in /board/..
> > > > > >
> > > > > > Why do we want this? The patch should have a motivation.
> > > > >
> > > > > I've asked a few people to look in to this because we have a lot of
> > > > > cases today of N _defconfig files where we could really instead have 1
> > > > > _defconfig file and N config fragment files.  But I do not want them
> > > > > living in the top level configs directory as that will get even more
> > > > > unmanageable.
> > > >
> > > > OK I see, thank you. The patch still needs this motivation though.
> > >
> > > So you're saying you want the message re-worded?
> >
> > Yes, to explain why.
>
> I think the message is fine as it clearly says what it does.
>
> > Could we also get some docs in doc/build/gcc.rst or similar?
>
> No, I don't think that makes sense yet.  And looking at that doc, we
> should split that up in to compiler specifics and then a general build
> doc.  Using fragments belongs in the board docs which use fragments (as

Indeed.

+Heinrich Schuchardt perhaps?

> is done in the series which have boards using fragments) and as a
> general "do this to make developing your board easier" that should come
> later once there's more agreement and understanding of what we can and
> should do with fragments, rather than meta-options in Kconfig.

Yes it is that understanding that I am missing.

>
> > > > > What's not in this patch (and not an ask at this point) is figuring out
> > > > > how buildman could handle "foo_defconfig bar.config" as the required
> > > > > config target.
> > > >
> > > > Indeed. Also, should they appear in the boards.cfg list?
> > >
> > > I doubt it? I'm not sure yet how we address getting buildman to know
> > > about valid additional combinations. Take the example of something like:
> > > som_vendor_carrier_defconfig + som_vendor_imx7_som.config +
> > > emmc_boot_instead.config + customer_production_tweaks.config
> > >
> > > How would you want buildman to know about that? Does it even really need
> > > to, on the other hand?  And that's not I think an uncommon example, it's
> > > just splitting colibri_imx7_emmc_defconfig in to how it would be used by
> > > someone taking that carrier+som to production, with their own
> > > touchscreen and a few other tweaks in the dtb that needs to be passed to
> > > linux.  Or the mnt reform with whatever SOM/COM you happen to have for
> > > it.
> >
> > Well firstly we should only worry about things that are in-tree.
>
> Well, since I'm not letting people bring in fragments until it won't
> make the configs directory even more unmanageable, we have a problem.
> The problem which this patch solves.  And the example I gave above is
> in-tree, except for the final step of "now make this my product", which
> when it's a matter of a new device tree and config, is fine for most
> cases.

My objection is really that this changes / adds behaviour for which
there is no mention in the docs. I didn't even know about this stuff.

>
> > The thing is, if we don't validate that the configs at least build,
> > then someone could change a config (anywhere in Kconfig or in a 'base'
> > defconfig) and break the build for these 'add-on' configs. Also if
>
> I'm not worried about this at the start. If people start trying to
> enable unique drivers only in fragments, we have a problem. But based on
> all of the proposed uses so far, we shouldn't see unique settings there
> that we need to have compile tested all the time.

OK

>
> > there is no record of what fragments can be built with what, it could
> > get awfully confusing.
>
> Exactly why I want these fragments to be able to live in the board
> directory rather than the top level configs directory.  Honestly, this
> also opens up the possibility of moving the defconfig files from
> configs/ to the board directory and I think that would be really good.

Yes it would be easier, since we can presumably still enumerate them
using MAINTAINERS

>
> > I would suggest an interface where you can query which fragments are
> > available for a board, and that buildman support building them. For
> > that to work, we need some sort of structure. For example the config
> > fragment could have a line listing the defconfig / .config filename it
> > is intended to augment.
>
> I'm not sure how buildman will handle fragments, if at all, but that's a
> secondary consideration.  Buildman isn't used by most people and in most
> cases, "make" is, and that supports (and has supported for I don't know
> how many years, off-hand) config fragments.

OK, well if it becomes a problem we can worry about it then.

Regards,
Simon

[PATCH] doc: Begin adding a best practices document for board ports

[Tom Rini]

To help guide developers down the right path, begin a document that
lists some best practices to follow when creating a new board port.

Signed-off-by: Tom Rini <trini@konsulko.com>
---
 doc/develop/board_best_practices.rst | 26 ++++++++++++++++++++++++++
 doc/develop/index.rst                |  1 +
 2 files changed, 27 insertions(+)
 create mode 100644 doc/develop/board_best_practices.rst

diff --git a/doc/develop/board_best_practices.rst b/doc/develop/board_best_practices.rst
new file mode 100644
index 000000000000..835ea86dedb2
--- /dev/null
+++ b/doc/develop/board_best_practices.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+Best Practices for Board Ports
+==============================
+
+In addition to the regular best practices such as using :doc:`checkpatch` and
+following :doc:`docstyle` and :doc:`codingstyle` there are some things which
+are specific to creating a new board port.
+
+* Implement :doc:`bootstd` to ensure that the most number of operating systems
+  will be available for the platform.
+
+* The platform defconfig file must be generated via `make savedefconfig`.
+
+* The Kconfig and Kbuild infrastructure supports using "fragments" tha can be
+  used to make changes on top of a defconfig file.  These can be useful for
+  many things such as:
+
+  * Supporting different firmware locations (e.g. eMMC, SD, QSPI).
+
+  * Multiple board variants when runtime detection is not desired.
+
+  * Supporting different build types such as production and development.
+
+  And when used should reside in the board directory itself rather than the
+  top-level `configs/` directory.
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 263d404b4ca8..5b230d0321f2 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -9,6 +9,7 @@ General
 .. toctree::
    :maxdepth: 1
 
+   board_best_practices
    codingstyle
    designprinciples
    docstyle
-- 
2.34.1

Re: [PATCH] doc: Begin adding a best practices document for board ports

[Heinrich Schuchardt]

On 8/8/23 00:15, Tom Rini wrote:
> To help guide developers down the right path, begin a document that
> lists some best practices to follow when creating a new board port.
> 
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
>   doc/develop/board_best_practices.rst | 26 ++++++++++++++++++++++++++
>   doc/develop/index.rst                |  1 +
>   2 files changed, 27 insertions(+)
>   create mode 100644 doc/develop/board_best_practices.rst
> 
> diff --git a/doc/develop/board_best_practices.rst b/doc/develop/board_best_practices.rst
> new file mode 100644
> index 000000000000..835ea86dedb2
> --- /dev/null
> +++ b/doc/develop/board_best_practices.rst
> @@ -0,0 +1,26 @@
> +.. SPDX-License-Identifier: GPL-2.0+:
> +
> +Best Practices for Board Ports
> +==============================
> +
> +In addition to the regular best practices such as using :doc:`checkpatch` and
> +following :doc:`docstyle` and :doc:`codingstyle` there are some things which
> +are specific to creating a new board port.
> +
> +* Implement :doc:`bootstd` to ensure that the most number of operating systems

This looks helpful. Just a few suggestions:

"to ensure that most operating systems will be supported by the platform."

> +  will be available for the platform.
> +
> +* The platform defconfig file must be generated via `make savedefconfig`.
> +
> +* The Kconfig and Kbuild infrastructure supports using "fragments" tha can be

%s/tha/that/

> +  used to make changes on top of a defconfig file.  These can be useful for

Maybe: %s/to make/to apply/

> +  many things such as:
> +
> +  * Supporting different firmware locations (e.g. eMMC, SD, QSPI).
> +
> +  * Multiple board variants when runtime detection is not desired.
> +
> +  * Supporting different build types such as production and development.
> +
> +  And when used should reside in the board directory itself rather than the

%s/And when used should/Kconfig fragments should/

%s/rather than the/rather than in the/

Best regards

Heinrich

> +  top-level `configs/` directory.
> diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> index 263d404b4ca8..5b230d0321f2 100644
> --- a/doc/develop/index.rst
> +++ b/doc/develop/index.rst
> @@ -9,6 +9,7 @@ General
>   .. toctree::
>      :maxdepth: 1
>   
> +   board_best_practices
>      codingstyle
>      designprinciples
>      docstyle

[v2] doc: Begin adding a best practices document for board ports

[Tom Rini]

To help guide developers down the right path, begin a document that
lists some best practices to follow when creating a new board port.

Signed-off-by: Tom Rini <trini@konsulko.com>
---
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Changes in v2:
- Apply feedback from Heinrich
---
 doc/develop/board_best_practices.rst | 26 ++++++++++++++++++++++++++
 doc/develop/index.rst                |  1 +
 2 files changed, 27 insertions(+)
 create mode 100644 doc/develop/board_best_practices.rst

diff --git a/doc/develop/board_best_practices.rst b/doc/develop/board_best_practices.rst
new file mode 100644
index 000000000000..b012ac59e232
--- /dev/null
+++ b/doc/develop/board_best_practices.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+Best Practices for Board Ports
+==============================
+
+In addition to the regular best practices such as using :doc:`checkpatch` and
+following :doc:`docstyle` and :doc:`codingstyle` there are some things which
+are specific to creating a new board port.
+
+* Implement :doc:`bootstd` to ensure that most operating systems will be
+  supported by the platform.
+
+* The platform defconfig file must be generated via `make savedefconfig`.
+
+* The Kconfig and Kbuild infrastructure supports using "fragments" that can be
+  used to apply changes on top of a defconfig file.  These can be useful for
+  many things such as:
+
+  * Supporting different firmware locations (e.g. eMMC, SD, QSPI).
+
+  * Multiple board variants when runtime detection is not desired.
+
+  * Supporting different build types such as production and development.
+
+  Kconfig fragments should reside in the board directory itself rather than in
+  the top-level `configs/` directory.
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 263d404b4ca8..5b230d0321f2 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -9,6 +9,7 @@ General
 .. toctree::
    :maxdepth: 1
 
+   board_best_practices
    codingstyle
    designprinciples
    docstyle
-- 
2.34.1

Re: [v2] doc: Begin adding a best practices document for board ports

[Simon Glass]

On Tue, 8 Aug 2023 at 14:36, Tom Rini <trini@konsulko.com> wrote:
>
> To help guide developers down the right path, begin a document that
> lists some best practices to follow when creating a new board port.
>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Changes in v2:
> - Apply feedback from Heinrich
> ---
>  doc/develop/board_best_practices.rst | 26 ++++++++++++++++++++++++++
>  doc/develop/index.rst                |  1 +
>  2 files changed, 27 insertions(+)
>  create mode 100644 doc/develop/board_best_practices.rst

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Tue, Jul 11, 2023 at 04:20:46PM -0500, Jason Kacines wrote:

> Add support to config fragments (.config) located in the /board
> directory. This will allow only base defconfigs to live in /configs and
> all fragments to live in their respective device directory in /board/..
> 
> Signed-off-by: Jason Kacines <j-kacines@ti.com>

Applied to u-boot/next, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[RFC PATCH 2/3] configs: Add am62x wakeup defconfigs

[Jason Kacines]

Introduce a minimal platform wakeup configuration for am62x devices.
These defconfigs are meant to serve as a foundation for custom boards to
build upon by only including necessary components to boot the device.

Defconfig fragments will be used to expand upon these base files.

Signed-off-by: Jason Kacines <j-kacines@ti.com>
---
 configs/am62x_a53_defconfig | 78 ++++++++++++++++++++++++++++++
 configs/am62x_r5_defconfig  | 94 +++++++++++++++++++++++++++++++++++++
 2 files changed, 172 insertions(+)
 create mode 100644 configs/am62x_a53_defconfig
 create mode 100644 configs/am62x_r5_defconfig

diff --git a/configs/am62x_a53_defconfig b/configs/am62x_a53_defconfig
new file mode 100644
index 0000000000..baaa229b34
--- /dev/null
+++ b/configs/am62x_a53_defconfig
@@ -0,0 +1,78 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_AM625=y
+CONFIG_K3_ATF_LOAD_ADDR=0x9e780000
+CONFIG_TARGET_AM625_A53_EVM=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b80000
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-sk"
+CONFIG_SPL_TEXT_BASE=0x80080000
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x82000000
+CONFIG_SPL_SIZE_LIMIT=0x40000
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_CMD_PXE is not set
+# CONFIG_CMD_DHCP is not set
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x81000000
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern; setenv fdtfile ti/${name_fdt}; run distro_bootcmd"
+CONFIG_SPL_MAX_SIZE=0x58000
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x80c80000
+CONFIG_SPL_BSS_MAX_SIZE=0x80000
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_CMD_MMC=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+# CONFIG_NET is not set
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+# CONFIG_SPL_YMODEM_SUPPORT is not set
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
diff --git a/configs/am62x_r5_defconfig b/configs/am62x_r5_defconfig
new file mode 100644
index 0000000000..64ae24bc90
--- /dev/null
+++ b/configs/am62x_r5_defconfig
@@ -0,0 +1,94 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SOC_K3_AM625=y
+CONFIG_TARGET_AM625_R5_EVM=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43c3a7f0
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
+CONFIG_SPL_TEXT_BASE=0x43c00000
+CONFIG_DM_RESET=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x82000000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x7000
+CONFIG_SPL_SIZE_LIMIT=0x3A7F0
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_LEGACY_IMAGE_FORMAT is not set
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_MAX_SIZE=0x3B000
+CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x43c3b000
+CONFIG_SPL_BSS_MAX_SIZE=0x3000
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x84000000
+CONFIG_SYS_SPL_MALLOC_SIZE=0x1000000
+CONFIG_SPL_EARLY_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_REMOTEPROC=y
+# CONFIG_SPL_YMODEM_SUPPORT is not set
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent interrupts"
+# CONFIG_NET is not set
+# CONFIG_BOOTDEV_ETH is not set
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_SPL_CLK_CCF=y
+CONFIG_SPL_CLK_K3_PLL=y
+CONFIG_SPL_CLK_K3=y
+CONFIG_TI_SCI_PROTOCOL=y
+# CONFIG_GPIO is not set
+# CONFIG_I2C is not set
+# CONFIG_INPUT is not set
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_TIMER=y
+CONFIG_SPL_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_LIB_RATIONAL=y
+CONFIG_SPL_LIB_RATIONAL=y
-- 
2.34.1

[RFC PATCH 3/3] board: ti: am62x: Add am62x_evm defconfig fragments

[Jason Kacines]

Introduce am62x_evm defconfig fragments that will be used on top of the
base wakeup defconfigs. The usage will be as follows:

make <...> am62x_r5_defconfig am62x_evm_r5.config
make <...> am62x_a53_defconfig am62x_evm_a53.config

This will use the Makefile changes previously mentioned to access the
.config fragments from /board/../

Also remove the original am62x_evm defconfigs now that fragments will be
used to support to the board.

Signed-off-by: Jason Kacines <j-kacines@ti.com>
---
 board/ti/am62x/am62x_evm_a53.config |  38 +++++++++
 board/ti/am62x/am62x_evm_r5.config  |  51 +++++++++++
 configs/am62x_evm_a53_defconfig     | 104 -----------------------
 configs/am62x_evm_r5_defconfig      | 127 ----------------------------
 4 files changed, 89 insertions(+), 231 deletions(-)
 create mode 100644 board/ti/am62x/am62x_evm_a53.config
 create mode 100644 board/ti/am62x/am62x_evm_r5.config
 delete mode 100644 configs/am62x_evm_a53_defconfig
 delete mode 100644 configs/am62x_evm_r5_defconfig

diff --git a/board/ti/am62x/am62x_evm_a53.config b/board/ti/am62x/am62x_evm_a53.config
new file mode 100644
index 0000000000..383bb4597a
--- /dev/null
+++ b/board/ti/am62x/am62x_evm_a53.config
@@ -0,0 +1,38 @@
+# CONFIG_TI_SECURE_DEVICE is not set
+CONFIG_SF_DEFAULT_SPEED=25000000
+CONFIG_SPL_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-sk"
+CONFIG_SPL_OF_LIST="k3-am625-sk"
+CONFIG_OF_LIST="k3-am625-sk"
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_DM_SPI_FLASH=y
+# CONFIG_SPL_SPI_FLASH_TINY is not set
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x280000
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_SYS_BOOTM_LEN=0x800000
+CONFIG_CMD_PXE=y
+CONFIG_CMD_DHCP=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HX_T=y
+CONFIG_NET=y
+CONFIG_PHY_TI_DP83867=y
+CONFIG_PHY_FIXED=y
+CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
diff --git a/board/ti/am62x/am62x_evm_r5.config b/board/ti/am62x/am62x_evm_r5.config
new file mode 100644
index 0000000000..5dffab74f6
--- /dev/null
+++ b/board/ti/am62x/am62x_evm_r5.config
@@ -0,0 +1,51 @@
+# CONFIG_TI_SECURE_DEVICE is not set
+CONFIG_SYS_MALLOC_LEN=0x08000000
+CONFIG_SYS_MALLOC_F_LEN=0x9000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SF_DEFAULT_SPEED=25000000
+CONFIG_SF_DEFAULT_MODE=0
+CONFIG_ENV_SIZE=0x20000
+CONFIG_GPIO=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
+CONFIG_SPL_DRIVERS_MISC=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_I2C=y
+CONFIG_INPUT=y
+CONFIG_NET=y
+CONFIG_BOOTDEV_ETH=y
+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+# CONFIG_SPL_SPI_FLASH_TINY is not set
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x80000
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_DFU=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_SPL_MISC=y
+CONFIG_ESM_K3=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HX_T=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
deleted file mode 100644
index 7c3bc184cf..0000000000
--- a/configs/am62x_evm_a53_defconfig
+++ /dev/null
@@ -1,104 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_K3=y
-CONFIG_TI_SECURE_DEVICE=y
-CONFIG_SYS_MALLOC_F_LEN=0x8000
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SOC_K3_AM625=y
-CONFIG_K3_ATF_LOAD_ADDR=0x9e780000
-CONFIG_TARGET_AM625_A53_EVM=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b80000
-CONFIG_SF_DEFAULT_SPEED=25000000
-CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="k3-am625-sk"
-CONFIG_SPL_TEXT_BASE=0x80080000
-CONFIG_OF_LIBFDT_OVERLAY=y
-CONFIG_DM_RESET=y
-CONFIG_SPL_MMC=y
-CONFIG_SPL_SERIAL=y
-CONFIG_SPL_STACK_R_ADDR=0x82000000
-CONFIG_SPL_SIZE_LIMIT=0x40000
-CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800
-CONFIG_SPL_FS_FAT=y
-CONFIG_SPL_LIBDISK_SUPPORT=y
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
-CONFIG_SPL_SPI=y
-# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_LOAD_FIT_ADDRESS=0x81000000
-CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern; setenv fdtfile ti/${name_fdt}; run distro_bootcmd"
-CONFIG_SPL_MAX_SIZE=0x58000
-CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-CONFIG_SPL_BSS_START_ADDR=0x80c80000
-CONFIG_SPL_BSS_MAX_SIZE=0x80000
-CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_STACK_R=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
-CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
-CONFIG_SPL_DM_MAILBOX=y
-CONFIG_SPL_DM_SPI_FLASH=y
-CONFIG_SPL_POWER_DOMAIN=y
-# CONFIG_SPL_SPI_FLASH_TINY is not set
-CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x280000
-CONFIG_SPL_YMODEM_SUPPORT=y
-CONFIG_SYS_BOOTM_LEN=0x800000
-CONFIG_CMD_MMC=y
-CONFIG_OF_CONTROL=y
-CONFIG_SPL_OF_CONTROL=y
-CONFIG_MULTI_DTB_FIT=y
-CONFIG_SPL_MULTI_DTB_FIT=y
-CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
-CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_SPL_DM=y
-CONFIG_SPL_DM_SEQ_ALIAS=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SPL_OF_TRANSLATE=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
-CONFIG_CLK_TI_SCI=y
-CONFIG_DMA_CHANNELS=y
-CONFIG_TI_K3_NAVSS_UDMA=y
-CONFIG_TI_SCI_PROTOCOL=y
-CONFIG_DM_MAILBOX=y
-CONFIG_K3_SEC_PROXY=y
-CONFIG_MMC_SDHCI=y
-CONFIG_MMC_SDHCI_ADMA=y
-CONFIG_SPL_MMC_SDHCI_ADMA=y
-CONFIG_MMC_SDHCI_AM654=y
-CONFIG_DM_SPI_FLASH=y
-CONFIG_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPI_FLASH_SOFT_RESET=y
-CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
-CONFIG_SPI_FLASH_SPANSION=y
-CONFIG_SPI_FLASH_S28HX_T=y
-CONFIG_PHY_TI_DP83867=y
-CONFIG_PHY_FIXED=y
-CONFIG_TI_AM65_CPSW_NUSS=y
-CONFIG_PHY=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_PINCTRL_SINGLE=y
-CONFIG_POWER_DOMAIN=y
-CONFIG_TI_SCI_POWER_DOMAIN=y
-CONFIG_K3_SYSTEM_CONTROLLER=y
-CONFIG_REMOTEPROC_TI_K3_ARM64=y
-CONFIG_RESET_TI_SCI=y
-CONFIG_DM_SERIAL=y
-CONFIG_SOC_DEVICE=y
-CONFIG_SOC_DEVICE_TI_K3=y
-CONFIG_SOC_TI=y
-CONFIG_SPI=y
-CONFIG_DM_SPI=y
-CONFIG_CADENCE_QSPI=y
-CONFIG_SYSRESET=y
-CONFIG_SPL_SYSRESET=y
-CONFIG_SYSRESET_TI_SCI=y
-CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig
deleted file mode 100644
index 3c5f367298..0000000000
--- a/configs/am62x_evm_r5_defconfig
+++ /dev/null
@@ -1,127 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_K3=y
-CONFIG_TI_SECURE_DEVICE=y
-CONFIG_SYS_MALLOC_LEN=0x08000000
-CONFIG_SYS_MALLOC_F_LEN=0x9000
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SOC_K3_AM625=y
-CONFIG_TARGET_AM625_R5_EVM=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43c3a7f0
-CONFIG_SF_DEFAULT_SPEED=25000000
-CONFIG_SF_DEFAULT_MODE=0
-CONFIG_ENV_SIZE=0x20000
-CONFIG_DM_GPIO=y
-CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
-CONFIG_SPL_TEXT_BASE=0x43c00000
-CONFIG_DM_RESET=y
-CONFIG_SPL_MMC=y
-CONFIG_SPL_SERIAL=y
-CONFIG_SPL_DRIVERS_MISC=y
-CONFIG_SPL_STACK_R_ADDR=0x82000000
-CONFIG_SPL_SYS_MALLOC_F_LEN=0x7000
-CONFIG_SPL_SIZE_LIMIT=0x3A7F0
-CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500
-CONFIG_SPL_FS_FAT=y
-CONFIG_SPL_LIBDISK_SUPPORT=y
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
-CONFIG_SPL_SPI=y
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000
-# CONFIG_DISPLAY_CPUINFO is not set
-CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
-CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
-CONFIG_SPL_MAX_SIZE=0x3B000
-CONFIG_SPL_PAD_TO=0x0
-CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-CONFIG_SPL_BSS_START_ADDR=0x43c3b000
-CONFIG_SPL_BSS_MAX_SIZE=0x3000
-CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_STACK_R=y
-CONFIG_SPL_SEPARATE_BSS=y
-CONFIG_SYS_SPL_MALLOC=y
-CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
-CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x84000000
-CONFIG_SYS_SPL_MALLOC_SIZE=0x1000000
-CONFIG_SPL_EARLY_BSS=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
-CONFIG_SPL_DM_MAILBOX=y
-CONFIG_SPL_DM_SPI_FLASH=y
-CONFIG_SPL_DM_RESET=y
-CONFIG_SPL_POWER_DOMAIN=y
-CONFIG_SPL_RAM_SUPPORT=y
-CONFIG_SPL_RAM_DEVICE=y
-CONFIG_SPL_REMOTEPROC=y
-# CONFIG_SPL_SPI_FLASH_TINY is not set
-CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x80000
-CONFIG_SPL_YMODEM_SUPPORT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_ASKENV=y
-CONFIG_CMD_DFU=y
-CONFIG_CMD_GPT=y
-CONFIG_CMD_MMC=y
-CONFIG_CMD_REMOTEPROC=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_TIME=y
-CONFIG_CMD_FAT=y
-CONFIG_OF_CONTROL=y
-CONFIG_SPL_OF_CONTROL=y
-CONFIG_SPL_MULTI_DTB_FIT=y
-CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
-CONFIG_SYS_RELOC_GD_ENV_ADDR=y
-CONFIG_SPL_DM=y
-CONFIG_SPL_DM_SEQ_ALIAS=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SPL_OF_TRANSLATE=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
-CONFIG_SPL_CLK_CCF=y
-CONFIG_SPL_CLK_K3_PLL=y
-CONFIG_SPL_CLK_K3=y
-CONFIG_TI_SCI_PROTOCOL=y
-CONFIG_DA8XX_GPIO=y
-CONFIG_DM_MAILBOX=y
-CONFIG_K3_SEC_PROXY=y
-CONFIG_SPL_MISC=y
-CONFIG_ESM_K3=y
-CONFIG_MMC_SDHCI=y
-CONFIG_MMC_SDHCI_ADMA=y
-CONFIG_SPL_MMC_SDHCI_ADMA=y
-CONFIG_MMC_SDHCI_AM654=y
-CONFIG_DM_SPI_FLASH=y
-CONFIG_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPI_FLASH_SOFT_RESET=y
-CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
-CONFIG_SPI_FLASH_SPANSION=y
-CONFIG_SPI_FLASH_S28HX_T=y
-CONFIG_PINCTRL=y
-# CONFIG_PINCTRL_GENERIC is not set
-CONFIG_SPL_PINCTRL=y
-# CONFIG_SPL_PINCTRL_GENERIC is not set
-CONFIG_PINCTRL_SINGLE=y
-CONFIG_POWER_DOMAIN=y
-CONFIG_TI_POWER_DOMAIN=y
-CONFIG_K3_SYSTEM_CONTROLLER=y
-CONFIG_REMOTEPROC_TI_K3_ARM64=y
-CONFIG_RESET_TI_SCI=y
-CONFIG_SPECIFY_CONSOLE_INDEX=y
-CONFIG_DM_SERIAL=y
-CONFIG_SOC_DEVICE=y
-CONFIG_SOC_DEVICE_TI_K3=y
-CONFIG_SOC_TI=y
-CONFIG_SPI=y
-CONFIG_DM_SPI=y
-CONFIG_CADENCE_QSPI=y
-CONFIG_TIMER=y
-CONFIG_SPL_TIMER=y
-CONFIG_OMAP_TIMER=y
-CONFIG_LIB_RATIONAL=y
-CONFIG_SPL_LIB_RATIONAL=y
-- 
2.34.1

Re: [RFC PATCH 0/3] Minimal platform configuration

[Simon Glass]

Hi Jason,

On Tue, 11 Jul 2023 at 16:28, Jason Kacines <j-kacines@ti.com> wrote:
>
> When someone attempts to bring up a custom board using TI SoCs (am62x in
> this case), it often takes several days for someone to reduce the
> current configuration from the TI EVM/SK boards to a configuration that
> works for their board.
>
> The goal of these changes is to allow for a minimal boot configuration
> to exist within UBoot that someone can access directly in order to
> test their boards for a sign of life before beginning development. This
> is all done with the hope to increase ease of use and reduce the
> upbringing process from several days to a few hours.
>
> With the use of fragments, the base defconfigs reside in configs/ and
> the config fragments reside in board/../
>
> There is still quite a lot of board specific code inside board_init_f()
> that will need attention later, however this series begins the process
> of splitting the am62x's configs into a separate generic defconfig
> everyone can use for new board wakeups with individual board/ti/*.config
> fragments for each board varient.

How about setting up some common defaults for your arch using Kconfig,
so that the board defconfigs are much smaller?

In general, boards in U-Boot have far too many individual settings.
Most of them should use a sensible default.

Going in the direction you have here just continues that tradition,
inventing what I feel is an unnecessary solution.

Regards,
Simon

Re: [RFC PATCH 0/3] Minimal platform configuration

[Nishanth Menon]

On 08:00-20230712, Simon Glass wrote:
> Hi Jason,
> 
> On Tue, 11 Jul 2023 at 16:28, Jason Kacines <j-kacines@ti.com> wrote:
> >
> > When someone attempts to bring up a custom board using TI SoCs (am62x in
> > this case), it often takes several days for someone to reduce the
> > current configuration from the TI EVM/SK boards to a configuration that
> > works for their board.
> >
> > The goal of these changes is to allow for a minimal boot configuration
> > to exist within UBoot that someone can access directly in order to
> > test their boards for a sign of life before beginning development. This
> > is all done with the hope to increase ease of use and reduce the
> > upbringing process from several days to a few hours.
> >
> > With the use of fragments, the base defconfigs reside in configs/ and
> > the config fragments reside in board/../
> >
> > There is still quite a lot of board specific code inside board_init_f()
> > that will need attention later, however this series begins the process
> > of splitting the am62x's configs into a separate generic defconfig
> > everyone can use for new board wakeups with individual board/ti/*.config
> > fragments for each board varient.
> 
> How about setting up some common defaults for your arch using Kconfig,
> so that the board defconfigs are much smaller?
> 
> In general, boards in U-Boot have far too many individual settings.
> Most of them should use a sensible default.
> 
> Going in the direction you have here just continues that tradition,
> inventing what I feel is an unnecessary solution.

Challenge here is SRAM. When we enable OSPI for example or USB DFU for a
group of our devices -> they follow a specific pattern of CONFIG
options, which over and over again, we mess up by having individual
config options being updated. This is similar in nature to the kernel
config fragment motivation as well - in fact just worse with SRAM
limitations with which SPL or early stages of bootloaders need to
function with.

Look at today's list:
am65x_evm_a53_defconfig
am65x_evm_r5_defconfig
am65x_evm_r5_usbdfu_defconfig
am65x_evm_r5_usbmsc_defconfig
am65x_hs_evm_a53_defconfig
am65x_hs_evm_r5_defconfig

The usbdfu or msc stuff just replicates it self over and over as people
enable that for next TI SoC and so and so forth.

Other patterns are stuff like Android configurations or distro boot
configurations - or uefi - instead of each vendor re-discovering the
right options, the opens up the possibility of standardized fragments
that any platform that chooses can pick.

I am with you that there are too many individual settings at times, and
there is a need to keep the defconfigs small as well. One thing we have
to fight against constantly is boot time memory availability and speed
of boot requirements. but those are details of the exact Kconfig options
enabled etc.. for us at least, config fragments opens up a sustainable
and low-fail option of consistently enabling features across SoCs and
platforms. I think many folks who struggle with the same will concur
as well. We are definitely open to following a structured set of rules
when and how it should be used.. but hopefully, this helps explains?
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [RFC PATCH 0/3] Minimal platform configuration

[Simon Glass]

Hi Nishanth,

On Thu, 13 Jul 2023 at 16:34, Nishanth Menon <nm@ti.com> wrote:
>
> On 08:00-20230712, Simon Glass wrote:
> > Hi Jason,
> >
> > On Tue, 11 Jul 2023 at 16:28, Jason Kacines <j-kacines@ti.com> wrote:
> > >
> > > When someone attempts to bring up a custom board using TI SoCs (am62x in
> > > this case), it often takes several days for someone to reduce the
> > > current configuration from the TI EVM/SK boards to a configuration that
> > > works for their board.
> > >
> > > The goal of these changes is to allow for a minimal boot configuration
> > > to exist within UBoot that someone can access directly in order to
> > > test their boards for a sign of life before beginning development. This
> > > is all done with the hope to increase ease of use and reduce the
> > > upbringing process from several days to a few hours.
> > >
> > > With the use of fragments, the base defconfigs reside in configs/ and
> > > the config fragments reside in board/../
> > >
> > > There is still quite a lot of board specific code inside board_init_f()
> > > that will need attention later, however this series begins the process
> > > of splitting the am62x's configs into a separate generic defconfig
> > > everyone can use for new board wakeups with individual board/ti/*.config
> > > fragments for each board varient.
> >
> > How about setting up some common defaults for your arch using Kconfig,
> > so that the board defconfigs are much smaller?
> >
> > In general, boards in U-Boot have far too many individual settings.
> > Most of them should use a sensible default.
> >
> > Going in the direction you have here just continues that tradition,
> > inventing what I feel is an unnecessary solution.
>
> Challenge here is SRAM. When we enable OSPI for example or USB DFU for a
> group of our devices -> they follow a specific pattern of CONFIG
> options, which over and over again, we mess up by having individual
> config options being updated. This is similar in nature to the kernel
> config fragment motivation as well - in fact just worse with SRAM
> limitations with which SPL or early stages of bootloaders need to
> function with.
>
> Look at today's list:
> am65x_evm_a53_defconfig
> am65x_evm_r5_defconfig
> am65x_evm_r5_usbdfu_defconfig
> am65x_evm_r5_usbmsc_defconfig
> am65x_hs_evm_a53_defconfig
> am65x_hs_evm_r5_defconfig
>
> The usbdfu or msc stuff just replicates it self over and over as people
> enable that for next TI SoC and so and so forth.
>
> Other patterns are stuff like Android configurations or distro boot
> configurations - or uefi - instead of each vendor re-discovering the
> right options, the opens up the possibility of standardized fragments
> that any platform that chooses can pick.
>
> I am with you that there are too many individual settings at times, and
> there is a need to keep the defconfigs small as well. One thing we have
> to fight against constantly is boot time memory availability and speed
> of boot requirements. but those are details of the exact Kconfig options
> enabled etc.. for us at least, config fragments opens up a sustainable
> and low-fail option of consistently enabling features across SoCs and
> platforms. I think many folks who struggle with the same will concur
> as well. We are definitely open to following a structured set of rules
> when and how it should be used.. but hopefully, this helps explains?

Yes, thank you.

Regards,
Simon