Re: [PATCH] arm: riscv: Remove additional ifdef from code guarded by CONFIG_IS_ENABLED

[Rick Chen]

> From: Michal Simek 
> Sent: Thursday, July 07, 2022 4:47 PM
> To: Simon Glass ; u-boot@lists.denx.de; g...@xilinx.com
> Cc: Alexandru Gagniuc ; Jan Kiszka 
> ; Leo Yu-Chi Liang(梁育齊) ; 
> Marek Vasut ; Peter Hoyes ; Rick Jian-Zhi 
> Chen(陳建志) ; Tom Rini 
> Subject: [PATCH] arm: riscv: Remove additional ifdef from code guarded by 
> CONFIG_IS_ENABLED
>
> CONFIG_OF_LIBFDT is used twice for guarding the same code. It is enough to do 
> it once that's why remove additional ifdefs from arm and risc-v code.
>
> Fixes: 0c303f9a6628 ("image: Drop IMAGE_ENABLE_OF_LIBFDT")
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/lib/bootm.c   | 2 --
>  arch/riscv/lib/bootm.c | 2 --
>  2 files changed, 4 deletions(-)

Reviewed-by: Rick Chen 

Re: [PATCH 1/2] designprinciples.rst: Perform minor cleanups

[Claudius Heine]

On 2022-07-08 20:38, Tom Rini wrote:

- Remove some missed wiki markup, and escape a "\n" correctly.
- Use gender-neutral language to refer to the user, consistently.

Cc: Claudius Heine 
Signed-off-by: Tom Rini 
---
  doc/develop/designprinciples.rst | 28 ++--
  1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
index 79694db77604..b6ceff1aa02b 100644
--- a/doc/develop/designprinciples.rst
+++ b/doc/develop/designprinciples.rst
@@ -18,8 +18,8 @@ relatively small NOR flash memory, which is expensive
  compared to the much larger NAND devices often used to store the
  operating system and the application.
  
-At the moment, U-Boot supports boards with just 128 !KiB ROM or with

-256 !KiB NOR flash. We should not easily ignore such configurations -
+At the moment, U-Boot supports boards with just 128 KiB ROM or with
+256 KiB NOR flash. We should not easily ignore such configurations -
  they may be the exception in among all the other supported boards,
  but if a design uses such a resource-constrained hardware setup it is
  usually because costs are critical, i. e. because the number of
@@ -28,15 +28,15 @@ millions...
  
  A usable and useful configuration of U-Boot, including a basic

  interactive command interpreter, support for download over Ethernet
-and the capability to program the flash shall fit in no more than 128 !KiB.
+and the capability to program the flash shall fit in no more than 128 KiB.
  
  Keep it Fast

  
  
  The end user is not interested in running U-Boot. In most embedded

-systems he is not even aware that U-Boot exists. The user wants to
+systems they are not even aware that U-Boot exists. The user wants to
  run some application code, and that as soon as possible after switching
-on his device.
+on their device.
  
  It is therefore essential that U-Boot is as fast as possible,

  especially that it loads and boots the operating system as fast as possible.
@@ -62,7 +62,7 @@ Keep it Simple
  ^^
  
  U-Boot is a boot loader, but it is also a tool used for board

-bring-up, for production testing, and for other activities
+bring-up, for production testing, and for other activities.
  
  Keep it Portable

  
@@ -95,13 +95,13 @@ Keep it Configurable
  Section "Keep it Small" already explains about the size restrictions
  for U-Boot on one side. On the other side, U-Boot is a powerful tool
  with many, many extremely useful features. The maintainer or user of
-each board will have to decide which features are important to him and
-what shall be included with his specific board configuration to meet
-his current requirements and restrictions.
+each board will have to decide which features are important to them and
+what shall be included with their specific board configuration to meet
+their current requirements and restrictions.
  
  Please make sure that it is easy to add or remove features from a

  board configuration, so everybody can make the best use of U-Boot on
-his system.
+their system.
  
  If a feature is not included, it should not have any residual code

  bloating the build.
@@ -124,7 +124,7 @@ debug is all the more important to many of us.
  * All initialization steps shall print some "begin doing this" message before
they actually start, and some "done" message when they complete. For 
example,
RAM initialization and size detection may print a "RAM: " before they start,
-  and "256 MB\n" when done.  The purpose of this is that you can always see
+  and "256 MB\\n" when done.  The purpose of this is that you can always see
which initialization step was running if there should be any problem.  This
is important not only during software development, but also for the service
people dealing with broken hardware in the field.
@@ -140,8 +140,8 @@ Please always keep in mind that there are at least three 
different
  groups of users for U-Boot, with completely different expectations
  and requirements:
  
-* The end user of an embedded device just wants to run some application; he

-  does not even want to know that U-Boot exists and only rarely interacts with
+* The end user of an embedded device just wants to run some application; they
+  do not even want to know that U-Boot exists and only rarely interacts with
it (for example to perform a reset to factory default settings etc.)
  * System designers and engineers working on the development of the application
and/or the operating system want a powerful tool that can boot from any boot
@@ -151,7 +151,7 @@ and requirements:
U-Boot to be as simple as possible so porting it to and maintaining it on
their hardware is easy for them.
  * Make it easy to test. Add debug code (but don't re-invent the wheel - use
-  existing macros like debug() or debugX()).
+  existing macros like debug()).
  
  Please always keep in mind that U-Boot tries to meet all thes

Re: [PATCH 2/2] process.rst: Perform minor cleanups

[Claudius Heine]

Hi Tom,

On 2022-07-08 20:38, Tom Rini wrote:

- Use gender-neutral language to refer to the user, consistently.
- Reword a few places so that they read more naturally.
- Make the long standing practice around "Twilight Time" more clear,
   hopefully.
- Replace a reference to MAKEALL with a reference to CI testing as
   that's the current requirement.

Cc: Claudius Heine 
Cc: Martin Bonner 
Signed-off-by: Tom Rini 
---
  doc/develop/process.rst | 31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index dd279fb9eff1..8f471fd161b2 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -42,21 +42,22 @@ Twilight Time
  -
  
  Usually patches do not get accepted as they are - the peer review that takes

-place will usually require changes and resubmits of the patches before they
+place will usually require changes and resubmissions of the patches before they
  are considered to be ripe for inclusion into mainline.
  
  Also, the review often happens not immediately after a patch was submitted,

  but only when somebody (usually the responsible custodian) finds time to do
  this.
  
-In the result, the final version of such patches gets submitted after the

+The result is that the final version of such patches gets submitted after the
  merge window has been closed.
  
  It is current practice in U-Boot that such patches are eligible to go into the

  upcoming release.
  
-In the result, the release of the ``"-rc1"`` version does not immediately follow

-the closing of the Merge Window.
+The result is that the release of the ``"-rc1"`` version and formal closing of
+the Merge Window does not preclude patches that were already posted from being
+merged for the upcoming release.
  
  Stabilization Period

  
@@ -71,13 +72,13 @@ Sometimes it is not clear if a patch contains a bug fix or 
not.
  For example, changes that remove dead code, unused macros etc. or
  that contain Coding Style fixes are not strict bug fixes.
  
-In such situations it is up to the responsible custodian to decide if he

-applies such patches even when the Merge Window is closed.
+In such situations it is up to the responsible custodian to decide if they
+apply such patches even when the Merge Window is closed.
  
  Exception: at the end of the Stabilization Period only strict bug

  fixes my be applied.
  
-Sometimes patches miss the the Merge Window slightly - say by few

+Sometimes patches miss the Merge Window slightly - say by few
  hours or even a day. Patch acceptance is not as critical as a
  financial transaction, or such. So if there is such a slight delay,
  the custodian is free to turn a blind eye and accept it anyway. The
@@ -105,7 +106,7 @@ Custodians
  --
  
  The Custodians take responsibility for some area of the U-Boot code.  The

-in-tree ``MAINTAINERS`` files list who is reponsible for which areas.
+in-tree ``MAINTAINERS`` files list who is responsible for which areas.
  
  It is their responsibility to pick up patches from the mailing list

  that fall into their responsibility, and to process these.
@@ -144,7 +145,7 @@ like this:
  
 #. U-Boot Philosophy

 #. Applies cleanly to the source tree
-   #. passes a ``MAKEALL`` compile test without creating new warnings
+   #. Passes :doc:`ci_testing` as this checks for new warnings and other 
issues.
  
  #. Notes:
  
@@ -153,7 +154,7 @@ like this:

   patch should send a short ACK to the mailing list.
#. We should create some tool to automatically do this.
#. This is well documented in :doc:`designprinciples`.
-  #. The custodian decides himself how recent the code must be.  It is
+  #. The custodian decides themselves how recent the code must be.  It is
   acceptable to request patches against the last officially released
   version of U-Boot or newer.  Of course a custodian can also accept
   patches against older code.
@@ -161,22 +162,22 @@ like this:
sign off/ack lines.
  
  5. The custodian decides to accept or to reject the patch.

-#. If accepted, the custodian adds the patch to his public git repository and
+#. If accepted, the custodian adds the patch to their public git repository and
 notifies the mailing list. This note should include:
  
 * a short description of the changes

 * the list of the affected boards / architectures etc.
 * suggested tests
  
-   Although the custodian is supposed to perform his own tests

-   it is a well-known and accepted fact that he needs help from
+   Although the custodian is supposed to perform their own tests
+   it is a well-known and accepted fact that they needs help from
 other developers who - for example - have access to the required
 hardware or tool chains.
 The custodian request help for tests and feedback from
 specific maintainers and U-Boot users.
  #. Once tests are passed, some agreed tim

Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

[Stefan Herbrechtsmeier]

Hi Marek,

Am 14.06.2022 um 09:38 schrieb Marek Vasut:

On 6/14/22 09:08, Stefan Herbrechtsmeier wrote:

Am 13.06.2022 um 22:26 schrieb Marek Vasut:

On 6/13/22 19:23, Stefan Herbrechtsmeier wrote:


[snip]


+    if (dev_read_u32(dev, "vendor-id", &hub->vendor_id))
+    hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+
+    if (dev_read_u32(dev, "product-id", &hub->product_id))
+    hub->product_id = data->product_id;
+
+    if (dev_read_u32(dev, "device-id", &hub->device_id))
+    hub->device_id = USB251XB_DEF_DEVICE_ID;
+


[snip]


+    if (dev_read_u32(dev, "language-id", &hub->lang_id))
+    hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+


This doesn't work because the ids are 16 bit [1,2] and the 
dev_read_u32 function checks the size.



+    if (!dev_read_u32(dev, "boost-up", &hub->boost_up))
+    hub->boost_up = USB251XB_DEF_BOOST_UP;


This looks like a 8 bit value [1].


The dev_read_u32() is also capable of reading 0x 16bit value 
from DT.


What kind of problem are you running into exactly ?


Have you test the values from device tree binding documentation:

vendor-id = /bits/ 16 <0x>;
product-id = /bits/ 16 <0x>;

I get an EOVERFLOW error.


No, I only tested foo = <0x>; .

Can you send a fix ?


Should I add a function to the driver or a dev_read_u8/16, 
ofnode_read_u8/16 and friends function?


It seems more like you would have to add the _u8 and _u16 variants into 
common code, alongside the _u32 variant (should be easy) and then use 
them in this driver (should also be easy), so two patches.


https://lists.denx.de/pipermail/u-boot/2022-June/486423.html
https://lists.denx.de/pipermail/u-boot/2022-June/486424.html

Do you have any comments?

Regards
  Stefan

Re: [PATCH] spl: mmc: Use correct MMC device when loading image

[Quentin Schulz]

Hi Harald,

On 7/6/22 12:58, Harald Seiler wrote:

When attempting to load images from multiple MMC devices in sequence,
spl_mmc_load() chooses the wrong device from the second attempt onwards.

The reason is that MMC initialization is only done on its first call and
spl_mmc_load() will then continue using this same device for all future
calls.

Fix this by checking the devnum of the "cached" device struct against
the one which is requested.  If they match, use the cached one but if
they do not match, initialize the new device.

This fixes specifying multiple MMC devices in the SPL's boot order to
fall back when U-Boot Proper is corrupted or missing on the first
attempted MMC device.

