Re: [PATCH v5 3/3] sysboot: add zboot support to boot x86 Linux kernel image

2021-02-02 Thread Bin Meng
On Tue, Feb 2, 2021 at 11:42 PM Kory Maincent  wrote:
>
> Add "zboot" command to the list of supported boot in the label_boot
> function.
>
> Signed-off-by: Kory Maincent 
> Reviewed-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Change since v1:
>  - Modify comment.
>
> Change since v2:
>  - Update do_zboot to do_zboot_parent function to follow the patch:
>5588e776b0
>
> Change since v3:
>  - Follow review from Simon Glass
>  - Add clean-up paches
>
> Change since v4:
>  - Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
>
>  cmd/pxe_utils.c   | 3 +++
>  include/command.h | 3 +++
>  2 files changed, 6 insertions(+)
>

applied to u-boot-x86, thanks!


Re: [PATCH v5 2/3] pxe_utils: clean-up, replace ifdef by IS_ENABLED

2021-02-02 Thread Bin Meng
On Tue, Feb 2, 2021 at 11:42 PM Kory Maincent  wrote:
>
> Replace all the macro ifdef by IS_ENABLED.
> All of these configs are set in the defconfig files and not in the
> include board headers files.
>
> Signed-off-by: Kory Maincent 
> ---
>
> Change since v4:
> - Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible
>
>  cmd/pxe_utils.c | 52 -
>  1 file changed, 25 insertions(+), 27 deletions(-)
>

applied to u-boot-x86, thanks!


Re: [PATCH v5 1/3] command.h: Clean-up patch, remove extern from the header

2021-02-02 Thread Bin Meng
On Tue, Feb 2, 2021 at 11:42 PM Kory Maincent  wrote:
>
> Remove the extern of the header because they are useless.
>
> Signed-off-by: Kory Maincent 
> Reviewed-by: Bin Meng 
> ---
>  include/command.h | 56 +++
>  1 file changed, 28 insertions(+), 28 deletions(-)
>

applied to u-boot-x86, thanks!


Re: [PATCH v5 01/20] mmc: sdhci: Add helper functions for UHS modes

