Re: [ANN] U-Boot v2020.07-rc2 released

[Heinrich Schuchardt]

On 5/13/20 5:54 AM, Heiko Schocher wrote:
> Hello Tom,
>
> Am 12.05.2020 um 15:28 schrieb Heiko Schocher:
>> Hello Tom,
>>
>> Am 12.05.2020 um 00:28 schrieb Tom Rini:
>>> Hey all,
>>>
>>> It's release day and I've tagged v2020.07-rc2.  At this point out we
>>> should be seeing stabilization, clean-up and localized new features.
>>>
>>> Once again, for a changelog,
>>> git log --merges v2020.07-rc1..v2020.07-rc2
>>> and as always, I ask for more details in the PRs people send me so I can
>>> put them in the merge commit.
>>>
>>> I'm planning to follow the every-other-week RC schedule and release on
>>> July 6th.  I'm also thinking about opening -next again on June 8th as
>>> that will give us a bit more time to focus on stability and regression
>>> fixing.  Thanks all!
>>>
>>
>> FYI:
>>
>> I have now running the following 4 boards in my daily automated tbot
>> testsetup (build and install U-boot on the boards, and run test.py)
>>
>> wandboard DL (imx6)
>> http://xeidos.ddns.net/ubtestresults/result/69
>>
>> socrates (mpc85xx)
>> http://xeidos.ddns.net/ubtestresults/result/70
>>
>> BBB (am335x)
>> http://xeidos.ddns.net/ubtestresults/result/71
>>
>> aristainetos2 (imx6) (with some patches on top, gpio fixes just posted
>> also on this board with secure boot enabled)
>> http://xeidos.ddns.net/ubtestresults/result/72
>>
>> Hope I find time to get this up and running for some of my at91 boards
>
> May I am nerving with this stuff .. but today morning, I see for the
> wandboard with commit 10bca13ea6 the image size increased around ~35K
> compared to commit 2a38d2239
>
> http://xeidos.ddns.net/ubtestresults/stats/wandboard_defconfig/10
>
> bye,
> Heiko

Hello Heiko,

I am not able to reproduce your 35k increase. This is what I got:

10bca13ea6
668860 u-boot-with-spl.imx
599164 u-boot.bin

2a38d2239
668780 u-boot-with-spl.imx
599084 u-boot.bin