Fixes: e1eb6ada4e38 ("spl: Make image loader infrastructure more universal")
Signed-off-by: Harald Seiler 
---
  common/spl/spl_mmc.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e1a7d25bd0..22c8a8097c 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -371,9 +371,11 @@ int spl_mmc_load(struct spl_image_info *spl_image,
u32 boot_mode;
int err = 0;
__maybe_unused int part = 0;
+   int mmc_dev;
  
-	/* Perform peripheral init only once */

-   if (!mmc) {
+   /* Perform peripheral init only once for an mmc device */
+   mmc_dev = spl_mmc_get_device_index(bootdev->boot_device);
+   if (!mmc || mmc->block_dev.devnum != mmc_dev) {


block_dev field only exists when CONFIG_BLK is not defined, c.f. 
https://elixir.bootlin.com/u-boot/latest/source/include/mmc.h#L705


Considering the commit introducing this, c.f. 
https://source.denx.de/u-boot/u-boot/-/commit/33fb211dd2706e666db4008801dc0d5903fd82f6, 
I can suggest the following diff (which makes it compile with 
rk3399-puma_defconfig):


diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e0e1a80536..c40b436a11 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -409,10 +409,17 @@ int spl_mmc_load(struct spl_image_info *spl_image,
int err = 0;
__maybe_unused int part = 0;
int mmc_dev;
+   struct blk_desc *block_dev;

/* Perform peripheral init only once for an mmc device */
mmc_dev = spl_mmc_get_device_index(bootdev->boot_device);
-   if (!mmc || mmc->block_dev.devnum != mmc_dev) {
+#if !CONFIG_IS_ENABLED(BLK)
+   block_dev = &mmc->block_dev;
+#else
+   block_dev = dev_get_uclass_plat(mmc->dev);
+#endif
+
+   if (!mmc || block_dev->devnum != mmc_dev) {
err = spl_mmc_find_device(&mmc, bootdev->boot_device);
if (err)
return err;

Note: Only build tested.

Cheers,
Quentin

Re: [PATCH 1/2] dm: core: Add functions to read 8/16-bit integers

[Marek Vasut]

On 6/14/22 15:21, Stefan Herbrechtsmeier wrote:

From: Stefan Herbrechtsmeier 

Add functions to read 8/16-bit integers like the existing functions for
32/64-bit to simplify read of 8/16-bit integers from device tree
properties.

Signed-off-by: Stefan Herbrechtsmeier 


Reviewed-by: Marek Vasut 

Re: [PATCH 2/2] misc: usb251xb: Support 8/16 bit device tree values

[Marek Vasut]

On 6/14/22 15:21, Stefan Herbrechtsmeier wrote:

From: Stefan Herbrechtsmeier 

The device tree binding [1] specify the vendor-id, product-id, device-id
and language-id as 16 bit values and the linux driver reads the boost-up
value as 8 bit value.

[1] 
https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb251xb.txt

Signed-off-by: Stefan Herbrechtsmeier 


Reviewed-by: Marek Vasut 

Re: [PATCH v8 1/9] efi_loader: expose END device path node

[Ilias Apalodimas]

On Sun, 10 Jul 2022 at 12:10, Heinrich Schuchardt  wrote:
>
> On 6/19/22 06:55, Masahisa Kojima wrote:
> > This commit exposes the END device path node.
> >
> > Signed-off-by: Masahisa Kojima 
>
> Reviewed-by: Heinrich Schuchardt 
>
> > ---
> > No change in v8
> >
> > Newly created in v7
> >
> >   include/efi_loader.h | 3 +++
> >   lib/efi_loader/efi_device_path.c | 2 +-
> >   2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index f6651e2c60..c6df29993c 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -798,6 +798,9 @@ ssize_t efi_dp_check_length(const struct 
> > efi_device_path *dp,
> >   (((_dp)->type == DEVICE_PATH_TYPE_##_type) && \
> >((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype))
> >
> > +/* template END node: */
> > +extern const struct efi_device_path END;
> > +
> >   /* Indicate supported runtime services */
> >   efi_status_t efi_init_runtime_supported(void);
> >
> > diff --git a/lib/efi_loader/efi_device_path.c 
> > b/lib/efi_loader/efi_device_path.c
> > index 50a988c561..4798cec622 100644
> > --- a/lib/efi_loader/efi_device_path.c
> > +++ b/lib/efi_loader/efi_device_path.c
> > @@ -30,7 +30,7 @@ const efi_guid_t efi_guid_virtio_dev = 
> > U_BOOT_VIRTIO_DEV_GUID;
> >   #endif
> >
> >   /* template END node: */
> > -static const struct efi_device_path END = {
> > +const struct efi_device_path END = {
> >   .type = DEVICE_PATH_TYPE_END,
> >   .sub_type = DEVICE_PATH_SUB_TYPE_END,
> >   .length   = sizeof(END),
>

Reviewed-by: Ilias Apalodimas 

Re: [PATCH v1] arm: relocate: Replace ADR instruction with non-pseudo-instruction

[Tom Rini]

On Sun, Jul 10, 2022 at 03:09:53AM -0400, Jesse Taube wrote:

> In Binutils 2.37 the ADR instruction has changed
> use alternate instructions.
> 
> The change causes armv7-m to not boot.
> 
> Signed-off-by: Jesse Taube 
> ---
>  arch/arm/lib/relocate.S | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> index 14b7f61c1a..22c419534f 100644
> --- a/arch/arm/lib/relocate.S
> +++ b/arch/arm/lib/relocate.S
> @@ -78,7 +78,13 @@ ENDPROC(relocate_vectors)
>   */
>  
>  ENTRY(relocate_code)
> - adr r3, relocate_code
> +/*
> + * Binutils doesn't comply with the arm docs for adr in thumb2
> + * from commit d3e52e120b68bf19552743fbc078e0a759f48cb7 onward
> + * to remove ambiguity explicitly define the pseudo-instruction
> + */
> + mov r3, pc
> + subs r3, #4
>   ldr r1, _image_copy_start_ofs
>   add r1, r3  /* r1 <- Run &__image_copy_start */
>   subsr4, r0, r1  /* r4 <- Run to copy offset  */

Thanks for posting this.  I'm hoping that perhaps one of our Arm folks
can review this.  Aside from whitespace (which can be fixed up easily),
this looks good and it's good to have a comment explaining why.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] process.rst: Perform minor cleanups

[Tom Rini]

On Mon, Jul 11, 2022 at 10:04:13AM +0200, Claudius Heine wrote:
> Hi Tom,
> 
> On 2022-07-08 20:38, Tom Rini wrote:
[snip]
> >   #. Once tests are passed, some agreed time limit expires, the custodian
> > -   requests that the changes in his public git repository be merged into 
> > the
> > -   main tree. If necessary, the custodian may have to adapt his changes to
> > +   requests that the changes in their public git repository be merged into 
> > the
> > +   main tree. If necessary, the custodian may have to adapt their changes 
> > to
> >  allow for a clean merge.
> >  Todo: define a reasonable time limit. 3 weeks?
> 
> Is this still a todo?

Per Heinrich's request, I'm going to reword this section in a follow-up.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] spl: mmc: Use correct MMC device when loading image

[Harald Seiler]

Hi,

On Mon, 2022-07-11 at 12:18 +0200, Quentin Schulz wrote:
> Hi Harald,
> 
> On 7/6/22 12:58, Harald Seiler wrote:
> > When attempting to load images from multiple MMC devices in sequence,
> > spl_mmc_load() chooses the wrong device from the second attempt onwards.
> > 
> > The reason is that MMC initialization is only done on its first call and
> > spl_mmc_load() will then continue using this same device for all future
> > calls.
> > 
> > Fix this by checking the devnum of the "cached" device struct against
> > the one which is requested.  If they match, use the cached one but if
> > they do not match, initialize the new device.
> > 
> > This fixes specifying multiple MMC devices in the SPL's boot order to
> > fall back when U-Boot Proper is corrupted or missing on the first
> > attempted MMC device.
> > 
> > Fixes: e1eb6ada4e38 ("spl: Make image loader infrastructure more universal")
> > Signed-off-by: Harald Seiler 
> > ---
> >   common/spl/spl_mmc.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > index e1a7d25bd0..22c8a8097c 100644
> > --- a/common/spl/spl_mmc.c
> > +++ b/common/spl/spl_mmc.c
> > @@ -371,9 +371,11 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> > u32 boot_mode;
> > int err = 0;
> > __maybe_unused int part = 0;
> > +   int mmc_dev;
> >   
> > -   /* Perform peripheral init only once */
> > -   if (!mmc) {
> > +   /* Perform peripheral init only once for an mmc device */
> > +   mmc_dev = spl_mmc_get_device_index(bootdev->boot_device);
> > +   if (!mmc || mmc->block_dev.devnum != mmc_dev) {
> 
> block_dev field only exists when CONFIG_BLK is not defined, c.f. 
> https://elixir.bootlin.com/u-boot/latest/source/include/mmc.h#L705
> 
> Considering the commit introducing this, c.f. 
> https://source.denx.de/u-boot/u-boot/-/commit/33fb211dd2706e666db4008801dc0d5903fd82f6,
>  
> I can suggest the following diff (which makes it compile with 
> rk3399-puma_defconfig):
> 
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index e0e1a80536..c40b436a11 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -409,10 +409,17 @@ int spl_mmc_load(struct spl_image_info *spl_image,
>  int err = 0;
>  __maybe_unused int part = 0;
>  int mmc_dev;
> +   struct blk_desc *block_dev;
> 
>  /* Perform peripheral init only once for an mmc device */
>  mmc_dev = spl_mmc_get_device_index(bootdev->boot_device);
> -   if (!mmc || mmc->block_dev.devnum != mmc_dev) {
> +#if !CONFIG_IS_ENABLED(BLK)
> +   block_dev = &mmc->block_dev;
> +#else
> +   block_dev = dev_get_uclass_plat(mmc->dev);
> +#endif
> +
> +   if (!mmc || block_dev->devnum != mmc_dev) {
>  err = spl_mmc_find_device(&mmc, bootdev->boot_device);
>  if (err)
>  return err;
> 
> Note: Only build tested.

Thanks for reporting.  It's not quite that simple because `mmc` is NULL
on first call to spl_mmc_load().  I'll send a v2 to fix this.

-- 
Harald

[PATCH v2] spl: mmc: Use correct MMC device when loading image

[Harald Seiler]

When attempting to load images from multiple MMC devices in sequence,
spl_mmc_load() chooses the wrong device from the second attempt onwards.

The reason is that MMC initialization is only done on its first call and
spl_mmc_load() will then continue using this same device for all future
calls.

Fix this by checking the devnum of the "cached" device struct against
the one which is requested.  If they match, use the cached one but if
they do not match, initialize the new device.

This fixes specifying multiple MMC devices in the SPL's boot order to
fall back when U-Boot Proper is corrupted or missing on the first
attempted MMC device.

Fixes: e1eb6ada4e38 ("spl: Make image loader infrastructure more universal")
Signed-off-by: Harald Seiler 
---

Notes:
Changes in v2:
  - Make it work with CONFIG_SPL_BLK as well

 common/spl/spl_mmc.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e1a7d25bd0..1c12f69d96 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -361,6 +361,17 @@ int __weak spl_mmc_emmc_boot_partition(struct mmc *mmc)
return default_spl_mmc_emmc_boot_partition(mmc);
 }
 
+static int spl_mmc_get_mmc_devnum(struct mmc *mmc)
+{
+   struct blk_desc *block_dev;
+#if !CONFIG_IS_ENABLED(BLK)
+   block_dev = &mmc->block_dev;
+#else
+   block_dev = dev_get_uclass_plat(mmc->dev);
+#endif
+   return block_dev->devnum;
+}
+
 int spl_mmc_load(struct spl_image_info *spl_image,
 struct spl_boot_device *bootdev,
 const char *filename,
@@ -371,9 +382,11 @@ int spl_mmc_load(struct spl_image_info *spl_image,
u32 boot_mode;
int err = 0;
__maybe_unused int part = 0;
+   int mmc_dev;
 
-   /* Perform peripheral init only once */
-   if (!mmc) {
+   /* Perform peripheral init only once for an mmc device */
+   mmc_dev = spl_mmc_get_device_index(bootdev->boot_device);
+   if (!mmc || spl_mmc_get_mmc_devnum(mmc) != mmc_dev) {
err = spl_mmc_find_device(&mmc, bootdev->boot_device);
if (err)
return err;
-- 
2.36.1

Re: [PATCH 3/3] doc: environment: Further expand on Image locations and provide example

[Tom Rini]

On Mon, Jul 11, 2022 at 08:42:08AM +0200, Heinrich Schuchardt wrote:
> On 7/10/22 18:17, Tom Rini wrote:
> > On Sun, Jul 10, 2022 at 02:26:04PM +0200, Heinrich Schuchardt wrote:
> > > On 6/30/22 12:06, Simon Glass wrote:
> > > > On Mon, 20 Jun 2022 at 08:32, Tom Rini  wrote:
> > > > > 
> > > > > Start by elaborating on what some of our constraints tend to be with
> > > > > image location values, and document where these external constraints
> > > > > come from.  Provide a new subsection, an example based on the TI ARMv7
> > > > > OMAP2PLUS families of chips, that gives sample values and explains why
> > > > > we use these particular values.  This is based on what is in
> > > > > include/configs/ti_armv7_common.h as of fb3ad9bd923d ("TI: Add, use a
> > > > > DEFAULT_LINUX_BOOT_ENV environment string") as this contains just the
> > > > > values referenced in this document now and not some of the further
> > > > > additions that are less generic.
> > > > > 
> > > > > Signed-off-by: Tom Rini 
> > > > > ---
> > > > >doc/usage/environment.rst | 39 
> > > > > +++
> > > > >1 file changed, 39 insertions(+)
> > > > 
> > > > Reviewed-by: Simon Glass 
> > > 
> > > Below you want a change?
> > 
> > Yes, often Simon does that (and it's fine) to both offer a tag but if
> > another iteration is needed to make a minor adjustment to some wording
> > or another, or to make when applying.  Which is fine with me.
> > 
> > > > > diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
> > > > > index a9a4702632d2..f70ccd6a58ee 100644
> > > > > --- a/doc/usage/environment.rst
> > > > > +++ b/doc/usage/environment.rst
> > > > > @@ -404,6 +404,42 @@ device tree blob  fdtfilefdt_addr_r  
> > > > >  fdt_addr
> > > > >ramdisk   ramdiskfileramdisk_addr_r   ramdisk_addr
> > > > >= ==  ==
> > > > > 
> > > > > +When setting the RAM addresses for `kernel_addr_r`, `fdt_addr_r` and
> > > > > +`ramdisk_addr_r` there are several constraints to keep in mind. When 
> > > > > booting
> > > > > +Linux, the `Booting ARM Linux`_ and `Booting AArch64 Linux`_ 
> > > > > documents lay out
> > > > > +the requirements for booting all ARM platforms, including both 
> > > > > alignment and
> > > > > +where within memory various things must be.  These guidelines tend 
> > > > > to also be
> > > > > +correct for other OSes and unless specifically contradicted by 
> > > > > documentation
> > > 
> > > What makes you think that BSD or Haiku have the same constraints as Linux?
> > 
> > Because of what I said, and experience?  Now, one may be a subset of
> > another, but that still means it will work for both.  This is intended
> > to be general best practices.  If you follow this then it's likely
> > anything else will work too.  The danger comes from trying to optimize
> > the sizes to be as small as possible, rather than as large/flexible as
> > will likely work anywhere.  I will try and expand on that idea in the
> > next iteration.
> > 
> > > > > +specific to another architecture, are good rules to follow for other
> > > > > +architectures as well.
> > > 
> > > No. RISC-V does not have the same requirements as ARM. E.g. the initrd
> > > can be located anywhere in memory.
> > 
> > Please point to documentation that confirms that, and some otherwise bad
> > examples that actually work.
> 
> [PATCH 1/1] RISC-V: load initrd wherever it fits into memory
> https://lore.kernel.org/all/20210629134018.62859-1-xypron.g...@gmx.de/

Looks like someone ran in to the first common case of "oops, overwrote
the ramdisk with the kernel bss" or something along those lines.

Which is why I'm asking for more architectures to add good examples of
where to load each payload in to memory, with explanations of why and
how big of a gap to have.  I _think_ in Linux RISC-V (and hopefully for
32bit and 64bit) used the arm64 Image format and so BSS size is
available in the header and so we can safely check for that overlap and
relocate rather than fail to boot.  Checking for, and avoiding to start
with, these types of problems is why I want to add the examples.

> Please, have a look at efi_get_max_initrd_addr() in these files:
> 
> arch/arm/include/asm/efi.h:73
> arch/arm64/include/asm/efi.h:77
> arch/loongarch/include/asm/efi.h:36
> arch/riscv/include/asm/efi.h:31
> 
> MAX_UNCOMP_KERNEL_SIZE = 32 MiB is only enforced in
> drivers/firmware/efi/libstub/arm32-stub.c.

This isn't an EFI thing however.  The max uncompressed Linux kernel
image for arm32 is something along the lines of 96MiB I recall rmk
telling me when I asked about it at the time.  The base+32MiB in the
example here is for optimal (but not REQUIRED) decompressor location.

> > > > > +Example Image locations
> > > > > +^^^
> > > 
> > > You seem not to refer to a file 'Image'.
> > > 
> > > %s/Image/image/
> > 
> > OK.
> > 
> > > > > +
> > > > > +If we take the Texas

Re: [PATCH v1] arm: relocate: Replace ADR instruction with non-pseudo-instruction

[Andre Przywara]

On Sun, 10 Jul 2022 03:09:53 -0400
Jesse Taube  wrote:

Hi Jesse,

> In Binutils 2.37 the ADR instruction has changed
> use alternate instructions.

Can you elaborate on this? What has changed exactly, and why? Looking at
the commit you mention below I don't see an immediate problem that would
require code changes? Also it speaks of forward references, but this one
is not one?
And I didn't spot any difference between 2.38 and 2.35, at least not in my
isolated test (but I didn't bother to compile a whole stage 1 GCC with
newer binutils yet).

> The change causes armv7-m to not boot.

What does "causes armv7-m to not boot" mean? It compiles fine, but hangs
or crashes?
Can you show the relevant disassembly from both binutils versions?

And from trying to reproduce this minimally, do we need a ".syntax unified"
in the .S file? 

> Signed-off-by: Jesse Taube 
> ---
>  arch/arm/lib/relocate.S | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> index 14b7f61c1a..22c419534f 100644
> --- a/arch/arm/lib/relocate.S
> +++ b/arch/arm/lib/relocate.S
> @@ -78,7 +78,13 @@ ENDPROC(relocate_vectors)
>   */
>  
>  ENTRY(relocate_code)
> - adr r3, relocate_code
> +/*
> + * Binutils doesn't comply with the arm docs for adr in thumb2
> + * from commit d3e52e120b68bf19552743fbc078e0a759f48cb7 onward
> + * to remove ambiguity explicitly define the pseudo-instruction
> + */
> + mov r3, pc
> + subs r3, #4

But this will break ARM, won't it? Because it would require to subtract #8?
I mean there is a reason for this adr instruction, because this offset
calculation is best left to the assembler. Not to speak of the fragility
of assuming that the relocate_code label is pointing to the very first
instruction. The ENTRY macro could also insert instructions.

Cheers,
Andre

>   ldr r1, _image_copy_start_ofs
>   add r1, r3  /* r1 <- Run &__image_copy_start */
>   subsr4, r0, r1  /* r4 <- Run to copy offset  */

Re: [PATCH 3/3] doc: environment: Further expand on Image locations and provide example

[Heinrich Schuchardt]

On 7/11/22 14:41, Tom Rini wrote:

On Mon, Jul 11, 2022 at 08:42:08AM +0200, Heinrich Schuchardt wrote:

On 7/10/22 18:17, Tom Rini wrote:

On Sun, Jul 10, 2022 at 02:26:04PM +0200, Heinrich Schuchardt wrote:

On 6/30/22 12:06, Simon Glass wrote:

On Mon, 20 Jun 2022 at 08:32, Tom Rini  wrote:


Start by elaborating on what some of our constraints tend to be with
image location values, and document where these external constraints
come from.  Provide a new subsection, an example based on the TI ARMv7
OMAP2PLUS families of chips, that gives sample values and explains why
we use these particular values.  This is based on what is in
include/configs/ti_armv7_common.h as of fb3ad9bd923d ("TI: Add, use a
DEFAULT_LINUX_BOOT_ENV environment string") as this contains just the
values referenced in this document now and not some of the further
additions that are less generic.

Signed-off-by: Tom Rini 
---
doc/usage/environment.rst | 39 +++
1 file changed, 39 insertions(+)


Reviewed-by: Simon Glass 


Below you want a change?


Yes, often Simon does that (and it's fine) to both offer a tag but if
another iteration is needed to make a minor adjustment to some wording
or another, or to make when applying.  Which is fine with me.


diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index a9a4702632d2..f70ccd6a58ee 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -404,6 +404,42 @@ device tree blob  fdtfilefdt_addr_r   fdt_addr
ramdisk   ramdiskfileramdisk_addr_r   ramdisk_addr
= ==  ==

+When setting the RAM addresses for `kernel_addr_r`, `fdt_addr_r` and
+`ramdisk_addr_r` there are several constraints to keep in mind. When booting
+Linux, the `Booting ARM Linux`_ and `Booting AArch64 Linux`_ documents lay out
+the requirements for booting all ARM platforms, including both alignment and
+where within memory various things must be.  These guidelines tend to also be
+correct for other OSes and unless specifically contradicted by documentation


What makes you think that BSD or Haiku have the same constraints as Linux?


Because of what I said, and experience?  Now, one may be a subset of
another, but that still means it will work for both.  This is intended
to be general best practices.  If you follow this then it's likely
anything else will work too.  The danger comes from trying to optimize
the sizes to be as small as possible, rather than as large/flexible as
will likely work anywhere.  I will try and expand on that idea in the
next iteration.


+specific to another architecture, are good rules to follow for other
+architectures as well.


No. RISC-V does not have the same requirements as ARM. E.g. the initrd
can be located anywhere in memory.


Please point to documentation that confirms that, and some otherwise bad
examples that actually work.


[PATCH 1/1] RISC-V: load initrd wherever it fits into memory
https://lore.kernel.org/all/20210629134018.62859-1-xypron.g...@gmx.de/


Looks like someone ran in to the first common case of "oops, overwrote
the ramdisk with the kernel bss" or something along those lines.


Not at all. The ramdisk was relocated by U-Boot unnecessarily to above
256 MiB after start of RAM and the EFI stub before the patch did not
accept this address for no reason.



Which is why I'm asking for more architectures to add good examples of
where to load each payload in to memory, with explanations of why and
how big of a gap to have.  I _think_ in Linux RISC-V (and hopefully for
32bit and 64bit) used the arm64 Image format and so BSS size is
available in the header and so we can safely check for that overlap and
relocate rather than fail to boot.  Checking for, and avoiding to start
with, these types of problems is why I want to add the examples.


I am not aware of any restrictions for the placement of kernel, initrd,
fdt for RISC-V. Therefore there is no need to relocate anything after
loading (without overlap).

The bootefi command will never relocate a kernel or an fdt on any
architecture. You just pass the original load addresses.




Please, have a look at efi_get_max_initrd_addr() in these files:

arch/arm/include/asm/efi.h:73
arch/arm64/include/asm/efi.h:77
arch/loongarch/include/asm/efi.h:36
arch/riscv/include/asm/efi.h:31

MAX_UNCOMP_KERNEL_SIZE = 32 MiB is only enforced in
drivers/firmware/efi/libstub/arm32-stub.c.


This isn't an EFI thing however.  The max uncompressed Linux kernel
image for arm32 is something along the lines of 96MiB I recall rmk
telling me when I asked about it at the time.  The base+32MiB in the
example here is for optimal (but not REQUIRED) decompressor location.


The decompressor is what follows the EFI stub in the image?




+Example Image locations
+^^^


You seem not to refer to a file 'Image'.

%s/Image/image/


OK.


+
+If we take the Texas Instruments OMAP2PLUS family o

Re: [RFC PATCH 1/2] efi_loader: Add SPI I/O protocol support

[Ilias Apalodimas]

Hi Paul

On Fri, 8 Jul 2022 at 12:46, Paul Barker  wrote:
>
> This addition allows UEFI applications running under u-boot to access
> peripherals on SPI busses. It is based on the UEFI Platform
> Initialization (PI) Specification, Version 1.7 Errata A (April 2020).
> Only the core functionality required to discover SPI peripherals and
> communicate with them is currently implemented. Other functionality such
> as the legacy SPI controller interface and the ability to update the SPI
> peripheral object associated with a particular SPI I/O protocol object
> is currently unimplemented.
>
> Since there are no open source implementations of this protocol to use
> as an example, educated guesses/hacks have been made in cases where the
> UEFI PI specification is unclear and these are documented in comments.
>
> This implementation has been tested on the SanCloud BBE Lite and allowed
> a UEFI test application to successfully communicate with a Micron
> Authenta flash device connected via the SPI bus.
>
> Signed-off-by: Paul Barker 
> ---
>  MAINTAINERS   |   6 +
>  include/efi_loader.h  |   4 +
>  include/efi_spi_protocol.h| 158 +
>  lib/efi_loader/Kconfig|   8 +
>  lib/efi_loader/Makefile   |   1 +
>  lib/efi_loader/efi_setup.c|   6 +
>  lib/efi_loader/efi_spi_protocol.c | 565 ++
>  7 files changed, 748 insertions(+)
>  create mode 100644 include/efi_spi_protocol.h
>  create mode 100644 lib/efi_loader/efi_spi_protocol.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f27ff4c20fc..4f5a735567a4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -831,6 +831,12 @@ F: tools/efivar.py
>  F: tools/file2include.c
>  F: tools/mkeficapsule.c
>
> +EFI SPI SUPPORT
> +M: Paul Barker 
> +S: Maintained
> +F: include/efi_spi_protocol.h
> +F: lib/efi_loader/efi_spi_protocol.c
> +
>  EFI VARIABLES VIA OP-TEE
>  M: Ilias Apalodimas 
>  S: Maintained
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index c1e00ebac398..8fd867a78db2 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -537,6 +537,10 @@ efi_status_t efi_rng_register(void);
>  efi_status_t efi_tcg2_register(void);
>  /* Called by efi_init_obj_list() to install RISCV_EFI_BOOT_PROTOCOL */
>  efi_status_t efi_riscv_register(void);
> +/* Called by efi_init_obj_list() to install EFI_SPI_CONFIGURATION_PROTOCOL &
> + * EFI_SPI_IO_PROTOCOL
> + */
> +efi_status_t efi_spi_protocol_register(void);
>  /* Called by efi_init_obj_list() to do initial measurement */
>  efi_status_t efi_tcg2_do_initial_measurement(void);
>  /* measure the pe-coff image, extend PCR and add Event Log */
> diff --git a/include/efi_spi_protocol.h b/include/efi_spi_protocol.h
> new file mode 100644
> index ..1a4456bd9349
> --- /dev/null
> +++ b/include/efi_spi_protocol.h
> @@ -0,0 +1,158 @@
> +/* SPDX-License-Identifier: BSD-2-Clause-Patent */
> +/*
> + * Copyright (c) 2017, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef _EFI_SPI_PROTOCOL_H
> +#define _EFI_SPI_PROTOCOL_H
> +
> +#include 
> +#include 
> +
> +#define EFI_SPI_CONFIGURATION_GUID  \
> +   EFI_GUID(0x85a6d3e6, 0xb65b, 0x4afc, \
> +0xb3, 0x8f, 0xc6, 0xd5, 0x4a, 0xf6, 0xdd, 0xc8)
> +
> +struct efi_spi_peripheral;
> +
> +struct efi_spi_part {
> +   efi_string_t vendor;
> +   efi_string_t part_number;
> +   u32 min_clock_hz;
> +   u32 max_clock_hz;
> +   bool chip_select_polarity;
> +};
> +
> +struct efi_spi_bus {
> +   efi_string_t friendly_name;
> +   struct efi_spi_peripheral *peripheral_list;
> +   struct efi_device_path *controller_path;
> +
> +   efi_status_t
> +   (EFIAPI * clock)(const struct efi_spi_peripheral *spi_peripheral,
> +   u32 *clock_hz);
> +
> +   void *clock_parameter;
> +};
> +
> +struct efi_spi_peripheral {
> +   struct efi_spi_peripheral *next_spi_peripheral;
> +   efi_string_t friendly_name;
> +   efi_guid_t *spi_peripheral_driver_guid;
> +   struct efi_spi_part *spi_part;
> +   u32 max_clock_hz;
> +   bool clock_polarity;
> +   bool clock_phase;
> +   u32 attributes;
> +   void *configuration_data;
> +   struct efi_spi_bus *spi_bus;
> +
> +   efi_status_t
> +   (EFIAPI * chip_select)(const struct efi_spi_peripheral 
> *spi_peripheral,
> +   bool pin_value);
> +
> +   void *chip_select_parameter;
> +};
> +
> +struct efi_spi_configuration_protocol {
> +   u32 bus_count;
> +   struct efi_spi_bus **bus_list;
> +};
> +
> +#define EFI_LEGACY_SPI_CONTROLLER_GUID  \
> +   EFI_GUID(0x39136fc7, 0x1a11, 0x49de, \
> +0xbf, 0x35, 0x0e, 0x78, 0xdd, 0xb5, 0x24, 0xfc)
> +
> +struct efi_legacy_spi_controller_protocol;
> +
> +struct efi_legacy_spi_controller_protocol {
> +   u32 maximum_offset;
> +   u32 maximum_range_bytes;
> +   u32 range_register_count;
> +
>

Re: [PATCH v1] arm: relocate: Replace ADR instruction with non-pseudo-instruction

[Tom Rini]

On Mon, Jul 11, 2022 at 01:57:40PM +0100, Andre Przywara wrote:
> On Sun, 10 Jul 2022 03:09:53 -0400
> Jesse Taube  wrote:
> 
> Hi Jesse,
> 
> > In Binutils 2.37 the ADR instruction has changed
> > use alternate instructions.
> 
> Can you elaborate on this? What has changed exactly, and why? Looking at
> the commit you mention below I don't see an immediate problem that would
> require code changes? Also it speaks of forward references, but this one
> is not one?
> And I didn't spot any difference between 2.38 and 2.35, at least not in my
> isolated test (but I didn't bother to compile a whole stage 1 GCC with
> newer binutils yet).

Some further references Jesse provided off-list:

https://stackoverflow.com/questions/59110205/why-do-forward-reference-adr-instructions-assemble-with-even-offsets-in-thumb-co

https://mail.gnu.org/archive/html/bug-binutils/2019-11/msg00187.html

https://sourceware.org/bugzilla/show_bug.cgi?id=25235

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/3] doc: environment: Further expand on Image locations and provide example

[Tom Rini]

On Mon, Jul 11, 2022 at 03:10:36PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 14:41, Tom Rini wrote:
> > On Mon, Jul 11, 2022 at 08:42:08AM +0200, Heinrich Schuchardt wrote:
> > > On 7/10/22 18:17, Tom Rini wrote:
> > > > On Sun, Jul 10, 2022 at 02:26:04PM +0200, Heinrich Schuchardt wrote:
> > > > > On 6/30/22 12:06, Simon Glass wrote:
> > > > > > On Mon, 20 Jun 2022 at 08:32, Tom Rini  wrote:
> > > > > > > 
> > > > > > > Start by elaborating on what some of our constraints tend to be 
> > > > > > > with
> > > > > > > image location values, and document where these external 
> > > > > > > constraints
> > > > > > > come from.  Provide a new subsection, an example based on the TI 
> > > > > > > ARMv7
> > > > > > > OMAP2PLUS families of chips, that gives sample values and 
> > > > > > > explains why
> > > > > > > we use these particular values.  This is based on what is in
> > > > > > > include/configs/ti_armv7_common.h as of fb3ad9bd923d ("TI: Add, 
> > > > > > > use a
> > > > > > > DEFAULT_LINUX_BOOT_ENV environment string") as this contains just 
> > > > > > > the
> > > > > > > values referenced in this document now and not some of the further
> > > > > > > additions that are less generic.
> > > > > > > 
> > > > > > > Signed-off-by: Tom Rini 
> > > > > > > ---
> > > > > > > doc/usage/environment.rst | 39 
> > > > > > > +++
> > > > > > > 1 file changed, 39 insertions(+)
> > > > > > 
> > > > > > Reviewed-by: Simon Glass 
> > > > > 
> > > > > Below you want a change?
> > > > 
> > > > Yes, often Simon does that (and it's fine) to both offer a tag but if
> > > > another iteration is needed to make a minor adjustment to some wording
> > > > or another, or to make when applying.  Which is fine with me.
> > > > 
> > > > > > > diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
> > > > > > > index a9a4702632d2..f70ccd6a58ee 100644
> > > > > > > --- a/doc/usage/environment.rst
> > > > > > > +++ b/doc/usage/environment.rst
> > > > > > > @@ -404,6 +404,42 @@ device tree blob  fdtfilefdt_addr_r  
> > > > > > >  fdt_addr
> > > > > > > ramdisk   ramdiskfileramdisk_addr_r   ramdisk_addr
> > > > > > > = ==  
> > > > > > > ==
> > > > > > > 
> > > > > > > +When setting the RAM addresses for `kernel_addr_r`, `fdt_addr_r` 
> > > > > > > and
> > > > > > > +`ramdisk_addr_r` there are several constraints to keep in mind. 
> > > > > > > When booting
> > > > > > > +Linux, the `Booting ARM Linux`_ and `Booting AArch64 Linux`_ 
> > > > > > > documents lay out
> > > > > > > +the requirements for booting all ARM platforms, including both 
> > > > > > > alignment and
> > > > > > > +where within memory various things must be.  These guidelines 
> > > > > > > tend to also be
> > > > > > > +correct for other OSes and unless specifically contradicted by 
> > > > > > > documentation
> > > > > 
> > > > > What makes you think that BSD or Haiku have the same constraints as 
> > > > > Linux?
> > > > 
> > > > Because of what I said, and experience?  Now, one may be a subset of
> > > > another, but that still means it will work for both.  This is intended
> > > > to be general best practices.  If you follow this then it's likely
> > > > anything else will work too.  The danger comes from trying to optimize
> > > > the sizes to be as small as possible, rather than as large/flexible as
> > > > will likely work anywhere.  I will try and expand on that idea in the
> > > > next iteration.
> > > > 
> > > > > > > +specific to another architecture, are good rules to follow for 
> > > > > > > other
> > > > > > > +architectures as well.
> > > > > 
> > > > > No. RISC-V does not have the same requirements as ARM. E.g. the initrd
> > > > > can be located anywhere in memory.
> > > > 
> > > > Please point to documentation that confirms that, and some otherwise bad
> > > > examples that actually work.
> > > 
> > > [PATCH 1/1] RISC-V: load initrd wherever it fits into memory
> > > https://lore.kernel.org/all/20210629134018.62859-1-xypron.g...@gmx.de/
> > 
> > Looks like someone ran in to the first common case of "oops, overwrote
> > the ramdisk with the kernel bss" or something along those lines.
> 
> Not at all. The ramdisk was relocated by U-Boot unnecessarily to above
> 256 MiB after start of RAM and the EFI stub before the patch did not
> accept this address for no reason.

Then bootm_size / bootm_low should have been set appropriately in
U-Boot.

> > Which is why I'm asking for more architectures to add good examples of
> > where to load each payload in to memory, with explanations of why and
> > how big of a gap to have.  I _think_ in Linux RISC-V (and hopefully for
> > 32bit and 64bit) used the arm64 Image format and so BSS size is
> > available in the header and so we can safely check for that overlap and
> > relocate rather than fail to boot.  Checking for, and avoiding to start
> > with, these types of pro

Re: [RFC PATCH 1/3] eficonfig: add UEFI Secure Boot Key enrollment interface

[Masahisa Kojima]

Hi Heinrich,

On Sun, 10 Jul 2022 at 18:37, Heinrich Schuchardt  wrote:
>
> On 7/8/22 11:14, Ilias Apalodimas wrote:
> > On Sun, Jun 19, 2022 at 02:20:20PM +0900, Masahisa Kojima wrote:
> >> This commit adds the menu-driven UEFI Secure Boot Key
> >> enrollment interface. User can enroll the PK, KEK, db
> >> and dbx by selecting EFI Signature Lists file.
> >> After the PK is enrolled, UEFI Secure Boot is enabled and
> >> EFI Signature Lists file must be signed by KEK or PK.
> >>
> >> Signed-off-by: Masahisa Kojima 
> >> ---
> >>   cmd/Makefile  |   3 +
> >>   cmd/eficonfig.c   |   3 +
> >>   cmd/eficonfig_sbkey.c | 202 ++
> >>   include/efi_config.h  |   3 +
> >>   4 files changed, 211 insertions(+)
> >>   create mode 100644 cmd/eficonfig_sbkey.c
> >>
> >> diff --git a/cmd/Makefile b/cmd/Makefile
> >> index 0afa687e94..9d87b639fc 100644
> >> --- a/cmd/Makefile
> >> +++ b/cmd/Makefile
> >> @@ -64,6 +64,9 @@ obj-$(CONFIG_CMD_EEPROM) += eeprom.o
> >>   obj-$(CONFIG_EFI) += efi.o
> >>   obj-$(CONFIG_CMD_EFIDEBUG) += efidebug.o
> >>   obj-$(CONFIG_CMD_EFICONFIG) += eficonfig.o
> >> +ifdef CONFIG_CMD_EFICONFIG
> >> +obj-$(CONFIG_EFI_SECURE_BOOT) += eficonfig_sbkey.o
> >> +endif
> >>   obj-$(CONFIG_CMD_ELF) += elf.o
> >>   obj-$(CONFIG_CMD_EROFS) += erofs.o
> >>   obj-$(CONFIG_HUSH_PARSER) += exit.o
> >> diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> >> index e62f5e41a4..e6d2cba9c5 100644
> >> --- a/cmd/eficonfig.c
> >> +++ b/cmd/eficonfig.c
> >> @@ -1832,6 +1832,9 @@ static const struct eficonfig_item 
> >> maintenance_menu_items[] = {
> >>  {"Edit Boot Option", eficonfig_process_edit_boot_option},
> >>  {"Change Boot Order", eficonfig_process_change_boot_order},
> >>  {"Delete Boot Option", eficonfig_process_delete_boot_option},
> >> +#if (CONFIG_IS_ENABLED(EFI_SECURE_BOOT))
> >> +{"Secure Boot Configuration", eficonfig_process_secure_boot_config},
> >> +#endif
> >>  {"Quit", eficonfig_process_quit},
> >>   };
> >>
> >> diff --git a/cmd/eficonfig_sbkey.c b/cmd/eficonfig_sbkey.c
> >> new file mode 100644
> >> index 00..a5c0dbe9b3
> >> --- /dev/null
> >> +++ b/cmd/eficonfig_sbkey.c
> >> @@ -0,0 +1,202 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +/*
> >> + *  Menu-driven UEFI Secure Boot key maintenance
> >> + *
> >> + *  Copyright (c) 2022 Masahisa Kojima, Linaro Limited
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
>
> Please, provide function descriptions.

OK.

>
> >> +static bool is_secureboot_enabled(void)
> >> +{
> >> +efi_status_t ret;
> >> +u8 secure_boot;
> >> +efi_uintn_t size;
> >> +
> >> +size = sizeof(secure_boot);
> >> +ret = efi_get_variable_int(u"SecureBoot", &efi_global_variable_guid,
> >> +   NULL, &size, &secure_boot, NULL);
> >> +
> >> +return secure_boot == 1;
> >> +}
> >> +
> >> +static efi_status_t eficonfig_process_enroll_key(void *data)
> >> +{
> >> +u32 attr;
> >> +char *buf = NULL;
> >> +efi_uintn_t size;
> >> +efi_status_t ret;
> >> +struct efi_file_handle *f;
> >> +struct efi_file_handle *root;
> >> +struct eficonfig_select_file_info file_info;
> >> +
> >> +file_info.current_path = calloc(1, EFICONFIG_FILE_PATH_BUF_SIZE);
> >> +if (!file_info.current_path)
> >> +goto out;
> >> +
> >> +ret = eficonfig_select_file_handler(&file_info);
> >> +if (ret != EFI_SUCCESS)
> >> +goto out;
> >> +
> >> +ret = efi_open_volume_int(file_info.current_volume, &root);
> >> +if (ret != EFI_SUCCESS)
> >> +goto out;
> >> +
> >> +ret = efi_file_open_int(root, &f, file_info.current_path, 
> >> EFI_FILE_MODE_READ, 0);
> >> +if (ret != EFI_SUCCESS)
> >> +goto out;
> >> +
> >> +size = 0;
> >> +ret = EFI_CALL(f->getinfo(f, &efi_file_info_guid, &size, NULL));
> >> +if (ret != EFI_BUFFER_TOO_SMALL)
> >> +goto out;
> >> +
> >> +buf = calloc(1, size);
> >> +if (!buf) {
> >> +ret = EFI_OUT_OF_RESOURCES;
> >> +goto out;
> >> +}
> >> +ret = EFI_CALL(f->getinfo(f, &efi_file_info_guid, &size, buf));
> >> +if (ret != EFI_SUCCESS)
> >> +goto out;
> >> +
> >> +size = ((struct efi_file_info *)buf)->file_size;
> >> +free(buf);
> >
> > You should set buf to NULL here.
>
> Assigning NULL would have no effect. The variable is reassigned in the
> next line.

OK.

>
> >
> >> +
> >> +buf = calloc(1, size);
> >> +if (!buf)
> >> +goto out;
> >> +
> >> +ret = efi_file_read_int(f, &size, buf);
> >> +if (ret != EFI_SUCCESS || size == 0)
> >> +goto out;
> >> +
> >> +attr = EFI_VARIABLE_NON_VOLATILE |
> >> +   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >> +   EFI_VARIABLE_RUNTIME_ACCESS |
> >> +   

Re: [RFC PATCH 1/2] efi_loader: Add SPI I/O protocol support

[Paul Barker]

On 11/07/2022 14:12, Ilias Apalodimas wrote:

Hi Paul


+static efi_status_t
+efi_spi_bus_clock(const struct efi_spi_peripheral *spi_peripheral,
+ u32 *clock_hz)
+{
+   EFI_ENTRY("%p, %p", spi_peripheral, clock_hz);
+   return EFI_EXIT(EFI_UNSUPPORTED);
+}
+


All the EFI_ENTRY/EXIT calls should be on functions marked as EFIAPI.
Most of the functions you use it on seem to be static function that
will never be called by an EFI application.


These functions are actually exported as part of EFI protocols and so 
can be called by an EFI application. So I should mark them as EFIAPI 
when I send v2 of this series.


Thanks,

--
Paul Barker
Principal Software Engineer
SanCloud Ltd

e: paul.bar...@sancloud.com
w: https://sancloud.com/


OpenPGP_0xA67255DFCCE62ECD.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[ANN] U-Boot v2022.07 released

[Tom Rini]

Hey all,

It's a week after the initially scheduled release day, but the last week
was as quiet as I expected, so now we're releasing v2022.07.  At this
point, the DM_ETH migration is 2 years past the deadline, and I have
sent some off-list reminders about migration earlier in the year.  One
of my early tasks for this next release is posting some driver removal
patches as a last call for migration.

Looking at the v2022.04 release email, I've made more progress on CONFIG
migrations and others have joined in (thanks!) but there's still much to
be done, and we still need some buildman work so that genboards.py can
be fully retired.

On a somewhat related note, my goal for the next release is to migrate
our wiki content (which people had noted went missing for a bit during
this cycle) to rST and our documentation site.

In terms of a changelog, 
git log --merges v2022.07-rc6..v2022.07
contains what I've pulled since the last RC or:
git log --merges v2022.04..v2022.07
for changes since the last full release.  As always, more details in
pull requests (or the tags referenced by them) will result in more
details here.

And now the merge window continues to be open and I'll merge next in to
master shortly.  v2022.10 is scheduled for release on Monday, October
3rd 2022 and the merge window closes on July 25th.  Thanks all!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/8] arm64: dts: sdm845: Remove redundant u-boot DT properties

[Ramon Fried]

On Tue, Jul 5, 2022 at 11:57 AM Daniel Thompson
 wrote:
>
> On Tue, Jul 05, 2022 at 11:05:04AM +0530, Sumit Garg wrote:
> > Hi Daniel,
> >
> > Thanks for your review.
> >
> > On Mon, 4 Jul 2022 at 21:28, Daniel Thompson  
> > wrote:
> > >
> > > On Mon, Jul 04, 2022 at 06:28:38PM +0530, Sumit Garg wrote:
> > > > U-boot specific DT properties belong to *-uboot.dtsi
> > >
> > > ... and are already included in starqltechn-uboot.dtsi (which is the
> > > only current consumer of sdm845.dtsi).
> > >
> > >
> > > Adding fuller comments, such as the above, makes things much easier to
> > > review: it makes clear why you consider the properties redundant rather
> > > then misfiled.
> > >
> >
> > I would rather say that this change is to follow the u-boot DT
> > recommendation [1]. I will update the commit message accordingly. BTW,
> > it looks like u-boot DT properties are incorrectly specified in
> > starqltechn-uboot.dtsi here [2] as there aren't any subnodes for the
> > "gcc" node. I will correct that too.
>
> That's fine. The wording was just an example and we written before I
> reviewed patch 4 and spotted the inconsistancies there.
>
>
> Daniel.
Reviewed-by: Ramon Fried 

Re: [PATCH v2 1/9] board: starqltechn: Align DT node overrides with sdm845.dtsi

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> Currently there is a mismatch among DT node overrides in starqltechn
> board DTS file and the actual DT nodes in the sdm845.dtsi. So fix that
> to align with DT nodes in sdm845.dtsi.
>
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/starqltechn-uboot.dtsi | 18 --
>  arch/arm/dts/starqltechn.dts|  2 +-
>  2 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/dts/starqltechn-uboot.dtsi 
> b/arch/arm/dts/starqltechn-uboot.dtsi
> index b55cccfe14..8d5d09c3a5 100644
> --- a/arch/arm/dts/starqltechn-uboot.dtsi
> +++ b/arch/arm/dts/starqltechn-uboot.dtsi
> @@ -16,16 +16,14 @@
> serial@a84000 {
> u-boot,dm-pre-reloc;
> };
> -   gcc {
> -   clock-controller@10 {
> -   u-boot,dm-pre-reloc;
> -   };
> -   gpio_north@390 {
> -   u-boot,dm-pre-reloc;
> -   };
> -   pinctrl@390 {
> -   u-boot,dm-pre-reloc;
> -   };
> +   clock-controller@10 {
> +   u-boot,dm-pre-reloc;
> +   };
> +   gpio_north@390 {
> +   u-boot,dm-pre-reloc;
> +   };
> +   pinctrl_north@390 {
> +   u-boot,dm-pre-reloc;
> };
> };
>  };
> diff --git a/arch/arm/dts/starqltechn.dts b/arch/arm/dts/starqltechn.dts
> index 0261388319..34a4f59cbd 100644
> --- a/arch/arm/dts/starqltechn.dts
> +++ b/arch/arm/dts/starqltechn.dts
> @@ -48,7 +48,7 @@
> status = "okay";
> };
>
> -   pinctrl@390 {
> +   pinctrl_north@390 {
> muic_i2c: muic_i2c {
> pins = "GPIO_33", "GPIO_34";
> drive-strength = <0x2>;
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH v2 2/9] arm64: dts: sdm845: Remove redundant u-boot DT properties

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> According to u-boot DT recomendation, u-boot specific DT properties belong
> to *-uboot.dtsi. Also for starqltechn board (which is the only current
> consumer of sdm845.dtsi), the properties are already included in
> starqltechn-uboot.dtsi, so remove corresponding redundant properties.
>
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/sdm845.dtsi | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
> index 6f2fb20d68..88030156d9 100644
> --- a/arch/arm/dts/sdm845.dtsi
> +++ b/arch/arm/dts/sdm845.dtsi
> @@ -18,7 +18,6 @@
> compatible = "simple-bus";
>
> gcc: clock-controller@10 {
> -   u-boot,dm-pre-reloc;
> compatible = "qcom,gcc-sdm845";
> reg = <0x10 0x1f>;
> #clock-cells = <1>;
> @@ -27,7 +26,6 @@
> };
>
> gpio_north: gpio_north@390 {
> -   u-boot,dm-pre-reloc;
> #gpio-cells = <2>;
> compatible = "qcom,sdm845-pinctrl";
> reg = <0x390 0x40>;
> @@ -38,7 +36,6 @@
> };
>
> tlmm_north: pinctrl_north@390 {
> -   u-boot,dm-pre-reloc;
> compatible = "qcom,tlmm-sdm845";
> reg = <0x390 0x40>;
> gpio-count = <150>;
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

[RESEND PATCH v3 0/1] Support SPL for i.MX7ULP

[Oleksandr Suvorov]

I've just realized this only patch was not applied among other
patches of the original patchset "Support SPL for i.MX7ULP".

Please apply this patch as now "include/configs/mx7ulp_com.h"
refers to non-existent "include/configs/imx7ulp_spl.h".

Changes in v3:
- rebase the patch to the current codebase

Ricardo Salveti (1):
  mx7ulp: add base SPL support for mx7ulp

 arch/arm/Makefile  |  2 +-
 arch/arm/mach-imx/Makefile |  2 +-
 arch/arm/mach-imx/mx7ulp/soc.c |  2 +-
 arch/arm/mach-imx/spl.c| 12 ---
 include/configs/imx7ulp_spl.h  | 39 ++
 5 files changed, 51 insertions(+), 6 deletions(-)
 create mode 100644 include/configs/imx7ulp_spl.h

-- 
2.36.1

[RESEND PATCH v3 1/1] mx7ulp: add base SPL support for mx7ulp

[Oleksandr Suvorov]

From: Ricardo Salveti 

Add a base implementation of mx7ulp SPL config header and soc,
and changes in makefiles in order to allow building SPL on mx7ulp
based devices.

Signed-off-by: Ricardo Salveti 
Co-developed-by: Oleksandr Suvorov 
Signed-off-by: Oleksandr Suvorov 
---

Changes in v3:
- rebase the patch to the current codebase

 arch/arm/Makefile  |  2 +-
 arch/arm/mach-imx/Makefile |  2 +-
 arch/arm/mach-imx/mx7ulp/soc.c |  2 +-
 arch/arm/mach-imx/spl.c| 12 ---
 include/configs/imx7ulp_spl.h  | 39 ++
 5 files changed, 51 insertions(+), 6 deletions(-)
 create mode 100644 include/configs/imx7ulp_spl.h

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index a37603035d8..7c7e88df61c 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -111,7 +111,7 @@ libs-y += arch/arm/cpu/
 libs-y += arch/arm/lib/
 
 ifeq ($(CONFIG_SPL_BUILD),y)
-ifneq (,$(CONFIG_MX23)$(CONFIG_MX28)$(filter $(SOC), mx25 mx5 mx6 mx7 mx35 
imx8m imx8 imx8ulp imxrt))
+ifneq (,$(CONFIG_MX23)$(CONFIG_MX28)$(filter $(SOC), mx25 mx5 mx6 mx7 mx7ulp 
mx35 imx8m imx8 imx8ulp imxrt))
 libs-y += arch/arm/mach-imx/
 endif
 else
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index aa0b6447f14..bbf812776bc 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -29,7 +29,7 @@ endif
 obj-$(CONFIG_GPT_TIMER) += timer.o
 obj-$(CONFIG_SYS_I2C_MXC) += i2c-mxv7.o
 endif
-ifeq ($(SOC),$(filter $(SOC),mx7 mx6 mxs imx8m imx8 imxrt))
+ifeq ($(SOC),$(filter $(SOC),mx7 mx7ulp mx6 mxs imx8m imx8 imxrt))
 obj-y  += misc.o
 obj-$(CONFIG_CMD_PRIBLOB) += priblob.o
 obj-$(CONFIG_SPL_BUILD)+= spl.o
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 217b7c45867..951b1888c58 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -234,7 +234,7 @@ void s_init(void)
 }
 #endif
 
-#ifndef CONFIG_ULP_WATCHDOG
+#if !CONFIG_IS_ENABLED(ULP_WATCHDOG) || CONFIG_IS_ENABLED(SPL_BUILD)
 void reset_cpu(void)
 {
setbits_le32(SIM0_RBASE, SIM_SOPT1_A7_SW_RESET);
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 64ca2967721..a033d4f6fa1 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -111,8 +111,12 @@ u32 spl_boot_device(void)
return BOOT_DEVICE_NONE;
 }
 
-#elif defined(CONFIG_MX7) || defined(CONFIG_IMX8M) || defined(CONFIG_IMX8)
-/* Translate iMX7/i.MX8M boot device to the SPL boot device enumeration */
+#elif defined(CONFIG_MX7) || defined(CONFIG_MX7ULP) || \
+   defined(CONFIG_IMX8M) || defined(CONFIG_IMX8)
+/*
+ * Translate iMX7/i.MX7ULP/i.MX8M/i.MX8 boot device to the SPL boot
+ * device enumeration
+ */
 u32 spl_boot_device(void)
 {
 #if defined(CONFIG_MX7)
@@ -124,7 +128,9 @@ u32 spl_boot_device(void)
 */
if (((bmode >> 24) & 0x03) == 0x01) /* Serial Downloader */
return BOOT_DEVICE_BOARD;
+#endif
 
+#if defined(CONFIG_MX7) || defined(CONFIG_MX7ULP)
/*
 * The above method does not detect that the boot ROM used
 * serial downloader in case the boot ROM decided to use the
@@ -182,7 +188,7 @@ u32 spl_boot_device(void)
return BOOT_DEVICE_NONE;
}
 }
-#endif /* CONFIG_MX7 || CONFIG_IMX8M || CONFIG_IMX8 */
+#endif /* CONFIG_MX7 || CONFIG_MX7ULP || CONFIG_IMX8M || CONFIG_IMX8 */
 
 #ifdef CONFIG_SPL_USB_GADGET
 int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
diff --git a/include/configs/imx7ulp_spl.h b/include/configs/imx7ulp_spl.h
new file mode 100644
index 000..33b034e
--- /dev/null
+++ b/include/configs/imx7ulp_spl.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * SPL definitions for the i.MX7ULP SPL
+ *
+ * (C) Copyright 2019 Foundries.io
+ */
+
+#ifndef __IMX7ULP_SPL_CONFIG_H
+#define __IMX7ULP_SPL_CONFIG_H
+
+#if CONFIG_IS_ENABLED(SPL)
+/*
+ * see figure 35-5 in i.MX 7ULP Reference manual:
+ *  - IMX7ULP A7 OCRAM free area RAM is from 0x2F01 to 0x2F03FF00.
+ *  - Set the stack at the end of the free area section, at 0x2003FEB8.
+ *  - The BOOT ROM loads what they consider the firmware image
+ *which consists of a 4K header in front of us that contains the IVT, DCD,
+ *and some padding thus 'our' max size is really 0x2F03FF00 - 0x2F011000.
+ *187KB is more than enough for the SPL.
+ */
+#define CONFIG_SPL_STACK   0x2F03FEB8
+
+/* MMC support */
+#if CONFIG_IS_ENABLED(SPL_MMC_SUPPORT)
+#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
+#define CONFIG_SYS_MONITOR_LEN 409600  /* 400 KB */
+#endif
+
+/* Define the payload for FAT/EXT support */
+#if CONFIG_IS_ENABLED(SPL_FS_FAT) || CONFIG_IS_ENABLED(SPL_FS_EXT4)
+#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img"
+#endif
+
+#define CONFIG_SYS_SPL_MALLOC_START0x6830
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */
+
+#endif /* CONFIG_SPL */
+
+#endif /* __IMX7ULP_SPL_CONFIG_H */

Re: [PATCH v1] arm: relocate: Replace ADR instruction with non-pseudo-instruction

[Andre Przywara]

On Mon, 11 Jul 2022 13:57:40 +0100
Andre Przywara  wrote:

Hi,

> On Sun, 10 Jul 2022 03:09:53 -0400
> Jesse Taube  wrote:
> 
> Hi Jesse,
> 
> > In Binutils 2.37 the ADR instruction has changed
> > use alternate instructions.
> 
> Can you elaborate on this? What has changed exactly, and why? Looking at
> the commit you mention below I don't see an immediate problem that would
> require code changes? Also it speaks of forward references, but this one
> is not one?
> And I didn't spot any difference between 2.38 and 2.35, at least not in my
> isolated test (but I didn't bother to compile a whole stage 1 GCC with
> newer binutils yet).

OK, so digging a bit deeper I think I have an idea:
With as 2.35 I get:
080007cc :
 80007cc:   f2af 0304   subwr3, pc, #4

whereas with 2.38 it's:
080007cc :
 80007cc:   f2af 0303   subwr3, pc, #3

the latter looks correct since we compile relocate.S with -mthumb
-mthumb-interwork, so the lowest bit of the *function* address should be
set, to indicate this is a Thumb function. And "ENTRY(relocate_code)"
clearly tells the assembler that relocate_code is a function entry point,
so should carry the instruction set flag in bit 0.
However we don't use the result of "adr" as an argument for a bx call
later, but to calculate some relocation offset, so the bit is getting in
the way.
Without thinking too much about this, wouldn't it help to just always
clear bit 0 in r3?
Or probably better: to have an additional label, which is not marked as a
function entry point?

Cheers,
Andre

> > The change causes armv7-m to not boot.
> 
> What does "causes armv7-m to not boot" mean? It compiles fine, but hangs
> or crashes?
> Can you show the relevant disassembly from both binutils versions?
> 
> And from trying to reproduce this minimally, do we need a ".syntax unified"
> in the .S file? 
> 
> > Signed-off-by: Jesse Taube 
> > ---
> >  arch/arm/lib/relocate.S | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> > index 14b7f61c1a..22c419534f 100644
> > --- a/arch/arm/lib/relocate.S
> > +++ b/arch/arm/lib/relocate.S
> > @@ -78,7 +78,13 @@ ENDPROC(relocate_vectors)
> >   */
> >  
> >  ENTRY(relocate_code)
> > -   adr r3, relocate_code
> > +/*
> > + * Binutils doesn't comply with the arm docs for adr in thumb2
> > + * from commit d3e52e120b68bf19552743fbc078e0a759f48cb7 onward
> > + * to remove ambiguity explicitly define the pseudo-instruction
> > + */
> > +   mov r3, pc
> > +   subs r3, #4
> 
> But this will break ARM, won't it? Because it would require to subtract #8?
> I mean there is a reason for this adr instruction, because this offset
> calculation is best left to the assembler. Not to speak of the fragility
> of assuming that the relocate_code label is pointing to the very first
> instruction. The ENTRY macro could also insert instructions.
> 
> Cheers,
> Andre
> 
> > ldr r1, _image_copy_start_ofs
> > add r1, r3  /* r1 <- Run &__image_copy_start */
> > subsr4, r0, r1  /* r4 <- Run to copy offset  */
> 

Re: [PATCH v1] arm: relocate: Replace ADR instruction with non-pseudo-instruction

[Andre Przywara]

On Mon, 11 Jul 2022 15:11:13 +0100
Andre Przywara  wrote:

> On Mon, 11 Jul 2022 13:57:40 +0100
> Andre Przywara  wrote:
> 
> Hi,
> 
> > On Sun, 10 Jul 2022 03:09:53 -0400
> > Jesse Taube  wrote:
> > 
> > Hi Jesse,
> >   
> > > In Binutils 2.37 the ADR instruction has changed
> > > use alternate instructions.  
> > 
> > Can you elaborate on this? What has changed exactly, and why? Looking at
> > the commit you mention below I don't see an immediate problem that would
> > require code changes? Also it speaks of forward references, but this one
> > is not one?
> > And I didn't spot any difference between 2.38 and 2.35, at least not in my
> > isolated test (but I didn't bother to compile a whole stage 1 GCC with
> > newer binutils yet).  
> 
> OK, so digging a bit deeper I think I have an idea:
> With as 2.35 I get:
> 080007cc :
>  80007cc:   f2af 0304   subwr3, pc, #4
> 
> whereas with 2.38 it's:
> 080007cc :
>  80007cc:   f2af 0303   subwr3, pc, #3
> 
> the latter looks correct since we compile relocate.S with -mthumb
> -mthumb-interwork, so the lowest bit of the *function* address should be
> set, to indicate this is a Thumb function. And "ENTRY(relocate_code)"
> clearly tells the assembler that relocate_code is a function entry point,
> so should carry the instruction set flag in bit 0.
> However we don't use the result of "adr" as an argument for a bx call
> later, but to calculate some relocation offset, so the bit is getting in
> the way.
> Without thinking too much about this, wouldn't it help to just always
> clear bit 0 in r3?
> Or probably better: to have an additional label, which is not marked as a
> function entry point?

Does that fix it?

diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 14b7f61c1a..5102bfabde 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -78,7 +78,8 @@ ENDPROC(relocate_vectors)
  */
 
 ENTRY(relocate_code)
-   adr r3, relocate_code
+relocate_base:
+   adr r3, relocate_base
ldr r1, _image_copy_start_ofs
add r1, r3  /* r1 <- Run &__image_copy_start */
subsr4, r0, r1  /* r4 <- Run to copy offset  */

Seems to generate the same code with both gas 2.35 and gas 2.38.

Cheers,
Andre

> 
> Cheers,
> Andre
> 
> > > The change causes armv7-m to not boot.  
> > 
> > What does "causes armv7-m to not boot" mean? It compiles fine, but hangs
> > or crashes?
> > Can you show the relevant disassembly from both binutils versions?
> > 
> > And from trying to reproduce this minimally, do we need a ".syntax unified"
> > in the .S file? 
> >   
> > > Signed-off-by: Jesse Taube 
> > > ---
> > >  arch/arm/lib/relocate.S | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> > > index 14b7f61c1a..22c419534f 100644
> > > --- a/arch/arm/lib/relocate.S
> > > +++ b/arch/arm/lib/relocate.S
> > > @@ -78,7 +78,13 @@ ENDPROC(relocate_vectors)
> > >   */
> > >  
> > >  ENTRY(relocate_code)
> > > - adr r3, relocate_code
> > > +/*
> > > + * Binutils doesn't comply with the arm docs for adr in thumb2
> > > + * from commit d3e52e120b68bf19552743fbc078e0a759f48cb7 onward
> > > + * to remove ambiguity explicitly define the pseudo-instruction
> > > + */
> > > + mov r3, pc
> > > + subs r3, #4  
> > 
> > But this will break ARM, won't it? Because it would require to subtract #8?
> > I mean there is a reason for this adr instruction, because this offset
> > calculation is best left to the assembler. Not to speak of the fragility
> > of assuming that the relocate_code label is pointing to the very first
> > instruction. The ENTRY macro could also insert instructions.
> > 
> > Cheers,
> > Andre
> >   
> > >   ldr r1, _image_copy_start_ofs
> > >   add r1, r3  /* r1 <- Run &__image_copy_start */
> > >   subsr4, r0, r1  /* r4 <- Run to copy offset  */  
> >   
> 

[PATCH] rockchip: rk3399: boot_devices: fix eMMC node name

[Quentin Schulz]

From: Quentin Schulz 

When idbloader.img is flashed on the eMMC, the SPL still tries to load
from SPI-NOR first.

This is due to an incorrect look-up in the Device Tree. Since commit
822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
node name (but not label) changed from sdhci@fe33 to mmc@fe33
meaning U-Boot SPL is not looking for the correct node name anymore and
fails to find the "same-as-spl" node when eMMC is the medium from which
the SPL booted.

Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 01a05599cd..de11a3fa30 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define GRF_BASE   0xff77
 
 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-   [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
[BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe32",
 };
@@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
const char *ofpath;
} spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe32" },
-   { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
+   { BOOT_DEVICE_MMC2, "/mmc@fe33" },
{ BOOT_DEVICE_SPI, "/spi@ff1d" },
};
 
-- 
2.36.1

[PATCH] rockchip: rk3399: boot_devices: fix eMMC node name

[Quentin Schulz]

From: Quentin Schulz 

When idbloader.img is flashed on the eMMC, the SPL still tries to load
from SPI-NOR first.

This is due to an incorrect look-up in the Device Tree. Since commit
822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
node name (but not label) changed from sdhci@fe33 to mmc@fe33
meaning U-Boot SPL is not looking for the correct node name anymore and
fails to find the "same-as-spl" node when eMMC is the medium from which
the SPL booted.

Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

Sorry for resend, was not yet subscribed.

 arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 01a05599cd..de11a3fa30 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define GRF_BASE   0xff77
 
 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-   [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
[BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe32",
 };
@@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
const char *ofpath;
} spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe32" },
-   { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
+   { BOOT_DEVICE_MMC2, "/mmc@fe33" },
{ BOOT_DEVICE_SPI, "/spi@ff1d" },
};
 
-- 
2.36.1

Re: [PATCH v2 3/9] clocks: sdm845: Import qcom,gcc-sdm845.h

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> Rather than using magic numbers as clock ids for peripherals import
> qcom,gcc-sdm845.h from Linux to be used standard macros for clock ids.
> So start using corresponding clk-id macro for debug UART.
>
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/sdm845.dtsi|   3 +-
>  arch/arm/mach-snapdragon/clock-sdm845.c |   3 +-
>  include/dt-bindings/clock/qcom,gcc-sdm845.h | 246 
>  3 files changed, 250 insertions(+), 2 deletions(-)
>  create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h
>
> diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
> index 88030156d9..b9506f1297 100644
> --- a/arch/arm/dts/sdm845.dtsi
> +++ b/arch/arm/dts/sdm845.dtsi
> @@ -8,6 +8,7 @@
>
>  /dts-v1/;
>
> +#include 
>  #include "skeleton64.dtsi"
>
>  / {
> @@ -55,7 +56,7 @@
> reg = <0xa84000 0x4000>;
> reg-names = "se_phys";
> clock-names = "se-clk";
> -   clocks = <&gcc 0x58>;
> +   clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
> pinctrl-names = "default";
> pinctrl-0 = <&qup_uart9>;
> qcom,wrapper-core = <0x8a>;
> diff --git a/arch/arm/mach-snapdragon/clock-sdm845.c 
> b/arch/arm/mach-snapdragon/clock-sdm845.c
> index 9572639238..f69be80898 100644
> --- a/arch/arm/mach-snapdragon/clock-sdm845.c
> +++ b/arch/arm/mach-snapdragon/clock-sdm845.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "clock-snapdragon.h"
>
>  #define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
> @@ -84,7 +85,7 @@ ulong msm_set_rate(struct clk *clk, ulong rate)
> struct msm_clk_priv *priv = dev_get_priv(clk->dev);
>
> switch (clk->id) {
> -   case 0x58: /*UART2*/
> +   case GCC_QUPV3_WRAP1_S1_CLK: /*UART2*/
> return clk_init_uart(priv, rate);
> default:
> return 0;
> diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h 
> b/include/dt-bindings/clock/qcom,gcc-sdm845.h
> new file mode 100644
> index 00..968fa65b9c
> --- /dev/null
> +++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h
> @@ -0,0 +1,246 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_SDM_GCC_SDM845_H
> +#define _DT_BINDINGS_CLK_SDM_GCC_SDM845_H
> +
> +/* GCC clock registers */
> +#define GCC_AGGRE_NOC_PCIE_TBU_CLK 0
> +#define GCC_AGGRE_UFS_CARD_AXI_CLK 1
> +#define GCC_AGGRE_UFS_PHY_AXI_CLK  2
> +#define GCC_AGGRE_USB3_PRIM_AXI_CLK3
> +#define GCC_AGGRE_USB3_SEC_AXI_CLK 4
> +#define GCC_BOOT_ROM_AHB_CLK   5
> +#define GCC_CAMERA_AHB_CLK 6
> +#define GCC_CAMERA_AXI_CLK 7
> +#define GCC_CAMERA_XO_CLK  8
> +#define GCC_CE1_AHB_CLK9
> +#define GCC_CE1_AXI_CLK10
> +#define GCC_CE1_CLK11
> +#define GCC_CFG_NOC_USB3_PRIM_AXI_CLK  12
> +#define GCC_CFG_NOC_USB3_SEC_AXI_CLK   13
> +#define GCC_CPUSS_AHB_CLK  14
> +#define GCC_CPUSS_AHB_CLK_SRC  15
> +#define GCC_CPUSS_RBCPR_CLK16
> +#define GCC_CPUSS_RBCPR_CLK_SRC17
> +#define GCC_DDRSS_GPU_AXI_CLK  18
> +#define GCC_DISP_AHB_CLK   19
> +#define GCC_DISP_AXI_CLK   20
> +#define GCC_DISP_GPLL0_CLK_SRC 21
> +#define GCC_DISP_GPLL0_DIV_CLK_SRC 22
> +#define GCC_DISP_XO_CLK23
> +#define GCC_GP1_CLK24
> +#define GCC_GP1_CLK_SRC25
> +#define GCC_GP2_CLK26
> +#define GCC_GP2_CLK_SRC27
> +#define GCC_GP3_CLK28
> +#define GCC_GP3_CLK_SRC29
> +#define GCC_GPU_CFG_AHB_CLK30
> +#define GCC_GPU_GPLL0_CLK_SRC  31
> +#define GCC_GPU_GPLL0_DIV_CLK_SRC  32
> +#define GCC_GPU_MEMNOC_GFX_CLK 33
> +#define GCC_GPU_SNOC_DVM_GFX_CLK   

Re: [PATCH v2 4/9] uart: sdm845: Fix debug UART pinmux

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> Configure debug UART pins as function: "qup9" rather than being regular
> gpios. It fixes a hang seen during pinmux setting.
>
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/sdm845.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
> index b9506f1297..df5b6dfcfc 100644
> --- a/arch/arm/dts/sdm845.dtsi
> +++ b/arch/arm/dts/sdm845.dtsi
> @@ -47,7 +47,7 @@
> /* DEBUG UART */
> qup_uart9: qup-uart9-default {
> pins = "GPIO_4", "GPIO_5";
> -   function = "gpio";
> +   function = "qup9";
> };
> };
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH v2 5/9] board: qualcomm: Add support for dragonboard845c

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> Add support for 96Boards Dragonboard 845C aka Robotics RB3 development
> platform. This board complies with 96Boards Open Platform Specifications.
>
> Features:
> - Qualcomm Snapdragon SDA845 SoC
> - 4GiB RAM
> - 64GiB UFS drive
>
> U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> For detailed build and boot instructions, refer to
> doc/board/qualcomm/sdm845.rst, board: dragonboard845c.
>
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/dragonboard845c-uboot.dtsi   |  37 +++
>  arch/arm/dts/dragonboard845c.dts  |  44 
>  arch/arm/mach-snapdragon/Kconfig  |  14 +++
>  board/qualcomm/dragonboard845c/Kconfig|  12 +++
>  board/qualcomm/dragonboard845c/MAINTAINERS|   6 ++
>  board/qualcomm/dragonboard845c/Makefile   |   9 ++
>  board/qualcomm/dragonboard845c/db845c.its |  63 +++
>  .../dragonboard845c/dragonboard845c.c |   9 ++
>  configs/dragonboard845c_defconfig |  28 +
>  doc/board/qualcomm/sdm845.rst | 100 +++---
>  include/configs/dragonboard845c.h |  28 +
>  11 files changed, 337 insertions(+), 13 deletions(-)
>  create mode 100644 arch/arm/dts/dragonboard845c-uboot.dtsi
>  create mode 100644 arch/arm/dts/dragonboard845c.dts
>  create mode 100644 board/qualcomm/dragonboard845c/Kconfig
>  create mode 100644 board/qualcomm/dragonboard845c/MAINTAINERS
>  create mode 100644 board/qualcomm/dragonboard845c/Makefile
>  create mode 100644 board/qualcomm/dragonboard845c/db845c.its
>  create mode 100644 board/qualcomm/dragonboard845c/dragonboard845c.c
>  create mode 100644 configs/dragonboard845c_defconfig
>  create mode 100644 include/configs/dragonboard845c.h
>
> diff --git a/arch/arm/dts/dragonboard845c-uboot.dtsi 
> b/arch/arm/dts/dragonboard845c-uboot.dtsi
> new file mode 100644
> index 00..8b5a7ee573
> --- /dev/null
> +++ b/arch/arm/dts/dragonboard845c-uboot.dtsi
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * U-Boot addition to handle Qualcomm Robotics RB3 Development Platform
> + * (dragonboard845c) pins
> + *
> + * (C) Copyright 2022 Sumit Garg 
> + */
> +
> +/
> +{
> +   soc {
> +   u-boot,dm-pre-reloc;
> +
> +   serial@a84000 {
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   clock-controller@10 {
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   pinctrl_north@390 {
> +   u-boot,dm-pre-reloc;
> +   };
> +   };
> +};
> +
> +&pm8998_pon {
> +   key_vol_down {
> +   gpios = <&pm8998_pon 1 0>;
> +   label = "key_vol_down";
> +   };
> +   key_power {
> +   gpios = <&pm8998_pon 0 0>;
> +   label = "key_power";
> +   };
> +};
> diff --git a/arch/arm/dts/dragonboard845c.dts 
> b/arch/arm/dts/dragonboard845c.dts
> new file mode 100644
> index 00..1722dce33f
> --- /dev/null
> +++ b/arch/arm/dts/dragonboard845c.dts
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm Robotics RB3 Development (dragonboard845c) board device
> + * tree source
> + *
> + * (C) Copyright 2022 Sumit Garg 
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm845.dtsi"
> +
> +/ {
> +   model = "Thundercomm Dragonboard 845c";
> +   compatible = "thundercomm,db845c", "qcom,sdm845";
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +
> +   aliases {
> +   serial0 = &debug_uart;
> +   };
> +
> +   memory {
> +   device_type = "memory";
> +   reg = <0 0x8000 0 0xfdfa>;
> +   };
> +
> +   psci {
> +   compatible = "arm,psci-1.0";
> +   method = "smc";
> +   };
> +
> +   soc: soc {
> +   serial@a84000 {
> +   status = "okay";
> +   };
> +   };
> +};
> +
> +#include "dragonboard845c-uboot.dtsi"
> diff --git a/arch/arm/mach-snapdragon/Kconfig 
> b/arch/arm/mach-snapdragon/Kconfig
> index 12cf02a56a..cb53dc8901 100644
> --- a/arch/arm/mach-snapdragon/Kconfig
> +++ b/arch/arm/mach-snapdragon/Kconfig
> @@ -44,6 +44,19 @@ config TARGET_DRAGONBOARD820C
>   - 3GiB RAM
>   - 32GiB UFS drive
>
> +config TARGET_DRAGONBOARD845C
> +   bool "96Boards Dragonboard 845C"
> +   help
> + Support for 96Boards Dragonboard 845C aka Robotics RB3 Development
> + Platform. This board complies with 96Boards Open Platform
> + Specifications. Features:
> + - Qualcomm Snapdragon SDA845 SoC
> + - 4GiB RAM
> + - 64GiB UFS drive
> +   select MISC_INIT_R
> +   select SDM845
> +   select DM_ETH if NET
> +
>  config TARGET_STARQLTECHN
> bool "Samsung S9 SM-G9600(starq

Re: [PATCH v2 6/9] mmc: msm_sdhci: Add SDCC version 5.0.0 support

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> For SDCC version 5.0.0, MCI registers are removed from SDCC interface
> and some registers are moved to HC. So add support to use the new
> compatible string "qcom,sdhci-msm-v5". Based on this new msm variant,
> pick the relevant variant data and use it to detect MCI presence thereby
> configuring register read/write to msm specific registers.
>
> Signed-off-by: Sumit Garg 
> ---
>  drivers/mmc/msm_sdhci.c | 96 +++--
>  1 file changed, 64 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
> index d63d7b3a2c..604f9c3ff9 100644
> --- a/drivers/mmc/msm_sdhci.c
> +++ b/drivers/mmc/msm_sdhci.c
> @@ -22,18 +22,17 @@
>  #define SDCC_MCI_POWER_SW_RST BIT(7)
>
>  /* This is undocumented register */
> -#define SDCC_MCI_VERSION 0x50
> -#define SDCC_MCI_VERSION_MAJOR_SHIFT 28
> -#define SDCC_MCI_VERSION_MAJOR_MASK  (0xf << SDCC_MCI_VERSION_MAJOR_SHIFT)
> -#define SDCC_MCI_VERSION_MINOR_MASK  0xff
> +#define SDCC_MCI_VERSION   0x50
> +#define SDCC_V5_VERSION0x318
> +
> +#define SDCC_VERSION_MAJOR_SHIFT   28
> +#define SDCC_VERSION_MAJOR_MASK(0xf << 
> SDCC_VERSION_MAJOR_SHIFT)
> +#define SDCC_VERSION_MINOR_MASK0xff
>
>  #define SDCC_MCI_STATUS2 0x6C
>  #define SDCC_MCI_STATUS2_MCI_ACT 0x1
>  #define SDCC_MCI_HC_MODE 0x78
>
> -/* Offset to SDHCI registers */
> -#define SDCC_SDHCI_OFFSET 0x900
> -
>  /* Non standard (?) SDHCI register */
>  #define SDHCI_VENDOR_SPEC_CAPABILITIES0  0x11c
>
> @@ -47,6 +46,10 @@ struct msm_sdhc {
> void *base;
>  };
>
> +struct msm_sdhc_variant_info {
> +   bool mci_removed;
> +};
> +
>  DECLARE_GLOBAL_DATA_PTR;
>
>  static int msm_sdc_clk_init(struct udevice *dev)
> @@ -85,25 +88,8 @@ static int msm_sdc_clk_init(struct udevice *dev)
> return 0;
>  }
>
> -static int msm_sdc_probe(struct udevice *dev)
> +static int msm_sdc_mci_init(struct msm_sdhc *prv)
>  {
> -   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> -   struct msm_sdhc_plat *plat = dev_get_plat(dev);
> -   struct msm_sdhc *prv = dev_get_priv(dev);
> -   struct sdhci_host *host = &prv->host;
> -   u32 core_version, core_minor, core_major;
> -   u32 caps;
> -   int ret;
> -
> -   host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_BROKEN_R1B;
> -
> -   host->max_clk = 0;
> -
> -   /* Init clocks */
> -   ret = msm_sdc_clk_init(dev);
> -   if (ret)
> -   return ret;
> -
> /* Reset the core and Enable SDHC mode */
> writel(readl(prv->base + SDCC_MCI_POWER) | SDCC_MCI_POWER_SW_RST,
>prv->base + SDCC_MCI_POWER);
> @@ -126,12 +112,45 @@ static int msm_sdc_probe(struct udevice *dev)
> /* Enable host-controller mode */
> writel(1, prv->base + SDCC_MCI_HC_MODE);
>
> -   core_version = readl(prv->base + SDCC_MCI_VERSION);
> +   return 0;
> +}
>
> -   core_major = (core_version & SDCC_MCI_VERSION_MAJOR_MASK);
> -   core_major >>= SDCC_MCI_VERSION_MAJOR_SHIFT;
> +static int msm_sdc_probe(struct udevice *dev)
> +{
> +   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> +   struct msm_sdhc_plat *plat = dev_get_plat(dev);
> +   struct msm_sdhc *prv = dev_get_priv(dev);
> +   const struct msm_sdhc_variant_info *var_info;
> +   struct sdhci_host *host = &prv->host;
> +   u32 core_version, core_minor, core_major;
> +   u32 caps;
> +   int ret;
>
> -   core_minor = core_version & SDCC_MCI_VERSION_MINOR_MASK;
> +   host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_BROKEN_R1B;
> +
> +   host->max_clk = 0;
> +
> +   /* Init clocks */
> +   ret = msm_sdc_clk_init(dev);
> +   if (ret)
> +   return ret;
> +
> +   var_info = (void *)dev_get_driver_data(dev);
> +   if (!var_info->mci_removed) {
> +   ret = msm_sdc_mci_init(prv);
> +   if (ret)
> +   return ret;
> +   }
> +
> +   if (!var_info->mci_removed)
> +   core_version = readl(prv->base + SDCC_MCI_VERSION);
> +   else
> +   core_version = readl(host->ioaddr + SDCC_V5_VERSION);
> +
> +   core_major = (core_version & SDCC_VERSION_MAJOR_MASK);
> +   core_major >>= SDCC_VERSION_MAJOR_SHIFT;
> +
> +   core_minor = core_version & SDCC_VERSION_MINOR_MASK;
>
> /*
>  * Support for some capabilities is not advertised by newer
> @@ -161,9 +180,13 @@ static int msm_sdc_probe(struct udevice *dev)
>  static int msm_sdc_remove(struct udevice *dev)
>  {
> struct msm_sdhc *priv = dev_get_priv(dev);
> +   const struct msm_sdhc_variant_info *var_info;
> +
> +   var_info = (void *)dev_get_driver_data(dev);
>
> -/* Disable host-controller mode */
> -   writel(0, priv->base + SDCC_MCI_HC_MODE);
> +   /* Disable host-control

Re: [PATCH v2 7/9] pinctrl: qcom: Add pinctrl driver for QCS404 SoC

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> Currently this pinctrl driver only supports BLSP UART2 specific pin
> configuration.
>
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/mach-snapdragon/Makefile |  1 +
>  arch/arm/mach-snapdragon/pinctrl-qcs404.c | 55 +++
>  arch/arm/mach-snapdragon/pinctrl-snapdragon.c |  1 +
>  arch/arm/mach-snapdragon/pinctrl-snapdragon.h |  1 +
>  4 files changed, 58 insertions(+)
>  create mode 100644 arch/arm/mach-snapdragon/pinctrl-qcs404.c
>
> diff --git a/arch/arm/mach-snapdragon/Makefile 
> b/arch/arm/mach-snapdragon/Makefile
> index 962855eb8c..cb8c1aa8d2 100644
> --- a/arch/arm/mach-snapdragon/Makefile
> +++ b/arch/arm/mach-snapdragon/Makefile
> @@ -15,4 +15,5 @@ obj-y += dram.o
>  obj-y += pinctrl-snapdragon.o
>  obj-y += pinctrl-apq8016.o
>  obj-y += pinctrl-apq8096.o
> +obj-y += pinctrl-qcs404.o
>  obj-$(CONFIG_SDM845) += pinctrl-sdm845.o
> diff --git a/arch/arm/mach-snapdragon/pinctrl-qcs404.c 
> b/arch/arm/mach-snapdragon/pinctrl-qcs404.c
> new file mode 100644
> index 00..889ead0f57
> --- /dev/null
> +++ b/arch/arm/mach-snapdragon/pinctrl-qcs404.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm QCS404 pinctrl
> + *
> + * (C) Copyright 2022 Sumit Garg 
> + */
> +
> +#include "pinctrl-snapdragon.h"
> +#include 
> +
> +#define MAX_PIN_NAME_LEN 32
> +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> +static const char * const msm_pinctrl_pins[] = {
> +   "SDC1_RCLK",
> +   "SDC1_CLK",
> +   "SDC1_CMD",
> +   "SDC1_DATA",
> +   "SDC2_CLK",
> +   "SDC2_CMD",
> +   "SDC2_DATA",
> +};
> +
> +static const struct pinctrl_function msm_pinctrl_functions[] = {
> +   {"blsp_uart2", 1},
> +};
> +
> +static const char *qcs404_get_function_name(struct udevice *dev,
> +   unsigned int selector)
> +{
> +   return msm_pinctrl_functions[selector].name;
> +}
> +
> +static const char *qcs404_get_pin_name(struct udevice *dev,
> +  unsigned int selector)
> +{
> +   if (selector < 120) {
> +   snprintf(pin_name, MAX_PIN_NAME_LEN, "GPIO_%u", selector);
> +   return pin_name;
> +   } else {
> +   return msm_pinctrl_pins[selector - 120];
> +   }
> +}
> +
> +static unsigned int qcs404_get_function_mux(unsigned int selector)
> +{
> +   return msm_pinctrl_functions[selector].val;
> +}
> +
> +struct msm_pinctrl_data qcs404_data = {
> +   .pin_count = 126,
> +   .functions_count = ARRAY_SIZE(msm_pinctrl_functions),
> +   .get_function_name = qcs404_get_function_name,
> +   .get_function_mux = qcs404_get_function_mux,
> +   .get_pin_name = qcs404_get_pin_name,
> +};
> diff --git a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c 
> b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
> index d1c560dd40..c2148a5d0a 100644
> --- a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
> +++ b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
> @@ -119,6 +119,7 @@ static const struct udevice_id msm_pinctrl_ids[] = {
>  #ifdef CONFIG_SDM845
> { .compatible = "qcom,tlmm-sdm845", .data = (ulong)&sdm845_data },
>  #endif
> +   { .compatible = "qcom,tlmm-qcs404", .data = (ulong)&qcs404_data },
> { }
>  };
>
> diff --git a/arch/arm/mach-snapdragon/pinctrl-snapdragon.h 
> b/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
> index ea524312a0..178ee01a41 100644
> --- a/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
> +++ b/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
> @@ -28,5 +28,6 @@ struct pinctrl_function {
>  extern struct msm_pinctrl_data apq8016_data;
>  extern struct msm_pinctrl_data apq8096_data;
>  extern struct msm_pinctrl_data sdm845_data;
> +extern struct msm_pinctrl_data qcs404_data;
>
>  #endif
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH v2 8/9] clocks: qcom: Add clock driver for QCS404 SoC

[Ramon Fried]

On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
>
> Currently its a dummy clock driver as clocks for UART and eMMC have been
> already enabled by ABL. Along with this import "qcom,gcc-qcs404.h" header
> from Linux mainline to support DT bindings.
I think it's better to initialize the clocks also here, this will
allow the u-boot to be used
instead of ABL. If it's a simple clock configuration, it's not a
problem to re-init it after ABL already did.

Re: [PATCH sunxi/next] spi: sunxi: use XCH status to detect in-progress transfer

[Icenowy Zheng]

在 2022-07-11星期一的 00:03 +0100，Andre Przywara写道：
> On Tue, 28 Jun 2022 14:49:24 +0800
> Icenowy Zheng  wrote:
> 
> Hi Icenowy,
> 
> > The current detection of RX FIFO depth seems to be not reliable,
> > and
> > XCH will self-clear when a transfer is done.
> 
> many thanks for sending this, indeed what I put in -next is broken,
> probably for everything except the F1C100 ;-)
> 
> Digging a bit deeper this gets more interesting, though:
> I chased the issue down to my very first commit, that is (now
> properly!)
> setting the SPI bus frequency in the SPI controller's CCR register.
> It
> turns out that there are more issues in this driver, which lead to an
> actual frequency limit of 1 MHz[1]. So my commit now actually
> programs
> this value, and apparently it's too slow(?) for the code? Raising the
> default 1 to 4 MHz makes it work again (even without your patch). The
> previous timeout is generous, though, but by looking at the FIFO
> status
> register it just seemed to be stuck after clocking out one byte only,
> with the RX buf staying at 0. Reading FSR after your new loop reveals
> that the condition holds (RX FIFO level == nbytes), so there is
> something quite weird going on. Without your patch, but with some
> udelay(1000) after(!) the loop it also works, interestingly.
> 
> As for the actual code change: looking at the XCH bit is probably
> indeed the most robust and clever method of checking for the end of a
> transfer, so I am tempted to take this change. However there are more
> things broken, apparently, and I would like to get to the bottom of
> those issues, before trying to paper over them.
> 
> Cheers,
> Andre
> 
> [1] The driver (as most U-Boot SPI drivers, actually) tries to read
> spi-max-frequency from the SPI's *controller* DT node, although this
> is
> a SPI *slave* property. It (correctly) doesn't find anything in
> there,
> so falls back to some (assumed) safe value of 1 MHz.

Ooops... It sounds like the SPI framework is broken?

> 
> > Check XCH bit when polling for transfer finish.
> 
> 
> > 
> > Signed-off-by: Icenowy Zheng 
> > ---
> >  drivers/spi/spi-sunxi.c | 14 +-
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
> > index 2f7725..a424c6a98e 100644
> > --- a/drivers/spi/spi-sunxi.c
> > +++ b/drivers/spi/spi-sunxi.c
> > @@ -83,7 +83,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >  #endif
> >  #define SUN4I_SPI_MIN_RATE 3000
> >  #define SUN4I_SPI_DEFAULT_RATE 100
> > -#define SUN4I_SPI_TIMEOUT_US   100
> > +#define SUN4I_SPI_TIMEOUT_MS   1000
> >  
> >  #define SPI_REG(priv, reg) ((priv)->base + \
> > (priv)->variant->regs[reg])
> > @@ -326,7 +326,6 @@ static int sun4i_spi_xfer(struct udevice *dev,
> > unsigned int bitlen,
> > struct dm_spi_slave_plat *slave_plat =
> > dev_get_parent_plat(dev);
> >  
> > u32 len = bitlen / 8;
> > -   u32 rx_fifocnt;
> > u8 nbytes;
> > int ret;
> >  
> > @@ -364,13 +363,10 @@ static int sun4i_spi_xfer(struct udevice
> > *dev, unsigned int bitlen,
> > setbits_le32(SPI_REG(priv, SPI_TCR),
> >  SPI_BIT(priv, SPI_TCR_XCH));
> >  
> > -   /* Wait till RX FIFO to be empty */
> > -   ret = readl_poll_timeout(SPI_REG(priv, SPI_FSR),
> > -    rx_fifocnt,
> > -    (((rx_fifocnt &
> > -    SPI_BIT(priv,
> > SPI_FSR_RF_CNT_MASK)) >>
> > -   
> > SUN4I_FIFO_STA_RF_CNT_BITS) >= nbytes),
> > -    SUN4I_SPI_TIMEOUT_US);
> > +   /* Wait for the transfer to be done */
> > +   ret = wait_for_bit_le32((const void *)SPI_REG(priv,
> > SPI_TCR),
> > +   SPI_BIT(priv, SPI_TCR_XCH),
> > +   false,
> > SUN4I_SPI_TIMEOUT_MS, false);
> > if (ret < 0) {
> > printf("ERROR: sun4i_spi: Timeout
> > transferring data\n");
> > sun4i_spi_set_cs(bus, slave_plat->cs,
> > false);
> 

Re: [ANN] U-Boot v2022.07 released

[Simon Glass]

Hi Tom,

On Mon, 11 Jul 2022 at 07:43, Tom Rini  wrote:
>
> Hey all,
>
> It's a week after the initially scheduled release day, but the last week
> was as quiet as I expected, so now we're releasing v2022.07.  At this
> point, the DM_ETH migration is 2 years past the deadline, and I have
> sent some off-list reminders about migration earlier in the year.  One
> of my early tasks for this next release is posting some driver removal
> patches as a last call for migration.
>
> Looking at the v2022.04 release email, I've made more progress on CONFIG
> migrations and others have joined in (thanks!) but there's still much to
> be done, and we still need some buildman work so that genboards.py can
> be fully retired.

On this point, I have a series at dm/buildman-working and should get
it out fairly soon.

>
> On a somewhat related note, my goal for the next release is to migrate
> our wiki content (which people had noted went missing for a bit during
> this cycle) to rST and our documentation site.
>
> In terms of a changelog,
> git log --merges v2022.07-rc6..v2022.07
> contains what I've pulled since the last RC or:
> git log --merges v2022.04..v2022.07
> for changes since the last full release.  As always, more details in
> pull requests (or the tags referenced by them) will result in more
> details here.
>
> And now the merge window continues to be open and I'll merge next in to
> master shortly.  v2022.10 is scheduled for release on Monday, October
> 3rd 2022 and the merge window closes on July 25th.  Thanks all!
>
> --
> Tom

Regards,
Simon

[PATCH 1/2] dt-bindings: mtd: partitions: add binding for U-Boot bootloader

[Rafał Miłecki]

From: Rafał Miłecki 

Right now there is no (known) real reason for a custom binding for
standard U-Boot partitions. Broadcom's U-Boot however requires extra
handling - looking for environment variables subblocks. This commit adds
Broadcom specific binding.

Signed-off-by: Rafał Miłecki 
---
 .../bindings/mtd/partitions/u-boot.yaml   | 49 +++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml

diff --git a/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
new file mode 100644
index ..8a88e7d16524
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/u-boot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: U-Boot bootloader partition
+
+description: |
+  U-Boot is a bootlodaer commonly used in embedded devices. It's almost always
+  located on some kind of flash device.
+
+  Device configuration is stored as a set of environment variables that are
+  located in a (usually standalone) block of data.
+
+maintainers:
+  - Rafał Miłecki 
+
+allOf:
+  - $ref: partition.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - const: brcm,u-boot
+description: |
+  Broadcom stores environment variables inside a U-Boot partition. They
+  can be identified by a custom header with magic value.
+
+unevaluatedProperties: false
+
+examples:
+  - |
+partitions {
+compatible = "fixed-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+compatible = "brcm,u-boot";
+reg = <0x0 0x10>;
+label = "u-boot";
+};
+
+partition@10 {
+reg = <0x10 0x1ff0>;
+label = "firmware";
+};
+};
-- 
2.34.1

[PATCH 2/2] mtd: parsers: add Broadcom's U-Boot parser

[Rafał Miłecki]

From: Rafał Miłecki 

Broadcom stores environment variables blocks inside U-Boot partition
itself. This driver finds & registers them.

Signed-off-by: Rafał Miłecki 
---
 drivers/mtd/parsers/Kconfig   | 10 
 drivers/mtd/parsers/Makefile  |  1 +
 drivers/mtd/parsers/brcm_u-boot.c | 84 +++
 3 files changed, 95 insertions(+)
 create mode 100644 drivers/mtd/parsers/brcm_u-boot.c

diff --git a/drivers/mtd/parsers/Kconfig b/drivers/mtd/parsers/Kconfig
index b43df73927a0..81f2d0a795a6 100644
--- a/drivers/mtd/parsers/Kconfig
+++ b/drivers/mtd/parsers/Kconfig
@@ -20,6 +20,16 @@ config MTD_BCM63XX_PARTS
  This provides partition parsing for BCM63xx devices with CFE
  bootloaders.
 
+config MTD_BRCM_U_BOOT
+   tristate "Broadcom's U-Boot partition parser"
+   depends on ARCH_BCM4908 || COMPILE_TEST
+   help
+ Broadcom uses a custom way of storing U-Boot environment variables.
+ They are placed inside U-Boot partition itself at unspecified offset.
+ It's possible to locate them by looking for a custom header with a
+ magic value. This driver does that and creates subpartitions for
+ each found environment variables block.
+
 config MTD_CMDLINE_PARTS
tristate "Command line partition table parsing"
depends on MTD
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index 2fcf0ab9e7da..23fa4de4016f 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
 obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
 obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
+obj-$(CONFIG_MTD_BRCM_U_BOOT)  += brcm_u-boot.o
 obj-$(CONFIG_MTD_CMDLINE_PARTS)+= cmdlinepart.o
 obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
 ofpart-y   += ofpart_core.o
diff --git a/drivers/mtd/parsers/brcm_u-boot.c 
b/drivers/mtd/parsers/brcm_u-boot.c
new file mode 100644
index ..7c338dc7b8f3
--- /dev/null
+++ b/drivers/mtd/parsers/brcm_u-boot.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2022 Rafał Miłecki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BRCM_U_BOOT_MAX_OFFSET 0x20
+#define BRCM_U_BOOT_STEP   0x1000
+
+#define BRCM_U_BOOT_MAX_PARTS  2
+
+#define BRCM_U_BOOT_MAGIC  0x75456e76  /* uEnv */
+
+struct brcm_u_boot_header {
+   __le32 magic;
+   __le32 length;
+} __packed;
+
+static const char *names[BRCM_U_BOOT_MAX_PARTS] = {
+   "u-boot-env",
+   "u-boot-env-backup",
+};
+
+static int brcm_u_boot_parse(struct mtd_info *mtd,
+const struct mtd_partition **pparts,
+struct mtd_part_parser_data *data)
+{
+   struct brcm_u_boot_header header;
+   struct mtd_partition *parts;
+   size_t bytes_read;
+   size_t offset;
+   int err;
+   int i = 0;
+
+   parts = kcalloc(BRCM_U_BOOT_MAX_PARTS, sizeof(*parts), GFP_KERNEL);
+   if (!parts)
+   return -ENOMEM;
+
+   for (offset = 0;
+offset < min_t(size_t, mtd->size, BRCM_U_BOOT_MAX_OFFSET);
+offset += BRCM_U_BOOT_STEP) {
+   err = mtd_read(mtd, offset, sizeof(header), &bytes_read, 
(uint8_t *)&header);
+   if (err && !mtd_is_bitflip(err)) {
+   pr_err("Failed to read from %s at 0x%zx: %d\n", 
mtd->name, offset, err);
+   continue;
+   }
+
+   if (le32_to_cpu(header.magic) != BRCM_U_BOOT_MAGIC)
+   continue;
+
+   parts[i].name = names[i];
+   parts[i].offset = offset;
+   parts[i].size = sizeof(header) + le32_to_cpu(header.length);
+   i++;
+   pr_info("offset:0x%zx magic:0x%08x BINGO\n", offset, 
header.magic);
+
+   if (i == BRCM_U_BOOT_MAX_PARTS)
+   break;
+   }
+
+   *pparts = parts;
+
+   return i;
+};
+
+static const struct of_device_id brcm_u_boot_of_match_table[] = {
+   { .compatible = "brcm,u-boot" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, brcm_u_boot_of_match_table);
+
+static struct mtd_part_parser brcm_u_boot_mtd_parser = {
+   .parse_fn = brcm_u_boot_parse,
+   .name = "brcm_u-boot",
+   .of_match_table = brcm_u_boot_of_match_table,
+};
+module_mtd_part_parser(brcm_u_boot_mtd_parser);
+
+MODULE_LICENSE("GPL");
-- 
2.34.1

U-Boot SPI DM framework issues

[Andre Przywara]

Hi,

while trying to debug some nasty SPI flash issue on sunxi, I came
across some oddities in the SPI DM framework, and wanted to check some
things, since I am not sure whether I miss things here:

- When I do a simple "sf probe" call, I see *two* calls to the .claim_bus
  callback: the first one from:
drivers/mtd/spi/sf_probe.c:spi_flash_probe_slave(), which is
  expected, but then also, shortly afterwards, a second call from:
drivers/spi/spi-mem.c:spi_mem_exec_op().
  After the probe operation finished, I see the corresponding
  two spi_release_bus() calls. Seeing *two* claim calls in that nested
  way looks rather odd, and the name *claim* sounds like it should be only
  one slave device/driver being able to, well, claim the bus.
  From digging through the code it looks like we call spi_mem_exec_op()
  only from *inside* drivers that already claimed the bus, so shall we
  drop the call inside spi_mem_exec_op()?
  Allowing those nested calls has some consequences for the
  implementation of .claim_bus in the controller drivers, as it does not
  sound indicated to enabled/disable hardware in there. Enabling clock
  gates *again* might not be harmful per se, but if the first .release_bus
  call already disables clocks and resets, this might cause problems.

- In many controller drivers I see the .of_to_plat implementation checking
  for a "spi-max-frequency" property in the *controller's* DT node, mostly
  with a fallback value, and using that frequency as an upper bus
  frequency limit for the whole controller operation. But looking at the
  official DT bindings, this property is supposed to be a *slave device*
  property, and indeed checking a few dozen .dts file I see it only being
  used in *child* nodes of SPI controllers, never in controller nodes.
  There is some proper usage in
  drivers/spi/spi-uclass.c:spi_slave_of_to_plat(), but to me it looks like
  the bus node code is wrong and should be removed, from the other
  invocation in spi-uclass.c and all the controller drivers.
  For sunxi (and probably others) this has the consequence of limiting the
  whole bus to some "default" frequency limit, which is rather low:
#define SUN4I_SPI_DEFAULT_RATE  100
plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
  "spi-max-frequency",
  SUN4I_SPI_DEFAULT_RATE);
  So we never go beyond this 1 MHz, even though the SPI flash chips
  explicitly advertise 40MHz or more in their child nodes.

Please let me know if I am missing something here! If not, I am happy to
send some patches aiming at fixing those things.

Cheers,
Andre

Re: [PATCH v1] arm: relocate: Replace ADR instruction with non-pseudo-instruction

[Jesse Taube]

On 7/11/22 08:57, Andre Przywara wrote:
> On Sun, 10 Jul 2022 03:09:53 -0400
> Jesse Taube  wrote:
> 
> Hi Jesse,
> 
>> In Binutils 2.37 the ADR instruction has changed
>> use alternate instructions.
> 
> Can you elaborate on this? What has changed exactly, and why? Looking at
> the commit you mention below I don't see an immediate problem that would
> require code changes? Also it speaks of forward references, but this one
> is not one?
> And I didn't spot any difference between 2.38 and 2.35, at least not in my
> isolated test (but I didn't bother to compile a whole stage 1 GCC with
> newer binutils yet).
> 
>> The change causes armv7-m to not boot.
> 
> What does "causes armv7-m to not boot" mean? It compiles fine, but hangs
> or crashes?
well when we reallocate it doesn't copy the whole instruction
so its an invalid instruction and boot loops.
> Can you show the relevant disassembly from both binutils versions?
> 
> And from trying to reproduce this minimally, do we need a ".syntax unified"
> in the .S file? 
Yes its required. sorry i didn't post the test code here...
The test code is as follows
```
.syntax unified
.global bug;
.align 4
bug:

 adr r3, bug
.size bug, .-bug
.type bug 2; // This changes offset from 4 to 3 in
include/linux/linkage.h:ENDPROC
//arm-linux-gnueabi-as  -march=armv7-m -c -o bug.o bug.S &&
arm-linux-gnueabi-objdump --disassemble=bug bug.o
```
> 
>> Signed-off-by: Jesse Taube 
>> ---
>>  arch/arm/lib/relocate.S | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
>> index 14b7f61c1a..22c419534f 100644
>> --- a/arch/arm/lib/relocate.S
>> +++ b/arch/arm/lib/relocate.S
>> @@ -78,7 +78,13 @@ ENDPROC(relocate_vectors)
>>   */
>>  
>>  ENTRY(relocate_code)
>> -adr r3, relocate_code
>> +/*
>> + * Binutils doesn't comply with the arm docs for adr in thumb2
>> + * from commit d3e52e120b68bf19552743fbc078e0a759f48cb7 onward
>> + * to remove ambiguity explicitly define the pseudo-instruction
>> + */
>> +mov r3, pc
>> +subs r3, #4
> 
> But this will break ARM, won't it? Because it would require to subtract #8?
> I mean there is a reason for this adr instruction, because this offset
> calculation is best left to the assembler. Not to speak of the fragility
> of assuming that the relocate_code label is pointing to the very first
> instruction. The ENTRY macro could also insert instructions.
> 
> Cheers,
> Andre
> 
>>  ldr r1, _image_copy_start_ofs
>>  add r1, r3  /* r1 <- Run &__image_copy_start */
>>  subsr4, r0, r1  /* r4 <- Run to copy offset  */
> 

[PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

[Tom Rini]

Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
The changes here are for formatting or slight rewording so that it reads
well when linking to other Sphinx documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
  Heinrich
---
 doc/develop/codingstyle.rst | 255 
 doc/develop/index.rst   |   8 ++
 2 files changed, 263 insertions(+)
 create mode 100644 doc/develop/codingstyle.rst

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
new file mode 100644
index ..bbeca42e656b
--- /dev/null
+++ b/doc/develop/codingstyle.rst
@@ -0,0 +1,255 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Coding Style
+===
+
+The following Coding Style requirements shall be mandatory for all code 
contributed to
+the U-Boot project.
+
+Exceptions are only allowed if code from other projects is integrated with no
+or only minimal changes.
+
+The following rules apply:
+
+* All contributions to U-Boot should conform to the `Linux kernel
+  coding style 
`_
+  and the `Lindent script 
`_.
+  * The exception for net files to the `multi-line comment
+  
`_
+  applies only to Linux, not to U-Boot. Only large hunks which are copied
+  unchanged from Linux may retain that comment format.
+
+* Use patman to send your patches (``tools/patman/patman -H`` for full
+  instructions). With a few tags in your commits this will check your patches
+  and take care of emailing them.
+
+* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
+  more information, read :doc:`checkpatch`. Note that this should be done
+  *before* posting on the mailing list!
+
+* Source files originating from different projects (for example the MTD
+  subsystem or the hush shell code from the BusyBox project) may, after
+  careful consideration, be exempted from these rules. For such files, the
+  original coding style may be kept to ease subsequent migration to newer
+  versions of those sources.
+
+* Please note that U-Boot is implemented in C (and to some small parts in
+  Assembler); no C++ is used, so please do not use C++ style comments (//) in
+  your code.
+
+  * The sole exception here is for SPDX tags in some files (checkpatch.pl will 
warn you).
+
+* Please also stick to the following formatting rules:
+
+  * Remove any trailing white space
+
+  * Use TAB characters for indentation and vertical alignment, not spaces
+
+  * Make sure NOT to use DOS ``\r\n`` line feeds
+
+  * Do not add more than 2 consecutive empty lines to source files
+
+  * Do not add trailing empty lines to source files
+
+  * Using the option ``git config --global color.diff auto`` will help to
+visually see whitespace problems in ``diff`` output from ``git``.
+
+  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
+feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The Right
+Thing (tm)
+
+Submissions of new code or patches that do not conform to these requirements
+shall be rejected with a request to reformat the changes.
+
+U-Boot Code Documentation
+-
+
+U-Boot adopted the kernel-doc annotation style, this is the only exception from
+multi-line comment rule of Coding Style. While not mandatory, adding
+documentation is strongly advised. The Linux kernel `kernel-doc
+`_
+documentation applies with no changes.
+
+Use structures for I/O access
+-
+
+U-Boot typically uses a C structure to map out the registers in an I/O region,
+rather than offsets. The reasons for this are:
+
+* It dissociates the register location (offset) from the register type, which
+  means the developer has to make sure the type is right for each access,
+  whereas with the struct method, this is checked by the compiler;
+
+* It avoids actually writing all offsets, which is (more) error- prone;
+
+* It allows for better compile time sanity-checking of values we write to 
registers.
+
+Some reasons why you might not use C structures:
+
+* Where the registers appear at different offsets in different hardware
+  revisions supported by the same driver
+
+* Where the driver only uses a small subset of registers and it is not worth
+  defining a struct to cover them all, with large empty regions
+
+* Where the offset of a register might be hard to figure out when buried a long
+  way down a structure, possibly with embedded sub-structures
+
+* This may need to change to the kernel model if we allow for more run-time
+  detection of what drivers are appropriate for what we're running on.
+
+Please use check_membe

[PATCH 2/7] doc: Migrate DesignPrinciples wiki page to Sphinx

[Tom Rini]

Move the current DesignPrinciples wiki page to
doc/develop/designprinciples.rst.  The changes here are for formatting
or slight rewording so that it reads well when linking to other Sphinx
documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
  Heinrich
---
 doc/develop/designprinciples.rst | 205 +++
 doc/develop/index.rst|   1 +
 2 files changed, 206 insertions(+)
 create mode 100644 doc/develop/designprinciples.rst

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
new file mode 100644
index ..43aeb5dacf5f
--- /dev/null
+++ b/doc/develop/designprinciples.rst
@@ -0,0 +1,205 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Design Principles
+
+
+The 10 Golden Rules of U-Boot design
+
+
+Keep it Small
+^
+
+U-Boot is a Boot Loader, i.e. its primary purpose in the shipping
+system is to load some operating system.
+That means that U-Boot is
+necessary to perform a certain task, but it's nothing you want to
+throw any significant resources at. Typically U-Boot is stored in
+relatively small NOR flash memory, which is expensive
+compared to the much larger NAND devices often used to store the
+operating system and the application.
+
+At the moment, U-Boot supports boards with just 128 KiB ROM or with
+256 KiB NOR flash. We should not easily ignore such configurations -
+they may be the exception in among all the other supported boards,
+but if a design uses such a resource-constrained hardware setup it is
+usually because costs are critical, i. e. because the number of
+manufactured boards might be tens or hundreds of thousands or even
+millions...
+
+A usable and useful configuration of U-Boot, including a basic
+interactive command interpreter, support for download over Ethernet
+and the capability to program the flash shall fit in no more than 128 !KiB.
+
+Keep it Fast
+
+
+The end user is not interested in running U-Boot. In most embedded
+systems he is not even aware that U-Boot exists. The user wants to
+run some application code, and that as soon as possible after switching
+on his device.
+
+It is therefore essential that U-Boot is as fast as possible,
+especially that it loads and boots the operating system as fast as possible.
+
+To achieve this, the following design principles shall be followed:
+
+* Enable caches as soon and whenever possible
+
+* Initialize devices only when they are needed within U-Boot, i.e. don't
+  initialize the Ethernet interface(s) unless U-Boot performs a download over
+  Ethernet; don't  initialize any IDE or USB devices unless U-Boot actually
+  tries to load files from these, etc.  (and don't forget to shut down these
+  devices after using them  - otherwise nasty things may happen when you try to
+  boot your OS).
+
+Also, building of U-Boot shall be as fast as possible.
+This makes it easier to run a build for all supported configurations
+or at least for all configurations of a specific architecture,
+which is essential for quality assurance.
+If building is cumbersome and slow, most people will omit
+this important step.
+
+Keep it Simple
+^^
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities
+
+Keep it Portable
+
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities that are
+very closely related to hardware development. So far, it has been
+ported to several hundreds of different boards on about 30 different
+processor families - please make sure that any code you add can be
+used on as many different platforms as possible.
+
+Avoid assembly language whenever possible - only the reset code with
+basic CPU initialization, maybe a static DRAM initialization and the C
+stack setup should be in assembly.
+All further initializations should be done in C using assembly/C
+subroutines or inline macros. These functions represent some
+kind of HAL functionality and should be defined consistently on all
+architectures. E.g. Basic MMU and cache control, stack pointer manipulation.
+Non-existing functions should expand into empty macros or error codes.
+
+Don't make assumptions over the environment where U-Boot is running.
+It may be communicating with a human operator on directly attached
+serial console, but it may be through a GSM modem as well, or driven
+by some automatic test or control system. So don't output any fancy
+control character sequences or similar.
+
+Keep it Configurable
+
+
+Section "Keep it Small" already explains about the size restrictions
+for U-Boot on one side. On the other side, U-Boot is a powerful tool
+with many, many extremely useful features. The maintainer or user of
+each board will have to 

[PATCH 3/7] doc: codingstyle: Remove comment about '//' style comments

[Tom Rini]

For some time now we've allowed for '//' style comments, which mirrors
the Linux kernel.  So drop this point here.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- None
---
 doc/develop/codingstyle.rst | 6 --
 1 file changed, 6 deletions(-)

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
index bbeca42e656b..fdc1f594babc 100644
--- a/doc/develop/codingstyle.rst
+++ b/doc/develop/codingstyle.rst
@@ -33,12 +33,6 @@ The following rules apply:
   original coding style may be kept to ease subsequent migration to newer
   versions of those sources.
 
-* Please note that U-Boot is implemented in C (and to some small parts in
-  Assembler); no C++ is used, so please do not use C++ style comments (//) in
-  your code.
-
-  * The sole exception here is for SPDX tags in some files (checkpatch.pl will 
warn you).
-
 * Please also stick to the following formatting rules:
 
   * Remove any trailing white space
-- 
2.25.1

[PATCH 4/7] doc: Migrate Process wiki page to Sphinx

[Tom Rini]

Move the current Process wiki page to doc/develop/process.rst.  The
changes here are for formatting or slight rewording so that it reads
well when linking to other Sphinx documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
  Heinrich
---
 doc/develop/index.rst   |   1 +
 doc/develop/process.rst | 200 
 2 files changed, 201 insertions(+)
 create mode 100644 doc/develop/process.rst

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index c0f4f0ba413a..eab00a55382a 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -11,6 +11,7 @@ General
 
codingstyle
designprinciples
+   process
 
 Implementation
 --
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
new file mode 100644
index ..534da4a2a704
--- /dev/null
+++ b/doc/develop/process.rst
@@ -0,0 +1,200 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Development Process
+==
+
+Management Summary
+--
+
+* Development happens in Release Cycles of 3 months.
+
+* The first 2 weeks are called Merge Window, which is followed by a
+  Stabilization Period.
+
+* Patches with new code get only accepted while the Merge Window is open.
+
+* A patch that is generally in good shape and that was submitted while the
+  Merge Window was open is eligible to go into the upcoming release, even if
+  changes and resubmits are needed.
+
+* During the Stabilization Period, only patches that contain bug fixes get
+  applied.
+
+Phases of the Development Process
+-
+
+U-Boot development takes place in `Release Cycles
+`_.  A Release Cycle lasts
+normally for three months.
+
+The first two weeks of each Release Cycle are called *Merge Window*.
+
+It is followed by a *Stabilization Period*.
+
+The end of a Release Cycle is marked by the release of a new U-Boot version.
+
+Merge Window
+
+
+The Merge Window is the period when new patches get submitted
+(and hopefully accepted) for inclusion into U-Boot mainline.
+
+This is the only time when new code (like support for new processors or new
+boards, or other new features or reorganization of code) is accepted.
+
+Twilight Time
+-
+
+Usually patches do not get accepted as they are - the peer review that takes
+place will usually require changes and resubmits of the patches before they
+are considered to be ripe for inclusion into mainline.
+
+Also, the review often happens not immediately after a patch was submitted,
+but only when somebody (usually the responsible custodian) finds time to do
+this.
+
+In the result, the final version of such patches gets submitted after the
+merge window has been closed.
+
+It is current practice in U-Boot that such patches are eligible to go into the
+upcoming release.
+
+In the result, the release of the ``"-rc1"`` version does not immediately 
follow
+the closing of the Merge Window.
+
+Stabilization Period
+
+
+During the Stabilization Period only patches containing bug fixes get
+applied.
+
+Corner Cases
+
+
+Sometimes it is not clear if a patch contains a bug fix or not.
+For example, changes that remove dead code, unused macros etc. or
+that contain Coding Style fixes are not strict bug fixes.
+
+In such situations it is up to the responsible custodian to decide if he
+applies such patches even when the Merge Window is closed.
+
+Exception: at the end of the Stabilization Period only strict bug
+fixes my be applied.
+
+Sometimes patches miss the the Merge Window slightly - say by few
+hours or even a day. Patch acceptance is not as critical as a
+financial transaction, or such. So if there is such a slight delay,
+the custodian is free to turn a blind eye and accept it anyway. The
+idea of the development process is to make it foreseeable,
+but not to slow down development.
+
+It makes more sense if an engineer spends another day on testing and
+cleanup and submits the patch a couple of hours late, instead of
+submitting a green patch which will waste efforts from several people
+during several rounds of review and reposts.
+
+Differences to the Linux Development Process
+
+
+* In Linux, top-level maintainers will collect patches in their trees and send
+  pull requests to Linus as soon as the merge window opens.
+  So far, most U-Boot custodians do not work like that; they send pull requests
+  only at (or even after) the end of the merge window.
+
+* In Linux, the closing of the merge window is marked by the release of the
+  next ``"-rc1"``
+  In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
+  the) patches that were submitted during the merge window have been applied.
+
+Custodians
+--
+
+The Custodians take responsibility for some area of th

[PATCH 5/7] designprinciples.rst: Perform minor cleanups

[Tom Rini]

- Remove some missed wiki markup, and escape a "\n" correctly.
- Use gender-neutral language to refer to the user, consistently.

Cc: Claudius Heine 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- None
---
 doc/develop/designprinciples.rst | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
index 43aeb5dacf5f..e5e12dca79f5 100644
--- a/doc/develop/designprinciples.rst
+++ b/doc/develop/designprinciples.rst
@@ -28,15 +28,15 @@ millions...
 
 A usable and useful configuration of U-Boot, including a basic
 interactive command interpreter, support for download over Ethernet
-and the capability to program the flash shall fit in no more than 128 !KiB.
+and the capability to program the flash shall fit in no more than 128 KiB.
 
 Keep it Fast
 
 
 The end user is not interested in running U-Boot. In most embedded
-systems he is not even aware that U-Boot exists. The user wants to
+systems they are not even aware that U-Boot exists. The user wants to
 run some application code, and that as soon as possible after switching
-on his device.
+on their device.
 
 It is therefore essential that U-Boot is as fast as possible,
 especially that it loads and boots the operating system as fast as possible.
@@ -63,7 +63,7 @@ Keep it Simple
 ^^
 
 U-Boot is a boot loader, but it is also a tool used for board
-bring-up, for production testing, and for other activities
+bring-up, for production testing, and for other activities.
 
 Keep it Portable
 
@@ -96,13 +96,13 @@ Keep it Configurable
 Section "Keep it Small" already explains about the size restrictions
 for U-Boot on one side. On the other side, U-Boot is a powerful tool
 with many, many extremely useful features. The maintainer or user of
-each board will have to decide which features are important to him and
-what shall be included with his specific board configuration to meet
-his current requirements and restrictions.
+each board will have to decide which features are important to them and
+what shall be included with their specific board configuration to meet
+their current requirements and restrictions.
 
 Please make sure that it is easy to add or remove features from a
 board configuration, so everybody can make the best use of U-Boot on
-his system.
+their system.
 
 If a feature is not included, it should not have any residual code
 bloating the build.
@@ -126,7 +126,7 @@ debug is all the more important to many of us.
 * All initialization steps shall print some "begin doing this" message before
   they actually start, and some "done" message when they complete. For example,
   RAM initialization and size detection may print a "RAM: " before they start,
-  and "256 MB\n" when done.  The purpose of this is that you can always see
+  and "256 MB\\n" when done.  The purpose of this is that you can always see
   which initialization step was running if there should be any problem.  This
   is important not only during software development, but also for the service
   people dealing with broken hardware in the field.
@@ -143,8 +143,8 @@ Please always keep in mind that there are at least three 
different
 groups of users for U-Boot, with completely different expectations
 and requirements:
 
-* The end user of an embedded device just wants to run some application; he
-  does not even want to know that U-Boot exists and only rarely interacts with
+* The end user of an embedded device just wants to run some application; they
+  do not even want to know that U-Boot exists and only rarely interacts with
   it (for example to perform a reset to factory default settings etc.)
 
 * System designers and engineers working on the development of the application
@@ -157,7 +157,7 @@ and requirements:
   their hardware is easy for them.
 
 * Make it easy to test. Add debug code (but don't re-invent the wheel - use
-  existing macros like debug() or debugX()).
+  existing macros like debug()).
 
 Please always keep in mind that U-Boot tries to meet all these
 different requirements.
-- 
2.25.1

[PATCH 6/7] process.rst: Perform minor cleanups

[Tom Rini]

- Use gender-neutral language to refer to the user, consistently.
- Reword a few places so that they read more naturally.
- Make the long standing practice around "Twilight Time" more clear,
  hopefully.
- Replace a reference to MAKEALL with a reference to CI testing as
  that's the current requirement.

Cc: Claudius Heine 
Cc: Martin Bonner 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Further tweak the wording, per Martin
---
 doc/develop/process.rst | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 534da4a2a704..d0c46b58f3e9 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -46,21 +46,22 @@ Twilight Time
 -
 
 Usually patches do not get accepted as they are - the peer review that takes
-place will usually require changes and resubmits of the patches before they
+place will usually require changes and resubmissions of the patches before they
 are considered to be ripe for inclusion into mainline.
 
-Also, the review often happens not immediately after a patch was submitted,
+Also the review often happens not immediately after a patch was submitted,
 but only when somebody (usually the responsible custodian) finds time to do
 this.
 
-In the result, the final version of such patches gets submitted after the
+The result is that the final version of such patches gets submitted after the
 merge window has been closed.
 
 It is current practice in U-Boot that such patches are eligible to go into the
 upcoming release.
 
-In the result, the release of the ``"-rc1"`` version does not immediately 
follow
-the closing of the Merge Window.
+The result is that the release of the ``"-rc1"`` version and formal closing of
+the Merge Window does not preclude patches that were already posted from being
+merged for the upcoming release.
 
 Stabilization Period
 
@@ -75,13 +76,13 @@ Sometimes it is not clear if a patch contains a bug fix or 
not.
 For example, changes that remove dead code, unused macros etc. or
 that contain Coding Style fixes are not strict bug fixes.
 
-In such situations it is up to the responsible custodian to decide if he
-applies such patches even when the Merge Window is closed.
+In such situations it is up to the responsible custodian to decide if they
+apply such patches even when the Merge Window is closed.
 
 Exception: at the end of the Stabilization Period only strict bug
 fixes my be applied.
 
-Sometimes patches miss the the Merge Window slightly - say by few
+Sometimes patches miss the Merge Window slightly - say by a few
 hours or even a day. Patch acceptance is not as critical as a
 financial transaction, or such. So if there is such a slight delay,
 the custodian is free to turn a blind eye and accept it anyway. The
@@ -110,7 +111,7 @@ Custodians
 --
 
 The Custodians take responsibility for some area of the U-Boot code.  The
-in-tree ``MAINTAINERS`` files list who is reponsible for which areas.
+in-tree ``MAINTAINERS`` files list who is responsible for which areas.
 
 It is their responsibility to pick up patches from the mailing list
 that fall into their responsibility, and to process these.
@@ -155,7 +156,7 @@ like this:
 
#. Applies cleanly to the source tree
 
-   #. passes a ``MAKEALL`` compile test without creating new warnings
+   #. Passes :doc:`ci_testing` as this checks for new warnings and other 
issues.
 
 #. Notes:
 
@@ -167,7 +168,7 @@ like this:
 
   #. This is well documented in :doc:`designprinciples`.
 
-  #. The custodian decides himself how recent the code must be.  It is
+  #. The custodian decides themselves how recent the code must be.  It is
  acceptable to request patches against the last officially released
  version of U-Boot or newer.  Of course a custodian can also accept
  patches against older code.
@@ -177,7 +178,7 @@ like this:
 
 #. The custodian decides to accept or to reject the patch.
 
-#. If accepted, the custodian adds the patch to his public git repository and
+#. If accepted, the custodian adds the patch to their public git repository and
notifies the mailing list. This note should include:
 
* a short description of the changes
@@ -186,15 +187,15 @@ like this:
 
* suggested tests
 
-   Although the custodian is supposed to perform his own tests
-   it is a well-known and accepted fact that he needs help from
+   Although the custodian is supposed to perform their own tests
+   it is a well-known and accepted fact that they needs help from
other developers who - for example - have access to the required
hardware or tool chains.
The custodian request help for tests and feedback from
specific maintainers and U-Boot users.
 
 #. Once tests are passed, some agreed time limit expires, the custodian
-   requests that the changes in his public git repository be merged into the
-   main tree. If necessary, the cust

[PATCH 7/7] process.rst: Modernize the "Workflow of a Custodian" section

[Tom Rini]

The "Workflow of a Custodian" section on the wiki had not been changed
in quite some time to reflect how the process has been functioning for
some time.  First, update some links to point to modern and current
sources of information.

Second, and more overarching, reword much of the section.  This expands
on the expectations of both custodians and developers when it comes to
rebasing patches.  Rework the final points to be clearer that Custodians
are expected to do their best to test the changes and ask for help when
needed, as well as that pull requests are expected in a timely manner.

Cc: Claudius Heine 
Cc: Martin Bonner 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- New patch
---
 doc/develop/process.rst | 88 -
 1 file changed, 42 insertions(+), 46 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index d0c46b58f3e9..56c9d274be71 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -132,16 +132,20 @@ Work flow of a Custodian
 The normal flow of work in the U-Boot development process will look
 like this:
 
-#. A developer submits a patch via e-mail to the u-boot-users mailing list.
-   U-Boot has adopted the `Linux kernel signoff policy 
`_, so the 
submitter must
-   include a ``Signed-off-by:`` line.
+#. A developer submits a patch via e-mail to the u-boot mailing list.  In
+   U-Boot, we make use of the `Developer Certificate of Origin
+   `_ that is common in other projects such
+   as the Linux kernel.  Following this and adding a ``Signed-off-by:`` line
+   that contains the developer's name and email address is required.
 
-#. Everybody who can is invited to review and test the changes.  Reviews should
-   reply on the mailing list with ``Acked-by`` lines.
+#. Everybody who can is invited to review and test the changes.  Typically, we
+   follow the same guidelines as the Linux kernel for `Acked-by
+   
`_
+   as well as `Reviewed-by
+   
`_
+   and similar additional tags.
 
-#. The responsible custodian
-
-   #. inspects this patch, especially for:
+#. The responsible custodian inspects this patch, especially for:
 
#. :doc:`codingstyle`
 
@@ -152,50 +156,42 @@ like this:
   * The patch does not introduce new problems, especially it does not break
 other boards or architectures
 
-   #. U-Boot Philosophy
+   #. U-Boot Philosophy, as documented in :doc:`designprinciples`.
 
-   #. Applies cleanly to the source tree
+   #. Applies cleanly to the source tree.  The custodian is expected to put in
+  a "best effort" if a patch does not apply cleanly, but can be made to 
apply
+  still.  It is up to the custodian to decide how recent of a commit the
+  patch must be against.  It is acceptable to request patches against the
+  last officially released version of U-Boot or newer.  Of course a
+  custodian can also accept patches against older code.  It can be
+  difficult to find the correct balance between putting too much work on
+  the custodian or too much work on an individual submitting a patch when
+  something does not apply cleanly.
 
#. Passes :doc:`ci_testing` as this checks for new warnings and other 
issues.
 
-#. Notes:
-
-  #. In some cases more than one custodian may be affected or feel responsible.
- To avoid duplicated efforts, the custodian who starts processing the
- patch should send a short ACK to the mailing list.
-
-  #. We should create some tool to automatically do this.
-
-  #. This is well documented in :doc:`designprinciples`.
-
-  #. The custodian decides themselves how recent the code must be.  It is
- acceptable to request patches against the last officially released
- version of U-Boot or newer.  Of course a custodian can also accept
- patches against older code.
-
-  #. Commits should show original author in the ``author`` field and include 
all
-  sign off/ack lines.
-
-#. The custodian decides to accept or to reject the patch.
-
-#. If accepted, the custodian adds the patch to their public git repository and
-   notifies the mailing list. This note should include:
+#. Note that in some cases more than one custodian may feel responsible for a
+   particular change.  To avoid duplicated efforts, the custodian who starts
+   processing the patch should follow up to the email saying they intend to
+   pick it up.
 
-   * a short description of the changes
+#. Commits must show original author in the ``author`` field and include all of
+   the ``Signed-off-by``, ``Reviewed-by``, etc, tags that have been submitted.
 
-   * the list of the affect

[PATCH 1/1] net: phy: possible NULL dereference in fixed_phy_create()

[Heinrich Schuchardt]

We check if phydev is NULL. Only but if it is non-NULL we set one
component of phydev. But even if it is NULL we set another. We should not
dereference NULL in either case.

Fixes: e24b58f5ed4f ("net: phy: don't require PHY interface mode during PHY 
creation")
Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/phy/phy.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 1121b99abf..945642ed93 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -984,10 +984,10 @@ struct phy_device *fixed_phy_create(ofnode node)
}
 
phydev = phy_device_create(NULL, 0, PHY_FIXED_ID, false);
-   if (phydev)
+   if (phydev) {
phydev->node = subnode;
-
-   phydev->interface = ofnode_read_phy_mode(node);
+   phydev->interface = ofnode_read_phy_mode(node);
+   }
 
return phydev;
 }
-- 
2.36.1

[PATCH] configs: stm32m15: support STM32MP_BOARD_EXTRA_ENV for st boards

[Patrick Delaunay]

Correctly handle STM32MP_BOARD_EXTRA_ENV define in stm32mp15_st_common.h;
the STM32MP_BOARD_EXTRA_ENV is added in CONFIG_EXTRA_ENV_SETTINGS
definition, as it is done "stm32mp15_st_common.h"

Without this patch, the content of STM32MP_BOARD_EXTRA_ENV is not used in
the default environment for STMicroelectronics boards.

Fixes: 806c4dd31532 ("configs: stm32mp1: set the console variable for 
extlinux.conf")
Reported-by: Gatien CHEVALLIER 
Signed-off-by: Patrick Delaunay 
---

 include/configs/stm32mp15_st_common.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/stm32mp15_st_common.h 
b/include/configs/stm32mp15_st_common.h
index 37b216e6e9f..6bdc286cfca 100644
--- a/include/configs/stm32mp15_st_common.h
+++ b/include/configs/stm32mp15_st_common.h
@@ -48,7 +48,8 @@
ST_STM32MP1_BOOTCMD \
STM32MP_PARTS_DEFAULT \
BOOTENV \
-   STM32MP_EXTRA
+   STM32MP_EXTRA \
+   STM32MP_BOARD_EXTRA_ENV
 
 #endif
 #endif
-- 
2.25.1

[PATCH 1/1] cmd: undefined return value of do_extension_apply()

[Heinrich Schuchardt]

If 'extension apply all' is executed and no extension is found, the return
value of do_extension_apply() is undefined. Return CMD_RET_FAILURE in this
case.

Fixes: 2f84e9cf06d3 ("cmd: add support for a new "extension" command")
Signed-off-by: Heinrich Schuchardt 
---
 cmd/extension_board.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/extension_board.c b/cmd/extension_board.c
index bbb4812ff8..f94abd612d 100644
--- a/cmd/extension_board.c
+++ b/cmd/extension_board.c
@@ -111,6 +111,7 @@ static int do_extension_apply(struct cmd_tbl *cmdtp, int 
flag,
return CMD_RET_USAGE;
 
if (strcmp(argv[1], "all") == 0) {
+   ret = CMD_RET_FAILURE;
list_for_each_entry(extension, &extension_list, list) {
ret = extension_apply(extension);
if (ret != CMD_RET_SUCCESS)
-- 
2.36.1

Re: [PATCH] rockchip: rk3399: boot_devices: fix eMMC node name

[Xavier Drudis Ferran]

El Mon, Jul 11, 2022 at 04:15:33PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> When idbloader.img is flashed on the eMMC, the SPL still tries to load
> from SPI-NOR first.
> 
> This is due to an incorrect look-up in the Device Tree. Since commit
> 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
> node name (but not label) changed from sdhci@fe33 to mmc@fe33
> meaning U-Boot SPL is not looking for the correct node name anymore and
> fails to find the "same-as-spl" node when eMMC is the medium from which
> the SPL booted.
>

Yes, I also saw that. I changed and tested it at some time, but since there
were other changes, I hesitate to send a Tested by for your patch. FWIW:

Reviewed-by: Xavier Drudis Ferran 

 
> Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
> 
> Sorry for resend, was not yet subscribed.
> 
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 01a05599cd..de11a3fa30 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define GRF_BASE 0xff77
>  
>  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> - [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
> + [BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
>   [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
>   [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
>  };
> @@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
>   const char *ofpath;
>   } spl_boot_devices_tbl[] = {
>   { BOOT_DEVICE_MMC1, "/mmc@fe32" },
> - { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
> + { BOOT_DEVICE_MMC2, "/mmc@fe33" },
>   { BOOT_DEVICE_SPI, "/spi@ff1d" },

Not related to this patch, but I also changed "/spi@ff1d" -> 
"/spi@ff1d/flash@0".
Not sure whether it needs to be different in both arrays in some case for some 
reason.

>   };
>  
> -- 
> 2.36.1
> 

[PATCH 1/3] doc: environment: Drop u-boot_addr_r

[Tom Rini]

This variable is never set nor explained why it would be set, drop it.

Reviewed-by: Simon Glass 
Reviewed-by: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- None
---
 doc/usage/environment.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 28a8952b7528..a3f23d4e4e22 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -390,7 +390,6 @@ in U-Boot code.
 = ==  ==
 Image File Name  RAM Address  Flash Location
 = ==  ==
-u-bootu-boot u-boot_addr_ru-boot_addr
 Linux kernel  bootfile   kernel_addr_rkernel_addr
 device tree blob  fdtfilefdt_addr_r   fdt_addr
 ramdisk   ramdiskfileramdisk_addr_r   ramdisk_addr
-- 
2.25.1

[PATCH 2/3] doc: environment: Expand on fdt_addr, initrd_addr and loadaddr

[Tom Rini]

- Explain why fdt_addr and initrd_addr should not be set to disable
  relocation normally.
- Provide some advice on the typical loadaddr default value.

Signed-off-by: Tom Rini 
---
Changes in v2:
- Fix "iamge" typo
---
 doc/usage/environment.rst | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index a3f23d4e4e22..30b08b281879 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -204,7 +204,9 @@ fdt_high
 to work it must reside in writable memory, have
 sufficient padding on the end of it for u-boot to
 add the information it needs into it, and the memory
-must be accessible by the kernel.
+must be accessible by the kernel.  This usage is strongly discouraged
+however as it also stops U-Boot from ensuring the device tree starting
+address is properly aligned and a misaligned tree will cause OS failures.
 
 fdtcontroladdr
 if set this is the address of the control flattened
@@ -240,14 +242,21 @@ initrd_high
 memory. In this case U-Boot will NOT COPY the
 ramdisk at all. This may be useful to reduce the
 boot time on your system, but requires that this
-feature is supported by your Linux kernel.
+feature is supported by your Linux kernel.  This usage however requires
+that the user ensure that there will be no overlap with other parts of the
+image such as the Linux kernel BSS.  It should not be enabled by default
+and only done as part of optimizing a deployment.
 
 ipaddr
 IP address; needed for tftpboot command
 
 loadaddr
 Default load address for commands like "bootp",
-"rarpboot", "tftpboot", "loadb" or "diskboot"
+"rarpboot", "tftpboot", "loadb" or "diskboot".  Note that the optimal
+default values here will vary between architectures.  On 32bit ARM for
+example, some offset from start of memory is used as the Linux kernel
+zImage has a self decompressor and it's best if we stay out of where that
+will be working.
 
 loads_echo
 see CONFIG_LOADS_ECHO
-- 
2.25.1

[PATCH 3/3] doc: environment: Further expand on Image locations and provide example

[Tom Rini]

Start by elaborating on what some of our constraints tend to be with
image location values, and document where these external constraints
can come from.  Provide a new subsection, an example based on the TI
ARMv7 OMAP2PLUS families of chips, that gives sample values and explains
why we use these particular values.  This is based on what is in
include/configs/ti_armv7_common.h as of fb3ad9bd923d ("TI: Add, use a
DEFAULT_LINUX_BOOT_ENV environment string") as this contains just the
values referenced in this document now and not some of the further
additions that are less generic.

Cc: Heinrich Schuchardt 
Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Largely rewrite both of the sections. Add more words to explain what
  kind of general constraints there are. Try and make it clear the TI
  example is one for ARMv7. We need examples for other architectures
  still, as follow-up patches.
---
 doc/usage/environment.rst | 53 +++
 1 file changed, 53 insertions(+)

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 30b08b281879..6f1dd1c3a879 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -404,6 +404,56 @@ device tree blob  fdtfilefdt_addr_r   fdt_addr
 ramdisk   ramdiskfileramdisk_addr_r   ramdisk_addr
 = ==  ==
 
+When setting the RAM addresses for `kernel_addr_r`, `fdt_addr_r` and
+`ramdisk_addr_r` there are several types of constraints to keep in mind. The
+one type of constraint is payload requirement. For example, a device tree MUST
+be loaded at an 8-byte aligned address as that is what the specification
+requires. In a similar manner, the operating system may define restrictions on
+where in memory space payloads can be. This is documented for example in Linux,
+with both the `Booting ARM Linux`_ and `Booting AArch64 Linux`_ documents.
+Finally, there are practical constraints. We do not know the size of a given
+payload a user will use but each payload must not overlap or it will corrupt
+the other payload. A similar problem can happen when a payload ends up being in
+the OS BSS area. For these reasons we need to ensure our default values here
+are both unlikely to lead to failure to boot and sufficiently explained so that
+they can be optimized for boot time or adjusted for smaller memory
+configurations.
+
+On different architectures we will have different constraints. It is important
+that we follow whatever documented requirements are available to best ensure
+forward compatibility. What follows are examples to highlight how to provide
+reasonable default values in different cases.
+
+Texas Instruments OMAP2PLUS (ARMv7) example
+^^^
+
+On these families of processors we are on a 32bit ARMv7 core.  As booting some
+form of Linux is our most common payload we will also keep in mind the
+documented requirements for booting that Linux provides.  These values are also
+known to be fine for booting a number of other operating systems (or their
+loaders).  In this example we define the following variables and values::
+
+loadaddr=0x8200
+kernel_addr_r=${loadaddr}
+fdt_addr_r=0x8800
+ramdisk_addr_r=0x8808
+bootm_size=0x1000
+
+The first thing to keep in mind is that DRAM starts at 0x8000. We set a
+32MiB buffer from the start of memory as our default load address and set
+``kernel_addr_r`` to that. This is because the Linux ``zImage`` decompressor
+will typically then be able to avoid doing a relocation itself. It also MUST be
+within the first 128MiB of memory. The next value is we set ``fdt_addr_r`` to
+be at 128MiB offset from the start of memory. This location is suggested by the
+kernel documentation and is exceedingly unlikely to be overwritten by the
+kernel itself given other architectural constraints.  We then allow for the
+device tree to be up to 512KiB in size before placing the ramdisk in memory. We
+then say that everything should be within the first 256MiB of memory so that
+U-Boot can relocate things as needed to ensure proper alignment. We pick 256MiB
+as our value here because we know there are very few platforms on in this
+family with less memory. It could be as high as 768MiB and still ensure that
+everything would be visible to the kernel, but again we go with what we assume
+is the safest assumption.
 
 Automatically updated variables
 ---
@@ -472,3 +522,6 @@ Implementation
 --
 
 See :doc:`../develop/environment` for internal development details.
+
+.. _`Booting ARM Linux`: 
https://www.kernel.org/doc/html/latest/arm/booting.html
+.. _`Booting AArch64 Linux`: 
https://www.kernel.org/doc/html/latest/arm64/booting.html
-- 
2.25.1

Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

[Martin Bonner]

On // comments:
a) I thought I had read recently that they are now accepted.
b) Can we stop calling them "C++ style"?  They have been legal in standard
C for all of this millennium!  There are university graduates who were born
after // comments became legal in standard C.
c) If we don't currently accept them, can we change the style now (see
previous point)?

A response along the lines of "this is just moving the wiki into .rst files
- we can actually change things separately" would seem entirely reasonable.
Martin


On Mon, 11 Jul 2022 at 19:15, Tom Rini  wrote:

> Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
> The changes here are for formatting or slight rewording so that it reads
> well when linking to other Sphinx documents.
>
> Cc: Heinrich Schuchardt 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - Assorted wiki -> Sphinx style corrections and a few typo fixes, per
>   Heinrich
> ---
>  doc/develop/codingstyle.rst | 255 
>  doc/develop/index.rst   |   8 ++
>  2 files changed, 263 insertions(+)
>  create mode 100644 doc/develop/codingstyle.rst
>
> diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> new file mode 100644
> index ..bbeca42e656b
> --- /dev/null
> +++ b/doc/develop/codingstyle.rst
> @@ -0,0 +1,255 @@
> +.. SPDX-License-Identifier: GPL-2.0+:
> +
> +U-Boot Coding Style
> +===
> +
> +The following Coding Style requirements shall be mandatory for all code
> contributed to
> +the U-Boot project.
> +
> +Exceptions are only allowed if code from other projects is integrated
> with no
> +or only minimal changes.
> +
> +The following rules apply:
> +
> +* All contributions to U-Boot should conform to the `Linux kernel
> +  coding style <
> https://www.kernel.org/doc/html/latest/process/coding-style.html>`_
> +  and the `Lindent script <
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Lindent
> >`_.
> +  * The exception for net files to the `multi-line comment
> +  <
> https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting
> >`_
> +  applies only to Linux, not to U-Boot. Only large hunks which are copied
> +  unchanged from Linux may retain that comment format.
> +
> +* Use patman to send your patches (``tools/patman/patman -H`` for full
> +  instructions). With a few tags in your commits this will check your
> patches
> +  and take care of emailing them.
> +
> +* If you don't use patman, make sure to run ``scripts/checkpatch.pl``.
> For
> +  more information, read :doc:`checkpatch`. Note that this should be done
> +  *before* posting on the mailing list!
> +
> +* Source files originating from different projects (for example the MTD
> +  subsystem or the hush shell code from the BusyBox project) may, after
> +  careful consideration, be exempted from these rules. For such files, the
> +  original coding style may be kept to ease subsequent migration to newer
> +  versions of those sources.
> +
> +* Please note that U-Boot is implemented in C (and to some small parts in
> +  Assembler); no C++ is used, so please do not use C++ style comments
> (//) in
> +  your code.
> +
> +  * The sole exception here is for SPDX tags in some files (checkpatch.pl
> will warn you).
> +
> +* Please also stick to the following formatting rules:
> +
> +  * Remove any trailing white space
> +
> +  * Use TAB characters for indentation and vertical alignment, not spaces
> +
> +  * Make sure NOT to use DOS ``\r\n`` line feeds
> +
> +  * Do not add more than 2 consecutive empty lines to source files
> +
> +  * Do not add trailing empty lines to source files
> +
> +  * Using the option ``git config --global color.diff auto`` will help to
> +visually see whitespace problems in ``diff`` output from ``git``.
> +
> +  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
> +feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The
> Right
> +Thing (tm)
> +
> +Submissions of new code or patches that do not conform to these
> requirements
> +shall be rejected with a request to reformat the changes.
> +
> +U-Boot Code Documentation
> +-
> +
> +U-Boot adopted the kernel-doc annotation style, this is the only
> exception from
> +multi-line comment rule of Coding Style. While not mandatory, adding
> +documentation is strongly advised. The Linux kernel `kernel-doc
> +`_
> +documentation applies with no changes.
> +
> +Use structures for I/O access
> +-
> +
> +U-Boot typically uses a C structure to map out the registers in an I/O
> region,
> +rather than offsets. The reasons for this are:
> +
> +* It dissociates the register location (offset) from the register type,
> which
> +  means the developer has to make sure the type is right for each access,
> +  whereas with the struct method, this is checked by the co

Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

[Tom Rini]

On Mon, Jul 11, 2022 at 09:02:47PM +0200, Martin Bonner wrote:

> On // comments:
> a) I thought I had read recently that they are now accepted.
> b) Can we stop calling them "C++ style"?  They have been legal in standard
> C for all of this millennium!  There are university graduates who were born
> after // comments became legal in standard C.
> c) If we don't currently accept them, can we change the style now (see
> previous point)?
> 
> A response along the lines of "this is just moving the wiki into .rst files
> - we can actually change things separately" would seem entirely reasonable.
> Martin

Yeah, I didn't cc you on
https://patchwork.ozlabs.org/project/uboot/patch/20220711171439.1657280-3-tr...@konsulko.com/,
sorry

-- 
Tom


signature.asc
Description: PGP signature

RE: [PATCH v4 3/7] configs: Add config for enabling FSPI boot option for i.MX8m

[ZHIZHIKIN Andrey]

Hello Mamta,

> -Original Message-
> From: Mamta Shukla 
> Sent: Thursday, July 7, 2022 2:45 PM
> To: u-boot@lists.denx.de
> Cc: sba...@denx.de; peng@nxp.com; aford...@gmail.com; GEO-CHHER-bsp-
> development ; feste...@denx.de; 
> SHUKLA
> Mamta Ramendra ; HAEMMERLE Thomas
> 
> Subject: [PATCH v4 3/7] configs: Add config for enabling FSPI boot option for
> i.MX8m
> 
> Add imx8mm_evk_fspi_defconfig to build QSPI boot image.
> This config is based on imx8mm_evk_defconfig with addtional config options for
> FSPI Header,SPL offset and imx-image config to boot from FSPI.
> 
> Signed-off-by: Mamta Shukla 
> Signed-off-by: Thomas Haemmerle 
> Tested-by: Adam Ford 
> Reviewed-by: Fabio Estevam 
> ---
> v2:
> -Remove extra line in commit message
> -Remove extra line in imx8mm_evk_fspi_defconfig
> -New patch in series to add an entry for imx8mm_evk_fspi_defconfig in
> board/freescale/imx8mm_evk/MAINTAINERS
> 
> v3:
> -No changes
> 
> v4:
> -No changes
> 
>  .../imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg   |   9 ++
>  configs/imx8mm_evk_fspi_defconfig | 115 ++
>  2 files changed, 124 insertions(+)
>  create mode 100644 board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
>  create mode 100644 configs/imx8mm_evk_fspi_defconfig
> 
> diff --git a/board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
> b/board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
> new file mode 100644
> index 00..ddcbd11eea
> --- /dev/null
> +++ b/board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#define __ASSEMBLY__

Usage of __ASSEMBLY__ has been dropped in commit 5c86a8f7a191 ("imx: Don't 
define __ASSEMBLY__ in source files"), therefore build produces the warning. 
Please remove this one.

> +
> +BOOT_FROMfspi
> +LOADER   u-boot-spl-ddr.bin  0x7E2000
> diff --git a/configs/imx8mm_evk_fspi_defconfig
> b/configs/imx8mm_evk_fspi_defconfig
> new file mode 100644
> index 00..50f6e4779b
> --- /dev/null
> +++ b/configs/imx8mm_evk_fspi_defconfig

New config file needs a re-sync to what is included on the master, specifically 
those 2 commits from Tom:
d46e86d25c2a ("configs: Resync with savedefconfig")
bfdb30559c76 ("configs: Resync with savedefconfig")

> @@ -0,0 +1,115 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_IMX8M=y
> +CONFIG_SYS_TEXT_BASE=0x4020
> +CONFIG_SYS_MALLOC_LEN=0x200
> +CONFIG_SPL_GPIO=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_ENV_SIZE=0x1000
> +CONFIG_ENV_OFFSET=0x40
> +CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="imx8mm-evk"
> +CONFIG_SPL_TEXT_BASE=0x7E2000
> +CONFIG_TARGET_IMX8MM_EVK=y
> +CONFIG_IMX_CONFIG="board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg"
> +CONFIG_SPL_NOR_SUPPORT=y
> +CONFIG_SPL_SERIAL_SUPPORT=y
> +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
> +CONFIG_SPL_MMC=y
> +CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_DRIVERS_MISC=y
> +CONFIG_SPL=y
> +CONFIG_SYS_LOAD_ADDR=0x4048
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_FIT=y
> +CONFIG_FIT_EXTERNAL_OFFSET=0x3000
> +CONFIG_SPL_LOAD_FIT=y
> +# CONFIG_USE_SPL_FIT_GENERATOR is not set
> +CONFIG_OF_SYSTEM_SETUP=y
> +CONFIG_BOARD_EARLY_INIT=y
> +CONFIG_BOARD_LATE_INIT=y
> +CONFIG_SPL_BOARD_INIT=y
> +CONFIG_SPL_SEPARATE_BSS=y
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x300
> +CONFIG_SPL_I2C=y
> +CONFIG_SPL_POWER=y
> +CONFIG_SPL_WATCHDOG=y
> +CONFIG_SYS_PROMPT="u-boot=> "
> +# CONFIG_CMD_EXPORTENV is not set
> +# CONFIG_CMD_IMPORTENV is not set
> +# CONFIG_CMD_CRC32 is not set
> +CONFIG_CMD_CLK=y
> +CONFIG_CMD_FUSE=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_CACHE=y
> +CONFIG_CMD_REGULATOR=y
> +CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_OF_CONTROL=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_ENV_OVERWRITE=y
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_DEV=1
> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> +CONFIG_USE_ETHPRIME=y
> +CONFIG_ETHPRIME="FEC"
> +CONFIG_SPL_DM=y
> +CONFIG_SPL_CLK_COMPOSITE_CCF=y
> +CONFIG_CLK_COMPOSITE_CCF=y
> +CONFIG_SPL_CLK_IMX8MM=y
> +CONFIG_CLK_IMX8MM=y
> +CONFIG_MXC_GPIO=y
> +CONFIG_DM_I2C=y
> +CONFIG_DM_MMC=y
> +CONFIG_SUPPORT_EMMC_BOOT=y
> +CONFIG_MMC_IO_VOLTAGE=y
> +CONFIG_MMC_UHS_SUPPORT=y
> +CONFIG_MMC_HS400_ES_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
> +CONFIG_FSL_USDHC=y
> +CONFIG_PHYLIB=y
> +CONFIG_PHY_ATHEROS=y
> +CONFIG_DM_ETH=y
> +CONFIG_PHY_GIGE=y
> +CONFIG_FEC_MXC=y
> +CONFIG_MII=y
> +CONFIG_PINCTRL=y
> +CONFIG_SPL_PINCTRL=y
> +CONFIG_PINCTRL_IMX8M=y
> +CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC_PCA9450=y
> +CONFIG_DM_REGULATOR=y
> +CONFIG_DM_REGULATOR_FIXED=y
> +CONFIG_DM_REGULATOR_GPIO=y
> +CONFIG_DM_PWM=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_PWM_IMX=y
> +CONFIG_MXC_UART=y
> +CONFIG_SYSRESET=y
> +CONFIG_SPL_SYSRESET=y
> +CONFIG_SYSRESET_PSCI=y
> +CONFIG_SYSRESET_WATCHDOG=y
> +CONFIG_DM_THERMAL=y
> +CONFIG_IMX_WATCHDOG=y
> +CO

RE: [PATCH v4 1/7] tools: mkimage: Add support to generate FlexSPI Header for i.MX8m

[ZHIZHIKIN Andrey]

Hello Mamta,

> -Original Message-
> From: Mamta Shukla 
> Sent: Thursday, July 7, 2022 2:45 PM
> To: u-boot@lists.denx.de
> Cc: sba...@denx.de; peng@nxp.com; aford...@gmail.com; GEO-CHHER-bsp-
> development ; feste...@denx.de; 
> SHUKLA
> Mamta Ramendra ; HAEMMERLE Thomas
> 
> Subject: [PATCH v4 1/7] tools: mkimage: Add support to generate FlexSPI Header
> for i.MX8m
> 
> Add struct with Flex SPI Configuration Block and enable generating
> fspi header using mkimage.
> 
> Refer i.MX 8M Mini Application Processor Reference Manual for
> detailed information about parameters for FlexSPI Configuration block.
> 
> Signed-off-by: Mamta Shukla 
> Signed-off-by: Thomas Haemmerle 
> Tested-by: Adam Ford 
> Reviewed-by: Fabio Estevam 
> ---
> v2:
> -Add check for error in case open() for fspi_fd in imx8mkimage.c fails
> 
> v3:
> -No changes
> 
> v4:
> -No changes
> 
>  include/imximage.h | 38 ++
>  tools/Kconfig  | 59 +
>  tools/imx8mimage.c | 81 +++---
>  3 files changed, 174 insertions(+), 4 deletions(-)
> 
> diff --git a/include/imximage.h b/include/imximage.h
> index 5a812f5a10..c1ecc0b7cb 100644
> --- a/include/imximage.h
> +++ b/include/imximage.h
> @@ -201,6 +201,44 @@ struct imx_header {
>   } header;
>  };
> 
> +typedef struct {
> + uint8_t tag[4];
> + uint8_t version[4];
> + uint8_t reserved_1[4];
> + uint8_t read_sample;
> + uint8_t datahold;
> + uint8_t datasetup;
> + uint8_t coladdrwidth;
> + uint8_t devcfgenable;
> + uint8_t reserved_2[3];
> + uint8_t devmodeseq[4];
> + uint8_t devmodearg[4];
> + uint8_t cmd_enable;
> + uint8_t reserved_3[3];
> + uint8_t cmd_seq[16] ;
> + uint8_t cmd_arg[16];
> + uint8_t controllermisc[4];
> + uint8_t dev_type;
> + uint8_t sflash_pad;
> + uint8_t serial_clk;
> + uint8_t lut_custom ;
> + uint8_t reserved_4[8];
> + uint8_t sflashA1[4];
> + uint8_t sflashA2[4];
> + uint8_t sflashB1[4];
> + uint8_t sflashB2[4];
> + uint8_t cspadover[4];
> + uint8_t sclkpadover[4];
> + uint8_t datapadover[4];
> + uint8_t dqspadover[4];
> + uint8_t timeout[4];
> + uint8_t commandInt[4];
> + uint8_t datavalid[4];
> + uint8_t busyoffset[2];
> + uint8_t busybitpolarity[2];
> + uint8_t lut[256];
> +} __attribute__((packed)) fspi_conf;
> +
>  typedef void (*set_dcd_val_t)(struct imx_header *imxhdr,
>   char *name, int lineno,
>   int fld, uint32_t value,
> diff --git a/tools/Kconfig b/tools/Kconfig
> index 117c921da3..539708f277 100644
> --- a/tools/Kconfig
> +++ b/tools/Kconfig
> @@ -98,4 +98,63 @@ config TOOLS_MKEFICAPSULE
> optionally sign that file. If you want to enable UEFI capsule
> update feature on your target, you certainly need this.
> 
> +menuconfig FSPI_CONF_HEADER
> + bool "FlexSPI Header Configuration"
> + help
> +   FSPI Header Configuration
> +
> +config FSPI_CONF_FILE
> + string "FlexSPI Header File"
> + depends on FSPI_CONF_HEADER
> + help
> +   FlexSPI Header File name
> +
> +config READ_CLK_SOURCE
> + hex "Sampling Clock Source"
> + default 0x00
> + depends on FSPI_CONF_HEADER
> + help
> +   Sample Clock source for Flash, default is internal loopback clock
> +
> +config DEVICE_TYPE
> + hex "Flash Type"
> + default 0x01
> + depends on FSPI_CONF_HEADER
> + help
> +   Flash type: Serial NOR (0X01) and Serial NAND (0x02)
> +
> +config FLASH_PAD_TYPE
> + hex "Flash Pad Type"
> + default 0x01
> + depends on FSPI_CONF_HEADER
> + help
> +   Flash Pad type :
> +   Single Pad 0x01
> +   Dual Pads  0x02
> +   Quad Pad   0x04
> +   Octal Pad  0x08
> +
> +config SERIAL_CLK_FREQUENCY
> + hex "Serial Clock Frequency"
> + default 0x02
> + depends on FSPI_CONF_HEADER
> + help
> +   Chip specific frequency: other value 30MHz
> +   1-30MHz  2-50MHz 3-60MHz 4-75MHz 5-80MHz 6-100MHz 7-133MHz 8-166MHz
> +
> +config LUT_CUSTOM_SEQUENCE
> + hex "Enable Custom Look Up Table(LUT) Sequence"
> + default 0x00
> + depends on FSPI_CONF_HEADER
> + help
> +   0 - Use predefined LUT Sequence
> +   1 - Use LUT Sequence provided
> +
> +config LUT_SEQUENCE
> + string "Look Up Table Sequence"
> + default "0x0b, 0x04, 0x18, 0x08, 0x08, 0x30, 0x04, 0x24"
> + depends on FSPI_CONF_HEADER
> + help
> +   Look Up Table Sequence
> +
>  endmenu
> diff --git a/tools/imx8mimage.c b/tools/imx8mimage.c
> index 4eed683396..facf8887a1 100644
> --- a/tools/imx8mimage.c
> +++ b/tools/imx8mimage.c
> @@ -12,7 +12,7 @@
>  #include "compiler.h"
> 
>  static uint32_t ap_start_addr, sld_start_addr, sld_src_off;
> -static char *ap_img, *sld_img, *signed_hdmi;
> +static char *ap_img, *sld_img, *signed_hdmi, *fspi;
>  static imx_header_

Re: [PATCH v1] arm: relocate: Replace ADR instruction with non-pseudo-instruction

[Jesse Taube]

On 7/11/22 10:19, Andre Przywara wrote:
> On Mon, 11 Jul 2022 15:11:13 +0100
> Andre Przywara  wrote:
> 
>> On Mon, 11 Jul 2022 13:57:40 +0100
>> Andre Przywara  wrote:
>>
>> Hi,
>>
>>> On Sun, 10 Jul 2022 03:09:53 -0400
>>> Jesse Taube  wrote:
>>>
>>> Hi Jesse,
>>>   
 In Binutils 2.37 the ADR instruction has changed
 use alternate instructions.  
>>>
>>> Can you elaborate on this? What has changed exactly, and why? Looking at
>>> the commit you mention below I don't see an immediate problem that would
>>> require code changes? Also it speaks of forward references, but this one
>>> is not one?
>>> And I didn't spot any difference between 2.38 and 2.35, at least not in my
>>> isolated test (but I didn't bother to compile a whole stage 1 GCC with
>>> newer binutils yet).  
>>
>> OK, so digging a bit deeper I think I have an idea:
>> With as 2.35 I get:
>> 080007cc :
>>  80007cc:   f2af 0304   subwr3, pc, #4
>>
>> whereas with 2.38 it's:
>> 080007cc :
>>  80007cc:   f2af 0303   subwr3, pc, #3
>>
>> the latter looks correct since we compile relocate.S with -mthumb
>> -mthumb-interwork, so the lowest bit of the *function* address should be
>> set, to indicate this is a Thumb function. And "ENTRY(relocate_code)"
>> clearly tells the assembler that relocate_code is a function entry point,
>> so should carry the instruction set flag in bit 0.
>> However we don't use the result of "adr" as an argument for a bx call
>> later, but to calculate some relocation offset, so the bit is getting in
>> the way.
>> Without thinking too much about this, wouldn't it help to just always
>> clear bit 0 in r3?
>> Or probably better: to have an additional label, which is not marked as a
>> function entry point?
> 
> Does that fix it?
> 
> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> index 14b7f61c1a..5102bfabde 100644
> --- a/arch/arm/lib/relocate.S
> +++ b/arch/arm/lib/relocate.S
> @@ -78,7 +78,8 @@ ENDPROC(relocate_vectors)
>   */
>  
>  ENTRY(relocate_code)
> - adr r3, relocate_code
> +relocate_base:
> + adr r3, relocate_base
>   ldr r1, _image_copy_start_ofs
>   add r1, r3  /* r1 <- Run &__image_copy_start */
>   subsr4, r0, r1  /* r4 <- Run to copy offset  */
> 
> Seems to generate the same code with both gas 2.35 and gas 2.38.

Works thanks. Do you want to submit it or. 
Sorry about me not knowing Assembly for arm very well...

Thanks,
Jesse
> Cheers,
> Andre
> 
>>
>> Cheers,
>> Andre
>>
 The change causes armv7-m to not boot.  
>>>
>>> What does "causes armv7-m to not boot" mean? It compiles fine, but hangs
>>> or crashes?
>>> Can you show the relevant disassembly from both binutils versions?
>>>
>>> And from trying to reproduce this minimally, do we need a ".syntax unified"
>>> in the .S file? 
>>>   
 Signed-off-by: Jesse Taube 
 ---
  arch/arm/lib/relocate.S | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
 index 14b7f61c1a..22c419534f 100644
 --- a/arch/arm/lib/relocate.S
 +++ b/arch/arm/lib/relocate.S
 @@ -78,7 +78,13 @@ ENDPROC(relocate_vectors)
   */
  
  ENTRY(relocate_code)
 -  adr r3, relocate_code
 +/*
 + * Binutils doesn't comply with the arm docs for adr in thumb2
 + * from commit d3e52e120b68bf19552743fbc078e0a759f48cb7 onward
 + * to remove ambiguity explicitly define the pseudo-instruction
 + */
 +  mov r3, pc
 +  subs r3, #4  
>>>
>>> But this will break ARM, won't it? Because it would require to subtract #8?
>>> I mean there is a reason for this adr instruction, because this offset
>>> calculation is best left to the assembler. Not to speak of the fragility
>>> of assuming that the relocate_code label is pointing to the very first
>>> instruction. The ENTRY macro could also insert instructions.
>>>
>>> Cheers,
>>> Andre
>>>   
ldr r1, _image_copy_start_ofs
add r1, r3  /* r1 <- Run &__image_copy_start */
subsr4, r0, r1  /* r4 <- Run to copy offset  */  
>>>   
>>
> 

imx8m read boot ROM log issue

[Belisko Marek]

Hi,

I'm trying to add support for reading imx8mq boot ROM event log and
got inspired by this patch:
https://lists.denx.de/pipermail/u-boot/2021-July/453318.html

My question is if the condition for checking log pointers is correct:

 /* If the ROM event log pointer is not valid. */
if (*rom_log_addr < 0x90 || *rom_log_addr >= 0xb0 ||
*rom_log_addr & 0x3)
return part;

rom_load_addr is set at the beginning of function to 0x9E0 which is
offset in OCRAM.
Then the value from this address is checked by the above condition and
in my experiments function always returns in this particular line (I'm
getting a value e.g. 0x710004bf at address 0x9e0) dueto the fact that
this condition is never met.

So my question is if I'm doing something wrong or I simply don't
understand the code :)

Thanks and regards,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: [PATCH 2/2] Nokia RX-51: Remove CONFIG_PREBOOT from defconfig

[Tom Rini]

On Sun, Jul 10, 2022 at 01:42:56PM +0200, Pali Rohár wrote:

> CONFIG_PREBOOT just cause putting "preboot=CONFIG_PREBOOT" into env list.
> Value CONFIG_PREBOOT="run preboot" in defconfig is just nonsense and does
> not do anything useful (it is infinite recursion). Config file for this
> board already contains default preboot= env variable with correct value,
> which has higher priority than CONFIG_PREBOOT and this is reason why
> nonsense CONFIG_PREBOOT is ignored.
> 
> Remove nonsense and unused CONFIG_PREBOOT from nokia_rx51_defconfig file.
> 
> Signed-off-by: Pali Rohár 
> ---
>  configs/nokia_rx51_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> index 309cf28269c1..46b794f168d9 100644
> --- a/configs/nokia_rx51_defconfig
> +++ b/configs/nokia_rx51_defconfig
> @@ -24,7 +24,6 @@ CONFIG_AUTOBOOT_MENU_SHOW=y
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="run sdboot;run emmcboot;run attachboot;echo"
>  CONFIG_USE_PREBOOT=y
> -CONFIG_PREBOOT="run preboot"
>  # CONFIG_SYS_DEVICE_NULLDEV is not set
>  CONFIG_HUSH_PARSER=y
>  CONFIG_SYS_PROMPT="Nokia RX-51 # "

These changes are actually a bit puzzling.  There are other platforms
that set preboot in their default environment, rather than via
CONFIG_PREBOOT, and their final value ends up being the one set in
CONFIG_EXTRA_ENV_SETTINGS rather than the empty string that
CONFIG_PREBOOT is.  I assume you've confirmed that at run-time you end
up with preboot="run preboot" being set, and not preboot="long command"
?  The difference between nokia_rx51 and the other platforms is, I
think, LTO being enabled and maybe that leads to a different final value
in the resulting environment.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH V4 resend] spl: imx8mm: enlarge SPL_MAX_SIZE

[Fabio Estevam]

Hi Peng,

On Mon, Jul 11, 2022 at 3:35 AM Peng Fan (OSS)  wrote:
>
> From: Peng Fan 
>
> The CONFIG_SPL_MAX_SIZE could be 0x27000 for i.MX8MM when SPL_TEXT_BASE
> set to 0x7E1000.
>
> The DDR firmware max uses 96KB, there is a 4KB padding header before
> SPL_TEXT_BASE, so the SPL MAX SIZE is `256KB - 96KB - 4KB`.
>
> Signed-off-by: Peng Fan 

Reviewed-by: Fabio Estevam 

Re: [PATCH v2 0/9] New boards support: db845c and qcs404-evb

[Peng Fan]

On 7/8/2022 9:13 PM, Sumit Garg wrote:

Add support for two new boards db845c and qcs404-evb:
- db845c is a 96boards compliant platform aka RB3 based on Qualcomm
   SDM845 SoC.
- qcs404-evb is an evaluation board from Qualcomm based on QCS404 SoC.

Both these platforms have one thing in common that u-boot is chain-loaded
in 64-bit mode via Android Boot Loader (ABL) which is an EFI application.
For further details on chain-loading refer to platform specific


Just curious about the flow:
ABL(an EFI applicaiton)->load U-Boot->start U-Boot? or you mean U-Boot 
run as EFI application?


THanks,
Peng.


documentation:
- doc/board/qualcomm/sdm845.rst
- doc/board/qualcomm/qcs404.rst

Changes in v2:
- Added patch #1 to fix DT node overrides in starqltechn-uboot.dtsi.
- Updated patch #2 commit description.
- Fixed a typo (s/96Board/96Boards/) in patch #5.

Sumit Garg (9):
   board: starqltechn: Align DT node overrides with sdm845.dtsi
   arm64: dts: sdm845: Remove redundant u-boot DT properties
   clocks: sdm845: Import qcom,gcc-sdm845.h
   uart: sdm845: Fix debug UART pinmux
   board: qualcomm: Add support for dragonboard845c
   mmc: msm_sdhci: Add SDCC version 5.0.0 support
   pinctrl: qcom: Add pinctrl driver for QCS404 SoC
   clocks: qcom: Add clock driver for QCS404 SoC
   board: qualcomm: Add support for QCS404 EVB

  arch/arm/dts/Makefile |   1 +
  arch/arm/dts/dragonboard845c-uboot.dtsi   |  37 +++
  arch/arm/dts/dragonboard845c.dts  |  44 
  arch/arm/dts/qcs404-evb-uboot.dtsi|  24 ++
  arch/arm/dts/qcs404-evb.dts   |  81 ++
  arch/arm/dts/sdm845.dtsi  |   8 +-
  arch/arm/dts/starqltechn-uboot.dtsi   |  18 +-
  arch/arm/dts/starqltechn.dts  |   2 +-
  arch/arm/mach-snapdragon/Kconfig  |  25 ++
  arch/arm/mach-snapdragon/Makefile |   3 +
  arch/arm/mach-snapdragon/clock-qcs404.c   |  30 +++
  arch/arm/mach-snapdragon/clock-sdm845.c   |   3 +-
  arch/arm/mach-snapdragon/clock-snapdragon.c   |   1 +
  .../include/mach/sysmap-qcs404.h  |  13 +
  arch/arm/mach-snapdragon/pinctrl-qcs404.c |  55 
  arch/arm/mach-snapdragon/pinctrl-snapdragon.c |   1 +
  arch/arm/mach-snapdragon/pinctrl-snapdragon.h |   1 +
  arch/arm/mach-snapdragon/sysmap-qcs404.c  |  31 +++
  board/qualcomm/dragonboard845c/Kconfig|  12 +
  board/qualcomm/dragonboard845c/MAINTAINERS|   6 +
  board/qualcomm/dragonboard845c/Makefile   |   9 +
  board/qualcomm/dragonboard845c/db845c.its |  63 +
  .../dragonboard845c/dragonboard845c.c |   9 +
  board/qualcomm/qcs404-evb/Kconfig |  15 ++
  board/qualcomm/qcs404-evb/MAINTAINERS |   6 +
  board/qualcomm/qcs404-evb/Makefile|   6 +
  board/qualcomm/qcs404-evb/qcs404-evb.c|  33 +++
  board/qualcomm/qcs404-evb/qcs404-evb.its  |  64 +
  configs/dragonboard845c_defconfig |  28 ++
  configs/qcs404evb_defconfig   |  39 +++
  doc/board/qualcomm/index.rst  |   1 +
  doc/board/qualcomm/qcs404.rst |  79 ++
  doc/board/qualcomm/sdm845.rst | 100 ++-
  drivers/mmc/msm_sdhci.c   |  96 ---
  include/configs/dragonboard845c.h |  28 ++
  include/configs/qcs404-evb.h  |  27 ++
  include/dt-bindings/clock/qcom,gcc-qcs404.h   | 180 +
  include/dt-bindings/clock/qcom,gcc-sdm845.h   | 246 ++
  38 files changed, 1363 insertions(+), 62 deletions(-)
  create mode 100644 arch/arm/dts/dragonboard845c-uboot.dtsi
  create mode 100644 arch/arm/dts/dragonboard845c.dts
  create mode 100644 arch/arm/dts/qcs404-evb-uboot.dtsi
  create mode 100644 arch/arm/dts/qcs404-evb.dts
  create mode 100644 arch/arm/mach-snapdragon/clock-qcs404.c
  create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-qcs404.h
  create mode 100644 arch/arm/mach-snapdragon/pinctrl-qcs404.c
  create mode 100644 arch/arm/mach-snapdragon/sysmap-qcs404.c
  create mode 100644 board/qualcomm/dragonboard845c/Kconfig
  create mode 100644 board/qualcomm/dragonboard845c/MAINTAINERS
  create mode 100644 board/qualcomm/dragonboard845c/Makefile
  create mode 100644 board/qualcomm/dragonboard845c/db845c.its
  create mode 100644 board/qualcomm/dragonboard845c/dragonboard845c.c
  create mode 100644 board/qualcomm/qcs404-evb/Kconfig
  create mode 100644 board/qualcomm/qcs404-evb/MAINTAINERS
  create mode 100644 board/qualcomm/qcs404-evb/Makefile
  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.c
  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.its
  create mode 100644 configs/dragonboard845c_defconfig
  create mode 100644 configs/qcs404evb_defconfig
  create mode 100644 doc/board/qualcomm/qcs404.rst
  create mode 100644 include/configs/dragonboard845c.h
  create mode 100644 include/configs/qcs404-evb.h
  create mode 100644 include/dt-bindings

[PATCH 00/19] buildman: Integration of boards.cfg file

[Simon Glass]

This series drops the need for the genboardscfg.py script, so that the
boards.cfg file is produced (and consumed) entirely within buildman. The
file is not entirely removed since it does have some uses and we need some
sort of cache for the information. The genboardscfg.py script is
effectively incorporated in buildman.

It also improves operation from an IDE with a new -I option and fixes up
some of the pylint warnings in buildman.

Finally, this series also fixes a bug which allows use to drop support for
CONFIG_SYS_EXTRA_OPTIONS which is long-standing desire. It also fixes a
minor bug that causes 'Invalid line' spam when checking for function bloat
with the -B option.


Simon Glass (19):
  buildman: Drop -I option
  buildman: Support running from an IDE
  buildman: Avoid using board as a variable
  buildman: Fix use of 'boards' in func_test
  buildman: Fix use of 'boards' in test
  buildman: Drop use of 'boards' in control
  buildman: Drop use of 'board' in board module
  buildman: Convert camel case in board.py
  buildman: Split out Boards into its own file
  buildman: Incorporate the genboardscfg.py tool
  buildman: Tidy up pylint problems in boards module
  buildman: Replace the Options column with config name
  Revert "Revert "global: Remove CONFIG_SYS_EXTRA_OPTIONS support""
  buildman: Return an error if there are maintainer warnings
  gitlab/azure: Use buildman instead of genboardscfg
  Drop genboardscfg.py
  buildman: Allow lines without a symbol
  buildman: Drop a Python 2.7 comment
  buildman: Drop a TODO that is done

 .azure-pipelines.yml|   2 +-
 .gitlab-ci.yml  |   2 +-
 boot/Kconfig|  13 -
 doc/README.kconfig  |   7 -
 doc/develop/moveconfig.rst  |   3 +-
 scripts/Makefile.autoconf   |   4 -
 scripts/build-whitelist.sh  |  23 +-
 scripts/pylint.base |   1 -
 tools/buildman/README   |  40 +-
 tools/buildman/board.py | 289 +---
 tools/buildman/boards.py| 752 
 tools/buildman/builder.py   | 140 +++---
 tools/buildman/builderthread.py |   6 +-
 tools/buildman/cmdline.py   |   7 +-
 tools/buildman/control.py   |  56 ++-
 tools/buildman/func_test.py |  59 +--
 tools/buildman/test.py  |  45 +-
 tools/buildman/toolchain.py |   8 +-
 tools/genboardscfg.py   | 444 ---
 tools/moveconfig.py |  65 ---
 20 files changed, 960 insertions(+), 1006 deletions(-)
 create mode 100644 tools/buildman/boards.py
 delete mode 100755 tools/genboardscfg.py

-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 03/19] buildman: Avoid using board as a variable

[Simon Glass]

We have a module called 'board'. Sometimes buildman uses 'brd' as an
instance variable but sometimes it uses 'board', which is confusing and
can mess with the module handling. Update the code to use 'brd'
consistently, making it easier for tools to determine when the module
is being referenced.

Signed-off-by: Simon Glass 
---

 tools/buildman/board.py | 40 ++---
 tools/buildman/builder.py   | 45 -
 tools/buildman/builderthread.py |  6 ++---
 tools/buildman/func_test.py |  8 +++---
 tools/buildman/test.py  |  4 +--
 tools/buildman/toolchain.py |  8 +++---
 6 files changed, 55 insertions(+), 56 deletions(-)

diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index 447aaabea86..08771b3f158 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -103,15 +103,15 @@ class Boards:
 # Use a simple list here, sinc OrderedDict requires Python 2.7
 self._boards = []
 
-def AddBoard(self, board):
+def AddBoard(self, brd):
 """Add a new board to the list.
 
 The board's target member must not already exist in the board list.
 
 Args:
-board: board to add
+brd: board to add
 """
-self._boards.append(board)
+self._boards.append(brd)
 
 def ReadBoards(self, fname):
 """Read a list of boards from a board file.
@@ -136,8 +136,8 @@ class Boards:
 if len(fields) > 8:
 fields = fields[:8]
 
-board = Board(*fields)
-self.AddBoard(board)
+brd = Board(*fields)
+self.AddBoard(brd)
 
 
 def GetList(self):
@@ -157,8 +157,8 @@ class Boards:
 value is board
 """
 board_dict = OrderedDict()
-for board in self._boards:
-board_dict[board.target] = board
+for brd in self._boards:
+board_dict[brd.target] = brd
 return board_dict
 
 def GetSelectedDict(self):
@@ -168,9 +168,9 @@ class Boards:
 List of Board objects that are marked selected
 """
 board_dict = OrderedDict()
-for board in self._boards:
-if board.build_it:
-board_dict[board.target] = board
+for brd in self._boards:
+if brd.build_it:
+board_dict[brd.target] = brd
 return board_dict
 
 def GetSelected(self):
@@ -179,7 +179,7 @@ class Boards:
 Returns:
 List of Board objects that are marked selected
 """
-return [board for board in self._boards if board.build_it]
+return [brd for brd in self._boards if brd.build_it]
 
 def GetSelectedNames(self):
 """Return a list of selected boards
@@ -187,7 +187,7 @@ class Boards:
 Returns:
 List of board names that are marked selected
 """
-return [board.target for board in self._boards if board.build_it]
+return [brd.target for brd in self._boards if brd.build_it]
 
 def _BuildTerms(self, args):
 """Convert command line arguments to a list of terms.
@@ -273,34 +273,34 @@ class Boards:
 exclude_list.append(Expr(expr))
 
 found = []
-for board in self._boards:
+for brd in self._boards:
 matching_term = None
 build_it = False
 if terms:
 match = False
 for term in terms:
-if term.Matches(board.props):
+if term.Matches(brd.props):
 matching_term = str(term)
 build_it = True
 break
 elif boards:
-if board.target in boards:
+if brd.target in boards:
 build_it = True
-found.append(board.target)
+found.append(brd.target)
 else:
 build_it = True
 
 # Check that it is not specifically excluded
 for expr in exclude_list:
-if expr.Matches(board.props):
+if expr.Matches(brd.props):
 build_it = False
 break
 
 if build_it:
-board.build_it = True
+brd.build_it = True
 if matching_term:
-result[matching_term].append(board.target)
-result['all'].append(board.target)
+result[matching_term].append(brd.target)
+result['all'].append(brd.target)
 
 if boards:
 remaining = set(boards) - set(found)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 078ddf070d3..462266b4b84 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -875,11 +875,11 @@ class Builder:
 config = {}
 environment = {}
 
-for bo

[PATCH 01/19] buildman: Drop -I option

[Simon Glass]

This has been deprecated with a notice that it will be removed after April
2021. Drop it now.

Signed-off-by: Simon Glass 
---

 tools/buildman/cmdline.py | 3 ---
 tools/buildman/control.py | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index 8586bdf3b58..ddcb1ec5fcd 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -59,9 +59,6 @@ def ParseArgs():
 parser.add_option('-i', '--in-tree', dest='in_tree',
   action='store_true', default=False,
   help='Build in the source tree instead of a separate directory')
-# -I will be removed after April 2021
-parser.add_option('-I', '--incremental', action='store_true',
-  default=False, help='Deprecated, does nothing. See -m')
 parser.add_option('-j', '--jobs', dest='jobs', type='int',
   default=None, help='Number of jobs to run at once (passed to make)')
 parser.add_option('-k', '--keep-outputs', action='store_true',
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 8f4810bc3ef..beade62408b 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -176,9 +176,6 @@ def DoBuildman(options, args, toolchains=None, 
make_func=None, boards=None,
 print()
 return 0
 
-if options.incremental:
-print(col.build(col.RED,
-'Warning: -I has been removed. See documentation'))
 if not options.output_dir:
 if options.work_in_output:
 sys.exit(col.build(col.RED, '-w requires that you specify -o'))
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 02/19] buildman: Support running from an IDE

[Simon Glass]

Add a flag to allow buildman to behave properly for use from an IDE. This
shows error/warning output on stderr and drops all summary and progress
information.

This should normally only be used when building a single board.

Fix up a confusing comment for GetResultSummary() while we are here, since
we want to use the Outcome object to access the unprocessed error lines
from the build.

Signed-off-by: Simon Glass 
---

 tools/buildman/README | 15 +
 tools/buildman/builder.py | 68 ---
 tools/buildman/cmdline.py |  2 ++
 tools/buildman/control.py |  7 ++--
 4 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/tools/buildman/README b/tools/buildman/README
index 49438cb909d..c67a074cb50 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -1092,6 +1092,21 @@ This will write the full build into /tmp/build including 
object files. You must
 specify the output directory with -o when using -w.
 
 
+Support for IDEs (Integrated Development Environments)
+==
+
+Normally buildman summarises the output and shows information indicating the
+meaning of each line of output. For example a '+' symbol appears at the start 
of
+each error line. Also, buildman prints information about what it is about to 
do,
+along with a summary at the end.
+
+When using buildman from an IDE, it is helpful to drop this behaviour. Use the
+-I/--ide option for that. You might find -W helpful also so that warnings do
+not cause the build to fail:
+
+   buildman -o /tmp/build --board sandbox -wWI
+
+
 Changing the configuration
 ==
 
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index aa2ffe16f6c..078ddf070d3 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -213,6 +213,8 @@ class Builder:
 threading is not being used
 _terminated: Thread was terminated due to an error
 _restarting_config: True if 'Restart config' is detected in output
+_ide: Produce output suitable for an Integrated Development 
Environment,
+i.e. dont emit progress information and put errors/warnings on 
stderr
 """
 class Outcome:
 """Records a build outcome for a single make invocation
@@ -325,6 +327,7 @@ class Builder:
 self.config_filenames = BASE_CONFIG_FILENAMES
 self.work_in_output = work_in_output
 self.adjust_cfg = adjust_cfg
+self._ide = False
 
 if not self.squash_config_y:
 self.config_filenames += EXTRA_CONFIG_FILENAMES
@@ -382,7 +385,7 @@ class Builder:
   show_detail=False, show_bloat=False,
   list_error_boards=False, show_config=False,
   show_environment=False, filter_dtb_warnings=False,
-  filter_migration_warnings=False):
+  filter_migration_warnings=False, ide=False):
 """Setup display options for the builder.
 
 Args:
@@ -397,6 +400,8 @@ class Builder:
 compiler
 filter_migration_warnings: Filter out any warnings about migrating
 a board to driver model
+ide: Create output that can be parsed by an IDE. There is no '+' 
prefix on
+error lines and output on stderr stays on stderr.
 """
 self._show_errors = show_errors
 self._show_sizes = show_sizes
@@ -407,6 +412,7 @@ class Builder:
 self._show_environment = show_environment
 self._filter_dtb_warnings = filter_dtb_warnings
 self._filter_migration_warnings = filter_migration_warnings
+self._ide = ide
 
 def _AddTimestamp(self):
 """Add a new timestamp to the list and record the build period.
@@ -535,8 +541,9 @@ class Builder:
 line += '%s  : ' % self._complete_delay
 
 line += target
-terminal.print_clear()
-tprint(line, newline=False, limit_to_line=True)
+if not self._ide:
+terminal.print_clear()
+tprint(line, newline=False, limit_to_line=True)
 
 def _GetOutputDir(self, commit_upto):
 """Get the name of the output directory for a commit number
@@ -834,8 +841,9 @@ class Builder:
 
 Returns:
 Tuple:
-Dict containing boards which passed building this commit.
-keyed by board.target
+Dict containing boards which built this commit:
+key: board.target
+value: Builder.Outcome object
 List containing a summary of error lines
 Dict keyed by error line, containing a list of the Board
 objects with that error
@@ -1369,8 +1377,14 @@ class Builder:
 better_warn, worse_warn = _CalcErrorDelta(self._base_warn_lines,
 self._base_warn_line_boards, warn_lines, warn_line_boards, 'w')
 
+  

[PATCH 04/19] buildman: Fix use of 'boards' in func_test

[Simon Glass]

We want to create a module called 'boards' so avoid use of this variable
name in this module. Change the global to be capitalised, as required by
Python style.

Signed-off-by: Simon Glass 
---

 tools/buildman/func_test.py | 38 ++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index 0265286908d..812dc924c8d 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -35,7 +35,7 @@ chromeos_daisy=VBOOT=${chroot}/build/daisy/usr ${vboot}
 chromeos_peach=VBOOT=${chroot}/build/peach_pit/usr ${vboot}
 '''
 
-boards = [
+BOARDS = [
 ['Active', 'arm', 'armv7', '', 'Tester', 'ARM Board 1', 'board0',  ''],
 ['Active', 'arm', 'armv7', '', 'Tester', 'ARM Board 2', 'board1', ''],
 ['Active', 'powerpc', 'powerpc', '', 'Tester', 'PowerPC board 1', 
'board2', ''],
@@ -188,13 +188,13 @@ class TestFunctional(unittest.TestCase):
 self._toolchains.Add('arm-gcc', test=False)
 self._toolchains.Add('powerpc-gcc', test=False)
 self._boards = board.Boards()
-for brd in boards:
+for brd in BOARDS:
 self._boards.AddBoard(board.Board(*brd))
 
 # Directories where the source been cloned
 self._clone_dirs = []
 self._commits = len(commit_shortlog.splitlines()) + 1
-self._total_builds = self._commits * len(boards)
+self._total_builds = self._commits * len(BOARDS)
 
 # Number of calls to make
 self._make_calls = 0
@@ -220,13 +220,13 @@ class TestFunctional(unittest.TestCase):
 return command.run_pipe([[self._buildman_pathname] + list(args)],
 capture=True, capture_stderr=True)
 
-def _RunControl(self, *args, boards=None, clean_dir=False,
+def _RunControl(self, *args, brds=None, clean_dir=False,
 test_thread_exceptions=False):
 """Run buildman
 
 Args:
 args: List of arguments to pass
-boards:
+brds: Boards object
 clean_dir: Used for tests only, indicates that the existing 
output_dir
 should be removed before starting the build
 test_thread_exceptions: Uses for tests only, True to make the 
threads
@@ -239,7 +239,7 @@ class TestFunctional(unittest.TestCase):
 sys.argv = [sys.argv[0]] + list(args)
 options, args = cmdline.ParseArgs()
 result = control.DoBuildman(options, args, toolchains=self._toolchains,
-make_func=self._HandleMake, boards=boards or self._boards,
+make_func=self._HandleMake, boards=brds or self._boards,
 clean_dir=clean_dir,
 test_thread_exceptions=test_thread_exceptions)
 self._builder = control.builder
@@ -451,7 +451,7 @@ class TestFunctional(unittest.TestCase):
 self.setupToolchains();
 self._RunControl('-o', self._output_dir)
 lines = terminal.get_print_test_lines()
-self.assertIn('Building current source for %d boards' % len(boards),
+self.assertIn('Building current source for %d boards' % len(BOARDS),
   lines[0].text)
 
 def testBadBranch(self):
@@ -467,7 +467,7 @@ class TestFunctional(unittest.TestCase):
 
 # Buildman always builds the upstream commit as well
 self.assertIn('Building %d commits for %d boards' %
-(self._commits, len(boards)), lines[0].text)
+(self._commits, len(BOARDS)), lines[0].text)
 self.assertEqual(self._builder.count, self._total_builds)
 
 # Only sandbox should succeed, the others don't have toolchains
@@ -493,17 +493,17 @@ class TestFunctional(unittest.TestCase):
 def testCount(self):
 """Test building a specific number of commitst"""
 self._RunControl('-b', TEST_BRANCH, '-c2', '-o', self._output_dir)
-self.assertEqual(self._builder.count, 2 * len(boards))
+self.assertEqual(self._builder.count, 2 * len(BOARDS))
 self.assertEqual(self._builder.fail, 0)
 # Each board has a config, and then one make per commit
-self.assertEqual(self._make_calls, len(boards) * (1 + 2))
+self.assertEqual(self._make_calls, len(BOARDS) * (1 + 2))
 
 def testIncremental(self):
 """Test building a branch twice - the second time should do nothing"""
 self._RunControl('-b', TEST_BRANCH, '-o', self._output_dir)
 
 # Each board has a mrproper, config, and then one make per commit
-self.assertEqual(self._make_calls, len(boards) * (self._commits + 1))
+self.assertEqual(self._make_calls, len(BOARDS) * (self._commits + 1))
 self._make_calls = 0
 self._RunControl('-b', TEST_BRANCH, '-o', self._output_dir, 
clean_dir=False)
 self.assertEqual(self._make_calls, 0)
@@ -516,19 +516,19 @@ class TestFunctional(unittest.TestCase):
 self._make_calls = 0
 self._RunControl('-b',

[PATCH 06/19] buildman: Drop use of 'boards' in control

[Simon Glass]

Use brds instead so that we can reserve 'boards' for a module name.

Signed-off-by: Simon Glass 
---

 tools/buildman/builder.py   | 11 +--
 tools/buildman/control.py   | 26 +-
 tools/buildman/func_test.py |  2 +-
 3 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 462266b4b84..33f9373b8f8 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -108,7 +108,7 @@ u-boot/ source directory
boards: List of Board objects which have line in the error/warning output
errline: The text of the error line
 """
-ErrLine = collections.namedtuple('ErrLine', 'char,boards,errline')
+ErrLine = collections.namedtuple('ErrLine', 'char,brds,errline')
 
 # Possible build outcomes
 OUTCOME_OK, OUTCOME_WARNING, OUTCOME_ERROR, OUTCOME_UNKNOWN = list(range(4))
@@ -1216,14 +1216,14 @@ class Builder:
 List of boards with that error line, or [] if the user has not
 requested such a list
 """
-boards = []
+brds = []
 board_set = set()
 if self._list_error_boards:
 for brd in line_boards[line]:
 if not brd in board_set:
-boards.append(brd)
+brds.append(brd)
 board_set.add(brd)
-return boards
+return brds
 
 def _CalcErrorDelta(base_lines, base_line_boards, lines, line_boards,
 char):
@@ -1326,8 +1326,7 @@ class Builder:
 if err_lines:
 out_list = []
 for line in err_lines:
-boards = ''
-names = [brd.target for brd in line.boards]
+names = [brd.target for brd in line.brds]
 board_str = ' '.join(names) if names else ''
 if board_str:
 out = self.col.build(colour, line.char + '(')
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 68dca97413f..c4dfc2af571 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -87,7 +87,7 @@ def ShowActions(series, why_selected, boards_selected, 
builder, options,
 for warning in board_warnings:
 print(col.build(col.YELLOW, warning))
 
-def ShowToolchainPrefix(boards, toolchains):
+def ShowToolchainPrefix(brds, toolchains):
 """Show information about a the tool chain used by one or more boards
 
 The function checks that all boards use the same toolchain, then prints
@@ -100,9 +100,9 @@ def ShowToolchainPrefix(boards, toolchains):
 Return:
 None on success, string error message otherwise
 """
-boards = boards.GetSelectedDict()
+board_selected = brds.GetSelectedDict()
 tc_set = set()
-for brd in boards.values():
+for brd in board_selected.values():
 tc_set.add(toolchains.Select(brd.arch))
 if len(tc_set) != 1:
 return 'Supplied boards must share one toolchain'
@@ -111,7 +111,7 @@ def ShowToolchainPrefix(boards, toolchains):
 print(tc.GetEnvArgs(toolchain.VAR_CROSS_COMPILE))
 return None
 
-def DoBuildman(options, args, toolchains=None, make_func=None, boards=None,
+def DoBuildman(options, args, toolchains=None, make_func=None, brds=None,
clean_dir=False, test_thread_exceptions=False):
 """The main control code for buildman
 
@@ -124,7 +124,7 @@ def DoBuildman(options, args, toolchains=None, 
make_func=None, boards=None,
 to execute 'make'. If this is None, the normal function
 will be used, which calls the 'make' tool with suitable
 arguments. This setting is useful for tests.
-board: Boards() object to use, containing a list of available
+brds: Boards() object to use, containing a list of available
 boards. If this is None it will be created and scanned.
 clean_dir: Used for tests only, indicates that the existing output_dir
 should be removed before starting the build
@@ -182,7 +182,7 @@ def DoBuildman(options, args, toolchains=None, 
make_func=None, boards=None,
 options.output_dir = '..'
 
 # Work out what subset of the boards we are building
-if not boards:
+if not brds:
 if not os.path.exists(options.output_dir):
 os.makedirs(options.output_dir)
 board_file = os.path.join(options.output_dir, 'boards.cfg')
@@ -197,8 +197,8 @@ def DoBuildman(options, args, toolchains=None, 
make_func=None, boards=None,
 if status != 0:
 sys.exit("Failed to generate boards.cfg")
 
-boards = board.Boards()
-boards.ReadBoards(board_file)
+brds = board.Boards()
+brds.ReadBoards(board_file)
 
 exclude = []
 if options.exclude:
@@ -211,14 +211,14 @@ def DoBuildman(options, args, toolchains=None, 
mak

[PATCH 05/19] buildman: Fix use of 'boards' in test

[Simon Glass]

We want to create a module called 'boards' so avoid use of this variable
name in this module. Change the global to be capitalised, as required by
Python style.

Signed-off-by: Simon Glass 
---

 tools/buildman/test.py | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index 62ad25db397..6c09cb7fad5 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.py
@@ -94,7 +94,7 @@ commits = [
  [errors[4]]],
 ]
 
-boards = [
+BOARDS = [
 ['Active', 'arm', 'armv7', '', 'Tester', 'ARM Board 1', 'board0',  ''],
 ['Active', 'arm', 'armv7', '', 'Tester', 'ARM Board 2', 'board1', ''],
 ['Active', 'powerpc', 'powerpc', '', 'Tester', 'PowerPC board 1', 
'board2', ''],
@@ -131,10 +131,10 @@ class TestBuild(unittest.TestCase):
 self.commits.append(comm)
 
 # Set up boards to build
-self.boards = board.Boards()
-for brd in boards:
-self.boards.AddBoard(board.Board(*brd))
-self.boards.SelectBoards([])
+self.brds = board.Boards()
+for brd in BOARDS:
+self.brds.AddBoard(board.Board(*brd))
+self.brds.SelectBoards([])
 
 # Add some test settings
 bsettings.Setup(None)
@@ -176,7 +176,7 @@ class TestBuild(unittest.TestCase):
 result.combined = result.stdout + result.stderr
 return result
 
-def assertSummary(self, text, arch, plus, boards, outcome=OUTCOME_ERR):
+def assertSummary(self, text, arch, plus, brds, outcome=OUTCOME_ERR):
 col = self._col
 expected_colour = (col.GREEN if outcome == OUTCOME_OK else
col.YELLOW if outcome == OUTCOME_WARN else col.RED)
@@ -184,7 +184,7 @@ class TestBuild(unittest.TestCase):
 # TODO(s...@chromium.org): If plus is '', we shouldn't need this
 expect += ' ' + col.build(expected_colour, plus)
 expect += '  '
-for brd in boards:
+for brd in brds:
 expect += col.build(expected_colour, ' %s' % brd)
 self.assertEqual(text, expect)
 
@@ -203,7 +203,7 @@ class TestBuild(unittest.TestCase):
 build = builder.Builder(self.toolchains, self.base_dir, None, threads,
 2, checkout=False, show_unknown=False)
 build.do_make = self.Make
-board_selected = self.boards.GetSelectedDict()
+board_selected = self.brds.GetSelectedDict()
 
 # Build the boards for the pre-defined commits and warnings/errors
 # associated with each. This calls our Make() to inject the fake 
output.
@@ -217,7 +217,7 @@ class TestBuild(unittest.TestCase):
 
 # We should get two starting messages, an update for every commit built
 # and a summary message
-self.assertEqual(count, len(commits) * len(boards) + 3)
+self.assertEqual(count, len(commits) * len(BOARDS) + 3)
 build.SetDisplayOptions(**kwdisplay_args);
 build.ShowSummary(self.commits, board_selected)
 if echo_lines:
@@ -236,7 +236,7 @@ class TestBuild(unittest.TestCase):
 filter_dtb_warnings: Adjust the check for output produced with the
--filter-dtb-warnings flag
 """
-def add_line_prefix(prefix, boards, error_str, colour):
+def add_line_prefix(prefix, brds, error_str, colour):
 """Add a prefix to each line of a string
 
 The training \n in error_str is removed before processing
@@ -253,9 +253,9 @@ class TestBuild(unittest.TestCase):
 lines = error_str.strip().splitlines()
 new_lines = []
 for line in lines:
-if boards:
+if brds:
 expect = self._col.build(colour, prefix + '(')
-expect += self._col.build(self._col.MAGENTA, boards,
+expect += self._col.build(self._col.MAGENTA, brds,
   bright=False)
 expect += self._col.build(colour, ') %s' % line)
 else:
@@ -468,18 +468,18 @@ class TestBuild(unittest.TestCase):
 
 def testBoardSingle(self):
 """Test single board selection"""
-self.assertEqual(self.boards.SelectBoards(['sandbox']),
+self.assertEqual(self.brds.SelectBoards(['sandbox']),
  ({'all': ['board4'], 'sandbox': ['board4']}, []))
 
 def testBoardArch(self):
 """Test single board selection"""
-self.assertEqual(self.boards.SelectBoards(['arm']),
+self.assertEqual(self.brds.SelectBoards(['arm']),
  ({'all': ['board0', 'board1'],
   'arm': ['board0', 'board1']}, []))
 
 def testBoardArchSingle(self):
 """Test single board selection"""
-self.assertEqual(self.boards.SelectBoards(['arm sandbox']),
+self.assertEqual(self.brds.SelectBoards(['arm sandbox']),
   

[PATCH 07/19] buildman: Drop use of 'board' in board module

[Simon Glass]

Use brds instead so that we can reserve 'boards' and 'board' as module
names.

Signed-off-by: Simon Glass 
---

 tools/buildman/board.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index 08771b3f158..8de71e487ee 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -116,7 +116,7 @@ class Boards:
 def ReadBoards(self, fname):
 """Read a list of boards from a board file.
 
-Create a board object for each and add it to our _boards list.
+Create a Board object for each and add it to our _boards list.
 
 Args:
 fname: Filename of boards.cfg file
@@ -238,21 +238,21 @@ class Boards:
 terms.append(term)
 return terms
 
-def SelectBoards(self, args, exclude=[], boards=None):
+def SelectBoards(self, args, exclude=[], brds=None):
 """Mark boards selected based on args
 
 Normally either boards (an explicit list of boards) or args (a list of
 terms to match against) is used. It is possible to specify both, in
 which case they are additive.
 
-If boards and args are both empty, all boards are selected.
+If brds and args are both empty, all boards are selected.
 
 Args:
 args: List of strings specifying boards to include, either named,
   or by their target, architecture, cpu, vendor or soc. If
   empty, all boards are selected.
 exclude: List of boards to exclude, regardless of 'args'
-boards: List of boards to build
+brds: List of boards to build
 
 Returns:
 Tuple
@@ -283,8 +283,8 @@ class Boards:
 matching_term = str(term)
 build_it = True
 break
-elif boards:
-if brd.target in boards:
+elif brds:
+if brd.target in brds:
 build_it = True
 found.append(brd.target)
 else:
@@ -302,8 +302,8 @@ class Boards:
 result[matching_term].append(brd.target)
 result['all'].append(brd.target)
 
-if boards:
-remaining = set(boards) - set(found)
+if brds:
+remaining = set(brds) - set(found)
 if remaining:
 warnings.append('Boards not found: %s\n' % ', 
'.join(remaining))
 
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 08/19] buildman: Convert camel case in board.py

[Simon Glass]

Convert this file to snake case and update all files which use it.

Signed-off-by: Simon Glass 
---

 tools/buildman/board.py | 38 ++---
 tools/buildman/control.py   | 12 ++--
 tools/buildman/func_test.py | 10 +-
 tools/buildman/test.py  | 24 +++
 4 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index 8de71e487ee..ebb9d6f67dc 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -16,7 +16,7 @@ class Expr:
 self._expr = expr
 self._re = re.compile(expr)
 
-def Matches(self, props):
+def matches(self, props):
 """Check if any of the properties match the regular expression.
 
 Args:
@@ -42,7 +42,7 @@ class Term:
 self._expr_list = []
 self._board_count = 0
 
-def AddExpr(self, expr):
+def add_expr(self, expr):
 """Add an Expr object to the list to check.
 
 Args:
@@ -55,7 +55,7 @@ class Term:
 """Return some sort of useful string describing the term"""
 return '&'.join([str(expr) for expr in self._expr_list])
 
-def Matches(self, props):
+def matches(self, props):
 """Check if any of the properties match this term
 
 Each of the expressions in the term is checked. All must match.
@@ -66,7 +66,7 @@ class Term:
True if all of the expressions in the Term match, else False
 """
 for expr in self._expr_list:
-if not expr.Matches(props):
+if not expr.matches(props):
 return False
 return True
 
@@ -103,7 +103,7 @@ class Boards:
 # Use a simple list here, sinc OrderedDict requires Python 2.7
 self._boards = []
 
-def AddBoard(self, brd):
+def add_board(self, brd):
 """Add a new board to the list.
 
 The board's target member must not already exist in the board list.
@@ -113,7 +113,7 @@ class Boards:
 """
 self._boards.append(brd)
 
-def ReadBoards(self, fname):
+def read_boards(self, fname):
 """Read a list of boards from a board file.
 
 Create a Board object for each and add it to our _boards list.
@@ -137,10 +137,10 @@ class Boards:
 fields = fields[:8]
 
 brd = Board(*fields)
-self.AddBoard(brd)
+self.add_board(brd)
 
 
-def GetList(self):
+def get_list(self):
 """Return a list of available boards.
 
 Returns:
@@ -148,7 +148,7 @@ class Boards:
 """
 return self._boards
 
-def GetDict(self):
+def get_dict(self):
 """Build a dictionary containing all the boards.
 
 Returns:
@@ -161,7 +161,7 @@ class Boards:
 board_dict[brd.target] = brd
 return board_dict
 
-def GetSelectedDict(self):
+def get_selected_dict(self):
 """Return a dictionary containing the selected boards
 
 Returns:
@@ -173,7 +173,7 @@ class Boards:
 board_dict[brd.target] = brd
 return board_dict
 
-def GetSelected(self):
+def get_selected(self):
 """Return a list of selected boards
 
 Returns:
@@ -181,7 +181,7 @@ class Boards:
 """
 return [brd for brd in self._boards if brd.build_it]
 
-def GetSelectedNames(self):
+def get_selected_names(self):
 """Return a list of selected boards
 
 Returns:
@@ -189,7 +189,7 @@ class Boards:
 """
 return [brd.target for brd in self._boards if brd.build_it]
 
-def _BuildTerms(self, args):
+def _build_terms(self, args):
 """Convert command line arguments to a list of terms.
 
 This deals with parsing of the arguments. It handles the '&'
@@ -227,18 +227,18 @@ class Boards:
 if sym == '&':
 oper = sym
 elif oper:
-term.AddExpr(sym)
+term.add_expr(sym)
 oper = None
 else:
 if term:
 terms.append(term)
 term = Term()
-term.AddExpr(sym)
+term.add_expr(sym)
 if term:
 terms.append(term)
 return terms
 
-def SelectBoards(self, args, exclude=[], brds=None):
+def select_boards(self, args, exclude=[], brds=None):
 """Mark boards selected based on args
 
 Normally either boards (an explicit list of boards) or args (a list of
@@ -262,7 +262,7 @@ class Boards:
 """
 result = OrderedDict()
 warnings = []
-terms = self._BuildTerms(args)
+terms = self._build_terms(args)
 
 result['all'] = []
 for term in terms:
@@ -279,7 +279,7 @@ class Boards:
 if terms:
 match = False
 for term in terms:
-if term.Matches(brd.props):
+if term.matches(brd

[PATCH 11/19] buildman: Tidy up pylint problems in boards module

[Simon Glass]

Fix all the pylint warnings. Also tidy up the comments so that they show
type information, as required.

Signed-off-by: Simon Glass 
---

 tools/buildman/boards.py | 352 +++
 1 file changed, 204 insertions(+), 148 deletions(-)

diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index c18914253e4..e16f3268ab1 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -24,19 +24,26 @@ from buildman import kconfiglib
 OUTPUT_FILE = 'boards.cfg'
 CONFIG_DIR = 'configs'
 SLEEP_TIME = 0.03
-COMMENT_BLOCK = '''#
+COMMENT_BLOCK = f'''#
 # List of boards
-#   Automatically generated by %s: don't edit
+#   Automatically generated by {__file__}: don't edit
 #
 # Status, Arch, CPU, SoC, Vendor, Board, Target, Options, Maintainers
 
-''' % __file__
+'''
 
 
-def try_remove(f):
-"""Remove a file ignoring 'No such file or directory' error."""
+def try_remove(fname):
+"""Remove a file ignoring 'No such file or directory' error.
+
+Args:
+fname (str): Filename to remove
+
+Raises:
+OSError: output file exists but could not be removed
+"""
 try:
-os.remove(f)
+os.remove(fname)
 except OSError as exception:
 # Ignore 'No such file or directory' error
 if exception.errno != errno.ENOENT:
@@ -46,20 +53,30 @@ def try_remove(f):
 def output_is_new(output):
 """Check if the output file is up to date.
 
+Looks at defconfig and Kconfig files to make sure none is newer than the
+output file. Also ensures that the boards.cfg does not mention any removed
+boards.
+
+Args:
+output (str): Filename to check
+
 Returns:
-  True if the given output file exists and is newer than any of
-  *_defconfig, MAINTAINERS and Kconfig*.  False otherwise.
+True if the given output file exists and is newer than any of
+*_defconfig, MAINTAINERS and Kconfig*.  False otherwise.
+
+Raises:
+OSError: output file exists but could not be opened
 """
+# pylint: disable=too-many-branches
 try:
 ctime = os.path.getctime(output)
 except OSError as exception:
 if exception.errno == errno.ENOENT:
 # return False on 'No such file or directory' error
 return False
-else:
-raise
+raise
 
-for (dirpath, dirnames, filenames) in os.walk(CONFIG_DIR):
+for (dirpath, _, filenames) in os.walk(CONFIG_DIR):
 for filename in fnmatch.filter(filenames, '*_defconfig'):
 if fnmatch.fnmatch(filename, '.*'):
 continue
@@ -67,7 +84,7 @@ def output_is_new(output):
 if ctime < os.path.getctime(filepath):
 return False
 
-for (dirpath, dirnames, filenames) in os.walk('.'):
+for (dirpath, _, filenames) in os.walk('.'):
 for filename in filenames:
 if (fnmatch.fnmatch(filename, '*~') or
 not fnmatch.fnmatch(filename, 'Kconfig*') and
@@ -79,8 +96,8 @@ def output_is_new(output):
 
 # Detect a board that has been removed since the current board database
 # was generated
-with open(output, encoding="utf-8") as f:
-for line in f:
+with open(output, encoding="utf-8") as inf:
+for line in inf:
 if line[0] == '#' or line == '\n':
 continue
 defconfig = line.split()[6] + '_defconfig'
@@ -97,7 +114,7 @@ class Expr:
 """Set up a new Expr object.
 
 Args:
-expr: String cotaining regular expression to store
+expr (str): String cotaining regular expression to store
 """
 self._expr = expr
 self._re = re.compile(expr)
@@ -106,7 +123,7 @@ class Expr:
 """Check if any of the properties match the regular expression.
 
 Args:
-   props: List of properties to check
+   props (list of str): List of properties to check
 Returns:
True if any of the properties match the regular expression
 """
@@ -132,7 +149,7 @@ class Term:
 """Add an Expr object to the list to check.
 
 Args:
-expr: New Expr object to add to the list of those that must
+expr (Expr): New Expr object to add to the list of those that must
   match for a board to be built.
 """
 self._expr_list.append(Expr(expr))
@@ -147,7 +164,7 @@ class Term:
 Each of the expressions in the term is checked. All must match.
 
 Args:
-   props: List of properties to check
+   props (list of str): List of properties to check
 Returns:
True if all of the expressions in the Term match, else False
 """
@@ -178,6 +195,7 @@ class KconfigScanner:
 os.environ['srctree'] = os.getcwd()
 os.environ['UBOOTVERSION'] = 'dummy'
 os.environ['KCONFIG_OBJDIR'] = ''
+self._tmpfile = None
 self._conf = kconfiglib.Kconfig(war

[PATCH 13/19] Revert "Revert "global: Remove CONFIG_SYS_EXTRA_OPTIONS support""

[Simon Glass]

This is not needed now that CONFIG_SYS_TARGET_NAME is correctly determined
when scanning Kconfig.

This reverts commit 25b8acee2ea11a9edc100c42a61f5d6187eb6167.

Signed-off-by: Simon Glass 
Suggested-by: Tom Rini 
---

 boot/Kconfig   | 13 
 doc/README.kconfig |  7 
 doc/develop/moveconfig.rst |  3 +-
 scripts/Makefile.autoconf  |  4 ---
 scripts/build-whitelist.sh | 23 ++
 tools/moveconfig.py| 65 --
 6 files changed, 4 insertions(+), 111 deletions(-)

diff --git a/boot/Kconfig b/boot/Kconfig
index 17438b566d5..37880af5519 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -452,19 +452,6 @@ config OF_STDOUT_VIA_ALIAS
  incorrect when used with device tree as this option does not
  exist / should not be used.
 
-config SYS_EXTRA_OPTIONS
-   string "Extra Options (DEPRECATED)"
-   help
- The old configuration infrastructure (= mkconfig + boards.cfg)
- provided the extra options field. If you have something like
- "HAS_BAR,BAZ=64", the optional options
-   #define CONFIG_HAS
-   #define CONFIG_BAZ  64
- will be defined in include/config.h.
- This option was prepared for the smooth migration from the old
- configuration to Kconfig. Since this option will be removed sometime,
- new boards should not use this option.
-
 config HAVE_SYS_TEXT_BASE
bool
depends on !NIOS2 && !XTENSA
diff --git a/doc/README.kconfig b/doc/README.kconfig
index 0689f66c2cd..808cf56e59c 100644
--- a/doc/README.kconfig
+++ b/doc/README.kconfig
@@ -99,7 +99,6 @@ Kconfig.  Each field of boards.cfg was converted as follows:
  Vendor  ->  CONFIG_SYS_VENDOR defined by Kconfig
  Board   ->  CONFIG_SYS_BOARD defined by Kconfig
  Target  ->  File name of defconfig (configs/_defconfig)
- Options ->  CONFIG_SYS_EXTRA_OPTIONS defined by Kconfig
  Maintainers ->  "M:" entry of MAINTAINERS
 
 
@@ -140,12 +139,6 @@ When removing an obsolete board, the following steps are 
generally needed:
 TODO
 
 
-- The option field of boards.cfg, which was used for the pre-Kconfig
-  configuration, moved to CONFIG_SYS_EXTRA_OPTIONS verbatim now.
-  Board maintainers are expected to implement proper Kconfig options
-  and switch over to them.  Eventually CONFIG_SYS_EXTRA_OPTIONS will go away.
-  CONFIG_SYS_EXTRA_OPTIONS should not be used for new boards.
-
 - In the pre-Kconfig, a single board had multiple entries in the boards.cfg
   file with differences in the option fields.  The corresponding defconfig
   files were auto-generated when switching to Kconfig.  Now we have too many
diff --git a/doc/develop/moveconfig.rst b/doc/develop/moveconfig.rst
index 2f53ea52b71..bfb7aff3582 100644
--- a/doc/develop/moveconfig.rst
+++ b/doc/develop/moveconfig.rst
@@ -295,8 +295,7 @@ Available options
 
  -y, --yes
Instead of prompting, automatically go ahead with all operations. This
-   includes cleaning up headers, CONFIG_SYS_EXTRA_OPTIONS, the config whitelist
-   and the README.
+   includes cleaning up headers, the config whitelist and the README.
 
 To see the complete list of supported options, run::
 
diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf
index 3fa4d50f1ea..5a4a1489553 100644
--- a/scripts/Makefile.autoconf
+++ b/scripts/Makefile.autoconf
@@ -112,10 +112,6 @@ vpl/include/autoconf.mk: vpl/u-boot.cfg
 # Prior to Kconfig, it was generated by mkconfig. Now it is created here.
 define filechk_config_h
(echo "/* Automatically generated - do not edit */";\
-   for i in $$(echo $(CONFIG_SYS_EXTRA_OPTIONS) | sed 's/,/ /g'); do \
-   echo \#define CONFIG_$$i\
-   | sed '/=/ {s/=//;q; } ; { s/$$/1/; }'; \
-   done;   \
echo \#define CONFIG_BOARDDIR board/$(if $(VENDOR),$(VENDOR)/)$(BOARD);\
echo \#include \;  \
echo \#include \; \
diff --git a/scripts/build-whitelist.sh b/scripts/build-whitelist.sh
index 6feb9b67cf5..37630c0271c 100755
--- a/scripts/build-whitelist.sh
+++ b/scripts/build-whitelist.sh
@@ -10,30 +10,13 @@
 #
 export LC_ALL=C LC_COLLATE=C
 
-# There are two independent greps. The first pulls out the component parts
-# of CONFIG_SYS_EXTRA_OPTIONS. An example is:
+# Looks for the rest of the CONFIG options, but exclude those in Kconfig and
+# defconfig files.
 #
-#  SUN7I_GMAC,AHCI,SATAPWR=SUNXI_GPB(8)
-#
-# We want this to produce:
-#  CONFIG_SUN7I_GMAC
-#  CONFIG_AHCI
-#  CONFIG_SATAPWR
-#
-# The second looks for the rest of the CONFIG options, but excludes those in
-# Kconfig and defconfig files.
-#
-(
-git grep CONFIG_SYS_EXTRA_OPTIONS |sed -n \
-   's/.*CONFIG_SYS_EXTRA_OPTIONS="\(.*\)"/\1/ p' \
-   | tr , '\n' \
-   | sed 's/ *\([A-Za-z0-9_]*\).*/CONFIG_\1/'
-
 git grep CONFIG_ | \

[PATCH 12/19] buildman: Replace the Options column with config name

[Simon Glass]

This appears in boards.cfg but we want to remove it. Drop support for
generating it and reading it. Detect an old boards.cfg file that has
this field and regenerate it, to avoid problems.

Instead, add the config name in that place. This fixes a subtle bug in
the generation code, since it uses 'target' for the config name and then
overwrites the value in scan() by setting params['target'] to the name
of the defconfig. The defconfig name is not the same as the
SYS_CONFIG_NAME variable.

With this change, we still have the config name and it can be searched
by buildman, e.g. with:

   buildman -nv sun5i

Signed-off-by: Simon Glass 
Reported-by: Tom Rini 
---

 tools/buildman/board.py  |  8 
 tools/buildman/boards.py | 19 ++-
 2 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index 3268b39e356..8ef905b8ce1 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -6,7 +6,7 @@
 
 class Board:
 """A particular board that we can build"""
-def __init__(self, status, arch, cpu, soc, vendor, board_name, target, 
options):
+def __init__(self, status, arch, cpu, soc, vendor, board_name, target, 
cfg_name):
 """Create a new board type.
 
 Args:
@@ -17,7 +17,7 @@ class Board:
 vendor: Name of vendor (e.g. armltd)
 board_name: Name of board (e.g. integrator)
 target: Target name (use make _defconfig to configure)
-options: board-specific options (e.g. integratorcp:CM1136)
+cfg_name: Config name
 """
 self.target = target
 self.arch = arch
@@ -25,7 +25,7 @@ class Board:
 self.board_name = board_name
 self.vendor = vendor
 self.soc = soc
-self.options = options
+self.cfg_name = cfg_name
 self.props = [self.target, self.arch, self.cpu, self.board_name,
-  self.vendor, self.soc, self.options]
+  self.vendor, self.soc, self.cfg_name]
 self.build_it = False
diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index e16f3268ab1..8832e40cd5d 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -28,7 +28,7 @@ COMMENT_BLOCK = f'''#
 # List of boards
 #   Automatically generated by {__file__}: don't edit
 #
-# Status, Arch, CPU, SoC, Vendor, Board, Target, Options, Maintainers
+# Status, Arch, CPU, SoC, Vendor, Board, Target, Config, Maintainers
 
 '''
 
@@ -98,6 +98,8 @@ def output_is_new(output):
 # was generated
 with open(output, encoding="utf-8") as inf:
 for line in inf:
+if 'Options,' in line:
+return False
 if line[0] == '#' or line == '\n':
 continue
 defconfig = line.split()[6] + '_defconfig'
@@ -186,7 +188,7 @@ class KconfigScanner:
 'vendor' : 'SYS_VENDOR',
 'board' : 'SYS_BOARD',
 'config' : 'SYS_CONFIG_NAME',
-'options' : 'SYS_EXTRA_OPTIONS'
+# 'target' is added later
 }
 
 def __init__(self):
@@ -216,7 +218,7 @@ class KconfigScanner:
 defconfig (str): path to the defconfig file to be processed
 
 Returns:
-Dictionary of board parameters.  It has a form:
+A dictionary of board parameters.  It has a form of:
 {
 'arch': ,
 'cpu': ,
@@ -225,7 +227,6 @@ class KconfigScanner:
 'board': ,
 'target': ,
 'config': ,
-'options': 
 }
 """
 # strip special prefixes and save it in a temporary file
@@ -262,14 +263,6 @@ class KconfigScanner:
 if params['arch'] == 'arm' and params['cpu'] == 'armv8':
 params['arch'] = 'aarch64'
 
-# fix-up options field. It should have the form:
-# [:comma separated config options]
-if params['options'] != '-':
-params['options'] = params['config'] + ':' + \
-params['options'].replace(r'\"', '"')
-elif params['config'] != params['target']:
-params['options'] = params['config']
-
 return params
 
 
@@ -708,7 +701,7 @@ class Boards:
 output (str): The path to the output file
 """
 fields = ('status', 'arch', 'cpu', 'soc', 'vendor', 'board', 'target',
-  'options', 'maintainers')
+  'config', 'maintainers')
 
 # First, decide the width of each column
 max_length = {f: 0 for f in fields}
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 09/19] buildman: Split out Boards into its own file

[Simon Glass]

Use a separate file for the Boards class so that its name matches the
module name.

Fix up the function names to match the pylint style and fix some other
warnings.

Signed-off-by: Simon Glass 
---

 tools/buildman/board.py | 281 +-
 tools/buildman/boards.py| 290 
 tools/buildman/control.py   |   4 +-
 tools/buildman/func_test.py |  11 +-
 tools/buildman/test.py  |   3 +-
 5 files changed, 301 insertions(+), 288 deletions(-)
 create mode 100644 tools/buildman/boards.py

diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index ebb9d6f67dc..3268b39e356 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -1,74 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 # Copyright (c) 2012 The Chromium OS Authors.
 
-from collections import OrderedDict
-import re
 
-class Expr:
-"""A single regular expression for matching boards to build"""
-
-def __init__(self, expr):
-"""Set up a new Expr object.
-
-Args:
-expr: String cotaining regular expression to store
-"""
-self._expr = expr
-self._re = re.compile(expr)
-
-def matches(self, props):
-"""Check if any of the properties match the regular expression.
-
-Args:
-   props: List of properties to check
-Returns:
-   True if any of the properties match the regular expression
-"""
-for prop in props:
-if self._re.match(prop):
-return True
-return False
-
-def __str__(self):
-return self._expr
-
-class Term:
-"""A list of expressions each of which must match with properties.
-
-This provides a list of 'AND' expressions, meaning that each must
-match the board properties for that board to be built.
-"""
-def __init__(self):
-self._expr_list = []
-self._board_count = 0
-
-def add_expr(self, expr):
-"""Add an Expr object to the list to check.
-
-Args:
-expr: New Expr object to add to the list of those that must
-  match for a board to be built.
-"""
-self._expr_list.append(Expr(expr))
-
-def __str__(self):
-"""Return some sort of useful string describing the term"""
-return '&'.join([str(expr) for expr in self._expr_list])
-
-def matches(self, props):
-"""Check if any of the properties match this term
-
-Each of the expressions in the term is checked. All must match.
-
-Args:
-   props: List of properties to check
-Returns:
-   True if all of the expressions in the Term match, else False
-"""
-for expr in self._expr_list:
-if not expr.matches(props):
-return False
-return True
+"""A single board which can be selected and built"""
 
 class Board:
 """A particular board that we can build"""
@@ -95,216 +29,3 @@ class Board:
 self.props = [self.target, self.arch, self.cpu, self.board_name,
   self.vendor, self.soc, self.options]
 self.build_it = False
-
-
-class Boards:
-"""Manage a list of boards."""
-def __init__(self):
-# Use a simple list here, sinc OrderedDict requires Python 2.7
-self._boards = []
-
-def add_board(self, brd):
-"""Add a new board to the list.
-
-The board's target member must not already exist in the board list.
-
-Args:
-brd: board to add
-"""
-self._boards.append(brd)
-
-def read_boards(self, fname):
-"""Read a list of boards from a board file.
-
-Create a Board object for each and add it to our _boards list.
-
-Args:
-fname: Filename of boards.cfg file
-"""
-with open(fname, 'r', encoding='utf-8') as fd:
-for line in fd:
-if line[0] == '#':
-continue
-fields = line.split()
-if not fields:
-continue
-for upto in range(len(fields)):
-if fields[upto] == '-':
-fields[upto] = ''
-while len(fields) < 8:
-fields.append('')
-if len(fields) > 8:
-fields = fields[:8]
-
-brd = Board(*fields)
-self.add_board(brd)
-
-
-def get_list(self):
-"""Return a list of available boards.
-
-Returns:
-List of Board objects
-"""
-return self._boards
-
-def get_dict(self):
-"""Build a dictionary containing all the boards.
-
-Returns:
-Dictionary:
-key is board.target
-value is board
-"""
-board_dict = OrderedDict()
-for brd in self._boards:
-board_dict[brd.target] = brd
-return board_dict
-
-def get_selecte

[PATCH 10/19] buildman: Incorporate the genboardscfg.py tool

[Simon Glass]

Bring this tool into buildman, so we don't have to run it separately. The
board.cfg file is still produced as part of the build, to save time when
doing another build in the same working directory. If it is out of date
with respect to the Kconfig, it is updated.

Time to regenerate on a recent single-thread machine is 4.6s (1.3s on a
32-thread machine), so we do need some sort of cache if we want buildman
to be useful on incremental builds. We could use Python's pickle format
but:

- it seems useful to allow boards.cfg to be regenerated, at least for a
  while, in case other tools use it
- it is possible to grep the file easily, e.g. to find boards which use
  a particular SoC (similar to 'buildman -nv '

Signed-off-by: Simon Glass 
Suggested-by: Tom Rini 
---

 tools/buildman/README |  21 +-
 tools/buildman/boards.py  | 402 ++
 tools/buildman/cmdline.py |   2 +
 tools/buildman/control.py |  16 +-
 4 files changed, 426 insertions(+), 15 deletions(-)

diff --git a/tools/buildman/README b/tools/buildman/README
index c67a074cb50..0666bc7d564 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -128,10 +128,10 @@ Selecting which boards to build
 ===
 
 Buildman lets you build all boards, or a subset. Specify the subset by passing
-command-line arguments that list the desired board name, architecture name,
-SOC name, or anything else in the boards.cfg file. Multiple arguments are
-allowed. Each argument will be interpreted as a regular expression, so
-behaviour is a superset of exact or substring matching. Examples are:
+command-line arguments that list the desired build target, architecture,
+CPU, board name, vendor, SoC or options. Multiple arguments are allowed. Each
+argument will be interpreted as a regular expression, so behaviour is a 
superset
+of exact or substring matching. Examples are:
 
 * 'tegra20'  All boards with a Tegra20 SoC
 * 'tegra'All boards with any Tegra Soc (Tegra20, Tegra30, Tegra114...)
@@ -1054,7 +1054,6 @@ between one commit and the next.
 For example:
 
 $ buildman -b squash brppt1 -sU
-boards.cfg is up to date. Nothing to do.
 Summary of 2 commits for 3 boards (3 threads, 3 jobs per thread)
 01: Migrate bootlimit to Kconfig
 02: Squashed commit of the following:
@@ -1309,6 +1308,18 @@ Some options you might like are:
 break anything. But note this does not check bisectability!
 
 
+Using boards.cfg
+
+
+This file is no-longer needed by buildman but it is still generated in the
+working directory. This helps avoid a delay on every build, since scanning all
+the Kconfig files takes a few seconds. Use the -R flag to force regeneration
+of the file - in that case buildman exits after writing the file.
+
+You should use 'buildman -nv ' instead of greoing the boards.cfg 
file,
+since it may be dropped altogether in future.
+
+
 TODO
 
 
diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index ec143f9e0f5..c18914253e4 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -1,12 +1,93 @@
 # SPDX-License-Identifier: GPL-2.0+
 # Copyright (c) 2012 The Chromium OS Authors.
+# Author: Simon Glass 
+# Author: Masahiro Yamada 
 
 """Maintains a list of boards and allows them to be selected"""
 
 from collections import OrderedDict
+import errno
+import fnmatch
+import glob
+import multiprocessing
+import os
 import re
+import sys
+import tempfile
+import time
 
 from buildman import board
+from buildman import kconfiglib
+
+
+### constant variables ###
+OUTPUT_FILE = 'boards.cfg'
+CONFIG_DIR = 'configs'
+SLEEP_TIME = 0.03
+COMMENT_BLOCK = '''#
+# List of boards
+#   Automatically generated by %s: don't edit
+#
+# Status, Arch, CPU, SoC, Vendor, Board, Target, Options, Maintainers
+
+''' % __file__
+
+
+def try_remove(f):
+"""Remove a file ignoring 'No such file or directory' error."""
+try:
+os.remove(f)
+except OSError as exception:
+# Ignore 'No such file or directory' error
+if exception.errno != errno.ENOENT:
+raise
+
+
+def output_is_new(output):
+"""Check if the output file is up to date.
+
+Returns:
+  True if the given output file exists and is newer than any of
+  *_defconfig, MAINTAINERS and Kconfig*.  False otherwise.
+"""
+try:
+ctime = os.path.getctime(output)
+except OSError as exception:
+if exception.errno == errno.ENOENT:
+# return False on 'No such file or directory' error
+return False
+else:
+raise
+
+for (dirpath, dirnames, filenames) in os.walk(CONFIG_DIR):
+for filename in fnmatch.filter(filenames, '*_defconfig'):
+if fnmatch.fnmatch(filename, '.*'):
+continue
+filepath = os.path.join(dirpath, filename)
+if ctime < os.path.getctime(filepath):
+return False
+
+for (dirpath, dirnames, filenames) in os.walk('.

[PATCH 17/19] buildman: Allow lines without a symbol

[Simon Glass]

The 'nm' tool can produce lines without a symbol, for example:

   0004 t

Silently skip these and anything else without three fields. Drop the
warning since there is nothing the user can do about it.

Signed-off-by: Simon Glass 
Reported-by: Tom Rini 
---

 tools/buildman/builder.py | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 33f9373b8f8..76252b90792 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -669,17 +669,15 @@ class Builder:
 """
 sym = {}
 for line in fd.readlines():
-try:
-if line.strip():
-size, type, name = line[:-1].split()
-except:
-tprint("Invalid line in file '%s': '%s'" % (fname, line[:-1]))
-continue
-if type in 'tTdDbB':
-# function names begin with '.' on 64-bit powerpc
-if '.' in name[1:]:
-name = 'static.' + name.split('.')[0]
-sym[name] = sym.get(name, 0) + int(size, 16)
+line = line.strip()
+parts = line.split()
+if line and len(parts) == 3:
+size, type, name = line.split()
+if type in 'tTdDbB':
+# function names begin with '.' on 64-bit powerpc
+if '.' in name[1:]:
+name = 'static.' + name.split('.')[0]
+sym[name] = sym.get(name, 0) + int(size, 16)
 return sym
 
 def _ProcessConfig(self, fname):
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 14/19] buildman: Return an error if there are maintainer warnings

[Simon Glass]

Detect warnings about missing maintain info and return result code 2 in
that case.

Signed-off-by: Simon Glass 
---

 tools/buildman/README |  3 ++-
 tools/buildman/boards.py  | 22 +-
 tools/buildman/control.py | 10 +-
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/tools/buildman/README b/tools/buildman/README
index 0666bc7d564..3ba08d0dace 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -1314,7 +1314,8 @@ Using boards.cfg
 This file is no-longer needed by buildman but it is still generated in the
 working directory. This helps avoid a delay on every build, since scanning all
 the Kconfig files takes a few seconds. Use the -R flag to force regeneration
-of the file - in that case buildman exits after writing the file.
+of the file - in that case buildman exits after writing the file. with exit 
code
+2 if there was an error in the maintainer files.
 
 You should use 'buildman -nv ' instead of greoing the boards.cfg 
file,
 since it may be dropped altogether in future.
diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index 8832e40cd5d..b30b344bc8e 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -276,11 +276,13 @@ class MaintainersDatabase:
 value: tuple:
 str: Board status (e.g. 'Active')
 str: List of maintainers, separated by :
+warnings (list of str): List of warnings due to missing status, etc.
 """
 
 def __init__(self):
 """Create an empty database."""
 self.database = {}
+self.warnings = []
 
 def get_status(self, target):
 """Return the status of the given board.
@@ -296,7 +298,7 @@ class MaintainersDatabase:
 str: 'Active', 'Orphan' or '-'.
 """
 if not target in self.database:
-print(f"WARNING: no status info for '{target}'", file=sys.stderr)
+self.warnings.append(f"WARNING: no status info for '{target}'")
 return '-'
 
 tmp = self.database[target][0]
@@ -306,7 +308,7 @@ class MaintainersDatabase:
 return 'Active'
 if tmp.startswith('Orphan'):
 return 'Orphan'
-print(f"WARNING: {tmp}: unknown status for '{target}'", 
file=sys.stderr)
+self.warnings.append(f"WARNING: {tmp}: unknown status for '{target}'")
 return '-'
 
 def get_maintainers(self, target):
@@ -320,7 +322,7 @@ class MaintainersDatabase:
 maintainers, they are separated with colons.
 """
 if not target in self.database:
-print(f"WARNING: no maintainers for '{target}'", file=sys.stderr)
+self.warnings.append(f"WARNING: no maintainers for '{target}'")
 return ''
 
 return ':'.join(self.database[target][1])
@@ -677,6 +679,9 @@ class Boards:
 
 Args:
 params_list (list of dict): A list of the board parameters
+
+Returns:
+list of str: List of warnings collected due to missing status, etc.
 """
 database = MaintainersDatabase()
 for (dirpath, _, filenames) in os.walk('.'):
@@ -688,6 +693,7 @@ class Boards:
 params['status'] = database.get_status(target)
 params['maintainers'] = database.get_maintainers(target)
 params_list[i] = params
+return database.warnings
 
 @classmethod
 def format_and_output(cls, params_list, output):
@@ -731,11 +737,17 @@ class Boards:
 jobs (int): The number of jobs to run simultaneously
 force (bool): Force to generate the output even if it is new
 quiet (bool): True to avoid printing a message if nothing needs 
doing
+
+Returns:
+bool: True if all is well, False if there were warnings
 """
 if not force and output_is_new(output):
 if not quiet:
 print(f'{output} is up to date. Nothing to do.')
-return
+return True
 params_list = self.scan_defconfigs(jobs)
-self.insert_maintainers_info(params_list)
+warnings = self.insert_maintainers_info(params_list)
+for warn in warnings:
+print(warn, file=sys.stderr)
 self.format_and_output(params_list, output)
+return not warnings
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 79ce2f6978a..0c75466fbd3 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -188,12 +188,12 @@ def DoBuildman(options, args, toolchains=None, 
make_func=None, brds=None,
 board_file = os.path.join(options.output_dir, 'boards.cfg')
 
 brds = boards.Boards()
-brds.ensure_board_list(board_file,
-   options.threads or multiprocessing.cpu_count(),
-   force=options.regen_board_list,
-   quiet=not options.verbose)
+ok = brds.ensure_board_list(board_file

[PATCH 15/19] gitlab/azure: Use buildman instead of genboardscfg

[Simon Glass]

Use the equivalent buildman functionality to check maintainer info.

Signed-off-by: Simon Glass 
---

 .azure-pipelines.yml | 2 +-
 .gitlab-ci.yml   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index bc2b437bd99..36ca3cb4626 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -140,7 +140,7 @@ stages:
   options: $(container_option)
 steps:
   - script: |
-  if [ `./tools/genboardscfg.py -f 2>&1 | wc -l` -ne 0 ]; then exit 1; 
fi
+  ./tools/buildman/buildman -R
 
   - job: tools_only
 displayName: 'Ensure host tools build'
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f9cd4175079..a516c5d4ee0 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -180,7 +180,7 @@ sloccount:
 Check for configs without MAINTAINERS entry:
   stage: testsuites
   script:
-- if [ `./tools/genboardscfg.py -f 2>&1 | wc -l` -ne 0 ]; then exit 1; fi
+- ./tools/buildman/buildman -R
 
 # Ensure host tools build
 Build tools-only:
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 16/19] Drop genboardscfg.py

[Simon Glass]

Now that buildman can generate this with the -R option, drop the script.

Signed-off-by: Simon Glass 
Suggested-by: Tom Rini 
---

 scripts/pylint.base   |   1 -
 tools/genboardscfg.py | 444 --
 2 files changed, 445 deletions(-)
 delete mode 100755 tools/genboardscfg.py

diff --git a/scripts/pylint.base b/scripts/pylint.base
index 9ebebf47ab9..dd6360e6256 100644
--- a/scripts/pylint.base
+++ b/scripts/pylint.base
@@ -201,7 +201,6 @@ tools_dtoc_test_fdt 6.88
 tools_dtoc_test_src_scan 9.43
 tools_efivar 6.71
 tools_endian-swap 9.29
-tools_genboardscfg 7.95
 tools_microcode-tool 7.25
 tools_moveconfig 8.34
 tools_patman___init__ 0.00
diff --git a/tools/genboardscfg.py b/tools/genboardscfg.py
deleted file mode 100755
index 07bf681d1d9..000
--- a/tools/genboardscfg.py
+++ /dev/null
@@ -1,444 +0,0 @@
-#!/usr/bin/env python3
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Author: Masahiro Yamada 
-#
-
-"""
-Converter from Kconfig and MAINTAINERS to a board database.
-
-Run 'tools/genboardscfg.py' to create a board database.
-
-Run 'tools/genboardscfg.py -h' for available options.
-"""
-
-import errno
-import fnmatch
-import glob
-import multiprocessing
-import optparse
-import os
-import sys
-import tempfile
-import time
-
-from buildman import kconfiglib
-
-### constant variables ###
-OUTPUT_FILE = 'boards.cfg'
-CONFIG_DIR = 'configs'
-SLEEP_TIME = 0.03
-COMMENT_BLOCK = '''#
-# List of boards
-#   Automatically generated by %s: don't edit
-#
-# Status, Arch, CPU, SoC, Vendor, Board, Target, Options, Maintainers
-
-''' % __file__
-
-### helper functions ###
-def try_remove(f):
-"""Remove a file ignoring 'No such file or directory' error."""
-try:
-os.remove(f)
-except OSError as exception:
-# Ignore 'No such file or directory' error
-if exception.errno != errno.ENOENT:
-raise
-
-def check_top_directory():
-"""Exit if we are not at the top of source directory."""
-for f in ('README', 'Licenses'):
-if not os.path.exists(f):
-sys.exit('Please run at the top of source directory.')
-
-def output_is_new(output):
-"""Check if the output file is up to date.
-
-Returns:
-  True if the given output file exists and is newer than any of
-  *_defconfig, MAINTAINERS and Kconfig*.  False otherwise.
-"""
-try:
-ctime = os.path.getctime(output)
-except OSError as exception:
-if exception.errno == errno.ENOENT:
-# return False on 'No such file or directory' error
-return False
-else:
-raise
-
-for (dirpath, dirnames, filenames) in os.walk(CONFIG_DIR):
-for filename in fnmatch.filter(filenames, '*_defconfig'):
-if fnmatch.fnmatch(filename, '.*'):
-continue
-filepath = os.path.join(dirpath, filename)
-if ctime < os.path.getctime(filepath):
-return False
-
-for (dirpath, dirnames, filenames) in os.walk('.'):
-for filename in filenames:
-if (fnmatch.fnmatch(filename, '*~') or
-not fnmatch.fnmatch(filename, 'Kconfig*') and
-not filename == 'MAINTAINERS'):
-continue
-filepath = os.path.join(dirpath, filename)
-if ctime < os.path.getctime(filepath):
-return False
-
-# Detect a board that has been removed since the current board database
-# was generated
-with open(output, encoding="utf-8") as f:
-for line in f:
-if line[0] == '#' or line == '\n':
-continue
-defconfig = line.split()[6] + '_defconfig'
-if not os.path.exists(os.path.join(CONFIG_DIR, defconfig)):
-return False
-
-return True
-
-### classes ###
-class KconfigScanner:
-
-"""Kconfig scanner."""
-
-### constant variable only used in this class ###
-_SYMBOL_TABLE = {
-'arch' : 'SYS_ARCH',
-'cpu' : 'SYS_CPU',
-'soc' : 'SYS_SOC',
-'vendor' : 'SYS_VENDOR',
-'board' : 'SYS_BOARD',
-'config' : 'SYS_CONFIG_NAME',
-'options' : 'SYS_EXTRA_OPTIONS'
-}
-
-def __init__(self):
-"""Scan all the Kconfig files and create a Kconfig object."""
-# Define environment variables referenced from Kconfig
-os.environ['srctree'] = os.getcwd()
-os.environ['UBOOTVERSION'] = 'dummy'
-os.environ['KCONFIG_OBJDIR'] = ''
-self._conf = kconfiglib.Kconfig(warn=False)
-
-def __del__(self):
-"""Delete a leftover temporary file before exit.
-
-The scan() method of this class creates a temporay file and deletes
-it on success.  If scan() method throws an exception on the way,
-the temporary file might be left over.  In that case, it should be
-deleted in this destructor.
-"""
-if hasattr(self, '_tmpfile') and self._tmpfile:
-try_remove(self._t

[PATCH 19/19] buildman: Drop a TODO that is done

[Simon Glass]

Buildman now uses worktrees when available, instead of doing a full clone.
This was done in this commit:

   76de29fc4f buildman: Use git worktrees instead of git clones when possible

Drop the TODO.

Signed-off-by: Simon Glass 
---

 tools/buildman/README | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/tools/buildman/README b/tools/buildman/README
index 3ba08d0dace..a8357a804b3 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -1331,9 +1331,6 @@ scope for more though, e.g.:
 - 'hunting' for problems, perhaps by building a few boards for each arch, or
   checking commits for changed files and building only boards which use those
   files
-- using the same git repo for all threads instead of cloning it. Currently
-  it uses about 500MB per thread, so on a 64-thread machine this is 32GB for
-  the build.
 
 
 Credits
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 18/19] buildman: Drop a Python 2.7 comment

[Simon Glass]

This is well out of date, but it is still reasonable to use a list. Drop
the comment.

Signed-off-by: Simon Glass 
---

 tools/buildman/boards.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index b30b344bc8e..8a0971aa407 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -371,7 +371,6 @@ class MaintainersDatabase:
 class Boards:
 """Manage a list of boards."""
 def __init__(self):
-# Use a simple list here, sinc OrderedDict requires Python 2.7
 self._boards = []
 
 def add_board(self, brd):
-- 
2.37.0.144.g8ac04bfd2-goog

Re: [RFC PATCH 3/3] eficonfig: add "Delete Key" menu entry

[Takahiro Akashi]

On Sun, Jul 10, 2022 at 12:10:13PM +0200, Heinrich Schuchardt wrote:
> On 6/19/22 07:20, Masahisa Kojima wrote:
> > This commit add the menu-driven interface to delete the
> > signature database entry.
> > EFI Signature Lists can contain the multiple signature
> > entries, this menu can delete the indivisual entry.
> > 
> > If the PK is enrolled and UEFI Secure Boot is in User Mode,
> 
> Why don't you mention Deployed Mode?
> 
> > user can not delete the existing signature lists since the
> > signature lists must be signed by KEK or PK but signing
> > information is not stored in the signature database.
> 
> Updating PK with an empty value must be possible if if the new value is
> signed with the old PK.
> 
> > 
> > Signed-off-by: Masahisa Kojima 
> > ---
> >   cmd/eficonfig_sbkey.c | 218 +-
> >   1 file changed, 217 insertions(+), 1 deletion(-)
> > 
> > diff --git a/cmd/eficonfig_sbkey.c b/cmd/eficonfig_sbkey.c
> > index 02ab8f8218..142bb4cef5 100644
> > --- a/cmd/eficonfig_sbkey.c
> > +++ b/cmd/eficonfig_sbkey.c
> > @@ -54,6 +54,29 @@ static const struct eficonfig_sigtype_to_str 
> > sigtype_to_str[] = {
> >   /*{EFI_CERT_SHA512_GUID,  "SHA512",   
> > SIG_TYPE_HASH}, */
> >   };
> > 
> 
> Please, add documentation to all functions.
> 
> > +static int eficonfig_console_yes_no(void)
> > +{
> > +   int esc = 0;
> > +   enum bootmenu_key key = KEY_NONE;
> > +
> > +   while (1) {
> > +   bootmenu_loop(NULL, &key, &esc);
> > +
> > +   switch (key) {
> > +   case KEY_SELECT:
> > +   return 1;
> > +   case KEY_QUIT:
> > +   return 0;
> > +   default:
> > +   break;
> > +   }
> > +   }
> > +
> > +   /* never happens */
> > +   debug("eficonfig: this should not happen");
> > +   return 0;
> 
> If this code is unreachable, remove it.
> 
> > +}
> > +
> >   static void eficonfig_console_wait_enter(void)
> >   {
> > int esc = 0;
> > @@ -72,7 +95,19 @@ static void eficonfig_console_wait_enter(void)
> > 
> > /* never happens */
> > debug("eficonfig: this should not happen");
> > -   return;
> 
> Please remove unreachable code.
> 
> > +}
> > +
> > +static bool is_setupmode(void)
> > +{
> > +   efi_status_t ret;
> > +   u8 setup_mode;
> > +   efi_uintn_t size;
> > +
> > +   size = sizeof(setup_mode);
> > +   ret = efi_get_variable_int(u"SetupMode", &efi_global_variable_guid,
> > +  NULL, &size, &setup_mode, NULL);
> > +
> > +   return setup_mode == 1;
> >   }
> > 
> >   static bool is_secureboot_enabled(void)
> > @@ -254,6 +289,103 @@ static efi_status_t 
> > eficonfig_process_sigdata_show(void *data)
> > return EFI_SUCCESS;
> >   }
> > 
> > +static efi_status_t eficonfig_process_sigdata_delete(void *data)
> > +{
> > +   int yes_no;
> > +   struct eficonfig_sig_data *sg = data;
> > +
> > +   display_sigdata_header(sg, "Delete");
> > +   display_sigdata_info(sg);
> > +
> > +   printf("\n\n  Press ENTER to delete, ESC/CTRL+C to quit");
> > +   yes_no = eficonfig_console_yes_no();
> > +   if (!yes_no)
> > +   return EFI_NOT_READY;
> > +
> > +   return EFI_SUCCESS;
> > +}
> > +
> > +static void delete_selected_signature_data(void *db, efi_uintn_t *db_size,
> > +  struct eficonfig_sig_data *target,
> > +  struct list_head *siglist_list)
> > +{
> > +   u8 *dest, *start;
> > +   struct list_head *pos, *n;
> > +   u32 remain;
> > +   u32 size = *db_size;
> > +   u8 *end = (u8 *)db + size;
> > +   struct eficonfig_sig_data *sg;
> > +
> > +   list_for_each_safe(pos, n, siglist_list) {
> > +   sg = list_entry(pos, struct eficonfig_sig_data, list);
> > +   if (sg->esl == target->esl && sg->esd == target->esd) {
> > +   remain = sg->esl->signature_list_size -
> > +(sizeof(struct efi_signature_list) -
> > +sg->esl->signature_header_size) -
> > +sg->esl->signature_size;
> > +   if (remain > 0) {
> > +   /* only delete the single signature data */
> > +   sg->esl->signature_list_size -= 
> > sg->esl->signature_size;
> > +   size -= sg->esl->signature_size;
> > +   dest = (u8 *)sg->esd;
> > +   start = (u8 *)sg->esd + sg->esl->signature_size;
> > +   } else {
> > +   /* delete entire signature list */
> > +   dest = (u8 *)sg->esl;
> > +   start = (u8 *)sg->esl + 
> > sg->esl->signature_list_size;
> > +   size -= sg->esl->signature_list_size;
> > +   }
> > +   memmove(dest, start, (end - start));
> > +   }
> > +   }
> > +
> > +   *db_size = size;
> > +}
> > +

Re: [PATCH v8 2/9] eficonfig: menu-driven addition of UEFI boot option

[Takahiro Akashi]

On Sun, Jul 10, 2022 at 11:03:43AM +0200, Heinrich Schuchardt wrote:
> On 6/19/22 06:56, Masahisa Kojima wrote:
> > This commit add the "eficonfig" command.
> > The "eficonfig" command implements the menu-driven UEFI boot option
> > maintenance feature. This commit implements the addition of
> > new boot option. User can select the block device volume having
> > efi_simple_file_system_protocol and select the file corresponding
> > to the Boot variable. User can also enter the description and
> > optional_data of the BOOT variable in utf8.
> > 
> > This commit adds "include/efi_config.h", it contains the common
> > definition to be used from other menus such as UEFI Secure Boot
> > key management.
> > 
> > Signed-off-by: Masahisa Kojima 
> > ---
> > Changes in v8:
> > - command name is change from "efimenu" to "eficonfig"
> > - function and struct prefixes is changed to "eficonfig"
> > - fix menu header string
> > 
> > Changes in v7:
> > - add "efimenu" command and uefi variable maintenance code
> >moved into cmd/efimenu.c
> > - create include/efimenu.h to define the common definition for
> >the other menu such as UEFI Secure Boot key management
> > - update boot option edit UI, user can select description, file,
> >and optional_data to edit in the same menu like following.
> > 
> >** Edit Boot Option **
> > 
> >   Description: debian
> >   File: virtio 0:1/EFI\debian\grubaa64.efi
> >   Optional Data: test
> >   Save
> >   Quit
> > 
> > - remove exit parameter from efimenu_process_common()
> > - menu title type is changed from u16 to char
> > - efimenu_process_common() add menu title string
> > - reduce printf/puts function call for displaying the menu
> > - efi_console_get_u16_string() accept 0 length to allow
> >optional_data is empty
> > - efi_console_get_u16_string() the "size" parameter name is changes to 
> > "count"
> > - efimenu is now designed to maintain the UEFI variables, remove autoboot 
> > related code
> > - remove one empty line before "Quit" entry
> > - efimenu_init() processes only the first time
> > 
> > Changes in v6:
> > - fix typos
> > - modify volume name to match U-Boot syntax
> > - compile in CONFIG_EFI_LOADER=n and CONFIG_CMD_BOOTEFI_BOOTMGR=n
> > - simplify u16_strncmp() usage
> > - support "a\b.efi" file path, use link list to handle filepath
> > - modify length check condition
> > - UEFI related menu items only appears with CONFIG_AUTOBOOT_MENU_SHOW=y
> > 
> > Changes in v5:
> > - remove forward declarations
> > - add const qualifier for menu items
> > - fix the possible unaligned access for directory info access
> > - split into three commit 1)add boot option 2) delete boot option 3)change 
> > boot order
> >This commit is 1)add boot option.
> > - fix file name buffer allocation size, it should be 
> > EFI_BOOTMENU_FILE_PATH_MAX * sizeof(u16)
> > - fix wrong size checking for file selection
> > 
> > Chanes in v4:
> > - UEFI boot option maintenance menu is integrated into bootmenu
> > - display the simplified volume name(e.g. usb0:1, nvme1:2) for the
> >volume selection
> > - instead of extending lib/efi_loader/efi_bootmgr.c, newly create
> >lib/efi_loader/efi_bootmenu_maintenance.c and implement boot
> >variable maintenance into it.
> > 
> > Changes in RFC v3:
> >   not included in v3 series
> > 
> > Changes in RFC v2:
> > - enable utf8 user input for boot option name
> > - create lib/efi_loader/efi_console.c::efi_console_get_u16_string() for
> >utf8 user input handling
> > - use u16_strlcat instead of u16_strcat
> > - remove the EFI_CALLs, and newly create or expose the following
> >xxx_int() functions.
> >  efi_locate_handle_buffer_int(), efi_open_volume_int(),
> >  efi_file_open_int(), efi_file_close_int(), efi_file_read_int() and
> >  efi_file_setpos_int().
> >Note that EFI_CALLs still exist for EFI_DEVICE_PATH_TO_TEXT_PROTOCOL
> >and EFI_SIMPLE_TEXT_INPUT/OUTPUT_PROTOCOL
> > - use efi_search_protocol() instead of calling locate_protocol() to get
> >the device_path_to_text_protocol interface.
> > - remove unnecessary puts(ANSI_CLEAR_LINE), this patch is still depends on
> >puts(ANSI_CLEAR_CONSOLE)
> > - skip SetVariable() if the bootorder is not changed
> > 
> >   cmd/Kconfig   |7 +
> >   cmd/Makefile  |1 +
> >   cmd/eficonfig.c   | 1270 +
> >   include/efi_config.h  |   91 +++
> >   include/efi_loader.h  |   40 ++
> >   lib/efi_loader/efi_boottime.c |   52 +-
> >   lib/efi_loader/efi_console.c  |   78 ++
> >   lib/efi_loader/efi_disk.c |   11 +
> >   lib/efi_loader/efi_file.c |   75 +-
> >   9 files changed, 1578 insertions(+), 47 deletions(-)
> >   create mode 100644 cmd/eficonfig.c
> >   create mode 100644 include/efi_config.h
> > 
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 09193b61b9..bb7f1d0463 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -18

Re: [PATCH] rockchip: rk3399: boot_devices: fix eMMC node name

[Art Nikpal]

Yes ! need to apply this patch

dts was changed

grep @fe33 arch/arm/dts/*.dtsi
arch/arm/dts/rk3399.dtsi:sdhci: mmc@fe33 {

same need to change  boot_devices in rk3399.c to /mmc@fe32

Reviewed-by: Artem Lapkin  
Tested-by: Artem Lapkin  

On Tue, Jul 12, 2022 at 2:22 AM Xavier Drudis Ferran  wrote:
>
> El Mon, Jul 11, 2022 at 04:15:33PM +0200, Quentin Schulz deia:
> > From: Quentin Schulz 
> >
> > When idbloader.img is flashed on the eMMC, the SPL still tries to load
> > from SPI-NOR first.
> >
> > This is due to an incorrect look-up in the Device Tree. Since commit
> > 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
> > node name (but not label) changed from sdhci@fe33 to mmc@fe33
> > meaning U-Boot SPL is not looking for the correct node name anymore and
> > fails to find the "same-as-spl" node when eMMC is the medium from which
> > the SPL booted.
> >
>
> Yes, I also saw that. I changed and tested it at some time, but since there
> were other changes, I hesitate to send a Tested by for your patch. FWIW:
>
> Reviewed-by: Xavier Drudis Ferran 
>
>
> > Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
> > Cc: Quentin Schulz 
> > Signed-off-by: Quentin Schulz 
> > ---
> >
> > Sorry for resend, was not yet subscribed.
> >
> >  arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> > b/arch/arm/mach-rockchip/rk3399/rk3399.c
> > index 01a05599cd..de11a3fa30 100644
> > --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> > +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> > @@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >  #define GRF_BASE 0xff77
> >
> >  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> > - [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
> > + [BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
> >   [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
> >   [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
> >  };
> > @@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
> >   const char *ofpath;
> >   } spl_boot_devices_tbl[] = {
> >   { BOOT_DEVICE_MMC1, "/mmc@fe32" },
> > - { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
> > + { BOOT_DEVICE_MMC2, "/mmc@fe33" },
> >   { BOOT_DEVICE_SPI, "/spi@ff1d" },
>
> Not related to this patch, but I also changed "/spi@ff1d" -> 
> "/spi@ff1d/flash@0".
> Not sure whether it needs to be different in both arrays in some case for 
> some reason.
>
> >   };
> >
> > --
> > 2.36.1
> >

Re: [TF-A] [RFC] Proposed location to host the firmware handoff specification.

[Julius Werner]

> That draft is the DEN0135 document [2].
> I realise that I haven’t made it sufficiently explicit in this thread that 
> the DEN0135 document [2] is still at draft quality (see ALP maturity called 
> out in the title page and footers).
> Please do not consider this a finished document 😊. We’ve been iterating on 
> this pdf as we gather feedback from the open-source communities.
> It's becoming clear that we need to move this debate to a more suitable forum.
> That’s why we’re proposing, in this thread, to move the document to 
> trustedfirmware.org.

Understood. FWIW, I totally support hosting this on TF.org, I think
that makes sense considering that it has good co-development
infrastructure that is open to everyone (e.g. Gerrit) already set up
and that it's easy to administer for you guys who are currently
organizing this. I don't really see Simon's concern regarding "captive
to one project" -- this whole spec is an attempt to cooperate better,
not work against each other, so there shouldn't need to be fights
about who "owns" it (just pick a place with good infrastructure and
let everyone access it there). If perhaps the real concern is rather
related to who controls future spec updates, tag assignments, etc.
then I think we should address those directly and define clear
processes that we can all feel comfortable with, rather than implying
that the final word on these is left to whoever controls the hosting
platform.

> The requirement originated in feedback from the u-boot community, please see 
> [3].
> The argument for 16-byte alignment is that some data-structures have to be 
> 16-byte aligned.
> We ought to meet that requirement if we ever want to carry those structures.

I still really think that this is wasting space to the point where it
defeats the purpose of this being a "lightweight" data handoff
structure. Consider that all of the bl_aux_params tags in TF-A (which
I described as one of the existing mechanisms for this kind of thing
in last year's thread) are 8 bytes or less, which means that for these
use cases the transfer list would have over 3 times as much overhead
as actual data. There seems to be some disconnect here since the
stated idea for this is to be a lightweight handoff mechanism to pass
individual pieces of information directly, yet all the initially
proposed tags are just for wrapping large existing hand off blobs that
bundle lot of information in their own structures (giving it a very
xkcd.com/927-like feel), and the spec design seems to be tuned toward
the latter use cases.

If individual tags have special alignment requirements, they could
just deal with that internally (by including another offset field in
the "data" part) without dragging every other tag in the structure
down with them. Alternatively, if you really want to keep this I think
an acceptable compromise could be to keep the 16-byte entry alignment
but reduce the transfer entry header size to 8 bytes, and then allow
tags that don't require 16 byte data alignment to immediately use the
following 8 bytes for data. That way, entries with 8 bytes or less of
data could fit both header and data into a single 16 byte block which
drastically cuts down on overhead for small data.

> > 2. The table entry header seems unnecessarily large. What's the point of
> > including a "header length" field when that field will always contain a 16?
>
> The "header length" enables the table entry header to be extended if we ever 
> need that in the future.
> Changes to the TE header are backwards compatible.
> A consumer obtains the address of the data by adding the "header length" to 
> the entry's base address.

I really don't see this as likely enough to be worth paying that big
upfront cost of making the whole structure so much less efficient to
start with. I think 8 bytes are already the most you'd reasonably want
to pay for header overhead, I find it highly improbable that we'd want
to introduce more fields later to make that even bigger. If there's
desire for optional large annotations (e.g. per-entry cryptographic
hashes) in the future, I'd rather suggest implementing that as
"companion entries" with special tags that are written right behind
the entry they refer to, rather than try squeezing it all into a
single header structure. If you want to leave some room for simple bit
flags, I would suggest masking out the high byte of the data length
field instead (i.e. splitting it into 3 and 1) -- it doesn't seem like
anyone would want to pass a data item larger than 32 MB in a firmware
information structure anyway.

> The TL header version is incremented when we do a new release of the document.
> At a new document release, we can introduce one or more new standard tags and 
> also append fields to the TL header.

FWIW I would suggest decoupling the data structure version from the
document version and only increasing the data structure version when
the actual structure changes in a meaningful way. Documents may be
amended to improv

Re: [PATCH v2 8/9] clocks: qcom: Add clock driver for QCS404 SoC

[Sumit Garg]

Hi Ramon,

Thanks for your review.

On Mon, 11 Jul 2022 at 20:08, Ramon Fried  wrote:
>
> On Fri, Jul 8, 2022 at 4:14 PM Sumit Garg  wrote:
> >
> > Currently its a dummy clock driver as clocks for UART and eMMC have been
> > already enabled by ABL. Along with this import "qcom,gcc-qcs404.h" header
> > from Linux mainline to support DT bindings.
> I think it's better to initialize the clocks also here, this will
> allow the u-boot to be used
> instead of ABL.

Actually, ABL is just an EFI application that is dependent on the EFI
API exposed from XBL which is essentially an edk2 based
implementation. The XBL source code is proprietary and its a signed
locked down bootloader which isn't replaceable. Although it may be
possible to run u-boot as an EFI application in the future then it
could be a replacement for ABL but still for driver backends it will
rely on XBL exposed EFI API.

> If it's a simple clock configuration, it's not a
> problem to re-init it after ABL already did.

Yeah it's simple enough configuration to be done but earlier I was
looking for a use-case. So nevertheless it's better for clarity at
least that we aren't relying on a blackbox implementation underneath.
I will add it in the next version.

-Sumit

Re: [PATCH v2 0/9] New boards support: db845c and qcs404-evb

[Sumit Garg]

Hi Peng,

On Tue, 12 Jul 2022 at 06:27, Peng Fan  wrote:
>
>
>
> On 7/8/2022 9:13 PM, Sumit Garg wrote:
> > Add support for two new boards db845c and qcs404-evb:
> > - db845c is a 96boards compliant platform aka RB3 based on Qualcomm
> >SDM845 SoC.
> > - qcs404-evb is an evaluation board from Qualcomm based on QCS404 SoC.
> >
> > Both these platforms have one thing in common that u-boot is chain-loaded
> > in 64-bit mode via Android Boot Loader (ABL) which is an EFI application.
> > For further details on chain-loading refer to platform specific
>
> Just curious about the flow:
> ABL(an EFI applicaiton)->load U-Boot->start U-Boot? or you mean U-Boot
> run as EFI application?
>

Here you can think of u-boot as just a replacement of the kernel image
within the boot.img. U-boot already has a provision for
LINUX_KERNEL_IMAGE_HEADER [1] which makes it look like a kernel image.
Boot chain:

XBL (edk2 proprietary source code) -> ABL(an EFI applicaiton) ->
U-boot (part of boot.img as a replacement of kernel) -> FIT image
(part of boot.img as a replacement of ramdisk)

Also, the final stage is configurable as u-boot allows interactions
with various media (eMMC, USB (WIP), network (WIP) etc.)

[1] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/Kconfig#L82

-Sumit

> THanks,
> Peng.
>
> > documentation:
> > - doc/board/qualcomm/sdm845.rst
> > - doc/board/qualcomm/qcs404.rst
> >
> > Changes in v2:
> > - Added patch #1 to fix DT node overrides in starqltechn-uboot.dtsi.
> > - Updated patch #2 commit description.
> > - Fixed a typo (s/96Board/96Boards/) in patch #5.
> >
> > Sumit Garg (9):
> >board: starqltechn: Align DT node overrides with sdm845.dtsi
> >arm64: dts: sdm845: Remove redundant u-boot DT properties
> >clocks: sdm845: Import qcom,gcc-sdm845.h
> >uart: sdm845: Fix debug UART pinmux
> >board: qualcomm: Add support for dragonboard845c
> >mmc: msm_sdhci: Add SDCC version 5.0.0 support
> >pinctrl: qcom: Add pinctrl driver for QCS404 SoC
> >clocks: qcom: Add clock driver for QCS404 SoC
> >board: qualcomm: Add support for QCS404 EVB
> >
> >   arch/arm/dts/Makefile |   1 +
> >   arch/arm/dts/dragonboard845c-uboot.dtsi   |  37 +++
> >   arch/arm/dts/dragonboard845c.dts  |  44 
> >   arch/arm/dts/qcs404-evb-uboot.dtsi|  24 ++
> >   arch/arm/dts/qcs404-evb.dts   |  81 ++
> >   arch/arm/dts/sdm845.dtsi  |   8 +-
> >   arch/arm/dts/starqltechn-uboot.dtsi   |  18 +-
> >   arch/arm/dts/starqltechn.dts  |   2 +-
> >   arch/arm/mach-snapdragon/Kconfig  |  25 ++
> >   arch/arm/mach-snapdragon/Makefile |   3 +
> >   arch/arm/mach-snapdragon/clock-qcs404.c   |  30 +++
> >   arch/arm/mach-snapdragon/clock-sdm845.c   |   3 +-
> >   arch/arm/mach-snapdragon/clock-snapdragon.c   |   1 +
> >   .../include/mach/sysmap-qcs404.h  |  13 +
> >   arch/arm/mach-snapdragon/pinctrl-qcs404.c |  55 
> >   arch/arm/mach-snapdragon/pinctrl-snapdragon.c |   1 +
> >   arch/arm/mach-snapdragon/pinctrl-snapdragon.h |   1 +
> >   arch/arm/mach-snapdragon/sysmap-qcs404.c  |  31 +++
> >   board/qualcomm/dragonboard845c/Kconfig|  12 +
> >   board/qualcomm/dragonboard845c/MAINTAINERS|   6 +
> >   board/qualcomm/dragonboard845c/Makefile   |   9 +
> >   board/qualcomm/dragonboard845c/db845c.its |  63 +
> >   .../dragonboard845c/dragonboard845c.c |   9 +
> >   board/qualcomm/qcs404-evb/Kconfig |  15 ++
> >   board/qualcomm/qcs404-evb/MAINTAINERS |   6 +
> >   board/qualcomm/qcs404-evb/Makefile|   6 +
> >   board/qualcomm/qcs404-evb/qcs404-evb.c|  33 +++
> >   board/qualcomm/qcs404-evb/qcs404-evb.its  |  64 +
> >   configs/dragonboard845c_defconfig |  28 ++
> >   configs/qcs404evb_defconfig   |  39 +++
> >   doc/board/qualcomm/index.rst  |   1 +
> >   doc/board/qualcomm/qcs404.rst |  79 ++
> >   doc/board/qualcomm/sdm845.rst | 100 ++-
> >   drivers/mmc/msm_sdhci.c   |  96 ---
> >   include/configs/dragonboard845c.h |  28 ++
> >   include/configs/qcs404-evb.h  |  27 ++
> >   include/dt-bindings/clock/qcom,gcc-qcs404.h   | 180 +
> >   include/dt-bindings/clock/qcom,gcc-sdm845.h   | 246 ++
> >   38 files changed, 1363 insertions(+), 62 deletions(-)
> >   create mode 100644 arch/arm/dts/dragonboard845c-uboot.dtsi
> >   create mode 100644 arch/arm/dts/dragonboard845c.dts
> >   create mode 100644 arch/arm/dts/qcs404-evb-uboot.dtsi
> >   create mode 100644 arch/arm/dts/qcs404-evb.dts
> >   create mode 100644 arch/arm/mach-snapdragon/clock-qcs404.c
> >   create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-qcs404.h
> >   create mode 100644 arch/arm/mach-snapdragon/pinctrl-qcs404.c
> >   cre

Re: [PATCH v8 2/9] eficonfig: menu-driven addition of UEFI boot option

[Heinrich Schuchardt]

On 7/12/22 03:55, Takahiro Akashi wrote:

On Sun, Jul 10, 2022 at 11:03:43AM +0200, Heinrich Schuchardt wrote:

On 6/19/22 06:56, Masahisa Kojima wrote:

This commit add the "eficonfig" command.
The "eficonfig" command implements the menu-driven UEFI boot option
maintenance feature. This commit implements the addition of
new boot option. User can select the block device volume having
efi_simple_file_system_protocol and select the file corresponding
to the Boot variable. User can also enter the description and
optional_data of the BOOT variable in utf8.

This commit adds "include/efi_config.h", it contains the common
definition to be used from other menus such as UEFI Secure Boot
key management.

Signed-off-by: Masahisa Kojima 
---
Changes in v8:
- command name is change from "efimenu" to "eficonfig"
- function and struct prefixes is changed to "eficonfig"
- fix menu header string

Changes in v7:
- add "efimenu" command and uefi variable maintenance code
moved into cmd/efimenu.c
- create include/efimenu.h to define the common definition for
the other menu such as UEFI Secure Boot key management
- update boot option edit UI, user can select description, file,
and optional_data to edit in the same menu like following.

** Edit Boot Option **

   Description: debian
   File: virtio 0:1/EFI\debian\grubaa64.efi
   Optional Data: test
   Save
   Quit

- remove exit parameter from efimenu_process_common()
- menu title type is changed from u16 to char
- efimenu_process_common() add menu title string
- reduce printf/puts function call for displaying the menu
- efi_console_get_u16_string() accept 0 length to allow
optional_data is empty
- efi_console_get_u16_string() the "size" parameter name is changes to "count"
- efimenu is now designed to maintain the UEFI variables, remove autoboot 
related code
- remove one empty line before "Quit" entry
- efimenu_init() processes only the first time

Changes in v6:
- fix typos
- modify volume name to match U-Boot syntax
- compile in CONFIG_EFI_LOADER=n and CONFIG_CMD_BOOTEFI_BOOTMGR=n
- simplify u16_strncmp() usage
- support "a\b.efi" file path, use link list to handle filepath
- modify length check condition
- UEFI related menu items only appears with CONFIG_AUTOBOOT_MENU_SHOW=y

Changes in v5:
- remove forward declarations
- add const qualifier for menu items
- fix the possible unaligned access for directory info access
- split into three commit 1)add boot option 2) delete boot option 3)change boot 
order
This commit is 1)add boot option.
- fix file name buffer allocation size, it should be EFI_BOOTMENU_FILE_PATH_MAX 
* sizeof(u16)
- fix wrong size checking for file selection

Chanes in v4:
- UEFI boot option maintenance menu is integrated into bootmenu
- display the simplified volume name(e.g. usb0:1, nvme1:2) for the
volume selection
- instead of extending lib/efi_loader/efi_bootmgr.c, newly create
lib/efi_loader/efi_bootmenu_maintenance.c and implement boot
variable maintenance into it.

Changes in RFC v3:
   not included in v3 series

Changes in RFC v2:
- enable utf8 user input for boot option name
- create lib/efi_loader/efi_console.c::efi_console_get_u16_string() for
utf8 user input handling
- use u16_strlcat instead of u16_strcat
- remove the EFI_CALLs, and newly create or expose the following
xxx_int() functions.
  efi_locate_handle_buffer_int(), efi_open_volume_int(),
  efi_file_open_int(), efi_file_close_int(), efi_file_read_int() and
  efi_file_setpos_int().
Note that EFI_CALLs still exist for EFI_DEVICE_PATH_TO_TEXT_PROTOCOL
and EFI_SIMPLE_TEXT_INPUT/OUTPUT_PROTOCOL
- use efi_search_protocol() instead of calling locate_protocol() to get
the device_path_to_text_protocol interface.
- remove unnecessary puts(ANSI_CLEAR_LINE), this patch is still depends on
puts(ANSI_CLEAR_CONSOLE)
- skip SetVariable() if the bootorder is not changed

   cmd/Kconfig   |7 +
   cmd/Makefile  |1 +
   cmd/eficonfig.c   | 1270 +
   include/efi_config.h  |   91 +++
   include/efi_loader.h  |   40 ++
   lib/efi_loader/efi_boottime.c |   52 +-
   lib/efi_loader/efi_console.c  |   78 ++
   lib/efi_loader/efi_disk.c |   11 +
   lib/efi_loader/efi_file.c |   75 +-
   9 files changed, 1578 insertions(+), 47 deletions(-)
   create mode 100644 cmd/eficonfig.c
   create mode 100644 include/efi_config.h

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 09193b61b9..bb7f1d0463 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1870,6 +1870,13 @@ config CMD_EFIDEBUG
  particularly for managing boot parameters as  well as examining
  various EFI status for debugging.

+config CMD_EFICONFIG
+   bool "eficonfig - provide menu-driven uefi variables maintenance 
interface"
+   depends on CMD_BOOTEFI_BOOTMGR
+   help
+ Enable the 'eficonfig' command which provides the menu-dr