2021-02-02 Thread Aswath Govindraju
On 03/02/21 11:36 am, Aswath Govindraju wrote:
> Hi Jaehoon,
> 
> On 02/02/21 3:40 am, Jaehoon Chung wrote:
>> Hi Aswath,
>>
>> On 1/29/21 11:47 PM, Aswath Govindraju wrote:
>>> From: Faiz Abbas 
>>>
>>> Add a set_voltage() function which handles the switch from 3.3V to 1.8V
>>> for SD card UHS modes.
>>>
>>> Signed-off-by: Faiz Abbas 
>>> Signed-off-by: Aswath Govindraju 
>>> ---
>>>  drivers/mmc/sdhci.c | 73 +
>>>  include/sdhci.h | 10 +++
>>>  2 files changed, 83 insertions(+)
>>>
>>> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
>>> index 06289343124e..276b6a08e571 100644
>>> --- a/drivers/mmc/sdhci.c
>>> +++ b/drivers/mmc/sdhci.c
>>> @@ -20,6 +20,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  static void sdhci_reset(struct sdhci_host *host, u8 mask)
>>>  {
>>> @@ -509,6 +510,78 @@ void sdhci_set_uhs_timing(struct sdhci_host *host)
>>> sdhci_writew(host, reg, SDHCI_HOST_CONTROL2);
>>>  }
>>>  
>>> +static void sdhci_set_voltage(struct sdhci_host *host)
>>> +{
>>> +   if (IS_ENABLED(CONFIG_MMC_IO_VOLTAGE)) {
>>> +   struct mmc *mmc = (struct mmc *)host->mmc;
>>> +   u32 ctrl;
>>> +
>>> +   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>>> +
>>> +   switch (mmc->signal_voltage) {
>>> +   case MMC_SIGNAL_VOLTAGE_330:
>>> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>>> +   if (mmc->vqmmc_supply) {
>>> +   if 
>>> (regulator_set_enable_if_allowed(mmc->vqmmc_supply, false)) {
>>> +   pr_err("failed to disable 
>>> vqmmc-supply\n");
>>> +   return;
>>> +   }
>>> +
>>> +   if (regulator_set_value(mmc->vqmmc_supply, 
>>> 330)) {
>>> +   pr_err("failed to set vqmmc-voltage to 
>>> 3.3V\n");
>>> +   return;
>>> +   }
>>> +
>>> +   if 
>>> (regulator_set_enable_if_allowed(mmc->vqmmc_supply, true)) {
>>> +   pr_err("failed to enable 
>>> vqmmc-supply\n");
>>> +   return;
>>> +   }
>>> +   }
>>> +#endif
>>> +   /* 3.3V regulator output should be stable within 5 ms */
>>> +   mdelay(5);
>>> +   if (IS_SD(mmc)) {
>>> +   ctrl &= ~SDHCI_CTRL_VDD_180;
>>> +   sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
>>> +   }
>>
>> According to Specification, after Signal bit was changed to 0 from 1, it 
>> needs to wait for stable within 5ms.
>> Isn't it right that mdelay(5) locates at here?
>>
> 
> I searched the spec for this and found the following line in it,
> 
> ```
> If this status is not supported, Host Driver should take more than 5ms for
> stable time of host voltage regulator from changing 1.8V Signaling
> Enable. Specific Host Driver may use a specific time, which is provided by
> Host System, instead of using 5ms.
> 
> ```
> 
> This is from the row of "Host Regulator Voltage Stable" in table
> describing "Present state register", "PartA2_SD
> Host_Controller_Simplified_Specification_Ver4.20" document, page 66.
> 
> The status mentioned is about host regulator voltage stable. Yes I can
> see that it has been mentioned that host driver has to wait for 5ms
> after changing the 1.8V signal enable bit. In that case I suppose the
> same has to be done at [1] as well right ?
> 
> 
> 
>>> +   break;
>>> +   case MMC_SIGNAL_VOLTAGE_180:
>>> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>>> +   if (mmc->vqmmc_supply) {
>>> +   if 
>>> (regulator_set_enable_if_allowed(mmc->vqmmc_supply, false)) {
>>> +   pr_err("failed to disable 
>>> vqmmc-supply\n");
>>> +   return;
>>> +   }
>>> +
>>> +   if (regulator_set_value(mmc->vqmmc_supply, 
>>> 180)) {
>>> +   pr_err("failed to set vqmmc-voltage to 
>>> 1.8V\n");
>>> +   return;
>>> +   }
>>> +
>>> +   if 
>>> (regulator_set_enable_if_allowed(mmc->vqmmc_supply, true)) {
>>> +   pr_err("failed to enable 
>>> vqmmc-supply\n");
>>> +   return;
>>> +   }
>>> +   }
>>> +#endif
>>> +   if (IS_SD(mmc)) {
>>> +   ctrl |= SDHCI_CTRL_VDD_180;
>>> +   sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
>>> +   }
> 
> [1]
> 
> For reference, I have also attached the page from where the above line
> was taken.
> 

If there was a problem access

Re: [PATCH v3 1/1] env: sf: single function env_sf_save()

2021-02-02 Thread Stefan Roese

On 02.02.21 18:09, Harry Waschkeit wrote:

On 02.02.21 15:54, Stefan Roese wrote:

On 02.02.21 15:43, Harry Waschkeit wrote:


On 02.02.21 10:30, Stefan Roese wrote:

On 02.02.21 09:21, Harry Waschkeit wrote:

Instead of implementing redundant environments in two very similar
functions env_sf_save(), handle redundancy in one function, placing 
the
few differences in appropriate pre-compiler sections depending on 
config

option CONFIG_ENV_OFFSET_REDUND.

Additionally, several checkpatch complaints were addressed.

This patch is in preparation for adding support for env erase.

Signed-off-by: Harry Waschkeit 
Reviewed-by: Stefan Roese 
---
Change in v3:
  - no change in patch, only added "reviewed-by" to commit log


JFYI:
No need to re-send this patch with this added RB tag, as I already did
send a new RB to the last mail as reply. Patchwork collects these tags
when sent to the list. So you only need to include them, if you send
a new patch version.


thanks for this hint, obviously I step into it all the time ...

Ok, lesson learnt, let's see what I can do wrong next time ... ;-/

Back on topic: I guess that was all I needed to do so that the patch 
will get merged when its time comes.


Yes, now we (you) need a bit of patience, so that other people might
review this patch as well. And usually it will get handled after some
time (depending on the development stage of U-Boot, merge window open
or shortly before release etc).


Ok, no problem with that.

That also means that I should wait with submission of the other patch 
(adding "env erase" support) until this one is merged.

Otherwise the patch would need to be significantly different ...


No, you don't have to wait. This would be counter-productive. Please
just add the dependancy to this patch in the commit text of the new
one to make this clear. Best would be below the "---" line so that
it will not be included in the git history.

Hmm, I guess it would have been better to not send that patch standalone 
but instead as a first one in a two-patch series where the second one 
adds the new functionality on top of the clean-up.

Anyway, something to keep in mind for next time :-)


Yep, that would have been even better. ;)

Thanks,
Stefan


It does not hurt of course to check this from time to time and
"trigger" the maintainer of the subsystem or the custodian this
patch is delegated to nothing is happening here for a too long
time (like more than 1 month).


Alright, good to know :-)

Thanks,
Harry


Thanks,
Stefan


If not, please let me know.

Thanks,
Harry


Thanks,
Stefan


Change in v2:
  - remove one more #ifdef, instead take advantage of compiler 
attribute

    __maybe_unused for one variable used only in case of redundant
    environments

  env/sf.c | 130 
++-

  1 file changed, 41 insertions(+), 89 deletions(-)

diff --git a/env/sf.c b/env/sf.c
index 937778aa37..199114fd3b 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -66,13 +66,14 @@ static int setup_flash_device(void)
  return 0;
  }
-#if defined(CONFIG_ENV_OFFSET_REDUND)
  static int env_sf_save(void)
  {
  env_t    env_new;
-    char    *saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
+    char    *saved_buffer = NULL;
  u32    saved_size, saved_offset, sector;
+    ulong    offset;
  int    ret;
+    __maybe_unused char flag = ENV_REDUND_OBSOLETE;
  ret = setup_flash_device();
  if (ret)
@@ -81,27 +82,33 @@ static int env_sf_save(void)
  ret = env_export(&env_new);
  if (ret)
  return -EIO;
-    env_new.flags    = ENV_REDUND_ACTIVE;
-    if (gd->env_valid == ENV_VALID) {
-    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
-    env_offset = CONFIG_ENV_OFFSET;
-    } else {
-    env_new_offset = CONFIG_ENV_OFFSET;
-    env_offset = CONFIG_ENV_OFFSET_REDUND;
-    }
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+    env_new.flags    = ENV_REDUND_ACTIVE;
+
+    if (gd->env_valid == ENV_VALID) {
+    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+    env_offset = CONFIG_ENV_OFFSET;
+    } else {
+    env_new_offset = CONFIG_ENV_OFFSET;
+    env_offset = CONFIG_ENV_OFFSET_REDUND;
+    }
+    offset = env_new_offset;
+#else
+    offset = CONFIG_ENV_OFFSET;
+#endif
  /* Is the sector larger than the env (i.e. embedded) */
  if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
  saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
-    saved_offset = env_new_offset + CONFIG_ENV_SIZE;
+    saved_offset = offset + CONFIG_ENV_SIZE;
  saved_buffer = memalign(ARCH_DMA_MINALIGN, saved_size);
  if (!saved_buffer) {
  ret = -ENOMEM;
  goto done;
  }
-    ret = spi_flash_read(env_flash, saved_offset,
-    saved_size, saved_buffer);
+    ret = spi_flash_read(env_flash, saved_offset, saved_size,
+ saved_buffer);
  if (ret)
  

Re: [PATCH] tools: Remove #include

2021-02-02 Thread Pali Rohár
On Monday 01 February 2021 16:20:18 Tom Rini wrote:
> On Wed, Jan 27, 2021 at 04:34:24PM +0100, Pali Rohár wrote:
> 
> > Header file version.h includes also autogenerated file timestamp.h which
> > is recompiled on every time when SOURCE_DATE_EPOCH change.
> > 
> > Tools do not use build time therefore they do not have to include
> > timestamp.h file.
> > 
> > This change prevents recompiling tools every time when SOURCE_DATE_EPOCH
> > changes.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> >  tools/dumpimage.c  | 2 +-
> >  tools/mkenvimage.c | 2 +-
> >  tools/mkimage.c| 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/dumpimage.c b/tools/dumpimage.c
> > index e5481435a7..54c2517c9e 100644
> > --- a/tools/dumpimage.c
> > +++ b/tools/dumpimage.c
> > @@ -7,7 +7,7 @@
> >  
> >  #include "dumpimage.h"
> >  #include 
> > -#include 
> > +#include "generated/version_autogenerated.h"
> >  
> >  static void usage(void);
> >  
> 
> I don't know if I really like this approach.  It also seems inconsistent
> as we have for example tools/fit-image.c that has content from
> generated/version_autogenerated.h but wasn't changed by this patch (nor
> the rest of the series).
> 
> I think a bit more invasive approach is required here.  I like the
>  approach you used elsewhere, and as best I can see,
> the only place U_BOOT_VERSION_STRING, which is where we have the
> timestamp itself, is used is cmd/version.c (and defined in version.h).
> We should isolate the file that has the date such that it's only
> in one file and referenced in one file.  This means probably removing
> the version_string global from arch/{powerpc,m68k} and dropping __weak
> from cmd/version.c and seeing what happens, as well.
> 
> Do you see where I'm thinking with this, or do I need to try and explain
> a bit more?  Thanks!

Hello Tom! I think I understood what you mean. I would need to look at
all places where version strings and timestamps in any forms are used as
this approach would need some other cleanup...

> 
> -- 
> Tom




Re: [PATCH u-boot-marvell] mmc: mv_sdhci: call mmc_of_parse()

2021-02-02 Thread Jaehoon Chung
On 2/3/21 2:37 AM, Marek Behún wrote:
> This is needed to parse more capabilities such as `non-removable`.
> 
> Commit da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect") caused
> a regression on Turris Omnia, because mv_sdhci driver did not fill out
> host_caps from device-tree.
> 
> Signed-off-by: Marek Behún 
> Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")

I don't think that this patch is for fixing its commit.

Best Regards,
Jaehoon Chung

> Cc: p...@kernel.org
> Cc: Baruch Siach 
> Cc: Stefan Roese 
> ---
>  drivers/mmc/mv_sdhci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 556dd38046..4dc4a0d2be 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -118,6 +118,10 @@ static int mv_sdhci_probe(struct udevice *dev)
>   host->mmc->dev = dev;
>   host->mmc->priv = host;
>  
> + ret = mmc_of_parse(dev, &plat->cfg);
> + if (ret)
> + return ret;
> +
>   ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
>   if (ret)
>   return ret;
> 



[PATCH v2 1/1] sandbox: host bind must close file descriptor

2021-02-02 Thread Heinrich Schuchardt
Each invocation of the 'host bind' command with a file name argument opens
a file descriptor. The next invocation of the 'host bind' command destroys
the block device but the file descriptor remains open. The same holds true
for the 'unbind blk' command.

Close the file descriptor when unbinding the host block device.

Signed-off-by: Heinrich Schuchardt 
---
v2:
remove superfluous data checking
---
 drivers/block/sandbox.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/block/sandbox.c b/drivers/block/sandbox.c
index f57f690d3c..ac20ff6493 100644
--- a/drivers/block/sandbox.c
+++ b/drivers/block/sandbox.c
@@ -230,6 +230,18 @@ int host_get_dev_err(int devnum, struct blk_desc 
**blk_devp)
 }

 #ifdef CONFIG_BLK
+
+int sandbox_host_unbind(struct udevice *dev)
+{
+   struct host_block_dev *host_dev;
+
+   /* Data validity is checked in host_dev_bind() */
+   host_dev = dev_get_plat(dev);
+   os_close(host_dev->fd);
+
+   return 0;
+}
+
 static const struct blk_ops sandbox_host_blk_ops = {
.read   = host_block_read,
.write  = host_block_write,
@@ -239,6 +251,7 @@ U_BOOT_DRIVER(sandbox_host_blk) = {
.name   = "sandbox_host_blk",
.id = UCLASS_BLK,
.ops= &sandbox_host_blk_ops,
+   .unbind = sandbox_host_unbind,
.plat_auto  = sizeof(struct host_block_dev),
 };
 #else
--
2.30.0



Re: [PATCH v5] net: tftp: Add client support for RFC 7440

2021-02-02 Thread Suneel Garapati
On Tue, Feb 2, 2021 at 11:46 AM Ramon Fried  wrote:
>
> On Tue, Feb 2, 2021 at 6:02 PM Suneel Garapati  wrote:
> >
> > On Mon, Feb 1, 2021 at 2:27 PM Ramon Fried  wrote:
> > >
> > > On Sat, Jan 30, 2021 at 11:26 PM Ramon Fried  wrote:
> > > >
> > > > On Sat, Jan 30, 2021 at 10:39 PM Suneel Garapati 
> > > >  wrote:
> > > > >
> > > > > Hello Ramon,
> > > > >
> > > > > With TFTP window size as default 1 and enabling TFTPPUT config option
> > > > > results in tftpboot command failure.
> > > > >
> > > > > Attached the pcap files for with and without TFTPPUT enabled.
> > > > > Both captures are the same except that the TFTPPUT option enables 
> > > > > ICMP handler
> > > > > and for the response from the server triggers a restart of netloop
> > > > > operation and eventually fails as below.
> > > > >
> > > > > > tftpboot 0x3000 192.168.1.1:Image
> > > > > Waiting for RPM0 LMAC0 link status... 10G_R [10G]
> > > > > Using rvu_pf#0 device
> > > > > TFTP from server 192.168.1.1; our IP address is 192.168.1.16
> > > > > Filename 'Image'. Load address: 0x3000
> > > > > Loading: ## 15.8 MiB
> > > > > 787.1 KiB/s
> > > > > done
> > > > > TFTP server died; starting again
> > > > > >
> > > > >
> > > > > I see the code issue as below on net/tftp.c [v2020.10] –
> > > > > /*
> > > > >  *  Acknowledge the block just received, which 
> > > > > will prompt
> > > > >  *  the remote for the next one.
> > > > >  */
> > > > > if (tftp_cur_block == tftp_next_ack) {
> > > > > tftp_send();
> > > > > tftp_next_ack += tftp_windowsize;
> > > > > }
> > > > >
> > > > > if (len < tftp_block_size) {
> > > > > //if (tftp_windowsize > 1) [Hack in use for
> > > > > now to work around this issue]
> > > > > tftp_send();  [ This
> > > > > causes extra ACK packet send with same block number and causes server
> > > > > to respond with ICMP error]
> > > > > tftp_complete();
> > > > > }
> > > > >
> > > > > I couldn’t try with tftp_windowsize > 1 as the test servers don’t 
> > > > > support.
> > > > > I tried with all latest commits on net/tftp.c on top of v2020.10 and
> > > > > still see the issue.
> > > > >
> > > > > This change is introduced in
> > > > > commit cc6b87ecaa96325577a8fafabc0d5972b816bc6c
> > > > > Author: Ramon Fried 
> > > > > Date:   Sat Jul 18 23:31:46 2020 +0300
> > > > >
> > > > > net: tftp: Add client support for RFC 7440
> > > > >
> > > > > Add support for RFC 7440: "TFTP Windowsize Option".
> > > > >
> > > > > Reverting this commit on v2020.10 also fixes the issue.
> > > > >
> > > > > I would like to know if this extra tftp_send is needed at all or only
> > > > > for window size > 1
> > > RFC7440 is not supported by most TFTP Servers, when adding support for
> > > this feature I didn't even consider TFTPPUT.
> > > I think that the best thing to do is to only support RFC7440 on TFTPGET.
> > > In this case we should remove the tftp_send() when sending a file.
> > > I will create a fix, would you mind testing to see if it works for you ?
> > > Thanks,
> > > Ramon.
> > Yes, I can test the fix.
> >
> > Thanks,
> > Suneel
> > > > >
> > > > > Regards,
> > > > > Suneel
> > > > Thanks for spotting this, I'll check it out.
> Hey Suneel
> Now when I dived deeper, I just figured out that __tftpboot__ doesn't
> work for you with window size = 1.
> This is very strange, my current setup is working also with this 
> configuration.
> Can you please check which TFTP server you're using on the other end ?

Did it work with/without CMD_TFTPPUT config option?
For me it fails only when this option is enabled.
What is the response on your setup from the server for the extra ack
packet sent on the last block?
TFTP server is a tftpd-hpa service on ubuntu 18.04 machine with basic setup.

>
> Thanks,
> Ramon.


Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Marek Vasut

On 2/2/21 5:23 PM, Andre Przywara wrote:
[...]


  drivers/nvme/nvme.c | 50 +
  1 file changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 5d6331ad34..758415a53b 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -53,6 +53,27 @@ struct nvme_queue {
 unsigned long cmdid_data[];
  };

+static void nvme_align_dcache_range(void *start, unsigned long size,
+   unsigned long *s, unsigned long *e)
+{
+   *s = rounddown((uintptr_t)start, ARCH_DMA_MINALIGN);
+   *e = roundup((uintptr_t)start + size, ARCH_DMA_MINALIGN);
+}


As mentioned in the other email, just rounding the value that we are
going to pass to the cache maintenance operation does not make sense,
so this function should go.


You keep saying that this patch makes no sense, but I don't see any 
explanation _why_ there is a problem.



+
+static void nvme_flush_dcache_range(void *start, unsigned long size)
+{
+   unsigned long s, e;
+   nvme_align_dcache_range(start, size, &s, &e);
+   flush_dcache_range(s, e);


There is no good reason for alignment restrictions when it comes to
clean (& invalidate), so there is no need for this wrapper.


Is that on ARM64-specific or is that applicable in general ? The driver 
is expected to work on any CPU. The flushed area start/end address must 
be cache line aligned, hence the wrapper is correct and needed.



+}
+
+static void nvme_invalidate_dcache_range(void *start, unsigned long size)
+{
+   unsigned long s, e;
+   nvme_align_dcache_range(start, size, &s, &e);
+   invalidate_dcache_range(s, e);


invalidate is tricky, we could use a wrapper similar to
invalidate_dcache_check() in bcmgenet.c. However I am not sure this is
very useful here, because most requests are already for a whole buffer
size (page or block).

Alignment of the buffer address will be checked by the implementation
of invalidate_dcache_range().


Both invalidate_dcache_range() and flush_dcache_range() will perform no 
operation if either start or end address is not cache-line aligned. If a 
driver passes such unaligned address to either function, then the driver 
must be fixed, because it will fail to perform cache flush/invalidate 
ops silently and then fail silently, e.g. like this nvme driver does.



+}
+
  static int nvme_wait_ready(struct nvme_dev *dev, bool enabled)
  {
 u32 bit = enabled ? NVME_CSTS_RDY : 0;
@@ -129,8 +150,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
 }
 *prp2 = (ulong)dev->prp_pool;

-   flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
-  dev->prp_entry_num * sizeof(u64));
+   nvme_flush_dcache_range(dev->prp_pool, dev->prp_entry_num * 
sizeof(u64));


As mentioned above, there should be no reason to check or round addresses for 
flush().


Again, if the start/end address of the flush/invalidate_dcache_range 
operation is unaligned, the operation is not performed, hence the 
alignment is mandatory.



It gets a bit more tricky if buffers overlap with buffers that are also
invalidated at some point, but that does not seem to be the case here.


The buffers are correctly padded already, hence there is no problem with 
overlap, and hence the rounding is exactly what has to be done.




 return 0;
  }
@@ -144,10 +164,8 @@ static __le16 nvme_get_cmd_id(void)

  static u16 nvme_read_completion_status(struct nvme_queue *nvmeq, u16 index)
  {
-   u64 start = (ulong)&nvmeq->cqes[index];
-   u64 stop = start + sizeof(struct nvme_completion);
-
-   invalidate_dcache_range(start, stop);


IIUC, this wants to invalidate a single CQ entry, which is 16 bytes
long. So this will also invalidate the neighboring entry, at least
(with 64 byte cache line size even three others).
Does the hardware require the queue entries to be consecutive?
If not, we could blow up struct nvme_completion to have the size of a
cache line.
If yes, this gets a bit more tricky.


The CQ entry is correctly padded, so this concern does not apply.
Note that this is also mentioned in the commit message.


One generic solution would be to use "coherent" memory, which is
basically mapped as uncached. And then put the CQ array in there. I
think we already have some support in U-Boot for that?


Yes, some drivers seems to be misusing coherent memory where it makes 
zero sense to use it. Here it makes zero sense, since the CQ entries are 
cacheline aligned and all that needs to be done is correctly apply the 
cache operations, which is done by this patch.



+   nvme_invalidate_dcache_range(&nvmeq->cqes[index],
+sizeof(struct nvme_completion));

 return le16_to_cpu(readw(&(nvmeq->cqes[index].status)));
  }
@@ -163,8 +181,7 @@ static void nvme_submit_cmd(struct nvme_queue *nvmeq, 
struct nvme_command *cmd)
 u16 tail = nvmeq->sq

[PATCH 1/1] efi_selftest: use GUID to find ESP in dtbdump

2021-02-02 Thread Heinrich Schuchardt
If dtbdump.efi is loaded from memory when calling LoadImage the loaded
image protocol will not indicate the partition from where it was loaded.
In this case use the EFI system partition for the 'load' and 'save'
commands.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/dtbdump.c | 85 +++---
 1 file changed, 52 insertions(+), 33 deletions(-)

diff --git a/lib/efi_selftest/dtbdump.c b/lib/efi_selftest/dtbdump.c
index 953b264d9d..38ab9f8bf0 100644
--- a/lib/efi_selftest/dtbdump.c
+++ b/lib/efi_selftest/dtbdump.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 

 #define BUFFER_SIZE 64
 #define ESC 0x17
@@ -27,6 +28,7 @@ static efi_handle_t handle;
 static struct efi_system_table *systable;
 static const efi_guid_t efi_dt_fixup_protocol_guid = 
EFI_DT_FIXUP_PROTOCOL_GUID;
 static const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
+static const efi_guid_t efi_system_partition_guid = PARTITION_SYSTEM_GUID;

 /**
  * print() - print string
@@ -230,6 +232,52 @@ void do_help(void)
error(L"exit   - exit the shell\r\n");
 }

+/**
+ * open_file_system() - open simple file system protocol
+ *
+ * file_system:interface of the simple file system protocol
+ * Return: status code
+ */
+static efi_status_t
+open_file_system(struct efi_simple_file_system_protocol **file_system)
+{
+   struct efi_loaded_image *loaded_image;
+   efi_status_t ret;
+   efi_handle_t *handle_buffer = NULL;
+   efi_uintn_t count;
+
+   ret = bs->open_protocol(handle, &loaded_image_guid,
+   (void **)&loaded_image, NULL, NULL,
+   EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+   if (ret != EFI_SUCCESS) {
+   error(L"Loaded image protocol not found\r\n");
+   return ret;
+   }
+
+   /* Open the simple file system protocol on the same partition */
+   ret = bs->open_protocol(loaded_image->device_handle,
+   &guid_simple_file_system_protocol,
+   (void **)file_system, NULL, NULL,
+   EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+   if (ret == EFI_SUCCESS)
+   return ret;
+
+   /* Open the simple file system protocol on the UEFI system partition */
+   ret = bs->locate_handle_buffer(BY_PROTOCOL, &efi_system_partition_guid,
+  NULL, &count, &handle_buffer);
+   if (ret == EFI_SUCCESS && handle_buffer)
+   ret = bs->open_protocol(handle_buffer[0],
+   &guid_simple_file_system_protocol,
+   (void **)file_system, NULL, NULL,
+   EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+   if (ret != EFI_SUCCESS)
+   error(L"Failed to open simple file system protocol\r\n");
+   if (handle)
+   bs->free_pool(handle_buffer);
+
+   return ret;
+}
+
 /**
  * do_load() - load and install device-tree
  *
@@ -239,7 +287,6 @@ void do_help(void)
 efi_status_t do_load(u16 *filename)
 {
struct efi_dt_fixup_protocol *dt_fixup_prot;
-   struct efi_loaded_image *loaded_image;
struct efi_simple_file_system_protocol *file_system;
struct efi_file_handle *root = NULL, *file = NULL;
u64 addr = 0;
@@ -258,22 +305,9 @@ efi_status_t do_load(u16 *filename)

filename = skip_whitespace(filename);

-   ret = bs->open_protocol(handle, &loaded_image_guid,
-   (void **)&loaded_image, NULL, NULL,
-   EFI_OPEN_PROTOCOL_GET_PROTOCOL);
-   if (ret != EFI_SUCCESS) {
-   error(L"Loaded image protocol not found\r\n");
-   return ret;
-   }
-   /* Open the simple file system protocol */
-   ret = bs->open_protocol(loaded_image->device_handle,
-   &guid_simple_file_system_protocol,
-   (void **)&file_system, NULL, NULL,
-   EFI_OPEN_PROTOCOL_GET_PROTOCOL);
-   if (ret != EFI_SUCCESS) {
-   error(L"Failed to open simple file system protocol\r\n");
+   ret = open_file_system(&file_system);
+   if (ret != EFI_SUCCESS)
goto out;
-   }

/* Open volume */
ret = file_system->open_volume(file_system, &root);
@@ -389,7 +423,6 @@ out:
  */
 efi_status_t do_save(u16 *filename)
 {
-   struct efi_loaded_image *loaded_image;
struct efi_simple_file_system_protocol *file_system;
efi_uintn_t dtb_size;
struct efi_file_handle *root, *file;
@@ -409,23 +442,9 @@ efi_status_t do_save(u16 *filename)

filename = skip_whitespace(filename);

-   ret = bs->open_protocol(handle, &loaded_image_guid,
-   (void **)&loaded_image, NULL, NULL,
-   EFI_OPEN_PROTOCOL_GET_PROTOCOL);
-   if (ret != EFI_S

[PATCH 1/1] efi_loader: install UEFI System Partition GUID

2021-02-02 Thread Heinrich Schuchardt
On the handle for the UEFI System Partition we must install the System
Partition GUID (with a NULL interface).

Let the efidebug command display the GUID.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/efidebug.c|  5 +
 lib/efi_loader/efi_disk.c | 15 +++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 83bc2196a5..bbbcb0a546 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -502,6 +503,10 @@ static const struct {
"Device-Tree Fixup",
EFI_DT_FIXUP_PROTOCOL_GUID,
},
+   {
+   "System Partition",
+   PARTITION_SYSTEM_GUID
+   },
/* Configuration table GUIDs */
{
"ACPI table",
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d0aad0252a..1f6b817dea 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -19,6 +19,7 @@
 struct efi_system_partition efi_system_partition;

 const efi_guid_t efi_block_io_guid = EFI_BLOCK_IO_PROTOCOL_GUID;
+const efi_guid_t efi_system_partition_guid = PARTITION_SYSTEM_GUID;

 /**
  * struct efi_disk_obj - EFI disk object
@@ -362,6 +363,7 @@ static efi_status_t efi_disk_add_dev(
 {
struct efi_disk_obj *diskobj;
struct efi_object *handle;
+   const efi_guid_t *guid = NULL;
efi_status_t ret;

/* Don't add empty devices */
@@ -400,6 +402,8 @@ static efi_status_t efi_disk_add_dev(
efi_free_pool(node);
diskobj->offset = part_info->start;
diskobj->media.last_block = part_info->size - 1;
+   if (part_info->bootable & PART_EFI_SYSTEM_PARTITION)
+   guid = &efi_system_partition_guid;
} else {
diskobj->dp = efi_dp_from_part(desc, part);
diskobj->offset = 0;
@@ -417,7 +421,8 @@ static efi_status_t efi_disk_add_dev(
handle = &diskobj->header;
ret = EFI_CALL(efi_install_multiple_protocol_interfaces(
&handle, &efi_guid_device_path, diskobj->dp,
-   &efi_block_io_guid, &diskobj->ops, NULL));
+   &efi_block_io_guid, &diskobj->ops,
+   guid, NULL, NULL));
if (ret != EFI_SUCCESS)
return ret;

@@ -467,13 +472,7 @@ static efi_status_t efi_disk_add_dev(

/* Store first EFI system partition */
if (part && !efi_system_partition.if_type) {
-   int r;
-   struct disk_partition info;
-
-   r = part_get_info(desc, part, &info);
-   if (r)
-   return EFI_DEVICE_ERROR;
-   if (info.bootable & PART_EFI_SYSTEM_PARTITION) {
+   if (part_info->bootable & PART_EFI_SYSTEM_PARTITION) {
efi_system_partition.if_type = desc->if_type;
efi_system_partition.devnum = desc->devnum;
efi_system_partition.part = part;
--
2.30.0



[PATCH 1/1] efi_loader: only check size if EFI_DT_APPLY_FIXUPS

2021-02-02 Thread Heinrich Schuchardt
In the implementation of the EFI_DT_FIXUP_PROTOCOL:

* Only check the buffer size when EFI_DT_APPLY_FIXUPS is set.
* In this case the field totalsize of the device-tree may not exceed the
  buffer size.
* Install device-tree only if EFI_DT_INSTALL_TABLE is set.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_dt_fixup.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c
index 3850ab3b0f..6de57b84d2 100644
--- a/lib/efi_loader/efi_dt_fixup.c
+++ b/lib/efi_loader/efi_dt_fixup.c
@@ -110,6 +110,7 @@ efi_dt_fixup(struct efi_dt_fixup_protocol *this, void *dtb,
 {
efi_status_t ret;
size_t required_size;
+   size_t total_size;
bootm_headers_t img = { 0 };

EFI_ENTRY("%p, %p, %p, %d", this, dtb, buffer_size, flags);
@@ -124,20 +125,20 @@ efi_dt_fixup(struct efi_dt_fixup_protocol *this, void 
*dtb,
goto out;
}
if (flags & EFI_DT_APPLY_FIXUPS) {
+   /* Check size */
required_size = fdt_off_dt_strings(dtb) +
fdt_size_dt_strings(dtb) +
0x3000;
-   } else {
-   required_size = fdt_totalsize(dtb);
-   }
-   if (required_size > *buffer_size) {
-   *buffer_size = required_size;
-   ret = EFI_BUFFER_TOO_SMALL;
-   goto out;
-   }
-   fdt_set_totalsize(dtb, *buffer_size);
+   total_size = fdt_totalsize(dtb);
+   if (required_size < total_size)
+   required_size = total_size;
+   if (required_size > *buffer_size) {
+   *buffer_size = required_size;
+   ret = EFI_BUFFER_TOO_SMALL;
+   goto out;
+   }

-   if (flags & EFI_DT_APPLY_FIXUPS) {
+   fdt_set_totalsize(dtb, *buffer_size);
if (image_setup_libfdt(&img, dtb, 0, NULL)) {
log_err("failed to process device tree\n");
ret = EFI_INVALID_PARAMETER;
@@ -147,10 +148,10 @@ efi_dt_fixup(struct efi_dt_fixup_protocol *this, void 
*dtb,
if (flags & EFI_DT_RESERVE_MEMORY)
efi_carve_out_dt_rsv(dtb);

-   if (EFI_DT_INSTALL_TABLE) {
+   if (flags & EFI_DT_INSTALL_TABLE) {
ret = efi_install_configuration_table(&efi_guid_fdt, dtb);
if (ret != EFI_SUCCESS) {
-   log_err("ERROR: failed to install device tree\n");
+   log_err("failed to install device tree\n");
goto out;
}
}
--
2.30.0



Re: [PATCH v5] net: tftp: Add client support for RFC 7440

2021-02-02 Thread Ramon Fried
On Tue, Feb 2, 2021 at 6:02 PM Suneel Garapati  wrote:
>
> On Mon, Feb 1, 2021 at 2:27 PM Ramon Fried  wrote:
> >
> > On Sat, Jan 30, 2021 at 11:26 PM Ramon Fried  wrote:
> > >
> > > On Sat, Jan 30, 2021 at 10:39 PM Suneel Garapati  
> > > wrote:
> > > >
> > > > Hello Ramon,
> > > >
> > > > With TFTP window size as default 1 and enabling TFTPPUT config option
> > > > results in tftpboot command failure.
> > > >
> > > > Attached the pcap files for with and without TFTPPUT enabled.
> > > > Both captures are the same except that the TFTPPUT option enables ICMP 
> > > > handler
> > > > and for the response from the server triggers a restart of netloop
> > > > operation and eventually fails as below.
> > > >
> > > > > tftpboot 0x3000 192.168.1.1:Image
> > > > Waiting for RPM0 LMAC0 link status... 10G_R [10G]
> > > > Using rvu_pf#0 device
> > > > TFTP from server 192.168.1.1; our IP address is 192.168.1.16
> > > > Filename 'Image'. Load address: 0x3000
> > > > Loading: ## 15.8 MiB
> > > > 787.1 KiB/s
> > > > done
> > > > TFTP server died; starting again
> > > > >
> > > >
> > > > I see the code issue as below on net/tftp.c [v2020.10] –
> > > > /*
> > > >  *  Acknowledge the block just received, which will 
> > > > prompt
> > > >  *  the remote for the next one.
> > > >  */
> > > > if (tftp_cur_block == tftp_next_ack) {
> > > > tftp_send();
> > > > tftp_next_ack += tftp_windowsize;
> > > > }
> > > >
> > > > if (len < tftp_block_size) {
> > > > //if (tftp_windowsize > 1) [Hack in use for
> > > > now to work around this issue]
> > > > tftp_send();  [ This
> > > > causes extra ACK packet send with same block number and causes server
> > > > to respond with ICMP error]
> > > > tftp_complete();
> > > > }
> > > >
> > > > I couldn’t try with tftp_windowsize > 1 as the test servers don’t 
> > > > support.
> > > > I tried with all latest commits on net/tftp.c on top of v2020.10 and
> > > > still see the issue.
> > > >
> > > > This change is introduced in
> > > > commit cc6b87ecaa96325577a8fafabc0d5972b816bc6c
> > > > Author: Ramon Fried 
> > > > Date:   Sat Jul 18 23:31:46 2020 +0300
> > > >
> > > > net: tftp: Add client support for RFC 7440
> > > >
> > > > Add support for RFC 7440: "TFTP Windowsize Option".
> > > >
> > > > Reverting this commit on v2020.10 also fixes the issue.
> > > >
> > > > I would like to know if this extra tftp_send is needed at all or only
> > > > for window size > 1
> > RFC7440 is not supported by most TFTP Servers, when adding support for
> > this feature I didn't even consider TFTPPUT.
> > I think that the best thing to do is to only support RFC7440 on TFTPGET.
> > In this case we should remove the tftp_send() when sending a file.
> > I will create a fix, would you mind testing to see if it works for you ?
> > Thanks,
> > Ramon.
> Yes, I can test the fix.
>
> Thanks,
> Suneel
> > > >
> > > > Regards,
> > > > Suneel
> > > Thanks for spotting this, I'll check it out.
Hey Suneel
Now when I dived deeper, I just figured out that __tftpboot__ doesn't
work for you with window size = 1.
This is very strange, my current setup is working also with this configuration.
Can you please check which TFTP server you're using on the other end ?

Thanks,
Ramon.


Re: [PATCH u-boot-marvell] mmc: mv_sdhci: call mmc_of_parse()

2021-02-02 Thread Marek Behún
> Hi Marek,
> I posted a similar patch earlier today:
> > Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")  
> My patch is missing this tag, though.
> baruch

OK, lets leave it on Stefan to decide which one to apply.
Marek


Re: [PATCH u-boot-marvell] mmc: mv_sdhci: call mmc_of_parse()

2021-02-02 Thread Baruch Siach
Hi Marek,

On Tue, Feb 02 2021, Marek Behún wrote:
> This is needed to parse more capabilities such as `non-removable`.
>
> Commit da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect") caused
> a regression on Turris Omnia, because mv_sdhci driver did not fill out
> host_caps from device-tree.

I posted a similar patch earlier today:

  
https://patchwork.ozlabs.org/project/uboot/patch/7dcd24e8d0149618cf686c47cce6728a64dffe2b.1612248184.git.bar...@tkos.co.il/

> Signed-off-by: Marek Behún 
> Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")

My patch is missing this tag, though.

baruch

> Cc: p...@kernel.org
> Cc: Baruch Siach 
> Cc: Stefan Roese 
> ---
>  drivers/mmc/mv_sdhci.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 556dd38046..4dc4a0d2be 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -118,6 +118,10 @@ static int mv_sdhci_probe(struct udevice *dev)
>   host->mmc->dev = dev;
>   host->mmc->priv = host;
>  
> + ret = mmc_of_parse(dev, &plat->cfg);
> + if (ret)
> + return ret;
> +
>   ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
>   if (ret)
>   return ret;


-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


[PATCH u-boot-marvell] mmc: mv_sdhci: call mmc_of_parse()

2021-02-02 Thread Marek Behún
This is needed to parse more capabilities such as `non-removable`.

Commit da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect") caused
a regression on Turris Omnia, because mv_sdhci driver did not fill out
host_caps from device-tree.

Signed-off-by: Marek Behún 
Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")
Cc: p...@kernel.org
Cc: Baruch Siach 
Cc: Stefan Roese 
---
 drivers/mmc/mv_sdhci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index 556dd38046..4dc4a0d2be 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -118,6 +118,10 @@ static int mv_sdhci_probe(struct udevice *dev)
host->mmc->dev = dev;
host->mmc->priv = host;
 
+   ret = mmc_of_parse(dev, &plat->cfg);
+   if (ret)
+   return ret;
+
ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
if (ret)
return ret;
-- 
2.26.2



Re: [PATCH 0/3] arm: mvebu: Espressobin: Set default env values at runtime

2021-02-02 Thread Andre Heider

On 02/02/2021 17:32, Stefan Roese wrote:

On 02.02.21 17:13, Andre Heider wrote:

On 02/02/2021 16:09, Stefan Roese wrote:

Hi Pali,
Hi Andre,

On 12.01.21 10:24, Pali Rohár wrote:

Hello!

On Tuesday 12 January 2021 09:18:44 Andre Heider wrote:

Hi Pali,

On 11/01/2021 11:51, Pali Rohár wrote:

Hello Stefan and Andre!

Could you please look at this patch series and tell me what do you 
think

about it? If it is fine or needs to take different approach?


I like the idea very much, and I bet there're quite some boards 
which could

make good use of "immutable envvars".

The obvious review point is the filler thing and its dependency on
DEFAULT_ENV_IS_RW, which probably won't win a beauty contest :) 
Maybe a

nicer integration would help in getting it merged?

I don't think it would take too much effort, first thing that comes 
to mind:

- board provides list of immutable vars
- env_set_default() backs up these vars
- env_set_default() imports default_environment
- env_set_default() imports backup on top

The last step should be easy, see env_set_default_vars().


This could probably work for $ethNaddr variables.

But there is still an issue how to handle $fdtfile. There is basically
default value for this variable, but value itself cannot be determined
at compile time, only at runtime. And for it variable flags do not 
help,
we just need an mechanism how to set default variable values not 
only at

compile time but also runtime.

That is why I chosen for now solution with modifying
default_environment[] array as it solve issue for both $fdtfile and
$ethNaddr variables.


So what is the outcome of this discussion? Andre, do you see any
hindering points in this patch series, apart from it not winning a
"beauty contest"? ;)


Hehe, nope, only aesthetic concerns, no hinderung points to block this 
going in.


I see. Then if appropriate, please send any matching tag(s) to these
patches.


I didn't test it, so this set is at least:
Acked-by: Andre Heider 

Thanks,
Andre


Re: [PATCH v3 1/1] env: sf: single function env_sf_save()

2021-02-02 Thread Harry Waschkeit

On 02.02.21 15:54, Stefan Roese wrote:

On 02.02.21 15:43, Harry Waschkeit wrote:


On 02.02.21 10:30, Stefan Roese wrote:

On 02.02.21 09:21, Harry Waschkeit wrote:

Instead of implementing redundant environments in two very similar
functions env_sf_save(), handle redundancy in one function, placing the
few differences in appropriate pre-compiler sections depending on config
option CONFIG_ENV_OFFSET_REDUND.

Additionally, several checkpatch complaints were addressed.

This patch is in preparation for adding support for env erase.

Signed-off-by: Harry Waschkeit 
Reviewed-by: Stefan Roese 
---
Change in v3:
  - no change in patch, only added "reviewed-by" to commit log


JFYI:
No need to re-send this patch with this added RB tag, as I already did
send a new RB to the last mail as reply. Patchwork collects these tags
when sent to the list. So you only need to include them, if you send
a new patch version.


thanks for this hint, obviously I step into it all the time ...

Ok, lesson learnt, let's see what I can do wrong next time ... ;-/

Back on topic: I guess that was all I needed to do so that the patch will get 
merged when its time comes.


Yes, now we (you) need a bit of patience, so that other people might
review this patch as well. And usually it will get handled after some
time (depending on the development stage of U-Boot, merge window open
or shortly before release etc).


Ok, no problem with that.

That also means that I should wait with submission of the other patch (adding "env 
erase" support) until this one is merged.
Otherwise the patch would need to be significantly different ...

Hmm, I guess it would have been better to not send that patch standalone but 
instead as a first one in a two-patch series where the second one adds the new 
functionality on top of the clean-up.
Anyway, something to keep in mind for next time :-)


It does not hurt of course to check this from time to time and
"trigger" the maintainer of the subsystem or the custodian this
patch is delegated to nothing is happening here for a too long
time (like more than 1 month).


Alright, good to know :-)

Thanks,
Harry


Thanks,
Stefan


If not, please let me know.

Thanks,
Harry


Thanks,
Stefan


Change in v2:
  - remove one more #ifdef, instead take advantage of compiler attribute
    __maybe_unused for one variable used only in case of redundant
    environments

  env/sf.c | 130 ++-
  1 file changed, 41 insertions(+), 89 deletions(-)

diff --git a/env/sf.c b/env/sf.c
index 937778aa37..199114fd3b 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -66,13 +66,14 @@ static int setup_flash_device(void)
  return 0;
  }
-#if defined(CONFIG_ENV_OFFSET_REDUND)
  static int env_sf_save(void)
  {
  env_t    env_new;
-    char    *saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
+    char    *saved_buffer = NULL;
  u32    saved_size, saved_offset, sector;
+    ulong    offset;
  int    ret;
+    __maybe_unused char flag = ENV_REDUND_OBSOLETE;
  ret = setup_flash_device();
  if (ret)
@@ -81,27 +82,33 @@ static int env_sf_save(void)
  ret = env_export(&env_new);
  if (ret)
  return -EIO;
-    env_new.flags    = ENV_REDUND_ACTIVE;
-    if (gd->env_valid == ENV_VALID) {
-    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
-    env_offset = CONFIG_ENV_OFFSET;
-    } else {
-    env_new_offset = CONFIG_ENV_OFFSET;
-    env_offset = CONFIG_ENV_OFFSET_REDUND;
-    }
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+    env_new.flags    = ENV_REDUND_ACTIVE;
+
+    if (gd->env_valid == ENV_VALID) {
+    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+    env_offset = CONFIG_ENV_OFFSET;
+    } else {
+    env_new_offset = CONFIG_ENV_OFFSET;
+    env_offset = CONFIG_ENV_OFFSET_REDUND;
+    }
+    offset = env_new_offset;
+#else
+    offset = CONFIG_ENV_OFFSET;
+#endif
  /* Is the sector larger than the env (i.e. embedded) */
  if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
  saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
-    saved_offset = env_new_offset + CONFIG_ENV_SIZE;
+    saved_offset = offset + CONFIG_ENV_SIZE;
  saved_buffer = memalign(ARCH_DMA_MINALIGN, saved_size);
  if (!saved_buffer) {
  ret = -ENOMEM;
  goto done;
  }
-    ret = spi_flash_read(env_flash, saved_offset,
-    saved_size, saved_buffer);
+    ret = spi_flash_read(env_flash, saved_offset, saved_size,
+ saved_buffer);
  if (ret)
  goto done;
  }
@@ -109,35 +116,39 @@ static int env_sf_save(void)
  sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
  puts("Erasing SPI flash...");
-    ret = spi_flash_erase(env_flash, env_new_offset,
-    sector * CONFIG_ENV_SECT_SIZE);
+    ret = spi_flash_erase(env_flash, offset,
+  sector * CONFIG_ENV_

ext4 metadata checksums

2021-02-02 Thread Fredrik Hallenberg
Hi, I have done some work on improving ext4 write support. In particular
adding metadata checksums. It seems to work ok but as there are so many
special cases it would be good if some more people could help with testing.
If someone is interested the fork is here:

https://github.com/megahallon/u-boot

Thanks


Re: [PATCH 0/3] arm: mvebu: Espressobin: Set default env values at runtime

2021-02-02 Thread Stefan Roese

On 02.02.21 17:13, Andre Heider wrote:

On 02/02/2021 16:09, Stefan Roese wrote:

Hi Pali,
Hi Andre,

On 12.01.21 10:24, Pali Rohár wrote:

Hello!

On Tuesday 12 January 2021 09:18:44 Andre Heider wrote:

Hi Pali,

On 11/01/2021 11:51, Pali Rohár wrote:

Hello Stefan and Andre!

Could you please look at this patch series and tell me what do you 
think

about it? If it is fine or needs to take different approach?


I like the idea very much, and I bet there're quite some boards 
which could

make good use of "immutable envvars".

The obvious review point is the filler thing and its dependency on
DEFAULT_ENV_IS_RW, which probably won't win a beauty contest :) Maybe a
nicer integration would help in getting it merged?

I don't think it would take too much effort, first thing that comes 
to mind:

- board provides list of immutable vars
- env_set_default() backs up these vars
- env_set_default() imports default_environment
- env_set_default() imports backup on top

The last step should be easy, see env_set_default_vars().


This could probably work for $ethNaddr variables.

But there is still an issue how to handle $fdtfile. There is basically
default value for this variable, but value itself cannot be determined
at compile time, only at runtime. And for it variable flags do not help,
we just need an mechanism how to set default variable values not only at
compile time but also runtime.

That is why I chosen for now solution with modifying
default_environment[] array as it solve issue for both $fdtfile and
$ethNaddr variables.


So what is the outcome of this discussion? Andre, do you see any
hindering points in this patch series, apart from it not winning a
"beauty contest"? ;)


Hehe, nope, only aesthetic concerns, no hinderung points to block this 
going in.


I see. Then if appropriate, please send any matching tag(s) to these
patches.

Thanks,
Stefan


Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Andre Przywara
On Tue, 2 Feb 2021 11:55:50 +0800
Bin Meng  wrote:

Hi,

had a look at the code, those are my findings:

> On Sun, Jan 31, 2021 at 1:53 AM Marek Vasut  wrote:
> >
> > The various structures in the driver are already correcty padded and  
> 
> typo: correctly
> 
> > cache aligned in memory, however the cache operations are called on
> > the structure sizes, which themselves might not be cache aligned. Add
> > the necessary rounding to fix this, which permits the nvme to work on
> > arm64.  
> 
> +ARM guys
> 
> Which ARM64 SoC did you test this with?
> 
> The round down in this patch should be unnecessary. But it's better to
> figure out which call to dcache_xxx() with an unaligned end address.
> 
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Bin Meng 
> > ---
> >  drivers/nvme/nvme.c | 50 +
> >  1 file changed, 32 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > index 5d6331ad34..758415a53b 100644
> > --- a/drivers/nvme/nvme.c
> > +++ b/drivers/nvme/nvme.c
> > @@ -53,6 +53,27 @@ struct nvme_queue {
> > unsigned long cmdid_data[];
> >  };
> >
> > +static void nvme_align_dcache_range(void *start, unsigned long size,
> > +   unsigned long *s, unsigned long *e)
> > +{
> > +   *s = rounddown((uintptr_t)start, ARCH_DMA_MINALIGN);
> > +   *e = roundup((uintptr_t)start + size, ARCH_DMA_MINALIGN);
> > +}

As mentioned in the other email, just rounding the value that we are
going to pass to the cache maintenance operation does not make sense,
so this function should go.

> > +
> > +static void nvme_flush_dcache_range(void *start, unsigned long size)
> > +{
> > +   unsigned long s, e;
> > +   nvme_align_dcache_range(start, size, &s, &e);
> > +   flush_dcache_range(s, e);

There is no good reason for alignment restrictions when it comes to
clean (& invalidate), so there is no need for this wrapper.

> > +}
> > +
> > +static void nvme_invalidate_dcache_range(void *start, unsigned long size)
> > +{
> > +   unsigned long s, e;
> > +   nvme_align_dcache_range(start, size, &s, &e);
> > +   invalidate_dcache_range(s, e);

invalidate is tricky, we could use a wrapper similar to
invalidate_dcache_check() in bcmgenet.c. However I am not sure this is
very useful here, because most requests are already for a whole buffer
size (page or block).

Alignment of the buffer address will be checked by the implementation
of invalidate_dcache_range().

> > +}
> > +
> >  static int nvme_wait_ready(struct nvme_dev *dev, bool enabled)
> >  {
> > u32 bit = enabled ? NVME_CSTS_RDY : 0;
> > @@ -129,8 +150,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 
> > *prp2,
> > }
> > *prp2 = (ulong)dev->prp_pool;
> >
> > -   flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
> > -  dev->prp_entry_num * sizeof(u64));
> > +   nvme_flush_dcache_range(dev->prp_pool, dev->prp_entry_num * 
> > sizeof(u64));

As mentioned above, there should be no reason to check or round addresses for 
flush().
It gets a bit more tricky if buffers overlap with buffers that are also
invalidated at some point, but that does not seem to be the case here.

> >
> > return 0;
> >  }
> > @@ -144,10 +164,8 @@ static __le16 nvme_get_cmd_id(void)
> >
> >  static u16 nvme_read_completion_status(struct nvme_queue *nvmeq, u16 index)
> >  {
> > -   u64 start = (ulong)&nvmeq->cqes[index];
> > -   u64 stop = start + sizeof(struct nvme_completion);
> > -
> > -   invalidate_dcache_range(start, stop);

IIUC, this wants to invalidate a single CQ entry, which is 16 bytes
long. So this will also invalidate the neighboring entry, at least
(with 64 byte cache line size even three others).
Does the hardware require the queue entries to be consecutive?
If not, we could blow up struct nvme_completion to have the size of a
cache line.
If yes, this gets a bit more tricky.

One generic solution would be to use "coherent" memory, which is
basically mapped as uncached. And then put the CQ array in there. I
think we already have some support in U-Boot for that?

> > +   nvme_invalidate_dcache_range(&nvmeq->cqes[index],
> > +sizeof(struct nvme_completion));
> >
> > return le16_to_cpu(readw(&(nvmeq->cqes[index].status)));
> >  }
> > @@ -163,8 +181,7 @@ static void nvme_submit_cmd(struct nvme_queue *nvmeq, 
> > struct nvme_command *cmd)
> > u16 tail = nvmeq->sq_tail;
> >
> > memcpy(&nvmeq->sq_cmds[tail], cmd, sizeof(*cmd));
> > -   flush_dcache_range((ulong)&nvmeq->sq_cmds[tail],
> > -  (ulong)&nvmeq->sq_cmds[tail] + sizeof(*cmd));
> > +   nvme_flush_dcache_range(&nvmeq->sq_cmds[tail], sizeof(*cmd));
> >
> > if (++tail == nvmeq->q_depth)
> > tail = 0;
> > @@ -338,8 +355,7 @@ static void nvme_init_queue(struct nvme_queue *nvmeq, 
> > u16 q

Re: [PATCH 0/3] arm: mvebu: Espressobin: Set default env values at runtime

2021-02-02 Thread Andre Heider

On 02/02/2021 16:09, Stefan Roese wrote:

Hi Pali,
Hi Andre,

On 12.01.21 10:24, Pali Rohár wrote:

Hello!

On Tuesday 12 January 2021 09:18:44 Andre Heider wrote:

Hi Pali,

On 11/01/2021 11:51, Pali Rohár wrote:

Hello Stefan and Andre!

Could you please look at this patch series and tell me what do you 
think

about it? If it is fine or needs to take different approach?


I like the idea very much, and I bet there're quite some boards which 
could

make good use of "immutable envvars".

The obvious review point is the filler thing and its dependency on
DEFAULT_ENV_IS_RW, which probably won't win a beauty contest :) Maybe a
nicer integration would help in getting it merged?

I don't think it would take too much effort, first thing that comes 
to mind:

- board provides list of immutable vars
- env_set_default() backs up these vars
- env_set_default() imports default_environment
- env_set_default() imports backup on top

The last step should be easy, see env_set_default_vars().


This could probably work for $ethNaddr variables.

But there is still an issue how to handle $fdtfile. There is basically
default value for this variable, but value itself cannot be determined
at compile time, only at runtime. And for it variable flags do not help,
we just need an mechanism how to set default variable values not only at
compile time but also runtime.

That is why I chosen for now solution with modifying
default_environment[] array as it solve issue for both $fdtfile and
$ethNaddr variables.


So what is the outcome of this discussion? Andre, do you see any
hindering points in this patch series, apart from it not winning a
"beauty contest"? ;)


Hehe, nope, only aesthetic concerns, no hinderung points to block this 
going in.


Thanks,
Andre


Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Marek Vasut

On 2/2/21 10:12 AM, Bin Meng wrote:
[...]

cache aligned in memory, however the cache operations are called on
the structure sizes, which themselves might not be cache aligned. Add
the necessary rounding to fix this, which permits the nvme to work on
arm64.


+ARM guys

Which ARM64 SoC did you test this with?


RCar3, although that's irrelevant, the problem will happen on any arm or
arm64, and possibly any other system which needs cache management.


There was a recent change to nvme.c that fixed a cache issue on ARMv8
so I thought this might be platform related.


I used master, so unlikely.


It's strange this issue was not exposed last time when this driver was
tested on ARMv8.


Which ARMv8 platform ?


The round down in this patch should be unnecessary.


Can you explain why ?


I just took a further look and most of the start address should be
cache line aligned (4KiB aligned) except the
nvme_read_completion_status(). It's only 16 bytes aligned which might
not be cache line aligned.


Right, there are various arm chips with 32B/64B alignment requirements.


But it's better to
figure out which call to dcache_xxx() with an unaligned end address.


If you look at the code, most of them can (and do) trigger this,
therefore they need such alignment, as explained in the commit message.


Now I wonder what's the correct implementation of the
invalidate_dcache_range() and flush_dcache_range() in U-Boot?
Shouldn't the round down/up happen in these APIs instead of doing such
in drivers?


Definitely not, because then the rounding might flush/invalidate cache
over areas where this could cause a problem (e.g. neighboring DMA
descriptors). The driver must do the cache management correctly.


Well we can implement in these APIs and document its expected usage.


That would be harmful, because you cannot really flush/invalidate half 
of cache line. Consider you have two 16B DMA descriptors next to each 
other, which is often the case, then the driver has to implement proper 
cache handling.


That this particular driver already has structures reasonably well 
padded that they can be flushed by adding rounding is an exception.



Either way a driver has to do the cache management correctly. Not
doing it in the driver eliminates some duplications of rounding
up/down.


Indeed, and rounding up/down is the correct way to do it in this driver, 
see the commit message.



For this case, I believe we just need to take care of
nvme_read_completion_status().


Can you validate this ?


Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Marek Vasut

On 2/2/21 2:04 PM, Andre Przywara wrote:

Hi,

[...]


The various structures in the driver are already correcty padded and


typo: correctly


cache aligned in memory, however the cache operations are called on
the structure sizes, which themselves might not be cache aligned. Add
the necessary rounding to fix this, which permits the nvme to work on
arm64.


+ARM guys

Which ARM64 SoC did you test this with?

The round down in this patch should be unnecessary. But it's better to
figure out which call to dcache_xxx() with an unaligned end address.


I agree. There is no requirement for the actual cache maintenance
instruction's address to be aligned, and also we align everything
already in the implementations of flush_dcache_range() and
invalidate_dcache_range().


I would suggest you insert check_cache_range() into 
arch/arm/cpu/armv8/cache_v8.c invalidate_dcache_range() and 
flush_dcache_range() which would prove you wrong.



Actually I think rounding here is *wrong*, as we paper over the
requirement of the *buffer* to be cache line aligned. So this must be
assured at buffer allocation time, and just rounding before calling
cache maintenance merely avoids (read: silences!) the warnings.

I think drivers/net/bcmgenet.c does the right thing.

Happy to provide more detailed rationale and explanations if needed.


Please do spend some more time on this, possibly even test your claim on 
real hardware, and then provide more details.


Re: [PATCH v5] net: tftp: Add client support for RFC 7440

2021-02-02 Thread Suneel Garapati
On Mon, Feb 1, 2021 at 2:27 PM Ramon Fried  wrote:
>
> On Sat, Jan 30, 2021 at 11:26 PM Ramon Fried  wrote:
> >
> > On Sat, Jan 30, 2021 at 10:39 PM Suneel Garapati  
> > wrote:
> > >
> > > Hello Ramon,
> > >
> > > With TFTP window size as default 1 and enabling TFTPPUT config option
> > > results in tftpboot command failure.
> > >
> > > Attached the pcap files for with and without TFTPPUT enabled.
> > > Both captures are the same except that the TFTPPUT option enables ICMP 
> > > handler
> > > and for the response from the server triggers a restart of netloop
> > > operation and eventually fails as below.
> > >
> > > > tftpboot 0x3000 192.168.1.1:Image
> > > Waiting for RPM0 LMAC0 link status... 10G_R [10G]
> > > Using rvu_pf#0 device
> > > TFTP from server 192.168.1.1; our IP address is 192.168.1.16
> > > Filename 'Image'. Load address: 0x3000
> > > Loading: ## 15.8 MiB
> > > 787.1 KiB/s
> > > done
> > > TFTP server died; starting again
> > > >
> > >
> > > I see the code issue as below on net/tftp.c [v2020.10] –
> > > /*
> > >  *  Acknowledge the block just received, which will 
> > > prompt
> > >  *  the remote for the next one.
> > >  */
> > > if (tftp_cur_block == tftp_next_ack) {
> > > tftp_send();
> > > tftp_next_ack += tftp_windowsize;
> > > }
> > >
> > > if (len < tftp_block_size) {
> > > //if (tftp_windowsize > 1) [Hack in use for
> > > now to work around this issue]
> > > tftp_send();  [ This
> > > causes extra ACK packet send with same block number and causes server
> > > to respond with ICMP error]
> > > tftp_complete();
> > > }
> > >
> > > I couldn’t try with tftp_windowsize > 1 as the test servers don’t support.
> > > I tried with all latest commits on net/tftp.c on top of v2020.10 and
> > > still see the issue.
> > >
> > > This change is introduced in
> > > commit cc6b87ecaa96325577a8fafabc0d5972b816bc6c
> > > Author: Ramon Fried 
> > > Date:   Sat Jul 18 23:31:46 2020 +0300
> > >
> > > net: tftp: Add client support for RFC 7440
> > >
> > > Add support for RFC 7440: "TFTP Windowsize Option".
> > >
> > > Reverting this commit on v2020.10 also fixes the issue.
> > >
> > > I would like to know if this extra tftp_send is needed at all or only
> > > for window size > 1
> RFC7440 is not supported by most TFTP Servers, when adding support for
> this feature I didn't even consider TFTPPUT.
> I think that the best thing to do is to only support RFC7440 on TFTPGET.
> In this case we should remove the tftp_send() when sending a file.
> I will create a fix, would you mind testing to see if it works for you ?
> Thanks,
> Ramon.
Yes, I can test the fix.

Thanks,
Suneel
> > >
> > > Regards,
> > > Suneel
> > Thanks for spotting this, I'll check it out.


[PATCH] xilinx: Show silicon version in SPL

2021-02-02 Thread Michal Simek
Both Zynq and ZynqMP can show silicon versions in SPL boot flow. It is
useful to be aware.
The patch is also fixing possition of these bits on ZynqMP.

Signed-off-by: Michal Simek 
---

 arch/arm/mach-zynqmp/include/mach/hardware.h | 4 ++--
 board/xilinx/zynq/board.c| 3 +++
 board/xilinx/zynqmp/zynqmp.c | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h 
b/arch/arm/mach-zynqmp/include/mach/hardware.h
index b328837c694f..3d3c48e24731 100644
--- a/arch/arm/mach-zynqmp/include/mach/hardware.h
+++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
@@ -128,8 +128,8 @@ struct apu_regs {
 
 #define ZYNQMP_CSU_VERSION_EMPTY_SHIFT 20
 
-#define ZYNQMP_SILICON_VER_MASK0xF000
-#define ZYNQMP_SILICON_VER_SHIFT   12
+#define ZYNQMP_SILICON_VER_MASK0xF
+#define ZYNQMP_SILICON_VER_SHIFT   0
 
 struct csu_regs {
u32 reserved0[4];
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 7ac069aaafdf..0fc11a48f14c 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -24,6 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
 {
+   if (IS_ENABLED(CONFIG_SPL_BUILD))
+   printf("Silicon version:\t%d\n", zynq_get_silicon_version());
+
return 0;
 }
 
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index d18c992e3f8f..8968cf90760f 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -328,6 +328,7 @@ int board_init(void)
if (sizeof(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE) > 1)
zynqmp_pmufw_load_config_object(zynqmp_pm_cfg_obj,
zynqmp_pm_cfg_obj_size);
+   printf("Silicon version:\t%d\n", zynqmp_get_silicon_version());
 #else
if (CONFIG_IS_ENABLED(DM_I2C) && CONFIG_IS_ENABLED(I2C_EEPROM))
xilinx_read_eeprom();
-- 
2.30.0



[PATCH v5 3/3] sysboot: add zboot support to boot x86 Linux kernel image

2021-02-02 Thread Kory Maincent
Add "zboot" command to the list of supported boot in the label_boot
function.

Signed-off-by: Kory Maincent 
Reviewed-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Change since v1:
 - Modify comment.

Change since v2:
 - Update do_zboot to do_zboot_parent function to follow the patch:
   5588e776b0

Change since v3:
 - Follow review from Simon Glass
 - Add clean-up paches

Change since v4:
 - Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'

 cmd/pxe_utils.c   | 3 +++
 include/command.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index e062c9edcf..4cf31119f4 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -655,6 +655,9 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
/* Try booting a Image */
else if (IS_ENABLED(CONFIG_CMD_BOOTZ))
do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
+   /* Try booting an x86_64 Linux kernel image */
+   else if (IS_ENABLED(CONFIG_CMD_ZBOOT))
+   do_zboot_parent(cmdtp, 0, bootm_argc, bootm_argv, NULL);
 
unmap_sysmem(buf);
 
diff --git a/include/command.h b/include/command.h
index 27604758a4..747f8f8095 100644
--- a/include/command.h
+++ b/include/command.h
@@ -165,6 +165,9 @@ int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc,
 int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
 char *const argv[]);
 
+int do_zboot_parent(struct cmd_tbl *cmdtp, int flag, int argc,
+   char *const argv[], int *repeatable);
+
 int common_diskboot(struct cmd_tbl *cmdtp, const char *intf, int argc,
char *const argv[]);
 
-- 
2.17.1



[PATCH v5 1/3] command.h: Clean-up patch, remove extern from the header

2021-02-02 Thread Kory Maincent
Remove the extern of the header because they are useless.

Signed-off-by: Kory Maincent 
Reviewed-by: Bin Meng 
---
 include/command.h | 56 +++
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/include/command.h b/include/command.h
index e229bf2825..27604758a4 100644
--- a/include/command.h
+++ b/include/command.h
@@ -55,8 +55,8 @@ struct cmd_tbl {
 };
 
 #if defined(CONFIG_CMD_RUN)
-extern int do_run(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[]);
+int do_run(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[]);
 #endif
 
 /* common/command.c */
@@ -69,7 +69,7 @@ int complete_subcmdv(struct cmd_tbl *cmdtp, int count, int 
argc,
 char *const argv[], char last_char, int maxv,
 char *cmdv[]);
 
-extern int cmd_usage(const struct cmd_tbl *cmdtp);
+int cmd_usage(const struct cmd_tbl *cmdtp);
 
 /* Dummy ->cmd and ->cmd_rep wrappers. */
 int cmd_always_repeatable(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -85,10 +85,10 @@ static inline bool cmd_is_repeatable(struct cmd_tbl *cmdtp)
 }
 
 #ifdef CONFIG_AUTO_COMPLETE
-extern int var_complete(int argc, char *const argv[], char last_char, int maxv,
-   char *cmdv[]);
-extern int cmd_auto_complete(const char *const prompt, char *buf, int *np,
-int *colp);
+int var_complete(int argc, char *const argv[], char last_char, int maxv,
+char *cmdv[]);
+int cmd_auto_complete(const char *const prompt, char *buf, int *np,
+ int *colp);
 #endif
 
 /**
@@ -145,13 +145,13 @@ int cmd_get_data_size(char *arg, int default_size);
 #endif
 
 #ifdef CONFIG_CMD_BOOTD
-extern int do_bootd(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
+int do_bootd(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
 #endif
 #ifdef CONFIG_CMD_BOOTM
-extern int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
-extern int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd);
+int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
+int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd);
 #else
 static inline int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd)
 {
@@ -159,28 +159,28 @@ static inline int bootm_maybe_autostart(struct cmd_tbl 
*cmdtp, const char *cmd)
 }
 #endif
 
-extern int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
+int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
 
-extern int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
+int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
 
-extern int common_diskboot(struct cmd_tbl *cmdtp, const char *intf, int argc,
-  char *const argv[]);
-
-extern int do_reset(struct cmd_tbl *cmdtp, int flag, int argc,
+int common_diskboot(struct cmd_tbl *cmdtp, const char *intf, int argc,
char *const argv[]);
-extern int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc,
-  char *const argv[]);
 
-extern unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
-   char *const argv[]);
+int do_reset(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
+int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc,
+   char *const argv[]);
+
+unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
+char *const argv[]);
 
 #if defined(CONFIG_CMD_NVEDIT_EFI)
-extern int do_env_print_efi(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
-extern int do_env_set_efi(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[]);
+int do_env_print_efi(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
+int do_env_set_efi(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[]);
 #endif
 
 /**
-- 
2.17.1



[PATCH v5 2/3] pxe_utils: clean-up, replace ifdef by IS_ENABLED

2021-02-02 Thread Kory Maincent
Replace all the macro ifdef by IS_ENABLED.
All of these configs are set in the defconfig files and not in the
include board headers files.

Signed-off-by: Kory Maincent 
---

Change since v4:
- Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible

 cmd/pxe_utils.c | 52 -
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 3526a651d7..e062c9edcf 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -340,7 +340,7 @@ static int label_localboot(struct pxe_label *label)
 /*
  * Loads fdt overlays specified in 'fdtoverlays'.
  */
-#ifdef CONFIG_OF_LIBFDT_OVERLAY
+#if (IS_ENABLED(CONFIG_OF_LIBFDT_OVERLAY))
 static void label_boot_fdtoverlay(struct cmd_tbl *cmdtp, struct pxe_label 
*label)
 {
char *fdtoverlay = label->fdtoverlays;
@@ -492,16 +492,16 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
env_get("gatewayip"), env_get("netmask"));
}
 
-#ifdef CONFIG_CMD_NET
-   if (label->ipappend & 0x2) {
-   int err;
+   if (IS_ENABLED(CONFIG_CMD_NET)) {
+   if (label->ipappend & 0x2) {
+   int err;
 
-   strcpy(mac_str, " BOOTIF=");
-   err = format_mac_pxe(mac_str + 8, sizeof(mac_str) - 8);
-   if (err < 0)
-   mac_str[0] = '\0';
+   strcpy(mac_str, " BOOTIF=");
+   err = format_mac_pxe(mac_str + 8, sizeof(mac_str) - 8);
+   if (err < 0)
+   mac_str[0] = '\0';
+   }
}
-#endif
 
if ((label->ipappend & 0x3) || label->append) {
char bootargs[CONFIG_SYS_CBSIZE] = "";
@@ -626,7 +626,7 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
}
}
 
-#ifdef CONFIG_OF_LIBFDT_OVERLAY
+#if IS_ENABLED(CONFIG_OF_LIBFDT_OVERLAY)
if (label->fdtoverlays)
label_boot_fdtoverlay(cmdtp, label);
 #endif
@@ -649,15 +649,13 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID)
do_bootm(cmdtp, 0, bootm_argc, bootm_argv);
-#ifdef CONFIG_CMD_BOOTI
/* Try booting an AArch64 Linux kernel image */
-   else
+   else if (IS_ENABLED(CONFIG_CMD_BOOTI))
do_booti(cmdtp, 0, bootm_argc, bootm_argv);
-#elif defined(CONFIG_CMD_BOOTZ)
/* Try booting a Image */
-   else
+   else if (IS_ENABLED(CONFIG_CMD_BOOTZ))
do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
-#endif
+
unmap_sysmem(buf);
 
 cleanup:
@@ -1424,20 +1422,20 @@ void handle_pxe_menu(struct cmd_tbl *cmdtp, struct 
pxe_menu *cfg)
struct menu *m;
int err;
 
-#ifdef CONFIG_CMD_BMP
-   /* display BMP if available */
-   if (cfg->bmp) {
-   if (get_relfile(cmdtp, cfg->bmp, image_load_addr)) {
-   if (CONFIG_IS_ENABLED(CMD_CLS))
-   run_command("cls", 0);
-   bmp_display(image_load_addr,
-   BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
-   } else {
-   printf("Skipping background bmp %s for failure\n",
-  cfg->bmp);
+   if (IS_ENABLED(CONFIG_CMD_BMP)) {
+   /* display BMP if available */
+   if (cfg->bmp) {
+   if (get_relfile(cmdtp, cfg->bmp, image_load_addr)) {
+   if (CONFIG_IS_ENABLED(CMD_CLS))
+   run_command("cls", 0);
+   bmp_display(image_load_addr,
+   BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
+   } else {
+   printf("Skipping background bmp %s for 
failure\n",
+  cfg->bmp);
+   }
}
}
-#endif
 
m = pxe_menu_to_menu(cfg);
if (!m)
-- 
2.17.1



Re: [PATCH 1/5] arm: dts: r8a774a1: Import DTS queued for Linux 5.12-rc1

2021-02-02 Thread Marek Vasut

On 2/2/21 2:01 PM, Adam Ford wrote:

On Tue, Feb 2, 2021 at 4:11 AM Biju Das  wrote:


Hi Marek and Adam,


Subject: Re: [PATCH 1/5] arm: dts: r8a774a1: Import DTS queued for Linux
5.12-rc1

On 2/1/21 4:19 PM, Adam Ford wrote:

On Mon, Jan 25, 2021 at 6:40 AM Marek Vasut  wrote:


On 1/25/21 12:22 AM, Adam Ford wrote:

On Sun, Jan 24, 2021 at 11:10 AM Marek Vasut  wrote:


On 1/13/21 12:52 AM, Adam Ford wrote:

Update the RZ/G2M dtsi and r8a774a1-beacon-rzg2m-kit kit from
Renesas repo destined to become 5.12-rc1.


I picked a DT sync for Linux 5.10 from Biju (on CC), does your
board need something from 5.12-rc1 or can it be based on 5.10 too ?


I honestly don't remember.  I had to unexpectedly leave town for
this week due to a funeral, and I won't be near a Linux development
computer to run tests until Feb 1, so I don't know if the board will
build using 5.10 or not.  Sorry I don't have a better answer.


Lets revisit this later then.


I tested the Beacon boards, but they have a dependency on usb2_clksel
that is not present in the 5.10 device tree.
I also noticed that I forgot to include versaclock.h dt-binding file
from the kernel, so the Beacon boards don't build for that too.



Do we have usb2_clksel support in u-boot? If yes, it make sense to import from 
5.12-rc1.
Similarly for other bits importing from kernel 5.12-rc1.

May be rpc-spcif support available in u-boot. So we could import from 5.12-rc1.
For  others like PCIe, ethernet the changes corresponding to dts is not present 
in driver.


I think  Marek has posted some rcar3 updates to support the PCIe.


RCar3 PCIe was supported for a while (years?), what I posted recently 
were NVMe fixes.



I
am hopeful that it will work on the RZ/G2 series.
I have rpc-spcif enabled and my plan was to post some updated configs
with it enabled once the updated configs had been merged.


RPC is drivers/mtd/renesas_rpc_hf.c and drivers/spi/renesas_rpc_spi.c ?

[...]


[PATCH v4 9/9] fastboot: Partition specification

2021-02-02 Thread Sean Anderson
This documents the way U-Boot understands partitions specifications.
This also updates the fastboot documentation for the changes in the
previous commit.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

Changes in v4:
- Expand documentation, making it more man-page-like

Changes in v2:
- Move partition documentation under doc/usage

 doc/android/fastboot.rst |  4 ++
 doc/usage/index.rst  |  1 +
 doc/usage/partitions.rst | 80 
 3 files changed, 85 insertions(+)
 create mode 100644 doc/usage/partitions.rst

diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index 16b11399b3..ce513a2a0f 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -154,6 +154,10 @@ The device index starts from ``a`` and refers to the 
interface (e.g. USB
 controller, SD/MMC controller) or disk index. The partition index starts
 from ``1`` and describes the partition number on the particular device.
 
+Alternatively, partition types may be specified using :ref:`U-Boot's partition
+syntax `. This allows specifying partitions like ``0.1``,
+``0#boot``, or ``:3``. The interface is always ``mmc``.
+
 Writing Partition Table
 ---
 
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 83cfbafd90..d45467caf2 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -6,6 +6,7 @@ Use U-Boot
 
fdt_overlays
netconsole
+   partitions
 
 Shell commands
 --
diff --git a/doc/usage/partitions.rst b/doc/usage/partitions.rst
new file mode 100644
index 00..cbf8ae34f1
--- /dev/null
+++ b/doc/usage/partitions.rst
@@ -0,0 +1,80 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. _partitions:
+
+Partitions
+==
+
+Synopsis
+
+
+::
+
+  [devnum][.hwpartnum][:partnum|#partname]
+
+Description
+---
+
+Many U-Boot commands allow specifying partitions (or whole disks) using a
+generic syntax.
+
+interface
+The interface used to access the partition's device, like ``mmc`` or
+``scsi``. For a full list of supported interfaces, consult the
+``if_typename_str`` array in ``drivers/block/blk-uclass.c``
+
+devnum
+The device number. This defaults to 0.
+
+hwpartnum
+The hardware partition number. All devices have at least one hardware
+partition. On most devices, hardware partition 0 specifies the whole
+device. On eMMC devices, hardware partition 0 is the user partition,
+hardware partitions 1 and 2 are the boot partitions, hardware partition
+3 is the RPMB partition, and further partitions are general-purpose
+user-created partitions. The default hardware partition number is 0.
+
+partnum
+The partition number, starting from 1. The partition number 0 specifies
+that the whole device is to be used as one "partition."
+
+partname
+The partition name. This is the partition label for GPT partitions. For
+MBR partitions, the following syntax is used::
+
+
+
+mbr_interface
+A device type like ``mmcsd`` or ``hd``. See the
+``part_set_generic_name`` function in ``disk/part.c`` for a
+complete list.
+
+devletter
+The device number as an offset from ``a``. For example, device
+number 2 would have a device letter of ``c``.
+
+partnum
+The partition number. This is the same as above.
+
+If neither ``partname`` nor ``partnum`` is specified and there is a partition
+table, then partition 1 is used. If there is no partition table, then the whole
+device is used as one "partition." If none of ``devnum``, ``hwpartnum``,
+``partnum``, or ``partname`` is specified, or only ``-`` is specified, then
+``devnum`` defaults to the value of the ``bootdevice`` environmental variable.
+
+Examples
+
+
+List the root directory contents on MMC device 2, hardware partition 1,
+and partition number 3::
+
+ls mmc 2.1:3 /
+
+Load ``/kernel.itb`` to address ``0x8000`` from SCSI device 0, hardware 
partition
+0, and the partition labeled ``boot``::
+
+load scsi #boot 0x8000 /kernel.itb
+
+Print the partition UUID of the SATA device ``$bootdevice``, hardware partition
+0, and partition number 0::
+
+part uuid sata -
-- 
2.25.1



[PATCH v4 8/9] fastboot: Allow u-boot-style partitions

2021-02-02 Thread Sean Anderson
This adds support for partitions of the form "dev.hwpart:part" and
"dev#partname". This allows one to flash to eMMC boot partitions without
having to use CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT. It also allows one to
flash to an entire device without needing CONFIG_FASTBOOT_MMC_USER_NAME.
Lastly, one can also flash MMC devices other than
CONFIG_FASTBOOT_FLASH_MMC_DEV.

Because devices can be specified explicitly, CONFIG_FASTBOOT_FLASH_MMC_DEV
is used only when necessary for existing functionality. For those cases,
fastboot_mmc_get_dev has been added as a helper function. This allows

There should be no conflicts with the existing system, but just in case, I
have ordered detection of these names after all existing names.

The fastboot_mmc_part test has been updated for these new names.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

Changes in v4:
- Fix missing closing brace

 drivers/fastboot/fb_mmc.c | 157 --
 test/dm/fastboot.c|  37 -
 2 files changed, 132 insertions(+), 62 deletions(-)

diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 71eeb02c8f..8e74e50e91 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -76,12 +76,37 @@ static int raw_part_get_info_by_name(struct blk_desc 
*dev_desc,
return 0;
 }
 
-static int part_get_info_by_name_or_alias(struct blk_desc *dev_desc,
-   const char *name, struct disk_partition *info)
+static int do_get_part_info(struct blk_desc **dev_desc, const char *name,
+   struct disk_partition *info)
 {
int ret;
 
-   ret = part_get_info_by_name(dev_desc, name, info);
+   /* First try partition names on the default device */
+   *dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
+   if (*dev_desc) {
+   ret = part_get_info_by_name(*dev_desc, name, info);
+   if (ret >= 0)
+   return ret;
+
+   /* Then try raw partitions */
+   ret = raw_part_get_info_by_name(*dev_desc, name, info);
+   if (ret >= 0)
+   return ret;
+   }
+
+   /* Then try dev.hwpart:part */
+   ret = part_get_info_by_dev_and_name_or_num("mmc", name, dev_desc,
+  info, true);
+   return ret;
+}
+
+static int part_get_info_by_name_or_alias(struct blk_desc **dev_desc,
+ const char *name,
+ struct disk_partition *info)
+{
+   int ret;
+
+   ret = do_get_part_info(dev_desc, name, info);
if (ret < 0) {
/* strlen("fastboot_partition_alias_") + PART_NAME_LEN + 1 */
char env_alias_name[25 + PART_NAME_LEN + 1];
@@ -92,8 +117,8 @@ static int part_get_info_by_name_or_alias(struct blk_desc 
*dev_desc,
strncat(env_alias_name, name, PART_NAME_LEN);
aliased_part_name = env_get(env_alias_name);
if (aliased_part_name != NULL)
-   ret = part_get_info_by_name(dev_desc,
-   aliased_part_name, info);
+   ret = do_get_part_info(dev_desc, aliased_part_name,
+  info);
}
return ret;
 }
@@ -430,27 +455,49 @@ int fastboot_mmc_get_part_info(const char *part_name,
   struct blk_desc **dev_desc,
   struct disk_partition *part_info, char *response)
 {
-   int r = 0;
+   int ret;
 
-   *dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
-   if (!*dev_desc) {
-   fastboot_fail("block device not found", response);
-   return -ENOENT;
-   }
if (!part_name || !strcmp(part_name, "")) {
fastboot_fail("partition not given", response);
return -ENOENT;
}
 
-   if (raw_part_get_info_by_name(*dev_desc, part_name, part_info) < 0) {
-   r = part_get_info_by_name_or_alias(*dev_desc, part_name, 
part_info);
-   if (r < 0) {
-   fastboot_fail("partition not found", response);
-   return r;
+   ret = part_get_info_by_name_or_alias(dev_desc, part_name, part_info);
+   if (ret < 0) {
+   switch (ret) {
+   case -ENOSYS:
+   case -EINVAL:
+   fastboot_fail("invalid partition or device", response);
+   break;
+   case -ENODEV:
+   fastboot_fail("no such device", response);
+   break;
+   case -ENOENT:
+   fastboot_fail("no such partition", response);
+   break;
+   case -EPROTONOSUPPORT:
+   fastboot_fail("unknown partition table type", response);
+   bre

[PATCH v4 7/9] fastboot: Move part_get_info_by_name_or_alias after raw_part_get_info_by_name

2021-02-02 Thread Sean Anderson
This makes the next commit more readable by doing the move now.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 drivers/fastboot/fb_mmc.c | 44 +++
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 75347bb99b..71eeb02c8f 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -28,28 +28,6 @@ struct fb_mmc_sparse {
struct blk_desc *dev_desc;
 };
 
-static int part_get_info_by_name_or_alias(struct blk_desc *dev_desc,
-   const char *name, struct disk_partition *info)
-{
-   int ret;
-
-   ret = part_get_info_by_name(dev_desc, name, info);
-   if (ret < 0) {
-   /* strlen("fastboot_partition_alias_") + PART_NAME_LEN + 1 */
-   char env_alias_name[25 + PART_NAME_LEN + 1];
-   char *aliased_part_name;
-
-   /* check for alias */
-   strcpy(env_alias_name, "fastboot_partition_alias_");
-   strncat(env_alias_name, name, PART_NAME_LEN);
-   aliased_part_name = env_get(env_alias_name);
-   if (aliased_part_name != NULL)
-   ret = part_get_info_by_name(dev_desc,
-   aliased_part_name, info);
-   }
-   return ret;
-}
-
 static int raw_part_get_info_by_name(struct blk_desc *dev_desc,
 const char *name,
 struct disk_partition *info)
@@ -98,6 +76,28 @@ static int raw_part_get_info_by_name(struct blk_desc 
*dev_desc,
return 0;
 }
 
+static int part_get_info_by_name_or_alias(struct blk_desc *dev_desc,
+   const char *name, struct disk_partition *info)
+{
+   int ret;
+
+   ret = part_get_info_by_name(dev_desc, name, info);
+   if (ret < 0) {
+   /* strlen("fastboot_partition_alias_") + PART_NAME_LEN + 1 */
+   char env_alias_name[25 + PART_NAME_LEN + 1];
+   char *aliased_part_name;
+
+   /* check for alias */
+   strcpy(env_alias_name, "fastboot_partition_alias_");
+   strncat(env_alias_name, name, PART_NAME_LEN);
+   aliased_part_name = env_get(env_alias_name);
+   if (aliased_part_name != NULL)
+   ret = part_get_info_by_name(dev_desc,
+   aliased_part_name, info);
+   }
+   return ret;
+}
+
 /**
  * fb_mmc_blk_write() - Write/erase MMC in chunks of FASTBOOT_MAX_BLK_WRITE
  *
-- 
2.25.1



[PATCH v4 6/9] fastboot: Remove mmcpart argument from raw_part_get_info_by_name

2021-02-02 Thread Sean Anderson
The only thing mmcpart was used for was to pass to blk_dselect_hwpart.
This calls blk_dselect_hwpart directly from raw_part_get_info_by_name. The
error handling is dropped, but it is reintroduced in the next commit
(albeit less specificly).

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 drivers/fastboot/fb_mmc.c | 41 +--
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 50532acb84..75347bb99b 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -51,7 +51,8 @@ static int part_get_info_by_name_or_alias(struct blk_desc 
*dev_desc,
 }
 
 static int raw_part_get_info_by_name(struct blk_desc *dev_desc,
-   const char *name, struct disk_partition *info, int *mmcpart)
+const char *name,
+struct disk_partition *info)
 {
/* strlen("fastboot_raw_partition_") + PART_NAME_LEN + 1 */
char env_desc_name[23 + PART_NAME_LEN + 1];
@@ -85,8 +86,13 @@ static int raw_part_get_info_by_name(struct blk_desc 
*dev_desc,
strncpy((char *)info->name, name, PART_NAME_LEN);
 
if (raw_part_desc) {
-   if (strcmp(strsep(&raw_part_desc, " "), "mmcpart") == 0)
-   *mmcpart = simple_strtoul(raw_part_desc, NULL, 0);
+   if (strcmp(strsep(&raw_part_desc, " "), "mmcpart") == 0) {
+   ulong mmcpart = simple_strtoul(raw_part_desc, NULL, 0);
+   int ret = blk_dselect_hwpart(dev_desc, mmcpart);
+
+   if (ret)
+   return ret;
+   }
}
 
return 0;
@@ -425,7 +431,6 @@ int fastboot_mmc_get_part_info(const char *part_name,
   struct disk_partition *part_info, char *response)
 {
int r = 0;
-   int mmcpart;
 
*dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
if (!*dev_desc) {
@@ -437,7 +442,7 @@ int fastboot_mmc_get_part_info(const char *part_name,
return -ENOENT;
}
 
-   if (raw_part_get_info_by_name(*dev_desc, part_name, part_info, 
&mmcpart) < 0) {
+   if (raw_part_get_info_by_name(*dev_desc, part_name, part_info) < 0) {
r = part_get_info_by_name_or_alias(*dev_desc, part_name, 
part_info);
if (r < 0) {
fastboot_fail("partition not found", response);
@@ -461,7 +466,6 @@ void fastboot_mmc_flash_write(const char *cmd, void 
*download_buffer,
 {
struct blk_desc *dev_desc;
struct disk_partition info;
-   int mmcpart = 0;
 
dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
if (!dev_desc || dev_desc->type == DEV_TYPE_UNKNOWN) {
@@ -541,16 +545,12 @@ void fastboot_mmc_flash_write(const char *cmd, void 
*download_buffer,
}
 #endif
 
-   if (raw_part_get_info_by_name(dev_desc, cmd, &info, &mmcpart) == 0) {
-   if (blk_dselect_hwpart(dev_desc, mmcpart)) {
-   pr_err("Failed to select hwpart\n");
-   fastboot_fail("Failed to select hwpart", response);
+   if (raw_part_get_info_by_name(dev_desc, cmd, &info) != 0) {
+   if (part_get_info_by_name_or_alias(dev_desc, cmd, &info) < 0) {
+   pr_err("cannot find partition: '%s'\n", cmd);
+   fastboot_fail("cannot find partition", response);
return;
}
-   } else if (part_get_info_by_name_or_alias(dev_desc, cmd, &info) < 0) {
-   pr_err("cannot find partition: '%s'\n", cmd);
-   fastboot_fail("cannot find partition", response);
-   return;
}
 
if (is_sparse_image(download_buffer)) {
@@ -593,7 +593,6 @@ void fastboot_mmc_erase(const char *cmd, char *response)
struct disk_partition info;
lbaint_t blks, blks_start, blks_size, grp_size;
struct mmc *mmc = find_mmc_device(CONFIG_FASTBOOT_FLASH_MMC_DEV);
-   int mmcpart = 0;
 
if (mmc == NULL) {
pr_err("invalid mmc device\n");
@@ -632,16 +631,12 @@ void fastboot_mmc_erase(const char *cmd, char *response)
}
 #endif
 
-   if (raw_part_get_info_by_name(dev_desc, cmd, &info, &mmcpart) == 0) {
-   if (blk_dselect_hwpart(dev_desc, mmcpart)) {
-   pr_err("Failed to select hwpart\n");
-   fastboot_fail("Failed to select hwpart", response);
+   if (raw_part_get_info_by_name(dev_desc, cmd, &info) != 0) {
+   if (part_get_info_by_name_or_alias(dev_desc, cmd, &info) < 0) {
+   pr_err("cannot find partition: '%s'\n", cmd);
+   fastboot_fail("cannot find partition", response);
return;
}
-   } else if (part_get_info_by_name_or_alias

[PATCH v4 5/9] part: Support string block devices in part_get_info_by_dev_and_name

2021-02-02 Thread Sean Anderson
This adds support for things like "#partname" and "0.1#partname". The block
device parsing is done like in blk_get_device_part_str.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v2)

Changes in v2:
- Update Documentation

 disk/part.c | 41 ++---
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/disk/part.c b/disk/part.c
index 39c6b00a59..aaeafbb0b2 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -692,12 +692,13 @@ int part_get_info_by_name(struct blk_desc *dev_desc, 
const char *name,
  * Get partition info from device number and partition name.
  *
  * Parse a device number and partition name string in the form of
- * "device_num#partition_name", for example "0#misc". If the partition
- * is found, sets dev_desc and part_info accordingly with the information
- * of the partition with the given partition_name.
+ * "devicenum.hwpartnum#partition_name", for example "0.1#misc". devicenum and
+ * hwpartnum are both optional, defaulting to 0. If the partition is found,
+ * sets dev_desc and part_info accordingly with the information of the
+ * partition with the given partition_name.
  *
  * @param[in] dev_iface Device interface
- * @param[in] dev_part_str Input string argument, like "0#misc"
+ * @param[in] dev_part_str Input string argument, like "0.1#misc"
  * @param[out] dev_desc Place to store the device description pointer
  * @param[out] part_info Place to store the partition information
  * @return 0 on success, or a negative on error
@@ -707,29 +708,31 @@ static int part_get_info_by_dev_and_name(const char 
*dev_iface,
 struct blk_desc **dev_desc,
 struct disk_partition *part_info)
 {
-   char *ep;
-   const char *part_str;
-   int dev_num, ret;
+   char *dup_str = NULL;
+   const char *dev_str, *part_str;
+   int ret;
 
+   /* Separate device and partition name specification */
part_str = strchr(dev_part_str, '#');
-   if (!part_str || part_str == dev_part_str)
-   return -EINVAL;
-
-   dev_num = simple_strtoul(dev_part_str, &ep, 16);
-   if (ep != part_str) {
-   /* Not all the first part before the # was parsed. */
+   if (part_str) {
+   dup_str = strdup(dev_part_str);
+   dup_str[part_str - dev_part_str] = 0;
+   dev_str = dup_str;
+   part_str++;
+   } else {
return -EINVAL;
}
-   part_str++;
 
-   *dev_desc = blk_get_dev(dev_iface, dev_num);
-   if (!*dev_desc) {
-   printf("Could not find %s %d\n", dev_iface, dev_num);
-   return -ENODEV;
-   }
+   ret = blk_get_device_by_str(dev_iface, dev_str, dev_desc);
+   if (ret)
+   goto cleanup;
+
ret = part_get_info_by_name(*dev_desc, part_str, part_info);
if (ret < 0)
printf("Could not find \"%s\" partition\n", part_str);
+
+cleanup:
+   free(dup_str);
return ret;
 }
 
-- 
2.25.1



[PATCH v4 4/9] part: Support getting whole disk from part_get_info_by_dev_and_name_or_num

2021-02-02 Thread Sean Anderson
This adds an option to part_get_info_by_dev_and_name_or_num to allow
callers to specify whether whole-disk partitions are fine.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 cmd/ab_select.c | 3 ++-
 disk/part.c | 5 +++--
 include/part.h  | 6 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/cmd/ab_select.c b/cmd/ab_select.c
index 6298fcfb60..3e46663d6e 100644
--- a/cmd/ab_select.c
+++ b/cmd/ab_select.c
@@ -22,7 +22,8 @@ static int do_ab_select(struct cmd_tbl *cmdtp, int flag, int 
argc,
 
/* Lookup the "misc" partition from argv[2] and argv[3] */
if (part_get_info_by_dev_and_name_or_num(argv[2], argv[3],
-&dev_desc, &part_info) < 0) {
+&dev_desc, &part_info,
+false) < 0) {
return CMD_RET_FAILURE;
}
 
diff --git a/disk/part.c b/disk/part.c
index 5e354e256f..39c6b00a59 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -736,7 +736,8 @@ static int part_get_info_by_dev_and_name(const char 
*dev_iface,
 int part_get_info_by_dev_and_name_or_num(const char *dev_iface,
 const char *dev_part_str,
 struct blk_desc **dev_desc,
-struct disk_partition *part_info)
+struct disk_partition *part_info,
+int allow_whole_dev)
 {
int ret;
 
@@ -750,7 +751,7 @@ int part_get_info_by_dev_and_name_or_num(const char 
*dev_iface,
 * directly.
 */
ret = blk_get_device_part_str(dev_iface, dev_part_str,
- dev_desc, part_info, 1);
+ dev_desc, part_info, allow_whole_dev);
if (ret < 0)
printf("Couldn't find partition %s %s\n",
   dev_iface, dev_part_str);
diff --git a/include/part.h b/include/part.h
index 815515aa80..7f78271a98 100644
--- a/include/part.h
+++ b/include/part.h
@@ -227,12 +227,16 @@ int part_get_info_by_name(struct blk_desc *dev_desc,
  * @param[in] dev_part_str Input partition description, like "0#misc" or "0:1"
  * @param[out] dev_descPlace to store the device description pointer
  * @param[out] part_info Place to store the partition information
+ * @param[in] allow_whole_dev true to allow the user to select partition 0
+ * (which means the whole device), false to require a valid
+ * partition number >= 1
  * @return 0 on success, or a negative on error
  */
 int part_get_info_by_dev_and_name_or_num(const char *dev_iface,
 const char *dev_part_str,
 struct blk_desc **dev_desc,
-struct disk_partition *part_info);
+struct disk_partition *part_info,
+int allow_whole_dev);
 
 /**
  * part_set_generic_name() - create generic partition like hda1 or sdb2
-- 
2.25.1



[PATCH v4 3/9] part: Give several functions more useful return values

2021-02-02 Thread Sean Anderson
Several functions in disk/part.c just return -1 on error. This makes them
return different errnos for different failures. This helps callers
differentiate between failures, even if they cannot read stdout.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 disk/part.c | 50 --
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/disk/part.c b/disk/part.c
index b69fd345f3..5e354e256f 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -354,7 +354,7 @@ int part_get_info(struct blk_desc *dev_desc, int part,
}
 #endif /* CONFIG_HAVE_BLOCK_DEVICE */
 
-   return -1;
+   return -ENOENT;
 }
 
 int part_get_info_whole_disk(struct blk_desc *dev_desc,
@@ -416,7 +416,7 @@ int blk_get_device_by_str(const char *ifname, const char 
*dev_hwpart_str,
*dev_desc = get_dev_hwpart(ifname, dev, hwpart);
if (!(*dev_desc) || ((*dev_desc)->type == DEV_TYPE_UNKNOWN)) {
debug("** Bad device %s %s **\n", ifname, dev_hwpart_str);
-   dev = -ENOENT;
+   dev = -ENODEV;
goto cleanup;
}
 
@@ -440,7 +440,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
 struct blk_desc **dev_desc,
 struct disk_partition *info, int allow_whole_dev)
 {
-   int ret = -1;
+   int ret;
const char *part_str;
char *dup_str = NULL;
const char *dev_str;
@@ -482,7 +482,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
if (0 == strcmp(ifname, "ubi")) {
if (!ubifs_is_mounted()) {
printf("UBIFS not mounted, use ubifsmount to mount 
volume first!\n");
-   return -1;
+   return -EINVAL;
}
 
*dev_desc = NULL;
@@ -504,6 +504,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
/* If still no dev_part_str, it's an error */
if (!dev_part_str) {
printf("** No device specified **\n");
+   ret = -ENODEV;
goto cleanup;
}
 
@@ -520,8 +521,10 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
 
/* Look up the device */
dev = blk_get_device_by_str(ifname, dev_str, dev_desc);
-   if (dev < 0)
+   if (dev < 0) {
+   ret = dev;
goto cleanup;
+   }
 
/* Convert partition ID string to number */
if (!part_str || !*part_str) {
@@ -538,6 +541,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
if (*ep || (part == 0 && !allow_whole_dev)) {
printf("** Bad partition specification %s %s **\n",
ifname, dev_part_str);
+   ret = -ENOENT;
goto cleanup;
}
}
@@ -551,6 +555,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
if (!(*dev_desc)->lba) {
printf("** Bad device size - %s %s **\n", ifname,
   dev_str);
+   ret = -EINVAL;
goto cleanup;
}
 
@@ -562,6 +567,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
if ((part > 0) || (!allow_whole_dev)) {
printf("** No partition table - %s %s **\n", ifname,
   dev_str);
+   ret = -EPROTONOSUPPORT;
goto cleanup;
}
 
@@ -630,7 +636,6 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
*info = tmpinfo;
} else {
printf("** No valid partitions found **\n");
-   ret = -1;
goto cleanup;
}
}
@@ -638,7 +643,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
printf("** Invalid partition type \"%.32s\""
" (expect \"" BOOT_PART_TYPE "\")\n",
info->type);
-   ret  = -1;
+   ret  = -EINVAL;
goto cleanup;
}
 
@@ -674,7 +679,7 @@ int part_get_info_by_name_type(struct blk_desc *dev_desc, 
const char *name,
}
}
 
-   return -1;
+   return -ENOENT;
 }
 
 int part_get_info_by_name(struct blk_desc *dev_desc, const char *name,
@@ -704,7 +709,7 @@ static int part_get_info_by_dev_and_name(const char 
*dev_iface,
 {
char *ep;
const char *part_str;
-   int dev_num;
+   int dev_num, ret;
 
part_str = strchr(dev_part_str, '#');
if (!part_str || part_str == dev_part_str)
@@ -720,13 +725,12 @@ static int part

[PATCH v4 2/9] test: dm: Add test for fastboot mmc partition naming

2021-02-02 Thread Sean Anderson
This test verifies the mapping between fastboot partitions and partitions
as understood by U-Boot. It also tests the creation of GPT partitions,
though that is not the primary goal.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 configs/sandbox64_defconfig |  2 ++
 configs/sandbox_defconfig   |  2 ++
 test/dm/Makefile|  3 ++
 test/dm/fastboot.c  | 64 +
 4 files changed, 71 insertions(+)
 create mode 100644 test/dm/fastboot.c

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 4e67819559..9fe07f0c38 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -110,6 +110,8 @@ CONFIG_DM_DEMO=y
 CONFIG_DM_DEMO_SIMPLE=y
 CONFIG_DM_DEMO_SHAPE=y
 CONFIG_DFU_SF=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_GPIO_HOG=y
 CONFIG_DM_GPIO_LOOKUP_LABEL=y
 CONFIG_PM8916_GPIO=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 0c7674efc9..269288783f 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -135,6 +135,8 @@ CONFIG_DFU_SF=y
 CONFIG_DMA=y
 CONFIG_DMA_CHANNELS=y
 CONFIG_SANDBOX_DMA=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_GPIO_HOG=y
 CONFIG_DM_GPIO_LOOKUP_LABEL=y
 CONFIG_PM8916_GPIO=y
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 46e076ed09..be4385c709 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -91,5 +91,8 @@ obj-$(CONFIG_SCMI_FIRMWARE) += scmi.o
 ifneq ($(CONFIG_PINMUX),)
 obj-$(CONFIG_PINCONF) += pinmux.o
 endif
+ifneq ($(CONFIG_EFI_PARTITION)$(CONFIG_FASTBOOT_FLASH_MMC),)
+obj-y += fastboot.o
+endif
 endif
 endif # !SPL
diff --git a/test/dm/fastboot.c b/test/dm/fastboot.c
new file mode 100644
index 00..8f905d8fa8
--- /dev/null
+++ b/test/dm/fastboot.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2015 Google, Inc
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FB_ALIAS_PREFIX "fastboot_partition_alias_"
+
+static int dm_test_fastboot_mmc_part(struct unit_test_state *uts)
+{
+   char response[FASTBOOT_RESPONSE_LEN] = {0};
+   char str_disk_guid[UUID_STR_LEN + 1];
+   struct blk_desc *mmc_dev_desc, *fb_dev_desc;
+   struct disk_partition part_info;
+   struct disk_partition parts[2] = {
+   {
+   .start = 48, /* GPT data takes up the first 34 blocks 
or so */
+   .size = 1,
+   .name = "test1",
+   },
+   {
+   .start = 49,
+   .size = 1,
+   .name = "test2",
+   },
+   };
+
+   ut_assertok(blk_get_device_by_str("mmc",
+ 
__stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV),
+ &mmc_dev_desc));
+   if (CONFIG_IS_ENABLED(RANDOM_UUID)) {
+   gen_rand_uuid_str(parts[0].uuid, UUID_STR_FORMAT_STD);
+   gen_rand_uuid_str(parts[1].uuid, UUID_STR_FORMAT_STD);
+   gen_rand_uuid_str(str_disk_guid, UUID_STR_FORMAT_STD);
+   }
+   ut_assertok(gpt_restore(mmc_dev_desc, str_disk_guid, parts,
+   ARRAY_SIZE(parts)));
+
+   /* "Classic" partition labels */
+   ut_asserteq(1, fastboot_mmc_get_part_info("test1", &fb_dev_desc,
+ &part_info, response));
+   ut_asserteq(2, fastboot_mmc_get_part_info("test2", &fb_dev_desc,
+ &part_info, response));
+
+   /* Test aliases */
+   ut_assertnull(env_get(FB_ALIAS_PREFIX "test3"));
+   ut_assertok(env_set(FB_ALIAS_PREFIX "test3", "test1"));
+   ut_asserteq(1, fastboot_mmc_get_part_info("test3", &fb_dev_desc,
+ &part_info, response));
+   ut_assertok(env_set(FB_ALIAS_PREFIX "test3", NULL));
+
+   return 0;
+}
+DM_TEST(dm_test_fastboot_mmc_part, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
-- 
2.25.1



[PATCH v4 1/9] mmc: sandbox: Add support for writing

2021-02-02 Thread Sean Anderson
This adds support writing to the sandbox mmc backed by an in-memory
buffer. The unit test has been updated to test reading, writing, and
erasing. I'm not sure what MMCs erase to; I picked 0, but if it's 0xFF
then that can be easily changed.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

Changes in v4:
- xxx_auto_alloc_size -> xxx_auto

 drivers/mmc/sandbox_mmc.c | 43 +--
 test/dm/mmc.c | 19 -
 2 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/sandbox_mmc.c b/drivers/mmc/sandbox_mmc.c
index 8a2391d651..18ba020aac 100644
--- a/drivers/mmc/sandbox_mmc.c
+++ b/drivers/mmc/sandbox_mmc.c
@@ -17,6 +17,17 @@ struct sandbox_mmc_plat {
struct mmc mmc;
 };
 
+#define MMC_CSIZE 0
+#define MMC_CMULT 8 /* 8 because the card is high-capacity */
+#define MMC_BL_LEN_SHIFT 10
+#define MMC_BL_LEN BIT(MMC_BL_LEN_SHIFT)
+#define MMC_CAPACITY (((MMC_CSIZE + 1) << (MMC_CMULT + 2)) \
+ * MMC_BL_LEN) /* 1 MiB */
+
+struct sandbox_mmc_priv {
+   u8 buf[MMC_CAPACITY];
+};
+
 /**
  * sandbox_mmc_send_cmd() - Emulate SD commands
  *
@@ -26,6 +37,10 @@ struct sandbox_mmc_plat {
 static int sandbox_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
struct mmc_data *data)
 {
+   struct sandbox_mmc_priv *priv = dev_get_priv(dev);
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+   static ulong erase_start, erase_end;
+
switch (cmd->cmdidx) {
case MMC_CMD_ALL_SEND_CID:
memset(cmd->response, '\0', sizeof(cmd->response));
@@ -44,8 +59,9 @@ static int sandbox_mmc_send_cmd(struct udevice *dev, struct 
mmc_cmd *cmd,
break;
case MMC_CMD_SEND_CSD:
cmd->response[0] = 0;
-   cmd->response[1] = 10 << 16;/* 1 << block_len */
-   cmd->response[2] = 0;
+   cmd->response[1] = (MMC_BL_LEN_SHIFT << 16) |
+  ((MMC_CSIZE >> 16) & 0x3f);
+   cmd->response[2] = (MMC_CSIZE & 0x) << 16;
cmd->response[3] = 0;
break;
case SD_CMD_SWITCH_FUNC: {
@@ -59,13 +75,27 @@ static int sandbox_mmc_send_cmd(struct udevice *dev, struct 
mmc_cmd *cmd,
break;
}
case MMC_CMD_READ_SINGLE_BLOCK:
-   memset(data->dest, '\0', data->blocksize);
-   break;
case MMC_CMD_READ_MULTIPLE_BLOCK:
-   strcpy(data->dest, "this is a test");
+   memcpy(data->dest, &priv->buf[cmd->cmdarg * data->blocksize],
+  data->blocks * data->blocksize);
+   break;
+   case MMC_CMD_WRITE_SINGLE_BLOCK:
+   case MMC_CMD_WRITE_MULTIPLE_BLOCK:
+   memcpy(&priv->buf[cmd->cmdarg * data->blocksize], data->src,
+  data->blocks * data->blocksize);
break;
case MMC_CMD_STOP_TRANSMISSION:
break;
+   case SD_CMD_ERASE_WR_BLK_START:
+   erase_start = cmd->cmdarg;
+   break;
+   case SD_CMD_ERASE_WR_BLK_END:
+   erase_end = cmd->cmdarg;
+   break;
+   case MMC_CMD_ERASE:
+   memset(&priv->buf[erase_start * mmc->write_bl_len], '\0',
+  (erase_end - erase_start + 1) * mmc->write_bl_len);
+   break;
case SD_CMD_APP_SEND_OP_COND:
cmd->response[0] = OCR_BUSY | OCR_HCS;
cmd->response[1] = 0;
@@ -148,5 +178,6 @@ U_BOOT_DRIVER(mmc_sandbox) = {
.bind   = sandbox_mmc_bind,
.unbind = sandbox_mmc_unbind,
.probe  = sandbox_mmc_probe,
-   .plat_auto  = sizeof(struct sandbox_mmc_plat),
+   .priv_auto = sizeof(struct sandbox_mmc_priv),
+   .plat_auto = sizeof(struct sandbox_mmc_plat),
 };
diff --git a/test/dm/mmc.c b/test/dm/mmc.c
index 4e5136c850..f744452ff2 100644
--- a/test/dm/mmc.c
+++ b/test/dm/mmc.c
@@ -29,16 +29,25 @@ static int dm_test_mmc_blk(struct unit_test_state *uts)
 {
struct udevice *dev;
struct blk_desc *dev_desc;
-   char cmp[1024];
+   int i;
+   char write[1024], read[1024];
 
ut_assertok(uclass_get_device(UCLASS_MMC, 0, &dev));
ut_assertok(blk_get_device_by_str("mmc", "0", &dev_desc));
 
-   /* Read a few blocks and look for the string we expect */
+   /* Write a few blocks and verify that we get the same data back */
ut_asserteq(512, dev_desc->blksz);
-   memset(cmp, '\0', sizeof(cmp));
-   ut_asserteq(2, blk_dread(dev_desc, 0, 2, cmp));
-   ut_assertok(strcmp(cmp, "this is a test"));
+   for (i = 0; i < sizeof(write); i++)
+   write[i] = i;
+   ut_asserteq(2, blk_dwrite(dev_desc, 0, 2, write));
+   ut_asserteq(2, blk_dread(dev_desc, 0, 2, read));
+   ut_asserteq_mem(write, read, sizeof(write));
+
+   /* Now erase them */
+   memset(write

[PATCH v4 0/9] fastboot: Add better support for specifying partitions

2021-02-02 Thread Sean Anderson
This series adds support for flashing eMMC boot partitions, and for
flashing whole partitions. Specifically, it does this by using the
existing U-Boot naming scheme to specify partitions, and not by adding
new KConfig options.

I have added tests for partition naming, but not for the whole flash
process (though that could be a future project). I have tested this on
one board, but I have *not* tested the mt85-specific KConfigs. Hopefully
this series can be a way to phase out those options.

Changes in v4:
- xxx_auto_alloc_size -> xxx_auto
- Fix missing closing brace
- Expand documentation, making it more man-page-like

Changes in v3:
- Rebase onto dfu/master

Changes in v2:
- Update documentation for part_get_info_by_dev_and_name
- Move partition documentation under doc/usage

Sean Anderson (9):
  mmc: sandbox: Add support for writing
  test: dm: Add test for fastboot mmc partition naming
  part: Give several functions more useful return values
  part: Support getting whole disk from
part_get_info_by_dev_and_name_or_num
  part: Support string block devices in part_get_info_by_dev_and_name
  fastboot: Remove mmcpart argument from raw_part_get_info_by_name
  fastboot: Move part_get_info_by_name_or_alias after
raw_part_get_info_by_name
  fastboot: Allow u-boot-style partitions
  fastboot: Partition specification

 cmd/ab_select.c |   3 +-
 configs/sandbox64_defconfig |   2 +
 configs/sandbox_defconfig   |   2 +
 disk/part.c |  90 +---
 doc/android/fastboot.rst|   4 +
 doc/usage/index.rst |   1 +
 doc/usage/partitions.rst|  80 ++
 drivers/fastboot/fb_mmc.c   | 210 +---
 drivers/mmc/sandbox_mmc.c   |  43 ++--
 include/part.h  |   6 +-
 test/dm/Makefile|   3 +
 test/dm/fastboot.c  |  95 
 test/dm/mmc.c   |  19 +++-
 13 files changed, 417 insertions(+), 141 deletions(-)
 create mode 100644 doc/usage/partitions.rst
 create mode 100644 test/dm/fastboot.c

-- 
2.25.1



Re: [PATCH 0/3] arm: mvebu: Espressobin: Set default env values at runtime

2021-02-02 Thread Pali Rohár
On Tuesday 02 February 2021 16:09:03 Stefan Roese wrote:
> Hi Pali,
> Hi Andre,
> 
> On 12.01.21 10:24, Pali Rohár wrote:
> > Hello!
> > 
> > On Tuesday 12 January 2021 09:18:44 Andre Heider wrote:
> > > Hi Pali,
> > > 
> > > On 11/01/2021 11:51, Pali Rohár wrote:
> > > > Hello Stefan and Andre!
> > > > 
> > > > Could you please look at this patch series and tell me what do you think
> > > > about it? If it is fine or needs to take different approach?
> > > 
> > > I like the idea very much, and I bet there're quite some boards which 
> > > could
> > > make good use of "immutable envvars".
> > > 
> > > The obvious review point is the filler thing and its dependency on
> > > DEFAULT_ENV_IS_RW, which probably won't win a beauty contest :) Maybe a
> > > nicer integration would help in getting it merged?
> > > 
> > > I don't think it would take too much effort, first thing that comes to 
> > > mind:
> > > - board provides list of immutable vars
> > > - env_set_default() backs up these vars
> > > - env_set_default() imports default_environment
> > > - env_set_default() imports backup on top
> > > 
> > > The last step should be easy, see env_set_default_vars().
> > 
> > This could probably work for $ethNaddr variables.
> > 
> > But there is still an issue how to handle $fdtfile. There is basically
> > default value for this variable, but value itself cannot be determined
> > at compile time, only at runtime. And for it variable flags do not help,
> > we just need an mechanism how to set default variable values not only at
> > compile time but also runtime.
> > 
> > That is why I chosen for now solution with modifying
> > default_environment[] array as it solve issue for both $fdtfile and
> > $ethNaddr variables.
> 
> So what is the outcome of this discussion? Andre, do you see any
> hindering points in this patch series, apart from it not winning a
> "beauty contest"? ;)

Hello! I have looked at it again and I can say that implementing a new
"immutable" bit for ethNaddr env variables would be better / cleaner
solution. But as I wrote for fdtfile env variable that immutable bit
does not help and we need some option how to set default value of this
variable at the runtime.

> I tend to pull it in shortly, if nobody objects.

Andre thought that other u-boot developers would not like this approach.
But I have not received any response, so I do not know if just nobody
looked at this patch or more people looked at it and did not have
objections.

Anyway, Andre are you going to look & implement for ethNaddr env
variables that approach via immutable bits?

I think current implementation can be changed at anytime in future.

> Thanks,
> Stefan
> 
> > > Maybe the first step can be solved with ENV_FLAGS_VAR, a new immutable 
> > > flag,
> > > and boards just making use of CONFIG_ENV_FLAGS_LIST_DEFAULT to declare
> > > those. But I fail to find an example in-tree.
> > > 
> > > Thanks,
> > > Andre
> > > 
> > > > 
> > > > On Wednesday 23 December 2020 12:21:27 Pali Rohár wrote:
> > > > > This patch series set default env values of $fdtfile and $ethNaddr for
> > > > > Espressobin board at runtime.
> > > > > 
> > > > > It fixes two main issues on Espressobin board that 'env default -a'
> > > > > completely erases permanent board MAC addresses and also erase 
> > > > > $fdtfile
> > > > > variable which is needed for booting Linux kernel via distro boot.
> > > > > 
> > > > > Lot of people were complaining about erasing permanent MAC addresses 
> > > > > by
> > > > > U-boot on this board and due to this issue some linux distributions
> > > > > started using static hardcoded MAC addresses for all Espressobin 
> > > > > boards
> > > > > to workaround this issue. Apparently erase of MAC addresses or usage 
> > > > > of
> > > > > static hardcoded value caused more issues on network (e.g. inability 
> > > > > to
> > > > > connect two of these boards to the same network).
> > > > > 
> > > > > Pali Rohár (3):
> > > > > env: Allow to set default_environment[] from board code via 
> > > > > compile
> > > > >   option DEFAULT_ENV_IS_RW
> > > > > arm: mvebu: Espressobin: Set default value for $fdtfile env 
> > > > > variable
> > > > > arm: mvebu: Espressobin: Set default value for $ethNaddr env 
> > > > > variable
> > > > > 
> > > > >board/Marvell/mvebu_armada-37xx/board.c | 41 
> > > > > -
> > > > >include/configs/mvebu_armada-37xx.h | 17 +-
> > > > >include/env_default.h   |  2 ++
> > > > >include/env_internal.h  |  4 +++
> > > > >4 files changed, 56 insertions(+), 8 deletions(-)
> > > > > 
> > > > > -- 
> > > > > 2.20.1
> > > > > 
> > > 
> 
> 
> Viele Grüße,
> Stefan
> 
> -- 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH 0/3] arm: mvebu: Espressobin: Set default env values at runtime

2021-02-02 Thread Stefan Roese

Hi Pali,
Hi Andre,

On 12.01.21 10:24, Pali Rohár wrote:

Hello!

On Tuesday 12 January 2021 09:18:44 Andre Heider wrote:

Hi Pali,

On 11/01/2021 11:51, Pali Rohár wrote:

Hello Stefan and Andre!

Could you please look at this patch series and tell me what do you think
about it? If it is fine or needs to take different approach?


I like the idea very much, and I bet there're quite some boards which could
make good use of "immutable envvars".

The obvious review point is the filler thing and its dependency on
DEFAULT_ENV_IS_RW, which probably won't win a beauty contest :) Maybe a
nicer integration would help in getting it merged?

I don't think it would take too much effort, first thing that comes to mind:
- board provides list of immutable vars
- env_set_default() backs up these vars
- env_set_default() imports default_environment
- env_set_default() imports backup on top

The last step should be easy, see env_set_default_vars().


This could probably work for $ethNaddr variables.

But there is still an issue how to handle $fdtfile. There is basically
default value for this variable, but value itself cannot be determined
at compile time, only at runtime. And for it variable flags do not help,
we just need an mechanism how to set default variable values not only at
compile time but also runtime.

That is why I chosen for now solution with modifying
default_environment[] array as it solve issue for both $fdtfile and
$ethNaddr variables.


So what is the outcome of this discussion? Andre, do you see any
hindering points in this patch series, apart from it not winning a
"beauty contest"? ;)

I tend to pull it in shortly, if nobody objects.

Thanks,
Stefan


Maybe the first step can be solved with ENV_FLAGS_VAR, a new immutable flag,
and boards just making use of CONFIG_ENV_FLAGS_LIST_DEFAULT to declare
those. But I fail to find an example in-tree.

Thanks,
Andre



On Wednesday 23 December 2020 12:21:27 Pali Rohár wrote:

This patch series set default env values of $fdtfile and $ethNaddr for
Espressobin board at runtime.

It fixes two main issues on Espressobin board that 'env default -a'
completely erases permanent board MAC addresses and also erase $fdtfile
variable which is needed for booting Linux kernel via distro boot.

Lot of people were complaining about erasing permanent MAC addresses by
U-boot on this board and due to this issue some linux distributions
started using static hardcoded MAC addresses for all Espressobin boards
to workaround this issue. Apparently erase of MAC addresses or usage of
static hardcoded value caused more issues on network (e.g. inability to
connect two of these boards to the same network).

Pali Rohár (3):
env: Allow to set default_environment[] from board code via compile
  option DEFAULT_ENV_IS_RW
arm: mvebu: Espressobin: Set default value for $fdtfile env variable
arm: mvebu: Espressobin: Set default value for $ethNaddr env variable

   board/Marvell/mvebu_armada-37xx/board.c | 41 -
   include/configs/mvebu_armada-37xx.h | 17 +-
   include/env_default.h   |  2 ++
   include/env_internal.h  |  4 +++
   4 files changed, 56 insertions(+), 8 deletions(-)

--
2.20.1






Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH] arm: mvebu: Espressobin: Set the maximum slave SPI speed to 40MHz

2021-02-02 Thread Stefan Roese

On 27.01.21 17:12, Pali Rohár wrote:

From: Konstantin Porotchkin 

While the SPI controller speed is defined by DTS, the maximum
slave speed (connected devices) is limited by the pre-defined
configuration value CONFIG_SF_DEFAULT_SPEED to 1MHz
This patch increases this maximum SPI slave device speed to 40MHz

Change-Id: I0d1239bd8a2061c66725c2c227c1e1f49c92c29e
Signed-off-by: Konstantin Porotchkin 
Reviewed-on: http://vgitil04.il.marvell.com:8080/59516
Tested-by: iSoC Platform CI 
Reviewed-by: Igal Liberman 
[pali: Set CONFIG_SF_DEFAULT_SPEED via defconfig]
Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  configs/mvebu_espressobin-88f3720_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index 8a859cba2e..4956199ccd 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -54,6 +54,7 @@ CONFIG_MMC_SDHCI_SDMA=y
  CONFIG_MMC_SDHCI_XENON=y
  CONFIG_MTD=y
  CONFIG_SF_DEFAULT_MODE=0
+CONFIG_SF_DEFAULT_SPEED=4000
  CONFIG_SPI_FLASH_GIGADEVICE=y
  CONFIG_SPI_FLASH_ISSI=y
  CONFIG_SPI_FLASH_MACRONIX=y




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH] version: Move version_string[] from version.h to version_string.h

2021-02-02 Thread Stefan Roese

On 27.01.21 16:56, Pali Rohár wrote:

More C files do not use compile time timestamp macros and do not have to be
recompiled every time when SOURCE_DATE_EPOCH changes.

This patch moves version_string[] from version.h to version_string.h and
updates other C files which only needs version_string[] string to include
version_string.h instead of version.h. After applying this patch these
files are not recompiled every time when SOURCE_DATE_EPOCH changes.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/ge/b1x5v2/b1x5v2.c| 2 +-
  board/ge/bx50v3/bx50v3.c| 2 +-
  board/ge/mx53ppd/mx53ppd.c  | 2 +-
  cmd/version.c   | 1 +
  common/main.c   | 2 +-
  drivers/video/cfb_console.c | 3 +--
  include/version.h   | 3 ---
  include/version_string.h| 8 
  lib/display_options.c   | 2 +-
  test/print_ut.c | 2 +-
  10 files changed, 16 insertions(+), 11 deletions(-)
  create mode 100644 include/version_string.h

diff --git a/board/ge/b1x5v2/b1x5v2.c b/board/ge/b1x5v2/b1x5v2.c
index 1cb347fd9e..18ba5c9e71 100644
--- a/board/ge/b1x5v2/b1x5v2.c
+++ b/board/ge/b1x5v2/b1x5v2.c
@@ -29,7 +29,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  
  #include "../common/vpd_reader.h"
  
diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c

index 3ea9425fd1..faad9cef72 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -32,7 +32,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  #include "../common/ge_rtc.h"
diff --git a/board/ge/mx53ppd/mx53ppd.c b/board/ge/mx53ppd/mx53ppd.c
index ef689733c4..9a76cdc388 100644
--- a/board/ge/mx53ppd/mx53ppd.c
+++ b/board/ge/mx53ppd/mx53ppd.c
@@ -32,7 +32,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include "ppd_gpio.h"
  #include 
diff --git a/cmd/version.c b/cmd/version.c
index 3686b87332..b183cc8b63 100644
--- a/cmd/version.c
+++ b/cmd/version.c
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #ifdef CONFIG_SYS_COREBOOT
  #include 
diff --git a/common/main.c b/common/main.c
index ae5bcdb32f..3f5214fd44 100644
--- a/common/main.c
+++ b/common/main.c
@@ -15,7 +15,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  
  static void run_preboot_environment_command(void)

diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 3f07f4eb29..1a471ce07b 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -71,7 +71,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  #include 
@@ -121,7 +121,6 @@
   * Console device
   */
  
-#include 

  #include 
  #include 
  #include 
diff --git a/include/version.h b/include/version.h
index 2d24451569..0a3b29adb8 100644
--- a/include/version.h
+++ b/include/version.h
@@ -16,7 +16,4 @@
  #define U_BOOT_VERSION_STRING U_BOOT_VERSION " (" U_BOOT_DATE " - " \
U_BOOT_TIME " " U_BOOT_TZ ")" CONFIG_IDENT_STRING
  
-#ifndef __ASSEMBLY__

-extern const char version_string[];
-#endif /* __ASSEMBLY__ */
  #endif/* __VERSION_H__ */
diff --git a/include/version_string.h b/include/version_string.h
new file mode 100644
index 00..a89a6e4370
--- /dev/null
+++ b/include/version_string.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef__VERSION_STRING_H__
+#define__VERSION_STRING_H__
+
+extern const char version_string[];
+
+#endif /* __VERSION_STRING_H__ */
diff --git a/lib/display_options.c b/lib/display_options.c
index b2025eeb5c..1b069761f8 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -8,7 +8,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  
diff --git a/test/print_ut.c b/test/print_ut.c

index a456a449ef..ae1cf85f1c 100644
--- a/test/print_ut.c
+++ b/test/print_ut.c
@@ -12,7 +12,7 @@
  #endif
  #include 
  #include 
-#include 
+#include 
  
  #define FAKE_BUILD_TAG	"jenkins-u-boot-denx_uboot_dm-master-build-aarch64" \

"and a lot more text to come"




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH] cmd: mvebu/bubt: Fix default options in help

2021-02-02 Thread Stefan Roese

On 27.01.21 11:56, Pali Rohár wrote:

Default options depends on compile time defines.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  cmd/mvebu/bubt.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 4c58fd3c2e..b64996320c 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -874,9 +874,9 @@ U_BOOT_CMD(
bubt, 4, 0, do_bubt_cmd,
"Burn a u-boot image to flash",
"[file-name] [destination [source]]\n"
-   "\t-file-name The image file name to burn. Default = 
flash-image.bin\n"
-   "\t-destination   Flash to burn to [spi, nand, mmc]. Default = active boot 
device\n"
-   "\t-sourceThe source to load image from [tftp, usb, mmc]. Default = 
tftp\n"
+   "\t-file-name The image file name to burn. Default = " 
CONFIG_MVEBU_UBOOT_DFLT_NAME "\n"
+   "\t-destination   Flash to burn to [spi, nand, mmc]. Default = " DEFAULT_BUBT_DST 
"\n"
+   "\t-sourceThe source to load image from [tftp, usb, mmc]. Default = " 
DEFAULT_BUBT_SRC "\n"
"Examples:\n"
"\tbubt - Burn flash-image.bin from tftp to active boot device\n"
"\tbubt flash-image-new.bin nand - Burn flash-image-new.bin from tftp to 
NAND flash\n"




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH v3 1/1] env: sf: single function env_sf_save()

2021-02-02 Thread Stefan Roese

On 02.02.21 15:43, Harry Waschkeit wrote:


On 02.02.21 10:30, Stefan Roese wrote:

On 02.02.21 09:21, Harry Waschkeit wrote:

Instead of implementing redundant environments in two very similar
functions env_sf_save(), handle redundancy in one function, placing the
few differences in appropriate pre-compiler sections depending on config
option CONFIG_ENV_OFFSET_REDUND.

Additionally, several checkpatch complaints were addressed.

This patch is in preparation for adding support for env erase.

Signed-off-by: Harry Waschkeit 
Reviewed-by: Stefan Roese 
---
Change in v3:
  - no change in patch, only added "reviewed-by" to commit log


JFYI:
No need to re-send this patch with this added RB tag, as I already did
send a new RB to the last mail as reply. Patchwork collects these tags
when sent to the list. So you only need to include them, if you send
a new patch version.


thanks for this hint, obviously I step into it all the time ...

Ok, lesson learnt, let's see what I can do wrong next time ... ;-/

Back on topic: I guess that was all I needed to do so that the patch 
will get merged when its time comes.


Yes, now we (you) need a bit of patience, so that other people might
review this patch as well. And usually it will get handled after some
time (depending on the development stage of U-Boot, merge window open
or shortly before release etc).

It does not hurt of course to check this from time to time and
"trigger" the maintainer of the subsystem or the custodian this
patch is delegated to nothing is happening here for a too long
time (like more than 1 month).

Thanks,
Stefan


If not, please let me know.

Thanks,
Harry


Thanks,
Stefan


Change in v2:
  - remove one more #ifdef, instead take advantage of compiler attribute
    __maybe_unused for one variable used only in case of redundant
    environments

  env/sf.c | 130 ++-
  1 file changed, 41 insertions(+), 89 deletions(-)

diff --git a/env/sf.c b/env/sf.c
index 937778aa37..199114fd3b 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -66,13 +66,14 @@ static int setup_flash_device(void)
  return 0;
  }
-#if defined(CONFIG_ENV_OFFSET_REDUND)
  static int env_sf_save(void)
  {
  env_t    env_new;
-    char    *saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
+    char    *saved_buffer = NULL;
  u32    saved_size, saved_offset, sector;
+    ulong    offset;
  int    ret;
+    __maybe_unused char flag = ENV_REDUND_OBSOLETE;
  ret = setup_flash_device();
  if (ret)
@@ -81,27 +82,33 @@ static int env_sf_save(void)
  ret = env_export(&env_new);
  if (ret)
  return -EIO;
-    env_new.flags    = ENV_REDUND_ACTIVE;
-    if (gd->env_valid == ENV_VALID) {
-    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
-    env_offset = CONFIG_ENV_OFFSET;
-    } else {
-    env_new_offset = CONFIG_ENV_OFFSET;
-    env_offset = CONFIG_ENV_OFFSET_REDUND;
-    }
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+    env_new.flags    = ENV_REDUND_ACTIVE;
+
+    if (gd->env_valid == ENV_VALID) {
+    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+    env_offset = CONFIG_ENV_OFFSET;
+    } else {
+    env_new_offset = CONFIG_ENV_OFFSET;
+    env_offset = CONFIG_ENV_OFFSET_REDUND;
+    }
+    offset = env_new_offset;
+#else
+    offset = CONFIG_ENV_OFFSET;
+#endif
  /* Is the sector larger than the env (i.e. embedded) */
  if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
  saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
-    saved_offset = env_new_offset + CONFIG_ENV_SIZE;
+    saved_offset = offset + CONFIG_ENV_SIZE;
  saved_buffer = memalign(ARCH_DMA_MINALIGN, saved_size);
  if (!saved_buffer) {
  ret = -ENOMEM;
  goto done;
  }
-    ret = spi_flash_read(env_flash, saved_offset,
-    saved_size, saved_buffer);
+    ret = spi_flash_read(env_flash, saved_offset, saved_size,
+ saved_buffer);
  if (ret)
  goto done;
  }
@@ -109,35 +116,39 @@ static int env_sf_save(void)
  sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
  puts("Erasing SPI flash...");
-    ret = spi_flash_erase(env_flash, env_new_offset,
-    sector * CONFIG_ENV_SECT_SIZE);
+    ret = spi_flash_erase(env_flash, offset,
+  sector * CONFIG_ENV_SECT_SIZE);
  if (ret)
  goto done;
  puts("Writing to SPI flash...");
-    ret = spi_flash_write(env_flash, env_new_offset,
-    CONFIG_ENV_SIZE, &env_new);
+    ret = spi_flash_write(env_flash, offset,
+  CONFIG_ENV_SIZE, &env_new);
  if (ret)
  goto done;
  if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
-    ret = spi_flash_write(env_flash, saved_offset,
-    saved_size, saved_buffer);
+    ret = spi_flash_write(env_flash, saved_offset, saved_size,
+  

Re: [PATCH v3 1/1] env: sf: single function env_sf_save()

2021-02-02 Thread Harry Waschkeit


On 02.02.21 10:30, Stefan Roese wrote:

On 02.02.21 09:21, Harry Waschkeit wrote:

Instead of implementing redundant environments in two very similar
functions env_sf_save(), handle redundancy in one function, placing the
few differences in appropriate pre-compiler sections depending on config
option CONFIG_ENV_OFFSET_REDUND.

Additionally, several checkpatch complaints were addressed.

This patch is in preparation for adding support for env erase.

Signed-off-by: Harry Waschkeit 
Reviewed-by: Stefan Roese 
---
Change in v3:
  - no change in patch, only added "reviewed-by" to commit log


JFYI:
No need to re-send this patch with this added RB tag, as I already did
send a new RB to the last mail as reply. Patchwork collects these tags
when sent to the list. So you only need to include them, if you send
a new patch version.


thanks for this hint, obviously I step into it all the time ...

Ok, lesson learnt, let's see what I can do wrong next time ... ;-/

Back on topic: I guess that was all I needed to do so that the patch will get 
merged when its time comes.

If not, please let me know.

Thanks,
Harry


Thanks,
Stefan


Change in v2:
  - remove one more #ifdef, instead take advantage of compiler attribute
    __maybe_unused for one variable used only in case of redundant
    environments

  env/sf.c | 130 ++-
  1 file changed, 41 insertions(+), 89 deletions(-)

diff --git a/env/sf.c b/env/sf.c
index 937778aa37..199114fd3b 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -66,13 +66,14 @@ static int setup_flash_device(void)
  return 0;
  }
-#if defined(CONFIG_ENV_OFFSET_REDUND)
  static int env_sf_save(void)
  {
  env_t    env_new;
-    char    *saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
+    char    *saved_buffer = NULL;
  u32    saved_size, saved_offset, sector;
+    ulong    offset;
  int    ret;
+    __maybe_unused char flag = ENV_REDUND_OBSOLETE;
  ret = setup_flash_device();
  if (ret)
@@ -81,27 +82,33 @@ static int env_sf_save(void)
  ret = env_export(&env_new);
  if (ret)
  return -EIO;
-    env_new.flags    = ENV_REDUND_ACTIVE;
-    if (gd->env_valid == ENV_VALID) {
-    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
-    env_offset = CONFIG_ENV_OFFSET;
-    } else {
-    env_new_offset = CONFIG_ENV_OFFSET;
-    env_offset = CONFIG_ENV_OFFSET_REDUND;
-    }
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+    env_new.flags    = ENV_REDUND_ACTIVE;
+
+    if (gd->env_valid == ENV_VALID) {
+    env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+    env_offset = CONFIG_ENV_OFFSET;
+    } else {
+    env_new_offset = CONFIG_ENV_OFFSET;
+    env_offset = CONFIG_ENV_OFFSET_REDUND;
+    }
+    offset = env_new_offset;
+#else
+    offset = CONFIG_ENV_OFFSET;
+#endif
  /* Is the sector larger than the env (i.e. embedded) */
  if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
  saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
-    saved_offset = env_new_offset + CONFIG_ENV_SIZE;
+    saved_offset = offset + CONFIG_ENV_SIZE;
  saved_buffer = memalign(ARCH_DMA_MINALIGN, saved_size);
  if (!saved_buffer) {
  ret = -ENOMEM;
  goto done;
  }
-    ret = spi_flash_read(env_flash, saved_offset,
-    saved_size, saved_buffer);
+    ret = spi_flash_read(env_flash, saved_offset, saved_size,
+ saved_buffer);
  if (ret)
  goto done;
  }
@@ -109,35 +116,39 @@ static int env_sf_save(void)
  sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
  puts("Erasing SPI flash...");
-    ret = spi_flash_erase(env_flash, env_new_offset,
-    sector * CONFIG_ENV_SECT_SIZE);
+    ret = spi_flash_erase(env_flash, offset,
+  sector * CONFIG_ENV_SECT_SIZE);
  if (ret)
  goto done;
  puts("Writing to SPI flash...");
-    ret = spi_flash_write(env_flash, env_new_offset,
-    CONFIG_ENV_SIZE, &env_new);
+    ret = spi_flash_write(env_flash, offset,
+  CONFIG_ENV_SIZE, &env_new);
  if (ret)
  goto done;
  if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
-    ret = spi_flash_write(env_flash, saved_offset,
-    saved_size, saved_buffer);
+    ret = spi_flash_write(env_flash, saved_offset, saved_size,
+  saved_buffer);
  if (ret)
  goto done;
  }
-    ret = spi_flash_write(env_flash, env_offset + offsetof(env_t, flags),
-    sizeof(env_new.flags), &flag);
-    if (ret)
-    goto done;
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+    ret = spi_flash_write(env_flash, env_offset + offsetof(env_t, flags),
+  sizeof(env_new.flags), &flag);
+    if (ret)
+    goto done;
-    puts("done\n");
+    puts("done\n");
-    gd->env_valid = gd->env_v

Re: [PATCH] azure: Add -E back for the world build script

2021-02-02 Thread Tom Rini
On Sun, Jan 31, 2021 at 04:38:35PM +0800, Bin Meng wrote:

> Commit dd5c954e917b ("travis/gitlab/azure: Use -W to avoid warnings check")
> added -W to avoid warnings check, but it mistakenly dropped -E for
> the world build script in the azure pipelines.
> 
> This caused builds on the azure pipelines fail to report warnings. Let's
> add it back.
> 
> Fixes: dd5c954e917b ("travis/gitlab/azure: Use -W to avoid warnings check")
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] test/py: fix runtest wrapper for pytest 6

2021-02-02 Thread Tom Rini
On Sat, Jan 30, 2021 at 08:12:18PM -0700, Stephen Warren wrote:

> The implementation of pytest_runtest_protocol() must call
> pytest_runtest_logstart() and pytest_runtest_logfinish(). This appears to
> be necessary even in pytest 5.2.1 judging by the default version of
> pytest_runtest_protocol(), but evidently some form of code reorganization
> in pytest only made this have a practical effect in the newer version. I'd
> previously been under the impression that 100% of the required work of
> pytest_runtest_protocol() was handled by the fact it called
> runtestprotocol() as its implementation. However, it appears that custom
> implementations do need to do a little more than this.
> 
> Reported-by: Heinrich Schuchardt 
> Signed-off-by: Stephen Warren 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] MAINTAINERS: Add maintainer to network subsystem

2021-02-02 Thread Tom Rini
On Fri, Jan 29, 2021 at 06:18:22PM +0200, Ramon Fried wrote:

> Add myself as co maintainer to network subsystem
> Acked-by: Tom Rini 
> Acked-by: Marek Vasut 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] disk: part_dos: update partition table entries after write

2021-02-02 Thread Tom Rini
On Thu, Jan 28, 2021 at 09:10:07AM +0100, Gary Bisson wrote:

> Fixes issues when switching from GPT to MBR partition tables.
> 
> Signed-off-by: Gary Bisson 
> Acked-by: Marek Szyprowski 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] common: Kconfig.boot: Add FIT_PRINT config option

2021-02-02 Thread Tom Rini
On Wed, Jan 27, 2021 at 02:01:48PM -0800, Ravik Hasija wrote:

> Config allows to disable printing contents of fitImage to optimize boottime.
> 
> Signed-off-by: Ravik Hasija 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] cmd: load, emit error message for invalid block device

2021-02-02 Thread Tom Rini
On Wed, Jan 27, 2021 at 09:26:43PM +0100, Heinrich Schuchardt wrote:

> The load command should not silently return to the console prompt if an
> invalid block device is specified and no file is loaded.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm: Remove #include from armv8/fwcall.c

2021-02-02 Thread Tom Rini
On Wed, Jan 27, 2021 at 04:29:13PM +0100, Pali Rohár wrote:

> No version information is used in armv8/fwcall.c therefore do not include
> version.h header file. This change prevents recompiling fwcall.o when
> SOURCE_DATE_EPOCH changes.
> 
> Signed-off-by: Pali Rohár 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] tools/fit_check_sign.c: Update usage function.

2021-02-02 Thread Tom Rini
On Sun, Jan 17, 2021 at 03:52:16PM +, Ilies CHERGUI wrote:

> Add "-c" option to set the configuration name when
> checking the FIT image signature.
> 
> Signed-off-by: Ilies CHERGUI 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: MX6sabresd broken since v2019.04

2021-02-02 Thread Heiko Schocher
Hello Fabio,

Am 02.02.21 um 15:12 schrieb Fabio Estevam:
> Hi Heiko,
> 
> On Tue, Feb 2, 2021 at 11:08 AM Heiko Schocher  wrote:
> 
>> I use currently SPL and u-boot.img ... seems I have to switch
>> to above image ... currently I have a lot of load on my desk,
>> so may this takes some time ... sorry
> 
> Sure, no problem.
> 
> The idea is to keep testing SPL and u-boot.img like you currently do
> and add an extra boot test that also tests u-boot-with-spl.imx.
> 
> This would allows to catch regressions with the u-boot-with-spl.imx format 
> too.

Ah, okay, yes this should be doable also ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de


Documentation page shows "The Linux Kernel"

2021-02-02 Thread Bin Meng
Hi Heinrich,

https://u-boot.readthedocs.io/en/latest/

top left corner shows "The Linux Kernel" while previously it was U-Boot

This was introduced by commit:

commit 98f01cf7a22ec81774a26a9e1bf11c7c3cdce424
Author: Heinrich Schuchardt 
Date:   Thu Dec 31 23:16:46 2020 +0100

doc: update Kernel documentation build system

Update the documentation build system according to Linux v5.11-rc1.

Deactive the automarkup.py extension module which on Gitlab CI is
incompatible with Unicode.

With this patch we can build the HTML documentation using either of
Sphinx 2 and Sphinx 3.

Would you please take a look?

Regards,
Bin


Re: MX6sabresd broken since v2019.04

2021-02-02 Thread Fabio Estevam
Hi Heiko,

On Tue, Feb 2, 2021 at 11:08 AM Heiko Schocher  wrote:

> I use currently SPL and u-boot.img ... seems I have to switch
> to above image ... currently I have a lot of load on my desk,
> so may this takes some time ... sorry

Sure, no problem.

The idea is to keep testing SPL and u-boot.img like you currently do
and add an extra boot test that also tests u-boot-with-spl.imx.

This would allows to catch regressions with the u-boot-with-spl.imx format too.

Thanks


Re: MX6sabresd broken since v2019.04

2021-02-02 Thread Heiko Schocher
Hello Fabio,

Am 01.02.21 um 18:40 schrieb Fabio Estevam:
> On Mon, Feb 1, 2021 at 1:36 PM Marek Vasut  wrote:
> 
>> I don't think WB uses OF_SEPARATE with fitImages, so maybe there its not
>> applicable at all ?
> 
> Wandboard does use OF_SEPARATE and FIT.
> 
> I have just tested flashing u-boot-with-spl.imx into a SD card and
> booting a wandboard.
> 
> It does behave the same as mx6sabresd:
> 
> - Fails to boot without your patch
> - Boots fine with your patch
> 
> So, yes, wandboard can be used to test u-boot-with-spl.imx and avoid
> future regressions in Heiko's boot farm.

Last build from this morning:

http://xeidos.ddns.net/ubtestresults/result/777

You find log here:

http://xeidos.ddns.net/ubtestresults/result/files/results/777/tbot.log

I use currently SPL and u-boot.img ... seems I have to switch
to above image ... currently I have a lot of load on my desk,
so may this takes some time ... sorry

bye,
Heiko

[1] extract part "update SPL and u-boot.img on wandboard" from logfile:
│   │   ├─[wandboard-uboot] run load_spl
│   │   │## ethernet@2188000 Waiting for PHY auto negotiation to 
complete done
│   │   │## Using ethernet@2188000 device
│   │   │## TFTP from server 192.168.3.1; our IP address is 192.168.3.21
│   │   │## Filename 'wandboard/tbot/SPL'.
│   │   │## Load address: 0x1200
│   │   │## Loading: *
│   │   │##
│   │   │##  1.6 MiB/s
│   │   │##
│   │   │## done
│   │   │## Bytes transferred = 48128 (bc00 hex)
│   │   │##
│   │   ├─[wandboard-uboot] run upd_spl
│   │   │## switch to partitions #0, OK
│   │   │## mmc0 is current device
│   │   │##
│   │   │## MMC write: dev # 0, block # 2, count 95 ... 95 blocks written: 
OK
│   │   ├─[wandboard-uboot] run cmp_spl
│   │   │## Using ethernet@2188000 device
│   │   │##
│   │   │## TFTP from server 192.168.3.1; our IP address is 192.168.3.21
│   │   │## Filename 'wandboard/tbot/SPL'.
│   │   │##
│   │   │## Load address: 0x1200
│   │   │## Loading: *
│   │   │##  2.9 MiB/s
│   │   │##
│   │   │## done
│   │   │## Bytes transferred = 48128 (bc00 hex)
│   │   │##
│   │   │##
│   │   │##
│   │   │## MMC read: dev # 0, block # 2, count 95 ... 95 blocks read: OK
│   │   │##
│   │   │## Total of 48128 byte(s) were the same
│   │   │##
│   │   ├─[wandboard-uboot] run load_ub
│   │   │## Using ethernet@2188000 device
│   │   │##
│   │   │## TFTP from server 192.168.3.1; our IP address is 192.168.3.21
│   │   │## Filename 'wandboard/tbot/u-boot.img'.
│   │   │##
│   │   │## Load address: 0x1200
│   │   │## Loading: *
│   │   │##
│   │   │##  2.9 MiB/s
│   │   │## done
│   │   │## Bytes transferred = 577444 (8cfa4 hex)
│   │   │##
│   │   ├─[wandboard-uboot] run upd_ub
│   │   │## switch to partitions #0, OK
│   │   │## mmc0 is current device
│   │   │##
│   │   │## MMC write: dev # 0, block # 138, count 1128 ... 1128 blocks 
written: OK
│   │   │##
│   │   ├─[wandboard-uboot] run cmp_ub
│   │   │## Using ethernet@2188000 device
│   │   │##
│   │   │## TFTP from server 192.168.3.1; our IP address is 192.168.3.21
│   │   │##
│   │   │## Filename 'wandboard/tbot/u-boot.img'.
│   │   │## Load address: 0x1200
│   │   │##
│   │   │## Loading: *
│   │   │##  2.5 MiB/s
│   │   │## done
│   │   │## Bytes transferred = 577444 (8cfa4 hex)
│   │   │##
│   │   │## MMC read: dev # 0, block # 138, count 1128 ... 1128 blocks 
read: OK
│   │   │## Total of 577444 byte(s) were the same
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de


[PATCH V2 3/6] arm: dts: r8a774e1: Import DTS queued for Linux 5.12-rc1

2021-02-02 Thread Adam Ford
Update the RZ/G2H dtsi from Renesas repo destined to become 5.12-rc1.

Signed-off-by: Adam Ford 
---
 arch/arm/dts/r8a774e1.dtsi | 1374 +++-
 1 file changed, 1347 insertions(+), 27 deletions(-)

V2:  No Change

diff --git a/arch/arm/dts/r8a774e1.dtsi b/arch/arm/dts/r8a774e1.dtsi
index 0f86cfd524..8eb006cbd9 100644
--- a/arch/arm/dts/r8a774e1.dtsi
+++ b/arch/arm/dts/r8a774e1.dtsi
@@ -28,6 +28,12 @@
clock-frequency = <0>;
};
 
+   audio_clk_b: audio_clk_b {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
audio_clk_c: audio_clk_c {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -127,6 +133,7 @@
power-domains = <&sysc R8A774E1_PD_CA57_CPU0>;
next-level-cache = <&L2_CA57>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_0>;
dynamic-power-coefficient = <854>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z>;
operating-points-v2 = <&cluster0_opp>;
@@ -141,6 +148,7 @@
power-domains = <&sysc R8A774E1_PD_CA57_CPU1>;
next-level-cache = <&L2_CA57>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_0>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z>;
operating-points-v2 = <&cluster0_opp>;
capacity-dmips-mhz = <1024>;
@@ -154,6 +162,7 @@
power-domains = <&sysc R8A774E1_PD_CA57_CPU2>;
next-level-cache = <&L2_CA57>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_0>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z>;
operating-points-v2 = <&cluster0_opp>;
capacity-dmips-mhz = <1024>;
@@ -167,6 +176,7 @@
power-domains = <&sysc R8A774E1_PD_CA57_CPU3>;
next-level-cache = <&L2_CA57>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_0>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z>;
operating-points-v2 = <&cluster0_opp>;
capacity-dmips-mhz = <1024>;
@@ -180,6 +190,7 @@
power-domains = <&sysc R8A774E1_PD_CA53_CPU0>;
next-level-cache = <&L2_CA53>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_1>;
#cooling-cells = <2>;
dynamic-power-coefficient = <277>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z2>;
@@ -194,6 +205,7 @@
power-domains = <&sysc R8A774E1_PD_CA53_CPU1>;
next-level-cache = <&L2_CA53>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_1>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z2>;
operating-points-v2 = <&cluster1_opp>;
capacity-dmips-mhz = <535>;
@@ -206,6 +218,7 @@
power-domains = <&sysc R8A774E1_PD_CA53_CPU2>;
next-level-cache = <&L2_CA53>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_1>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z2>;
operating-points-v2 = <&cluster1_opp>;
capacity-dmips-mhz = <535>;
@@ -218,6 +231,7 @@
power-domains = <&sysc R8A774E1_PD_CA53_CPU3>;
next-level-cache = <&L2_CA53>;
enable-method = "psci";
+   cpu-idle-states = <&CPU_SLEEP_1>;
clocks = <&cpg CPG_CORE R8A774E1_CLK_Z2>;
operating-points-v2 = <&cluster1_opp>;
capacity-dmips-mhz = <535>;
@@ -236,6 +250,28 @@
cache-unified;
cache-level = <2>;
};
+
+   idle-states {
+   entry-method = "psci";
+
+   CPU_SLEEP_0: cpu-sleep-0 {
+   compatible = "arm,idle-state";
+   arm,psci-suspend-param = <0x001>;
+   local-timer-stop;
+   entry-latency-us = <400>;
+   exit-latency-us = <500>;
+   min-residency-us = <4000>;
+   };
+
+   CPU_SLEEP_1: cpu-sleep-1 {
+   compatible = "arm,idle-state";
+ 

[PATCH V2 6/6] ARM: rmobile: Add Beacon EmbeddedWorks RZG2H Dev Kit

2021-02-02 Thread Adam Ford
The Beacon EmbeddedWorks kit is based on the R8A774E1 SoC also
known as the RZ/G2H.

The kit consists of a SOM + Baseboard and supports microSD,
eMMC, Ethernet, a couple celular radios, two CAN interfaces,
Bluetooth and WiFi.  It shares much of the same design as
the RZ/G2M and RZ/G2N dev kits.

Signed-off-by: Adam Ford 
---
 arch/arm/dts/Makefile |  1 +
 .../dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi | 44 
 arch/arm/dts/r8a774e1-beacon-rzg2h-kit.dts| 71 +++
 arch/arm/mach-rmobile/Kconfig.64  |  5 ++
 board/beacon/beacon-rzg2m/Kconfig |  2 +-
 configs/r8a774e1_beacon_defconfig | 67 +
 6 files changed, 189 insertions(+), 1 deletion(-)

V2:  No Change

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 71f49cc79b..50b52b901a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -810,6 +810,7 @@ dtb-$(CONFIG_RCAR_GEN2) += \
 dtb-$(CONFIG_RCAR_GEN3) += \
r8a774a1-beacon-rzg2m-kit.dtb \
r8a774b1-beacon-rzg2n-kit.dtb \
+   r8a774e1-beacon-rzg2h-kit.dtb \
r8a77950-ulcb-u-boot.dtb \
r8a77950-salvator-x-u-boot.dtb \
r8a77960-ulcb-u-boot.dtb \
diff --git a/arch/arm/dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi 
b/arch/arm/dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi
new file mode 100644
index 00..eef200af2d
--- /dev/null
+++ b/arch/arm/dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Compass Electronics Group, LLC
+ */
+
+/ {
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+&cpg {
+   u-boot,dm-pre-reloc;
+};
+
+&extal_clk {
+   u-boot,dm-pre-reloc;
+};
+
+&prr {
+   u-boot,dm-pre-reloc;
+};
+
+&extalr_clk {
+   u-boot,dm-pre-reloc;
+};
+
+&sdhi0 {
+   /delete-property/ cd-gpios;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr104;
+   max-frequency = <20800>;
+};
+
+&sdhi2 {
+   status = "disabled";
+};
+
+&sdhi3 {
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   mmc-hs400-1_8v;
+};
diff --git a/arch/arm/dts/r8a774e1-beacon-rzg2h-kit.dts 
b/arch/arm/dts/r8a774e1-beacon-rzg2h-kit.dts
new file mode 100644
index 00..273f062f29
--- /dev/null
+++ b/arch/arm/dts/r8a774e1-beacon-rzg2h-kit.dts
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774e1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+   model = "Beacon Embedded Works RZ/G2H Development Kit";
+   compatible ="beacon,beacon-rzg2h", "renesas,r8a774e1";
+
+   aliases {
+   serial0 = &scif2;
+   serial1 = &hscif0;
+   serial2 = &hscif1;
+   serial3 = &scif0;
+   serial4 = &hscif2;
+   serial5 = &scif5;
+   serial6 = &scif4;
+   ethernet0 = &avb;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@5 {
+   device_type = "memory";
+   reg = <0x5 0x 0x0 0x8000>;
+   };
+};
+
+&du {
+   pinctrl-0 = <&du_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   clocks = <&cpg CPG_MOD 724>,
+   <&cpg CPG_MOD 723>,
+   <&cpg CPG_MOD 721>,
+   <&versaclock5 1>,
+   <&x302_clk>,
+   <&versaclock5 2>;
+   clock-names = "du.0", "du.1", "du.3",
+   "dclkin.0", "dclkin.1", "dclkin.3";
+};
+
+/* Reference versaclock instead of audio_clk_a */
+&rcar_sound {
+   clocks = <&cpg CPG_MOD 1005>,
+<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+<&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+<&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+<&versaclock6_bb 4>, <&audio_clk_b>,
+<&audio_clk_c>,
+<&cpg CPG_CORE R8A774E1_CLK_S0D4>;
+};
diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index 35354126e4..b95c8e8d29 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -60,6 +60,11 @@ choice
prompt "Renesas ARM64 SoCs board select"
optional
 
+config TARGET_BEACON_RZG2H
+   bool "Beacon

[PATCH V2 4/6] arm: dts: r8a774b1: Import DTS queued for Linux 5.12-rc1

2021-02-02 Thread Adam Ford
Update the RZ/G2N dtsi from Renesas repo destined to become 5.12-rc1.

Signed-off-by: Adam Ford 
---
 arch/arm/dts/r8a774b1.dtsi | 76 +-
 1 file changed, 74 insertions(+), 2 deletions(-)

V2:  No Change

diff --git a/arch/arm/dts/r8a774b1.dtsi b/arch/arm/dts/r8a774b1.dtsi
index 23119c0ae7..5b05474dc2 100644
--- a/arch/arm/dts/r8a774b1.dtsi
+++ b/arch/arm/dts/r8a774b1.dtsi
@@ -2,7 +2,7 @@
 /*
  * Device Tree Source for the r8a774b1 SoC
  *
- * Copyright (C) 2020 Renesas Electronics Corp.
+ * Copyright (C) 2019 Renesas Electronics Corp.
  */
 
 #include 
@@ -282,7 +282,7 @@
resets = <&cpg 905>;
};
 
-   pfc: pin-controller@e606 {
+   pfc: pinctrl@e606 {
compatible = "renesas,pfc-r8a774b1";
reg = <0 0xe606 0 0x50c>;
};
@@ -709,6 +709,21 @@
status = "disabled";
};
 
+   usb2_clksel: clock-controller@e6590630 {
+   compatible = "renesas,r8a774b1-rcar-usb2-clock-sel",
+"renesas,rcar-gen3-usb2-clock-sel";
+   reg = <0 0xe6590630 0 0x02>;
+   clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
+<&usb_extal_clk>, <&usb3s0_clk>;
+   clock-names = "ehci_ohci", "hs-usb-if",
+ "usb_extal", "usb_xtal";
+   #clock-cells = <0>;
+   power-domains = <&sysc R8A774B1_PD_ALWAYS_ON>;
+   resets = <&cpg 703>, <&cpg 704>;
+   reset-names = "ehci_ohci", "hs-usb-if";
+   status = "disabled";
+   };
+
usb_dmac0: dma-controller@e65a {
compatible = "renesas,r8a774b1-usb-dmac",
 "renesas,usb-dmac";
@@ -989,6 +1004,8 @@
power-domains = <&sysc R8A774B1_PD_ALWAYS_ON>;
resets = <&cpg 812>;
phy-mode = "rgmii";
+   rx-internal-delay-ps = <0>;
+   tx-internal-delay-ps = <0>;
iommus = <&ipmmu_ds0 16>;
#address-cells = <1>;
#size-cells = <0>;
@@ -2158,6 +2175,23 @@
status = "disabled";
};
 
+   rpc: spi@ee20 {
+   compatible = "renesas,r8a774b1-rpc-if",
+"renesas,rcar-gen3-rpc-if";
+   reg = <0 0xee20 0 0x200>,
+ <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+   reg-names = "regs", "dirmap", "wbuf";
+   interrupts = ;
+   clocks = <&cpg CPG_MOD 917>;
+   clock-names = "rpc";
+   power-domains = <&sysc R8A774B1_PD_ALWAYS_ON>;
+   resets = <&cpg 917>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
sata: sata@ee30 {
compatible = "renesas,sata-r8a774b1",
 "renesas,rcar-gen3-sata";
@@ -2240,6 +2274,44 @@
status = "disabled";
};
 
+   pciec0_ep: pcie-ep@fe00 {
+   compatible = "renesas,r8a774b1-pcie-ep",
+"renesas,rcar-gen3-pcie-ep";
+   reg = <0x0 0xfe00 0 0x8>,
+ <0x0 0xfe10 0 0x10>,
+ <0x0 0xfe20 0 0x20>,
+ <0x0 0x3000 0 0x800>,
+ <0x0 0x3800 0 0x800>;
+   reg-names = "apb-base", "memory0", "memory1", 
"memory2", "memory3";
+   interrupts = ,
+,
+;
+   clocks = <&cpg CPG_MOD 319>;
+   clock-names = "pcie";
+   resets = <&cpg 319>;
+   power-domains = <&sysc R8A774B1_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   pciec1_ep: pcie-ep@ee80 {
+   compatible = "renesas,r8a774b1-pcie-ep",
+"renesas,rcar-gen3-pcie-ep";
+   reg = <0x0 0xee80 0 0x8>,
+ <0x0 0xee90 0 0x10>,
+ <0x0 0xeea0 0 0x20>,
+ <0x0 0xc000 0 0x800>,
+ <0x0 0xc800 0 0x800>;
+  

[PATCH V2 5/6] ARM: rmobile: Add Beacon EmbeddedWorks RZG2N Dev Kit

2021-02-02 Thread Adam Ford
The Beacon EmbeddedWorks kit is based on the R8A774B1 SoC also
known as the RZ/G2N.

The kit consists of a SOM + Baseboard and supports microSD,
eMMC, Ethernet, a couple celular radios, two CAN interfaces,
Bluetooth and WiFi.  It shares much of the same design as
the RZ/G2M dev kit.

Signed-off-by: Adam Ford 
---
 arch/arm/dts/Makefile |  1 +
 .../dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi | 34 +
 arch/arm/dts/r8a774b1-beacon-rzg2n-kit.dts| 66 +
 arch/arm/mach-rmobile/Kconfig.64  |  5 ++
 board/beacon/beacon-rzg2m/Kconfig |  2 +-
 configs/r8a774b1_beacon_defconfig | 71 +++
 6 files changed, 178 insertions(+), 1 deletion(-)

V2:  Fix MMC location of env

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 858b79ac97..71f49cc79b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -809,6 +809,7 @@ dtb-$(CONFIG_RCAR_GEN2) += \
 
 dtb-$(CONFIG_RCAR_GEN3) += \
r8a774a1-beacon-rzg2m-kit.dtb \
+   r8a774b1-beacon-rzg2n-kit.dtb \
r8a77950-ulcb-u-boot.dtb \
r8a77950-salvator-x-u-boot.dtb \
r8a77960-ulcb-u-boot.dtb \
diff --git a/arch/arm/dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi 
b/arch/arm/dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi
new file mode 100644
index 00..a0c0a7f35c
--- /dev/null
+++ b/arch/arm/dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Compass Electronics Group, LLC
+ */
+
+/ {
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+&cpg {
+   u-boot,dm-pre-reloc;
+};
+
+&extal_clk {
+   u-boot,dm-pre-reloc;
+};
+
+&prr {
+   u-boot,dm-pre-reloc;
+};
+
+&extalr_clk {
+   u-boot,dm-pre-reloc;
+};
+
+&sdhi0 {
+   /delete-property/ cd-gpios;
+};
+
+&sdhi2 {
+   status = "disabled";
+};
diff --git a/arch/arm/dts/r8a774b1-beacon-rzg2n-kit.dts 
b/arch/arm/dts/r8a774b1-beacon-rzg2n-kit.dts
new file mode 100644
index 00..71763f4402
--- /dev/null
+++ b/arch/arm/dts/r8a774b1-beacon-rzg2n-kit.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774b1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+   model = "Beacon Embedded Works RZ/G2N Development Kit";
+   compatible ="beacon,beacon-rzg2n", "renesas,r8a774b1";
+
+   aliases {
+   serial0 = &scif2;
+   serial1 = &hscif0;
+   serial2 = &hscif1;
+   serial3 = &scif0;
+   serial4 = &hscif2;
+   serial5 = &scif5;
+   serial6 = &scif4;
+   ethernet0 = &avb;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&du {
+   pinctrl-0 = <&du_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   clocks = <&cpg CPG_MOD 724>,
+   <&cpg CPG_MOD 723>,
+   <&cpg CPG_MOD 721>,
+   <&versaclock5 1>,
+   <&x302_clk>,
+   <&versaclock5 2>;
+   clock-names = "du.0", "du.1", "du.3",
+   "dclkin.0", "dclkin.1", "dclkin.3";
+};
+
+/* Reference versaclock instead of audio_clk_a */
+&rcar_sound {
+   clocks = <&cpg CPG_MOD 1005>,
+<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+<&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+<&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+<&versaclock6_bb 4>, <&audio_clk_b>,
+<&audio_clk_c>,
+<&cpg CPG_CORE R8A774B1_CLK_S0D4>;
+};
diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index 0ef6cf619b..35354126e4 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -65,6 +65,11 @@ config TARGET_BEACON_RZG2M
select R8A774A1
select PINCTRL_PFC_R8A774A1
 
+config TARGET_BEACON_RZG2N
+   bool "Beacon EmbeddedWorks RZ/G2N Dev Kit"
+   select R8A774B1
+   select PINCTRL_PFC_R8A774B1
+
 config TARGET_CONDOR
bool "Condor board"
imply R8A77980
diff --git a/board/beacon/beacon-rzg2m/Kconfig 
b/board/beacon/beacon-rzg2m/Kconfig
index c03857cf2f..9c653e386e 100644
--- a/board/beacon/beacon-rzg2m/Kconfig
+++ b/board/beacon/beaco

[PATCH V2 2/6] arm: dts: r8a774a1: Import DTS queued for Linux 5.12-rc1

2021-02-02 Thread Adam Ford
Update the RZ/G2M dtsi and r8a774a1-beacon-rzg2m-kit kit
from Renesas repo destined to become 5.12-rc1.

Signed-off-by: Adam Ford 
---
 arch/arm/dts/beacon-renesom-baseboard.dtsi | 359 -
 arch/arm/dts/beacon-renesom-som.dtsi   |  57 +++-
 arch/arm/dts/r8a774a1-beacon-rzg2m-kit.dts |  59 +++-
 arch/arm/dts/r8a774a1.dtsi |  74 -
 4 files changed, 445 insertions(+), 104 deletions(-)

V2:  No Change

diff --git a/arch/arm/dts/beacon-renesom-baseboard.dtsi 
b/arch/arm/dts/beacon-renesom-baseboard.dtsi
index 8a472c057a..5f998d4706 100644
--- a/arch/arm/dts/beacon-renesom-baseboard.dtsi
+++ b/arch/arm/dts/beacon-renesom-baseboard.dtsi
@@ -5,35 +5,27 @@
 
 #include 
 #include 
+#include 
 
 / {
-   aliases {
-   serial0 = &scif2;
-   serial1 = &hscif0;
-   serial2 = &hscif1;
-   serial3 = &scif0;
-   serial4 = &hscif2;
-   serial5 = &scif5;
-   spi0 = &msiof0;
-   spi1 = &msiof1;
-   spi2 = &msiof2;
-   spi3 = &msiof3;
-   ethernet0 = &avb;
-   };
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
-   backlight: backlight {
+   backlight_lvds: backlight-lvds {
compatible = "pwm-backlight";
power-supply = <®_lcd>;
enable-gpios = <&gpio_exp1 3 GPIO_ACTIVE_HIGH>;
-   pwms = <&pwm0 0 5>;
+   pwms = <&pwm2 0 25000>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
};
 
+   backlight_dpi: backlight-dpi {
+   compatible = "pwm-backlight";
+   power-supply = <®_lcd>;
+   enable-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
+   pwms = <&pwm0 0 25000>;
+   brightness-levels = <0 25 33 50 63 75 88 100>;
+   default-brightness-level = <6>;
+   };
+
hdmi0-out {
compatible = "hdmi-connector";
type = "a";
@@ -48,38 +40,38 @@
keys {
compatible = "gpio-keys";
 
-   key-1 {
+   key-1 { /* S19 */
gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   label = "Switch-1";
+   linux,code = ;
+   label = "Up";
wakeup-source;
debounce-interval = <20>;
};
-   key-2 {
+   key-2 { /*S20 */
gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   label = "Switch-2";
+   linux,code = ;
+   label = "Left";
wakeup-source;
debounce-interval = <20>;
};
-   key-3 {
+   key-3 { /* S21 */
gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   label = "Switch-3";
+   linux,code = ;
+   label = "Down";
wakeup-source;
debounce-interval = <20>;
};
-   key-4 {
+   key-4 { /* S22 */
gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   label = "Switch-4";
+   linux,code = ;
+   label = "Right";
wakeup-source;
debounce-interval = <20>;
};
-   key-5 {
+   key-5 { /* S23 */
gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   label = "Switch-4";
+   linux,code = ;
+   label = "Center";
wakeup-source;
debounce-interval = <20>;
};
@@ -98,17 +90,59 @@
led1 {
gpios = <&gpio7 0 GPIO_ACTIVE_HIGH>;
label = "LED1";
-   linux,default-trigger = "heartbeat";
};
led2 {
gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>;
label = "LED2";
-   linux,default-trigger = "heartbeat";
};
led3 {
gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
label = "LED3";
-   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   lvds {
+   compatible = "panel-lvds";
+   power-supply = <®_lcd_reset>;
+   width-mm = <223>;
+   height-mm = <125>;
+   backlight = <&backlight_lvds>;
+   dat

Re: [QUESTION] Kernel 5.10 image might be too big to be loaded by U-Boot on RPi 4B

2021-02-02 Thread Tom Rini
On Tue, Feb 02, 2021 at 09:28:20AM +0100, Matthias Brugger wrote:
> On Thu, Jan 28, 2021 at 04:54:03PM +0800, Jian-Hong Pan wrote:
> > Load u-Boot environment ... from mmc 0:2
> > 622 bytes read in 24 ms (24.4 KiB/s)
> > Load device tree ...
> > 25693 bytes read in 30 ms (835.9 KiB/s)
> > fdt_addr_r @  0x0260 , size= 645d
> > Load kernel and unzip it ...
> > 13013555 bytes read in 574 ms (21.6 MiB/s)
> > Uncompressed size: 38742528 = 0x24F2A00
> > kernel_addr_r @  0x0008 , size= 24f2a00
> > Load RAM disk ...
> > 54360540 bytes read in 2298 ms (22.6 MiB/s)
> > ramdisk_addr_r @  0x0270 , size= 33d79dc
> > Boot ...
> > Moving Image from 0x8 to 0x20, end=282
> > ERROR: RD image overlaps OS image (OS=0x20..0x282)
> > SCRIPT FAILED: continuing...
> > Card did not respond to voltage select!
> > genet@7d58 Waiting for PHY auto negotiation to complete
> > 
> > It shows error: "RD image overlaps OS image (OS=0x20..0x282)"
> > 
> > So, I calculated the memory address and space:
> > 
> > 0x20 (kernel start address) + 0x24F2A00 (kernel size) = 0x26F2A00 <
> > 282 (kernel end), but > 0x270 (ramdisk start address) & > 0x260
> > (FDT start address)
> > 
> > The kernel image size 0x24F2A00 bytes is too fat to sit in the memory space
> > prepared by U-Boot and overlaps ramdisk and FDT's memory spaces.
> > It is more than 36.9MB, which is over 36MB mentioned in U-Boot's comment
> > [2].
> 
> If I did the math right, we should have a lot of space left. 
> You could try to bump up fdt_addr_r=0x0290 and
> ramdisk_addr_r=0x02A0 and see what happens.

The environment section in include/configs/rpi.h needs to be updated.
You cannot disable device tree relocation by default as that leads to
problems.  You need to set bootm_size to something that will cover all
of the valid lowmem area the device tree and initrd can reside in.
Please see include/configs/ti_armv7_common.h which is based on what the
kernel documents as minimum / maximum values / locations.  Thanks.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH V2 1/6] dt-bindings: Sync versaclock.h with upcoming 5.12-rc1

2021-02-02 Thread Adam Ford
The versaclock doesn't have a driver yet, but there are a bunch
of device tree updates for the Beacon RZ/G2 boards that won't
compile without these.  A driver is coming, so sync the bindings
for now

Signed-off-by: Adam Ford 
---
 include/dt-bindings/clk/versaclock.h | 13 +
 1 file changed, 13 insertions(+)

V2:  New to series in order to make series build

diff --git a/include/dt-bindings/clk/versaclock.h 
b/include/dt-bindings/clk/versaclock.h
new file mode 100644
index 00..c6a6a09465
--- /dev/null
+++ b/include/dt-bindings/clk/versaclock.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/* This file defines field values used by the versaclock 6 family
+ * for defining output type
+ */
+
+#define VC5_LVPECL 0
+#define VC5_CMOS   1
+#define VC5_HCSL33 2
+#define VC5_LVDS   3
+#define VC5_CMOS2  4
+#define VC5_CMOSD  5
+#define VC5_HCSL25 6
-- 
2.25.1



Re: [PATCH v4 3/3] pxe_utils: clean-up, replace ifdef by IS_ENABLED

2021-02-02 Thread Bin Meng
Hi Kory,

On Tue, Feb 2, 2021 at 7:56 PM Kory Maincent  wrote:
>
> Replace all the macro ifdef by IS_ENABLED.
> All of these configs are set in the defconfig files and not in the
> include board headers files.
>
> Signed-off-by: Kory Maincent 
> ---
>  cmd/pxe_utils.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> index b788ee9576..a6e7d27682 100644
> --- a/cmd/pxe_utils.c
> +++ b/cmd/pxe_utils.c
> @@ -340,7 +340,7 @@ static int label_localboot(struct pxe_label *label)
>  /*
>   * Loads fdt overlays specified in 'fdtoverlays'.
>   */
> -#ifdef CONFIG_OF_LIBFDT_OVERLAY
> +#if IS_ENABLED(CONFIG_OF_LIBFDT_OVERLAY)
>  static void label_boot_fdtoverlay(struct cmd_tbl *cmdtp, struct pxe_label 
> *label)
>  {
> char *fdtoverlay = label->fdtoverlays;
> @@ -492,7 +492,7 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
> pxe_label *label)
> env_get("gatewayip"), env_get("netmask"));
> }
>
> -#ifdef CONFIG_CMD_NET
> +#if IS_ENABLED(CONFIG_CMD_NET)

This should use: if (IS_ENABLED(CONFIG_CMD_NET)) to increase build coverage.

> if (label->ipappend & 0x2) {
> int err;
>
> @@ -626,7 +626,7 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
> pxe_label *label)
> }
> }
>
> -#ifdef CONFIG_OF_LIBFDT_OVERLAY
> +#if IS_ENABLED(CONFIG_OF_LIBFDT_OVERLAY)
> if (label->fdtoverlays)
> label_boot_fdtoverlay(cmdtp, label);
>  #endif
> @@ -649,11 +649,11 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
> pxe_label *label)
> /* Try bootm for legacy and FIT format image */
> if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID)
> do_bootm(cmdtp, 0, bootm_argc, bootm_argv);
> -#ifdef CONFIG_CMD_BOOTI
> +#if IS_ENABLED(CONFIG_CMD_BOOTI)
> /* Try booting an AArch64 Linux kernel image */
> else
> do_booti(cmdtp, 0, bootm_argc, bootm_argv);
> -#elif defined(CONFIG_CMD_BOOTZ)
> +#elif IS_ENABLED(CONFIG_CMD_BOOTZ)
> /* Try booting a Image */
> else
> do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> @@ -1428,7 +1428,7 @@ void handle_pxe_menu(struct cmd_tbl *cmdtp, struct 
> pxe_menu *cfg)
> struct menu *m;
> int err;
>
> -#ifdef CONFIG_CMD_BMP
> +#if IS_ENABLED(CONFIG_CMD_BMP)
> /* display BMP if available */
> if (cfg->bmp) {
> if (get_relfile(cmdtp, cfg->bmp, image_load_addr)) {
> --

Regards,
Bin


Re: [PATCH v4 2/3] command.h: Clean-up patch, remove extern from the header

2021-02-02 Thread Bin Meng
On Tue, Feb 2, 2021 at 7:56 PM Kory Maincent  wrote:
>
> Remove the extern of the header because they are useless.
>
> Signed-off-by: Kory Maincent 
> ---
>  include/command.h | 56 +++
>  1 file changed, 28 insertions(+), 28 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v4 1/3] sysboot: add zboot support to boot x86 Linux kernel image

2021-02-02 Thread Bin Meng
On Tue, Feb 2, 2021 at 7:56 PM Kory Maincent  wrote:
>
> Add "zboot" command to the list of supported boot in the label_boot
> function.
>
> Signed-off-by: Kory Maincent 
> Reviewed-by: Simon Glass 
> ---
>
> Change since v1:
>  - Modify comment.
>
> Change since v2:
>  - Update do_zboot to do_zboot_parent function to follow the patch:
>5588e776b0
>
> Change since v3:
>  - Follow review from Simon Glass
>  - Add clean-up paches
>
>  cmd/pxe_utils.c   | 4 
>  include/command.h | 3 +++
>  2 files changed, 7 insertions(+)
>

Reviewed-by: Bin Meng 

However I think it's better we reorder the patches so that this patch
becomes the last one after the 2 clean-up patches.

Regards,
Bin


Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Andre Przywara
On Tue, 2 Feb 2021 11:55:50 +0800
Bin Meng  wrote:

Hi,

> On Sun, Jan 31, 2021 at 1:53 AM Marek Vasut  wrote:
> >
> > The various structures in the driver are already correcty padded and  
> 
> typo: correctly
> 
> > cache aligned in memory, however the cache operations are called on
> > the structure sizes, which themselves might not be cache aligned. Add
> > the necessary rounding to fix this, which permits the nvme to work on
> > arm64.  
> 
> +ARM guys
> 
> Which ARM64 SoC did you test this with?
> 
> The round down in this patch should be unnecessary. But it's better to
> figure out which call to dcache_xxx() with an unaligned end address.

I agree. There is no requirement for the actual cache maintenance
instruction's address to be aligned, and also we align everything
already in the implementations of flush_dcache_range() and
invalidate_dcache_range().

Actually I think rounding here is *wrong*, as we paper over the
requirement of the *buffer* to be cache line aligned. So this must be
assured at buffer allocation time, and just rounding before calling
cache maintenance merely avoids (read: silences!) the warnings.

I think drivers/net/bcmgenet.c does the right thing.

Happy to provide more detailed rationale and explanations if needed.

Cheers,
Andre
 
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Bin Meng 
> > ---
> >  drivers/nvme/nvme.c | 50 +
> >  1 file changed, 32 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > index 5d6331ad34..758415a53b 100644
> > --- a/drivers/nvme/nvme.c
> > +++ b/drivers/nvme/nvme.c
> > @@ -53,6 +53,27 @@ struct nvme_queue {
> > unsigned long cmdid_data[];
> >  };
> >
> > +static void nvme_align_dcache_range(void *start, unsigned long size,
> > +   unsigned long *s, unsigned long *e)
> > +{
> > +   *s = rounddown((uintptr_t)start, ARCH_DMA_MINALIGN);
> > +   *e = roundup((uintptr_t)start + size, ARCH_DMA_MINALIGN);
> > +}
> > +
> > +static void nvme_flush_dcache_range(void *start, unsigned long size)
> > +{
> > +   unsigned long s, e;
> > +   nvme_align_dcache_range(start, size, &s, &e);
> > +   flush_dcache_range(s, e);
> > +}
> > +
> > +static void nvme_invalidate_dcache_range(void *start, unsigned long size)
> > +{
> > +   unsigned long s, e;
> > +   nvme_align_dcache_range(start, size, &s, &e);
> > +   invalidate_dcache_range(s, e);
> > +}
> > +
> >  static int nvme_wait_ready(struct nvme_dev *dev, bool enabled)
> >  {
> > u32 bit = enabled ? NVME_CSTS_RDY : 0;
> > @@ -129,8 +150,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 
> > *prp2,
> > }
> > *prp2 = (ulong)dev->prp_pool;
> >
> > -   flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
> > -  dev->prp_entry_num * sizeof(u64));
> > +   nvme_flush_dcache_range(dev->prp_pool, dev->prp_entry_num * 
> > sizeof(u64));
> >
> > return 0;
> >  }
> > @@ -144,10 +164,8 @@ static __le16 nvme_get_cmd_id(void)
> >
> >  static u16 nvme_read_completion_status(struct nvme_queue *nvmeq, u16 index)
> >  {
> > -   u64 start = (ulong)&nvmeq->cqes[index];
> > -   u64 stop = start + sizeof(struct nvme_completion);
> > -
> > -   invalidate_dcache_range(start, stop);
> > +   nvme_invalidate_dcache_range(&nvmeq->cqes[index],
> > +sizeof(struct nvme_completion));
> >
> > return le16_to_cpu(readw(&(nvmeq->cqes[index].status)));
> >  }
> > @@ -163,8 +181,7 @@ static void nvme_submit_cmd(struct nvme_queue *nvmeq, 
> > struct nvme_command *cmd)
> > u16 tail = nvmeq->sq_tail;
> >
> > memcpy(&nvmeq->sq_cmds[tail], cmd, sizeof(*cmd));
> > -   flush_dcache_range((ulong)&nvmeq->sq_cmds[tail],
> > -  (ulong)&nvmeq->sq_cmds[tail] + sizeof(*cmd));
> > +   nvme_flush_dcache_range(&nvmeq->sq_cmds[tail], sizeof(*cmd));
> >
> > if (++tail == nvmeq->q_depth)
> > tail = 0;
> > @@ -338,8 +355,7 @@ static void nvme_init_queue(struct nvme_queue *nvmeq, 
> > u16 qid)
> > nvmeq->cq_phase = 1;
> > nvmeq->q_db = &dev->dbs[qid * 2 * dev->db_stride];
> > memset((void *)nvmeq->cqes, 0, NVME_CQ_SIZE(nvmeq->q_depth));
> > -   flush_dcache_range((ulong)nvmeq->cqes,
> > -  (ulong)nvmeq->cqes + 
> > NVME_CQ_SIZE(nvmeq->q_depth));
> > +   nvme_flush_dcache_range(nvmeq->cqes, NVME_CQ_SIZE(nvmeq->q_depth));
> > dev->online_queues++;
> >  }
> >
> > @@ -466,13 +482,13 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid,
> >
> > c.identify.cns = cpu_to_le32(cns);
> >
> > -   invalidate_dcache_range(dma_addr,
> > -   dma_addr + sizeof(struct nvme_id_ctrl));
> > +   nvme_invalidate_dcache_range((void *)dma_addr,
> > +sizeof(struct nvme_id_ctrl));
> >
> >   

[PATCH 0/5] lmb: Add config for the number of memory and reserved regions

2021-02-02 Thread Patrick Delaunay


Hi,

I propose a update of the lmb library to allow the configuration
with Kconfig of the number of memory and reserved regions in lmb
libary:
- CONFIG_LMB_RESERVED_REGIONS
- CONFIG_LMB_MEMORY_REGIONS

By default, I keep the default value of 8 regions.

This serie avoids issue on stm32mp15 platform,
as the kernel device tree defines many and non contiguous reserved
regions.



Patrick Delaunay (5):
  lmb: move CONFIG_LMB in Kconfig
  lmb: remove lmb_region.size
  lmb: Move lmb property arrays in struct lmb
  lmb: Add 2 config to define the max number of regions
  configs: stm32mp15: increase the number of reserved memory region in
lmb

 arch/arc/include/asm/config.h|  2 --
 arch/arm/include/asm/config.h|  1 -
 arch/m68k/include/asm/config.h   |  1 -
 arch/microblaze/include/asm/config.h |  2 --
 arch/mips/include/asm/config.h   |  1 -
 arch/nds32/include/asm/config.h  |  1 -
 arch/powerpc/include/asm/config.h|  1 -
 arch/riscv/include/asm/config.h  |  1 -
 arch/sh/include/asm/config.h |  2 --
 arch/x86/include/asm/config.h|  1 -
 arch/xtensa/include/asm/config.h |  2 --
 configs/stm32mp15_basic_defconfig|  1 +
 configs/stm32mp15_trusted_defconfig  |  1 +
 include/configs/10m50_devboard.h |  5 
 include/configs/3c120_devboard.h |  5 
 include/configs/sandbox.h|  2 --
 include/configs/x86-common.h |  2 --
 include/image.h  |  2 +-
 include/lmb.h| 34 
 lib/Kconfig  | 23 +++
 lib/lmb.c| 14 ++--
 scripts/config_whitelist.txt |  1 -
 22 files changed, 63 insertions(+), 42 deletions(-)

-- 
2.17.1



[PATCH 1/5] lmb: move CONFIG_LMB in Kconfig

2021-02-02 Thread Patrick Delaunay
Migrate CONFIG_LMB in Kconfig.

Signed-off-by: Patrick Delaunay 
---

 arch/arc/include/asm/config.h| 2 --
 arch/arm/include/asm/config.h| 1 -
 arch/m68k/include/asm/config.h   | 1 -
 arch/microblaze/include/asm/config.h | 2 --
 arch/mips/include/asm/config.h   | 1 -
 arch/nds32/include/asm/config.h  | 1 -
 arch/powerpc/include/asm/config.h| 1 -
 arch/riscv/include/asm/config.h  | 1 -
 arch/sh/include/asm/config.h | 2 --
 arch/x86/include/asm/config.h| 1 -
 arch/xtensa/include/asm/config.h | 2 --
 include/configs/10m50_devboard.h | 5 -
 include/configs/3c120_devboard.h | 5 -
 include/configs/sandbox.h| 2 --
 include/configs/x86-common.h | 2 --
 include/image.h  | 2 +-
 lib/Kconfig  | 7 +++
 scripts/config_whitelist.txt | 1 -
 18 files changed, 8 insertions(+), 31 deletions(-)

diff --git a/arch/arc/include/asm/config.h b/arch/arc/include/asm/config.h
index d88c361488..46e94be141 100644
--- a/arch/arc/include/asm/config.h
+++ b/arch/arc/include/asm/config.h
@@ -8,6 +8,4 @@
 
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
-#define CONFIG_LMB
-
 #endif /*__ASM_ARC_CONFIG_H_ */
diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
index bf692ce279..14860d89b6 100644
--- a/arch/arm/include/asm/config.h
+++ b/arch/arm/include/asm/config.h
@@ -6,7 +6,6 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
-#define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
 #if defined(CONFIG_ARCH_LS1021A) || \
diff --git a/arch/m68k/include/asm/config.h b/arch/m68k/include/asm/config.h
index 7ea443673a..221eb93d58 100644
--- a/arch/m68k/include/asm/config.h
+++ b/arch/m68k/include/asm/config.h
@@ -6,7 +6,6 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
-#define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
 #endif
diff --git a/arch/microblaze/include/asm/config.h 
b/arch/microblaze/include/asm/config.h
index 3ae71b3e01..221eb93d58 100644
--- a/arch/microblaze/include/asm/config.h
+++ b/arch/microblaze/include/asm/config.h
@@ -6,8 +6,6 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
-#define CONFIG_LMB
-
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
 #endif
diff --git a/arch/mips/include/asm/config.h b/arch/mips/include/asm/config.h
index 7ea443673a..221eb93d58 100644
--- a/arch/mips/include/asm/config.h
+++ b/arch/mips/include/asm/config.h
@@ -6,7 +6,6 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
-#define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
 #endif
diff --git a/arch/nds32/include/asm/config.h b/arch/nds32/include/asm/config.h
index 8964a58f27..6c1cbce7ef 100644
--- a/arch/nds32/include/asm/config.h
+++ b/arch/nds32/include/asm/config.h
@@ -7,6 +7,5 @@
 
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
-#define CONFIG_LMB
 
 #endif
diff --git a/arch/powerpc/include/asm/config.h 
b/arch/powerpc/include/asm/config.h
index c9c9964630..99b410dc9b 100644
--- a/arch/powerpc/include/asm/config.h
+++ b/arch/powerpc/include/asm/config.h
@@ -18,7 +18,6 @@
   #define HWCONFIG_BUFFER_SIZE 256
 #endif
 
-#define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
 #ifndef CONFIG_MAX_MEM_MAPPED
diff --git a/arch/riscv/include/asm/config.h b/arch/riscv/include/asm/config.h
index 156cb94dc0..d911007537 100644
--- a/arch/riscv/include/asm/config.h
+++ b/arch/riscv/include/asm/config.h
@@ -7,7 +7,6 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
-#define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
 #endif
diff --git a/arch/sh/include/asm/config.h b/arch/sh/include/asm/config.h
index e1cd322152..406156dff5 100644
--- a/arch/sh/include/asm/config.h
+++ b/arch/sh/include/asm/config.h
@@ -8,8 +8,6 @@
 
 #include 
 
-#define CONFIG_LMB
-
 /* Timer */
 #define CONFIG_SYS_TIMER_COUNTS_DOWN
 #define CONFIG_SYS_TIMER_COUNTER   (TMU_BASE + 0xc)/* TCNT0 */
diff --git a/arch/x86/include/asm/config.h b/arch/x86/include/asm/config.h
index 7ea443673a..221eb93d58 100644
--- a/arch/x86/include/asm/config.h
+++ b/arch/x86/include/asm/config.h
@@ -6,7 +6,6 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
-#define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
 #endif
diff --git a/arch/xtensa/include/asm/config.h b/arch/xtensa/include/asm/config.h
index 5a95fc93f7..a1096ab196 100644
--- a/arch/xtensa/include/asm/config.h
+++ b/arch/xtensa/include/asm/config.h
@@ -9,8 +9,6 @@
 
 #include 
 
-#define CONFIG_LMB
-
 /*
  * Make boot parameters available in the MMUv2 virtual memory layout by
  * restricting used physical memory to the first 128MB.
diff --git a/include/configs/10m50_devboard.h b/include/configs/10m50_devboard.h
index 768b4a6dfc..3ffc744928 100644
--- a/include/configs/10m50_devboard.h
+++ b/include/configs/10m50_devboard.h
@@ -34,11 +34,6 @@
  */
 #define CONFIG_BOOTP_BOOTFILESIZE
 
-/*
- * FDT options
- */
-#define CONFIG_LMB
-
 /*
  * MEMORY ORGANIZATION
  * -Monitor at top of sdram.
diff --git a/include/configs/3c120_devboard

Re: [PATCH V2] ARM: imx: Include u-boot.img in u-boot-with-spl.imx if OF_SEPARATE=y

2021-02-02 Thread Christoph Niedermaier
From: Marek Vasut 
Sent: Monday, February 1, 2021 9:07 PM

> The u-boot-with-spl.imx is a concatenation of SPL and u-boot.uim.
> The u-boot.uim is u-boot.bin wrapped in uImage. In case OF_SEPARATE
> is enabled, the u-boot.bin does not contain control DT for U-Boot,
> and so u-boot.uim does not contain the DT, and so u-boot-with-spl.imx
> does not contain the DT, and a system where u-boot-with-spl.imx is
> written to offset 1024B to the start of storage no longer boots, as
> it is missing DT.
> 
> In case OF_SEPARATE is enabled, u-boot.img contains both u-boot.bin
> and the necessary DTs. Therefore, use u-boot.img instead of u-boot.uim
> to generate u-boot-with-spl.imx when OF_SEPARATE is enabled.
> 
> Tested-by: Fabio Estevam 
> Signed-off-by: Marek Vasut 
> Cc: Christoph Niedermaier 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Simon Glass 
> Cc: Stefano Babic 
> Cc: Ye Li 
> Cc: uboot-imx 
> ---
> V2: Swap the u-boot.uim <-> u-boot.img in the conditional so this would
> match the patch which Fabio originally tested
> ---
>  arch/arm/mach-imx/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index 1aa26a50ad8..e6b4654cd35 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -202,10 +202,10 @@ append = cat $(filter-out $< $(PHONY), $^) >> $@
>  quiet_cmd_pad_cat = CAT $@
>  cmd_pad_cat = $(cmd_objcopy) && $(append) || rm -f $@
> 
> -u-boot-with-spl.imx: SPL u-boot.uim FORCE
> +u-boot-with-spl.imx: SPL $(if $(CONFIG_OF_SEPARATE),u-boot.img,u-
> boot.uim) FORCE
> $(call if_changed,pad_cat)
> 
> -u-boot-with-nand-spl.imx: spl/u-boot-nand-spl.imx u-boot.uim FORCE
> +u-boot-with-nand-spl.imx: spl/u-boot-nand-spl.imx $(if
> $(CONFIG_OF_SEPARATE),u-boot.img,u-boot.uim) FORCE
> $(call if_changed,pad_cat)
> 
>  quiet_cmd_u-boot-nand-spl_imx = GEN $@
> --
> 2.29.2


Tested-by: Christoph Niedermaier 

Best regards
Christoph


IPv6 Support

2021-02-02 Thread Raymond Yeung
Does uboot currently support IPv6?  If so, how mature/stable is it?

Thanks,
Raymond


Re: [PATCH 1/5] arm: dts: r8a774a1: Import DTS queued for Linux 5.12-rc1

2021-02-02 Thread Adam Ford
On Tue, Feb 2, 2021 at 4:11 AM Biju Das  wrote:
>
> Hi Marek and Adam,
>
> > Subject: Re: [PATCH 1/5] arm: dts: r8a774a1: Import DTS queued for Linux
> > 5.12-rc1
> >
> > On 2/1/21 4:19 PM, Adam Ford wrote:
> > > On Mon, Jan 25, 2021 at 6:40 AM Marek Vasut  wrote:
> > >>
> > >> On 1/25/21 12:22 AM, Adam Ford wrote:
> > >>> On Sun, Jan 24, 2021 at 11:10 AM Marek Vasut  wrote:
> > 
> >  On 1/13/21 12:52 AM, Adam Ford wrote:
> > > Update the RZ/G2M dtsi and r8a774a1-beacon-rzg2m-kit kit from
> > > Renesas repo destined to become 5.12-rc1.
> > 
> >  I picked a DT sync for Linux 5.10 from Biju (on CC), does your
> >  board need something from 5.12-rc1 or can it be based on 5.10 too ?
> > >>>
> > >>> I honestly don't remember.  I had to unexpectedly leave town for
> > >>> this week due to a funeral, and I won't be near a Linux development
> > >>> computer to run tests until Feb 1, so I don't know if the board will
> > >>> build using 5.10 or not.  Sorry I don't have a better answer.
> > >>
> > >> Lets revisit this later then.
> > >
> > > I tested the Beacon boards, but they have a dependency on usb2_clksel
> > > that is not present in the 5.10 device tree.
> > > I also noticed that I forgot to include versaclock.h dt-binding file
> > > from the kernel, so the Beacon boards don't build for that too.
> > >
>
> Do we have usb2_clksel support in u-boot? If yes, it make sense to import 
> from 5.12-rc1.
> Similarly for other bits importing from kernel 5.12-rc1.
>
> May be rpc-spcif support available in u-boot. So we could import from 
> 5.12-rc1.
> For  others like PCIe, ethernet the changes corresponding to dts is not 
> present in driver.

I think  Marek has posted some rcar3 updates to support the PCIe.  I
am hopeful that it will work on the RZ/G2 series.
I have rpc-spcif enabled and my plan was to post some updated configs
with it enabled once the updated configs had been merged.

>
> Do we have any plans to update the driver or plan to delete the 
> properties/nodes
> from U-boot specific dtsi, so that we can save image size?

I had not thought of that, but I can take a look at it.

>
> > > I can submit a V2 with the binding file included, or I can submit the
> > > dt-binding file now and wait on the Beacon boards until that file has
> > > been merged, or I can redo the device tree in a custom way to work the
> > > 5.10 and not use the veraclock dt-bindings since there is no
> > > versaclock driver in U-Boot anyway.  You may have an alternative as
> > > well.
> >
> > Can you try to figure out the best option with Biju , who is in charge of
> > all the RZG stuff ? Either way works for me.
> >
> > You also likely want to roll V2 out soon, since the RC1 is out. I would
> > still like to pick it for 2021.04 .
>
> As Marek, suggested please send V2.

I will do a V2 today.

adam

>
> Regards,
> Biju


[PATCH 4/5] lmb: Add 2 config to define the max number of regions

2021-02-02 Thread Patrick Delaunay
Add 2 configs CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS
to change independently the max number of the regions in lmb
library.

Increase CONFIG_LMB_RESERVED_REGIONS is useful to avoid lmb errors in
bootm when the number of reserved regions (not adjacent) is reached:
+ 1 region for relocated U-Boot
+ 1 region for initrd
+ 1 region for relocated linux device tree
+ reserved memory regions present in Linux device tree.

The current limit of 8 regions is reached with only 5 reserved regions
in DT.

Signed-off-by: Patrick Delaunay 
---

 include/lmb.h |  6 ++
 lib/Kconfig   | 16 
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index df543028d5..97be24ed66 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -12,8 +12,6 @@
  * Copyright (C) 2001 Peter Bergner, IBM Corp.
  */
 
-#define MAX_LMB_REGIONS 8
-
 /**
  * struct lmb_property - Description of one region.
  *
@@ -54,8 +52,8 @@ struct lmb_region {
 struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
-   struct lmb_property memory_regions[MAX_LMB_REGIONS + 1];
-   struct lmb_property reserved_regions[MAX_LMB_REGIONS + 1];
+   struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS + 1];
+   struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS + 1];
 };
 
 extern void lmb_init(struct lmb *lmb);
diff --git a/lib/Kconfig b/lib/Kconfig
index 43bd7190b9..4249399b6f 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -706,6 +706,22 @@ config LMB
help
  Support the library logical memory blocks.
 
+config LMB_MEMORY_REGIONS
+   int "Number of memory regions in lmb lib"
+   depends on LMB
+   default 8
+   help
+ Define the number of supported memory regions in the library logical
+ memory blocks.
+
+config LMB_RESERVED_REGIONS
+   int "Number of reserved regions in lmb lib"
+   depends on LMB
+   default 8
+   help
+ Define the number of supported reserved regions in the library logical
+ memory blocks.
+
 endmenu
 
 config PHANDLE_CHECK_SEQ
-- 
2.17.1



[PATCH 2/5] lmb: remove lmb_region.size

2021-02-02 Thread Patrick Delaunay
Remove the unused field size of struct lmb_region as it is initialized to 0
and never used after in lmb library.

See Linux kernel commit 4734b594c6ca ("memblock: Remove memblock_type.size
and add memblock.memory_size instead")

Signed-off-by: Patrick Delaunay 
---

 include/lmb.h | 1 -
 lib/lmb.c | 6 --
 2 files changed, 7 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index e9f19b16ea..a3247544c1 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -21,7 +21,6 @@ struct lmb_property {
 
 struct lmb_region {
unsigned long cnt;
-   phys_size_t size;
struct lmb_property region[MAX_LMB_REGIONS+1];
 };
 
diff --git a/lib/lmb.c b/lib/lmb.c
index d126f8dc04..5cf419f439 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -20,8 +20,6 @@ void lmb_dump_all_force(struct lmb *lmb)
 
printf("lmb_dump_all:\n");
printf("memory.cnt = 0x%lx\n", lmb->memory.cnt);
-   printf("memory.size= 0x%llx\n",
-  (unsigned long long)lmb->memory.size);
for (i = 0; i < lmb->memory.cnt; i++) {
printf("memory.reg[0x%lx].base   = 0x%llx\n", i,
   (unsigned long long)lmb->memory.region[i].base);
@@ -30,8 +28,6 @@ void lmb_dump_all_force(struct lmb *lmb)
}
 
printf("\nreserved.cnt = 0x%lx\n", lmb->reserved.cnt);
-   printf("reserved.size  = 0x%llx\n",
-  (unsigned long long)lmb->reserved.size);
for (i = 0; i < lmb->reserved.cnt; i++) {
printf("reserved.reg[0x%lx].base = 0x%llx\n", i,
   (unsigned long long)lmb->reserved.region[i].base);
@@ -100,9 +96,7 @@ static void lmb_coalesce_regions(struct lmb_region *rgn, 
unsigned long r1,
 void lmb_init(struct lmb *lmb)
 {
lmb->memory.cnt = 0;
-   lmb->memory.size = 0;
lmb->reserved.cnt = 0;
-   lmb->reserved.size = 0;
 }
 
 static void lmb_reserve_common(struct lmb *lmb, void *fdt_blob)
-- 
2.17.1



[PATCH 3/5] lmb: Move lmb property arrays in struct lmb

2021-02-02 Thread Patrick Delaunay
Move lmb property arrays to struct lmb and manage the array size in
a the new element 'max' of struct lmb_region. This modification allows
to update its size independently in the next patch.

see Linux kernel commit bf23c51f1f49 ("memblock: Move memblock arrays
to static storage in memblock.c and make their size a variable")

Signed-off-by: Patrick Delaunay 
---

 include/lmb.h | 31 ++-
 lib/lmb.c |  8 +++-
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index a3247544c1..df543028d5 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -14,19 +14,48 @@
 
 #define MAX_LMB_REGIONS 8
 
+/**
+ * struct lmb_property - Description of one region.
+ *
+ * @base: Base address of the region.
+ * @size: Size of the region
+ */
 struct lmb_property {
phys_addr_t base;
phys_size_t size;
 };
 
+/**
+ * struct lmb_region - Description of a set of region.
+ *
+ * @cnt: Number of regions.
+ * @max: Size of the region array, max value of cnt.
+ * @region: Address of the region properties array
+ */
 struct lmb_region {
unsigned long cnt;
-   struct lmb_property region[MAX_LMB_REGIONS+1];
+   unsigned long max;
+   struct lmb_property *region;
 };
 
+/**
+ * struct lmb - Logical memory block handle.
+ *
+ * Clients provide storage for Logical memory block (lmb) handles.
+ * The content of the structure is managed by the lmb library.
+ * A lmb struct is  initialized by lmb_init() functions.
+ * The lmb struct is passed to all other lmb APIs.
+ *
+ * @memory: Description of memory regions.
+ * @reserved: Description of reserved regions.
+ * @memory_regions: Array of the memory regions (statically allocated)
+ * @reserved_regions: Array of the reserved regions (statically allocated)
+ */
 struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
+   struct lmb_property memory_regions[MAX_LMB_REGIONS + 1];
+   struct lmb_property reserved_regions[MAX_LMB_REGIONS + 1];
 };
 
 extern void lmb_init(struct lmb *lmb);
diff --git a/lib/lmb.c b/lib/lmb.c
index 5cf419f439..c97be0a064 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -95,7 +95,13 @@ static void lmb_coalesce_regions(struct lmb_region *rgn, 
unsigned long r1,
 
 void lmb_init(struct lmb *lmb)
 {
+   /* Hookup the initial arrays */
+   lmb->memory.region = lmb->memory_regions;
+   lmb->memory.max = ARRAY_SIZE(lmb->memory_regions) - 1;
lmb->memory.cnt = 0;
+
+   lmb->reserved.region = lmb->reserved_regions;
+   lmb->reserved.max = ARRAY_SIZE(lmb->reserved_regions) - 1;
lmb->reserved.cnt = 0;
 }
 
@@ -179,7 +185,7 @@ static long lmb_add_region(struct lmb_region *rgn, 
phys_addr_t base, phys_size_t
 
if (coalesced)
return coalesced;
-   if (rgn->cnt >= MAX_LMB_REGIONS)
+   if (rgn->cnt >= rgn->max)
return -1;
 
/* Couldn't coalesce the LMB, so add it to the sorted table. */
-- 
2.17.1



[PATCH 5/5] configs: stm32mp15: increase the number of reserved memory region in lmb

2021-02-02 Thread Patrick Delaunay
For the latest kernel device tree the max number of reserved regions
in lmb library is reached: 8 with 5 reserved regions in device tree.

When a new region is added, the lmb allocation for the device tree
relocation failed and boot with ramdisk failed.

This patch avoid this issue by increasing the max number of
supported reserved memory in lmb library.


Signed-off-by: Patrick Delaunay 
---

 configs/stm32mp15_basic_defconfig   | 1 +
 configs/stm32mp15_trusted_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index d3e5775a5a..df59ef70b1 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -157,3 +157,4 @@ CONFIG_WDT=y
 CONFIG_WDT_STM32MP=y
 CONFIG_ERRNO_STR=y
 CONFIG_FDT_FIXUP_PARTITIONS=y
+CONFIG_LMB_RESERVED_REGIONS=16
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index d392b0ff2a..0078dccf66 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -137,3 +137,4 @@ CONFIG_WDT=y
 CONFIG_WDT_STM32MP=y
 CONFIG_ERRNO_STR=y
 CONFIG_FDT_FIXUP_PARTITIONS=y
+CONFIG_LMB_RESERVED_REGIONS=16
-- 
2.17.1



[PATCH] clk: at91: compat: partially revert "dm: Remove uses of device_bind_offset()"

2021-02-02 Thread Eugen Hristev
Revert changes in at91 compat.c that cause u-boot to fail booting on
sama5d4_xplained and sama5d2_xplained

Log below:


No serial driver found
Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Fixes: a2703ce10c ("dm: Remove uses of device_bind_offset()")
Cc: Simon Glass 
Signed-off-by: Eugen Hristev 
---
 drivers/clk/at91/compat.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/at91/compat.c b/drivers/clk/at91/compat.c
index e514f26656..dfdc3a6a92 100644
--- a/drivers/clk/at91/compat.c
+++ b/drivers/clk/at91/compat.c
@@ -62,30 +62,34 @@ static int at91_pmc_core_probe(struct udevice *dev)
  */
 int at91_clk_sub_device_bind(struct udevice *dev, const char *drv_name)
 {
-   ofnode parent = dev_ofnode(dev);
-   ofnode node;
+   const void *fdt = gd->fdt_blob;
+   int offset = dev_of_offset(dev);
bool pre_reloc_only = !(gd->flags & GD_FLG_RELOC);
const char *name;
int ret;
 
-   ofnode_for_each_subnode(node, parent) {
-   if (pre_reloc_only && !ofnode_pre_reloc(node))
+   for (offset = fdt_first_subnode(fdt, offset);
+offset > 0;
+offset = fdt_next_subnode(fdt, offset)) {
+   if (pre_reloc_only &&
+   !ofnode_pre_reloc(offset_to_ofnode(offset)))
continue;
/*
 * If this node has "compatible" property, this is not
 * a clock sub-node, but a normal device. skip.
 */
-   if (ofnode_read_prop(node, "compatible", NULL))
+   fdt_get_property(fdt, offset, "compatible", &ret);
+   if (ret >= 0)
continue;
 
if (ret != -FDT_ERR_NOTFOUND)
return ret;
 
-   name = ofnode_get_name(node);
+   name = fdt_get_name(fdt, offset, NULL);
if (!name)
return -EINVAL;
-   ret = device_bind_driver_to_node(dev, drv_name, name, node,
-NULL);
+   ret = device_bind_driver_to_node(dev, drv_name, name,
+   offset_to_ofnode(offset), NULL);
if (ret)
return ret;
}
-- 
2.25.1



[PATCH] xilinx: common: Fix CONFIG_XILINX_OF_BOARD_DTB_ADDR handling for ZynqMP

2021-02-02 Thread Michal Simek
Fix bug introduced by commit listed below. It is for cases where Versal or
ZynqMP don't have DDR mapped. Later SPL was also excluded by
commit a672b9871b57 ("xilinx: common: Do not touch
CONFIG_XILINX_OF_BOARD_DTB_ADDR in SPL").

Fixes: 506009fc1022 ("xilinx: common: Change macro handling in 
board_fdt_blob_setup()")
Signed-off-by: Michal Simek 
---

 board/xilinx/common/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 4df10bf18941..a2f2fde64b65 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -326,7 +326,7 @@ void *board_fdt_blob_setup(void)
 
if (!IS_ENABLED(CONFIG_SPL_BUILD) &&
!IS_ENABLED(CONFIG_VERSAL_NO_DDR) &&
-   !IS_ENABLED(CONFIG_VERSAL_NO_DDR)) {
+   !IS_ENABLED(CONFIG_ZYNQMP_NO_DDR)) {
fdt_blob = (void *)CONFIG_XILINX_OF_BOARD_DTB_ADDR;
 
if (fdt_magic(fdt_blob) == FDT_MAGIC)
-- 
2.30.0



[PATCH v4 1/3] sysboot: add zboot support to boot x86 Linux kernel image

2021-02-02 Thread Kory Maincent
Add "zboot" command to the list of supported boot in the label_boot
function.

Signed-off-by: Kory Maincent 
Reviewed-by: Simon Glass 
---

Change since v1:
 - Modify comment.

Change since v2:
 - Update do_zboot to do_zboot_parent function to follow the patch:
   5588e776b0

Change since v3:
 - Follow review from Simon Glass
 - Add clean-up paches

 cmd/pxe_utils.c   | 4 
 include/command.h | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 3526a651d7..b788ee9576 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -657,6 +657,10 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
/* Try booting a Image */
else
do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
+#elif IS_ENABLED(CONFIG_CMD_ZBOOT)
+   /* Try booting an x86_64 Linux kernel image */
+   else
+   do_zboot_parent(cmdtp, 0, bootm_argc, bootm_argv, NULL);
 #endif
unmap_sysmem(buf);
 
diff --git a/include/command.h b/include/command.h
index e229bf2825..45d59f92d2 100644
--- a/include/command.h
+++ b/include/command.h
@@ -165,6 +165,9 @@ extern int do_bootz(struct cmd_tbl *cmdtp, int flag, int 
argc,
 extern int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[]);
 
+int do_zboot_parent(struct cmd_tbl *cmdtp, int flag, int argc,
+   char *const argv[], int *repeatable);
+
 extern int common_diskboot(struct cmd_tbl *cmdtp, const char *intf, int argc,
   char *const argv[]);
 
-- 
2.17.1



[PATCH v4 3/3] pxe_utils: clean-up, replace ifdef by IS_ENABLED

2021-02-02 Thread Kory Maincent
Replace all the macro ifdef by IS_ENABLED.
All of these configs are set in the defconfig files and not in the
include board headers files.

Signed-off-by: Kory Maincent 
---
 cmd/pxe_utils.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index b788ee9576..a6e7d27682 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -340,7 +340,7 @@ static int label_localboot(struct pxe_label *label)
 /*
  * Loads fdt overlays specified in 'fdtoverlays'.
  */
-#ifdef CONFIG_OF_LIBFDT_OVERLAY
+#if IS_ENABLED(CONFIG_OF_LIBFDT_OVERLAY)
 static void label_boot_fdtoverlay(struct cmd_tbl *cmdtp, struct pxe_label 
*label)
 {
char *fdtoverlay = label->fdtoverlays;
@@ -492,7 +492,7 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
env_get("gatewayip"), env_get("netmask"));
}
 
-#ifdef CONFIG_CMD_NET
+#if IS_ENABLED(CONFIG_CMD_NET)
if (label->ipappend & 0x2) {
int err;
 
@@ -626,7 +626,7 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
}
}
 
-#ifdef CONFIG_OF_LIBFDT_OVERLAY
+#if IS_ENABLED(CONFIG_OF_LIBFDT_OVERLAY)
if (label->fdtoverlays)
label_boot_fdtoverlay(cmdtp, label);
 #endif
@@ -649,11 +649,11 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID)
do_bootm(cmdtp, 0, bootm_argc, bootm_argv);
-#ifdef CONFIG_CMD_BOOTI
+#if IS_ENABLED(CONFIG_CMD_BOOTI)
/* Try booting an AArch64 Linux kernel image */
else
do_booti(cmdtp, 0, bootm_argc, bootm_argv);
-#elif defined(CONFIG_CMD_BOOTZ)
+#elif IS_ENABLED(CONFIG_CMD_BOOTZ)
/* Try booting a Image */
else
do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
@@ -1428,7 +1428,7 @@ void handle_pxe_menu(struct cmd_tbl *cmdtp, struct 
pxe_menu *cfg)
struct menu *m;
int err;
 
-#ifdef CONFIG_CMD_BMP
+#if IS_ENABLED(CONFIG_CMD_BMP)
/* display BMP if available */
if (cfg->bmp) {
if (get_relfile(cmdtp, cfg->bmp, image_load_addr)) {
-- 
2.17.1



[PATCH v4 2/3] command.h: Clean-up patch, remove extern from the header

2021-02-02 Thread Kory Maincent
Remove the extern of the header because they are useless.

Signed-off-by: Kory Maincent 
---
 include/command.h | 56 +++
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/include/command.h b/include/command.h
index 45d59f92d2..747f8f8095 100644
--- a/include/command.h
+++ b/include/command.h
@@ -55,8 +55,8 @@ struct cmd_tbl {
 };
 
 #if defined(CONFIG_CMD_RUN)
-extern int do_run(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[]);
+int do_run(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[]);
 #endif
 
 /* common/command.c */
@@ -69,7 +69,7 @@ int complete_subcmdv(struct cmd_tbl *cmdtp, int count, int 
argc,
 char *const argv[], char last_char, int maxv,
 char *cmdv[]);
 
-extern int cmd_usage(const struct cmd_tbl *cmdtp);
+int cmd_usage(const struct cmd_tbl *cmdtp);
 
 /* Dummy ->cmd and ->cmd_rep wrappers. */
 int cmd_always_repeatable(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -85,10 +85,10 @@ static inline bool cmd_is_repeatable(struct cmd_tbl *cmdtp)
 }
 
 #ifdef CONFIG_AUTO_COMPLETE
-extern int var_complete(int argc, char *const argv[], char last_char, int maxv,
-   char *cmdv[]);
-extern int cmd_auto_complete(const char *const prompt, char *buf, int *np,
-int *colp);
+int var_complete(int argc, char *const argv[], char last_char, int maxv,
+char *cmdv[]);
+int cmd_auto_complete(const char *const prompt, char *buf, int *np,
+ int *colp);
 #endif
 
 /**
@@ -145,13 +145,13 @@ int cmd_get_data_size(char *arg, int default_size);
 #endif
 
 #ifdef CONFIG_CMD_BOOTD
-extern int do_bootd(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
+int do_bootd(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
 #endif
 #ifdef CONFIG_CMD_BOOTM
-extern int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
-extern int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd);
+int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
+int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd);
 #else
 static inline int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd)
 {
@@ -159,31 +159,31 @@ static inline int bootm_maybe_autostart(struct cmd_tbl 
*cmdtp, const char *cmd)
 }
 #endif
 
-extern int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
+int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
 
-extern int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
+int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
 
 int do_zboot_parent(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[], int *repeatable);
 
-extern int common_diskboot(struct cmd_tbl *cmdtp, const char *intf, int argc,
-  char *const argv[]);
-
-extern int do_reset(struct cmd_tbl *cmdtp, int flag, int argc,
+int common_diskboot(struct cmd_tbl *cmdtp, const char *intf, int argc,
char *const argv[]);
-extern int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc,
-  char *const argv[]);
 
-extern unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
-   char *const argv[]);
+int do_reset(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
+int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc,
+   char *const argv[]);
+
+unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
+char *const argv[]);
 
 #if defined(CONFIG_CMD_NVEDIT_EFI)
-extern int do_env_print_efi(struct cmd_tbl *cmdtp, int flag, int argc,
-   char *const argv[]);
-extern int do_env_set_efi(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[]);
+int do_env_print_efi(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[]);
+int do_env_set_efi(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[]);
 #endif
 
 /**
-- 
2.17.1



RE: [PATCH 1/5] arm: dts: r8a774a1: Import DTS queued for Linux 5.12-rc1

2021-02-02 Thread Biju Das
Hi Marek and Adam,

> Subject: Re: [PATCH 1/5] arm: dts: r8a774a1: Import DTS queued for Linux
> 5.12-rc1
> 
> On 2/1/21 4:19 PM, Adam Ford wrote:
> > On Mon, Jan 25, 2021 at 6:40 AM Marek Vasut  wrote:
> >>
> >> On 1/25/21 12:22 AM, Adam Ford wrote:
> >>> On Sun, Jan 24, 2021 at 11:10 AM Marek Vasut  wrote:
> 
>  On 1/13/21 12:52 AM, Adam Ford wrote:
> > Update the RZ/G2M dtsi and r8a774a1-beacon-rzg2m-kit kit from
> > Renesas repo destined to become 5.12-rc1.
> 
>  I picked a DT sync for Linux 5.10 from Biju (on CC), does your
>  board need something from 5.12-rc1 or can it be based on 5.10 too ?
> >>>
> >>> I honestly don't remember.  I had to unexpectedly leave town for
> >>> this week due to a funeral, and I won't be near a Linux development
> >>> computer to run tests until Feb 1, so I don't know if the board will
> >>> build using 5.10 or not.  Sorry I don't have a better answer.
> >>
> >> Lets revisit this later then.
> >
> > I tested the Beacon boards, but they have a dependency on usb2_clksel
> > that is not present in the 5.10 device tree.
> > I also noticed that I forgot to include versaclock.h dt-binding file
> > from the kernel, so the Beacon boards don't build for that too.
> >

Do we have usb2_clksel support in u-boot? If yes, it make sense to import from 
5.12-rc1.
Similarly for other bits importing from kernel 5.12-rc1.

May be rpc-spcif support available in u-boot. So we could import from 5.12-rc1.
For  others like PCIe, ethernet the changes corresponding to dts is not present 
in driver.

Do we have any plans to update the driver or plan to delete the properties/nodes
from U-boot specific dtsi, so that we can save image size?

> > I can submit a V2 with the binding file included, or I can submit the
> > dt-binding file now and wait on the Beacon boards until that file has
> > been merged, or I can redo the device tree in a custom way to work the
> > 5.10 and not use the veraclock dt-bindings since there is no
> > versaclock driver in U-Boot anyway.  You may have an alternative as
> > well.
> 
> Can you try to figure out the best option with Biju , who is in charge of
> all the RZG stuff ? Either way works for me.
> 
> You also likely want to roll V2 out soon, since the RC1 is out. I would
> still like to pick it for 2021.04 .

As Marek, suggested please send V2.

Regards,
Biju


Re: [PATCH v3] sysboot: add zboot support to boot x86 Linux kernel image

2021-02-02 Thread Bin Meng
HI Köry,

On Tue, Feb 2, 2021 at 5:35 PM Köry Maincent  wrote:
>
> Hi Simon,
>
> Thanks for the review.
>
> On Mon, 1 Feb 2021 13:44:46 -0700
> Simon Glass  wrote:
>
> > Hi Kory,
> >
> > On Mon, 1 Feb 2021 at 08:31, Kory Maincent  
> > wrote:
> > >
> > > Add "zboot" command to the list of supported boot in the label_boot
> > > function.
> > >
> > > Signed-off-by: Kory Maincent 
> > > ---
> > >
> > > Change since v1:
> > >  - Modify comment
> > >
> > > Change since v2:
> > >  - Update do_zboot to do_zboot_parent function to follow the patch:
> > >5588e776b0
> > >
> > >  cmd/pxe_utils.c   | 4 
> > >  include/command.h | 3 +++
> > >  2 files changed, 7 insertions(+)
> > >
> > > diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> > > index 3526a651d7..06611262c1 100644
> > > --- a/cmd/pxe_utils.c
> > > +++ b/cmd/pxe_utils.c
> > > @@ -657,6 +657,10 @@ static int label_boot(struct cmd_tbl *cmdtp, struct
> > > pxe_label *label) /* Try booting a Image */
> > > else
> > > do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> > > +#elif defined(CONFIG_CMD_ZBOOT)
> >
> > Can this use IS_ENABLED() ?
>
> Yes it can use IS_ENABLED indeed.

A separate clean-up patch to convert existing ones using IS_ENABLED()

>
> >
> > > +   /* Try booting an x86_64 Linux kernel image */
> > > +   else
> > > +   do_zboot_parent(cmdtp, 0, bootm_argc, bootm_argv, NULL);
> > >  #endif
> > > unmap_sysmem(buf);
> > >
> > > diff --git a/include/command.h b/include/command.h
> > > index e229bf2825..cb91ba81b5 100644
> > > --- a/include/command.h
> > > +++ b/include/command.h
> > > @@ -165,6 +165,9 @@ extern int do_bootz(struct cmd_tbl *cmdtp, int flag,
> > > int argc, extern int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
> > > char *const argv[]);
> > >
> > > +extern int do_zboot_parent(struct cmd_tbl *cmdtp, int flag, int argc,
> > > +  char *const argv[], int *repeatable);
> >
> > We don't normally use extern for function decls in header files.
>
> Ok, why the other boot commands (do_booti, do_bootz) use extern?
>

I think you can create a clean-up patch to remove extern.

Regards,
Bin


Re: [PATCH v3] sysboot: add zboot support to boot x86 Linux kernel image

2021-02-02 Thread Köry Maincent
Hi Simon,

Thanks for the review.

On Mon, 1 Feb 2021 13:44:46 -0700
Simon Glass  wrote:

> Hi Kory,
> 
> On Mon, 1 Feb 2021 at 08:31, Kory Maincent  wrote:
> >
> > Add "zboot" command to the list of supported boot in the label_boot
> > function.
> >
> > Signed-off-by: Kory Maincent 
> > ---
> >
> > Change since v1:
> >  - Modify comment
> >
> > Change since v2:
> >  - Update do_zboot to do_zboot_parent function to follow the patch:
> >5588e776b0
> >
> >  cmd/pxe_utils.c   | 4 
> >  include/command.h | 3 +++
> >  2 files changed, 7 insertions(+)
> >
> > diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> > index 3526a651d7..06611262c1 100644
> > --- a/cmd/pxe_utils.c
> > +++ b/cmd/pxe_utils.c
> > @@ -657,6 +657,10 @@ static int label_boot(struct cmd_tbl *cmdtp, struct
> > pxe_label *label) /* Try booting a Image */
> > else
> > do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> > +#elif defined(CONFIG_CMD_ZBOOT)  
> 
> Can this use IS_ENABLED() ?

Yes it can use IS_ENABLED indeed.

> 
> > +   /* Try booting an x86_64 Linux kernel image */
> > +   else
> > +   do_zboot_parent(cmdtp, 0, bootm_argc, bootm_argv, NULL);
> >  #endif
> > unmap_sysmem(buf);
> >
> > diff --git a/include/command.h b/include/command.h
> > index e229bf2825..cb91ba81b5 100644
> > --- a/include/command.h
> > +++ b/include/command.h
> > @@ -165,6 +165,9 @@ extern int do_bootz(struct cmd_tbl *cmdtp, int flag,
> > int argc, extern int do_booti(struct cmd_tbl *cmdtp, int flag, int argc,
> > char *const argv[]);
> >
> > +extern int do_zboot_parent(struct cmd_tbl *cmdtp, int flag, int argc,
> > +  char *const argv[], int *repeatable);  
> 
> We don't normally use extern for function decls in header files.

Ok, why the other boot commands (do_booti, do_bootz) use extern?

Regards,


Re: [PATCH v3 1/1] env: sf: single function env_sf_save()

2021-02-02 Thread Stefan Roese

On 02.02.21 09:21, Harry Waschkeit wrote:

Instead of implementing redundant environments in two very similar
functions env_sf_save(), handle redundancy in one function, placing the
few differences in appropriate pre-compiler sections depending on config
option CONFIG_ENV_OFFSET_REDUND.

Additionally, several checkpatch complaints were addressed.

This patch is in preparation for adding support for env erase.

Signed-off-by: Harry Waschkeit 
Reviewed-by: Stefan Roese 
---
Change in v3:
  - no change in patch, only added "reviewed-by" to commit log


JFYI:
No need to re-send this patch with this added RB tag, as I already did
send a new RB to the last mail as reply. Patchwork collects these tags
when sent to the list. So you only need to include them, if you send
a new patch version.

Thanks,
Stefan


Change in v2:
  - remove one more #ifdef, instead take advantage of compiler attribute
__maybe_unused for one variable used only in case of redundant
environments

  env/sf.c | 130 ++-
  1 file changed, 41 insertions(+), 89 deletions(-)

diff --git a/env/sf.c b/env/sf.c
index 937778aa37..199114fd3b 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -66,13 +66,14 @@ static int setup_flash_device(void)
return 0;
  }
  
-#if defined(CONFIG_ENV_OFFSET_REDUND)

  static int env_sf_save(void)
  {
env_t   env_new;
-   char*saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
+   char*saved_buffer = NULL;
u32 saved_size, saved_offset, sector;
+   ulong   offset;
int ret;
+   __maybe_unused char flag = ENV_REDUND_OBSOLETE;
  
  	ret = setup_flash_device();

if (ret)
@@ -81,27 +82,33 @@ static int env_sf_save(void)
ret = env_export(&env_new);
if (ret)
return -EIO;
-   env_new.flags   = ENV_REDUND_ACTIVE;
  
-	if (gd->env_valid == ENV_VALID) {

-   env_new_offset = CONFIG_ENV_OFFSET_REDUND;
-   env_offset = CONFIG_ENV_OFFSET;
-   } else {
-   env_new_offset = CONFIG_ENV_OFFSET;
-   env_offset = CONFIG_ENV_OFFSET_REDUND;
-   }
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+   env_new.flags   = ENV_REDUND_ACTIVE;
+
+   if (gd->env_valid == ENV_VALID) {
+   env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+   env_offset = CONFIG_ENV_OFFSET;
+   } else {
+   env_new_offset = CONFIG_ENV_OFFSET;
+   env_offset = CONFIG_ENV_OFFSET_REDUND;
+   }
+   offset = env_new_offset;
+#else
+   offset = CONFIG_ENV_OFFSET;
+#endif
  
  	/* Is the sector larger than the env (i.e. embedded) */

if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
-   saved_offset = env_new_offset + CONFIG_ENV_SIZE;
+   saved_offset = offset + CONFIG_ENV_SIZE;
saved_buffer = memalign(ARCH_DMA_MINALIGN, saved_size);
if (!saved_buffer) {
ret = -ENOMEM;
goto done;
}
-   ret = spi_flash_read(env_flash, saved_offset,
-   saved_size, saved_buffer);
+   ret = spi_flash_read(env_flash, saved_offset, saved_size,
+saved_buffer);
if (ret)
goto done;
}
@@ -109,35 +116,39 @@ static int env_sf_save(void)
sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
  
  	puts("Erasing SPI flash...");

-   ret = spi_flash_erase(env_flash, env_new_offset,
-   sector * CONFIG_ENV_SECT_SIZE);
+   ret = spi_flash_erase(env_flash, offset,
+ sector * CONFIG_ENV_SECT_SIZE);
if (ret)
goto done;
  
  	puts("Writing to SPI flash...");
  
-	ret = spi_flash_write(env_flash, env_new_offset,

-   CONFIG_ENV_SIZE, &env_new);
+   ret = spi_flash_write(env_flash, offset,
+ CONFIG_ENV_SIZE, &env_new);
if (ret)
goto done;
  
  	if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {

-   ret = spi_flash_write(env_flash, saved_offset,
-   saved_size, saved_buffer);
+   ret = spi_flash_write(env_flash, saved_offset, saved_size,
+ saved_buffer);
if (ret)
goto done;
}
  
-	ret = spi_flash_write(env_flash, env_offset + offsetof(env_t, flags),

-   sizeof(env_new.flags), &flag);
-   if (ret)
-   goto done;
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+   ret = spi_flash_write(env_flash, env_offset + offsetof(env_t, 
flags),
+ siz

Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Bin Meng
On Tue, Feb 2, 2021 at 5:04 PM Marek Vasut  wrote:
>
> On 2/2/21 9:54 AM, Bin Meng wrote:
> [...]
>  cache aligned in memory, however the cache operations are called on
>  the structure sizes, which themselves might not be cache aligned. Add
>  the necessary rounding to fix this, which permits the nvme to work on
>  arm64.
> >>>
> >>> +ARM guys
> >>>
> >>> Which ARM64 SoC did you test this with?
> >>
> >> RCar3, although that's irrelevant, the problem will happen on any arm or
> >> arm64, and possibly any other system which needs cache management.
> >
> > There was a recent change to nvme.c that fixed a cache issue on ARMv8
> > so I thought this might be platform related.
>
> I used master, so unlikely.

It's strange this issue was not exposed last time when this driver was
tested on ARMv8.

>
> >>> The round down in this patch should be unnecessary.
> >>
> >> Can you explain why ?
> >
> > I just took a further look and most of the start address should be
> > cache line aligned (4KiB aligned) except the
> > nvme_read_completion_status(). It's only 16 bytes aligned which might
> > not be cache line aligned.
>
> Right, there are various arm chips with 32B/64B alignment requirements.
>
> >>> But it's better to
> >>> figure out which call to dcache_xxx() with an unaligned end address.
> >>
> >> If you look at the code, most of them can (and do) trigger this,
> >> therefore they need such alignment, as explained in the commit message.
> >
> > Now I wonder what's the correct implementation of the
> > invalidate_dcache_range() and flush_dcache_range() in U-Boot?
> > Shouldn't the round down/up happen in these APIs instead of doing such
> > in drivers?
>
> Definitely not, because then the rounding might flush/invalidate cache
> over areas where this could cause a problem (e.g. neighboring DMA
> descriptors). The driver must do the cache management correctly.

Well we can implement in these APIs and document its expected usage.
Either way a driver has to do the cache management correctly. Not
doing it in the driver eliminates some duplications of rounding
up/down.

For this case, I believe we just need to take care of
nvme_read_completion_status().

Regards,
Bin


RE: Subject:[PATCH v2 4/4] board/km: add support for seli8 design based on nxp ls102x

2021-02-02 Thread Aleksandar Gerasimovski


-Original Message-
From: Priyanka Jain (OSS)  
Sent: Dienstag, 2. Februar 2021 07:33
To: Aleksandar Gerasimovski ; 
Priyanka Jain (OSS) ; u-boot@lists.denx.de
Cc: Valentin Longchamp ; Holger 
Brunck ; Rainer Boschung 
; Matteo Ghidoni 

Subject: RE: Subject: [PATCH v2 4/4] board/km: add support for seli8 design 
based on nxp ls102x

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


>-Original Message-
>From: Aleksandar Gerasimovski powergrids.com>
>Sent: Tuesday, January 19, 2021 4:11 PM
>To: Priyanka Jain (OSS) ; 
>u-boot@lists.denx.de
>Cc: Valentin Longchamp ; 
>Holger Brunck ; Rainer Boschung 
>; Matteo Ghidoni 
>
>Subject: Subject: [PATCH v2 4/4] board/km: add support for seli8 design 
>based on nxp ls102x
>
>The SELI8 design is a new tdm service unit card for Hitachi-Powergrids 
>XMC and FOX product lines.
>
>It is based on NXP LS1021 SoC and it provides following interfaces:
> - IFC interface for NOR, NAND and external FPGA's
> - 1 x RGMII ETH for debug purposes
> - 2 x SGMII ETH for management communication via back-plane
> - 1 x uQE HDLC for management communication via back-plane
> - 1 x I2C for peripheral devices
> - 1 x SPI for peripheral devices
> - 1 x UART for debug logging
>
>It is foreseen that the design will be later re-used for another XMC 
>and FOX service cards with similar SoC requirements.
>
>Signed-off-by: Rainer Boschung 
>Signed-off-by: Matteo Ghidoni 
>Signed-off-by: Aleksandar Gerasimovski 
>
>---

Kindly fix below checkpatch errors /warnings
WARNING: 'AYSNC' may be misspelled - perhaps 'ASYNC'?
#799: FILE: include/configs/km/pg-wcom-ls102xa.h:64:
+   CSOR_NOR_NOR_MODE_AYSNC_NOR | \

ERROR: All commands are managed by Kconfig
#953: FILE: include/configs/km/pg-wcom-ls102xa.h:218:
+#define CONFIG_CMDLINE_TAG

total: 1 errors, 2 warnings, 0 checks, 964 lines checked

Regards
Priyanka

Hi Priyanka,

CSOR_NOR_NOR_MODE_AYSNC_NOR is named like in mainline (nxp) see 
include/fsl_ifc.h
If you asking me to change that than it belongs to a separate patch, not this 
topic.

CONFIG_CMDLINE_TAG is a whitelisted on mainline, there is no Kconfig for that.

Regards,
Aleksandar




Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Marek Vasut

On 2/2/21 9:54 AM, Bin Meng wrote:
[...]

cache aligned in memory, however the cache operations are called on
the structure sizes, which themselves might not be cache aligned. Add
the necessary rounding to fix this, which permits the nvme to work on
arm64.


+ARM guys

Which ARM64 SoC did you test this with?


RCar3, although that's irrelevant, the problem will happen on any arm or
arm64, and possibly any other system which needs cache management.


There was a recent change to nvme.c that fixed a cache issue on ARMv8
so I thought this might be platform related.


I used master, so unlikely.


The round down in this patch should be unnecessary.


Can you explain why ?


I just took a further look and most of the start address should be
cache line aligned (4KiB aligned) except the
nvme_read_completion_status(). It's only 16 bytes aligned which might
not be cache line aligned.


Right, there are various arm chips with 32B/64B alignment requirements.


But it's better to
figure out which call to dcache_xxx() with an unaligned end address.


If you look at the code, most of them can (and do) trigger this,
therefore they need such alignment, as explained in the commit message.


Now I wonder what's the correct implementation of the
invalidate_dcache_range() and flush_dcache_range() in U-Boot?
Shouldn't the round down/up happen in these APIs instead of doing such
in drivers?


Definitely not, because then the rounding might flush/invalidate cache 
over areas where this could cause a problem (e.g. neighboring DMA 
descriptors). The driver must do the cache management correctly.


Re: [PATCH] mmc: mv_sdhci: parse device-tree entry

2021-02-02 Thread Jaehoon Chung
On 2/2/21 3:43 PM, Baruch Siach wrote:
> Call mmc_of_parse() so that generic DT properties like 'non-removable'
> are taken into account.
> 
> This fixes boot on Clearfog with eMMC on SOM that requires the
> non-removable property.
> 
> Reported-by: Thorsten Spille 
> Signed-off-by: Baruch Siach 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/mv_sdhci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 9b3dfa13e619..0a8987c1b5da 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -118,6 +118,10 @@ static int mv_sdhci_probe(struct udevice *dev)
>   host->mmc->dev = dev;
>   host->mmc->priv = host;
>  
> + ret = mmc_of_parse(dev, &plat->cfg);
> + if (ret)
> + return ret;
> +
>   ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
>   if (ret)
>   return ret;
> 



Re: [PATCH] nvme: Fix cache alignment

2021-02-02 Thread Bin Meng
On Tue, Feb 2, 2021 at 4:05 PM Marek Vasut  wrote:
>
> On 2/2/21 4:55 AM, Bin Meng wrote:
>
> Hi,
>
> >> The various structures in the driver are already correcty padded and
> >
> > typo: correctly
> >
> >> cache aligned in memory, however the cache operations are called on
> >> the structure sizes, which themselves might not be cache aligned. Add
> >> the necessary rounding to fix this, which permits the nvme to work on
> >> arm64.
> >
> > +ARM guys
> >
> > Which ARM64 SoC did you test this with?
>
> RCar3, although that's irrelevant, the problem will happen on any arm or
> arm64, and possibly any other system which needs cache management.

There was a recent change to nvme.c that fixed a cache issue on ARMv8
so I thought this might be platform related.

>
> > The round down in this patch should be unnecessary.
>
> Can you explain why ?

I just took a further look and most of the start address should be
cache line aligned (4KiB aligned) except the
nvme_read_completion_status(). It's only 16 bytes aligned which might
not be cache line aligned.

>
> > But it's better to
> > figure out which call to dcache_xxx() with an unaligned end address.
>
> If you look at the code, most of them can (and do) trigger this,
> therefore they need such alignment, as explained in the commit message.

Now I wonder what's the correct implementation of the
invalidate_dcache_range() and flush_dcache_range() in U-Boot?
Shouldn't the round down/up happen in these APIs instead of doing such
in drivers?

Regards,
Bin


Re: [QUESTION] Kernel 5.10 image might be too big to be loaded by U-Boot on RPi 4B

2021-02-02 Thread Matthias Brugger
On Thu, Jan 28, 2021 at 04:54:03PM +0800, Jian-Hong Pan wrote:
> Load u-Boot environment ... from mmc 0:2
> 622 bytes read in 24 ms (24.4 KiB/s)
> Load device tree ...
> 25693 bytes read in 30 ms (835.9 KiB/s)
> fdt_addr_r @  0x0260 , size= 645d
> Load kernel and unzip it ...
> 13013555 bytes read in 574 ms (21.6 MiB/s)
> Uncompressed size: 38742528 = 0x24F2A00
> kernel_addr_r @  0x0008 , size= 24f2a00
> Load RAM disk ...
> 54360540 bytes read in 2298 ms (22.6 MiB/s)
> ramdisk_addr_r @  0x0270 , size= 33d79dc
> Boot ...
> Moving Image from 0x8 to 0x20, end=282
> ERROR: RD image overlaps OS image (OS=0x20..0x282)
> SCRIPT FAILED: continuing...
> Card did not respond to voltage select!
> genet@7d58 Waiting for PHY auto negotiation to complete
> 
> It shows error: "RD image overlaps OS image (OS=0x20..0x282)"
> 
> So, I calculated the memory address and space:
> 
> 0x20 (kernel start address) + 0x24F2A00 (kernel size) = 0x26F2A00 <
> 282 (kernel end), but > 0x270 (ramdisk start address) & > 0x260
> (FDT start address)
> 
> The kernel image size 0x24F2A00 bytes is too fat to sit in the memory space
> prepared by U-Boot and overlaps ramdisk and FDT's memory spaces.
> It is more than 36.9MB, which is over 36MB mentioned in U-Boot's comment
> [2].
> 

If I did the math right, we should have a lot of space left. 
You could try to bump up fdt_addr_r=0x0290 and
ramdisk_addr_r=0x02A0 and see what happens.

Regards,
Matthias


> We understand this can be fixed by a workaround like tuning/reducing the
> kernel's build config.  However, is it possible to have another way to
> resolve this problem?
> 
> [1]
> https://kernel.ubuntu.com/git/ubuntu/unstable.git/tree/?h=Ubuntu-5.10-5.10.0-10.11
> [2]
> https://github.com/u-boot/u-boot/blob/v2021.01/include/configs/rpi.h#L140
> 
> Jain-Hong Pan


[PATCH v3 1/1] env: sf: single function env_sf_save()

2021-02-02 Thread Harry Waschkeit
Instead of implementing redundant environments in two very similar
functions env_sf_save(), handle redundancy in one function, placing the
few differences in appropriate pre-compiler sections depending on config
option CONFIG_ENV_OFFSET_REDUND.

Additionally, several checkpatch complaints were addressed.

This patch is in preparation for adding support for env erase.

Signed-off-by: Harry Waschkeit 
Reviewed-by: Stefan Roese  
---
Change in v3:
 - no change in patch, only added "reviewed-by" to commit log

Change in v2:
 - remove one more #ifdef, instead take advantage of compiler attribute
   __maybe_unused for one variable used only in case of redundant
   environments

 env/sf.c | 130 ++-
 1 file changed, 41 insertions(+), 89 deletions(-)

diff --git a/env/sf.c b/env/sf.c
index 937778aa37..199114fd3b 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -66,13 +66,14 @@ static int setup_flash_device(void)
return 0;
 }
 
-#if defined(CONFIG_ENV_OFFSET_REDUND)
 static int env_sf_save(void)
 {
env_t   env_new;
-   char*saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
+   char*saved_buffer = NULL;
u32 saved_size, saved_offset, sector;
+   ulong   offset;
int ret;
+   __maybe_unused char flag = ENV_REDUND_OBSOLETE;
 
ret = setup_flash_device();
if (ret)
@@ -81,27 +82,33 @@ static int env_sf_save(void)
ret = env_export(&env_new);
if (ret)
return -EIO;
-   env_new.flags   = ENV_REDUND_ACTIVE;
 
-   if (gd->env_valid == ENV_VALID) {
-   env_new_offset = CONFIG_ENV_OFFSET_REDUND;
-   env_offset = CONFIG_ENV_OFFSET;
-   } else {
-   env_new_offset = CONFIG_ENV_OFFSET;
-   env_offset = CONFIG_ENV_OFFSET_REDUND;
-   }
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+   env_new.flags   = ENV_REDUND_ACTIVE;
+
+   if (gd->env_valid == ENV_VALID) {
+   env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+   env_offset = CONFIG_ENV_OFFSET;
+   } else {
+   env_new_offset = CONFIG_ENV_OFFSET;
+   env_offset = CONFIG_ENV_OFFSET_REDUND;
+   }
+   offset = env_new_offset;
+#else
+   offset = CONFIG_ENV_OFFSET;
+#endif
 
/* Is the sector larger than the env (i.e. embedded) */
if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
-   saved_offset = env_new_offset + CONFIG_ENV_SIZE;
+   saved_offset = offset + CONFIG_ENV_SIZE;
saved_buffer = memalign(ARCH_DMA_MINALIGN, saved_size);
if (!saved_buffer) {
ret = -ENOMEM;
goto done;
}
-   ret = spi_flash_read(env_flash, saved_offset,
-   saved_size, saved_buffer);
+   ret = spi_flash_read(env_flash, saved_offset, saved_size,
+saved_buffer);
if (ret)
goto done;
}
@@ -109,35 +116,39 @@ static int env_sf_save(void)
sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
 
puts("Erasing SPI flash...");
-   ret = spi_flash_erase(env_flash, env_new_offset,
-   sector * CONFIG_ENV_SECT_SIZE);
+   ret = spi_flash_erase(env_flash, offset,
+ sector * CONFIG_ENV_SECT_SIZE);
if (ret)
goto done;
 
puts("Writing to SPI flash...");
 
-   ret = spi_flash_write(env_flash, env_new_offset,
-   CONFIG_ENV_SIZE, &env_new);
+   ret = spi_flash_write(env_flash, offset,
+ CONFIG_ENV_SIZE, &env_new);
if (ret)
goto done;
 
if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
-   ret = spi_flash_write(env_flash, saved_offset,
-   saved_size, saved_buffer);
+   ret = spi_flash_write(env_flash, saved_offset, saved_size,
+ saved_buffer);
if (ret)
goto done;
}
 
-   ret = spi_flash_write(env_flash, env_offset + offsetof(env_t, flags),
-   sizeof(env_new.flags), &flag);
-   if (ret)
-   goto done;
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+   ret = spi_flash_write(env_flash, env_offset + offsetof(env_t, 
flags),
+ sizeof(env_new.flags), &flag);
+   if (ret)
+   goto done;
 
-   puts("done\n");
+   puts("done\n");
 
-   gd->env_valid = gd->env_valid == ENV_REDUND ? ENV_VALID : ENV_REDUND;
+   gd->env_valid = gd->env_valid == ENV_REDU

RE: [v3 16/33] configs: ls1021atwr: enable CONFIG_MPC8XXX_GPIO

2021-02-02 Thread Biwen Li (OSS)


> -Original Message-
> From: Priyanka Jain (OSS) 
> Sent: 2021年2月2日 14:03
> To: Biwen Li (OSS) 
> Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
> ; Biwen Li 
> Subject: RE: [v3 16/33] configs: ls1021atwr: enable CONFIG_MPC8XXX_GPIO
> 
> >-Original Message-
> >From: U-Boot  On Behalf Of Biwen Li
> >Sent: Thursday, January 28, 2021 3:10 PM
> >To: Priyanka Jain 
> >Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
> >; Biwen Li 
> >Subject: [v3 16/33] configs: ls1021atwr: enable CONFIG_MPC8XXX_GPIO
> >
> >From: Biwen Li 
> >
> >Enable CONFIG_MPC8XXX_GPIO for board ls1021atwr
> >
> >Signed-off-by: Biwen Li 
> >---
> 
> Kindly fix below build error for ls1021atwr platforms
> 
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../drivers/gpio/mpc8xxx_gpio.c: In function â
> mpc8xxx_gpio_get_valâ :
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../drivers/gpio/mpc8xxx_gpio.c:50:29: error:
> dereferencing pointer to incomplete type â struct ccsr_gpioâ
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi)return in_le32(&data->base->gpdat) & mask;
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi)  ^
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> +ls1021atwr_qspi ls1021atwr_sdcard_ifc
> ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../include/linux/byteorder/little_endian.h:35:51:
> note: in definition of macro â __le32_to_cpuâ (ls1021atwr_nor
> ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT ls1021atwr_qspi
> ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi)  #define __le32_to_cpu(x) ((__force
> __u32)(__le32)(x))
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi)
> ^
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> +ls1021atwr_qspi ls1021atwr_sdcard_ifc
> ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../arch/arm/include/asm/io.h:105:25: note: in
> expansion of macro â __arch_getlâ (ls1021atwr_nor ls1021atwr_nor_lpuart
> ls1021atwr_nor_SECURE_BOOT ls1021atwr_qspi ls1021atwr_sdcard_ifc
> ls1021atwr_sdcard_ifc_SECURE_BOOT ls1021atwr_sdcard_qspi)  #define
> __raw_readl(a)  __arch_getl(a)
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi)  ^~~
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> +ls1021atwr_qspi ls1021atwr_sdcard_ifc
> ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../arch/arm/include/asm/io.h:173:49: note: in
> expansion of macro â __raw_readlâ (ls1021atwr_nor ls1021atwr_nor_lpuart
> ls1021atwr_nor_SECURE_BOOT ls1021atwr_qspi ls1021atwr_sdcard_ifc
> ls1021atwr_sdcard_ifc_SECURE_BOOT ls1021atwr_sdcard_qspi)  #define
> in_arch(type,endian,a)  endian##_to_cpu(__raw_read##type(a))
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi)
> ^~
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> +ls1021atwr_qspi ls1021atwr_sdcard_ifc
> ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../arch/arm/include/asm/io.h:180:20: note: in
> expansion of macro â in_archâ (ls1021atwr_nor ls1021atwr_nor_lpuart
> ls1021atwr_nor_SECURE_BOOT ls1021atwr_qspi ls1021atwr_sdcard_ifc
> ls1021atwr_sdcard_ifc_SECURE_BOOT ls1021atwr_sdcard_qspi)  #define
> in_le32(a) in_arch(l,le32,a)
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ^~~
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../drivers/gpio/mpc8xxx_gpio.c:50:10: note: in
> expansion of macro â in_le32â
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi)   ^~~
> +(ls1021atwr_nor ls1021atwr_nor_lpuart ls1021atwr_nor_SECURE_BOOT
> ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> ls1021atwr_sdcard_qspi) ../drivers/gpio/mpc8xxx_gpio.c: In function â
> mpc8xxx_gpio_of_to_platâ :
> +(ls1021atwr_nor ls1021atwr_nor_lpuart 

[v4 32/33] configs: lx2160ardb: enable CMD_GPIO

2021-02-02 Thread Biwen Li
From: Biwen Li 

Enable CMD_GPIO for board lx2160ardb

Signed-off-by: Biwen Li 
---
 configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 +
 configs/lx2160ardb_tfa_defconfig | 1 +
 configs/lx2160ardb_tfa_stmm_defconfig| 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
index 0551ef0793..a57ed79c11 100644
--- a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
@@ -26,6 +26,7 @@ CONFIG_CMD_GREPENV=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_DM=y
 CONFIG_CMD_GPT=y
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig
index 52ac1264ae..bd2e839ee3 100644
--- a/configs/lx2160ardb_tfa_defconfig
+++ b/configs/lx2160ardb_tfa_defconfig
@@ -28,6 +28,7 @@ CONFIG_CMD_GREPENV=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_DM=y
 CONFIG_CMD_GPT=y
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_OPTEE_RPMB=y
diff --git a/configs/lx2160ardb_tfa_stmm_defconfig 
b/configs/lx2160ardb_tfa_stmm_defconfig
index d9c1674026..5afb2d055b 100644
--- a/configs/lx2160ardb_tfa_stmm_defconfig
+++ b/configs/lx2160ardb_tfa_stmm_defconfig
@@ -29,6 +29,7 @@ CONFIG_CMD_NVEDIT_EFI=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_DM=y
 CONFIG_CMD_GPT=y
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
-- 
2.17.1



[v4 33/33] configs: lx2160aqds: enable CMD_GPIO

2021-02-02 Thread Biwen Li
From: Biwen Li 

Enable CMD_GPIO for board lx2160aqds

Signed-off-by: Biwen Li 
---
 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 +
 configs/lx2160aqds_tfa_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
index cf4bf8a19a..13f817eedc 100644
--- a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
@@ -26,6 +26,7 @@ CONFIG_CMD_GREPENV=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_DM=y
 CONFIG_CMD_GPT=y
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig
index f0e8dca8f9..2bc023f780 100644
--- a/configs/lx2160aqds_tfa_defconfig
+++ b/configs/lx2160aqds_tfa_defconfig
@@ -28,6 +28,7 @@ CONFIG_CMD_GREPENV=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_DM=y
 CONFIG_CMD_GPT=y
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
-- 
2.17.1



[v4 31/33] configs: ls1088ardb: enable DM_GPIO and CMD_GPIO

2021-02-02 Thread Biwen Li
From: Biwen Li 

Enable DM_GPIO and CMD_GPIO for board ls1088ardb

Signed-off-by: Biwen Li 
---
 configs/ls1088ardb_qspi_SECURE_BOOT_defconfig| 2 ++
 configs/ls1088ardb_qspi_defconfig| 2 ++
 configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 2 ++
 configs/ls1088ardb_sdcard_qspi_defconfig | 2 ++
 configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 +
 configs/ls1088ardb_tfa_defconfig | 1 +
 6 files changed, 10 insertions(+)

diff --git a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig 
b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig
index b4fdc00aa5..2c461816bc 100644
--- a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig
+++ b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig
@@ -23,6 +23,7 @@ CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
earlycon=uart8250,mmio,0x21
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_MISC_INIT_R=y
+CONFIG_DM_GPIO=y
 CONFIG_CMD_GREPENV=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
@@ -39,6 +40,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_CMD_GPIO=y
 CONFIG_SCSI_AHCI=y
 CONFIG_SATA_CEVA=y
 CONFIG_DM_MMC=y
diff --git a/configs/ls1088ardb_qspi_defconfig 
b/configs/ls1088ardb_qspi_defconfig
index 40fe7c4520..f474119d59 100644
--- a/configs/ls1088ardb_qspi_defconfig
+++ b/configs/ls1088ardb_qspi_defconfig
@@ -24,6 +24,7 @@ CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
earlycon=uart8250,mmio,0x21
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_MISC_INIT_R=y
+CONFIG_DM_GPIO=y
 CONFIG_CMD_GREPENV=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
@@ -42,6 +43,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x2030
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_CMD_GPIO=y
 CONFIG_SCSI_AHCI=y
 CONFIG_SATA_CEVA=y
 CONFIG_DM_MMC=y
diff --git a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig 
b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig
index 9c7a85fe62..83b99e1236 100644
--- a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig
+++ b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig
@@ -35,6 +35,7 @@ CONFIG_SPL_HASH_SUPPORT=y
 CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y
+CONFIG_DM_GPIO=y
 CONFIG_CMD_GREPENV=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
@@ -52,6 +53,7 @@ CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_CMD_GPIO=y
 CONFIG_SPL_DM=y
 CONFIG_SCSI_AHCI=y
 CONFIG_FSL_ESDHC=y
diff --git a/configs/ls1088ardb_sdcard_qspi_defconfig 
b/configs/ls1088ardb_sdcard_qspi_defconfig
index d409ef3f94..7f49253f53 100644
--- a/configs/ls1088ardb_sdcard_qspi_defconfig
+++ b/configs/ls1088ardb_sdcard_qspi_defconfig
@@ -34,6 +34,7 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x8b0
 CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y
+CONFIG_DM_GPIO=y
 CONFIG_CMD_GREPENV=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
@@ -52,6 +53,7 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_CMD_GPIO=y
 CONFIG_SCSI_AHCI=y
 CONFIG_SATA_CEVA=y
 CONFIG_DM_MMC=y
diff --git a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig 
b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig
index 6a07577015..095a85bb59 100644
--- a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig
@@ -41,6 +41,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_CMD_GPIO=y
 CONFIG_SCSI_AHCI=y
 CONFIG_SATA_CEVA=y
 CONFIG_DM_I2C=y
diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index d9b11eba71..49a49cd6d9 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -46,6 +46,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x2050
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_CMD_GPIO=y
 CONFIG_SCSI_AHCI=y
 CONFIG_SATA_CEVA=y
 CONFIG_DM_I2C=y
-- 
2.17.1



  1   2   >