80 additional bytes seems to be in line with the few lines added to
drivers/gpio/gpio-uclass.c in 47bd533e9dd0 ("gpio: emulate open drain &
open source in dm_gpio_set_value()").

I am building on Debian Buster with gcc (Debian 9.3.0-11) 9.3.0.

Please, indicate the size of which file is shown in the caption of your
graphs.
Please, check if your distribution updated your build system between the
two builds.

Best regards

Heinrich

[PATCH] MAINTAINERS: POWERPC MPC8XX: Update email address

[Christophe Leroy]

Our email addresses have changed from @c-s.fr to @csgroup.eu

Update entry in MAINTAINERS

Signed-off-by: Christophe Leroy 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ec59ce8b8802..d67112479700 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -818,7 +818,7 @@ S:  Maintained
 F: arch/powerpc/
 
 POWERPC MPC8XX
-M: Christophe Leroy 
+M: Christophe Leroy 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-mpc8xx.git
 F: arch/powerpc/cpu/mpc8xx/
-- 
2.25.0

Re: [ANN] U-Boot v2020.07-rc2 released

[Heiko Schocher]

Hello Tom,

Am 12.05.2020 um 15:28 schrieb Heiko Schocher:

Hello Tom,

Am 12.05.2020 um 00:28 schrieb Tom Rini:

Hey all,

It's release day and I've tagged v2020.07-rc2.  At this point out we
should be seeing stabilization, clean-up and localized new features.

Once again, for a changelog,
git log --merges v2020.07-rc1..v2020.07-rc2
and as always, I ask for more details in the PRs people send me so I can
put them in the merge commit.

I'm planning to follow the every-other-week RC schedule and release on
July 6th.  I'm also thinking about opening -next again on June 8th as
that will give us a bit more time to focus on stability and regression
fixing.  Thanks all!



FYI:

I have now running the following 4 boards in my daily automated tbot
testsetup (build and install U-boot on the boards, and run test.py)

wandboard DL (imx6)
http://xeidos.ddns.net/ubtestresults/result/69

socrates (mpc85xx)
http://xeidos.ddns.net/ubtestresults/result/70

BBB (am335x)
http://xeidos.ddns.net/ubtestresults/result/71

aristainetos2 (imx6) (with some patches on top, gpio fixes just posted
also on this board with secure boot enabled)
http://xeidos.ddns.net/ubtestresults/result/72

Hope I find time to get this up and running for some of my at91 boards


May I am nerving with this stuff .. but today morning, I see for the
wandboard with commit 10bca13ea6 the image size increased around ~35K
compared to commit 2a38d2239

http://xeidos.ddns.net/ubtestresults/stats/wandboard_defconfig/10

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

Re: [PATCH 1/1] tools: ftdgrep: use /* fallthrough */ as needed

[Tom Rini]

On Mon, May 11, 2020 at 09:08:03PM +0200, Heinrich Schuchardt wrote:
> On 5/11/20 8:40 PM, Tom Rini wrote:
> > On Sun, May 10, 2020 at 10:12:07PM +0900, Masahiro Yamada wrote:
> >> On Sun, May 10, 2020 at 12:12 AM Heinrich Schuchardt  
> >> wrote:
> >>>
> >>> GCC recognizes /* fallthrough */ if -Wimplicit-fallthrough=3 is enabled.
> >>
> >> FYI.
> >>
> >> Linux decided to not use /* fallthrough */ any more
> >> because Clang does not recognize it.
> >>
> >> __attribute__((__fallthrough__)) is supported
> >> by both Clang and recent GCC.
> In fact Linux has a define:
> 
> include/linux/compiler_attributes.h:200:# define fallthrough
> __attribute__((__fallthrough__))
> 
> And in the code you would use
> 
>   case foo:
>   fallthrough;
>   case bar:
> 
> But the Linux kernel still has a lot of lines with
> 
> /* fallthrough */
> 
> Documentation/process/deprecated.rst:
> 
> 
> As there have been a long list of flaws `due to missing "break"
> statements `_, we no
> longer allow implicit fall-through. In order to identify intentional
> fall-through cases, we have adopted a pseudo-keyword macro "fallthrough"
> which expands to gcc's extension `__attribute__((__fallthrough__))
> `_. (When
> the C17/C18  `[[fallthrough]]` syntax is more commonly supported by C
> compilers, static analyzers, and IDEs, we can switch to using that
> syntax for the macro pseudo-keyword.)
> 
> 
> Using the attribute is not standard C and not any better than using the
> comment. The real target is the C17 syntax.
> 
> >>
> >>
> >> Linux is now doing treewide conversion
> >> from /* fallthrough */ to 'fallthrough;'.
> >>
> >> See include/linux/compiler_attributes.h in Linux.
> >>
> >> I do not know if U-Boot wants to align with it.
> >> (up to Tom ?)
> >
> > A re-sync on the compiler headers again and making use of this sounds
> > like a good idea, yes.
> >
> 
> We should enable -Wimplicit-fallthrough like the kernel does. This
> defaults to -Wimplicit-fallthrough=3 and is happy with both the comment
> as well as with the attribute.
> 
> @Tom:
> Will you update the compiler headers within this release cycle?
> Otherwise we should take the patch as is to get us closer to the
> -Wimplicit-fallthrough target.

I'm not going to update it for this release cycle.  I've done the
initial import and build and there's some fairly large changes related
to inlining that I want to look at harder to see if we can/should do
something about (I don't want to derail this thread, I'll start
another).  But it's very far from zero size change and given the inline
changes I think it'll need real testing.

And since the kernel isn't making a huge use yet of fallthrough; we can
afford to look a little harder at things.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1 2/2] drivers: pcie: add Broadcom IPROC PCIe RC driver

[Simon Glass]

Hi Rayagonda,

On Tue, 12 May 2020 at 02:00, Rayagonda Kokatanur
 wrote:
>
> From: Srinath Mannam 
>
> Add support for IPROC PAXC PCIe RC driver.
>
> Signed-off-by: Srinath Mannam 
> Signed-off-by: Rayagonda Kokatanur 
> ---
>  drivers/pci/Kconfig  |7 +
>  drivers/pci/Makefile |1 +
>  drivers/pci/pcie_iproc.c | 1287 ++
>  3 files changed, 1295 insertions(+)
>  create mode 100644 drivers/pci/pcie_iproc.c

Reviewed-by: Simon Glass 

Changes below.

For a v1 patch you don't need to put a version. Sorry I was confused by that.

>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 437cd9a055..3b134c27a0 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -174,6 +174,13 @@ config PCIE_INTEL_FPGA
>   Say Y here if you want to enable PCIe controller support on Intel
>   FPGA, example Stratix 10.
>
> +config PCIE_IPROC
> +   bool "Iproc PCIe support"
> +   depends on DM_PCI
> +   help
> + Broadcom iProc PCIe controller driver.
> + Say Y here if you want to enable Broadcom iProc PCIe controller,

Can you add some more detail here - what features does it support?

> +
>  config PCI_MVEBU
> bool "Enable Armada XP/38x PCIe driver"
> depends on ARCH_MVEBU
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index c051ecc9f3..8d3fb169b1 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_SH4_PCI) += pci_sh4.o
>  obj-$(CONFIG_SH7751_PCI) +=pci_sh7751.o
>  obj-$(CONFIG_SH7780_PCI) +=pci_sh7780.o
>  obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
> +obj-$(CONFIG_PCIE_IPROC) += pcie_iproc.o
>  obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
>  obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
>  obj-$(CONFIG_PCIE_FSL) += pcie_fsl.o pcie_fsl_fixup.o
> diff --git a/drivers/pci/pcie_iproc.c b/drivers/pci/pcie_iproc.c
> new file mode 100644
> index 00..d77735fcf2
> --- /dev/null
> +++ b/drivers/pci/pcie_iproc.c
> @@ -0,0 +1,1287 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Broadcom
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define EP_PERST_SOURCE_SELECT_SHIFT 2
> +#define EP_PERST_SOURCE_SELECT   BIT(EP_PERST_SOURCE_SELECT_SHIFT)
> +#define EP_MODE_SURVIVE_PERST_SHIFT  1
> +#define EP_MODE_SURVIVE_PERSTBIT(EP_MODE_SURVIVE_PERST_SHIFT)
> +#define RC_PCIE_RST_OUTPUT_SHIFT 0
> +#define RC_PCIE_RST_OUTPUT   BIT(RC_PCIE_RST_OUTPUT_SHIFT)
> +
> +#define CFG_IND_ADDR_MASK0x1ffc
> +
> +#define CFG_ADDR_BUS_NUM_SHIFT   20
> +#define CFG_ADDR_BUS_NUM_MASK0x0ff0
> +#define CFG_ADDR_DEV_NUM_SHIFT   15
> +#define CFG_ADDR_DEV_NUM_MASK0x000f8000
> +#define CFG_ADDR_FUNC_NUM_SHIFT  12
> +#define CFG_ADDR_FUNC_NUM_MASK   0x7000
> +#define CFG_ADDR_REG_NUM_SHIFT   2
> +#define CFG_ADDR_REG_NUM_MASK0x0ffc
> +#define CFG_ADDR_CFG_TYPE_SHIFT  0
> +#define CFG_ADDR_CFG_TYPE_MASK   0x0003
> +
> +#define IPROC_PCI_PM_CAP 0x48
> +#define IPROC_PCI_PM_CAP_MASK0x
> +#define IPROC_PCI_EXP_CAP0xac
> +
> +#define IPROC_PCIE_REG_INVALID   0x
> +
> +#define PCI_EXP_TYPE_ROOT_PORT   0x4 /* Root Port */
> +#define PCI_EXP_RTCTL28  /* Root Control */
> +/* CRS Software Visibility capability */
> +#define PCI_EXP_RTCAP_CRSVIS 0x0001
> +
> +#define PCI_EXP_LNKSTA   18  /* Link Status */
> +#define PCI_EXP_LNKSTA_NLW   0x03f0  /* Negotiated Link Width */
> +
> +#define PCIE_PHYLINKUP_SHIFT 3
> +#define PCIE_PHYLINKUP   BIT(PCIE_PHYLINKUP_SHIFT)
> +#define PCIE_DL_ACTIVE_SHIFT 2
> +#define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
> +
> +/* derive the enum index of the outbound/inbound mapping registers */
> +#define MAP_REG(base_reg, index) ((base_reg) + (index) * 2)
> +
> +/*
> + * Maximum number of outbound mapping window sizes that can be supported by 
> any
> + * OARR/OMAP mapping pair
> + */
> +#define MAX_NUM_OB_WINDOW_SIZES  4
> +
> +#define OARR_VALID_SHIFT 0
> +#define OARR_VALID   BIT(OARR_VALID_SHIFT)
> +#define OARR_SIZE_CFG_SHIFT  1
> +
> +/*
> + * Maximum number of inbound mapping region sizes that can be supported by an
> + * IARR
> + */
> +#define MAX_NUM_IB_REGION_SIZES  9
> +
> +#define IMAP_VALID_SHIFT 0
> +#define IMAP_VALID   BIT(IMAP_VALID_SHIFT)
> +
> +#define APB_ERR_EN_SHIFT 0
> +#define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
> +
> +/**
> + * iProc PCIe host registers
> + */
> +enum iproc_pcie_reg {
> +   /* clock/reset signal control */
> +   IPROC_PCIE_CLK_CTRL = 0,
> +
> +   /*
> +* To allow MSI to be steered to an external MSI controller (e.g., ARM
> +* GICv3 

Re: [PATCH v1 2/2] drivers: pcie: add Broadcom IPROC PCIe RC driver

[Rayagonda Kokatanur]

Hi Simon,

On Wed, May 13, 2020 at 7:56 AM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Tue, 12 May 2020 at 02:00, Rayagonda Kokatanur
>  wrote:
> >
> > From: Srinath Mannam 
> >
> > Add support for IPROC PAXC PCIe RC driver.
> >
> > Signed-off-by: Srinath Mannam 
> > Signed-off-by: Rayagonda Kokatanur 
> > ---
> >  drivers/pci/Kconfig  |7 +
> >  drivers/pci/Makefile |1 +
> >  drivers/pci/pcie_iproc.c | 1287 ++
> >  3 files changed, 1295 insertions(+)
> >  create mode 100644 drivers/pci/pcie_iproc.c
>
> Are you missing a change log?
This is a v1 patch.
Sorry I didn't get why change log is required.

Regards,
Rayagonda

>
> Regards,
> Simon

Re: [PATCH v1 2/2] drivers: pcie: add Broadcom IPROC PCIe RC driver

[Simon Glass]

Hi Rayagonda,

On Tue, 12 May 2020 at 02:00, Rayagonda Kokatanur
 wrote:
>
> From: Srinath Mannam 
>
> Add support for IPROC PAXC PCIe RC driver.
>
> Signed-off-by: Srinath Mannam 
> Signed-off-by: Rayagonda Kokatanur 
> ---
>  drivers/pci/Kconfig  |7 +
>  drivers/pci/Makefile |1 +
>  drivers/pci/pcie_iproc.c | 1287 ++
>  3 files changed, 1295 insertions(+)
>  create mode 100644 drivers/pci/pcie_iproc.c

Are you missing a change log?

Regards,
Simon

Re: [PATCH v1 1/2] drivers: pci: add api to get dma regions

[Simon Glass]

Hi Rayagonda,

On Tue, 12 May 2020 at 02:00, Rayagonda Kokatanur
 wrote:
>
> Add api to get dma regions.
>
> Signed-off-by: Rayagonda Kokatanur 
> ---
>  drivers/pci/pci-uclass.c | 42 
>  include/pci.h|  3 ++-
>  2 files changed, 44 insertions(+), 1 deletion(-)
>

Please can you add a test in test/dm/pci.c

> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 7f46e901fb..f5a87f74a7 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -1176,6 +1176,48 @@ ulong pci_conv_size_to_32(ulong old, ulong value, uint 
> offset,
> return value;
>  }
>
> +int pci_get_dma_regions(struct udevice *dev, struct pci_region *memp, int 
> index)
> +{
> +   int pci_addr_cells, addr_cells, size_cells;
> +   int cells_per_record;
> +   const u32 *prop;
> +   int len;
> +   int i = 0;
> +
> +   prop = ofnode_get_property(dev_ofnode(dev), "dma-ranges", );

dev_read_prop

> +   if (!prop) {
> +   log_err("PCI: Device '%s': Cannot decode dma-ranges\n",
> +   dev->name);
> +   return -EINVAL;
> +   }
> +
> +   pci_addr_cells = ofnode_read_simple_addr_cells(dev_ofnode(dev));
> +   addr_cells = ofnode_read_simple_addr_cells(dev_ofnode(dev->parent));
> +   size_cells = ofnode_read_simple_size_cells(dev_ofnode(dev));

Use dev_... versions

> +
> +   /* PCI addresses are always 3-cells */
> +   len /= sizeof(u32);
> +   cells_per_record = pci_addr_cells + addr_cells + size_cells;
> +   debug("%s: len=%d, cells_per_record=%d\n", __func__, len,
> + cells_per_record);
> +
> +   while (len) {
> +   memp->bus_start = fdtdec_get_number(prop + 1, 2);
> +   prop += pci_addr_cells;
> +   memp->phys_start = fdtdec_get_number(prop, addr_cells);
> +   prop += addr_cells;
> +   memp->size = fdtdec_get_number(prop, size_cells);
> +   prop += size_cells;
> +

Can you look at how to share code with decode_regions()?


> +   if (i == index)
> +   return 0;
> +   i++;
> +   len -= cells_per_record;
> +   }
> +
> +   return -EINVAL;
> +}
> +
>  int pci_get_regions(struct udevice *dev, struct pci_region **iop,
> struct pci_region **memp, struct pci_region **prefp)
>  {
> diff --git a/include/pci.h b/include/pci.h
> index aff56b24f9..bcc699e257 100644
> --- a/include/pci.h
> +++ b/include/pci.h
> @@ -1297,7 +1297,8 @@ struct udevice *pci_get_controller(struct udevice *dev);
>   */
>  int pci_get_regions(struct udevice *dev, struct pci_region **iop,
> struct pci_region **memp, struct pci_region **prefp);
> -
> +int
> +pci_get_dma_regions(struct udevice *dev, struct pci_region *memp, int index);

put 'int' on the same line. Also please add a function comment.

>  /**
>   * dm_pci_write_bar32() - Write the address of a BAR
>   *
> --
> 2.17.1
>

Regards,
Simon

Re: [PPC] Internet connection on qemu-ppce500

[kosai1111]

It goes without saying, that the satellite broadband often costs more than
fixed line broadband deals and set up costs are between £100 to £400. Prices
for satellite broadband tend to vary between £20 per month to £100 per
month. Satellite broadband deals also often have restrictive download limits
and those seeking a more generous allowance will have to pay extra. These
aren't the all cons, which it has, more can be written on 
https://usave.co.uk/   .
If the Wachusett Brewing don't solve these problems, his project is doomed
to failure.



--
Sent from: http://u-boot.10912.n7.nabble.com/

Re: [PATCH v4 12/16] usb: dwc3: add make compatible for rockchip platform

[Frank Wang]

Hi Marek,

On 2020/5/12 15:26, Marek Vasut wrote:

On 5/12/20 3:08 AM, Frank Wang wrote:

Hi Marek,

On 2020/5/11 17:48, Marek Vasut wrote:

On 5/11/20 9:57 AM, Frank Wang wrote:
[...]


@@ -394,6 +407,12 @@ static int dwc3_glue_probe(struct udevice *dev)
   if (ret)
   return ret;
   +    if (glue->resets.count < 1) {

This condition is only true if count == 0 ?
What's the purpose of this test ?

For previous dts of the Linux kernel, the reset phandles were in
dwc3-glue nodes, however, they are moved recently into dwc3 that is a
child node of dwc3-glue.

So the above codes is to make compatible.

Why doesn't it check for count == 0 then ?


Will fix.


BR,
Frank

Re: U-CLASS SPI Bus and Devices

[Rudolf J Streif]

Hi Simon,

Thanks for your response.

On 5/7/20 6:36 PM, Simon Glass wrote:
> Hi Rudolf,
>
> On Wed, 18 Mar 2020 at 05:25, Rudolf J Streif  
> wrote:
>> I ran into an issue today with a U-CLASS SPI NOR flash device on a NXP
>> FlexSPI controller. U-Boot started correctly from the flash device but
>> using 'sf probe 0:0' would always return 'Invalid bus 0 (err=-19)'. This
>> error message is emitted by spi_get_bus_and_cs() in
>> drivers/spi/spi-uclass.c. I traced the issue to
>> uclass_get_device_by_seq() in drivers/core/uclass.c.
>>
>> The function first searches the device list for a device that already
>> claimed the sequence number (dev->seq). If not found it would look if a
>> device requested that sequence number (dev->seq_req). That would always
>> fail for my device. The bus had not been probed yet and hence dev->seq
>> was -1 and the device also had dev->req_seq set to -1.
>>
>> The board is using a device tree hence it would only make sense to set
>> the requested sequence number via the device tree. However, there is no
>> such thing and even if there was it might not be specified.
>>
>> Consequently, the device was never probed although the driver was
>> correctly set up via device tree.
>>
>> I worked around it by simply setting dev->req_seq of the first device
>> that had it set to -1 to the sequence number the search function was
>> looking for (see patch below). It solved my problem but I don't know if
>> that is the right way of addressing it. I could not find any other
>> solution for this particular problem anywhere.
>>
>> Rudi
> You can put the SPI flash in the device tree with an alias pointing to
> it.. That is the intended way with driver model.

The board I am using the the FSL/NXP LX2160A-RDB. The dts
arch/arm/dts/fsl-lx2160a-rdb.dts defines:

 / {
    model = "NXP Layerscape LX2160ARDB Board";
    compatible = "fsl,lx2160ardb", "fsl,lx2160a";

    aliases {
    spi0 = 
    };
};

I am I missing something?

Regards,

Rudi


>
> Regards,
> SImon
>
>
>
>>
>>
>> From 0f05ab964fcc7d29d8d467e663d7daa72328cf66 Mon Sep 17 00:00:00 2001
>> From: Rudolf J Streif 
>> Date: Tue, 17 Mar 2020 17:13:07 -0700
>> Subject: [PATCH] Fix issue with SPI device sequence number
>>
>> If the requested sequence number for a SPI device was -1 (any)
>> then the device would never be probed. This fix simply assigns
>> the sequence number asked for at probing to the device if it has
>> not been probed yet and the requested sequence number is -1.
>>
>> Signed-off-by: Rudolf J Streif 
>> ---
>>  drivers/core/uclass.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
>> index fc3157de39..e791103153 100644
>> --- a/drivers/core/uclass.c
>> +++ b/drivers/core/uclass.c
>> @@ -310,6 +310,8 @@ int uclass_find_device_by_seq(enum uclass_id id, int
>> seq_or_req_seq,
>>
>> uclass_foreach_dev(dev, uc) {
>> debug("   - %d %d '%s'\n", dev->req_seq, dev->seq,
>> dev->name);
>> +   if (find_req_seq && dev->req_seq == -1)
>> +   dev->req_seq = seq_or_req_seq;
>> if ((find_req_seq ? dev->req_seq : dev->seq) ==
>> seq_or_req_seq) {
>> *devp = dev;
>> --
>> 2.23.0
>>
>>
>>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700




signature.asc
Description: OpenPGP digital signature

Re: Antwort: Re: [PATCH v2 00/35] dm: Add programmatic generation of ACPI tables (part B)

[Simon Glass]

Hi Andy,

On Tue, 12 May 2020 at 06:32, Andy Shevchenko
 wrote:
>
> On Tue, May 12, 2020 at 01:55:49PM +0200, Wolfgang Wallner wrote:
>
> > > Since you were involved a lot in the discussion in the part A series,
> > > would you please let me know if you get some time to review this?
> >
> > Unfortunately, I don't have as much time now for review of part B as I had 
> > for
> > part A. I already started reviewing part B and I will try to continue when 
> > time
> > allows.
>
> I'm busy at the moment and I will be not available for this for few weeks.
> Code can be fixed iteratively, the most important part now is to see the big
> picture of the design and approach.
>
> Could you remind which patch in the series describes that? I will look at it
> closer and try to allocate a bit of time to do it.
>

The big picture was in part A. Part B uses the same mechanism to add
support for SSDT and DSDT generation, e.g. see [1] and [2].

Regards,
Simon

[1] 
http://patchwork.ozlabs.org/project/uboot/patch/20200510203409.203520-24-...@chromium.org/
[2] 
http://patchwork.ozlabs.org/project/uboot/patch/20200510143320.v2.32.I8b14735c2286701cc6be7d36b85bbad8ca58babd@changeid/

Re: [PATCH 1/4] clk: clk-imx8mm: Add flexspi clock and fix set parent

[Fabio Estevam]

Hi Peng,

On Sun, May 3, 2020 at 9:37 AM Peng Fan  wrote:
>
> From: Ye Li 
>
> Add flexspi relevant clocks, and fix set parent clock,  so we can

These are two different changes, which should be addressed by two
separate patches.

Thanks

Re: [PATCH 1/4] clk: clk-imx8mm: Add flexspi clock and fix set parent

[Adam Ford]

On Sun, May 3, 2020 at 7:37 AM Peng Fan  wrote:
>
> From: Ye Li 
>
> Add flexspi relevant clocks, and fix set parent clock,  so we can
> assign clocks through DTB

In one place it's called flexspi, but in two other places it's called
QSPI.   I recognize that the FlexSPI is controlling a quad-spi nor
flash chip, but isn't there an IP block on some of the i.MX SoC's
called QSPI that is different from FSPI used here?

>
> Signed-off-by: Ye Li 
> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/imx/clk-imx8mm.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index fc41a028f6..95069e7395 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -118,6 +118,9 @@ static const char *imx8mm_wdog_sels[] = {"clock-osc-24m", 
> "sys_pll1_133m", "sys_
>  static const char *imx8mm_usdhc3_sels[] = {"clock-osc-24m", "sys_pll1_400m", 
> "sys_pll1_800m", "sys_pll2_500m",
>"sys_pll3_out", "sys_pll1_266m", 
> "audio_pll2_clk", "sys_pll1_100m", };
>
> +static const char *imx8mm_qspi_sels[] = {"clock-osc-24m", "sys_pll1_400m", 
> "sys_pll2_333m", "sys_pll2_500m",
> +  "audio_pll2_out", "sys_pll1_266m", 
> "sys_pll3_out", "sys_pll1_100m", };
> +

 To reduce confusion, shouldn't the references for FSPI instead of QSPI?

>  static ulong imx8mm_clk_get_rate(struct clk *clk)
>  {
> struct clk *c;
> @@ -190,7 +193,10 @@ static int imx8mm_clk_set_parent(struct clk *clk, struct 
> clk *parent)
> if (ret)
> return ret;
>
> -   return clk_set_parent(c, cp);
> +   ret = clk_set_parent(c, cp);
> +   c->dev->parent = cp->dev;
> +
> +   return ret;
>  }
>
>  static struct clk_ops imx8mm_clk_ops = {
> @@ -369,6 +375,8 @@ static int imx8mm_clk_probe(struct udevice *dev)
> clk_dm(IMX8MM_CLK_USDHC3,
>imx8m_clk_composite("usdhc3", imx8mm_usdhc3_sels,
>base + 0xbc80));
> +   clk_dm(IMX8MM_CLK_QSPI,
> +  imx8m_clk_composite("qspi", imx8mm_qspi_sels, base + 0xab80));
>

And also here?

> clk_dm(IMX8MM_CLK_I2C1_ROOT,
>imx_clk_gate4("i2c1_root_clk", "i2c1", base + 0x4170, 0));
> @@ -392,6 +400,8 @@ static int imx8mm_clk_probe(struct udevice *dev)
>imx_clk_gate4("wdog3_root_clk", "wdog", base + 0x4550, 0));
> clk_dm(IMX8MM_CLK_USDHC3_ROOT,
>imx_clk_gate4("usdhc3_root_clk", "usdhc3", base + 0x45e0, 0));
> +   clk_dm(IMX8MM_CLK_QSPI_ROOT,
> +  imx_clk_gate4("qspi_root_clk", "qspi", base + 0x42f0, 0));
>
> /* clks not needed in SPL stage */
>  #ifndef CONFIG_SPL_BUILD
> --
> 2.16.4
>

Re: [PULL] u-boot-usb/master

[Tom Rini]

On Tue, May 12, 2020 at 08:39:16PM +0200, Marek Vasut wrote:

> The following changes since commit 2a38d2239d0bb4d128b00886bf097ab247a0b1a7:
> 
>   Prepare v2020.07-rc2 (2020-05-11 18:28:19 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 648856ac19ea528ecdc3788a638e080c33256a3c:
> 
>   usb: dwc3: Add versal compatibility string to dwc3 glue ids
> (2020-05-12 09:27:14 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] phy: sun4i-usb: Align H6 initialization logic with the kernel

[Roman Stratiienko]

H6 SOC needs additional initialization of PHY registers. Corresponding
changes can be found in the kernel patch [1].

Without this changes there is no enumeration of 'musb' gadget.

[1] - 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae409cc7c3cdb9ac4a1dba3eae70efec3d6b6c79

Fixes: 35fa673e0e5f ("sunxi: phy: Add USB PHY support for Allwinner H6")
Signed-off-by: Roman Stratiienko 
---
CC: Ondrej Jirman 
CC: Icenowy Zheng 
CC: Marek Vasut 
CC: linux-su...@googlegroups.com
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 612c428cf5..688ee7d4cc 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -279,7 +279,8 @@ static int sun4i_usb_phy_init(struct phy *phy)
return ret;
}
 
-   if (data->cfg->type == sun8i_a83t_phy) {
+   if (data->cfg->type == sun8i_a83t_phy ||
+   data->cfg->type == sun50i_h6_phy) {
if (phy->id == 0) {
val = readl(data->base + data->cfg->phyctl_offset);
val |= PHY_CTL_VBUSVLDEXT;
@@ -321,7 +322,8 @@ static int sun4i_usb_phy_exit(struct phy *phy)
int ret;
 
if (phy->id == 0) {
-   if (data->cfg->type == sun8i_a83t_phy) {
+   if (data->cfg->type == sun8i_a83t_phy ||
+   data->cfg->type == sun50i_h6_phy) {
void __iomem *phyctl = data->base +
data->cfg->phyctl_offset;
 
-- 
2.25.1

Re: [PATCH v2 09/10] pci: Add driver for Broadcom STB PCIe controller

[Jim Quinlan]

On Tue, May 12, 2020 at 12:42 PM Sylwester Nawrocki
 wrote:
>
> Hi Jim,
>
> On 08.05.2020 16:25, Jim Quinlan wrote:
>  static int brcm_pcie_probe(struct udevice *dev)
>  +{
>  +   struct udevice *ctlr = pci_get_controller(dev);
>  +   struct pci_controller *hose = dev_get_uclass_priv(ctlr);
>  +   struct brcm_pcie *pcie = dev_get_priv(dev);
>  +   void __iomem *base = pcie->base;
>  +   bool ssc_good = false;
>  +   int num_out_wins = 0;
>  +   u64 rc_bar2_offset, rc_bar2_size;
>  +   unsigned int scb_size_val;
>  +   int i, ret;
>  +   u16 nlw, cls, lnksta;
>  +   u32 tmp;
>  +
>  +   /* Reset the bridge */
>  +   brcm_pcie_bridge_sw_init_set(pcie, 1);
>  +
>  +   udelay(150);
> >>> Please add a comment as to how you chose the value, and below.
> >> This was picked from Jim Quinlan's original code submission:
> >> https://protect2.fireeye.com/url?k=9d9c41ed-c002ef77-9d9dcaa2-0cc47a336fae-205e162c16256602=1=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F9%2F19%2F642
> >>
> >> Sadly there isn't any comment there.
>
> > The bridge is being reset and then un-reset.  The delay is a safety
> > precaution to preclude the reset signal from looking like a glitch.
>
> If you don't mind I will add that sentence as a comment for the reset
> delay.
Yes, please do.  Thanks, Jim
>
> --
> Regards,
> Sylwester

Re: raspberrypi cm3 v2019.07 not working

[Belisko Marek]

On Tue, May 12, 2020 at 1:51 PM Matthias Brugger  wrote:
>
>
>
> On 12/05/2020 13:39, Matthias Brugger wrote:
> >
> >
> > On 12/05/2020 13:36, Belisko Marek wrote:
> >> On Tue, May 12, 2020 at 1:16 PM Matthias Brugger  
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 12/05/2020 13:00, Belisko Marek wrote:
>  On Tue, May 12, 2020 at 12:51 PM Matthias Brugger  
>  wrote:
> >
> >
> >
> > On 12/05/2020 11:15, Belisko Marek wrote:
> >> On Fri, May 8, 2020 at 11:39 PM Belisko Marek 
> >>  wrote:
> >>>
> >>> Hi Matthias,
> >>>
> >>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger  
> >>> wrote:
> 
>  Hi Marek,
> 
>  On 08/05/2020 21:52, Belisko Marek wrote:
> > On Wed, May 6, 2020 at 11:02 PM Belisko Marek 
> >  wrote:
> >>
> >> On Tue, May 5, 2020 at 10:18 PM Belisko Marek 
> >>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I 
> >>> got
> >>> no feedback on console. When used 2018.01 it boots fine. Probably 
> >>> I
> >>> need to do git bisect but maybe someone have some idea or 
> >>> experience
> >>> what can cause that. Thanks.
> >> I give a try 2020.01 and I got only this:
> >> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
> >>
> >> DRAM:  948 MiB
> >> RPI Compute Module 3 (0xa020a0)
> >>
> >> I'll try to debug it and let you know.
> > Debug messages shows this:
> > https://pastebin.com/2SwNzrb1
> >
> > I tried to debug but I have no clue what is going one there.
> >
> > Also u-boot 2019.07 is not working at all on cm3 due to this commit
> > (after bisect when reverted u-boot start working again):
> > 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x 
> > device
> > tree sources to Linux 5.1-rc6 state
> >
> > Any ideas hint how to resolve this issue? Thanks.
> >
> 
>  Can you try to cherry-pick the following two patches to your tree:
>  5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
>  89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
> >>> But those are present in 2020.01 and this version at least print
> >>> something to console but stuck somewhere (pls see pastebin log with
> >>> debug enabled)
> >>> I prefer to run 2020.01 ;). Thanks.
> >> Any other stuff I can try to make it working in 2020.01? Could that be
> >> firmware issue somehow? Thanks.
> >
> > Sorry I didn't realized that your first try was with 2020.01.
> > I just confirmed that it acutually does not boot. As a shortcut, do you 
> > know
> > which is the last working version of U-Boot?
>  v2019.07 with reverted  commit :
>  143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>  tree sources to Linux 5.1-rc6 state
>  work fine. Without revert it shows anything on console. So something
>  between 2019.07..2020.01 mus fix it partially ;)
> >>>
> >>> I just tired v2020.04 and it works for me. Would you mind testing that on 
> >>> your end?
> >> OK I'll give a try and try to bisect between 2020.01 and 2020.04. I
> >> have dependency on 2020.01 as I integrate mender
> >> and then use this version.
> >
> > I'm on that no need for you to do it.
> >
>
> The result for me is:
> 7099d71d87 ("common: Drop mdm_init()")
>
> which kind of makes no sense. Can you retry, I think I made a mistake 
> somewhere
> in the process.
>
> For reference here is my log:
>
> $ git bisect log
> git bisect start
> # bad: [36fec02b1f90b92cf51ec531564f9284eae27ab4] Prepare v2020.04
> git bisect bad 36fec02b1f90b92cf51ec531564f9284eae27ab4
> # good: [0b0c6af38738f2c132cfd41a240889acaa031c8f] Prepare v2020.01
> git bisect good 0b0c6af38738f2c132cfd41a240889acaa031c8f
> # good: [2f39ab1649caddf748ef1eff60c40fede5995ced] clock_imx8mq: Make
> frac_pll_init() static
> git bisect good 2f39ab1649caddf748ef1eff60c40fede5995ced
> # bad: [e6da32f243b3846e5c18183b8604b71ccb535a89] Merge tag 'ti-v2020.04-rc3' 
> of
> https://gitlab.denx.de/u-boot/custodians/u-boot-ti
> git bisect bad e6da32f243b3846e5c18183b8604b71ccb535a89
> # bad: [c95215a6ca1cc7bb53cc634159e222abc06fddff] Merge tag 'rpi-next-2020.04'
> of https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi
> git bisect bad c95215a6ca1cc7bb53cc634159e222abc06fddff
> # bad: [d7b433e40b037733f47b83b8e2f385f91035924b] env: kconfig: Restrict
> rockchip env for MMC
> git bisect bad d7b433e40b037733f47b83b8e2f385f91035924b
> # bad: [6db7943b92f7a4b5858b6a68f137462ed0293e09] i2c: designware_i2c: Rename
> 'max' speed to 'high' speed
> git bisect bad 6db7943b92f7a4b5858b6a68f137462ed0293e09
> # bad: [f32934916c65d3c26c5436b393d886fce8b9ab9f] common: Rename and move 
> source()
> git bisect bad 

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[Tom Rini]

On Tue, May 12, 2020 at 05:39:46PM +0100, André Przywara wrote:
> On 12/05/2020 16:09, Tom Rini wrote:
> 
> Hi,
> 
> > On Tue, May 12, 2020 at 03:53:55PM +0100, André Przywara wrote:
> >> On 12/05/2020 15:25, Tom Rini wrote:
> >>> On Tue, May 12, 2020 at 03:18:33PM +0100, André Przywara wrote:
>  On 09/05/2020 15:25, Amit Singh Tomar wrote:
> > This patch adds node for ethernet controller found on Action Semi OWL
> > S700 SoC.
> >
> > Since, there is no upstream Linux binding exist for S700 ethernet
> > controller, Changes are put in u-boot specific dtsi file.
> 
>  But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
>  file, since you specify the PHY mode in here (which is board specific).
> >>>
> >>> The general way to move forward here is that bindings should be getting
> >>> proposed to Linux and accepted there, and U-Boot can take a WIP of them,
> >>> that gets updated later on to match, but we shouldn't get it here first.
> >>
> >> Yes, this is of course a stop-gap measure, but a useful one: Being able
> >> to TFTP a kernel helps with developing the kernel port, especially since
> >> U-Boot doesn't support MMC (yet).
> >> And there are easier things than pushing a DT binding into the kernel
> >> tree without having a Linux driver ready ...
> > 
> > So, we're at -rc2 for v2020.07.  The DDR calculation stuff I can see
> > getting pulled in.  Is the ethernet driver for this SoC so far from done
> > that it's not ready for linux-next?  Things don't have to be in mainline
> > proper, but the expectation is that it's making reasonable progress
> > there and been reviewed so that binding changes between what we take in
> > U-Boot at first and a final re-sync once it is in mainline are minimal.
> 
> I don't think there is any particular rush in getting this actually
> merged. After all it seems like the users of this board can be counted
> on one hand.
> I think it's nice to have this on the list, so interested parties can
> pull it in if there is a need. But we can surely wait how the binding
> evolves in the kernel tree, though this might take some time.

OK, I think that'll be good enough for a while then.  I'll mark this as
RFC in patchwork so I don't forget it's not quite ready for merging
anyhow.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL u-boot] Please pull u-boot-amlogic-20200511

[Tom Rini]

On Tue, May 12, 2020 at 11:26:52AM +0200, Neil Armstrong wrote:

> Hi Tom,
> 
> This PR enables adds GPIO Open-Drain/Open-Source emulation in GPIO uclass
> and finally enables USB Host support for the Odroid-C2 board.
> 
> The CI job is at 
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/3196
> 
> Thanks,
> Neil
> 
> The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d:
> 
>   Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git 
> tags/u-boot-amlogic-20200511
> 
> for you to fetch changes up to 9bf87e256c26246fa6d8df491617e40cb7df89c2:
> 
>   test: dm: update test for open-drain/open-source emulation in gpio-uclass 
> (2020-05-11 15:12:56 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit 2a38d2239d0bb4d128b00886bf097ab247a0b1a7:

  Prepare v2020.07-rc2 (2020-05-11 18:28:19 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-usb.git master

for you to fetch changes up to 648856ac19ea528ecdc3788a638e080c33256a3c:

  usb: dwc3: Add versal compatibility string to dwc3 glue ids
(2020-05-12 09:27:14 +0200)


Jagan Teki (1):
  usb: dwc3: add dis_del_phy_power_chg_quirk

Siva Durga Prasad Paladugu (1):
  usb: dwc3: Add versal compatibility string to dwc3 glue ids

 drivers/usb/dwc3/core.c | 6 ++
 drivers/usb/dwc3/core.h | 1 +
 drivers/usb/dwc3/dwc3-generic.c | 1 +
 include/dwc3-uboot.h| 1 +
 4 files changed, 9 insertions(+)

Re: [PATCH][v4 6/6] board: tbs2910: add documentation

[Soeren Moch]

On 09.05.20 19:59, Denis 'GNUtoo' Carikli wrote:
> On Sun, 1 Mar 2020 14:59:23 +0100
> Soeren Moch  wrote:
>
>> To ease the review process it is good style to add a patch revision
>> history below the sign-off after a "---" separator. This would look
>> like ---
>> changes in v4:
>>  - bla
> I usually use that to indicate changes that do not correspond to the
> changes requested by the reviewers, or where the fix is slightly
> different from the one suggested during the review.
This usually is better addressed in a discussion before sending a new
version of a patch series. Just ignoring review comments often leads to
rejection of the new patch, this is waste of time for everybody, and
unnecessarily delays  patch merging. Of course reviewers not always have
the best idea how to solve a problem. But discussing pros and cons in a
direct answer to the review is much faster and easier as always sending
a new version of the patches.
>
> If the fix sticks to precisely what was suggested, does it still
> helps to include such changes in the ChangeLog too?
Yes , this helps for sure. Even if there is no change at all in some
patches of a series, it helps if there is a
---
changes in v4:
- none

Soeren

[RESEND PATCH v3 6/9] linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian

[Sylwester Nawrocki]

From: Nicolas Saenz Julienne 

Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
 e7d4a95da86e0 "bitfield: fix *_encode_bits()",
 37a3862e12382 "bitfield: add u8 helpers".

Signed-off-by: Nicolas Saenz Julienne 
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki 
---
Resending as I sent wrong version of [PATCH v3 6/9] by mistake.

Changes since v2:
 - added some more missing whitespaces as pointed out by checkpatch.pl.

Changes since v1:
 - added empty lines between functions and macros.

Changes since RFC:
 - new patch.
---
 include/linux/bitfield.h | 52 
 1 file changed, 52 insertions(+)

diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 8b9d6ff..7ad8b08 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -103,4 +103,56 @@
(typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
})

+extern void __compiletime_error("value doesn't fit into mask")
+__field_overflow(void);
+extern void __compiletime_error("bad bitfield mask")
+__bad_mask(void);
+
+static __always_inline u64 field_multiplier(u64 field)
+{
+   if ((field | (field - 1)) & ((field | (field - 1)) + 1))
+   __bad_mask();
+   return field & -field;
+}
+
+static __always_inline u64 field_mask(u64 field)
+{
+   return field / field_multiplier(field);
+}
+
+#define MAKE_OP(type, base, to, from)  \
+static __always_inline __##type type##_encode_bits(base v, base field) \
+{  \
+   if (__builtin_constant_p(v) && (v & ~field_mask(field)))\
+   __field_overflow(); \
+   return to((v & field_mask(field)) * field_multiplier(field));   \
+}  \
+static __always_inline __##type type##_replace_bits(__##type old,  \
+   base val, base field)   \
+{  \
+   return (old & ~to(field)) | type##_encode_bits(val, field); \
+}  \
+static __always_inline void type##p_replace_bits(__##type * p, \
+   base val, base field)   \
+{  \
+   *p = (*p & ~to(field)) | type##_encode_bits(val, field);\
+}  \
+static __always_inline base type##_get_bits(__##type v, base field)\
+{  \
+   return (from(v) & field) / field_multiplier(field); \
+}
+
+#define __MAKE_OP(size)
\
+   MAKE_OP(le##size, u##size, cpu_to_le##size, le##size##_to_cpu) \
+   MAKE_OP(be##size, u##size, cpu_to_be##size, be##size##_to_cpu) \
+   MAKE_OP(u##size, u##size, ,)
+
+MAKE_OP(u8, u8, ,)
+__MAKE_OP(16)
+__MAKE_OP(32)
+__MAKE_OP(64)
+
+#undef __MAKE_OP
+#undef MAKE_OP
+
 #endif
--
2.7.4

[PATCH v3 8/9] pci: Add driver for Broadcom BCM2711 SoC PCIe controller

[Sylwester Nawrocki]

This patch adds basic driver PCI Express controller found on Broadcom
set-top-box SoCs, e.g. BCM2711.
The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
handling removed. The inbound access memory region is not currently
parsed from dma-ranges DT property and a fixed 3GB region is used.

The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
USB Host Controller.

Signed-off-by: Nicolas Saenz Julienne 
Signed-off-by: Sylwester Nawrocki 
---
Changes since v2:
 - removed MDO_RD_DONE, MDIO_WT_DONE macro definitions,
 - updated the Kconfig entry help text,
 - reordered #include entries to match the coding style,
 - s/udev/dev,
 - s/ENODEV/EINVAL in brcm_pcie_probe() and brcm_pcie_config_address()
   functions,
 - Simplified brcm_pcie_mdio_{read, write} functions (readl_poll_timeout),
 - shortened register bit fields macro definitions,
 - dropped brcm_pcie_perst_set() and brcm_pcie_bridge_sw_init_set()
   function in favour of direct clrbits_le32/setbits_le32 calls,
 - use setbits_le32/clrbits_le32/clrsetbits_le32 instead of
   readl(), u32p_replace_bits(), writel() sequence
 - simplified brcm_pcie_config_address(), brcm_pcie_set_gen() functions,
 - changed reset pulse delay to 100 us,
 - Replaced FIELD_GET() with open coded bitwise operations,
 - brcm_cpie_cfg_index() function merged into brcm_pcie_config_address(),
 - use standard PCI PCI_EXP_LNKSTA_CLS_* link speed defines
 - added kernel-doc function comments.

Changes since v1:
 - fixed argument in brcm_pcie_set_ssc() function call,
 - changed rc_bar2_size assignment to value 0xC000, as in upstream
   devicetree.
Changes since RFC:
 - reworked to align with current Linux mainline version and u-boot
   driver by Nicolas Saenz Julienne.
---
 drivers/pci/Kconfig|   9 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pcie_brcmstb.c | 623 +
 3 files changed, 633 insertions(+)
 create mode 100644 drivers/pci/pcie_brcmstb.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 437cd9a..543bd46 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -197,4 +197,13 @@ config PCIE_MEDIATEK
  Say Y here if you want to enable Gen2 PCIe controller,
  which could be found on MT7623 SoC family.
 
+config PCI_BRCMSTB
+   bool "Broadcom STB PCIe controller"
+   depends on DM_PCI
+   depends on ARCH_BCM283X
+   help
+ Say Y here if you want to enable support for PCIe controller
+ on Broadcom set-top-box (STB) SoCs.
+ This driver currently supports only BCM2711 SoC and RC mode
+ of the controller.
 endif
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index c051ecc..3e53b1f 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -43,3 +43,4 @@ obj-$(CONFIG_PCI_PHYTIUM) += pcie_phytium.o
 obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o
 obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o
 obj-$(CONFIG_PCIE_MEDIATEK) += pcie_mediatek.o
+obj-$(CONFIG_PCI_BRCMSTB) += pcie_brcmstb.o
diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c
new file mode 100644
index 000..dade79e
--- /dev/null
+++ b/drivers/pci/pcie_brcmstb.c
@@ -0,0 +1,623 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Broadcom STB PCIe controller driver
+ *
+ * Copyright (C) 2020 Samsung Electronics Co., Ltd.
+ *
+ * Based on upstream Linux kernel driver:
+ * drivers/pci/controller/pcie-brcmstb.c
+ * Copyright (C) 2009 - 2017 Broadcom
+ *
+ * Based driver by Nicolas Saenz Julienne
+ * Copyright (C) 2020 Nicolas Saenz Julienne 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Offset of the mandatory PCIe capability config registers */
+#define BRCM_PCIE_CAP_REGS 0x00ac
+
+/* The PCIe controller register offsets */
+#define PCIE_RC_CFG_VENDOR_SPECIFIC_REG1   0x0188
+#define  VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK0xc
+#define  VENDOR_SPECIFIC_REG1_LITTLE_ENDIAN0x0
+
+#define PCIE_RC_CFG_PRIV1_ID_VAL3  0x043c
+#define  CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xff
+
+#define PCIE_RC_DL_MDIO_ADDR   0x1100
+#define PCIE_RC_DL_MDIO_WR_DATA0x1104
+#define PCIE_RC_DL_MDIO_RD_DATA0x1108
+
+#define PCIE_MISC_MISC_CTRL0x4008
+#define  MISC_CTRL_SCB_ACCESS_EN_MASK  0x1000
+#define  MISC_CTRL_CFG_READ_UR_MODE_MASK   0x2000
+#define  MISC_CTRL_MAX_BURST_SIZE_MASK 0x30
+#define  MISC_CTRL_MAX_BURST_SIZE_128  0x0
+#define  MISC_CTRL_SCB0_SIZE_MASK  0xf800
+
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO   0x400c
+#define PCIE_MEM_WIN0_LO(win)  \
+   PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + ((win) * 4)
+
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI   0x4010
+#define 

[PATCH v3 9/9] configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit)

[Sylwester Nawrocki]

This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Sylwester Nawrocki 
---
Changes since v2:
 - rpi_4_32b_defconfig, rpi_4_defconfig changes moved to separate
   patch
Changes since v1:
 - removed unneeded CONFIG_XHCI_64BIT_DWORD_ACCESS_ONLY entry.

Changes since RFC:
 - none.
---
 configs/rpi_arm64_defconfig | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index fea86be..f12d1e3 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -7,13 +7,14 @@ CONFIG_NR_DRAM_BANKS=2
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_PREBOOT=y
-CONFIG_PREBOOT="usb start"
+CONFIG_PREBOOT="pci enum; usb start;"
 CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_FS_UUID=y
 CONFIG_OF_BOARD=y
@@ -26,11 +27,16 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_BCM2835=y
 CONFIG_DM_ETH=y
 CONFIG_BCMGENET=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_PCI_BRCMSTB=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
 CONFIG_USB=y
 CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PCI=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
-- 
2.7.4

[PATCH v3 7/9] pci: Add some PCI Express capability register offset definitions

[Sylwester Nawrocki]

Add PCI Express capability definitions required by the Broadcom
STB PCIe controller driver.

Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Bin Meng 
Reviewed-by: Nicolas Saenz Julienne 
---
Changes since v2:
 - added Current Link Speed defines.
Changes since v1:
 - none.
Changes since RFC:
 - ensure the entries are added in order, sorted by ascending
   address values.
---
 include/pci.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/pci.h b/include/pci.h
index dfdbb32..ff5f620 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -479,11 +479,20 @@
 #define PCI_EXP_DEVCTL 8   /* Device Control */
 #define  PCI_EXP_DEVCTL_BCR_FLR0x8000  /* Bridge Configuration Retry / 
FLR */
 #define PCI_EXP_LNKCAP 12  /* Link Capabilities */
+#define  PCI_EXP_LNKCAP_SLS0x000f /* Supported Link Speeds */
+#define  PCI_EXP_LNKCAP_MLW0x03f0 /* Maximum Link Width */
 #define  PCI_EXP_LNKCAP_DLLLARC0x0010 /* Data Link Layer Link 
Active Reporting Capable */
 #define PCI_EXP_LNKSTA 18  /* Link Status */
+#define  PCI_EXP_LNKSTA_CLS0x000f  /* Current Link Speed */
+#define  PCI_EXP_LNKSTA_CLS_2_5GB 0x0001 /* Current Link Speed 2.5GT/s */
+#define  PCI_EXP_LNKSTA_CLS_5_0GB 0x0002 /* Current Link Speed 5.0GT/s */
+#define  PCI_EXP_LNKSTA_CLS_8_0GB 0x0003 /* Current Link Speed 8.0GT/s */
+#define  PCI_EXP_LNKSTA_NLW0x03f0  /* Negotiated Link Width */
+#define  PCI_EXP_LNKSTA_NLW_SHIFT 4/* start of NLW mask in link status */
 #define  PCI_EXP_LNKSTA_DLLLA  0x2000  /* Data Link Layer Link Active */
 #define PCI_EXP_SLTCAP 20  /* Slot Capabilities */
 #define  PCI_EXP_SLTCAP_PSN0xfff8 /* Physical Slot Number */
+#define PCI_EXP_LNKCTL248  /* Link Control 2 */
 
 /* Include the ID list */
 
-- 
2.7.4

[PATCH v3 5/9] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)

[Sylwester Nawrocki]

From: Marek Szyprowski 

Create a non-cacheable mapping for the 0x6 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Nicolas Saenz Julienne 
---
Changes since v2:
 -  fixed typo MAX_MAP_MAX_ENTRIES -> MEM_MAP_MAX_ENTRIES
Changes since v1:
 - none.
---
 arch/arm/mach-bcm283x/init.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 4295356..9f5bca3 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -11,10 +11,15 @@
 #include 
 #include 
 
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS   0x6UL
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE   0x80UL
+
 #ifdef CONFIG_ARM64
 #include 
 
-static struct mm_region bcm283x_mem_map[] = {
+#define MEM_MAP_MAX_ENTRIES (4)
+
+static struct mm_region bcm283x_mem_map[MEM_MAP_MAX_ENTRIES] = {
{
.virt = 0xUL,
.phys = 0xUL,
@@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
}
 };
 
-static struct mm_region bcm2711_mem_map[] = {
+static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
{
.virt = 0xUL,
.phys = 0xUL,
@@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
+   .virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+   .phys = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+   .size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
/* List terminator */
0,
}
@@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
 {
int i;
 
-   for (i = 0; i < 2; i++) {
+   for (i = 0; i < MEM_MAP_MAX_ENTRIES; i++) {
mem_map[i].virt = pd[i].virt;
mem_map[i].phys = pd[i].phys;
mem_map[i].size = pd[i].size;
-- 
2.7.4

[PATCH v3 3/9] pci: Move some PCIe register offset definitions to a common header

[Sylwester Nawrocki]

Some PCI Express register offsets are currently defined in multiple
drivers, move them to a common header to avoid re-definitions and
as a pre-requisite for adding new PCIe driver.
While at it replace some spaces with tabs.

Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Bin Meng 
Reviewed-by: Nicolas Saenz Julienne 
---
Changes since v1:
 - none.
Changes since RFC:
 - whitespace clean up.
---
 drivers/pci/pci-rcar-gen3.c   |  8 
 drivers/pci/pcie_intel_fpga.c |  3 ---
 include/pci.h | 13 +++--
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/pci-rcar-gen3.c b/drivers/pci/pci-rcar-gen3.c
index 30eff67..393f1c9 100644
--- a/drivers/pci/pci-rcar-gen3.c
+++ b/drivers/pci/pci-rcar-gen3.c
@@ -117,14 +117,6 @@
 #define RCAR_PCI_MAX_RESOURCES 4
 #define MAX_NR_INBOUND_MAPS6
 
-#define PCI_EXP_FLAGS  2   /* Capabilities register */
-#define PCI_EXP_FLAGS_TYPE 0x00f0  /* Device/Port type */
-#define PCI_EXP_TYPE_ROOT_PORT 0x4 /* Root Port */
-#define PCI_EXP_LNKCAP 12  /* Link Capabilities */
-#define PCI_EXP_LNKCAP_DLLLARC 0x0010  /* Data Link Layer Link Active 
Reporting Capable */
-#define PCI_EXP_SLTCAP 20  /* Slot Capabilities */
-#define PCI_EXP_SLTCAP_PSN 0xfff8  /* Physical Slot Number */
-
 enum {
RCAR_PCI_ACCESS_READ,
RCAR_PCI_ACCESS_WRITE,
diff --git a/drivers/pci/pcie_intel_fpga.c b/drivers/pci/pcie_intel_fpga.c
index 6a9f29c..69363a0 100644
--- a/drivers/pci/pcie_intel_fpga.c
+++ b/drivers/pci/pcie_intel_fpga.c
@@ -65,9 +65,6 @@
 #define IS_ROOT_PORT(pcie, bdf)\
((PCI_BUS(bdf) == pcie->first_busno) ? true : false)
 
-#define PCI_EXP_LNKSTA 18  /* Link Status */
-#define PCI_EXP_LNKSTA_DLLLA   0x2000  /* Data Link Layer Link Active */
-
 /**
  * struct intel_fpga_pcie - Intel FPGA PCIe controller state
  * @bus: Pointer to the PCI bus
diff --git a/include/pci.h b/include/pci.h
index aff56b2..dfdbb32 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -471,10 +471,19 @@
 #define  PCI_EA_FIELD_MASK 0xfffc  /* For Base & Max Offset */
 
 /* PCI Express capabilities */
+#define PCI_EXP_FLAGS  2   /* Capabilities register */
+#define  PCI_EXP_FLAGS_TYPE0x00f0  /* Device/Port type */
+#define  PCI_EXP_TYPE_ROOT_PORT 0x4/* Root Port */
 #define PCI_EXP_DEVCAP 4   /* Device capabilities */
-#define  PCI_EXP_DEVCAP_FLR 0x1000 /* Function Level Reset */
+#define  PCI_EXP_DEVCAP_FLR0x1000 /* Function Level Reset */
 #define PCI_EXP_DEVCTL 8   /* Device Control */
-#define  PCI_EXP_DEVCTL_BCR_FLR 0x8000  /* Bridge Configuration Retry / FLR */
+#define  PCI_EXP_DEVCTL_BCR_FLR0x8000  /* Bridge Configuration Retry / 
FLR */
+#define PCI_EXP_LNKCAP 12  /* Link Capabilities */
+#define  PCI_EXP_LNKCAP_DLLLARC0x0010 /* Data Link Layer Link 
Active Reporting Capable */
+#define PCI_EXP_LNKSTA 18  /* Link Status */
+#define  PCI_EXP_LNKSTA_DLLLA  0x2000  /* Data Link Layer Link Active */
+#define PCI_EXP_SLTCAP 20  /* Slot Capabilities */
+#define  PCI_EXP_SLTCAP_PSN0xfff8 /* Physical Slot Number */
 
 /* Include the ID list */
 
-- 
2.7.4

[PATCH v3 6/9] linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian

[Sylwester Nawrocki]

From: Nicolas Saenz Julienne 

Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
 e7d4a95da86e0 "bitfield: fix *_encode_bits()",
 37a3862e12382 "bitfield: add u8 helpers".

Signed-off-by: Nicolas Saenz Julienne 
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki 
---
Changes since v1:
 - added empty lines between functions and macros.

Changes since RFC:
 - new patch.
---
 include/linux/bitfield.h | 50 
 1 file changed, 50 insertions(+)

diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 8b9d6ff..7acba4c 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -103,4 +103,54 @@
(typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
})
 
+extern void __compiletime_error("value doesn't fit into mask")
+__field_overflow(void);
+extern void __compiletime_error("bad bitfield mask")
+__bad_mask(void);
+static __always_inline u64 field_multiplier(u64 field)
+{
+   if ((field | (field - 1)) & ((field | (field - 1)) + 1))
+   __bad_mask();
+   return field & -field;
+}
+static __always_inline u64 field_mask(u64 field)
+{
+   return field / field_multiplier(field);
+}
+
+#define MAKE_OP(type,base,to,from) \
+static __always_inline __##type type##_encode_bits(base v, base field) \
+{  \
+   if (__builtin_constant_p(v) && (v & ~field_mask(field)))\
+   __field_overflow(); \
+   return to((v & field_mask(field)) * field_multiplier(field));   \
+}  \
+static __always_inline __##type type##_replace_bits(__##type old,  \
+   base val, base field)   \
+{  \
+   return (old & ~to(field)) | type##_encode_bits(val, field); \
+}  \
+static __always_inline void type##p_replace_bits(__##type *p,  \
+   base val, base field)   \
+{  \
+   *p = (*p & ~to(field)) | type##_encode_bits(val, field);\
+}  \
+static __always_inline base type##_get_bits(__##type v, base field)\
+{  \
+   return (from(v) & field)/field_multiplier(field);   \
+}
+
+#define __MAKE_OP(size)
\
+   MAKE_OP(le##size,u##size,cpu_to_le##size,le##size##_to_cpu) \
+   MAKE_OP(be##size,u##size,cpu_to_be##size,be##size##_to_cpu) \
+   MAKE_OP(u##size,u##size,,)
+
+MAKE_OP(u8,u8,,)
+__MAKE_OP(16)
+__MAKE_OP(32)
+__MAKE_OP(64)
+
+#undef __MAKE_OP
+#undef MAKE_OP
+
 #endif
-- 
2.7.4

[PATCH v3 4/9] rpi4: shorten a mapping for the DRAM

[Sylwester Nawrocki]

From: Marek Szyprowski 

Remove the overlap between DRAM and device's IO area.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Nicolas Saenz Julienne 
---
Changes since v1:
 - none.
---
 arch/arm/mach-bcm283x/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 9966d6c..4295356 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -38,7 +38,7 @@ static struct mm_region bcm2711_mem_map[] = {
{
.virt = 0xUL,
.phys = 0xUL,
-   .size = 0xfe00UL,
+   .size = 0xfc00UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-- 
2.7.4

[PATCH v3 1/9] usb: xhci: Add missing cache flush in the scratchpad array initialization

[Sylwester Nawrocki]

In current code there is no cache flush after initializing the scratchpad
buffer array with the scratchpad buffer pointers. This leads to a failure
of the "slot enable" command on the rpi4 board (Broadcom STB PCIe
controller + VL805 USB hub) - the very first TRB transfer on the command
ring fails and there is a timeout while waiting for the command completion
event. After adding the missing cache flush everything seems to be working
as expected.

Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Bin Meng 
Reviewed-by: Nicolas Saenz Julienne 
---
Changes since v1:
 - none.
---
 drivers/usb/host/xhci-mem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 93450ee..729bdc3 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -393,6 +393,9 @@ static int xhci_scratchpad_alloc(struct xhci_ctrl *ctrl)
scratchpad->sp_array[i] = cpu_to_le64(ptr);
}
 
+   xhci_flush_cache((uintptr_t)scratchpad->sp_array,
+sizeof(u64) * num_sp);
+
return 0;
 
 fail_sp3:
-- 
2.7.4

[PATCH v3 0/9] USB host support for Raspberry Pi 4 board (64-bit)

[Sylwester Nawrocki]

Hi all,

This patch series adds USB host support for Raspberry Pi 4 board. 
It includes the Broadcom STB PCIe controller driver ported from Linux 
kernel, a memory mapping update for the xHCI controller on PCIe bus
for 64-bit builds and some related fixes and updates in the usb/xhci 
and the pci driver core code.

The 32-bit ARM part has be excluded from the series and will be posted
separately.

This iteration includes mostly correction in the PCIe controller driver
patch addressing Simon's review comments. Hopefully I have addressed 
all comments. I didn't decide to use struct for the control registers
as the registers offsets used are sparse and I don't have detailed 
documentation of the hardware to be able to define the struct accurately.

The patch series is based on v2020.07-rc1 tree.

Thanks,
Sylwester

Marek Szyprowski (2):
  rpi4: shorten a mapping for the DRAM
  rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM
64bit)

Nicolas Saenz Julienne (1):
  linux/bitfield.h: Add primitives for manipulating bitfields both in
host- and fixed-endian

Sylwester Nawrocki (6):
  usb: xhci: Add missing cache flush in the scratchpad array
initialization
  usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq
  pci: Move some PCIe register offset definitions to a common header
  pci: Add some PCI Express capability register offset definitions
  pci: Add driver for Broadcom BCM2711 SoC PCIe controller
  configs: Enable support for the XHCI controller on RPI4 board (ARM
64-bit)

 arch/arm/mach-bcm283x/init.c  |  20 +-
 configs/rpi_arm64_defconfig   |   8 +-
 drivers/pci/Kconfig   |   9 +
 drivers/pci/Makefile  |   1 +
 drivers/pci/pci-rcar-gen3.c   |   8 -
 drivers/pci/pcie_brcmstb.c| 623 ++
 drivers/pci/pcie_intel_fpga.c |   3 -
 drivers/usb/host/xhci-mem.c   |   3 +
 include/linux/bitfield.h  |  50 
 include/pci.h |  22 +-
 include/usb/xhci.h|   8 -
 11 files changed, 729 insertions(+), 26 deletions(-)
 create mode 100644 drivers/pci/pcie_brcmstb.c

-- 
2.7.4

[PATCH v3 2/9] usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq

[Sylwester Nawrocki]

There might be hardware configurations where 64-bit data accesses
to XHCI registers are not supported properly.  This patch removes
the readq/writeq so always two 32-bit accesses are used to read/write
64-bit XHCI registers, similarly as it is done in Linux kernel.

This patch fixes operation of the XHCI controller on RPI4 Broadcom
BCM2711 SoC based board, where the VL805 USB XHCI controller is
connected to the PCIe Root Complex, which is attached to the system
through the SCB bridge.

Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely
the 64-bit wide register accesses initiated by the CPU are not properly
translated to a sequence of 32-bit PCIe accesses.
xhci_readq(), for example, always returns same value in upper and lower
32-bits, e.g. 0xabcd1234abcd1234 instead of 0xabcd1234.

Cc: Sergey Temerkhanov 
Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Bin Meng 
Reviewed-by: Nicolas Saenz Julienne 
---
Changes since v1:
 - none.
Changes since RFC:
 - dropped Kconfig option, switched to not using readq/writeq
   unconditionally.
---
 include/usb/xhci.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 6017504..c16106a 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -,28 +,20 @@ static inline void xhci_writel(uint32_t volatile *regs, 
const unsigned int val)
  */
 static inline u64 xhci_readq(__le64 volatile *regs)
 {
-#if BITS_PER_LONG == 64
-   return readq(regs);
-#else
__u32 *ptr = (__u32 *)regs;
u64 val_lo = readl(ptr);
u64 val_hi = readl(ptr + 1);
return val_lo + (val_hi << 32);
-#endif
 }
 
 static inline void xhci_writeq(__le64 volatile *regs, const u64 val)
 {
-#if BITS_PER_LONG == 64
-   writeq(val, regs);
-#else
__u32 *ptr = (__u32 *)regs;
u32 val_lo = lower_32_bits(val);
/* FIXME */
u32 val_hi = upper_32_bits(val);
writel(val_lo, ptr);
writel(val_hi, ptr + 1);
-#endif
 }
 
 int xhci_hcd_init(int index, struct xhci_hccr **ret_hccr,
-- 
2.7.4

Re: [PATCH v3 00/17] mtd: spi-nor-core: add xSPI Octal DTR support

[Pratyush Yadav]

On 12/05/20 10:13PM, Jagan Teki wrote:
> On Mon, Mar 30, 2020 at 9:15 PM Pratyush Yadav  wrote:
> >
> > Hi,
> >
> > This series adds support for octal DTR flashes in the spi-nor framework,
> > and then adds hooks for the Cypress Semper flash which is an xSPI
> > compliant Octal DTR flash.
> >
> > The Cadence QSPI controller driver is also updated to run in Octal DTR
> > mode.
> >
> > Tested on TI J721e EVM with 1-bit ECC on the Cypress flash on top of
> > u-boot-ti/next.
> >
> > This series depends on [0].
> >
> > [0] cf. <20200224071051.19331-1-p.ya...@ti.com>
> > [0] https://lists.denx.de/pipermail/u-boot/2020-February/401192.html
> >
> > Changes in v3:
> > - Read 2 bytes in Octal DTR mode when reading SR and FSR to avoid
> >   tripping up controllers.
> > - Use op->data.nbytes as a measure of whether the data phase exists or
> >   not. This fixes data buswidth not being updadted for SR and FSR reads
> >   because they keep data buffer as NULL when calling spi_nor_setup_op().
> > - Add support for Micron mt35xu512aba to run in Octal DTR mode.
> 
> Do you have foot-print statistics for these changes? if yes can mark it here.

Do you mean binary size difference?

With these changes, the U-Boot binary is 830308 bytes. Without them it 
is 825260 bytes. That is a 5048 byte increase.

With these changes, the SPL binary weighs in at 605312 bytes. Without 
them it is 600488 bytes. That is a 4824 byte increase.

This is with both the Spansion and STMicro configs enabled. When I 
disable them I get the follwing data.

U-Boot:
With: 822644
Without: 819688
Difference: 2956

SPL:
With: 599218
Without: 596192
Difference: 3026
 

-- 
Regards,
Pratyush Yadav
Texas Instruments India

Re: [PATCH v1 1/2] driver: spi: add brcm iproc qspi support.

[Jagan Teki]

On Mon, May 4, 2020 at 12:27 PM Rayagonda Kokatanur
 wrote:
>
> Add brcm iproc qspi support.
>
> Signed-off-by: Rayagonda Kokatanur 
> ---
>  drivers/spi/Kconfig  |  14 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/iproc_qspi.c | 852 +++
>  drivers/spi/iproc_qspi.h |  18 +
>  drivers/spi/iproc_spi.c  |  71 
>  5 files changed, 956 insertions(+)
>  create mode 100644 drivers/spi/iproc_qspi.c
>  create mode 100644 drivers/spi/iproc_qspi.h
>  create mode 100644 drivers/spi/iproc_spi.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 4166c6104e..6333536468 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -148,6 +148,20 @@ config ICH_SPI
>   access the SPI NOR flash on platforms embedding this Intel
>   ICH IP core.
>
> +config IPROC_QSPI
> +   bool "QSPI driver for BCM iProc QSPI Controller"
> +   select IPROC_SPI
> +   help
> + This selects the BCM iProc QSPI controller.
> + This driver support spi flash single, quad and memory reads.
> +
> +config BCM_IPROC_USE_BSPI
> +   bool "Broadcom BSPI driver for fast read"
> +   depends on IPROC_QSPI
> +   help
> + This selects the BCM BSPI driver for fast read mode.
> + Enable this mode if flash(nand/nor) supports.
> +
>  config MESON_SPIFC
> bool "Amlogic Meson SPI Flash Controller driver"
> depends on ARCH_MESON
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 52462e19a3..359f6a87cb 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
>  obj-$(CONFIG_FSL_ESPI) += fsl_espi.o
>  obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
>  obj-$(CONFIG_ICH_SPI) +=  ich.o
> +obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o
>  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>  obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
>  obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
> diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c
> new file mode 100644
> index 00..e28b063f82
> --- /dev/null
> +++ b/drivers/spi/iproc_qspi.c
> @@ -0,0 +1,852 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 Broadcom
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "iproc_qspi.h"
> +
> +#define QSPI_AXI_CLK17500 /* 175MHz */
> +
> +/* default SCK frequency, unit: HZ */
> +#define QSPI_DEF_SCK_FREQ   5000
> +
> +#define QSPI_WAIT_TIMEOUT_MS200U /* msec */
> +
> +/* Chip attributes */
> +#define SPBR_MIN8U
> +#define SPBR_MAX255U
> +#define NUM_CDRAM   16U
> +
> +#define CDRAM_PCS0  2
> +#define CDRAM_CONT  BIT(7)
> +#define CDRAM_BITS_EN   BIT(6)
> +#define CDRAM_QUAD_MODE BIT(8)
> +#define CDRAM_RBIT_INPUTBIT(10)
> +
> +#define MSPI_SPEBIT(6)
> +#define MSPI_CONT_AFTER_CMD BIT(7)
> +
> +/*
> + * Register fields
> + */
> +#define MSPI_SPCR0_MSB_BITS_8   0x0020
> +#define BSPI_RAF_CONTROL_START_MASK 0x0001
> +#define BSPI_RAF_STATUS_SESSION_BUSY_MASK   0x0001
> +#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK 0x0002
> +#define BSPI_BITS_PER_PHASE_ADDR_MARK   0x0001
> +#define BSPI_BITS_PER_CYCLE_DATA_SHIFT  0
> +#define BSPI_BITS_PER_CYCLE_ADDR_SHIFT  16
> +#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT 3
> +#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT 1
> +#define BSPI_STRAP_OVERRIDE_SHIFT   0
> +
> +/*
> + * Flash opcode and parameters
> + */
> +#define OPCODE_RDSR 0x05
> +#define OPCODE_FAST_READ0x0B
> +#define OPCODE_DUAL_READ0x3b
> +#define OPCODE_QUAD_READ0x6b
> +#define OPCODE_EN4B 0xB7
> +#define OPCODE_EX4B 0xE9
> +#define OPCODE_BRWR 0x17

Flash opcode cannot be in the spi bus driver. I have already commented
similar stuff in previous version [1]


> +
> +/* MSPI registers */
> +#define MSPI_SPCR0_LSB_REG 0x000
> +#define MSPI_SPCR0_MSB_REG 0x004
> +#define MSPI_SPCR1_LSB_REG 0x008
> +#define MSPI_SPCR1_MSB_REG 0x00c
> +#define MSPI_NEWQP_REG 0x010
> +#define MSPI_ENDQP_REG 0x014
> +#define MSPI_SPCR2_REG 0x018
> +#define MSPI_STATUS_REG0x020
> +#define MSPI_CPTQP_REG 0x024
> +#define MSPI_TXRAM_REG 0x040
> +#define MSPI_RXRAM_REG 0x0c0
> +#define MSPI_CDRAM_REG 0x140
> +#define 

[PATCH 2/2] [RFC] clk: stm32mp1: Handle SoC speed grade configs

[Marek Vasut]

There are two speed grades of the STM32MP1, the A/C and D/F, the
former can run up to 650 MHz, the later at up to 800 MHz. Allow
specifying PLL config for both in the DT, so that it is possible
to cater for boards which can be populated with either SoC.

Signed-off-by: Marek Vasut 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
---
 drivers/clk/clk_stm32mp1.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
index 50df8425bf..cecc06638e 100644
--- a/drivers/clk/clk_stm32mp1.c
+++ b/drivers/clk/clk_stm32mp1.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1464,6 +1465,12 @@ static void pll_csg(struct stm32mp1_clk_priv *priv, int 
pll_id, u32 *csg)
setbits_le32(priv->base + pll[pll_id].pllxcr, RCC_PLLNCR_SSCG_CTRL);
 }
 
+static __maybe_unused int stm32mp1_is_df(void)
+{
+   /* ID bit 7 is set on 15x{D,F}xx and not on 15x{A,C}xx */
+   return get_cpu_type() & BIT(7);
+}
+
 static  __maybe_unused int pll_set_rate(struct udevice *dev,
int pll_id,
int div_id,
@@ -1491,8 +1498,13 @@ static  __maybe_unused int pll_set_rate(struct udevice 
*dev,
 
ret = ofnode_read_u32_array(plloff, "cfg",
pllcfg, PLLCFG_NB);
-   if (ret < 0)
-   return -FDT_ERR_NOTFOUND;
+   if (ret < 0) {
+   ret = ofnode_read_u32_array(plloff,
+   stm32mp1_is_df() ? "cfg-df" : "cfg-ac",
+   pllcfg, PLLCFG_NB);
+   if (ret < 0)
+   return -FDT_ERR_NOTFOUND;
+   }
 
fck_ref = pll_get_fref_ck(priv, pll_id);
 
@@ -1687,8 +1699,13 @@ static int stm32mp1_clktree(struct udevice *dev)
ret = ofnode_read_u32_array(plloff[i], "cfg",
pllcfg[i], PLLCFG_NB);
if (ret < 0) {
-   debug("field cfg invalid: error %d\n", ret);
-   return -FDT_ERR_NOTFOUND;
+   ret = ofnode_read_u32_array(plloff[i],
+   stm32mp1_is_df() ? "cfg-df" : "cfg-ac",
+   pllcfg[i], PLLCFG_NB);
+   if (ret < 0) {
+   debug("field cfg invalid: error %d\n", ret);
+   return -FDT_ERR_NOTFOUND;
+   }
}
}
 
@@ -1783,6 +1800,11 @@ static int stm32mp1_clktree(struct udevice *dev)
continue;
 
fracv = ofnode_read_u32_default(plloff[i], "frac", 0);
+   if (!fracv) {
+   fracv = ofnode_read_u32_default(plloff[i],
+   stm32mp1_is_df() ? "frac-df" : 
"frac-ac",
+   0);
+   }
pll_config(priv, i, pllcfg[i], fracv);
ret = ofnode_read_u32_array(plloff[i], "csg", csg, PLLCSG_NB);
if (!ret) {
-- 
2.25.1

[PATCH 1/2] [RFC] ARM: stm32: Make bsec available in SPL

[Marek Vasut]

Make the bsec driver available both in SPL and in U-Boot proper
to make it possible to read out the SoC type (A/C/D/F) and thus
to determine the MPU PLL configuration (650/800 MHz).

Signed-off-by: Marek Vasut 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
---
 arch/arm/mach-stm32mp/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index eee39c27c3..42c0206249 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -3,6 +3,7 @@
 # Copyright (C) 2018, STMicroelectronics - All Rights Reserved
 #
 
+obj-y += bsec.o
 obj-y += cpu.o
 obj-y += dram_init.o
 obj-y += syscon.o
@@ -10,7 +11,6 @@ obj-y += syscon.o
 ifdef CONFIG_SPL_BUILD
 obj-y += spl.o
 else
-obj-y += bsec.o
 obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
 obj-$(CONFIG_ARMV7_PSCI) += psci.o
 endif
-- 
2.25.1

Re: [PATCH 1/1] imx: rom api: fix image offset computation

[Patrick Wildt]

On Tue, May 12, 2020 at 03:09:54PM +0200, S??bastien Szymanski wrote:
> According to the table 6-25 "Primary image offset and IVT offset
> details", in the IMX8MNRM, the ROM expects the following image offset:
> 
> SD: 32KB
> eMMC: 0 if image is in boot partion and 32KB if it is on user partition
> NAND: 0
> FlexSPI: 4KB
> SPI: 0
> 
> On eMMC, it is more likely that U-Boot is on the boot partion, so rework
> the offset computation by handling the two specific cases (SD and
> FlexSPI).

Likely, but not really.  I have a product where it's on the eMMC but not
in a boot partition.  If this gets committed, should I sent a diff to
revert it? :-)  I'm not (yet?) using that code, but shouldn't there be
a way to see if we are on a boot partition or not?

Best regards,
Patrick

> Signed-off-by: S??bastien Szymanski 
> ---
>  arch/arm/mach-imx/spl_imx_romapi.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/spl_imx_romapi.c 
> b/arch/arm/mach-imx/spl_imx_romapi.c
> index 5dc0f7174e..1e9d7bd9ab 100644
> --- a/arch/arm/mach-imx/spl_imx_romapi.c
> +++ b/arch/arm/mach-imx/spl_imx_romapi.c
> @@ -84,10 +84,12 @@ static int spl_romapi_load_image_seekable(struct 
> spl_image_info *spl_image,
>  image_offset, pagesize, offset);
>  
>   if (((rom_bt_dev >> 16) & 0xff) ==  BT_DEV_TYPE_FLEXSPINOR)
> - offset = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512;
> + offset = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - 0x1000;
> + else if (((rom_bt_dev >> 16) & 0xff) ==  BT_DEV_TYPE_SD)
> + offset = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - 0x8000;
>   else
>   offset = image_offset +
> - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - 0x8000;
> + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512;
>  
>   size = ALIGN(sizeof(struct image_header), pagesize);
>   ret = g_rom_api->download_image((u8 *)header, offset, size,
> -- 
> 2.26.2
> 

Re: [PATCH] ARM: dts: stm32: Synchronize DDR setttings on DH SoMs

[Marek Vasut]

On 4/29/20 3:08 PM, Marek Vasut wrote:
> Add custom DDR DRAM settings for the DHCOR and DHCOM SoMs and put them
> into use by the board file instead of the default ones. These new DRAM
> settings are a better fit for the SoMs.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---
> Note that these settings are generated by the cubemx tool

Seems like quite a few of those stm32mp1 patches still aren't in
u-boot/master ?

Re: [PATCH v3 00/17] mtd: spi-nor-core: add xSPI Octal DTR support

[Jagan Teki]

On Mon, Mar 30, 2020 at 9:15 PM Pratyush Yadav  wrote:
>
> Hi,
>
> This series adds support for octal DTR flashes in the spi-nor framework,
> and then adds hooks for the Cypress Semper flash which is an xSPI
> compliant Octal DTR flash.
>
> The Cadence QSPI controller driver is also updated to run in Octal DTR
> mode.
>
> Tested on TI J721e EVM with 1-bit ECC on the Cypress flash on top of
> u-boot-ti/next.
>
> This series depends on [0].
>
> [0] cf. <20200224071051.19331-1-p.ya...@ti.com>
> [0] https://lists.denx.de/pipermail/u-boot/2020-February/401192.html
>
> Changes in v3:
> - Read 2 bytes in Octal DTR mode when reading SR and FSR to avoid
>   tripping up controllers.
> - Use op->data.nbytes as a measure of whether the data phase exists or
>   not. This fixes data buswidth not being updadted for SR and FSR reads
>   because they keep data buffer as NULL when calling spi_nor_setup_op().
> - Add support for Micron mt35xu512aba to run in Octal DTR mode.

Do you have foot-print statistics for these changes? if yes can mark it here.

Jagan.

Re: [PATCH v2 09/10] pci: Add driver for Broadcom STB PCIe controller

[Sylwester Nawrocki]

Hi Jim,

On 08.05.2020 16:25, Jim Quinlan wrote:
 static int brcm_pcie_probe(struct udevice *dev)
 +{
 +   struct udevice *ctlr = pci_get_controller(dev);
 +   struct pci_controller *hose = dev_get_uclass_priv(ctlr);
 +   struct brcm_pcie *pcie = dev_get_priv(dev);
 +   void __iomem *base = pcie->base;
 +   bool ssc_good = false;
 +   int num_out_wins = 0;
 +   u64 rc_bar2_offset, rc_bar2_size;
 +   unsigned int scb_size_val;
 +   int i, ret;
 +   u16 nlw, cls, lnksta;
 +   u32 tmp;
 +
 +   /* Reset the bridge */
 +   brcm_pcie_bridge_sw_init_set(pcie, 1);
 +
 +   udelay(150);
>>> Please add a comment as to how you chose the value, and below.
>> This was picked from Jim Quinlan's original code submission:
>> https://protect2.fireeye.com/url?k=9d9c41ed-c002ef77-9d9dcaa2-0cc47a336fae-205e162c16256602=1=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F9%2F19%2F642
>>
>> Sadly there isn't any comment there.

> The bridge is being reset and then un-reset.  The delay is a safety
> precaution to preclude the reset signal from looking like a glitch.

If you don't mind I will add that sentence as a comment for the reset
delay.

-- 
Regards,
Sylwester

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[André Przywara]

On 12/05/2020 16:09, Tom Rini wrote:

Hi,

> On Tue, May 12, 2020 at 03:53:55PM +0100, André Przywara wrote:
>> On 12/05/2020 15:25, Tom Rini wrote:
>>> On Tue, May 12, 2020 at 03:18:33PM +0100, André Przywara wrote:
 On 09/05/2020 15:25, Amit Singh Tomar wrote:
> This patch adds node for ethernet controller found on Action Semi OWL
> S700 SoC.
>
> Since, there is no upstream Linux binding exist for S700 ethernet
> controller, Changes are put in u-boot specific dtsi file.

 But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
 file, since you specify the PHY mode in here (which is board specific).
>>>
>>> The general way to move forward here is that bindings should be getting
>>> proposed to Linux and accepted there, and U-Boot can take a WIP of them,
>>> that gets updated later on to match, but we shouldn't get it here first.
>>
>> Yes, this is of course a stop-gap measure, but a useful one: Being able
>> to TFTP a kernel helps with developing the kernel port, especially since
>> U-Boot doesn't support MMC (yet).
>> And there are easier things than pushing a DT binding into the kernel
>> tree without having a Linux driver ready ...
> 
> So, we're at -rc2 for v2020.07.  The DDR calculation stuff I can see
> getting pulled in.  Is the ethernet driver for this SoC so far from done
> that it's not ready for linux-next?  Things don't have to be in mainline
> proper, but the expectation is that it's making reasonable progress
> there and been reviewed so that binding changes between what we take in
> U-Boot at first and a final re-sync once it is in mainline are minimal.

I don't think there is any particular rush in getting this actually
merged. After all it seems like the users of this board can be counted
on one hand.
I think it's nice to have this on the list, so interested parties can
pull it in if there is a need. But we can surely wait how the binding
evolves in the kernel tree, though this might take some time.

Cheers,
Andre.

Re: [PATCH][v4 6/6] board: tbs2910: add documentation

[Denis 'GNUtoo' Carikli]

On Sun, 1 Mar 2020 14:59:23 +0100
Soeren Moch  wrote:

> To ease the review process it is good style to add a patch revision
> history below the sign-off after a "---" separator. This would look
> like ---
> changes in v4:
>  - bla
I usually use that to indicate changes that do not correspond to the
changes requested by the reviewers, or where the fix is slightly
different from the one suggested during the review.

If the fix sticks to precisely what was suggested, does it still
helps to include such changes in the ChangeLog too?

Denis.


pgp0uzOvhiDXN.pgp
Description: OpenPGP digital signature

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[Amit Tomer]

> So, we're at -rc2 for v2020.07.  The DDR calculation stuff I can see
> getting pulled in.  Is the ethernet driver for this SoC so far from done
> that it's not ready for linux-next?  Things don't have to be in mainline
> proper, but the expectation is that it's making reasonable progress
> there and been reviewed so that binding changes between what we take in
> U-Boot at first and a final re-sync once it is in mainline are minimal.

To be honest, we haven't put any of the Ethernet bits for Linux yet.
We have put few patches for review to support MMC for S700 in Linux,
and once those gets merged we would start working on Ethernet.

Thanks
-Amit

Re: [PATCH] dt-bindings: vendor-prefixes: Add U-Boot bootloader prefix

[Rob Herring]

On Thu, 30 Apr 2020 11:31:27 +0200, Michal Simek wrote:
> List U-Boot project in vendor prefixes.
> 
> For more information take a look at:
> https://en.wikipedia.org/wiki/Das_U-Boot
> Source code is available here:
> https://gitlab.denx.de/u-boot/u-boot
> 
> Signed-off-by: Michal Simek 
> ---
> 
> The patch was created based on discussion with Rob
> https://lore.kernel.org/linux-devicetree/CAL_Jsq+ehJSK7sjqmKtWOVjr-QZ3LDB+ywCO85uF8WJ+cB=a...@mail.gmail.com/
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Applied, thanks!

Re: [RFC PATCH 1/2] arm: provide a function for boards init code to modify MMU virtual-physical map

[Sylwester Nawrocki]

On 12.05.2020 15:17, Marek Szyprowski wrote:
> -void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
> -  enum dcache_option option);
> +static inline void mmu_set_region_dcache_behaviour(phys_addr_t start,
> + size_t size, enum dcache_option option)

aarch64 build fails with an error:

arch/arm/cpu/armv8/cache_v8.c:555:6: error: redefinition of 
‘mmu_set_region_dcache_behaviour’
 void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
  ^~~
In file included from ./arch/arm/include/asm/cache.h:11:0,
 from include/net.h:15,
 from include/common.h:41,
 from arch/arm/cpu/armv8/cache_v8.c:10:
./arch/arm/include/asm/system.h:593:20: note: previous definition of 
‘mmu_set_region_dcache_behaviour’ was here
 static inline void mmu_set_region_dcache_behaviour(phys_addr_t start,
^~~
  CC  common/exports.o
scripts/Makefile.build:265: recipe for target 'arch/arm/cpu/armv8/cache_v8.o' 
failed
make[1]: *** [arch/arm/cpu/armv8/cache_v8.o] Error 1
Makefile:1790: recipe for target 'arch/arm/cpu/armv8' failed
make: *** [arch/arm/cpu/armv8] Error 2

-- 
Thanks,
Sylwester

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[Tom Rini]

On Tue, May 12, 2020 at 03:53:55PM +0100, André Przywara wrote:
> On 12/05/2020 15:25, Tom Rini wrote:
> > On Tue, May 12, 2020 at 03:18:33PM +0100, André Przywara wrote:
> >> On 09/05/2020 15:25, Amit Singh Tomar wrote:
> >>> This patch adds node for ethernet controller found on Action Semi OWL
> >>> S700 SoC.
> >>>
> >>> Since, there is no upstream Linux binding exist for S700 ethernet
> >>> controller, Changes are put in u-boot specific dtsi file.
> >>
> >> But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
> >> file, since you specify the PHY mode in here (which is board specific).
> > 
> > The general way to move forward here is that bindings should be getting
> > proposed to Linux and accepted there, and U-Boot can take a WIP of them,
> > that gets updated later on to match, but we shouldn't get it here first.
> 
> Yes, this is of course a stop-gap measure, but a useful one: Being able
> to TFTP a kernel helps with developing the kernel port, especially since
> U-Boot doesn't support MMC (yet).
> And there are easier things than pushing a DT binding into the kernel
> tree without having a Linux driver ready ...

So, we're at -rc2 for v2020.07.  The DDR calculation stuff I can see
getting pulled in.  Is the ethernet driver for this SoC so far from done
that it's not ready for linux-next?  Things don't have to be in mainline
proper, but the expectation is that it's making reasonable progress
there and been reviewed so that binding changes between what we take in
U-Boot at first and a final re-sync once it is in mainline are minimal.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[André Przywara]

On 12/05/2020 15:37, Amit Tomer wrote:
> Hi,
> 
> On Tue, May 12, 2020 at 7:49 PM André Przywara  wrote:
>>
>> On 09/05/2020 15:25, Amit Singh Tomar wrote:
>>> This patch adds node for ethernet controller found on Action Semi OWL
>>> S700 SoC.
>>>
>>> Since, there is no upstream Linux binding exist for S700 ethernet
>>> controller, Changes are put in u-boot specific dtsi file.
>>
>> But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
>> file, since you specify the PHY mode in here (which is board specific).
> 
> But MAC is present on SoC , so I thought of adding it s700 specific
> u-boot.dtsi as
> it is already hosting few other things .

The MAC is indeed, but not the PHY and the MAC address.
And since this -u-boot.dtsi trick only works once in the chain, you have
to move this to the board version of the file.
Doesn't really make any difference looking at the vast number of boards
using the S700 ;-)

> 
>>> Signed-off-by: Amit Singh Tomar 
>>> ---
>>>  arch/arm/dts/s700-u-boot.dtsi | 13 +
>>>  1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
>>> index a52775f2..1b2768272c62 100644
>>> --- a/arch/arm/dts/s700-u-boot.dtsi
>>> +++ b/arch/arm/dts/s700-u-boot.dtsi
>>> @@ -6,6 +6,19 @@
>>>  /{
>>>   soc {
>>>   u-boot,dm-pre-reloc;
>>> +
>>> + gmac:  ethernet@e022 {
>>> + compatible = "actions,s700-ethernet";
>>> + reg = <0 0xe022 0 0x2000>;
>>> + interrupts = ;
>>> + interrupt-names = "macirq";
>>> + local-mac-address = [ 00 18 fe 66 66 66 ];
>>
>> Is there another solution to that? Maybe put that in the environment
>> instead? Or generate this randomly or ideally by hashing some serial number?
> 
> Yeah, I tried having "CONFIG_NET_RANDOM_ETHADDR" other day which seems
> to work(would double check it).
> 
> But is there a reason not to use "local-mac-address", since driver
> does not support parsing this
> property ?

I don't think local-mac-address is meant to be in a .dts file, actually.
It's more useful to communicate some MAC address between firmware and
bootloaders/kernels. You can use this in your development setup, but
this should not be submitted. Otherwise every board on the planet would
use the same MAC address.

Cheers,
Andre

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[André Przywara]

On 12/05/2020 15:25, Tom Rini wrote:
> On Tue, May 12, 2020 at 03:18:33PM +0100, André Przywara wrote:
>> On 09/05/2020 15:25, Amit Singh Tomar wrote:
>>> This patch adds node for ethernet controller found on Action Semi OWL
>>> S700 SoC.
>>>
>>> Since, there is no upstream Linux binding exist for S700 ethernet
>>> controller, Changes are put in u-boot specific dtsi file.
>>
>> But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
>> file, since you specify the PHY mode in here (which is board specific).
> 
> The general way to move forward here is that bindings should be getting
> proposed to Linux and accepted there, and U-Boot can take a WIP of them,
> that gets updated later on to match, but we shouldn't get it here first.

Yes, this is of course a stop-gap measure, but a useful one: Being able
to TFTP a kernel helps with developing the kernel port, especially since
U-Boot doesn't support MMC (yet).
And there are easier things than pushing a DT binding into the kernel
tree without having a Linux driver ready ...

Cheers,
Andre

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[Tom Rini]

On Tue, May 12, 2020 at 08:12:37PM +0530, Amit Tomer wrote:
> Hi,
> 
> > The general way to move forward here is that bindings should be getting
> > proposed to Linux and accepted there, and U-Boot can take a WIP of them,
> > that gets updated later on to match, but we shouldn't get it here first.
> 
> I do have a plan to propose this binding to Linux but this is kind of
> ready(I mean, the other bits
> like PHY and driver) for U-boot. So thought of posting it to the list here.

For some initial review, fine, but we need to have the Linux bindings
being reviewed at the same time, and before things come in to U-Boot.
Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[Amit Tomer]

Hi,

> The general way to move forward here is that bindings should be getting
> proposed to Linux and accepted there, and U-Boot can take a WIP of them,
> that gets updated later on to match, but we shouldn't get it here first.

I do have a plan to propose this binding to Linux but this is kind of
ready(I mean, the other bits
like PHY and driver) for U-boot. So thought of posting it to the list here.

Thanks
-Amit

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[Amit Tomer]

Hi,

On Tue, May 12, 2020 at 7:49 PM André Przywara  wrote:
>
> On 09/05/2020 15:25, Amit Singh Tomar wrote:
> > This patch adds node for ethernet controller found on Action Semi OWL
> > S700 SoC.
> >
> > Since, there is no upstream Linux binding exist for S700 ethernet
> > controller, Changes are put in u-boot specific dtsi file.
>
> But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
> file, since you specify the PHY mode in here (which is board specific).

But MAC is present on SoC , so I thought of adding it s700 specific
u-boot.dtsi as
it is already hosting few other things .

> > Signed-off-by: Amit Singh Tomar 
> > ---
> >  arch/arm/dts/s700-u-boot.dtsi | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
> > index a52775f2..1b2768272c62 100644
> > --- a/arch/arm/dts/s700-u-boot.dtsi
> > +++ b/arch/arm/dts/s700-u-boot.dtsi
> > @@ -6,6 +6,19 @@
> >  /{
> >   soc {
> >   u-boot,dm-pre-reloc;
> > +
> > + gmac:  ethernet@e022 {
> > + compatible = "actions,s700-ethernet";
> > + reg = <0 0xe022 0 0x2000>;
> > + interrupts = ;
> > + interrupt-names = "macirq";
> > + local-mac-address = [ 00 18 fe 66 66 66 ];
>
> Is there another solution to that? Maybe put that in the environment
> instead? Or generate this randomly or ideally by hashing some serial number?

Yeah, I tried having "CONFIG_NET_RANDOM_ETHADDR" other day which seems
to work(would double check it).

But is there a reason not to use "local-mac-address", since driver
does not support parsing this
property ?

Thanks
-Amit.

Re: [PATCH v3 2/7] uart: pl011: Add proper DM clock support

[André Przywara]

On 28/04/2020 18:57, Simon Glass wrote:

Hi,

sorry for the delay, found this, slightly mouldy already, in my draft
folder.

First, thanks for the review! I saw the Tom merged this already, but
wanted to come back to the DT hacks:

> Hi Andre,
> 
> On Mon, 27 Apr 2020 at 12:18, Andre Przywara  wrote:
>>
>> Even though the PL011 UART driver claims to be DM compliant, it does not
>> really a good job with parsing DT nodes. U-Boot seems to adhere to a
>> non-standard binding, either requiring to have a "skip-init" property in
>> the node, or to have an extra "clock" property holding the base
>> *frequency* value for the baud rate generator.
>> DTs in the U-Boot tree seem to have been hacked to match this
>> requirement.
> 
> One problem is that we want a 'debug UART' to work before the clock
> driver is running, so we want to do the *minimum possible* amount of
> init to get the UART running. So we don't want to start up driver
> model, clock drivers, etc.

I understand this very well - having an UART up and running as early as
possible is crucial for debugging.

> I think we should have useful helpers like the 'clock' property to
> avoid lots of parsing very early in U-Boot. Of course such things are
> hard for kernel people to understand / agree to but that doesn't make
> them wrong.

I agree, but I don't think we should mess around with the DT for this
purpose. This is basically a U-Boot requirement or debug feature, not a
machine property. And deviating from the official DT binding is not a
good idea.

I think for those U-Boot specific debug features we can just have CONFIG
options - for instance we already have CONFIG_PL011_CLOCK. Also I
strongly believe that skip-init does not belong into the DT. It's a
*U-Boot* decision to not *re*-init the UART, not a machine property.
There are PL011 compatible UARTs which should *not* be initialised
(SBSA-UART), but both TX1 and RPi don't have those, but instead real PL011s.
So if we desperately wanted this in the DT, we could actually use
compatible = "arm,sbsa-uart", then we don't need any clock at all.

But I was more thinking about turning skip-init into a config symbol and
defining this for TX1 and RPi. We do already something similar for the
RPi4 in Trusted Firmware [1]. This would allow us to remove the
skip-init property from the u-boot.dtsi, and would help with booting
with the DT from the SD card instead (for which the GPU firmware puts
the pointer to into the beginning of memory [2]).

I have a patch for that already, will send it soonish.

Cheers,
Andre

[1]
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0eda713b9bd65222155900aacf3a67805351f88f
[2]
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=c4597e13a2925cc6bf802d9376238f5de18b292a


>>
>> The official binding does not mention any of these properties, instead
>> recommends a standard "clocks" property to point to the baud base clock.
>>
>> Some boards use simple "fixed-clock" providers, which U-Boot readily
>> supports, so let's add some simple DM clock code to the PL011 driver to
>> learn the rate of the first clock, as described by the official binding.
>>
>> These clock nodes seem to be not ready very early in the boot process,
>> so provide a fallback value, by re-using the already existing
>> CONFIG_PL011_CLOCK variable.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  drivers/serial/serial_pl01x.c | 47 +++
>>  1 file changed, 31 insertions(+), 16 deletions(-)
> 
> Reviewed-by: Simon Glass 
>>
>> diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
>> index 2a5f256184..14040f32ef 100644
>> --- a/drivers/serial/serial_pl01x.c
>> +++ b/drivers/serial/serial_pl01x.c
>> @@ -12,6 +12,7 @@
> 
> Regards,
> Simon
> 

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[Tom Rini]

On Tue, May 12, 2020 at 03:18:33PM +0100, André Przywara wrote:
> On 09/05/2020 15:25, Amit Singh Tomar wrote:
> > This patch adds node for ethernet controller found on Action Semi OWL
> > S700 SoC.
> > 
> > Since, there is no upstream Linux binding exist for S700 ethernet
> > controller, Changes are put in u-boot specific dtsi file.
> 
> But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
> file, since you specify the PHY mode in here (which is board specific).

The general way to move forward here is that bindings should be getting
proposed to Linux and accepted there, and U-Boot can take a WIP of them,
that gets updated later on to match, but we shouldn't get it here first.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller

[André Przywara]

On 09/05/2020 15:25, Amit Singh Tomar wrote:
> This patch adds node for ethernet controller found on Action Semi OWL
> S700 SoC.
> 
> Since, there is no upstream Linux binding exist for S700 ethernet
> controller, Changes are put in u-boot specific dtsi file.

But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
file, since you specify the PHY mode in here (which is board specific).

> Signed-off-by: Amit Singh Tomar 
> ---
>  arch/arm/dts/s700-u-boot.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
> index a52775f2..1b2768272c62 100644
> --- a/arch/arm/dts/s700-u-boot.dtsi
> +++ b/arch/arm/dts/s700-u-boot.dtsi
> @@ -6,6 +6,19 @@
>  /{
>   soc {
>   u-boot,dm-pre-reloc;
> +
> + gmac:  ethernet@e022 {
> + compatible = "actions,s700-ethernet";
> + reg = <0 0xe022 0 0x2000>;
> + interrupts = ;
> + interrupt-names = "macirq";
> + local-mac-address = [ 00 18 fe 66 66 66 ];

Is there another solution to that? Maybe put that in the environment
instead? Or generate this randomly or ideally by hashing some serial number?

Cheers,
Andre.

> + clocks = < CLK_ETHERNET>, < CLK_RMII_REF>;
> + clock-names = "ethernet", "rmii_ref";
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
>   };
>  };
>  
> 

Re: [PATCH v2 1/1] efi_loader: put device tree into EfiACPIReclaimMemory

[Grant Likely]

On 11/05/2020 12:55, Heinrich Schuchardt wrote:

On 11.05.20 10:48, Grant Likely wrote:

On 07/05/2020 19:19, Heinrich Schuchardt wrote:

According to the UEFI spec ACPI tables should be placed in
EfiACPIReclaimMemory. Let's do the same with the device tree.

Suggested-by: Ard Biesheuvel 
Cc: Grant Likely 
Signed-off-by: Heinrich Schuchardt 
---
v2:
 adjust the unit test


Is there any impact to changing the memory type for current users? Does
the kernel currently expect the EFI_BOOT_SERVICES_DATA memory type? What
happens if Grub or another EFI application replaces the DTB table? Will
it try to use a different memory type, and will that matter?


If we are using GRUB, linux_boot() allocates EFI_LOADER_DATA memory and
copies the FDT to it. When the devicetree command is used GRUB also
allocates EFI_LOADER_DATA.

So changes in U-Boot have no effect on what Linux sees if booted via GRUB.

Both EFI_BOOT_SERVICES_DATA and EFI_LOADER_DATA are meant to be gone
past ExitBootServices(). EfiACPIReclaimMemory is were the UEFI payload
is adviced to consider if keeping the memory at runtime is needed.

The current patch therefore makes no difference to Linux before
ExitBootServices(). A side effect could be that Linux unnecessarily
keeps the EfiACPIReclaimMemory instead of reusing it. But Linux's
is_usable_memory() in drivers/firmware/efi/arm-init.c treats
EFI_ACPI_RECLAIM_MEMORY, EFI_ACPI_RECLAIM_MEMORY,
EFI_ACPI_RECLAIM_MEMORY just the same.


Okay. Works for me.

g.


@Daniel, Leif
A patch for the EBBR specification suggests to use
EFI_ACPI_RECLAIM_MEMORY for the devicetree passed to Linux. Please,
consider if you would apply this in GRUB too.

Best regards

Heinrich



g.


---
   cmd/bootefi.c  | 4 ++--
   lib/efi_selftest/efi_selftest_memory.c | 4 ++--
   2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 54b4b8f984..06573b14e9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -127,13 +127,13 @@ static efi_status_t copy_fdt(void **fdtp)
   new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
    fdt_size, 0);
   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
- EFI_BOOT_SERVICES_DATA, fdt_pages,
+ EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
    _fdt_addr);
   if (ret != EFI_SUCCESS) {
   /* If we can't put it there, put it somewhere */
   new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
- EFI_BOOT_SERVICES_DATA, fdt_pages,
+ EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
    _fdt_addr);
   if (ret != EFI_SUCCESS) {
   printf("ERROR: Failed to reserve space for FDT\n");
diff --git a/lib/efi_selftest/efi_selftest_memory.c
b/lib/efi_selftest/efi_selftest_memory.c
index e71732dc6d..4d32a28006 100644
--- a/lib/efi_selftest/efi_selftest_memory.c
+++ b/lib/efi_selftest/efi_selftest_memory.c
@@ -176,9 +176,9 @@ static int execute(void)
   /* Check memory reservation for the device tree */
   if (fdt_addr &&
   find_in_memory_map(map_size, memory_map, desc_size, fdt_addr,
-   EFI_BOOT_SERVICES_DATA) != EFI_ST_SUCCESS) {
+   EFI_ACPI_RECLAIM_MEMORY) != EFI_ST_SUCCESS) {
   efi_st_error
-    ("Device tree not marked as boot services data\n");
+    ("Device tree not marked as ACPI reclaim memory\n");
   return EFI_ST_FAILURE;
   }
   return EFI_ST_SUCCESS;
--
2.26.2

Re: [ANN] U-Boot v2020.07-rc2 released

[Heiko Schocher]

Hello Tom,

Am 12.05.2020 um 00:28 schrieb Tom Rini:

Hey all,

It's release day and I've tagged v2020.07-rc2.  At this point out we
should be seeing stabilization, clean-up and localized new features.

Once again, for a changelog,
git log --merges v2020.07-rc1..v2020.07-rc2
and as always, I ask for more details in the PRs people send me so I can
put them in the merge commit.

I'm planning to follow the every-other-week RC schedule and release on
July 6th.  I'm also thinking about opening -next again on June 8th as
that will give us a bit more time to focus on stability and regression
fixing.  Thanks all!



FYI:

I have now running the following 4 boards in my daily automated tbot
testsetup (build and install U-boot on the boards, and run test.py)

wandboard DL (imx6)
http://xeidos.ddns.net/ubtestresults/result/69

socrates (mpc85xx)
http://xeidos.ddns.net/ubtestresults/result/70

BBB (am335x)
http://xeidos.ddns.net/ubtestresults/result/71

aristainetos2 (imx6) (with some patches on top, gpio fixes just posted
also on this board with secure boot enabled)
http://xeidos.ddns.net/ubtestresults/result/72

Hope I find time to get this up and running for some of my at91 boards

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

[RFC PATCH 0/2] ARM: arbitrary virtual-physical mappings for RPi4 XHCI support

[Marek Szyprowski]

Hi All,

This is a result of the following discussion:
https://lists.denx.de/pipermail/u-boot/2020-May/411086.html

Those 2 patches are replacement for the patch discussed there.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Marek Szyprowski (2):
  arm: provide a function for boards init code to modify MMU
virtual-physical map
  rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM
32bit)

 arch/arm/include/asm/mmu.h|  8 
 arch/arm/include/asm/system.h | 18 --
 arch/arm/lib/cache-cp15.c | 18 --
 arch/arm/mach-bcm283x/Kconfig |  1 +
 arch/arm/mach-bcm283x/include/mach/base.h |  6 ++
 arch/arm/mach-bcm283x/init.c  | 14 ++
 include/configs/rpi.h |  5 +
 7 files changed, 62 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/include/asm/mmu.h

-- 
1.9.1

[RFC PATCH 2/2] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

[Marek Szyprowski]

Create a non-cacheable mapping for the 0x6 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff80 CPU virtual address.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/mach-bcm283x/Kconfig |  1 +
 arch/arm/mach-bcm283x/include/mach/base.h |  6 ++
 arch/arm/mach-bcm283x/init.c  | 14 ++
 include/configs/rpi.h |  5 +
 4 files changed, 26 insertions(+)

diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index 00419bf..bcb7f1d 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -36,6 +36,7 @@ config BCM2711_32B
select BCM2711
select ARMV7_LPAE
select CPU_V7A
+   select PHYS_64BIT
 
 config BCM2711_64B
bool "Broadcom BCM2711 SoC 64-bit support"
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
b/arch/arm/mach-bcm283x/include/mach/base.h
index c4ae398..1bf89db 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -8,4 +8,10 @@
 
 extern unsigned long rpi_bcm283x_base;
 
+#ifdef CONFIG_ARMV7_LPAE
+#include 
+#define phys_to_virt addrmap_phys_to_virt
+#define virt_to_phys addrmap_virt_to_phys
+#endif
+
 #endif
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 6a748da..4b9c831 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -145,6 +145,20 @@ int mach_cpu_init(void)
 }
 
 #ifdef CONFIG_ARMV7_LPAE
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT   0xff80UL
+#include 
+
+void init_addr_map(void)
+{
+   mmu_set_region_dcache_behaviour_phys(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
+BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
+DCACHE_OFF);
+   addrmap_set_entry(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
+ BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+ BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE, 0);
+}
+
 void enable_caches(void)
 {
dcache_enable();
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index b53a4b6..7da2cff 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -63,6 +63,11 @@
 #define CONFIG_SYS_BOOTM_LEN   SZ_64M
 #endif
 
+#ifdef CONFIG_ARMV7_LPAE
+#define CONFIG_ADDR_MAP 1
+#define CONFIG_SYS_NUM_ADDR_MAP 2
+#endif
+
 /* Devices */
 /* GPIO */
 #define CONFIG_BCM2835_GPIO
-- 
1.9.1

[RFC PATCH 1/2] arm: provide a function for boards init code to modify MMU virtual-physical map

[Marek Szyprowski]

Provide a function for setting arbitrary virtual-physical MMU mapping
for the given region.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/include/asm/mmu.h|  8 
 arch/arm/include/asm/system.h | 18 --
 arch/arm/lib/cache-cp15.c | 18 --
 3 files changed, 36 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/include/asm/mmu.h

diff --git a/arch/arm/include/asm/mmu.h b/arch/arm/include/asm/mmu.h
new file mode 100644
index 000..fe3d793
--- /dev/null
+++ b/arch/arm/include/asm/mmu.h
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARM_MMU_H
+#define __ASM_ARM_MMU_H
+
+#ifdef CONFIG_ADDR_MAP
+extern void init_addr_map(void);
+#endif
+
+#endif
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 81ccead..a513f4a 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -573,14 +573,28 @@ s32 psci_features(u32 function_id, u32 psci_fid);
 void save_boot_params_ret(void);
 
 /**
+ * Change the virt/phys mapping and cache settings for a region.
+ *
+ * \param virt virtual start address of memory region to change
+ * \param phys physical address for the memory region to set
+ * \param size size of memory region to change
+ * \param option   dcache option to select
+ */
+void mmu_set_region_dcache_behaviour_phys(phys_addr_t virt, phys_addr_t phys,
+   size_t size, enum dcache_option option);
+
+/**
  * Change the cache settings for a region.
  *
  * \param startstart address of memory region to change
  * \param size size of memory region to change
  * \param option   dcache option to select
  */
-void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
-enum dcache_option option);
+static inline void mmu_set_region_dcache_behaviour(phys_addr_t start,
+   size_t size, enum dcache_option option)
+{
+   mmu_set_region_dcache_behaviour_phys(start, start, size, option);
+}
 
 #ifdef CONFIG_SYS_NONCACHED_MEMORY
 void noncached_init(void);
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index f8d2096..7c14d1d 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -24,7 +24,8 @@ __weak void arm_init_domains(void)
 {
 }
 
-void set_section_dcache(int section, enum dcache_option option)
+static void set_section_phys(int section, phys_addr_t phys,
+enum dcache_option option)
 {
 #ifdef CONFIG_ARMV7_LPAE
u64 *page_table = (u64 *)gd->arch.tlb_addr;
@@ -36,7 +37,7 @@ void set_section_dcache(int section, enum dcache_option 
option)
 #endif
 
/* Add the page offset */
-   value |= ((u32)section << MMU_SECTION_SHIFT);
+   value |= phys;
 
/* Add caching bits */
value |= option;
@@ -45,13 +46,18 @@ void set_section_dcache(int section, enum dcache_option 
option)
page_table[section] = value;
 }
 
+void set_section_dcache(int section, enum dcache_option option)
+{
+   set_section_phys(section, (u32)section << MMU_SECTION_SHIFT, option);
+}
+
 __weak void mmu_page_table_flush(unsigned long start, unsigned long stop)
 {
debug("%s: Warning: not implemented\n", __func__);
 }
 
-void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
-enum dcache_option option)
+void mmu_set_region_dcache_behaviour_phys(phys_addr_t start, phys_addr_t phys,
+   size_t size, enum dcache_option option)
 {
 #ifdef CONFIG_ARMV7_LPAE
u64 *page_table = (u64 *)gd->arch.tlb_addr;
@@ -70,8 +76,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
debug("%s: start=%pa, size=%zu, option=0x%x\n", __func__, , size,
  option);
 #endif
-   for (upto = start; upto < end; upto++)
-   set_section_dcache(upto, option);
+   for (upto = start; upto < end; upto++, phys += MMU_SECTION_SIZE)
+   set_section_phys(upto, phys, option);
 
/*
 * Make sure range is cache line aligned
-- 
1.9.1

Re: [PATCH v2] cmd: avb: free partition buffer upon verify completion

[Igor Opaniuk]

Hi Gary,

On Mon, May 11, 2020 at 1:11 PM Gary Bisson
 wrote:
>
> Doing the same as the unittests for libavb [1].
>
> Allows to run 'avb verify' multiple times which can be useful after a
> failure to be able to re-flash the partition and try again.
>
> [1]
> https://android.googlesource.com/platform/external/avb/+/refs/tags/android-9.0.0_r37/test/avb_slot_verify_unittest.cc#156
>
> Signed-off-by: Gary Bisson 
> ---
> Hi,
>
> Changelog v2:
> - use avb_slot_verity_data_free as suggested by Igor
>
> This was added because of the following scenario:
> 1- fastboot flash boot boot.img
> 2- avb verify
>   -> fails because vbmeta wasn't updated
> 3- fastboot flash vbmeta vbmeta.img
> 4- avb verify
>   -> fails because it can't allocate memory as previous buffer wasn't
> freed
>
> Let me know if you have any questions.
>
> Regards,
> Gary
> ---
>  cmd/avb.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/cmd/avb.c b/cmd/avb.c
> index a4de5c40a2..93d1a31819 100644
> --- a/cmd/avb.c
> +++ b/cmd/avb.c
> @@ -312,6 +312,9 @@ int do_avb_verify_part(cmd_tbl_t *cmdtp, int flag,
> printf("Unknown error occurred\n");
> }
>
> +   if (out_data)
> +   avb_slot_verify_data_free(out_data);
> +
> return res;
>  }
>
> --
> 2.26.2
>

Reviewed-by: Igor Opaniuk 

Thanks

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk

[PATCH 1/1] imx: rom api: fix image offset computation

[Sébastien Szymanski]

According to the table 6-25 "Primary image offset and IVT offset
details", in the IMX8MNRM, the ROM expects the following image offset:

SD: 32KB
eMMC: 0 if image is in boot partion and 32KB if it is on user partition
NAND: 0
FlexSPI: 4KB
SPI: 0

On eMMC, it is more likely that U-Boot is on the boot partion, so rework
the offset computation by handling the two specific cases (SD and
FlexSPI).

Signed-off-by: Sébastien Szymanski 
---
 arch/arm/mach-imx/spl_imx_romapi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/spl_imx_romapi.c 
b/arch/arm/mach-imx/spl_imx_romapi.c
index 5dc0f7174e..1e9d7bd9ab 100644
--- a/arch/arm/mach-imx/spl_imx_romapi.c
+++ b/arch/arm/mach-imx/spl_imx_romapi.c
@@ -84,10 +84,12 @@ static int spl_romapi_load_image_seekable(struct 
spl_image_info *spl_image,
   image_offset, pagesize, offset);
 
if (((rom_bt_dev >> 16) & 0xff) ==  BT_DEV_TYPE_FLEXSPINOR)
-   offset = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512;
+   offset = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - 0x1000;
+   else if (((rom_bt_dev >> 16) & 0xff) ==  BT_DEV_TYPE_SD)
+   offset = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - 0x8000;
else
offset = image_offset +
-   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - 0x8000;
+   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512;
 
size = ALIGN(sizeof(struct image_header), pagesize);
ret = g_rom_api->download_image((u8 *)header, offset, size,
-- 
2.26.2

[PATCH v4 3/3] gpio: search for gpio label if gpio is not found through bank name

[Heiko Schocher]

dm_gpio_lookup_name() searches for a gpio through
the bank name. But we have also gpio labels, and it
makes sense to search for a gpio also in the labels
we have defined, if no gpio is found through the
bank name definition.

This is useful for example if you have a wp pin on
different gpios on different board versions.

If dm_gpio_lookup_name() searches also for the gpio labels,
you can give the gpio an unique label name and search
for this label, and do not need to differ between
board revisions.

Signed-off-by: Heiko Schocher 
---

Example on the aristainetos board:

=> gpio clear wp_spi_nor.gpio-hog
gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0
=>

before this patch, you need to know where your
pin is:

=> gpio clear GPIO2_15
gpio: pin GPIO2_15 (gpio 47) value is 0
=>

travis build:

Changes in v4:
- rebased to current master ac14bc4169

Changes in v3:
- add comment from Simon Glass
  make this new function configurable through Kconfig
  option DM_GPIO_LOOKUP_LABEL

Changes in v2:
- add comment from Simon Glass
  move code into seperate function dm_gpio_lookup_label()
  add test if dm_gpio_lookup_label() works

 drivers/gpio/Kconfig   | 22 ++
 drivers/gpio/gpio-uclass.c | 47 ++
 test/dm/gpio.c |  7 ++
 3 files changed, 76 insertions(+)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 2081520f42..4a635b905c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -46,6 +46,28 @@ config GPIO_HOG
  is a mechanism providing automatic GPIO request and config-
  uration as part of the gpio-controller's driver probe function.
 
+config DM_GPIO_LOOKUP_LABEL
+   bool "Enable searching for gpio labelnames"
+   depends on DM_GPIO
+   default y
+   help
+ This option enables searching for gpio names in
+ the defined gpio labels, if the search for the
+ gpio bank name failed. This makes sense if you use
+ different gpios on different hardware versions
+ for the same functionality in board code.
+
+config SPL_DM_GPIO_LOOKUP_LABEL
+   bool "Enable searching for gpio labelnames"
+   depends on DM_GPIO && SPL_DM && SPL_GPIO_SUPPORT
+   default n
+   help
+ This option enables searching for gpio names in
+ the defined gpio labels, if the search for the
+ gpio bank name failed. This makes sense if you use
+ different gpios on different hardware versions
+ for the same functionality in board code.
+
 config ALTERA_PIO
bool "Altera PIO driver"
depends on DM_GPIO
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index fc94334160..8af41f15b5 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -67,6 +67,46 @@ static int gpio_to_device(unsigned int gpio, struct 
gpio_desc *desc)
return ret ? ret : -ENOENT;
 }
 
+#if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
+/**
+ * dm_gpio_lookup_label() - look for name in gpio device
+ *
+ * search in uc_priv, if there is a gpio with labelname same
+ * as name.
+ *
+ * @name:  name which is searched
+ * @uc_priv:   gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ * @return:0 if found, -ENOENT if not.
+ */
+static int
+dm_gpio_lookup_label(const char *name, struct gpio_dev_priv *uc_priv,
+ulong *offset)
+{
+   int len;
+   int i;
+
+   *offset = -1;
+   len = strlen(name);
+   for (i = 0; i < uc_priv->gpio_count; i++) {
+   if (!uc_priv->name[i])
+   continue;
+   if (!strncmp(name, uc_priv->name[i], len)) {
+   *offset = i;
+   return 0;
+   }
+   }
+   return -ENOENT;
+}
+#else
+static int
+dm_gpio_lookup_label(const char *name, struct gpio_dev_priv *uc_priv,
+ulong *offset)
+{
+   return -ENOENT;
+}
+#endif
+
 int dm_gpio_lookup_name(const char *name, struct gpio_desc *desc)
 {
struct gpio_dev_priv *uc_priv = NULL;
@@ -95,6 +135,13 @@ int dm_gpio_lookup_name(const char *name, struct gpio_desc 
*desc)
if (!strict_strtoul(name + len, 10, ))
break;
}
+
+   /*
+* if we did not found a gpio through its bank
+* name, we search for a valid gpio label.
+*/
+   if (!dm_gpio_lookup_label(name, uc_priv, ))
+   break;
}
 
if (!dev)
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index bae1996962..75eafaa866 100644
--- a/test/dm/gpio.c
+++ b/test/dm/gpio.c
@@ -131,6 +131,13 @@ static int dm_test_gpio(struct unit_test_state *uts)
ut_assertok(dm_gpio_set_value(desc, 0));
ut_asserteq(0, dm_gpio_get_value(desc));
 
+   /* Check if lookup for labels work */
+   ut_assertok(gpio_lookup_name("hog_input_active_low", , ,
+   

[PATCH v4 2/3] sandbox, test: add test for GPIO_HOG function

[Heiko Schocher]

currently gpio hog function is not tested with "ut dm gpio"
so add some basic tests for gpio hog functionality.

For this enable GPIO_HOG in sandbox_defconfig, add
in DTS some gpio hog entries, and add testcase in
"ut dm gpio" command.

Signed-off-by: Heiko Schocher 

---

Changes in v4:
- rebased to current master ac14bc4169

Changes in v3: None
Changes in v2:
- add basic gpio hog test functions

 arch/sandbox/dts/test.dts  | 20 
 configs/sandbox64_defconfig|  1 +
 configs/sandbox_defconfig  |  1 +
 configs/sandbox_flattree_defconfig |  1 +
 configs/sandbox_spl_defconfig  |  1 +
 test/dm/gpio.c | 23 +++
 6 files changed, 47 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 15cd2330a3..39490dc6b0 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -341,6 +341,26 @@
#gpio-cells = <1>;
gpio-bank-name = "a";
sandbox,gpio-count = <20>;
+   hog_input_active_low {
+   gpio-hog;
+   input;
+   gpios = <0 GPIO_ACTIVE_LOW>;
+   };
+   hog_input_active_high {
+   gpio-hog;
+   input;
+   gpios = <1 GPIO_ACTIVE_HIGH>;
+   };
+   hog_output_low {
+   gpio-hog;
+   output-low;
+   gpios = <2 GPIO_ACTIVE_HIGH>;
+   };
+   hog_output_high {
+   gpio-hog;
+   output-high;
+   gpios = <3 GPIO_ACTIVE_HIGH>;
+   };
};
 
gpio_b: extra-gpios {
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index c1237ea296..39dc3dc687 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -98,6 +98,7 @@ CONFIG_DM_DEMO_SIMPLE=y
 CONFIG_DM_DEMO_SHAPE=y
 CONFIG_BOARD=y
 CONFIG_BOARD_SANDBOX=y
+CONFIG_GPIO_HOG=y
 CONFIG_PM8916_GPIO=y
 CONFIG_SANDBOX_GPIO=y
 CONFIG_I2C_CROS_EC_TUNNEL=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 9445d78118..9015458070 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -115,6 +115,7 @@ CONFIG_BOARD_SANDBOX=y
 CONFIG_DMA=y
 CONFIG_DMA_CHANNELS=y
 CONFIG_SANDBOX_DMA=y
+CONFIG_GPIO_HOG=y
 CONFIG_PM8916_GPIO=y
 CONFIG_SANDBOX_GPIO=y
 CONFIG_DM_HWSPINLOCK=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index a4a7ae8379..b5a85e1278 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -83,6 +83,7 @@ CONFIG_DM_DEMO_SIMPLE=y
 CONFIG_DM_DEMO_SHAPE=y
 CONFIG_BOARD=y
 CONFIG_BOARD_SANDBOX=y
+CONFIG_GPIO_HOG=y
 CONFIG_PM8916_GPIO=y
 CONFIG_SANDBOX_GPIO=y
 CONFIG_I2C_CROS_EC_TUNNEL=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 945fe54d20..7341fa3221 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -102,6 +102,7 @@ CONFIG_DM_DEMO_SHAPE=y
 CONFIG_BOARD=y
 CONFIG_BOARD_SANDBOX=y
 CONFIG_SPL_FIRMWARE=y
+CONFIG_GPIO_HOG=y
 CONFIG_PM8916_GPIO=y
 CONFIG_SANDBOX_GPIO=y
 CONFIG_I2C_CROS_EC_TUNNEL=y
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index f5c7aaf3bc..bae1996962 100644
--- a/test/dm/gpio.c
+++ b/test/dm/gpio.c
@@ -19,6 +19,7 @@ static int dm_test_gpio(struct unit_test_state *uts)
unsigned int offset, gpio;
struct dm_gpio_ops *ops;
struct udevice *dev;
+   struct gpio_desc *desc;
const char *name;
int offset_count;
char buf[80];
@@ -108,6 +109,28 @@ static int dm_test_gpio(struct unit_test_state *uts)
ut_asserteq_str("a", name);
ut_asserteq(20, offset_count);
 
+   /* add gpio hog tests */
+   ut_assertok(gpio_hog_lookup_name("hog_input_active_low", ));
+   ut_asserteq(GPIOD_IS_IN | GPIOD_ACTIVE_LOW, desc->flags);
+   ut_asserteq(0, desc->offset);
+   ut_asserteq(1, dm_gpio_get_value(desc));
+   ut_assertok(gpio_hog_lookup_name("hog_input_active_high", ));
+   ut_asserteq(GPIOD_IS_IN, desc->flags);
+   ut_asserteq(1, desc->offset);
+   ut_asserteq(0, dm_gpio_get_value(desc));
+   ut_assertok(gpio_hog_lookup_name("hog_output_low", ));
+   ut_asserteq(GPIOD_IS_OUT, desc->flags);
+   ut_asserteq(2, desc->offset);
+   ut_asserteq(0, dm_gpio_get_value(desc));
+   ut_assertok(dm_gpio_set_value(desc, 1));
+   ut_asserteq(1, dm_gpio_get_value(desc));
+   ut_assertok(gpio_hog_lookup_name("hog_output_high", ));
+   ut_asserteq(GPIOD_IS_OUT, desc->flags);
+   ut_asserteq(3, desc->offset);
+   ut_asserteq(1, 

[PATCH v4 0/3] gpio: add possibility to search for gpio label name

[Heiko Schocher]

search for gpio label if gpio name from bankname is not found.

This makes sense on boards with different hardware verions. You
can now search for the gpio label name, and can give the gpio
a unique name. The real gpio pin number is not needed in board
code anymore.

while at it add basic gpio hog test functions in seperate patch.

Changes in v4:
- new in version 4
- rebased to current master ac14bc4169
- rebased to current master ac14bc4169

Changes in v3:
- add comment from Simon Glass
  make this new function configurable through Kconfig
  option DM_GPIO_LOOKUP_LABEL

Changes in v2:
- add basic gpio hog test functions
- add comment from Simon Glass
  move code into seperate function dm_gpio_lookup_label()
  add test if dm_gpio_lookup_label() works

Heiko Schocher (3):
  gpio-uclass.c: save the GPIOD flags also in the gpio descriptor
  sandbox, test: add test for GPIO_HOG function
  gpio: search for gpio label if gpio is not found through bank name

 arch/sandbox/dts/test.dts  | 20 
 configs/sandbox64_defconfig|  1 +
 configs/sandbox_defconfig  |  1 +
 configs/sandbox_flattree_defconfig |  1 +
 configs/sandbox_spl_defconfig  |  1 +
 drivers/gpio/Kconfig   | 22 +
 drivers/gpio/gpio-uclass.c | 50 ++
 test/dm/gpio.c | 30 ++
 8 files changed, 126 insertions(+)

-- 
2.24.1

[PATCH v4 1/3] gpio-uclass.c: save the GPIOD flags also in the gpio descriptor

[Heiko Schocher]

save the GPIOD_ flags also in the gpio descriptor.

Signed-off-by: Heiko Schocher 


---

Changes in v4:
- new in version 4

Changes in v3: None
Changes in v2: None

 drivers/gpio/gpio-uclass.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 757ab7106e..fc94334160 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -572,6 +572,9 @@ static int _dm_gpio_set_dir_flags(struct gpio_desc *desc, 
ulong flags)
return ret;
}
 
+   /* save the flags also in descriptor */
+   desc->flags = flags;
+
/* GPIOD_ are directly managed by driver in set_dir_flags*/
if (ops->set_dir_flags) {
ret = ops->set_dir_flags(dev, desc->offset, flags);
-- 
2.24.1

RE: [PATCH 2/2] configs: rpi_arm64: enable SDHCI SDMA support

[Peng Fan]

> Subject: [PATCH 2/2] configs: rpi_arm64: enable SDHCI SDMA support
> 
> From: Matthias Brugger 
> 
> RPi4 supports SDMA on it's SDHCI controller. Enable to option for the combine
> RPi3/4 config.
> 
> Signed-off-by: Matthias Brugger 
> 
> ---
> 
>  configs/rpi_arm64_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index
> b9bb083a1d..66c4a5368c 100644
> --- a/configs/rpi_arm64_defconfig
> +++ b/configs/rpi_arm64_defconfig
> @@ -23,6 +23,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM_KEYBOARD=y
>  CONFIG_DM_MMC=y
>  CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_BCM2835=y
>  CONFIG_DM_ETH=y
>  CONFIG_BCMGENET=y

Reviewed-by: Peng Fan 

RE: [PATCH 1/2] mmc: sdhci: Use debug for not supported SDMA info message

[Peng Fan]

> Subject: [PATCH 1/2] mmc: sdhci: Use debug for not supported SDMA info
> message
> 
> From: Matthias Brugger 
> 
> If CONFIG_MMC_SDHCI_SDMA is enabled but the HW could not support it,
> we no longer error out. Instead we do not enable it in the host.
> Change the output from printf to debug as this isn't an error but only
> additional information now.
> 
> Signed-off-by: Matthias Brugger 
> ---
> 
>  drivers/mmc/sdhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> 6e8f6e3d17..8bb4393ce1 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -744,8 +744,8 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
> sdhci_host *host,
>   if ((caps & SDHCI_CAN_DO_SDMA)) {
>   host->flags |= USE_SDMA;
>   } else {
> - printf("%s: Your controller doesn't support SDMA!!\n",
> -__func__);
> + debug("%s: Your controller doesn't support SDMA!!\n",
> +   __func__);
>   }
>  #endif
>  #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
> --

Reviewed-by: Peng Fan 

Re: Antwort: Re: [PATCH v2 00/35] dm: Add programmatic generation of ACPI tables (part B)

[Andy Shevchenko]

On Tue, May 12, 2020 at 01:55:49PM +0200, Wolfgang Wallner wrote:

> > Since you were involved a lot in the discussion in the part A series,
> > would you please let me know if you get some time to review this?
> 
> Unfortunately, I don't have as much time now for review of part B as I had for
> part A. I already started reviewing part B and I will try to continue when 
> time
> allows.

I'm busy at the moment and I will be not available for this for few weeks.
Code can be fixed iteratively, the most important part now is to see the big
picture of the design and approach.

Could you remind which patch in the series describes that? I will look at it
closer and try to allocate a bit of time to do it.

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC] am65x_evm_r5: Disable serial output

[Tom Rini]

On Tue, May 12, 2020 at 11:35:06AM +0530, Lokesh Vutla wrote:
> Hi Tom,
> 
> On 12/05/20 1:11 AM, Tom Rini wrote:
> > Given limitations on the current implementation of our test framework,
> > having both am65x_evm_r5 and am65x_evm_a53 have serial output on the
> > same port confuses the tests.  If we disable serial output in r5 and
> > disable the SPL tests as well, we can run the rest of the testsuite on
> > am65x_evm_a53.
> > 
> > Cc: Lokesh Vutla 
> > Signed-off-by: Tom Rini 
> > ---
> > For practical reasons this depends on
> > http://patchwork.ozlabs.org/project/uboot/patch/20200507230810.21476-1-sam...@sholland.org/
> > to build.  Since this also removes YMODEM support, I assume it breaks a
> 
> Right this breaks UART boot which is very useful for remote testing of U-Boot.
> This cannot be compromised.

I figured you might be using that in the lab there (I've got a WiFi SD
card for mine again).

> May be I am missing something, Can you explain what is the problem here?

See https://lists.denx.de/pipermail/u-boot/2020-May/410921.html

-- 
Tom


signature.asc
Description: PGP signature

Antwort: [PATCH v2] test: Use ut_asserteq_mem() where possible

[Wolfgang Wallner]

Hi Simon,

-"Simon Glass"  schrieb: -
>Betreff: [PATCH v2] test: Use ut_asserteq_mem() where possible
>
>Quite a few tests still use ut_assertok(memcmp(...)) and variants.
>Modify
>them to use the macro designed for this purpose.
>
>Suggested-by: Wolfgang Wallner 
>
>Signed-off-by: Simon Glass 
>---
>
>Changes in v2:
>- Convert two more that were missed
>
> test/compression.c   |   8 +--
> test/dm/acpi.c   |   6 +-
> test/dm/axi.c|   4 +-
> test/dm/dma.c|   6 +-
> test/dm/eth.c|  12 ++--
> test/dm/i2c.c|  18 +++---
> test/dm/misc.c   |  10 ++--
> test/dm/osd.c| 134
>+++
> test/dm/remoteproc.c |   6 +-
> test/dm/sf.c |   4 +-
> test/unicode_ut.c|   6 +-
> 11 files changed, 112 insertions(+), 102 deletions(-)

Reviewed-by: Wolfgang Wallner 

Re: [GIT PULL] TI changes for v2020.07-rc2

[Tom Rini]

On Tue, May 12, 2020 at 11:24:10AM +0530, Vignesh Raghavendra wrote:
> 
> 
> On 11/05/20 11:53 pm, Tom Rini wrote:
> > On Mon, May 11, 2020 at 06:12:59PM +0530, Lokesh Vutla wrote:
> > 
> >> Hi Tom,
> >>Please find the pull request for v2020.07-rc2 containing TI specific 
> >> changes.
> >>
> >> Travis-CI build: 
> >> https://travis-ci.org/github/lokeshvutla/u-boot/builds/685502396
> >>
> >> Thanks and regards,
> >> Lokesh
> >>
> >> The following changes since commit 
> >> c5c657644bc35fd6b3d6e5517698721e90646b8d:
> >>
> >>   Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)
> >>
> >> are available in the Git repository at:
> >>
> >>   https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git 
> >> tags/ti-v2020.07-rc2
> >>
> >> for you to fetch changes up to 42e05704d8c0e84e8d0eb0bb52253adaa7c9eb86:
> >>
> >>   Nokia RX-51: Update README.nokia_rx51 (2020-05-11 10:16:49 +0530)
> >>
> > 
> > Applied to u-boot/master, thanks!
> > 
> > Please note that both before and after this change, I don't have
> > ethernet working on the am65x_evm_a53 here.
> > 
> 
> Works for me with latest tip and v2019.12b sysfw:
> 
> https://pastebin.ubuntu.com/p/QPKMHpdXCQ/
> 
> What version of SYSFW was used? Could you please share the full log and
> what exactly fails with etherent? Does basic ping work?

I'm using 19.12.2-v2019.12b

and I see:
=> dhcp
cpsw_nuss@04600 Waiting for PHY auto negotiation to complete. 
TIMEOUT !

That said, I've tried all 3 ethernet ports on the board and none of them
have any link lights when I run dhcp.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH V2 1/5] imx8mp_evk: spl: drop useless code

[Fabio Estevam]

Hi Peng,

On Tue, May 12, 2020 at 8:59 AM Peng Fan  wrote:

> I not met this error. Which commit hash are you using?

I am using top of tree U-Boot master:

commit 2a38d2239d0bb4d128b00886bf097ab247a0b1a7
Author: Tom Rini 
Date:   Mon May 11 18:28:19 2020 -0400

Prepare v2020.07-rc2

Signed-off-by: Tom Rini 

Plus this watchdog patch:
https://patchwork.ozlabs.org/project/uboot/patch/20200511140031.8862-4-feste...@gmail.com/

Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

[Marek Szyprowski]

Hi Matthias,

On 08.05.2020 23:26, Matthias Brugger wrote:
> Adding Tom as he is the arm maintainer.
>
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski 
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
>> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Sylwester Nawrocki 
>> ---
>> Changes since v1:
>>   - none.
>> ---
>>   arch/arm/mach-bcm283x/Kconfig |  1 +
>>   arch/arm/mach-bcm283x/include/mach/base.h |  7 +
>>   arch/arm/mach-bcm283x/init.c  | 52 
>> +++
>>   3 files changed, 60 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
>> index 00419bf..bcb7f1d 100644
>> --- a/arch/arm/mach-bcm283x/Kconfig
>> +++ b/arch/arm/mach-bcm283x/Kconfig
>> @@ -36,6 +36,7 @@ config BCM2711_32B
>>  select BCM2711
>>  select ARMV7_LPAE
>>  select CPU_V7A
>> +select PHYS_64BIT
>>   
>>   config BCM2711_64B
>>  bool "Broadcom BCM2711 SoC 64-bit support"
>> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
>> b/arch/arm/mach-bcm283x/include/mach/base.h
>> index c4ae398..1d10dc9 100644
>> --- a/arch/arm/mach-bcm283x/include/mach/base.h
>> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
>> @@ -6,6 +6,13 @@
>>   #ifndef _BCM283x_BASE_H_
>>   #define _BCM283x_BASE_H_
>>   
>> +#include 
>> +
>>   extern unsigned long rpi_bcm283x_base;
>>   
>> +#ifdef CONFIG_ARMV7_LPAE
>> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
>> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
>> +#endif
>> +
>>   #endif
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 6a748da..5d0d160 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
>>   }
>>   
>>   #ifdef CONFIG_ARMV7_LPAE
>> +
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT0xff80UL
>> +
>> +void *rpi4_phys_to_virt(phys_addr_t paddr)
>> +{
>> +if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
>> +paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
>> +BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
>> +return (void *)(unsigned long)paddr;
> I think for this cases we have addrmap_phys_to_virt() which up to now is only
> used by powerpc.
>
>> +}
>> +
>> +static void set_section_phys(unsigned int section, phys_addr_t phys,
>> + enum dcache_option option)
>> +{
>> +u64 *page_table = (u64 *)gd->arch.tlb_addr;
>> +/* Need to set the access flag to not fault */
>> +u64 value = TTB_SECT_AP | TTB_SECT_AF;
>> +
>> +/* Add the page offset */
>> +value |= (phys);
>> +
>> +/* Add caching bits */
>> +value |= option;
>> +
>> +/* Set PTE */
>> +page_table[section] = value;
>> +}
>> +
>> +static void rpi4_create_pcie_xhci_mapping(void)
>> +{
>> +unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
>> +phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
>> +unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
>> +
>> +while (size) {
>> +set_section_phys(sect, phys_addr, DCACHE_OFF);
>> +sect++;
>> +phys_addr += MMU_SECTION_SIZE;
>> +size -= MMU_SECTION_SIZE;
>> +}
>> +}
> I wonder if we can't do all this in the pcie driver probe function. Maybe we 
> can
> create a new function like mmu_set_region_dcache_behaviour_phys which allows 
> us
> to update a mapping that's not 1:1.
>
> Tom what do you think?

In theory this could be moved to pcie probe, but then how the pcie 
driver would know WHERE in the virtual address space it should create a 
mapping for the needed MMIO area? IMHO this is something SoC or board 
specific and creating such mapping in board init is justified.

I will adapt the code to use addr_map helpers.

Best regards

-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] dt-bindings: vendor-prefixes: Add U-Boot bootloader prefix

[Linus Walleij]

On Thu, Apr 30, 2020 at 11:31 AM Michal Simek  wrote:

> List U-Boot project in vendor prefixes.
>
> For more information take a look at:
> https://en.wikipedia.org/wiki/Das_U-Boot
> Source code is available here:
> https://gitlab.denx.de/u-boot/u-boot
>
> Signed-off-by: Michal Simek 
> ---
>
> The patch was created based on discussion with Rob
> https://lore.kernel.org/linux-devicetree/CAL_Jsq+ehJSK7sjqmKtWOVjr-QZ3LDB+ywCO85uF8WJ+cB=a...@mail.gmail.com/

Makes sense.
Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

RE: [PATCH V2 1/5] imx8mp_evk: spl: drop useless code

[Peng Fan]

> Subject: Re: [PATCH V2 1/5] imx8mp_evk: spl: drop useless code
> 
> Hi Peng,
> 
> On Tue, May 12, 2020 at 6:16 AM Peng Fan  wrote:
> >
> > Drop useless getting ccm device, there is no need to explicted do this
> > in board code, and we not enable SPL CLK currently.
> >
> > Signed-off-by: Peng Fan 
> 
> I got an error while applying this patch:
> 
> patching file board/freescale/imx8mp_evk/spl.c Hunk #2 FAILED at 39.
> 1 out of 2 hunks FAILED -- saving rejects to file
> board/freescale/imx8mp_evk/spl.c.rej

Ok. I'll rebase and try.

> 
> I fixed it manually and applied the whole series plus this watchdog one:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20200511140031.8862-4-f
> estevam%40gmail.com%2Fdata=02%7C01%7Cpeng.fan%40nxp.com%
> 7Cc16790e08601447b539c08d7f669a3ef%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C637248805891280120sdata=4rvjaQt%2BoWw6
> 45GNynVYVJavcf6XU%2FhS0K3cfqKyRUM%3Dreserved=0
> 
> I get an "alloc space exhausted" error message though:
> 
> U-Boot SPL 2020.07-rc2-dirty (May 12 2020 - 08:29:04 -0300) Normal Boot
> WDT:   Started with servicing (60s timeout)
> Trying to boot from BOOTROM
> image offset 0x8000, pagesize 0x200, ivt offset 0x0
> 
> 
> U-Boot 2020.07-rc2-dirty (May 12 2020 - 08:29:04 -0300)
> 
> alloc space exhausted
> CPU:   Freescale i.MX8MP rev1.0 at 1000 MHz
> 
> Despite the alloc error, the boot completes and the 'reset' command works.

I not met this error. Which commit hash are you using?

> 
> I am still not able to boot a imx_5.4.3_2.0.0 NXP kernel though as it hangs
> after the serial driver is probed:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpasteb
> in.com%2Fraw%2Fix5dnGubdata=02%7C01%7Cpeng.fan%40nxp.com%
> 7Cc16790e08601447b539c08d7f669a3ef%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C637248805891290111sdata=z4rJdfJsEEeDux%2
> Fs3VGs291EPuwYLjeYH981boDooEo%3Dreserved=0
> 
> Are you able to boot an imx_5.4.3_2.0.0 NXP kernel?
> 
> If so, can you please share your ATF and LPDDR4 firmware files?

I am using local latest 5.4 atf/kernel. I'll send you the link private.

Regards,
Peng.

> 
> Thanks

Antwort: Re: [PATCH v2 00/35] dm: Add programmatic generation of ACPI tables (part B)

[Wolfgang Wallner]

Hi Bin,

-"Bin Meng"  schrieb: -
> Betreff: Re: [PATCH v2 00/35] dm: Add programmatic generation of ACPI tables 
> (part B)
> 
> Hi Wolfgang, Andy,
> 
> On Mon, May 11, 2020 at 4:34 AM Simon Glass  wrote:
> >
> > NOTE: I have resent this as v1 to avoid confusion
> >
> > This is split from the original series in an attempt to get things applied
> > in chunks.
> >
> > This part includes:
> > - writing basic ACPI code for integers, strings, names, packages
> > - writing descriptors for GPIO, I2C, interrupts, SPI
> > - writing code to enable/disable ACPI peripherals via GPIOs
> > - writing SSDT and DSDT tables
> > - additional ways to determine ACPI device names
> >
> > Much of this code is taken from coreboot and I have tried to avoid
> > changing the original code for no reason. Changes include:
> > - splitting the acpi_dp functions into their own file
> > - adding tests
> > - adding (lots of) comments
> > - using a context pointer instead of global variables
> > - tidying up some code where couldn't resist (e.g. 
> > acpigen_emit_namestring())
> >
> > Changes in v2:
> > - Fix memset of I2C descriptor
> > - Fix memset of SPI descriptor
> >
> > Changes in v1:
> > - Capitalise ACPI_OPS_PTR
> > - Split into more patches for review
> > - Add tests
> > - Rebase on top of common.h series
> > - Fix 'the an' typo
> > - Move header definitions into this patch
> > - Update sandbox driver slightly for testing
> > - Switch parameter order of _acpi_fill_ssdt() and make it static
> > - Fix 'sentinal' and 'METHOD_FILL_SDDT' typos
> > - Correct the commit subject
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Use OEM_TABLE_ID instead of ACPI_TABLE_CREATOR
> > - Update ACPI_DSTATUS enum
> > - Drop writing of coreboot tables
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Use acpi,ddn instead of acpi,desc
> > - Rename to acpi_device_infer_name()
> > - Update newly created sandbox tests
> >
> 
> Since you were involved a lot in the discussion in the part A series,
> would you please let me know if you get some time to review this?

Unfortunately, I don't have as much time now for review of part B as I had for
part A. I already started reviewing part B and I will try to continue when time
allows.

regards, Wolfgang

Re: raspberrypi cm3 v2019.07 not working

[Matthias Brugger]

On 12/05/2020 13:39, Matthias Brugger wrote:
> 
> 
> On 12/05/2020 13:36, Belisko Marek wrote:
>> On Tue, May 12, 2020 at 1:16 PM Matthias Brugger  
>> wrote:
>>>
>>>
>>>
>>> On 12/05/2020 13:00, Belisko Marek wrote:
 On Tue, May 12, 2020 at 12:51 PM Matthias Brugger  
 wrote:
>
>
>
> On 12/05/2020 11:15, Belisko Marek wrote:
>> On Fri, May 8, 2020 at 11:39 PM Belisko Marek  
>> wrote:
>>>
>>> Hi Matthias,
>>>
>>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger  
>>> wrote:

 Hi Marek,

 On 08/05/2020 21:52, Belisko Marek wrote:
> On Wed, May 6, 2020 at 11:02 PM Belisko Marek 
>  wrote:
>>
>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek 
>>  wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>>> no feedback on console. When used 2018.01 it boots fine. Probably I
>>> need to do git bisect but maybe someone have some idea or experience
>>> what can cause that. Thanks.
>> I give a try 2020.01 and I got only this:
>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>>
>> DRAM:  948 MiB
>> RPI Compute Module 3 (0xa020a0)
>>
>> I'll try to debug it and let you know.
> Debug messages shows this:
> https://pastebin.com/2SwNzrb1
>
> I tried to debug but I have no clue what is going one there.
>
> Also u-boot 2019.07 is not working at all on cm3 due to this commit
> (after bisect when reverted u-boot start working again):
> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
> tree sources to Linux 5.1-rc6 state
>
> Any ideas hint how to resolve this issue? Thanks.
>

 Can you try to cherry-pick the following two patches to your tree:
 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>>> But those are present in 2020.01 and this version at least print
>>> something to console but stuck somewhere (pls see pastebin log with
>>> debug enabled)
>>> I prefer to run 2020.01 ;). Thanks.
>> Any other stuff I can try to make it working in 2020.01? Could that be
>> firmware issue somehow? Thanks.
>
> Sorry I didn't realized that your first try was with 2020.01.
> I just confirmed that it acutually does not boot. As a shortcut, do you 
> know
> which is the last working version of U-Boot?
 v2019.07 with reverted  commit :
 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
 tree sources to Linux 5.1-rc6 state
 work fine. Without revert it shows anything on console. So something
 between 2019.07..2020.01 mus fix it partially ;)
>>>
>>> I just tired v2020.04 and it works for me. Would you mind testing that on 
>>> your end?
>> OK I'll give a try and try to bisect between 2020.01 and 2020.04. I
>> have dependency on 2020.01 as I integrate mender
>> and then use this version.
> 
> I'm on that no need for you to do it.
> 

The result for me is:
7099d71d87 ("common: Drop mdm_init()")

which kind of makes no sense. Can you retry, I think I made a mistake somewhere
in the process.

For reference here is my log:

$ git bisect log
git bisect start
# bad: [36fec02b1f90b92cf51ec531564f9284eae27ab4] Prepare v2020.04
git bisect bad 36fec02b1f90b92cf51ec531564f9284eae27ab4
# good: [0b0c6af38738f2c132cfd41a240889acaa031c8f] Prepare v2020.01
git bisect good 0b0c6af38738f2c132cfd41a240889acaa031c8f
# good: [2f39ab1649caddf748ef1eff60c40fede5995ced] clock_imx8mq: Make
frac_pll_init() static
git bisect good 2f39ab1649caddf748ef1eff60c40fede5995ced
# bad: [e6da32f243b3846e5c18183b8604b71ccb535a89] Merge tag 'ti-v2020.04-rc3' of
https://gitlab.denx.de/u-boot/custodians/u-boot-ti
git bisect bad e6da32f243b3846e5c18183b8604b71ccb535a89
# bad: [c95215a6ca1cc7bb53cc634159e222abc06fddff] Merge tag 'rpi-next-2020.04'
of https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi
git bisect bad c95215a6ca1cc7bb53cc634159e222abc06fddff
# bad: [d7b433e40b037733f47b83b8e2f385f91035924b] env: kconfig: Restrict
rockchip env for MMC
git bisect bad d7b433e40b037733f47b83b8e2f385f91035924b
# bad: [6db7943b92f7a4b5858b6a68f137462ed0293e09] i2c: designware_i2c: Rename
'max' speed to 'high' speed
git bisect bad 6db7943b92f7a4b5858b6a68f137462ed0293e09
# bad: [f32934916c65d3c26c5436b393d886fce8b9ab9f] common: Rename and move 
source()
git bisect bad f32934916c65d3c26c5436b393d886fce8b9ab9f
# bad: [ef20e5359bde42ad7e1aae8f0bf893dbca2ef2d0] common: Drop
CONFIG_POST_STD/ALT_LIST
git bisect bad ef20e5359bde42ad7e1aae8f0bf893dbca2ef2d0
# bad: [34971eec84e25773e29acfeeeae5ccb88f197ab4] common: Move do_tftpb() to 
net.h
git bisect bad 34971eec84e25773e29acfeeeae5ccb88f197ab4
# bad: 

Re: [PATCH 1/2] imx: imx8mp_evk: fix boot issue

[Fabio Estevam]

Hi Peng,

On Mon, May 11, 2020 at 10:32 PM Peng Fan  wrote:

> After a thought, i.MX8MQ/MM/MN/MP have different OCRAM sizes,
> and ATF locates in different places. So I would keep current code as is.

Ok, this can be done later as a cleanup. What we should really avoid
is to keep duplicating these SPL configurations in every i.MX8M board
file.

Re: [PATCH V2 1/5] imx8mp_evk: spl: drop useless code

[Fabio Estevam]

Hi Peng,

On Tue, May 12, 2020 at 6:16 AM Peng Fan  wrote:
>
> Drop useless getting ccm device, there is no need to explicted do this
> in board code, and we not enable SPL CLK currently.
>
> Signed-off-by: Peng Fan 

I got an error while applying this patch:

patching file board/freescale/imx8mp_evk/spl.c
Hunk #2 FAILED at 39.
1 out of 2 hunks FAILED -- saving rejects to file
board/freescale/imx8mp_evk/spl.c.rej

I fixed it manually and applied the whole series plus this watchdog one:
https://patchwork.ozlabs.org/project/uboot/patch/20200511140031.8862-4-feste...@gmail.com/

I get an "alloc space exhausted" error message though:

U-Boot SPL 2020.07-rc2-dirty (May 12 2020 - 08:29:04 -0300)
Normal Boot
WDT:   Started with servicing (60s timeout)
Trying to boot from BOOTROM
image offset 0x8000, pagesize 0x200, ivt offset 0x0


U-Boot 2020.07-rc2-dirty (May 12 2020 - 08:29:04 -0300)

alloc space exhausted
CPU:   Freescale i.MX8MP rev1.0 at 1000 MHz

Despite the alloc error, the boot completes and the 'reset' command works.

I am still not able to boot a imx_5.4.3_2.0.0 NXP kernel though as it
hangs after the serial driver is probed:
https://pastebin.com/raw/ix5dnGub

Are you able to boot an imx_5.4.3_2.0.0 NXP kernel?

If so, can you please share your ATF and LPDDR4 firmware files?

Thanks

Re: raspberrypi cm3 v2019.07 not working

[Matthias Brugger]

On 12/05/2020 13:36, Belisko Marek wrote:
> On Tue, May 12, 2020 at 1:16 PM Matthias Brugger  
> wrote:
>>
>>
>>
>> On 12/05/2020 13:00, Belisko Marek wrote:
>>> On Tue, May 12, 2020 at 12:51 PM Matthias Brugger  wrote:



 On 12/05/2020 11:15, Belisko Marek wrote:
> On Fri, May 8, 2020 at 11:39 PM Belisko Marek  
> wrote:
>>
>> Hi Matthias,
>>
>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger  
>> wrote:
>>>
>>> Hi Marek,
>>>
>>> On 08/05/2020 21:52, Belisko Marek wrote:
 On Wed, May 6, 2020 at 11:02 PM Belisko Marek 
  wrote:
>
> On Tue, May 5, 2020 at 10:18 PM Belisko Marek 
>  wrote:
>>
>> Hi,
>>
>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>> no feedback on console. When used 2018.01 it boots fine. Probably I
>> need to do git bisect but maybe someone have some idea or experience
>> what can cause that. Thanks.
> I give a try 2020.01 and I got only this:
> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>
> DRAM:  948 MiB
> RPI Compute Module 3 (0xa020a0)
>
> I'll try to debug it and let you know.
 Debug messages shows this:
 https://pastebin.com/2SwNzrb1

 I tried to debug but I have no clue what is going one there.

 Also u-boot 2019.07 is not working at all on cm3 due to this commit
 (after bisect when reverted u-boot start working again):
 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
 tree sources to Linux 5.1-rc6 state

 Any ideas hint how to resolve this issue? Thanks.

>>>
>>> Can you try to cherry-pick the following two patches to your tree:
>>> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
>>> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>> But those are present in 2020.01 and this version at least print
>> something to console but stuck somewhere (pls see pastebin log with
>> debug enabled)
>> I prefer to run 2020.01 ;). Thanks.
> Any other stuff I can try to make it working in 2020.01? Could that be
> firmware issue somehow? Thanks.

 Sorry I didn't realized that your first try was with 2020.01.
 I just confirmed that it acutually does not boot. As a shortcut, do you 
 know
 which is the last working version of U-Boot?
>>> v2019.07 with reverted  commit :
>>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>>> tree sources to Linux 5.1-rc6 state
>>> work fine. Without revert it shows anything on console. So something
>>> between 2019.07..2020.01 mus fix it partially ;)
>>
>> I just tired v2020.04 and it works for me. Would you mind testing that on 
>> your end?
> OK I'll give a try and try to bisect between 2020.01 and 2020.04. I
> have dependency on 2020.01 as I integrate mender
> and then use this version.

I'm on that no need for you to do it.

Regards,
Matthias

Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY

[Matthias Brugger]

On 12/05/2020 13:34, LABBE Corentin wrote:
> On Tue, May 12, 2020 at 12:17:25PM +0200, Matthias Brugger wrote:
>> Hi Corentin,
>>
>> On 09/05/2020 01:25, Matthias Brugger wrote:
>>> On 09/05/2020 01:18, Matthias Brugger wrote:
 Hi Corentin,

 On 24/04/2020 14:51, LABBE Corentin wrote:
> On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote:
>> As discussed at 
>> https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/
>> the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY.
>> Without it, booting with an initrd fail.
>>
>> Signed-off-by: Corentin Labbe 
>> ---
>>  configs/rpi_4_defconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
>> index 6d148dab07..8540b3c927 100644
>> --- a/configs/rpi_4_defconfig
>> +++ b/configs/rpi_4_defconfig
>> @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000
>>  CONFIG_NR_DRAM_BANKS=2
>>  CONFIG_DISTRO_DEFAULTS=y
>>  CONFIG_OF_BOARD_SETUP=y
>> -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
>> +CONFIG_ARCH_FIXUP_FDT_MEMORY=y
>>  CONFIG_MISC_INIT_R=y
>>  # CONFIG_DISPLAY_CPUINFO is not set
>>  # CONFIG_DISPLAY_BOARDINFO is not set
>> -- 
>

 Patch looks good, but is there any reason why you don't enable it for
 rpi_4_32b_defconfig and rpi_arm64_defconfig?

>>>
>>> And please add me to the recipients list, otherwise this patches most 
>>> probably
>>> get lost.
>>>
>>
>> Are you planning to send a new version of the patch which enables the option 
>> for
>> all configs?
>>
> 
> Yes, I will.
> But note that I didnt tested rpi_4_32b_defconfig.
> And I am currently unable to test it.
> If you want it to be tested, could you apply this patch as is, and I will 
> submit the rpi_4_32b_defconfig later.
> 

Ok, please don't forget to submit/test  configs/rpi_arm64_defconfig as well.

Regards,
Matthias

Re: raspberrypi cm3 v2019.07 not working

[Belisko Marek]

On Tue, May 12, 2020 at 1:16 PM Matthias Brugger  wrote:
>
>
>
> On 12/05/2020 13:00, Belisko Marek wrote:
> > On Tue, May 12, 2020 at 12:51 PM Matthias Brugger  wrote:
> >>
> >>
> >>
> >> On 12/05/2020 11:15, Belisko Marek wrote:
> >>> On Fri, May 8, 2020 at 11:39 PM Belisko Marek  
> >>> wrote:
> 
>  Hi Matthias,
> 
>  On Fri, May 8, 2020 at 11:28 PM Matthias Brugger  
>  wrote:
> >
> > Hi Marek,
> >
> > On 08/05/2020 21:52, Belisko Marek wrote:
> >> On Wed, May 6, 2020 at 11:02 PM Belisko Marek 
> >>  wrote:
> >>>
> >>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek 
> >>>  wrote:
> 
>  Hi,
> 
>  I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>  no feedback on console. When used 2018.01 it boots fine. Probably I
>  need to do git bisect but maybe someone have some idea or experience
>  what can cause that. Thanks.
> >>> I give a try 2020.01 and I got only this:
> >>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
> >>>
> >>> DRAM:  948 MiB
> >>> RPI Compute Module 3 (0xa020a0)
> >>>
> >>> I'll try to debug it and let you know.
> >> Debug messages shows this:
> >> https://pastebin.com/2SwNzrb1
> >>
> >> I tried to debug but I have no clue what is going one there.
> >>
> >> Also u-boot 2019.07 is not working at all on cm3 due to this commit
> >> (after bisect when reverted u-boot start working again):
> >> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
> >> tree sources to Linux 5.1-rc6 state
> >>
> >> Any ideas hint how to resolve this issue? Thanks.
> >>
> >
> > Can you try to cherry-pick the following two patches to your tree:
> > 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
> > 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>  But those are present in 2020.01 and this version at least print
>  something to console but stuck somewhere (pls see pastebin log with
>  debug enabled)
>  I prefer to run 2020.01 ;). Thanks.
> >>> Any other stuff I can try to make it working in 2020.01? Could that be
> >>> firmware issue somehow? Thanks.
> >>
> >> Sorry I didn't realized that your first try was with 2020.01.
> >> I just confirmed that it acutually does not boot. As a shortcut, do you 
> >> know
> >> which is the last working version of U-Boot?
> > v2019.07 with reverted  commit :
> > 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
> > tree sources to Linux 5.1-rc6 state
> > work fine. Without revert it shows anything on console. So something
> > between 2019.07..2020.01 mus fix it partially ;)
>
> I just tired v2020.04 and it works for me. Would you mind testing that on 
> your end?
OK I'll give a try and try to bisect between 2020.01 and 2020.04. I
have dependency on 2020.01 as I integrate mender
and then use this version.
>
> Do you have a hard dependency on v2020.01?
>
> Regards,
> Matthias

Thanks.

BR,

marek


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

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

RE: [PATCH] MAINTAINERS: add QorIQ DPAA

[Madalin Bucur (OSS)]

> -Original Message-
> From: Priyanka Jain 
> Sent: Tuesday, May 12, 2020 12:53 PM
> To: Madalin Bucur (OSS) ;
> joe.hershber...@ni.com; Priyanka Jain (OSS) 
> Cc: u-boot@lists.denx.de
> Subject: RE: [PATCH] MAINTAINERS: add QorIQ DPAA
> 
> >-Original Message-
> >From: U-Boot  On Behalf Of Madalin Bucur
> >Sent: Monday, May 4, 2020 3:42 PM
> >To: joe.hershber...@ni.com; Priyanka Jain (OSS)
> >
> >Cc: u-boot@lists.denx.de; Madalin Bucur (OSS)
> >
> >Subject: [PATCH] MAINTAINERS: add QorIQ DPAA
> >
> >Add entries for the QorIQ DPAA related files - the DPAA FMan Ethernet
> driver
> >and the QorIQ ARM DPAA device tree include files.
> >
> >Signed-off-by: Madalin Bucur 
> >---
> >This was included in v3 of the DPAA DM patches but, as v1 was merged, it
> >was left out, resending.
> >
> > MAINTAINERS | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> >diff --git a/MAINTAINERS b/MAINTAINERS
> >index 66f0b07..76f4cc1 100644
> >--- a/MAINTAINERS
> >+++ b/MAINTAINERS
> >@@ -850,6 +850,12 @@ S:  Maintained
> > T:  git
> >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> >b.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-
> >mpc86xx.gitdata=02%7C01%7Cpriyanka.jain%40nxp.com%7C8a143a
> >8949dc42d069af08d7f0138c2d%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> >7C0%7C0%7C637241839090504358sdata=hgaCJijYavgoLmGsfOEAN
> >MDcyfx8VLFB%2BvZPKgGu6R4%3Dreserved=0
> > F:  arch/powerpc/cpu/mpc86xx/
> >
> >+QORIQ DPAA
> >+M:  Madalin Bucur 
> >+S:  Maintained
> >+F:  drivers/net/fm/
> >+F:  arch/arm/dts/qoriq*
> >+
> 
> 
> This MAINTAINER file is mainly for custodian maintainers.
> And currently I am acting as Maintainer  of the files mentioned
> If you want to add specific file names here to fix checkpatch error,
> please add file names under " FREESCALE QORIQ" section
> 
> Regards
> Priyanka

Ok, please add these files to your entry then.

Madalin

Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY

[LABBE Corentin]

On Tue, May 12, 2020 at 12:17:25PM +0200, Matthias Brugger wrote:
> Hi Corentin,
> 
> On 09/05/2020 01:25, Matthias Brugger wrote:
> > On 09/05/2020 01:18, Matthias Brugger wrote:
> >> Hi Corentin,
> >>
> >> On 24/04/2020 14:51, LABBE Corentin wrote:
> >>> On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote:
>  As discussed at 
>  https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/
>  the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY.
>  Without it, booting with an initrd fail.
> 
>  Signed-off-by: Corentin Labbe 
>  ---
>   configs/rpi_4_defconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
>  index 6d148dab07..8540b3c927 100644
>  --- a/configs/rpi_4_defconfig
>  +++ b/configs/rpi_4_defconfig
>  @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000
>   CONFIG_NR_DRAM_BANKS=2
>   CONFIG_DISTRO_DEFAULTS=y
>   CONFIG_OF_BOARD_SETUP=y
>  -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
>  +CONFIG_ARCH_FIXUP_FDT_MEMORY=y
>   CONFIG_MISC_INIT_R=y
>   # CONFIG_DISPLAY_CPUINFO is not set
>   # CONFIG_DISPLAY_BOARDINFO is not set
>  -- 
> >>>
> >>
> >> Patch looks good, but is there any reason why you don't enable it for
> >> rpi_4_32b_defconfig and rpi_arm64_defconfig?
> >>
> > 
> > And please add me to the recipients list, otherwise this patches most 
> > probably
> > get lost.
> > 
> 
> Are you planning to send a new version of the patch which enables the option 
> for
> all configs?
> 

Yes, I will.
But note that I didnt tested rpi_4_32b_defconfig.
And I am currently unable to test it.
If you want it to be tested, could you apply this patch as is, and I will 
submit the rpi_4_32b_defconfig later.

Regards

Re: raspberrypi cm3 v2019.07 not working

[Matthias Brugger]

On 12/05/2020 13:00, Belisko Marek wrote:
> On Tue, May 12, 2020 at 12:51 PM Matthias Brugger  wrote:
>>
>>
>>
>> On 12/05/2020 11:15, Belisko Marek wrote:
>>> On Fri, May 8, 2020 at 11:39 PM Belisko Marek  
>>> wrote:

 Hi Matthias,

 On Fri, May 8, 2020 at 11:28 PM Matthias Brugger  wrote:
>
> Hi Marek,
>
> On 08/05/2020 21:52, Belisko Marek wrote:
>> On Wed, May 6, 2020 at 11:02 PM Belisko Marek  
>> wrote:
>>>
>>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek  
>>> wrote:

 Hi,

 I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
 no feedback on console. When used 2018.01 it boots fine. Probably I
 need to do git bisect but maybe someone have some idea or experience
 what can cause that. Thanks.
>>> I give a try 2020.01 and I got only this:
>>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>>>
>>> DRAM:  948 MiB
>>> RPI Compute Module 3 (0xa020a0)
>>>
>>> I'll try to debug it and let you know.
>> Debug messages shows this:
>> https://pastebin.com/2SwNzrb1
>>
>> I tried to debug but I have no clue what is going one there.
>>
>> Also u-boot 2019.07 is not working at all on cm3 due to this commit
>> (after bisect when reverted u-boot start working again):
>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>> tree sources to Linux 5.1-rc6 state
>>
>> Any ideas hint how to resolve this issue? Thanks.
>>
>
> Can you try to cherry-pick the following two patches to your tree:
> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
 But those are present in 2020.01 and this version at least print
 something to console but stuck somewhere (pls see pastebin log with
 debug enabled)
 I prefer to run 2020.01 ;). Thanks.
>>> Any other stuff I can try to make it working in 2020.01? Could that be
>>> firmware issue somehow? Thanks.
>>
>> Sorry I didn't realized that your first try was with 2020.01.
>> I just confirmed that it acutually does not boot. As a shortcut, do you know
>> which is the last working version of U-Boot?
> v2019.07 with reverted  commit :
> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
> tree sources to Linux 5.1-rc6 state
> work fine. Without revert it shows anything on console. So something
> between 2019.07..2020.01 mus fix it partially ;)

I just tired v2020.04 and it works for me. Would you mind testing that on your 
end?

Do you have a hard dependency on v2020.01?

Regards,
Matthias

[PATCH] arch: arm: uDPU: fix PHY mode definition to sgmii-2500

[Jakov Petrina]

Commit f49ac7e1c4 switched the default PHY speed to 3.125Gbit to resolve
issues with SFP modules. However, U-Boot does not have a "2500base-x"
phy-mode.

Resolve this by using "sgmii-2500" instead.

Signed-off-by: Jakov Petrina 
Signed-off-by: Vladimir Vid 
Cc: Luka Perkov 
Cc: Stefan Roese 
---
 arch/arm/dts/armada-3720-uDPU.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/armada-3720-uDPU.dts 
b/arch/arm/dts/armada-3720-uDPU.dts
index 07c7b91175..7f4b8222f4 100644
--- a/arch/arm/dts/armada-3720-uDPU.dts
+++ b/arch/arm/dts/armada-3720-uDPU.dts
@@ -125,14 +125,14 @@
  {
pinctrl-0 = <_pins>;
status = "okay";
-   phy-mode = "2500base-x";
+   phy-mode = "sgmii-2500";
managed = "in-band-status";
phy = <>;
 };
 
  {
status = "okay";
-   phy-mode = "2500base-x";
+   phy-mode = "sgmii-2500";
managed = "in-band-status";
phy = <>;
 };
-- 
2.26.2

Re: raspberrypi cm3 v2019.07 not working

[Belisko Marek]

On Tue, May 12, 2020 at 12:51 PM Matthias Brugger  wrote:
>
>
>
> On 12/05/2020 11:15, Belisko Marek wrote:
> > On Fri, May 8, 2020 at 11:39 PM Belisko Marek  
> > wrote:
> >>
> >> Hi Matthias,
> >>
> >> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger  wrote:
> >>>
> >>> Hi Marek,
> >>>
> >>> On 08/05/2020 21:52, Belisko Marek wrote:
>  On Wed, May 6, 2020 at 11:02 PM Belisko Marek  
>  wrote:
> >
> > On Tue, May 5, 2020 at 10:18 PM Belisko Marek  
> > wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
> >> no feedback on console. When used 2018.01 it boots fine. Probably I
> >> need to do git bisect but maybe someone have some idea or experience
> >> what can cause that. Thanks.
> > I give a try 2020.01 and I got only this:
> > U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
> >
> > DRAM:  948 MiB
> > RPI Compute Module 3 (0xa020a0)
> >
> > I'll try to debug it and let you know.
>  Debug messages shows this:
>  https://pastebin.com/2SwNzrb1
> 
>  I tried to debug but I have no clue what is going one there.
> 
>  Also u-boot 2019.07 is not working at all on cm3 due to this commit
>  (after bisect when reverted u-boot start working again):
>  143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>  tree sources to Linux 5.1-rc6 state
> 
>  Any ideas hint how to resolve this issue? Thanks.
> 
> >>>
> >>> Can you try to cherry-pick the following two patches to your tree:
> >>> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
> >>> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
> >> But those are present in 2020.01 and this version at least print
> >> something to console but stuck somewhere (pls see pastebin log with
> >> debug enabled)
> >> I prefer to run 2020.01 ;). Thanks.
> > Any other stuff I can try to make it working in 2020.01? Could that be
> > firmware issue somehow? Thanks.
>
> Sorry I didn't realized that your first try was with 2020.01.
> I just confirmed that it acutually does not boot. As a shortcut, do you know
> which is the last working version of U-Boot?
v2019.07 with reverted  commit :
143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
tree sources to Linux 5.1-rc6 state
work fine. Without revert it shows anything on console. So something
between 2019.07..2020.01 mus fix it partially ;)
>
> Regards,
> Matthias

BR,

marek

RE: [PATCH v2 17/39] bdinfo: arc: Use the generic bd command

[Alexey Brodkin]

Hi Simon,

> -Original Message-
> From: Simon Glass 
> Sent: Sunday, May 10, 2020 11:17 PM
> To: U-Boot Mailing List 
> Cc: Bin Meng ; Stefan Roese ; Tom Rini 
> ; Daniel
> Schwierzeck ; Simon Glass ; 
> Alexey Brodkin
> 
> Subject: [PATCH v2 17/39] bdinfo: arc: Use the generic bd command
> 
> There is nothing new in the arc 'bd' command beyond what is already there.
> Switch it over to use the generic code.
> 
> Signed-off-by: Simon Glass 

Acked-by: Alexey Brodkin 

Re: raspberrypi cm3 v2019.07 not working

[Matthias Brugger]

On 12/05/2020 11:15, Belisko Marek wrote:
> On Fri, May 8, 2020 at 11:39 PM Belisko Marek  wrote:
>>
>> Hi Matthias,
>>
>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger  wrote:
>>>
>>> Hi Marek,
>>>
>>> On 08/05/2020 21:52, Belisko Marek wrote:
 On Wed, May 6, 2020 at 11:02 PM Belisko Marek  
 wrote:
>
> On Tue, May 5, 2020 at 10:18 PM Belisko Marek  
> wrote:
>>
>> Hi,
>>
>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>> no feedback on console. When used 2018.01 it boots fine. Probably I
>> need to do git bisect but maybe someone have some idea or experience
>> what can cause that. Thanks.
> I give a try 2020.01 and I got only this:
> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>
> DRAM:  948 MiB
> RPI Compute Module 3 (0xa020a0)
>
> I'll try to debug it and let you know.
 Debug messages shows this:
 https://pastebin.com/2SwNzrb1

 I tried to debug but I have no clue what is going one there.

 Also u-boot 2019.07 is not working at all on cm3 due to this commit
 (after bisect when reverted u-boot start working again):
 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
 tree sources to Linux 5.1-rc6 state

 Any ideas hint how to resolve this issue? Thanks.

>>>
>>> Can you try to cherry-pick the following two patches to your tree:
>>> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
>>> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>> But those are present in 2020.01 and this version at least print
>> something to console but stuck somewhere (pls see pastebin log with
>> debug enabled)
>> I prefer to run 2020.01 ;). Thanks.
> Any other stuff I can try to make it working in 2020.01? Could that be
> firmware issue somehow? Thanks.

Sorry I didn't realized that your first try was with 2020.01.
I just confirmed that it acutually does not boot. As a shortcut, do you know
which is the last working version of U-Boot?

Regards,
Matthias

[PATCH 2/2] spl: add fixed memory node in target fdt also when loading ATF

[Heiko Stuebner]

From: Heiko Stuebner 

In a loading chain SPL -> ATF (->OP-TEE) -> U-Boot, ATF and a subsequent
OP-TEE will re-use the same fdt as the U-Boot target and may need the
information about usable memory ranges.

Especially OP-TEE needs this to initialize dynamic shared memory
(the only type U-Boot implements when talking to OP-TEE).

So allow spl_fixup_fdt() to take a fdt_blob argument, falling back to
the existing CONFIG_SYS_SPL_ARGS_ADDR if needed and call it from the
ATF path as well.

Signed-off-by: Heiko Stuebner 
Change-Id: I95d555e170534ad7fd03b183773e0b1f2d90d486
---
 common/spl/spl.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index b0f0e1557b..90d8bfd058 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -58,7 +58,8 @@ static bd_t bdata __attribute__ ((section(".data")));
  */
 __weak void show_boot_progress(int val) {}
 
-#if defined(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF)
+#if defined(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) || \
+defined(CONFIG_SPL_ATF)
 /* weak, default platform-specific function to initialize dram banks */
 __weak int dram_init_banksize(void)
 {
@@ -100,12 +101,14 @@ void __weak spl_perform_fixups(struct spl_image_info 
*spl_image)
 {
 }
 
-void spl_fixup_fdt(void)
+void spl_fixup_fdt(void *fdt_blob)
 {
-#if defined(CONFIG_SPL_OF_LIBFDT) && defined(CONFIG_SYS_SPL_ARGS_ADDR)
-   void *fdt_blob = (void *)CONFIG_SYS_SPL_ARGS_ADDR;
+#if defined(CONFIG_SPL_OF_LIBFDT)
int err;
 
+   if (!fdt_blob)
+   return;
+
err = fdt_check_header(fdt_blob);
if (err < 0) {
printf("fdt_root: %s\n", fdt_strerror(err));
@@ -638,7 +641,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
initr_watchdog();
 #endif
 
-   if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF))
+   if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) ||
+   IS_ENABLED(CONFIG_SPL_ATF))
dram_init_banksize();
 
bootcount_inc();
@@ -680,6 +684,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 #if CONFIG_IS_ENABLED(ATF)
case IH_OS_ARM_TRUSTED_FIRMWARE:
debug("Jumping to U-Boot via ARM Trusted Firmware\n");
+   spl_fixup_fdt(spl_image.fdt_addr);
spl_invoke_atf(_image);
break;
 #endif
@@ -699,7 +704,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 #ifdef CONFIG_SPL_OS_BOOT
case IH_OS_LINUX:
debug("Jumping to Linux\n");
-   spl_fixup_fdt();
+#if defined(CONFIG_SYS_SPL_ARGS_ADDR)
+   spl_fixup_fdt((void *)CONFIG_SYS_SPL_ARGS_ADDR);
+#endif
spl_board_prepare_for_linux();
jump_to_image_linux(_image);
 #endif
-- 
2.25.1

[PATCH 1/2] rockchip: spl: do full dram_init instead of only probing

[Heiko Stuebner]

From: Heiko Stuebner 

Parts of later SPL may need RAM information as well, so do full
dram_init() call, which includes the existing dram probing but also
initializes the ram information in gd.

All Rockchip SoCs use a TPL+SPL combination now, so that's ok for all
of them.

Signed-off-by: Heiko Stuebner 
Change-Id: I2c7496f2d88d65a9f80f74d2139bf307bb4b442b
---
 arch/arm/mach-rockchip/spl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 0b76af6080..0eda2c3485 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -135,13 +135,15 @@ void board_init_f(ulong dummy)
/* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */
timer_init();
 #endif
-#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_OS_BOOT)
+#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_RAM)
debug("\nspl:init dram\n");
-   ret = uclass_get_device(UCLASS_RAM, 0, );
+   ret = dram_init();
if (ret) {
printf("DRAM init failed: %d\n", ret);
return;
}
+   gd->ram_top = gd->ram_base + get_effective_memsize();
+   gd->ram_top = board_get_usable_ram_top(gd->ram_size);
 #endif
preloader_console_init();
 }
-- 
2.25.1

Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

[Sylwester Nawrocki]

On 11.05.2020 21:47, Matthias Brugger wrote:
 static void rpi4_create_pcie_xhci_mapping(void)
 +{
 +  unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
 +  phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
 +  unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
 +
 +  while (size) {
 +  set_section_phys(sect, phys_addr, DCACHE_OFF);
 +  sect++;
 +  phys_addr += MMU_SECTION_SIZE;
 +  size -= MMU_SECTION_SIZE;
 +  }
 +}
>>> I wonder if we can't do all this in the pcie driver probe function. Maybe 
>>> we can
>>> create a new function like mmu_set_region_dcache_behaviour_phys which 
>>> allows us
>>> to update a mapping that's not 1:1.
>>>
>>> Tom what do you think?
>> I think a harder look at how PowerPC handled this situation is in order,
>> and then following / extending that path is in order.
>>
> Thanks Tom for the feedback.
> Sylwester, I propose to split the series in two. One for adding the driver to
> 64-bit U-Boot and another one to add support for rpi_4_32b_defconfig. This way
> we could get the driver merged for 2020.07 for sure, while 32-bit parts could
> take more cycles to be ready. What do you think?

Sounds good to me, I will split the series and will post the 64-bits part
first, while we work on the 32-bit part according to your suggestions.

-- 
Thanks,
Sylwester

[Patch v2] configs: ls1046a: Define ENV_ADDR value

[Kuldeep Singh]

CONFIG_ENV_ADDR helps in picking environment from flash before DDR init.
The macro value is already defined in ls1046ardb_tfa_defconfig, also
define the value as 0x4030 in qspi_defconfig.

ls1046aqds has one spansion flash "S25FL128S_64K" of size 16M with
sector size 64K. Correct ENV_ADDR and ENV_SECT_SIZE value for QSPI and
TFA defconfigs of the board.

Signed-off-by: Kuldeep Singh 
---
v2:
- Reword commit message as per Priyanka's comments.
- Rebase to top

 configs/ls1046aqds_qspi_defconfig | 1 +
 configs/ls1046aqds_tfa_defconfig  | 4 ++--
 configs/ls1046ardb_qspi_defconfig | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/configs/ls1046aqds_qspi_defconfig 
b/configs/ls1046aqds_qspi_defconfig
index c31c374..00b3568 100644
--- a/configs/ls1046aqds_qspi_defconfig
+++ b/configs/ls1046aqds_qspi_defconfig
@@ -34,6 +34,7 @@ 
CONFIG_MTDPARTS_DEFAULT="mtdparts=155.spi-0:2m(uboot),14m(free)"
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-qds-duart"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_ENV_ADDR=0x4030
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
diff --git a/configs/ls1046aqds_tfa_defconfig b/configs/ls1046aqds_tfa_defconfig
index 07cdf8d..e412c05 100644
--- a/configs/ls1046aqds_tfa_defconfig
+++ b/configs/ls1046aqds_tfa_defconfig
@@ -4,7 +4,7 @@ CONFIG_TFABOOT=y
 CONFIG_SYS_TEXT_BASE=0x8200
 CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x50
-CONFIG_ENV_SECT_SIZE=0x2
+CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
@@ -42,7 +42,7 @@ CONFIG_ENV_IS_IN_NAND=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_USE_ENV_SPI_BUS=y
 CONFIG_ENV_SPI_BUS=0
-CONFIG_ENV_ADDR=0x6050
+CONFIG_ENV_ADDR=0x4050
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
 CONFIG_FSL_CAAM=y
diff --git a/configs/ls1046ardb_qspi_defconfig 
b/configs/ls1046ardb_qspi_defconfig
index 6c2b157..5197868 100644
--- a/configs/ls1046ardb_qspi_defconfig
+++ b/configs/ls1046ardb_qspi_defconfig
@@ -30,6 +30,7 @@ 
CONFIG_MTDPARTS_DEFAULT="mtdparts=155.spi-0:1m(rcw),15m(u-boot),48m(kernel.i
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_ENV_ADDR=0x4030
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
-- 
2.7.4

Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY

[Matthias Brugger]

Hi Corentin,

On 09/05/2020 01:25, Matthias Brugger wrote:
> On 09/05/2020 01:18, Matthias Brugger wrote:
>> Hi Corentin,
>>
>> On 24/04/2020 14:51, LABBE Corentin wrote:
>>> On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote:
 As discussed at 
 https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/
 the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY.
 Without it, booting with an initrd fail.

 Signed-off-by: Corentin Labbe 
 ---
  configs/rpi_4_defconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
 index 6d148dab07..8540b3c927 100644
 --- a/configs/rpi_4_defconfig
 +++ b/configs/rpi_4_defconfig
 @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000
  CONFIG_NR_DRAM_BANKS=2
  CONFIG_DISTRO_DEFAULTS=y
  CONFIG_OF_BOARD_SETUP=y
 -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 +CONFIG_ARCH_FIXUP_FDT_MEMORY=y
  CONFIG_MISC_INIT_R=y
  # CONFIG_DISPLAY_CPUINFO is not set
  # CONFIG_DISPLAY_BOARDINFO is not set
 -- 
>>>
>>
>> Patch looks good, but is there any reason why you don't enable it for
>> rpi_4_32b_defconfig and rpi_arm64_defconfig?
>>
> 
> And please add me to the recipients list, otherwise this patches most probably
> get lost.
> 

Are you planning to send a new version of the patch which enables the option for
all configs?

Regards,
Matthias

Re: [Patch V4 0/3] Support SDMA mode on RPI4 target - 32bit

[Matthias Brugger]

On 27/03/2020 05:07, Jaehoon Chung wrote:
> RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel side)
> But It doesn't use on u-boot side. Then it's too slow about read/write 
> performance.
> This patchset is supported SDMA mode on RPI4 target(32/64bit).
> - Tested on RPI4 1GB/2GB/4GB target

Whole series queued for v2020.07

Thanks a lot!
Matthias

> 
> Read/write time about 8MB file
> Before
> - Read : 1.472 seconds
> - Write : 4.690 seconds
> After
> - Read : 0.359 seconds
> - Write : 0.574 seconds
> 
> This patch is based on my RFC's patches.RPI4's SDHCI controller is supported 
> SDMA mode. (Checked on kernel side)
> But It doesn't use on u-boot side. Then it's too slow about read/write 
> performance.
> This patchset is supported SDMA mode on RPI4 target(32bit).
> - I didn't test on RPI4 64bit.
> 
> Read/write time about 8MB file
> Before
> - Read : 1.472 seconds
> - Write : 4.690 seconds
> After
> - Read : 0.359 seconds
> - Write : 0.574 seconds
> 
> Changelog on V4
> - Enable SDMA in rpi4_defconfig for 64bit
> 
> Changelog on V3
> - Rebased on latest u-boot-mmc
> 
> Changelog on V2
> - Keep printf message instead of debug
> - Add Peng's Reviewed-by tag
> 
> 
> Jaehoon Chung (3):
>   mmc: sdhci: use phys2bus macro when dma address is accessed
>   mmc: sdhci: not return error when SDMA is not supported
>   configs: rpi_4 : enable SDHCI_SDMA config
> 
>  configs/rpi_4_32b_defconfig |  1 +
>  configs/rpi_4_defconfig |  1 +
>  drivers/mmc/sdhci.c | 13 +++--
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 

Re: [PATCH] configs: rpi_arm64: sync env size with rpi_{3,4}_defconfig

[Matthias Brugger]

On 05/05/2020 12:09, Marek Szyprowski wrote:
> Use the same environment size as the configs dedicated for rpi3 and rpi4.
> This allows to switch between the builds and not to loose the settings
> stored on the SD card.
> 
> Signed-off-by: Marek Szyprowski 

queued for 2020.07

Thanks!

> ---
>  configs/rpi_arm64_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> index 926dfc3..7c59400 100644
> --- a/configs/rpi_arm64_defconfig
> +++ b/configs/rpi_arm64_defconfig
> @@ -3,6 +3,7 @@ CONFIG_ARCH_BCM283X=y
>  CONFIG_SYS_TEXT_BASE=0x0008
>  CONFIG_TARGET_RPI_ARM64=y
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_ENV_SIZE=0x4000
>  CONFIG_NR_DRAM_BANKS=2
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_OF_BOARD_SETUP=y
> 

RE: [PATCH 3/3] configs: ls2080aqds_tfa_defconfig: enable DM_ETH and related

[Ioana Ciornei]

> Subject: RE: [PATCH 3/3] configs: ls2080aqds_tfa_defconfig: enable DM_ETH
> and related
> 
> >-Original Message-
> >From: U-Boot  On Behalf Of Ioana Ciornei
> >Sent: Wednesday, April 29, 2020 4:03 PM
> >To: u-boot@lists.denx.de; Priyanka Jain 
> >Cc: Alexandru Marginean ; Madalin Bucur
> >; Florin Laurentiu Chiculita
> >; Razvan Ionut Cirjan
> >; Ioana Ciornei 
> >Subject: [PATCH 3/3] configs: ls2080aqds_tfa_defconfig: enable DM_ETH
> >and related
> >
> >Enable CONFIG_DM_ETH and CONFIG_DM_MDIO and related configs for the
> >LS2080AQDS board.
> >
> >Signed-off-by: Ioana Ciornei 
> >---
> > configs/ls2088aqds_tfa_defconfig | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> >diff --git a/configs/ls2088aqds_tfa_defconfig
> >b/configs/ls2088aqds_tfa_defconfig
> >index 9f49736b4f31..9eb7effce56d 100644
> >--- a/configs/ls2088aqds_tfa_defconfig
> >+++ b/configs/ls2088aqds_tfa_defconfig
> >@@ -3,8 +3,8 @@ CONFIG_TARGET_LS2080AQDS=y  CONFIG_TFABOOT=y
> > CONFIG_SYS_TEXT_BASE=0x8200
> > CONFIG_ENV_SIZE=0x2
> >-CONFIG_ENV_SECT_SIZE=0x2
> > CONFIG_ENV_OFFSET=0x50
> >+CONFIG_ENV_SECT_SIZE=0x2
> 
> 
> Why you need above change?
> 
> Regards
> Priyanka

The change above resulted from a make savedefconfig.
It's not needed but it would be good to have the defconfigs aligned with the 
result of the make command.

Regards,
Ioana

RE: [PATCH 3/3] configs: ls2080aqds_tfa_defconfig: enable DM_ETH and related

[Priyanka Jain (OSS)]

>-Original Message-
>From: U-Boot  On Behalf Of Ioana Ciornei
>Sent: Wednesday, April 29, 2020 4:03 PM
>To: u-boot@lists.denx.de; Priyanka Jain 
>Cc: Alexandru Marginean ; Madalin Bucur
>; Florin Laurentiu Chiculita
>; Razvan Ionut Cirjan
>; Ioana Ciornei 
>Subject: [PATCH 3/3] configs: ls2080aqds_tfa_defconfig: enable DM_ETH
>and related
>
>Enable CONFIG_DM_ETH and CONFIG_DM_MDIO and related configs for the
>LS2080AQDS board.
>
>Signed-off-by: Ioana Ciornei 
>---
> configs/ls2088aqds_tfa_defconfig | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
>diff --git a/configs/ls2088aqds_tfa_defconfig
>b/configs/ls2088aqds_tfa_defconfig
>index 9f49736b4f31..9eb7effce56d 100644
>--- a/configs/ls2088aqds_tfa_defconfig
>+++ b/configs/ls2088aqds_tfa_defconfig
>@@ -3,8 +3,8 @@ CONFIG_TARGET_LS2080AQDS=y  CONFIG_TFABOOT=y
> CONFIG_SYS_TEXT_BASE=0x8200
> CONFIG_ENV_SIZE=0x2
>-CONFIG_ENV_SECT_SIZE=0x2
> CONFIG_ENV_OFFSET=0x50
>+CONFIG_ENV_SECT_SIZE=0x2


Why you need above change?

Regards
Priyanka

[PATCH 1/2] mmc: sdhci: Use debug for not supported SDMA info message

[matthias . bgg]

From: Matthias Brugger 

If CONFIG_MMC_SDHCI_SDMA is enabled but the HW could not support it,
we no longer error out. Instead we do not enable it in the host.
Change the output from printf to debug as this isn't an error but only
additional information now.

Signed-off-by: Matthias Brugger 
---

 drivers/mmc/sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 6e8f6e3d17..8bb4393ce1 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -744,8 +744,8 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct 
sdhci_host *host,
if ((caps & SDHCI_CAN_DO_SDMA)) {
host->flags |= USE_SDMA;
} else {
-   printf("%s: Your controller doesn't support SDMA!!\n",
-  __func__);
+   debug("%s: Your controller doesn't support SDMA!!\n",
+ __func__);
}
 #endif
 #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
-- 
2.26.2