Re: [PATCH 080/149] board: kontron: Remove and add needed includes

[Frieder Schrempf]

On 01.05.24 04:42, Tom Rini wrote:
> Remove  from this board vendor directory and when needed
> add missing include files directly.
> 
> Signed-off-by: Tom Rini 

Acked-by: Frieder Schrempf 

Re: [PATCH v2 6/6] spinand: bind UBI block

[Frieder Schrempf]

On 25.03.24 15:41, Alexey Romanov wrote:
> UBI block is virtual block device, which is an abstraction
> over MTD layer. Therefore it is logical to use it in combination
> with MTD drivers.
> 
> Signed-off-by: Alexey Romanov 

Reviewed-by: Frieder Schrempf 

> ---
>  drivers/mtd/nand/spi/core.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index dd880adf31..c47f6c1b46 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1182,8 +1183,13 @@ static int spinand_bind(struct udevice *dev)
>  {
>   if (blk_enabled()) {
>   struct spinand_plat *plat = dev_get_plat(dev);
> + int ret;
> +
> + ret = mtd_bind(dev, >mtd);
> + if (ret)
> + return ret;
>  
> - return mtd_bind(dev, >mtd);
> + return ubi_bind(dev);
>   }
>  
>   return 0;

Re: [PATCH v2 3/3] spinand: bind mtdblock

[Frieder Schrempf]

On 07.03.24 14:07, Alexey Romanov wrote:
> Bind SPI-NAND driver to MTD block driver.
> 
> Signed-off-by: Alexey Romanov 

Reviewed-by: Frieder Schrempf 

> ---
>  drivers/mtd/nand/spi/core.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 2a3dbcfcb4..dd880adf31 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -36,6 +36,10 @@
>  #include 
>  #endif
>  
> +struct spinand_plat {
> + struct mtd_info *mtd;
> +};
> +
>  /* SPI NAND index visible in MTD names */
>  static int spi_nand_idx;
>  
> @@ -1174,12 +1178,24 @@ static void spinand_cleanup(struct spinand_device 
> *spinand)
>   kfree(spinand->scratchbuf);
>  }
>  
> +static int spinand_bind(struct udevice *dev)
> +{
> + if (blk_enabled()) {
> + struct spinand_plat *plat = dev_get_plat(dev);
> +
> + return mtd_bind(dev, >mtd);
> + }
> +
> + return 0;
> +}
> +
>  static int spinand_probe(struct udevice *dev)
>  {
>   struct spinand_device *spinand = dev_get_priv(dev);
>   struct spi_slave *slave = dev_get_parent_priv(dev);
>   struct mtd_info *mtd = dev_get_uclass_priv(dev);
>   struct nand_device *nand = spinand_to_nand(spinand);
> + struct spinand_plat *plat = dev_get_plat(dev);
>   int ret;
>  
>  #ifndef __UBOOT__
> @@ -1219,6 +1235,8 @@ static int spinand_probe(struct udevice *dev)
>   if (ret)
>   goto err_spinand_cleanup;
>  
> + plat->mtd = mtd;
> +
>   return 0;
>  
>  err_spinand_cleanup:
> @@ -1288,6 +1306,8 @@ U_BOOT_DRIVER(spinand) = {
>   .of_match = spinand_ids,
>   .priv_auto  = sizeof(struct spinand_device),
>   .probe = spinand_probe,
> + .bind = spinand_bind,
> + .plat_auto = sizeof(struct spinand_plat),
>  };
>  
>  void board_nand_init(void)

Re: [PATCH V3] mtd: spinand: Add support for XTX SPINAND

[Frieder Schrempf]

On 11.03.24 11:12, Bruce Suen wrote:
> [Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
> Informationen, warum dies wichtig ist, finden Sie unter 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Add support for XTX XT26G0xA and XT26xxxD.The driver is ported from
> linux-6.7.1.This driver is tested on Banana BPI-R3 with XT26G01A and
> XT26G12D.
> 
> Signed-off-by: Bruce Suen 

The commit message still has some minor flaws like missing spaces after
the periods, but anyway:

Reviewed-by: Frieder Schrempf 

Re: [PATCH V2] mtd: spinand: Add support for XTX SPINAND

[Frieder Schrempf]

Hi Bruce,

On 11.03.24 03:54, Bruce Suen wrote:
> [Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
> Informationen, warum dies wichtig ist, finden Sie unter 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Add support for XTX XT26G0xA and XT26xxxD,the driver is ported from
> linux-6.7.1.

Please, fix the spelling like this:

Add support for XTX XT26G0xA and XT26xxxD. The driver is ported from
Linux 6.7.1.

Also, did you test this driver in U-Boot with some specific board and
SPI NAND chip? Then please add the information about your setup to the
commit message. Thanks!

> 
> Signed-off-by: Bruce Suen 
> ---
> V1->V2:
> - remove patch errors

Checkpatch still produces the following warnings, please fix them!

CHECK: Alignment should match open parenthesis
#90: FILE: drivers/mtd/nand/spi/xtx.c:44:
+static int xt26g0xa_ooblayout_ecc(struct mtd_info *mtd, int section,
+   struct mtd_oob_region *region)

CHECK: Alignment should match open parenthesis
#102: FILE: drivers/mtd/nand/spi/xtx.c:56:
+static int xt26g0xa_ooblayout_free(struct mtd_info *mtd, int section,
+   struct mtd_oob_region *region)

Thanks
Frieder

> ---
>  drivers/mtd/nand/spi/Makefile |   2 +-
>  drivers/mtd/nand/spi/core.c   |   1 +
>  drivers/mtd/nand/spi/xtx.c| 266 ++
>  include/linux/mtd/spinand.h   |   1 +
>  4 files changed, 269 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/nand/spi/xtx.c
> 
> diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
> index f172f4787f..65b836b34c 100644
> --- a/drivers/mtd/nand/spi/Makefile
> +++ b/drivers/mtd/nand/spi/Makefile
> @@ -1,5 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
> 
>  spinand-objs := core.o esmt.o gigadevice.o macronix.o micron.o paragon.o
> -spinand-objs += toshiba.o winbond.o
> +spinand-objs += toshiba.o winbond.o xtx.o
>  obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 8ca33459f9..62c28aa422 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -829,6 +829,7 @@ static const struct spinand_manufacturer 
> *spinand_manufacturers[] = {
> _spinand_manufacturer,
> _spinand_manufacturer,
> _c8_spinand_manufacturer,
> +   _spinand_manufacturer,
>  };
> 
>  static int spinand_manufacturer_match(struct spinand_device *spinand,
> diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
> new file mode 100644
> index 00..6b7b265136
> --- /dev/null
> +++ b/drivers/mtd/nand/spi/xtx.c
> @@ -0,0 +1,266 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Author:
> + * Felix Matouschek 
> + */
> +
> +#include 
> +#ifndef __UBOOT__
> +#include 
> +#include 
> +#endif
> +#include 
> +
> +#define SPINAND_MFR_XTX0x0B
> +
> +#define XT26G0XA_STATUS_ECC_MASK   GENMASK(5, 2)
> +#define XT26G0XA_STATUS_ECC_NO_DETECTED(0 << 2)
> +#define XT26G0XA_STATUS_ECC_8_CORRECTED(3 << 4)
> +#define XT26G0XA_STATUS_ECC_UNCOR_ERROR(2 << 4)
> +
> +#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
> +#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
> +#define XT26XXXD_STATUS_ECC_1_7_CORRECTED   (1)
> +#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
> +#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
> +
> +static SPINAND_OP_VARIANTS(read_cache_variants,
> +   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
> +
> +static SPINAND_OP_VARIANTS(write_cache_variants,
> +   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
> +   SPINAND_PROG_LOAD(true, 0, NULL, 0));
> +
> +static SPINAND_OP_VARIANTS(update_cache_variants,
> +   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
> +   SPINAND_PROG_LOAD(false, 0, NULL, 0));
> +
> +static int xt26g0xa_ooblayout_ecc(struct mtd_info *mtd, int section,
> +   struct mtd_oob_region *region)
> +{
> +   if (section)
> +   return -ERANGE;
> +
> +   region->offset = 48;
> +   region->length = 16;
> +
> +   return 0;
> +}
> +
> +static int xt26g0xa_ooblayout_free(struct mtd_info *mtd, int section,
> +   struct mtd_oob_region *region)
> +{
> +   if (section)
> +   return -ERANGE;
> +
> +   region->offset = 1;
> +   region->length = 47;
> +
> +   return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops xt26g0xa_ooblayout = {
> +   .ecc = xt26g0xa_ooblayout_ecc,
> +   .rfree = xt26g0xa_ooblayout_free,
> +};
> +
> +static 

Re: [PATCH v1 0/4] Introduce mtdblock device

[Frieder Schrempf]

Hi Alexey,

On 01.03.24 14:42, Alexey Romanov wrote:
> Hi Frieder,
> 
> On Thu, Feb 29, 2024 at 09:51:04AM +0100, Frieder Schrempf wrote:
>> Hi Alexey,
>>
>> On 27.02.24 11:04, Alexey Romanov wrote:
>>> Hello!
>>>
>>> This series adds support for the mtdblock device, which
>>> allows to read/write data block by block. For example,
>>> it can now be used for BCB or Android AB command:
>>>
>>>   $ bcb load mtd 0 part_name
>>>
>>> Tested only on SPI NAND, so bind is made only for
>>> SPI NAND drivers.
>>
>> I don't know much about Android, but as far as I understand you are
>> trying to store dynamic, boot-related information on the MTD device.
>>
>> This might be acceptable if the underlying device is a NOR flash, but
>> for any type of NAND device it sounds like a rather bad idea.
>>
>> NAND devices need some kind of FTL (flash translation layer) in order to
>> work reliably. Using a block filesystem directly on the NAND MTD device
>> will cause problems as soon as any bad blocks or bit flips occur.
>>
>> People are therefore discouraged to use mtdblock on NAND and in the
>> kernel there is even a warning if you try to mount a NAND mtdblock
>> partition.
> 
> You are completely right. But, unfortunately, these are legacy ones that
> need to be supported. On some boards this approach was chosen a long
> time ago and mistakenly, so I think we need to support this for NAND.
> 
>>
>> Maybe you should reconsider this and look into how to use UBIFS as a
>> FTL. On the other hand I'm not quite sure if the UBIFS layer in U-Boot
>> is really stable and maintained. So this might not be a good idea either.
> 
> Yeah, on our new boards we switched to using UBI, and we already have 
> an implementation UBI block device for U-Boot. Will send this to
> mailing list in the near future.
> 
>>
>> Anyway, I'm against implementing mtdblock for SPI NAND (or any other NAND).
> 
> Maybe we'll just add warning like it's done in the Linux?

If we really need this, then yes, please add a warning that is printed
to the console.

Thanks
Frieder

Re: [PATCH] mtd: spinand: Add support for XTX SPI NAND

[Frieder Schrempf]

Hi Bruce,

On 01.03.24 09:01, Bruce Sun wrote:
> Add support for XTX XT26G0xA and XT26xxxD,the driver is ported from
> linux-6.7.1.

This patch is missing your Signed-off-by tag. And it seems to be
formatted incorrectly. At least I can't apply it to master or nand-next.

How do you create the patch? Can you please make sure to use 'git
format-patch' and/or 'git send-email' properly?

And also please use scripts/checkpatch.pl on your patch before sending it.

Thanks
Frieder

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Frieder Schrempf]

Hi Michael,

On 29.02.24 16:45, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> I will ask dario to pick them up. I wil review too We have a bunch of
> patches to get in nand-next

Ok, thanks. But please wait until Bruce sends a new version based on the
Linux driver as I have asked him to do that.

Thanks
Frieder

> 
> Michael
> 
> On Thu, Feb 29, 2024 at 10:24 AM Bruce Sun  wrote:
>>
>> Thans for your advice, I will port the driver from linux driver(xtx.c)
>> later.
>>
>> On 2/29/2024 5:05 PM, Frieder Schrempf wrote:
>>> Hi Bruce,
>>>
>>> On 26.12.23 08:58, Bruce Suen wrote:
>>>> [Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
>>>> Informationen, warum dies wichtig ist, finden Sie unter 
>>>> https://aka.ms/LearnAboutSenderIdentification ]
>>>>
>>>> Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
>>>> XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
>>>> XT26Q04DX SPI NAND.
>>>>
>>>> These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
>>>> ECC(8bit strength per 512bytes).
>>>>
>>>> Datasheet Links:
>>>> - http://www.xtxtech.com/download/?AId=458
>>>> - http://www.xtxtech.com/download/?AId=495
>>>>
>>>> Signed-off-by: Bruce Suen 
>>> Below you seem to have written a new driver based on gigadevice.c. Can
>>> you please instead port the existing Linux driver (xtx.c). This will
>>> help us to sync the drivers in the future if new chips will be added.
>>>
>>> Thanks
>>> Frieder
>>>
>>>> ---
>>>>   drivers/mtd/nand/spi/Makefile |   1 +
>>>>   drivers/mtd/nand/spi/core.c   |   1 +
>>>>   drivers/mtd/nand/spi/xtx.c| 180 ++
>>>>   include/linux/mtd/spinand.h   |   1 +
>>>>   4 files changed, 183 insertions(+)
>>>>   create mode 100644 drivers/mtd/nand/spi/xtx.c
>>>>
>>>> diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
>>>> index 3051de4f7e..e46cfed446 100644
>>>> --- a/drivers/mtd/nand/spi/Makefile
>>>> +++ b/drivers/mtd/nand/spi/Makefile
>>>> @@ -1,4 +1,5 @@
>>>>   # SPDX-License-Identifier: GPL-2.0
>>>>
>>>>   spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o 
>>>> toshiba.o winbond.o
>>>> +spinand-objs += xtx.o
>>>>   obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
>>>> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
>>>> index 597b088ca7..0b4c067425 100644
>>>> --- a/drivers/mtd/nand/spi/core.c
>>>> +++ b/drivers/mtd/nand/spi/core.c
>>>> @@ -828,6 +828,7 @@ static const struct spinand_manufacturer 
>>>> *spinand_manufacturers[] = {
>>>>  _spinand_manufacturer,
>>>>  _spinand_manufacturer,
>>>>  _spinand_manufacturer,
>>>> +   _spinand_manufacturer,
>>>>   };
>>>>
>>>>   static int spinand_manufacturer_match(struct spinand_device *spinand,
>>>> diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
>>>> new file mode 100644
>>>> index 00..602861c77b
>>>> --- /dev/null
>>>> +++ b/drivers/mtd/nand/spi/xtx.c
>>>> @@ -0,0 +1,180 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Copyright (C) 2018 Stefan Roese 
>>>> + *
>>>> + * Derived from drivers/mtd/nand/spi/micron.c
>>>> + *   Copyright (c) 2016-2017 Micron Technology, Inc.
>>>> + */
>>>> +
>>>> +#ifndef __UBOOT__
>>>> +#include 
>>>> +#include 
>>>> +#endif
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#define SPINAND_MFR_XTX0x0B
>>>> +
>>>> +#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
>>>> +#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
>>>> +#define XT26XXXD_STATUS_ECC_1_7_CORRECTED   (1)
>>>> +#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
>>>> +#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
>>>> +
>>>> +static SPINAND_OP_VARIANTS(read_cache_variants,
>>>> +   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
>>>> +   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
>>

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Frieder Schrempf]

On 30.01.24 04:11, Bruce Sun wrote:
>   
> Sie erhalten nicht oft eine E-Mail von bruce_s...@163.com. Erfahren Sie,
> warum dies wichtig ist 
>   
> 
> 
> On 1/29/2024 8:00 PM, Jagan Teki wrote:
>> On Tue, Dec 26, 2023 at 1:28 PM Bruce Suen  wrote:
>>> Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
>>> XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
>>> XT26Q04DX SPI NAND.
>>>
>>> These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
>>> ECC(8bit strength per 512bytes).
>>>
>>> Datasheet Links:
>>> - http://www.xtxtech.com/download/?AId=458
>>> - http://www.xtxtech.com/download/?AId=495
>>>
>>> Signed-off-by: Bruce Suen 
>>> ---
>> This won't apply on my spi tree, maybe some out-of-master changes are 
>> stopping.
>
> can you give me your spi tree? I use
> "https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git“ before.

Using u-boot-nand-flash seems correct as this is what MAINTAINERS lists
as tree for SPI NAND.

Jagan, I think this is expected to be handled by Dario and Michael and
not by the SPI maintainer.

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Frieder Schrempf]

Hi Bruce,

On 26.12.23 08:58, Bruce Suen wrote:
> [Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
> Informationen, warum dies wichtig ist, finden Sie unter 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
> XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
> XT26Q04DX SPI NAND.
> 
> These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
> ECC(8bit strength per 512bytes).
> 
> Datasheet Links:
> - http://www.xtxtech.com/download/?AId=458
> - http://www.xtxtech.com/download/?AId=495
> 
> Signed-off-by: Bruce Suen 

Below you seem to have written a new driver based on gigadevice.c. Can
you please instead port the existing Linux driver (xtx.c). This will
help us to sync the drivers in the future if new chips will be added.

Thanks
Frieder

> ---
>  drivers/mtd/nand/spi/Makefile |   1 +
>  drivers/mtd/nand/spi/core.c   |   1 +
>  drivers/mtd/nand/spi/xtx.c| 180 ++
>  include/linux/mtd/spinand.h   |   1 +
>  4 files changed, 183 insertions(+)
>  create mode 100644 drivers/mtd/nand/spi/xtx.c
> 
> diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
> index 3051de4f7e..e46cfed446 100644
> --- a/drivers/mtd/nand/spi/Makefile
> +++ b/drivers/mtd/nand/spi/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
> 
>  spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o toshiba.o 
> winbond.o
> +spinand-objs += xtx.o
>  obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 597b088ca7..0b4c067425 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -828,6 +828,7 @@ static const struct spinand_manufacturer 
> *spinand_manufacturers[] = {
> _spinand_manufacturer,
> _spinand_manufacturer,
> _spinand_manufacturer,
> +   _spinand_manufacturer,
>  };
> 
>  static int spinand_manufacturer_match(struct spinand_device *spinand,
> diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
> new file mode 100644
> index 00..602861c77b
> --- /dev/null
> +++ b/drivers/mtd/nand/spi/xtx.c
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Stefan Roese 
> + *
> + * Derived from drivers/mtd/nand/spi/micron.c
> + *   Copyright (c) 2016-2017 Micron Technology, Inc.
> + */
> +
> +#ifndef __UBOOT__
> +#include 
> +#include 
> +#endif
> +#include 
> +#include 
> +
> +#define SPINAND_MFR_XTX0x0B
> +
> +#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
> +#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
> +#define XT26XXXD_STATUS_ECC_1_7_CORRECTED   (1)
> +#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
> +#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
> +
> +static SPINAND_OP_VARIANTS(read_cache_variants,
> +   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
> +
> +static SPINAND_OP_VARIANTS(write_cache_variants,
> +   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
> +   SPINAND_PROG_LOAD(true, 0, NULL, 0));
> +
> +static SPINAND_OP_VARIANTS(update_cache_variants,
> +   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
> +   SPINAND_PROG_LOAD(false, 0, NULL, 0));
> +
> +static int xt26xxxd_ooblayout_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *region)
> +{
> +   if (section)
> +   return -ERANGE;
> +
> +   region->offset = mtd->oobsize / 2;
> +   region->length = mtd->oobsize / 2;
> +
> +   return 0;
> +}
> +
> +static int xt26xxxd_ooblayout_free(struct mtd_info *mtd, int section,
> +  struct mtd_oob_region *region)
> +{
> +   if (section)
> +   return -ERANGE;
> +
> +   region->offset = 2;
> +   region->length = mtd->oobsize / 2 - 2;
> +
> +   return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops xt26xxxd_ooblayout = {
> +   .ecc = xt26xxxd_ooblayout_ecc,
> +   .rfree = xt26xxxd_ooblayout_free,
> +};
> +
> +static int xt26xxxd_ecc_get_status(struct spinand_device *spinand,
> +  u8 status)
> +{
> +   switch (FIELD_GET(STATUS_ECC_MASK, status)) {
> +   case XT26XXXD_STATUS_ECC_NO_DETECTED:
> +   return 0;
> +   case XT26XXXD_STATUS_ECC_UNCOR_ERROR:
> +   return -EBADMSG;
> +   case XT26XXXD_STATUS_ECC_1_7_CORRECTED:
> +   return 4 + FIELD_GET(XT26XXXD_STATUS_ECC3_ECC2_MASK, status);
> +   case 

Re: [PATCH v1 0/4] Introduce mtdblock device

[Frieder Schrempf]

Hi Alexey,

On 27.02.24 11:04, Alexey Romanov wrote:
> Hello!
> 
> This series adds support for the mtdblock device, which
> allows to read/write data block by block. For example,
> it can now be used for BCB or Android AB command:
> 
>   $ bcb load mtd 0 part_name
> 
> Tested only on SPI NAND, so bind is made only for
> SPI NAND drivers.

I don't know much about Android, but as far as I understand you are
trying to store dynamic, boot-related information on the MTD device.

This might be acceptable if the underlying device is a NOR flash, but
for any type of NAND device it sounds like a rather bad idea.

NAND devices need some kind of FTL (flash translation layer) in order to
work reliably. Using a block filesystem directly on the NAND MTD device
will cause problems as soon as any bad blocks or bit flips occur.

People are therefore discouraged to use mtdblock on NAND and in the
kernel there is even a warning if you try to mount a NAND mtdblock
partition.

Maybe you should reconsider this and look into how to use UBIFS as a
FTL. On the other hand I'm not quite sure if the UBIFS layer in U-Boot
is really stable and maintained. So this might not be a good idea either.

Anyway, I'm against implementing mtdblock for SPI NAND (or any other NAND).

Best regards
Frieder

[PATCH] board: imx6dl-sielaff: spl.c: Remove multiline string

[Frieder Schrempf]

From: Frieder Schrempf 

Remove the malformed multiline string and fix the checkpatch warning.

Reported-by: Dan Carpenter 
Signed-off-by: Frieder Schrempf 
---
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 board/sielaff/imx6dl-sielaff/spl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/sielaff/imx6dl-sielaff/spl.c 
b/board/sielaff/imx6dl-sielaff/spl.c
index 64a84fd5122..6815952c0fb 100644
--- a/board/sielaff/imx6dl-sielaff/spl.c
+++ b/board/sielaff/imx6dl-sielaff/spl.c
@@ -93,8 +93,8 @@ int board_mmc_init(struct bd_info *bis)
usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
break;
default:
-   printf("Warning: you configured more USDHC controllers \
-   (%d) than supported by the board\n", i + 1);
+   printf("Warning: you configured more USDHC controllers 
(%d) than supported by the board\n",
+  i + 1);
return -EINVAL;
}
 
-- 
2.43.0

Re: [PATCH v3 2/3] board: Add support for Sielaff i.MX6 Solo board

[Frieder Schrempf]

Hi Dan,

On 20.02.24 06:56, Dan Carpenter wrote:
> On Thu, Feb 15, 2024 at 02:35:20PM +0100, Frieder Schrempf wrote:
>> +int board_mmc_getcd(struct mmc *mmc)
> 
> This function is never called.  Also for bool functions make them type
> bool and name them so that it's clear they return true/false such as
> board_mmc_getcd_was_successful() but less wordy.

What makes you think so? This is an implementation for the existing
prototype from mmc.h. As far as I can see this is called by the mmc
driver and I can't change it in any way.

> 
>> +{
>> +struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
>> +int ret = 0;
>> +
>> +switch (cfg->esdhc_base) {
>> +case USDHC3_BASE_ADDR:
>> +ret = !gpio_get_value(USDHC3_CD_GPIO);
>> +break;
>> +}
>> +
>> +return ret;
>> +}
>> +
>> +int board_mmc_init(struct bd_info *bis)
>> +{
>> +int i, ret;
>> +
>> +/*
>> + * According to the board_mmc_init() the following map is done:
>> + * (U-boot device node)(Physical Port)
>> + * mmc0USDHC1
>> + * mmc1USDHC2
>> + */
>> +for (i = 0; i < CFG_SYS_FSL_USDHC_NUM; i++) {
>> +switch (i) {
>> +case 0:
>> +imx_iomux_v3_setup_multiple_pads(usdhc3_pads,
>> + 
>> ARRAY_SIZE(usdhc3_pads));
>> +gpio_direction_input(USDHC3_CD_GPIO);
>> +usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
>> +break;
>> +default:
>> +printf("Warning: you configured more USDHC controllers \
>> +(%d) than supported by the board\n", i + 1);
>> +return -EINVAL;
> 
> This will look weird if it's ever printed:
> 
> "Warning: you configured more USDHC controllers   
> (%d) than supported by the board\n"
> 
> There is a checkpatch warnings for this.
> 
> WARNING: Avoid line continuations in quoted strings
> #1137: FILE: board/sielaff/imx6dl-sielaff/spl.c:96:
> +   printf("Warning: you configured more USDHC 
> controllers \

Agreed. Fabio already applied this to his tree. I can send a fixup for this.

Thanks
Frieder

Re: [PATCH v3 1/3] mtd: spi-nor-ids: Add support for ESMT/EON EN25Q80B

[Frieder Schrempf]

Hi Andre,

On 15.02.24 17:50, Andre Przywara wrote:
> On Thu, 15 Feb 2024 14:35:19 +0100
> Frieder Schrempf  wrote:
> 
>> From: Frieder Schrempf 
>>
>> The datasheet can be found here:
>> https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25Q80B_Ver.E.pdf
>>
>> Signed-off-by: Frieder Schrempf 
>> Reviewed-by: Fabio Estevam 
>> ---
>> Changes in v3:
>> * none
> 
> Why do you resend then? Also v4 seems unchanged? Did you adjust the people
> in CC:? If you want to notify more people, please just reply to your own
> patch.

This is part of a patch series and there are changes in other patches
within the series. The usual workflow is to send the whole series again
even if not all patches changed. At least that's what I've always been
doing and so far no one complained. If there's a better way, please let
me know.

Thanks
Frieder

Re: [PATCH v3 3/3] doc: board: Add minimal documentation for Sielaff i.MX6 Solo board

[Frieder Schrempf]

Hi Heinrich,

thanks for your comments. I fixed all these issues in v4.

On 15.02.24 14:53, Heinrich Schuchardt wrote:
> On 15.02.24 2:35 PM, Frieder Schrempf wrote:
>> From: Frieder Schrempf 
>>
>> Describe how to build and boot for the Sielaff i.MX6 Solo board.
>>
>> Signed-off-by: Frieder Schrempf 
>> ---
>> Changes in v3:
>> * include docs in upper-level index
>>
>> Changes in v2:
>> * none
>> ---
>>   doc/board/index.rst  |  1 +
>>   doc/board/sielaff/imx6dl-sielaff.rst | 32 
>>   doc/board/sielaff/index.rst  |  9 
>>   3 files changed, 42 insertions(+)
>>   create mode 100644 doc/board/sielaff/imx6dl-sielaff.rst
>>   create mode 100644 doc/board/sielaff/index.rst
>>
>> diff --git a/doc/board/index.rst b/doc/board/index.rst
>> index d0f9f355d2e..62357c99388 100644
>> --- a/doc/board/index.rst
>> +++ b/doc/board/index.rst
>> @@ -42,6 +42,7 @@ Board-specific doc
>>  renesas/index
>>  rockchip/index
>>  samsung/index
>> +   sielaff/index
>>  siemens/index
>>  sifive/index
>>  sipeed/index
>> diff --git a/doc/board/sielaff/imx6dl-sielaff.rst
>> b/doc/board/sielaff/imx6dl-sielaff.rst
>> new file mode 100644
>> index 000..24dd67ccaef
>> --- /dev/null
>> +++ b/doc/board/sielaff/imx6dl-sielaff.rst
>> @@ -0,0 +1,32 @@
>> +.. SPDX-License-Identifier: GPL-2.0+
>> +
>> +Sielaff i.MX6 Solo Board
>> +
>> +
>> +The Sielaff i.MX6 Solo board is a control and HMI board for vending
>> +machines.
> 
> Thank you for providing the build instruction.
> 
> I had to look up the abbreviation:
> 
> %s/HMI/Human Machine Interface (HMI)/
> 
>> +
>> +Quick Start
>> +---
>> +
>> +- Build U-Boot
>> +- Boot
> 
> These lines are not needed. We have a navigation tree on the left side
> of the generated HTML page.
> 
>> +
>> +Build U-Boot
>> +
>> +
>> +.. code-block:: bash
>> +
>> +   $ make imx6dl_sielaff_defconfig
>> +   $ make CROSS_COMPILE=arm-none-linux-gnueabihf-
> 
> U-Boot does not use floats.
> 
> make CROSS_COMPILE=arm-linux-gnueabi-
> 
>> +
>> +Burn the flash.bin to SD card at an offset of 1 KiB:
> 
> Copy the flash.bin file to an SD card at an offset of 1 KiB:
> 
>> +
>> +.. code-block:: bash
>> +
>> +   $ dd if=flash.bin of=/dev/sd[x] bs=1K seek=1 conv=notrunc
> 
> Please, remove '$ '. It makes copy and paste more difficult.
> Anyway $ is the wrong prompt. Only root can use dd.
> If you really want a prompt, use:
> 
> .. prompt:: bash #
> 
> conv=notrunc has no effect on SD-cards but is needed when copying to an
> image file.

Thanks
Frieder

[PATCH v4 3/3] doc: board: Add minimal documentation for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

Describe how to build and boot for the Sielaff i.MX6 Solo board.

Signed-off-by: Frieder Schrempf 
---
Changes in v4:
* changes requested by Heinrich (thanks!)

Changes in v3:
* include docs in upper-level index

Changes in v2:
* none
---
 doc/board/index.rst  |  1 +
 doc/board/sielaff/imx6dl-sielaff.rst | 29 
 doc/board/sielaff/index.rst  |  9 +
 3 files changed, 39 insertions(+)
 create mode 100644 doc/board/sielaff/imx6dl-sielaff.rst
 create mode 100644 doc/board/sielaff/index.rst

diff --git a/doc/board/index.rst b/doc/board/index.rst
index d0f9f355d2e..62357c99388 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -42,6 +42,7 @@ Board-specific doc
renesas/index
rockchip/index
samsung/index
+   sielaff/index
siemens/index
sifive/index
sipeed/index
diff --git a/doc/board/sielaff/imx6dl-sielaff.rst 
b/doc/board/sielaff/imx6dl-sielaff.rst
new file mode 100644
index 000..699079b3271
--- /dev/null
+++ b/doc/board/sielaff/imx6dl-sielaff.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff i.MX6 Solo Board
+
+
+The Sielaff i.MX6 Solo board is a control and Human Machine Interface (HMI)
+board for vending machines.
+
+Quick Start
+---
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   make imx6dl_sielaff_defconfig
+   make CROSS_COMPILE=arm-linux-gnueabi-
+
+Copy the flash.bin file to an SD card at an offset of 1 KiB:
+
+.. code-block:: bash
+
+   dd if=flash.bin of=/dev/sd[x] bs=1K seek=1
+
+Boot
+
+
+Put the SD card in the slot on the board and apply power.
diff --git a/doc/board/sielaff/index.rst b/doc/board/sielaff/index.rst
new file mode 100644
index 000..a8376484d88
--- /dev/null
+++ b/doc/board/sielaff/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff
+===
+
+.. toctree::
+   :maxdepth: 2
+
+   imx6dl-sielaff
-- 
2.43.0

[PATCH v4 2/3] board: Add support for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

The Sielaff i.MX6 Solo board is a control and HMI board for vending
machines. Add support for this board.

The devicetree files are taken from pending changes in the Linux
kernel that are available from linux-next and will likely be
part of Linux v6.9.

Signed-off-by: Frieder Schrempf 
---
Changes in v4:
* none

Changes in v3:
* Add missing MAINTAINERS file

Changes in v2:
* Implement changes suggested by Fabio (Thanks!)
  * Fix system reset and remove unneeded cpu_reset()
  * Add 'static const' to nfc_pads[]
  * Remove hostname from env
  * Remove options to disable caches
* Enable watchdog and wdt command
* Enable LTO
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi   |  38 ++
 arch/arm/dts/imx6dl-sielaff.dts   | 533 ++
 arch/arm/mach-imx/mx6/Kconfig |  10 +
 board/sielaff/imx6dl-sielaff/Kconfig  |  15 +
 board/sielaff/imx6dl-sielaff/MAINTAINERS  |   9 +
 board/sielaff/imx6dl-sielaff/Makefile |   8 +
 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c | 111 
 .../sielaff/imx6dl-sielaff/imx6dl-sielaff.env | 114 
 board/sielaff/imx6dl-sielaff/spl.c| 273 +
 configs/imx6dl_sielaff_defconfig  | 120 
 include/configs/imx6dl-sielaff.h  |  25 +
 12 files changed, 1257 insertions(+)
 create mode 100644 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6dl-sielaff.dts
 create mode 100644 board/sielaff/imx6dl-sielaff/Kconfig
 create mode 100644 board/sielaff/imx6dl-sielaff/MAINTAINERS
 create mode 100644 board/sielaff/imx6dl-sielaff/Makefile
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
 create mode 100644 board/sielaff/imx6dl-sielaff/spl.c
 create mode 100644 configs/imx6dl_sielaff_defconfig
 create mode 100644 include/configs/imx6dl-sielaff.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0fcae77cefe..d60fa1179af 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -930,6 +930,7 @@ dtb-y += \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
+   imx6dl-sielaff.dtb \
imx6dl-wandboard-revd1.dtb \
imx6s-dhcom-drc02.dtb
 
diff --git a/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi 
b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
new file mode 100644
index 000..8f5a70ccb85
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+   binman: binman {
+   filename = "flash.bin";
+   pad-byte = <0x00>;
+
+   spl: blob-ext@1 {
+   offset = <0x0>;
+   filename = "SPL";
+   };
+
+   uboot: blob-ext@2 {
+   offset = <0x11000>;
+   filename = "u-boot.img";
+   };
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   };
+};
+
+ {
+   phy-mode = "rmii";
+   phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+   phy-reset-duration = <100>;
+};
+
+ {
+   fsl,legacy-bch-geometry;
+};
diff --git a/arch/arm/dts/imx6dl-sielaff.dts b/arch/arm/dts/imx6dl-sielaff.dts
new file mode 100644
index 000..7de8d5f2651
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff.dts
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   model = "Sielaff i.MX6 Solo";
+   compatible = "sielaff,imx6dl-board", "fsl,imx6dl";
+
+   chosen {
+   stdout-path = 
+   };
+
+   backlight: pwm-backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight>;
+   pwms = < 0 5 0>;
+   brightness-levels = <0 0 64 88 112 136 184 232 255>;
+   default-brightness-level = <4>;
+   enable-gpios = < 16 GPIO_ACTIVE_HIGH>;
+   power-supply = <_backlight>;
+   };
+
+   cec {
+   compatible = "cec-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_hdmi_cec>;
+   cec-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   hdmi-phandle = <>;
+   };
+
+   enet_ref: clock-enet-ref {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency 

[PATCH v4 1/3] mtd: spi-nor-ids: Add support for ESMT/EON EN25Q80B

[Frieder Schrempf]

From: Frieder Schrempf 

The datasheet can be found here:
https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25Q80B_Ver.E.pdf

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v4:
* none

Changes in v3:
* none

Changes in v2:
* Add R-b tag from Fabio (Thanks!)
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 38a287487ed..4e83b8c94c9 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -80,6 +80,7 @@ const struct flash_info spi_nor_ids[] = {
 #endif
 #ifdef CONFIG_SPI_FLASH_EON/* EON */
/* EON -- en25xxx */
+   { INFO("en25q80b",   0x1c3014, 0, 64 * 1024,   16, SECT_4K) },
{ INFO("en25q32b",   0x1c3016, 0, 64 * 1024,   64, 0) },
{ INFO("en25q64",0x1c3017, 0, 64 * 1024,  128, SECT_4K) },
{ INFO("en25q128b",  0x1c3018, 0, 64 * 1024,  256, 0) },
-- 
2.43.0

Re: [PATCH v2 2/3] board: Add support for Sielaff i.MX6 Solo board

[Frieder Schrempf]

On 15.02.24 13:27, Fabio Estevam wrote:
> Hi Frieder,
> 
> On Tue, Feb 13, 2024 at 2:22 PM Frieder Schrempf  wrote:
>>
>> From: Frieder Schrempf 
>>
>> The Sielaff i.MX6 Solo board is a control and HMI board for vending
>> machines. Add support for this board.
>>
>> The devicetree files are taken from pending changes in the Linux
>> kernel that are available from linux-next and will likely be
>> part of Linux v6.9.
>>
>> Signed-off-by: Frieder Schrempf 
>> ---
>> Changes in v2:
>> * Implement changes suggested by Fabio (Thanks!)
>>   * Fix system reset and remove unneeded cpu_reset()
>>   * Add 'static const' to nfc_pads[]
>>   * Remove hostname from env
>>   * Remove options to disable caches
>> * Enable watchdog and wdt command
>> * Enable LTO
> 
> I put this series in CI and it complained that there is no MAINTAINERS
> entry for this board:
> 
> https://source.denx.de/u-boot/custodians/u-boot-imx/-/jobs/784464
> 
> and there was also an issue with the documentation:
> 
> https://source.denx.de/u-boot/custodians/u-boot-imx/-/jobs/784463
> 
> Please fix these two issues and submit v3.

Oops, right. Totally forgot about these two things. I just sent out a
v3. Thanks!

[PATCH v3 3/3] doc: board: Add minimal documentation for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

Describe how to build and boot for the Sielaff i.MX6 Solo board.

Signed-off-by: Frieder Schrempf 
---
Changes in v3:
* include docs in upper-level index

Changes in v2:
* none
---
 doc/board/index.rst  |  1 +
 doc/board/sielaff/imx6dl-sielaff.rst | 32 
 doc/board/sielaff/index.rst  |  9 
 3 files changed, 42 insertions(+)
 create mode 100644 doc/board/sielaff/imx6dl-sielaff.rst
 create mode 100644 doc/board/sielaff/index.rst

diff --git a/doc/board/index.rst b/doc/board/index.rst
index d0f9f355d2e..62357c99388 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -42,6 +42,7 @@ Board-specific doc
renesas/index
rockchip/index
samsung/index
+   sielaff/index
siemens/index
sifive/index
sipeed/index
diff --git a/doc/board/sielaff/imx6dl-sielaff.rst 
b/doc/board/sielaff/imx6dl-sielaff.rst
new file mode 100644
index 000..24dd67ccaef
--- /dev/null
+++ b/doc/board/sielaff/imx6dl-sielaff.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff i.MX6 Solo Board
+
+
+The Sielaff i.MX6 Solo board is a control and HMI board for vending
+machines.
+
+Quick Start
+---
+
+- Build U-Boot
+- Boot
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   $ make imx6dl_sielaff_defconfig
+   $ make CROSS_COMPILE=arm-none-linux-gnueabihf-
+
+Burn the flash.bin to SD card at an offset of 1 KiB:
+
+.. code-block:: bash
+
+   $ dd if=flash.bin of=/dev/sd[x] bs=1K seek=1 conv=notrunc
+
+Boot
+
+
+Put the SD card in the slot on the board and apply power.
diff --git a/doc/board/sielaff/index.rst b/doc/board/sielaff/index.rst
new file mode 100644
index 000..a8376484d88
--- /dev/null
+++ b/doc/board/sielaff/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff
+===
+
+.. toctree::
+   :maxdepth: 2
+
+   imx6dl-sielaff
-- 
2.43.0

[PATCH v3 2/3] board: Add support for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

The Sielaff i.MX6 Solo board is a control and HMI board for vending
machines. Add support for this board.

The devicetree files are taken from pending changes in the Linux
kernel that are available from linux-next and will likely be
part of Linux v6.9.

Signed-off-by: Frieder Schrempf 
---
Changes in v3:
* Add missing MAINTAINERS file

Changes in v2:
* Implement changes suggested by Fabio (Thanks!)
  * Fix system reset and remove unneeded cpu_reset()
  * Add 'static const' to nfc_pads[]
  * Remove hostname from env
  * Remove options to disable caches
* Enable watchdog and wdt command
* Enable LTO
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi   |  38 ++
 arch/arm/dts/imx6dl-sielaff.dts   | 533 ++
 arch/arm/mach-imx/mx6/Kconfig |  10 +
 board/sielaff/imx6dl-sielaff/Kconfig  |  15 +
 board/sielaff/imx6dl-sielaff/MAINTAINERS  |   9 +
 board/sielaff/imx6dl-sielaff/Makefile |   8 +
 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c | 111 
 .../sielaff/imx6dl-sielaff/imx6dl-sielaff.env | 114 
 board/sielaff/imx6dl-sielaff/spl.c| 273 +
 configs/imx6dl_sielaff_defconfig  | 120 
 include/configs/imx6dl-sielaff.h  |  25 +
 12 files changed, 1257 insertions(+)
 create mode 100644 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6dl-sielaff.dts
 create mode 100644 board/sielaff/imx6dl-sielaff/Kconfig
 create mode 100644 board/sielaff/imx6dl-sielaff/MAINTAINERS
 create mode 100644 board/sielaff/imx6dl-sielaff/Makefile
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
 create mode 100644 board/sielaff/imx6dl-sielaff/spl.c
 create mode 100644 configs/imx6dl_sielaff_defconfig
 create mode 100644 include/configs/imx6dl-sielaff.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0fcae77cefe..d60fa1179af 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -930,6 +930,7 @@ dtb-y += \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
+   imx6dl-sielaff.dtb \
imx6dl-wandboard-revd1.dtb \
imx6s-dhcom-drc02.dtb
 
diff --git a/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi 
b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
new file mode 100644
index 000..8f5a70ccb85
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+   binman: binman {
+   filename = "flash.bin";
+   pad-byte = <0x00>;
+
+   spl: blob-ext@1 {
+   offset = <0x0>;
+   filename = "SPL";
+   };
+
+   uboot: blob-ext@2 {
+   offset = <0x11000>;
+   filename = "u-boot.img";
+   };
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   };
+};
+
+ {
+   phy-mode = "rmii";
+   phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+   phy-reset-duration = <100>;
+};
+
+ {
+   fsl,legacy-bch-geometry;
+};
diff --git a/arch/arm/dts/imx6dl-sielaff.dts b/arch/arm/dts/imx6dl-sielaff.dts
new file mode 100644
index 000..7de8d5f2651
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff.dts
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   model = "Sielaff i.MX6 Solo";
+   compatible = "sielaff,imx6dl-board", "fsl,imx6dl";
+
+   chosen {
+   stdout-path = 
+   };
+
+   backlight: pwm-backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight>;
+   pwms = < 0 5 0>;
+   brightness-levels = <0 0 64 88 112 136 184 232 255>;
+   default-brightness-level = <4>;
+   enable-gpios = < 16 GPIO_ACTIVE_HIGH>;
+   power-supply = <_backlight>;
+   };
+
+   cec {
+   compatible = "cec-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_hdmi_cec>;
+   cec-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   hdmi-phandle = <>;
+   };
+
+   enet_ref: clock-enet-ref {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency 

[PATCH v3 1/3] mtd: spi-nor-ids: Add support for ESMT/EON EN25Q80B

[Frieder Schrempf]

From: Frieder Schrempf 

The datasheet can be found here:
https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25Q80B_Ver.E.pdf

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v3:
* none

Changes in v2:
* Add R-b tag from Fabio (Thanks!)
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 38a287487ed..4e83b8c94c9 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -80,6 +80,7 @@ const struct flash_info spi_nor_ids[] = {
 #endif
 #ifdef CONFIG_SPI_FLASH_EON/* EON */
/* EON -- en25xxx */
+   { INFO("en25q80b",   0x1c3014, 0, 64 * 1024,   16, SECT_4K) },
{ INFO("en25q32b",   0x1c3016, 0, 64 * 1024,   64, 0) },
{ INFO("en25q64",0x1c3017, 0, 64 * 1024,  128, SECT_4K) },
{ INFO("en25q128b",  0x1c3018, 0, 64 * 1024,  256, 0) },
-- 
2.43.0

[PATCH v2 2/3] board: Add support for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

The Sielaff i.MX6 Solo board is a control and HMI board for vending
machines. Add support for this board.

The devicetree files are taken from pending changes in the Linux
kernel that are available from linux-next and will likely be
part of Linux v6.9.

Signed-off-by: Frieder Schrempf 
---
Changes in v2:
* Implement changes suggested by Fabio (Thanks!)
  * Fix system reset and remove unneeded cpu_reset()
  * Add 'static const' to nfc_pads[]
  * Remove hostname from env
  * Remove options to disable caches
* Enable watchdog and wdt command
* Enable LTO
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi   |  38 ++
 arch/arm/dts/imx6dl-sielaff.dts   | 533 ++
 arch/arm/mach-imx/mx6/Kconfig |  10 +
 board/sielaff/imx6dl-sielaff/Kconfig  |  15 +
 board/sielaff/imx6dl-sielaff/Makefile |   8 +
 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c | 111 
 .../sielaff/imx6dl-sielaff/imx6dl-sielaff.env | 114 
 board/sielaff/imx6dl-sielaff/spl.c| 273 +
 configs/imx6dl_sielaff_defconfig  | 120 
 include/configs/imx6dl-sielaff.h  |  25 +
 11 files changed, 1248 insertions(+)
 create mode 100644 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6dl-sielaff.dts
 create mode 100644 board/sielaff/imx6dl-sielaff/Kconfig
 create mode 100644 board/sielaff/imx6dl-sielaff/Makefile
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
 create mode 100644 board/sielaff/imx6dl-sielaff/spl.c
 create mode 100644 configs/imx6dl_sielaff_defconfig
 create mode 100644 include/configs/imx6dl-sielaff.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0fcae77cefe..d60fa1179af 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -930,6 +930,7 @@ dtb-y += \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
+   imx6dl-sielaff.dtb \
imx6dl-wandboard-revd1.dtb \
imx6s-dhcom-drc02.dtb
 
diff --git a/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi 
b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
new file mode 100644
index 000..8f5a70ccb85
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+   binman: binman {
+   filename = "flash.bin";
+   pad-byte = <0x00>;
+
+   spl: blob-ext@1 {
+   offset = <0x0>;
+   filename = "SPL";
+   };
+
+   uboot: blob-ext@2 {
+   offset = <0x11000>;
+   filename = "u-boot.img";
+   };
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   };
+};
+
+ {
+   phy-mode = "rmii";
+   phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+   phy-reset-duration = <100>;
+};
+
+ {
+   fsl,legacy-bch-geometry;
+};
diff --git a/arch/arm/dts/imx6dl-sielaff.dts b/arch/arm/dts/imx6dl-sielaff.dts
new file mode 100644
index 000..7de8d5f2651
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff.dts
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   model = "Sielaff i.MX6 Solo";
+   compatible = "sielaff,imx6dl-board", "fsl,imx6dl";
+
+   chosen {
+   stdout-path = 
+   };
+
+   backlight: pwm-backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight>;
+   pwms = < 0 5 0>;
+   brightness-levels = <0 0 64 88 112 136 184 232 255>;
+   default-brightness-level = <4>;
+   enable-gpios = < 16 GPIO_ACTIVE_HIGH>;
+   power-supply = <_backlight>;
+   };
+
+   cec {
+   compatible = "cec-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_hdmi_cec>;
+   cec-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   hdmi-phandle = <>;
+   };
+
+   enet_ref: clock-enet-ref {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   clock-output-names = "enet-ref";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+ 

[PATCH v2 3/3] doc: board: Add minimal documentation for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

Describe how to build and boot for the Sielaff i.MX6 Solo board.

Signed-off-by: Frieder Schrempf 
---
Changes in v2:
* none
---
 doc/board/sielaff/imx6dl-sielaff.rst | 32 
 doc/board/sielaff/index.rst  |  9 
 2 files changed, 41 insertions(+)
 create mode 100644 doc/board/sielaff/imx6dl-sielaff.rst
 create mode 100644 doc/board/sielaff/index.rst

diff --git a/doc/board/sielaff/imx6dl-sielaff.rst 
b/doc/board/sielaff/imx6dl-sielaff.rst
new file mode 100644
index 000..24dd67ccaef
--- /dev/null
+++ b/doc/board/sielaff/imx6dl-sielaff.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff i.MX6 Solo Board
+
+
+The Sielaff i.MX6 Solo board is a control and HMI board for vending
+machines.
+
+Quick Start
+---
+
+- Build U-Boot
+- Boot
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   $ make imx6dl_sielaff_defconfig
+   $ make CROSS_COMPILE=arm-none-linux-gnueabihf-
+
+Burn the flash.bin to SD card at an offset of 1 KiB:
+
+.. code-block:: bash
+
+   $ dd if=flash.bin of=/dev/sd[x] bs=1K seek=1 conv=notrunc
+
+Boot
+
+
+Put the SD card in the slot on the board and apply power.
diff --git a/doc/board/sielaff/index.rst b/doc/board/sielaff/index.rst
new file mode 100644
index 000..a8376484d88
--- /dev/null
+++ b/doc/board/sielaff/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff
+===
+
+.. toctree::
+   :maxdepth: 2
+
+   imx6dl-sielaff
-- 
2.43.0

[PATCH v2 1/3] mtd: spi-nor-ids: Add support for ESMT/EON EN25Q80B

[Frieder Schrempf]

From: Frieder Schrempf 

The datasheet can be found here:
https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25Q80B_Ver.E.pdf

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v2:
* Add R-b tag from Fabio (Thanks!)
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 38a287487ed..4e83b8c94c9 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -80,6 +80,7 @@ const struct flash_info spi_nor_ids[] = {
 #endif
 #ifdef CONFIG_SPI_FLASH_EON/* EON */
/* EON -- en25xxx */
+   { INFO("en25q80b",   0x1c3014, 0, 64 * 1024,   16, SECT_4K) },
{ INFO("en25q32b",   0x1c3016, 0, 64 * 1024,   64, 0) },
{ INFO("en25q64",0x1c3017, 0, 64 * 1024,  128, SECT_4K) },
{ INFO("en25q128b",  0x1c3018, 0, 64 * 1024,  256, 0) },
-- 
2.43.0

Re: [PATCH 2/3] board: Add support for Sielaff i.MX6 Solo board

[Frieder Schrempf]

Hi Fabio,

thanks for reviewing!

On 10.02.24 19:12, Fabio Estevam wrote:
> Hi Frieder,
> 
> On Thu, Feb 8, 2024 at 1:59 PM Frieder Schrempf  wrote:
> 
>> +/ {
>> +   binman: binman {
>> +   filename = "flash.bin";
>> +   pad-byte = <0x00>;
>> +
>> +   spl: blob-ext@1 {
>> +   offset = <0x0>;
>> +   filename = "SPL";
>> +   };
>> +
>> +   uboot: blob-ext@2 {
>> +   offset = <0x11000>;
>> +   filename = "u-boot.img";
>> +   };
>> +   };
> 
> As mentioned in patch 3/3, please remove the binman entry and use
> u-boot-with-spl.imx instead.

I understand the reasoning and I can change that if you insist. But I'm
not really happy about it as we already use the flash.bin as common name
for the binary across all platforms downstream. Also in our upstream
config for the i.MX6UL/ULL SoMs we already use this pattern (see [1]).

> 
>> +config TARGET_MX6S_SIELAFF
>> +   bool "Sielaff i.MX6 Solo Board"
>> +   depends on MX6S
>> +   select BINMAN
> 
> Please drop it.
> 
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +iomux_v3_cfg_t nfc_pads[] = {
> 
> Make it static.

OK

> 
>> --- /dev/null
>> +++ b/board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
>> @@ -0,0 +1,115 @@
>> +blkloadfdt=fatload ${device} ${devnum}:${partnum} ${fdt_addr} 
>> ${load_fdt_file}
>> +blkloadimage=fatload ${device} ${devnum}:${partnum} ${loadaddr} 
>> ${load_image}
>> +boot_devices=usb mmc ubi
>> +bootargs_base=vt.global_cursor_default=0 consoleblank=0 cma=200M 
>> fbcon=rotate:1
>> +bootdelay=3
>> +bootdir=
>> +console=ttymxc1,115200
>> +ethact=FEC0
>> +fdt_addr=0x1800
>> +fdt_file_legacy=imx6dl_sielaff.dtb
>> +fdt_file=imx6dl-sielaff.dtb
>> +fdt_high=0x
>> +hostname=mx6s-siline-hmi
> 
> Please remove it.

OK

> 
>> +void reset_cpu(void)
>> +{
>> +}
> 
> Is this needed?

No, I will drop it.

> Does the 'reset' command work on this board?

No, I will fix it.

>> +++ b/configs/imx6dl_sielaff_defconfig
>> @@ -0,0 +1,117 @@
>> +CONFIG_ARM=y
>> +CONFIG_SPL_SYS_ICACHE_OFF=y
>> +CONFIG_SPL_SYS_DCACHE_OFF=y
> 
> These options should be dropped.

OK

> 
>> +#include 
>> +#include 
>> +#include "mx6_common.h"
>> +
>> +#define CFG_MXC_UART_BASE  UART2_BASE
> 
> As you use DM_SERIAL, this can be dropped.

This is still needed as SPL runs without DM due to internal RAM size
constraints.

Thanks
Frieder

[1]
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx6ul-kontron-bl-common-u-boot.dtsi#L10

[PATCH 3/3] doc: board: Add minimal documentation for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

Describe how to build and boot for the Sielaff i.MX6 Solo board.

Signed-off-by: Frieder Schrempf 
---
 doc/board/sielaff/imx6dl-sielaff.rst | 32 
 doc/board/sielaff/index.rst  |  9 
 2 files changed, 41 insertions(+)
 create mode 100644 doc/board/sielaff/imx6dl-sielaff.rst
 create mode 100644 doc/board/sielaff/index.rst

diff --git a/doc/board/sielaff/imx6dl-sielaff.rst 
b/doc/board/sielaff/imx6dl-sielaff.rst
new file mode 100644
index 000..24dd67ccaef
--- /dev/null
+++ b/doc/board/sielaff/imx6dl-sielaff.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff i.MX6 Solo Board
+
+
+The Sielaff i.MX6 Solo board is a control and HMI board for vending
+machines.
+
+Quick Start
+---
+
+- Build U-Boot
+- Boot
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   $ make imx6dl_sielaff_defconfig
+   $ make CROSS_COMPILE=arm-none-linux-gnueabihf-
+
+Burn the flash.bin to SD card at an offset of 1 KiB:
+
+.. code-block:: bash
+
+   $ dd if=flash.bin of=/dev/sd[x] bs=1K seek=1 conv=notrunc
+
+Boot
+
+
+Put the SD card in the slot on the board and apply power.
diff --git a/doc/board/sielaff/index.rst b/doc/board/sielaff/index.rst
new file mode 100644
index 000..a8376484d88
--- /dev/null
+++ b/doc/board/sielaff/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sielaff
+===
+
+.. toctree::
+   :maxdepth: 2
+
+   imx6dl-sielaff
-- 
2.43.0

[PATCH 2/3] board: Add support for Sielaff i.MX6 Solo board

[Frieder Schrempf]

From: Frieder Schrempf 

The Sielaff i.MX6 Solo board is a control and HMI board for vending
machines. Add support for this board.

The devicetree files are taken from pending changes in the Linux
kernel that are available from linux-next and will likely be
part of Linux v6.9.

Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi   |  33 ++
 arch/arm/dts/imx6dl-sielaff.dts   | 533 ++
 arch/arm/mach-imx/mx6/Kconfig |  10 +
 board/sielaff/imx6dl-sielaff/Kconfig  |  15 +
 board/sielaff/imx6dl-sielaff/Makefile |   8 +
 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c | 111 
 .../sielaff/imx6dl-sielaff/imx6dl-sielaff.env | 115 
 board/sielaff/imx6dl-sielaff/spl.c| 277 +
 configs/imx6dl_sielaff_defconfig  | 117 
 include/configs/imx6dl-sielaff.h  |  25 +
 11 files changed, 1245 insertions(+)
 create mode 100644 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6dl-sielaff.dts
 create mode 100644 board/sielaff/imx6dl-sielaff/Kconfig
 create mode 100644 board/sielaff/imx6dl-sielaff/Makefile
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c
 create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
 create mode 100644 board/sielaff/imx6dl-sielaff/spl.c
 create mode 100644 configs/imx6dl_sielaff_defconfig
 create mode 100644 include/configs/imx6dl-sielaff.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0fcae77cefe..d60fa1179af 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -930,6 +930,7 @@ dtb-y += \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
+   imx6dl-sielaff.dtb \
imx6dl-wandboard-revd1.dtb \
imx6s-dhcom-drc02.dtb
 
diff --git a/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi 
b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
new file mode 100644
index 000..47f4c499031
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+   binman: binman {
+   filename = "flash.bin";
+   pad-byte = <0x00>;
+
+   spl: blob-ext@1 {
+   offset = <0x0>;
+   filename = "SPL";
+   };
+
+   uboot: blob-ext@2 {
+   offset = <0x11000>;
+   filename = "u-boot.img";
+   };
+   };
+};
+
+ {
+   phy-mode = "rmii";
+   phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+   phy-reset-duration = <100>;
+};
+
+ {
+   fsl,legacy-bch-geometry;
+};
diff --git a/arch/arm/dts/imx6dl-sielaff.dts b/arch/arm/dts/imx6dl-sielaff.dts
new file mode 100644
index 000..7de8d5f2651
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff.dts
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   model = "Sielaff i.MX6 Solo";
+   compatible = "sielaff,imx6dl-board", "fsl,imx6dl";
+
+   chosen {
+   stdout-path = 
+   };
+
+   backlight: pwm-backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight>;
+   pwms = < 0 5 0>;
+   brightness-levels = <0 0 64 88 112 136 184 232 255>;
+   default-brightness-level = <4>;
+   enable-gpios = < 16 GPIO_ACTIVE_HIGH>;
+   power-supply = <_backlight>;
+   };
+
+   cec {
+   compatible = "cec-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_hdmi_cec>;
+   cec-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   hdmi-phandle = <>;
+   };
+
+   enet_ref: clock-enet-ref {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   clock-output-names = "enet-ref";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_keys>;
+
+   key-0 {
+   gpios = < 16 0>;
+   debounce-interval = <10>;
+   linux,code = <1>;
+   };
+
+   key-1 {
+   gpios = < 27 0>;
+   debounce-interval = &l

[PATCH 1/3] mtd: spi-nor-ids: Add support for ESMT/EON EN25Q80B

[Frieder Schrempf]

From: Frieder Schrempf 

The datasheet can be found here:
https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25Q80B_Ver.E.pdf

Signed-off-by: Frieder Schrempf 
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 38a287487ed..4e83b8c94c9 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -80,6 +80,7 @@ const struct flash_info spi_nor_ids[] = {
 #endif
 #ifdef CONFIG_SPI_FLASH_EON/* EON */
/* EON -- en25xxx */
+   { INFO("en25q80b",   0x1c3014, 0, 64 * 1024,   16, SECT_4K) },
{ INFO("en25q32b",   0x1c3016, 0, 64 * 1024,   64, 0) },
{ INFO("en25q64",0x1c3017, 0, 64 * 1024,  128, SECT_4K) },
{ INFO("en25q128b",  0x1c3018, 0, 64 * 1024,  256, 0) },
-- 
2.43.0

Re: [PATCH v2 1/1] mtd: spinand: add support for ESMT F50x1G41LB

[Frieder Schrempf]

On 17.10.23 21:29, Igor Prusov wrote:
> Adaptation of Linux commit d74c36480a67
> 
> This patch adds support for ESMT F50L1G41LB and F50D1G41LB.
> It seems that ESMT likes to use random JEDEC ID from other vendors.
> Their 1G chips uses 0xc8 from GigaDevice and 2G/4G chips uses 0x2c from
> Micron. For this reason, the ESMT entry is named esmt_c8 with explicit
> JEDEC ID in variable name.
> 
> Datasheets:
> https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50L1G41LB(2M).pdf
> https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50D1G41LB(2M).pdf
> 
> Signed-off-by: Igor Prusov 
> Signed-off-by: Chuanhong Guo 
> Signed-off-by: Martin Kurbanov 
> Signed-off-by: Dmitry Rokosov 
> Tested-by: Martin Kurbanov 

Reviewed-by: Frieder Schrempf 

Re: [PATCH v1 1/2] mtd: spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

On 04.10.23 17:07, Igor Prusov wrote:
> Adaptation of Linux commit f1541773af49.
> 
> Currently there are 3 different variants of read_id implementation:
> 1. opcode only. Found in GD5FxGQ4xF.
> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> 3. opcode + 1 dummy byte. Found in other currently supported chips.
> 
> Original implementation was for variant 1 and let detect function
> of chips with variant 2 and 3 to ignore the first byte. This isn't
> robust:
> 
> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> during read, chip will get a random id offset, and the entire id
> buffer will shift by that offset, causing detect failure.
> 
> 2. For chips of variant 1, if it happens to get a devid that equals
> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
> detected.
> 
> This patch reworks detect procedure to address problems above. New
> logic do detection for all variants separatedly, in 1-2-3 order.
> Since all current detect methods do exactly the same id matching
> procedure, unify them into core.c and remove detect method from
> manufacture_ops.
> 
> Signed-off-by: Chuanhong Guo 
> Signed-off-by: Igor Prusov 

An adaptation of this patch was already sent long ago [1] and Dario also
picked it up in nand-next [2]. Though it looks like this was never
merged upstream as there wasn't any pull request sent to Tom, right?

Dario, as you already seem to have rebased nand-next recently, can you
please sent the changes to Tom for picking them up? As the merge window
is open at the moment it would be good to get it done soon. Thanks!

[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230110115843.391630-1-frie...@fris.de/
[2]
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/commits/nand-next/

Re: [RFC PATCH] env: Export environment config to OS devicetree

[Frieder Schrempf]

Hi Simon, hi Stefano,

On 04.08.23 15:39, Stefano Babic wrote:
> Hi Simon,
> 
> On 04.08.23 05:42, Simon Glass wrote:
>> Hi,
>>
>> On Thu, 3 Aug 2023 at 07:21, Stefano Babic  wrote:
>>>
>>> Hi Frieder,
>>>
>>> On 03.08.23 14:51, Frieder Schrempf wrote:
>>>> Hi Stefano,
>>>>
>>>> On 03.08.23 10:14, Stefano Babic wrote:
>>>>> Hi Frieder,
>>>>>
>>>>> On 01.08.23 16:46, Frieder Schrempf wrote:
>>>>>> From: Frieder Schrempf 
>>>>>>
>>>>>> There are plenty of cases where the OS wants to know where the
>>>>>> persistent environment is stored in order to print or manipulate it.
>>>>>>
>>>>>> In most cases a userspace tool like libubootenv [1] is used to handle
>>>>>> the environment. It uses hardcoded settings in a config file in the
>>>>>> rootfs to determine the exact location of the environment.
>>>>>>
>>>>>
>>>>> ...or the configuration file is generated, or it is located on a rw
>>>>> (overlayfs) partition.
>>>>>
>>>>>> In order to make systems more flexible and let userspace tools
>>>>>> detect the location of the environment currently in use, let's
>>>>>> add an option to export the runtime configuration to the FDT passed
>>>>>> to the OS.
>>>>>>> This is especially useful when your device is able to use multiple
>>>>>> locations for the environment and the rootfs containing the
>>>>>> fw_env.config file should be kept universal.
>>>>>
>>>>> Ok
>>>>>
>>>>> One possible issue is there is a hard dependency between the
>>>>> properties
>>>>> set in DT and the user space tool. The tool in user space is bound to
>>>>> the list of properties, and changes / extensions for the user tool
>>>>> requires changes in DT semantics (which properties, their path, etc).
>>>>>
>>>>> The same hard dependency is set by fw_env.config with its strong
>>>>> hardcoded and position dependent syntax. This one of the reason I
>>>>> introduced YAML support in libubootenv, so that the user tool is
>>>>> independent and can add own properties.
>>>>>
>>>>> I am just asking if this use case requires a new interface, or it is
>>>>> already available in some way. I mean, the configuration is YAML
>>>>> instead
>>>>> of fw_env.config and contains multiple setup ("namespaces"), like:
>>>>>
>>>>> mmc:
>>>>>     size : 0x10
>>>>>     lockfile : /var/lock/fw_printenv.lock
>>>>>     devices:
>>>>>   - path : /dev/mmcblk0boot0
>>>>>     offset : 0x1E
>>>>>     sectorsize : 0x10
>>>>>   - path : /dev/mmcblk0boot0
>>>>>     offset : 0x1E
>>>>>     sectorsize : 0x10
>>>>> spi:
>>>>>     size : 0x10
>>>>>     lockfile : /var/lock/fw_printenv.lock
>>>>>     devices:
>>>>>   - path : /dev/mtd0
>>>>>     offset : 0x1E
>>>>>     sectorsize : 0x10
>>>>>   - path : /dev/mtd0
>>>>>     offset : 0x1F
>>>>>     sectorsize : 0x10
>>>>>
>>>>> This configuration file can safely stored in your common rootfs and
>>>>> covers all possible storage for environment. It does not cover
>>>>> "runtime"
>>>>> changes, but well, I do not think this is a use case.
>>>>>
>>>>> An advantage here is that new options, useful for the User Space tool,
>>>>> can be simply introduced for the tool without the need to synchronize
>>>>> with DT spec and U-Boot.
>>>>>
>>>>> A mapping between location index and device path is not required. What
>>>>> is still required is a selector, and this can be implemented in DT
>>>>> or as
>>>>> kernel parameter.
>>>>>
>>>>> Does this already cover your use case or do we need the
>>>>> introduction of
>>>>> this new interface ?
>>>>

Re: [RFC PATCH] env: Export environment config to OS devicetree

[Frieder Schrempf]

Hi Stefano,

On 03.08.23 10:14, Stefano Babic wrote:
> Hi Frieder,
> 
> On 01.08.23 16:46, Frieder Schrempf wrote:
>> From: Frieder Schrempf 
>>
>> There are plenty of cases where the OS wants to know where the
>> persistent environment is stored in order to print or manipulate it.
>>
>> In most cases a userspace tool like libubootenv [1] is used to handle
>> the environment. It uses hardcoded settings in a config file in the
>> rootfs to determine the exact location of the environment.
>>
> 
> ...or the configuration file is generated, or it is located on a rw
> (overlayfs) partition.
> 
>> In order to make systems more flexible and let userspace tools
>> detect the location of the environment currently in use, let's
>> add an option to export the runtime configuration to the FDT passed
>> to the OS.
>> > This is especially useful when your device is able to use multiple
>> locations for the environment and the rootfs containing the
>> fw_env.config file should be kept universal.
> 
> Ok
> 
> One possible issue is there is a hard dependency between the properties
> set in DT and the user space tool. The tool in user space is bound to
> the list of properties, and changes / extensions for the user tool
> requires changes in DT semantics (which properties, their path, etc).
> 
> The same hard dependency is set by fw_env.config with its strong
> hardcoded and position dependent syntax. This one of the reason I
> introduced YAML support in libubootenv, so that the user tool is
> independent and can add own properties.
> 
> I am just asking if this use case requires a new interface, or it is
> already available in some way. I mean, the configuration is YAML instead
> of fw_env.config and contains multiple setup ("namespaces"), like:
> 
> mmc:
>   size : 0x10
>   lockfile : /var/lock/fw_printenv.lock
>   devices:
>     - path : /dev/mmcblk0boot0
>   offset : 0x1E
>   sectorsize : 0x10
>     - path : /dev/mmcblk0boot0
>   offset : 0x1E
>   sectorsize : 0x10
> spi:
>   size : 0x10
>   lockfile : /var/lock/fw_printenv.lock
>   devices:
>     - path : /dev/mtd0
>   offset : 0x1E
>   sectorsize : 0x10
>     - path : /dev/mtd0
>   offset : 0x1F
>   sectorsize : 0x10
> 
> This configuration file can safely stored in your common rootfs and
> covers all possible storage for environment. It does not cover "runtime"
> changes, but well, I do not think this is a use case.
> 
> An advantage here is that new options, useful for the User Space tool,
> can be simply introduced for the tool without the need to synchronize
> with DT spec and U-Boot.
> 
> A mapping between location index and device path is not required. What
> is still required is a selector, and this can be implemented in DT or as
> kernel parameter.
> 
> Does this already cover your use case or do we need the introduction of
> this new interface ?

Thanks for the feedback! I've seen the YAML configuration feature in
libubootenv but I missed the fact, that it already supports something
like the namespace parameter for selecting different configurations.

Indeed this would solve one part of the issue. And yes, I think we could
use the DT or a kernel parameter to pass a selector from U-Boot to
userspace.

Do you think we could add something to libubootenv to automatically
select the default namespace based on some DT property or kernel parameter?

If yes, I think this would be a viable solution for me.

> 
>>
>> Currently the general information like location/type, size, offset
>> and redundancy are exported. Userspace tools might already be able
>> to guess the correct device to access based on this information.
>>
>> For further device-specific information two additional properties
>> 'id1' and 'id2' are used. The current implementation uses them for
>> MMC and SPI FLASH like this:
>>
>> | Type   | id1    | id2    |
>> | -- | -- | -- |
>> | MMC    | MMC device index in U-Boot | MMC hwpart index in U-Boot |
>> | SPI FLASH  | SPI bus index in U-Boot    | SPI CS index in U-Boot |
>>
>> Further extensions for other environment devices are possible.
>>
>> We add the necessary information to the '/chosen' node. The following
>> shows two examples:
>>
>> Redundant environment in MMC:
>>
>>    /chosen {
>>  u-boot,env-config {
>>    location = <5>;  # according to 'enum env_location'
>>    offset = <0x1E>

[RFC PATCH] env: Export environment config to OS devicetree

[Frieder Schrempf]

From: Frieder Schrempf 

There are plenty of cases where the OS wants to know where the
persistent environment is stored in order to print or manipulate it.

In most cases a userspace tool like libubootenv [1] is used to handle
the environment. It uses hardcoded settings in a config file in the
rootfs to determine the exact location of the environment.

In order to make systems more flexible and let userspace tools
detect the location of the environment currently in use, let's
add an option to export the runtime configuration to the FDT passed
to the OS.

This is especially useful when your device is able to use multiple
locations for the environment and the rootfs containing the
fw_env.config file should be kept universal.

Currently the general information like location/type, size, offset
and redundancy are exported. Userspace tools might already be able
to guess the correct device to access based on this information.

For further device-specific information two additional properties
'id1' and 'id2' are used. The current implementation uses them for
MMC and SPI FLASH like this:

| Type   | id1| id2|
| -- | -- | -- |
| MMC| MMC device index in U-Boot | MMC hwpart index in U-Boot |
| SPI FLASH  | SPI bus index in U-Boot| SPI CS index in U-Boot |

Further extensions for other environment devices are possible.

We add the necessary information to the '/chosen' node. The following
shows two examples:

Redundant environment in MMC:

  /chosen {
u-boot,env-config {
  location = <5>;  # according to 'enum env_location'
  offset = <0x1E>;
  size = <0x10>;
  sect_size = <0x10>;
  id1 = <1>;   # MMC device index
  id2 = <0>;   # MMC HW partition index
};
u-boot,env-redund-config {
  offset = <0x1F>;
};
  };

Redundant environment in SPI NOR:

  /chosen {
u-boot,env-config {
  location = <10>; # according to 'enum env_location'
  offset = <0x1E>;
  size = <0x10>;
  sect_size = <0x10>;
  id1 = <0>;   # SPI bus
  id2 = <0>;   # SPI CS
};
u-boot,env-redund-config {
  offset = <0x1F>;
};
  };

See [2] for an example parser implementation for libubootenv.

[1] https://github.com/sbabic/libubootenv
[2] 
https://github.com/fschrempf/libubootenv/commit/726a7ac9b1b1020354ee8fe750f4cad3df01f5e7

Cc: Stefano Babic 
Cc: Michael Walle 
Signed-off-by: Frieder Schrempf 
---
 boot/Kconfig |  9 
 boot/image-fdt.c |  8 
 env/env.c| 53 
 include/env.h|  4 
 4 files changed, 74 insertions(+)

diff --git a/boot/Kconfig b/boot/Kconfig
index e8fb03b801..16a94f9b35 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -702,6 +702,15 @@ config OF_BOARD_SETUP
  board-specific information in the device tree for use by the OS.
  The device tree is then passed to the OS.
 
+config OF_EXPORT_ENV_CONFIG
+   bool "Export environment config to device tree before boot"
+   depends on OF_LIBFDT
+   help
+ This causes U-Boot to call fdt_environment_config() before booting 
into
+ the operating system. This function exports the currently in use
+ environemnt configuration to the "chosen" node of the fdt. This allows
+ the OS to determine where the environment is located.
+
 config OF_SYSTEM_SETUP
bool "Set up system-specific details in device tree before boot"
depends on OF_LIBFDT
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index f10200f647..c02c8f33ef 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -643,6 +643,14 @@ int image_setup_libfdt(struct bootm_headers *images, void 
*blob,
/* Append PStore configuration */
fdt_fixup_pstore(blob);
 #endif
+   if (IS_ENABLED(CONFIG_OF_EXPORT_ENV_CONFIG)) {
+   fdt_ret = fdt_environment_config(blob);
+   if (fdt_ret) {
+   printf("ERROR: environment config fdt fixup failed: 
%s\n",
+  fdt_strerror(fdt_ret));
+   goto err;
+   }
+   }
if (IS_ENABLED(CONFIG_OF_BOARD_SETUP)) {
const char *skip_board_fixup;
 
diff --git a/env/env.c b/env/env.c
index 2aa52c98f8..a640977205 100644
--- a/env/env.c
+++ b/env/env.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -156,6 +157,58 @@ __weak enum env_location env_get_location(enum 
env_operation op, int prio)
return arch_env_get_location(op, prio);
 }
 
+#ifdef CONFIG_OF_EXPORT_ENV_CONFIG
+int fdt_environment_config(void *blob)
+{
+   struct mm

Re: [PATCH 00/30] imx: misc update and fix

[Frieder Schrempf]

On 02.06.23 08:45, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> This patchset includes some misc update and fix from NXP downstream
>  - i.MX8 SCU API usage correction
>  - Use ELE(EdgeLockSecure Enclave) public from NXP to replace S400 or Sentinel
>  - Secondary container support and header checking fix
>  - New ELE API to support secure fuse and lifecycle and DEK Blob
>  - Bootaux: update macro and support i.MX8
>  - i.MX8 AHAB code clean up to reuse common code
>  - ELE MU update
> 
> CI: 
> https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/16469
> 
> Clement Faure (1):
>   imx: cmd_dek: add ELE DEK Blob generation support
> 
> Gaurav Jain (1):
>   imx: imx8: ahab: sha256: enable image verification using ARMv8 crypto
> extension
> 
> Maximus Sun (1):
>   imx: priblob: Update to use structure
> 
> Nitin Garg (1):
>   imx: parse-container: Use malloc for container processing
> 
> Peng Fan (17):
>   imx: mach: correct SCU API usage
>   imx: toradex/apalis-imx8: correct SCU API usage
>   imx: toradex/colibri-imx8x: correct SCU API usage
>   imx: siemens/capricorn: correct SCU API usage
>   imx: advantech: correct SCU API usage
>   imx: congatec/cgtqmx8: correct SCU API usage
>   imx: scu_api: update to version 1.16 and add more APIs
>   imx: use generic name ele(EdgeLockSecure Enclave)
>   imx: parse-container: fix build warning
>   imx: ele_ahab: use hextoul
>   imx: ele_api: support program secure fuse and return lifecycle
>   imx: ele_api: add DEK Blob generation
>   imx: imx8ulp: start the ELE RNG at boot
>   imx: iamge-container: support secondary container
>   imx: bootaux: change names of MACROs used to boot MCU on iMX devices
>   imx: imx8m: clock: not configure reserved SRC register
>   imx: imx8m: add CAAM_BASE_ADDR
> 
> Utkarsh Gupta (1):
>   imx: fsl_sec: preprocessor casting issue with addresses involving math
> 
> Ye Li (8):
>   imx: cmd_dek: Fix Uninitialized pointer read
>   imx: misc: ele_mu: Update MU TR registers count
>   imx: misc: ele_mu: Update ELE MU driver
>   imx: hab: Fix coverity issue in HAB event decoding
>   imx: image-container: Fix container header checking
>   imx: bootaux: Fix bootaux issue when running on ARM64
>   imx: imx8: bootaux: Add i.MX8 M4 boot support
>   imx: ahab: Update AHAB for iMX8 and iMX8ULP
> 
>  arch/arm/Kconfig  |   4 +-
>  arch/arm/include/asm/arch-imx8m/imx-regs.h|   3 +-
>  arch/arm/include/asm/arch-imx9/ccm_regs.h |   2 +-
>  arch/arm/include/asm/arch-mx6/imx-regs.h  |   2 +-
>  arch/arm/include/asm/arch-mx7/imx-regs.h  |   2 +-
>  arch/arm/include/asm/global_data.h|   4 +-
>  arch/arm/include/asm/mach-imx/ahab.h  |  15 +
>  .../asm/mach-imx/{s400_api.h => ele_api.h}|  53 +--
>  arch/arm/include/asm/mach-imx/sys_proto.h |   1 +
>  arch/arm/mach-imx/Kconfig |   9 +-
>  arch/arm/mach-imx/Makefile|   5 +
>  arch/arm/mach-imx/cmd_dek.c   |  89 -
>  arch/arm/mach-imx/ele_ahab.c  |  91 -
>  arch/arm/mach-imx/hab.c   |  41 ++-
>  arch/arm/mach-imx/image-container.c   |  96 -
>  arch/arm/mach-imx/imx8/ahab.c | 161 ++---
>  arch/arm/mach-imx/imx8/cpu.c  | 180 +-
>  arch/arm/mach-imx/imx8/fdt.c  |   2 +-
>  arch/arm/mach-imx/imx8/snvs_security_sc.c | 175 +
>  arch/arm/mach-imx/imx8m/clock_imx8mm.c|   1 -
>  arch/arm/mach-imx/imx8ulp/Makefile|   1 -
>  arch/arm/mach-imx/imx8ulp/rdc.c   |  18 +-
>  arch/arm/mach-imx/imx8ulp/soc.c   |  16 +-
>  arch/arm/mach-imx/imx8ulp/upower/upower_hal.c |   6 +-
>  arch/arm/mach-imx/imx9/clock.c|   8 +-
>  arch/arm/mach-imx/imx9/clock_root.c   |   2 +-
>  arch/arm/mach-imx/imx9/imx_bootaux.c  |   6 +-
>  arch/arm/mach-imx/imx9/soc.c  |  16 +-
>  arch/arm/mach-imx/imx9/trdc.c |  14 +-
>  arch/arm/mach-imx/imx_bootaux.c   |  45 ++-
>  arch/arm/mach-imx/parse-container.c   | 119 ++-
>  arch/arm/mach-imx/priblob.c   |  10 +-
>  board/advantech/imx8qm_dmsse20_a1/spl.c   |   6 +-
>  board/advantech/imx8qm_rom7720_a1/spl.c   |   6 +-
>  board/congatec/cgtqmx8/cgtqmx8.c  |   8 +-
>  board/freescale/imx8ulp_evk/spl.c |  20 +-
>  board/freescale/imx93_evk/spl.c   |   1 -
>  board/kontron/sl-mx8mm/sl-mx8mm.c |   2 +-
>  board/kontron/sl-mx8mm/spl.c  |   2 +-

The summary mentions changes to board files that I'm maintaining here,
but looking through the 30 patches I don't see any changes to these
files. Also I'm not Cc'ed anywhere.

Am I missing something? Are the cover letter stats broken?

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

On 31.05.23 14:58, Dario Binacchi wrote:
> Hi Frieder, All
> 
> On Wed, May 31, 2023 at 12:58 PM Frieder Schrempf
>  wrote:
>>
>> On 17.05.23 09:43, Frieder Schrempf wrote:
>>> Hi Michael, hi Dario,
>>>
>>> On 15.05.23 23:33, Michael Nazzareno Trimarchi wrote:
>>>> Hi
>>>>
>>>> Il lun 15 mag 2023, 23:12 Tom Rini >>> <mailto:tr...@konsulko.com>> ha scritto:
>>>>
>>>> On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote:
>>>> > Hi Michael, hi Dario,
>>>> >
>>>> > On 18.04.23 15:46, Frieder Schrempf wrote:
>>>> > > Hi Michael, Dario,
>>>> > >
>>>> > > On 28.03.23 09:57, Frieder Schrempf wrote:
>>>> > >> Hi Michael,
>>>> > >>
>>>> > >> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
>>>> > >>> Hi
>>>> > >>>
>>>> > >>> I will review
>>>> > >>>
>>>> > >>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini >>> <mailto:tr...@konsulko.com>> wrote:
>>>> > >>>>
>>>> > >>>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf 
>>>> wrote:
>>>> > >>>>> Hi,
>>>> > >>>>>
>>>> > >>>>> On 10.01.23 12:58, Frieder Schrempf wrote:
>>>> > >>>>>> From: Mikhail Kshevetskiy >>> <mailto:mikhail.kshevets...@iopsys.eu>>
>>>> > >>>>>>
>>>> > >>>>>> Currently there are 3 different variants of read_id
>>>> implementation:
>>>> > >>>>>> 1. opcode only. Found in GD5FxGQ4xF.
>>>> > >>>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>>>> > >>>>>> 3. opcode + 1 dummy byte. Found in other currently
>>>> supported chips.
>>>> > >>>>>>
>>>> > >>>>>> Original implementation was for variant 1 and let detect
>>>> function
>>>> > >>>>>> of chips with variant 2 and 3 to ignore the first byte.
>>>> This isn't
>>>> > >>>>>> robust:
>>>> > >>>>>>
>>>> > >>>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>>>> > >>>>>> during read, chip will get a random id offset, and the
>>>> entire id
>>>> > >>>>>> buffer will shift by that offset, causing detect failure.
>>>> > >>>>>>
>>>> > >>>>>> 2. For chips of variant 1, if it happens to get a devid
>>>> that equals
>>>> > >>>>>> to manufacture id of variant 2 or 3 chips, it'll get
>>>> incorrectly
>>>> > >>>>>> detected.
>>>> > >>>>>>
>>>> > >>>>>> This patch reworks detect procedure to address problems
>>>> above. New
>>>> > >>>>>> logic do detection for all variants separatedly, in 1-2-3
>>>> order.
>>>> > >>>>>> Since all current detect methods do exactly the same id
>>>> matching
>>>> > >>>>>> procedure, unify them into core.c and remove detect method 
>>>> from
>>>> > >>>>>> manufacture_ops.
>>>> > >>>>>>
>>>> > >>>>>> This is a rework of Chuanhong Guo >>> <mailto:gch981...@gmail.com>> patch
>>>> > >>>>>> submitted to linux kernel
>>>> > >>>>>>
>>>> > >>>>>> Signed-off-by: Mikhail Kshevetskiy
>>>> mailto:mikhail.kshevets...@iopsys.eu>>
>>>> > >>>>>> Signed-off-by: Frieder Schrempf
>>>> mailto:frieder.schre...@kontron.de>>
>>>> > >>>>>
>>>> > >>>>> +Cc: Jagan, Tom
>>>> > >>>>

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

On 17.05.23 09:43, Frieder Schrempf wrote:
> Hi Michael, hi Dario,
> 
> On 15.05.23 23:33, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> Il lun 15 mag 2023, 23:12 Tom Rini > <mailto:tr...@konsulko.com>> ha scritto:
>>
>>     On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote:
>> > Hi Michael, hi Dario,
>> >
>> > On 18.04.23 15:46, Frieder Schrempf wrote:
>> > > Hi Michael, Dario,
>> > >
>> > > On 28.03.23 09:57, Frieder Schrempf wrote:
>> > >> Hi Michael,
>> > >>
>> > >> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
>> > >>> Hi
>> > >>>
>>     > >>> I will review
>> > >>>
>> > >>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini > <mailto:tr...@konsulko.com>> wrote:
>> > >>>>
>> > >>>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
>> > >>>>> Hi,
>> > >>>>>
>> > >>>>> On 10.01.23 12:58, Frieder Schrempf wrote:
>> > >>>>>> From: Mikhail Kshevetskiy > <mailto:mikhail.kshevets...@iopsys.eu>>
>> > >>>>>>
>> > >>>>>> Currently there are 3 different variants of read_id
>> implementation:
>> > >>>>>> 1. opcode only. Found in GD5FxGQ4xF.
>> > >>>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>> > >>>>>> 3. opcode + 1 dummy byte. Found in other currently
>> supported chips.
>> > >>>>>>
>> > >>>>>> Original implementation was for variant 1 and let detect
>> function
>> > >>>>>> of chips with variant 2 and 3 to ignore the first byte.
>> This isn't
>> > >>>>>> robust:
>> > >>>>>>
>> > >>>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>> > >>>>>> during read, chip will get a random id offset, and the
>> entire id
>> > >>>>>> buffer will shift by that offset, causing detect failure.
>> > >>>>>>
>> > >>>>>> 2. For chips of variant 1, if it happens to get a devid
>> that equals
>> > >>>>>> to manufacture id of variant 2 or 3 chips, it'll get
>> incorrectly
>> > >>>>>> detected.
>> > >>>>>>
>> > >>>>>> This patch reworks detect procedure to address problems
>> above. New
>> > >>>>>> logic do detection for all variants separatedly, in 1-2-3
>> order.
>> > >>>>>> Since all current detect methods do exactly the same id
>> matching
>> > >>>>>> procedure, unify them into core.c and remove detect method from
>> > >>>>>> manufacture_ops.
>> > >>>>>>
>> > >>>>>> This is a rework of Chuanhong Guo > <mailto:gch981...@gmail.com>> patch
>> > >>>>>> submitted to linux kernel
>> > >>>>>>
>> > >>>>>> Signed-off-by: Mikhail Kshevetskiy
>> mailto:mikhail.kshevets...@iopsys.eu>>
>> > >>>>>> Signed-off-by: Frieder Schrempf
>> mailto:frieder.schre...@kontron.de>>
>> > >>>>>
>> > >>>>> +Cc: Jagan, Tom
>> > >>>>>
>> > >>>>> Who is supposed to pick up these patches? Some of them have
>> been around
>> > >>>>> for some months (before I resent them).
>> > >>>>>
>> > >>>>> There is no maintainer for drivers/mtd/spinand/ and no
>> maintainer for
>> > >>>>> drivers/mtd/ in general.
>> > >>>>>
>> > >>>>> In Patchwork Jagan got assigned, but the get_maintainer.pl
>> <http://get_maintainer.pl/> script didn't
>> > >>>>> even add him to Cc, of course.
>> > >>>>>
>> > >>>>> Any ideas how to proceed?
>> > >>>>
>> > >>>> We don't have anyone dedicated to that area, yes, sadly. I've
>> added
>> > >>>> Michael and Dario as they've also been doing mtd-but-not-spi
>> work of
>> > >>>> late to see if they're interested. Or since you've long been
>> working
>> > >>>> here, would you like to more formally maintain the area? Thanks!
>> > >>>
>> > >>> They can come from our tree. I will try to sort out all my
>> duties weeked
>> > >>
>> > >> Any news regarding reviewing/picking these patches?
>> > >
>> > > Ping!
>> > >
>> > > Can you please apply these patches, that have been waiting for
>> so long?
>> >
>> > I still can't see this applied anywhere. You already told me to take
>> > care of it multiple times. Can you please get it done?
>>
>> Yes, I'd really like to see a PR at least vs -next at this point so
>> things aren't lost, thanks!
>>
>>
>> I think that we pick already it so it will happen.
> 
> I can see patch 1/5 of this series in the nand-next tree. What about the
> other four patches of this series? Please pick them up, too!

Ping, again! I will just keep on doing this and hope at some point you
will pick up the patches.

Re: [PATCH] imx8m: soc.c: demote some printfs to debug

[Frieder Schrempf]

On 22.05.23 11:27, Rasmus Villemoes wrote:
> Getting
> 
>   Found /vpu_g1@3830 node
>   Modify /vpu_g1@3830:status disabled
>   Found /vpu_g2@3831 node
>   Modify /vpu_g2@3831:status disabled
> 
> etc. on the console on every boot is needlessly verbose. Demote the
> "Found ..." lines to debug(), which is consistent with other instances
> in soc.c.
> 
> Signed-off-by: Rasmus Villemoes 

Reviewed-by: Frieder Schrempf 

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

Hi Michael, hi Dario,

On 15.05.23 23:33, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> Il lun 15 mag 2023, 23:12 Tom Rini  <mailto:tr...@konsulko.com>> ha scritto:
> 
> On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote:
> > Hi Michael, hi Dario,
> >
>     > On 18.04.23 15:46, Frieder Schrempf wrote:
> > > Hi Michael, Dario,
> > >
> > > On 28.03.23 09:57, Frieder Schrempf wrote:
> > >> Hi Michael,
> > >>
> > >> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
> > >>> Hi
> > >>>
> > >>> I will review
> > >>>
> > >>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini  <mailto:tr...@konsulko.com>> wrote:
> > >>>>
> > >>>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> On 10.01.23 12:58, Frieder Schrempf wrote:
> > >>>>>> From: Mikhail Kshevetskiy  <mailto:mikhail.kshevets...@iopsys.eu>>
> > >>>>>>
> > >>>>>> Currently there are 3 different variants of read_id
> implementation:
> > >>>>>> 1. opcode only. Found in GD5FxGQ4xF.
> > >>>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> > >>>>>> 3. opcode + 1 dummy byte. Found in other currently
> supported chips.
> > >>>>>>
> > >>>>>> Original implementation was for variant 1 and let detect
> function
> > >>>>>> of chips with variant 2 and 3 to ignore the first byte.
> This isn't
> > >>>>>> robust:
> > >>>>>>
> > >>>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> > >>>>>> during read, chip will get a random id offset, and the
> entire id
> > >>>>>> buffer will shift by that offset, causing detect failure.
> > >>>>>>
> > >>>>>> 2. For chips of variant 1, if it happens to get a devid
> that equals
> > >>>>>> to manufacture id of variant 2 or 3 chips, it'll get
> incorrectly
> > >>>>>> detected.
> > >>>>>>
> > >>>>>> This patch reworks detect procedure to address problems
> above. New
> > >>>>>> logic do detection for all variants separatedly, in 1-2-3
> order.
> > >>>>>> Since all current detect methods do exactly the same id
> matching
> > >>>>>> procedure, unify them into core.c and remove detect method from
> > >>>>>> manufacture_ops.
> > >>>>>>
> > >>>>>> This is a rework of Chuanhong Guo  <mailto:gch981...@gmail.com>> patch
> > >>>>>> submitted to linux kernel
> > >>>>>>
> > >>>>>> Signed-off-by: Mikhail Kshevetskiy
> mailto:mikhail.kshevets...@iopsys.eu>>
> > >>>>>> Signed-off-by: Frieder Schrempf
> mailto:frieder.schre...@kontron.de>>
> > >>>>>
> > >>>>> +Cc: Jagan, Tom
> > >>>>>
> > >>>>> Who is supposed to pick up these patches? Some of them have
> been around
> > >>>>> for some months (before I resent them).
> > >>>>>
> > >>>>> There is no maintainer for drivers/mtd/spinand/ and no
> maintainer for
> > >>>>> drivers/mtd/ in general.
> > >>>>>
> > >>>>> In Patchwork Jagan got assigned, but the get_maintainer.pl
> <http://get_maintainer.pl/> script didn't
> > >>>>> even add him to Cc, of course.
> > >>>>>
> > >>>>> Any ideas how to proceed?
> > >>>>
> > >>>> We don't have anyone dedicated to that area, yes, sadly. I've
> added
> > >>>> Michael and Dario as they've also been doing mtd-but-not-spi
> work of
> > >>>> late to see if they're interested. Or since you've long been
> working
> > >>>> here, would you like to more formally maintain the area? Thanks!
> > >>>
> > >>> They can come from our tree. I will try to sort out all my
> duties weeked
> > >>
> > >> Any news regarding reviewing/picking these patches?
> > >
> > > Ping!
> > >
> > > Can you please apply these patches, that have been waiting for
> so long?
> >
> > I still can't see this applied anywhere. You already told me to take
> > care of it multiple times. Can you please get it done?
> 
> Yes, I'd really like to see a PR at least vs -next at this point so
> things aren't lost, thanks!
> 
> 
> I think that we pick already it so it will happen.

I can see patch 1/5 of this series in the nand-next tree. What about the
other four patches of this series? Please pick them up, too!

Thanks
Frieder

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

Hi Michael, hi Dario,

On 18.04.23 15:46, Frieder Schrempf wrote:
> Hi Michael, Dario,
> 
> On 28.03.23 09:57, Frieder Schrempf wrote:
>> Hi Michael,
>>
>> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
>>> Hi
>>>
>>> I will review
>>>
>>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini  wrote:
>>>>
>>>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
>>>>> Hi,
>>>>>
>>>>> On 10.01.23 12:58, Frieder Schrempf wrote:
>>>>>> From: Mikhail Kshevetskiy 
>>>>>>
>>>>>> Currently there are 3 different variants of read_id implementation:
>>>>>> 1. opcode only. Found in GD5FxGQ4xF.
>>>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>>>>>> 3. opcode + 1 dummy byte. Found in other currently supported chips.
>>>>>>
>>>>>> Original implementation was for variant 1 and let detect function
>>>>>> of chips with variant 2 and 3 to ignore the first byte. This isn't
>>>>>> robust:
>>>>>>
>>>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>>>>>> during read, chip will get a random id offset, and the entire id
>>>>>> buffer will shift by that offset, causing detect failure.
>>>>>>
>>>>>> 2. For chips of variant 1, if it happens to get a devid that equals
>>>>>> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
>>>>>> detected.
>>>>>>
>>>>>> This patch reworks detect procedure to address problems above. New
>>>>>> logic do detection for all variants separatedly, in 1-2-3 order.
>>>>>> Since all current detect methods do exactly the same id matching
>>>>>> procedure, unify them into core.c and remove detect method from
>>>>>> manufacture_ops.
>>>>>>
>>>>>> This is a rework of Chuanhong Guo  patch
>>>>>> submitted to linux kernel
>>>>>>
>>>>>> Signed-off-by: Mikhail Kshevetskiy 
>>>>>> Signed-off-by: Frieder Schrempf 
>>>>>
>>>>> +Cc: Jagan, Tom
>>>>>
>>>>> Who is supposed to pick up these patches? Some of them have been around
>>>>> for some months (before I resent them).
>>>>>
>>>>> There is no maintainer for drivers/mtd/spinand/ and no maintainer for
>>>>> drivers/mtd/ in general.
>>>>>
>>>>> In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't
>>>>> even add him to Cc, of course.
>>>>>
>>>>> Any ideas how to proceed?
>>>>
>>>> We don't have anyone dedicated to that area, yes, sadly. I've added
>>>> Michael and Dario as they've also been doing mtd-but-not-spi work of
>>>> late to see if they're interested. Or since you've long been working
>>>> here, would you like to more formally maintain the area? Thanks!
>>>
>>> They can come from our tree. I will try to sort out all my duties weeked
>>
>> Any news regarding reviewing/picking these patches?
> 
> Ping!
> 
> Can you please apply these patches, that have been waiting for so long?

I still can't see this applied anywhere. You already told me to take
care of it multiple times. Can you please get it done?

Thanks
Frieder

Re: [PATCH V2 01/53] spl: imx8mm: enlarge SPL_MAX_SIZE

[Frieder Schrempf]

Hi,

On 26.07.22 10:40, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> The CONFIG_SPL_MAX_SIZE could be 0x27000 for i.MX8MM when SPL_TEXT_BASE
> set to 0x7E1000.
> 
> The DDR firmware max uses 96KB, there is a 4KB padding header before
> SPL_TEXT_BASE, so the SPL MAX SIZE is `256KB - 96KB - 4KB`.

Am I right to assume that setting CONFIG_SPL_MAX_SIZE to 0x27000 is more
restricting nowadays than it would need to be?

If I understand correctly nowadays the DDR firmware doesn't need a fixed
96 KiB area with padding anymore, but rather takes up only the space it
needs (~ 57 KiB) due to "binman magic".

If this is correct, is it safe to increase CONFIG_SPL_MAX_SIZE?
Is there a sane default that we could use instead of 0x27000?

Thanks
Frieder

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

On 18.04.23 20:24, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Tue, Apr 18, 2023 at 8:20 PM Mikhail Kshevetskiy
>  wrote:
>>
>> I can try to resend patches (flash drivers synced with linux-6.1).
>> Unfortunately I am not sure I will be able to do it after changes in our
>> mail system.
> 
> I don't think that re-sync now is what we want to do. The idea here is
> to have easy patch that we can review.
> 
> We should go for this for now

Yes, there is no resend or resync needed. The patchset I sent [1] still
applies on current master.

Resyncing with a later version of Linux, like 6.1 won't be that easy
because of the upstream ECC engine abstraction.

Mikhail, if you are willing to do this, this is fine and appreciated,
but we should do that after merging this series.

[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230110115843.391630-1-frie...@fris.de/

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

Hi Michael, Dario,

On 28.03.23 09:57, Frieder Schrempf wrote:
> Hi Michael,
> 
> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> I will review
>>
>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini  wrote:
>>>
>>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
>>>> Hi,
>>>>
>>>> On 10.01.23 12:58, Frieder Schrempf wrote:
>>>>> From: Mikhail Kshevetskiy 
>>>>>
>>>>> Currently there are 3 different variants of read_id implementation:
>>>>> 1. opcode only. Found in GD5FxGQ4xF.
>>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>>>>> 3. opcode + 1 dummy byte. Found in other currently supported chips.
>>>>>
>>>>> Original implementation was for variant 1 and let detect function
>>>>> of chips with variant 2 and 3 to ignore the first byte. This isn't
>>>>> robust:
>>>>>
>>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>>>>> during read, chip will get a random id offset, and the entire id
>>>>> buffer will shift by that offset, causing detect failure.
>>>>>
>>>>> 2. For chips of variant 1, if it happens to get a devid that equals
>>>>> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
>>>>> detected.
>>>>>
>>>>> This patch reworks detect procedure to address problems above. New
>>>>> logic do detection for all variants separatedly, in 1-2-3 order.
>>>>> Since all current detect methods do exactly the same id matching
>>>>> procedure, unify them into core.c and remove detect method from
>>>>> manufacture_ops.
>>>>>
>>>>> This is a rework of Chuanhong Guo  patch
>>>>> submitted to linux kernel
>>>>>
>>>>> Signed-off-by: Mikhail Kshevetskiy 
>>>>> Signed-off-by: Frieder Schrempf 
>>>>
>>>> +Cc: Jagan, Tom
>>>>
>>>> Who is supposed to pick up these patches? Some of them have been around
>>>> for some months (before I resent them).
>>>>
>>>> There is no maintainer for drivers/mtd/spinand/ and no maintainer for
>>>> drivers/mtd/ in general.
>>>>
>>>> In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't
>>>> even add him to Cc, of course.
>>>>
>>>> Any ideas how to proceed?
>>>
>>> We don't have anyone dedicated to that area, yes, sadly. I've added
>>> Michael and Dario as they've also been doing mtd-but-not-spi work of
>>> late to see if they're interested. Or since you've long been working
>>> here, would you like to more formally maintain the area? Thanks!
>>
>> They can come from our tree. I will try to sort out all my duties weeked
> 
> Any news regarding reviewing/picking these patches?

Ping!

Can you please apply these patches, that have been waiting for so long?

Thanks
Frieder

Re: [PATCH v3] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.

[Frieder Schrempf]

On 31.03.23 16:18, Sebastian Andrzej Siewior wrote:
> From: Manuel Traut 
> 
> The board is similar to "Kontron SL i.MX8M Mini" SoM. There are two variants.
> Snowflake_v2 has an external SDCard Interface. LEIG is the same, but without
> display and without external SDCard Interface. Both variants support
> only 1GiB of main memory.
> 
> [ bigeasy: porting and a bit of cleanup ]
> 
> Signed-off-by: Manuel Traut 
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
> v2…v3:
>  Addressing Frieder's comments:
>  - Add "kontron,imx8mm-sl" to the compatible string.
>  - Remove pca9450 node and pinctrl_i2c1. The included
>imx8mm-kontron-sl.dtsi already provides this.
>  - Merge the overwritten values in dram_timing.ddrc_cfg/fsp_msg directly
>into lpddr4_timing.c.
>  - Simplify the init in spl_dram_init() and panic() if the init failed.
>  - Replace a reference to SMARC with the current product name of the
>SoM.
> 
> v1…v2:
>  - Clarify details about the board and whether or not there is an
>external SD-card interface.

LGTM!

Reviewed-by: Frieder Schrempf 

Re: [PATCH v2] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.

[Frieder Schrempf]

On 28.03.23 11:37, Sebastian Andrzej Siewior wrote:
> On 2023-03-28 11:34:42 [+0200], Frieder Schrempf wrote:
>> You can easily answer that yourself, by looking at the comments I made
>> in [1]. There are comments for the DT compatible, the PMIC node, the
>> I2C1 pinctrl node and the DDR init code you haven't responded to.
> 
> I'm sorry. I really haven't seen those, I assumed it was just a full
> quote the mail and stopped scrolling after a while (before seeing
> anything you wrote).

No worries! It's easy to miss something in a long e-mail patch.

Re: [PATCH v2] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.

[Frieder Schrempf]

On 28.03.23 11:30, Sebastian Andrzej Siewior wrote:
> On 2023-03-28 09:53:28 [+0200], Frieder Schrempf wrote:
>> On 28.03.23 09:47, Sebastian Andrzej Siewior wrote:
>>> The board is similar to "Kontron SL i.MX8M Mini" SoM. There are two 
>>> variants.
>>> Snowflake_v2 has an external SDCard Interface. LEIG is the same, but without
>>> display and without external SDCard Interface. Both variants support
>>> only 1GiB of main memory.
>>>
>>> Signed-off-by: Manuel Traut 
>>> Signed-off-by: Sebastian Andrzej Siewior 
>>> ---
>>> v1…v2:
>>>  - Clarify details about the board and whether or not there is an
>>>external SD-card interface.
>>
>> What about my other review comments to v1?
> 
> I update the Name to "Kontron SL i.MX8M Mini" SoM in the description but
> forgot to add it to the changelog. Was there something else missed?

You can easily answer that yourself, by looking at the comments I made
in [1]. There are comments for the DT compatible, the PMIC node, the
I2C1 pinctrl node and the DDR init code you haven't responded to.

[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230310135021.krabf...@linutronix.de/#3078257

Re: [PATCH 1/2] MAINTAINERS: Add entry for SPI NAND framework and drivers

[Frieder Schrempf]

On 28.02.23 15:48, Tom Rini wrote:
> On Tue, Feb 28, 2023 at 09:52:45AM +0100, Frieder Schrempf wrote:
>> On 27.02.23 16:24, Dario Binacchi wrote:
>>> Hi Frieder,
>>>
>>> On Mon, Feb 13, 2023 at 10:47 AM Frieder Schrempf  wrote:
>>>>
>>>> From: Frieder Schrempf 
>>>>
>>>> In [1] Michael agreed on taking patches for SPI NAND through the RAW
>>>> NAND tree. Add a dedicated entry to the MAINTAINERS file which adds
>>>> Michael and Dario as maintainers and myself as reviewer.
>>>>
>>>> [1] 
>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2023-February%2F508571.html=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4HDR%2BwouzdpqPFWPdvnZWRXSyjc94T%2F0pPHaXTYNrsM%3D=0
>>>>
>>>> Signed-off-by: Frieder Schrempf 
>>>> Cc: Jagan Teki 
>>>> Cc: Dario Binacchi 
>>>> Cc: Michael Nazzareno Trimarchi 
>>>> Cc: Tom Rini 
>>>> ---
>>>>  MAINTAINERS | 8 
>>>>  1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index b9c505d5fa..e40c401337 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -1375,6 +1375,14 @@ T:   git 
>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-spi.git=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RPFcfbNZYy7sKTu8PruDhcIDts7ufkzrUtPr1cR8yhw%3D=0
>>>>  F: drivers/spi/
>>>>  F: include/spi*
>>>>
>>>> +SPI NAND
>>>> +M: Dario Binacchi 
>>>> +M: Michael Trimarchi 
>>>> +R: Frieder Schrempf 
>>>> +S: Maintained
>>>> +T: git 
>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-nand-flash.git=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pGjKSC7chQZ4%2BvT7QVNDdselY2P4llM5AeEMLTjzYUI%3D=0
>>>> +F: drivers/mtd/nand/spi/
>>>> +
>>>
>>> Please re-send a single patch where you only consider drivers/mtd/nand
>>> for NAND FLASH
>>> in order to be as similar as possible to the Linux kernel MAINTAINERS file.
>>> Add to it "+R: Frieder Schrempf "
>>
>> Actually, I don't really like to be listed as reviewer for the whole
>> NAND subsystem. I only have limited time and knowledge and SPI NAND is
>> an area I feel I can provide help.
>>
>>> Neither SPI NAND nor  RAW NAND exists in the Linux kernel MAINTAINERS file.
>>
>> Is there a requirement to have MAINTAINERS in sync with Linux?
> 
> What matters most is that get_maintainers.pl returns something useful
> and correct. So if you're only comfortable with SPI NAND, the above is
> fine, we have similar for SPI-NOR already.

This sounds like an Ack from Tom, so can someone pick up this series,
please?

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

Hi Michael,

On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> I will review
> 
> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini  wrote:
>>
>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
>>> Hi,
>>>
>>> On 10.01.23 12:58, Frieder Schrempf wrote:
>>>> From: Mikhail Kshevetskiy 
>>>>
>>>> Currently there are 3 different variants of read_id implementation:
>>>> 1. opcode only. Found in GD5FxGQ4xF.
>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>>>> 3. opcode + 1 dummy byte. Found in other currently supported chips.
>>>>
>>>> Original implementation was for variant 1 and let detect function
>>>> of chips with variant 2 and 3 to ignore the first byte. This isn't
>>>> robust:
>>>>
>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>>>> during read, chip will get a random id offset, and the entire id
>>>> buffer will shift by that offset, causing detect failure.
>>>>
>>>> 2. For chips of variant 1, if it happens to get a devid that equals
>>>> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
>>>> detected.
>>>>
>>>> This patch reworks detect procedure to address problems above. New
>>>> logic do detection for all variants separatedly, in 1-2-3 order.
>>>> Since all current detect methods do exactly the same id matching
>>>> procedure, unify them into core.c and remove detect method from
>>>> manufacture_ops.
>>>>
>>>> This is a rework of Chuanhong Guo  patch
>>>> submitted to linux kernel
>>>>
>>>> Signed-off-by: Mikhail Kshevetskiy 
>>>> Signed-off-by: Frieder Schrempf 
>>>
>>> +Cc: Jagan, Tom
>>>
>>> Who is supposed to pick up these patches? Some of them have been around
>>> for some months (before I resent them).
>>>
>>> There is no maintainer for drivers/mtd/spinand/ and no maintainer for
>>> drivers/mtd/ in general.
>>>
>>> In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't
>>> even add him to Cc, of course.
>>>
>>> Any ideas how to proceed?
>>
>> We don't have anyone dedicated to that area, yes, sadly. I've added
>> Michael and Dario as they've also been doing mtd-but-not-spi work of
>> late to see if they're interested. Or since you've long been working
>> here, would you like to more formally maintain the area? Thanks!
> 
> They can come from our tree. I will try to sort out all my duties weeked

Any news regarding reviewing/picking these patches?

Thanks
Frieder

Re: [PATCH v2] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.

[Frieder Schrempf]

On 28.03.23 09:47, Sebastian Andrzej Siewior wrote:
> The board is similar to "Kontron SL i.MX8M Mini" SoM. There are two variants.
> Snowflake_v2 has an external SDCard Interface. LEIG is the same, but without
> display and without external SDCard Interface. Both variants support
> only 1GiB of main memory.
> 
> Signed-off-by: Manuel Traut 
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
> v1…v2:
>  - Clarify details about the board and whether or not there is an
>external SD-card interface.

What about my other review comments to v1?

Re: [PATCH] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.

[Frieder Schrempf]

On 16.03.23 11:33, Frieder Schrempf wrote:
> On 10.03.23 14:50, Sebastian Andrzej Siewior wrote:
>> From: Manuel Traut 
>>
>> The board is similar to Kontron's N801x design. It lacks external eMMC
>> support and only supports only 1GiB of main memory.
> 
> Good to see some custom boards being upstreamed!
> 
> It would be worth mentioning here that it is based on the "Kontron SL
> i.MX8M Mini" SoM, which is the proper name of the product nowadays.
> 
> What do you mean by "it lacks external eMMC support"?
> There is an eMMC on the SoM, so the hardware does support it.

Or did I misunderstand the snowflake hardware and it actually doesn't
have the SoM onboard but is designed like the SoM?

Re: [PATCH] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.

[Frieder Schrempf]

On 10.03.23 14:50, Sebastian Andrzej Siewior wrote:
> From: Manuel Traut 
> 
> The board is similar to Kontron's N801x design. It lacks external eMMC
> support and only supports only 1GiB of main memory.

Good to see some custom boards being upstreamed!

It would be worth mentioning here that it is based on the "Kontron SL
i.MX8M Mini" SoM, which is the proper name of the product nowadays.

What do you mean by "it lacks external eMMC support"?
There is an eMMC on the SoM, so the hardware does support it.

> 
> [ bigeasy: porting and a bit of cleanup ]
> 
> Signed-off-by: Manuel Traut 
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
>  arch/arm/dts/Makefile |1 +
>  .../dts/imx8mm-mt-snowflake-v2-u-boot.dtsi|  116 ++
>  arch/arm/dts/imx8mm-mt-snowflake-v2.dts   |  186 ++
>  arch/arm/mach-imx/imx8m/Kconfig   |8 +
>  board/mt/snowflake_v2/Kconfig |   18 +
>  board/mt/snowflake_v2/MAINTAINERS |7 +
>  board/mt/snowflake_v2/Makefile|9 +
>  board/mt/snowflake_v2/imximage.cfg|8 +
>  board/mt/snowflake_v2/lpddr4_timing.c | 1844 +
>  board/mt/snowflake_v2/snowflake_v2.c  |   32 +
>  board/mt/snowflake_v2/snowflake_v2.env|   33 +
>  board/mt/snowflake_v2/spl.c   |  167 ++
>  configs/snowflake_v2_emmcboot_defconfig   |  134 ++
>  include/configs/snowflake_v2.h|   54 +
>  14 files changed, 2617 insertions(+)
>  create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2.dts
>  create mode 100644 board/mt/snowflake_v2/Kconfig
>  create mode 100644 board/mt/snowflake_v2/MAINTAINERS
>  create mode 100644 board/mt/snowflake_v2/Makefile
>  create mode 100644 board/mt/snowflake_v2/imximage.cfg
>  create mode 100644 board/mt/snowflake_v2/lpddr4_timing.c
>  create mode 100644 board/mt/snowflake_v2/snowflake_v2.c
>  create mode 100644 board/mt/snowflake_v2/snowflake_v2.env
>  create mode 100644 board/mt/snowflake_v2/spl.c
>  create mode 100644 configs/snowflake_v2_emmcboot_defconfig
>  create mode 100644 include/configs/snowflake_v2.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7a577deb5023d..ba0786064847e 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -964,6 +964,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
>   imx8mm-icore-mx8mm-edimm2.2.dtb \
>   imx8mm-kontron-bl.dtb \
>   imx8mm-kontron-bl-osm-s.dtb \
> + imx8mm-mt-snowflake-v2.dtb \
>   imx8mm-mx8menlo.dtb \
>   imx8mm-phg.dtb \
>   imx8mm-venice.dtb \
> diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi 
> b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> new file mode 100644
> index 0..d6476db292b79
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Mettler Toledo GmbH
> + */
> +
> +/ {
> +
> + aliases {
> + usbgadget0 = 
> + };
> +
> + usbg1: usbg1 {
> + u-boot,dm-spl;
> + compatible = "fsl,imx27-usb-gadget";
> + dr_mode = "peripheral";
> + chipidea,usb = <>;
> + status = "okay";
> + };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + status = "okay";
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +_ecspi1 {
> + u-boot,dm-spl;
> +};
> +
> +_i2c1 {
> + u-boot,dm-spl;
> +};
> +
> +_pmic {
> + u-boot,dm-spl;
> +};
> +
> +_uart3 {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +_usdhc1 {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc1_100mhz {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc1_200mhz {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_wdog {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2.dts 
> b/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> new file mode 100644
> index 0..49761b22afcf0
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> @@ -0,0 +1,186 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Mettler Toledo GmbH
> + */
> +
> +/dts-v1/;
> +
> +#include 

Re: i.MX8MP SPL failures due to memory corruption/overflow?

[Frieder Schrempf]

Hi Emanuele,

On 15.03.23 22:25, Emanuele Ghidoli wrote:
> [Sie erhalten nicht häufig E-Mails von ghidoliemanu...@gmail.com.
> Weitere Informationen, warum dies wichtig ist, finden Sie unter
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> On 15/03/2023 16:24, Frieder Schrempf wrote:
>> On 15.03.23 15:42, Frieder Schrempf wrote:
>>> On 15.03.23 15:17, Michael Nazzareno Trimarchi wrote:
>>>> Hi
>>>>
>>>> On Wed, Mar 15, 2023 at 3:13 PM Frieder Schrempf
>>>>  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to bring up a new board based on the i.MX8MP and I have an
>>>>> issue I'm hoping someone can help solving.
>>>>>
>>>>> I'm seeing failures in the early SPL code, usually in the DDR
>>>>> initialization. Often they look like:
>>>>>
>>>>>    U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +)
>>>>>    Training FAILED
>>>>>    Failed to initialize DDR RAM!
>>>>>    ### ERROR ### Please RESET the board ###
>>>>>
>>>>> But sometimes ddr_init() doesn't even return an error and only the
>>>>> get_ram_size() afterwards which tries to allocate the memory fails.
>>>>>
>>>>
>>>> In my experience you don't have space inside the cpu internal
>>>> memory. It means
>>>> that you overlap some stack with the code. Change the printf means
>>>> move a bit. So you have
>>>> problem but depends what you are going to destroy
>>>
>>> Thanks for your reply. That's exactly what I'm thinking, too.
>>>
>>>>
>>>>> The strange thing is that the issues appear or disappear
>>>>> deterministically on the binary level. This means I sometimes get a
>>>>> U-Boot binary which runs just fine in 100% of cases. Then I change for
>>>>> example one of the following:
>>>>>
>>>>> * Adding a single printf() somewhere in the boards spl.c
>>>>> * Using the same binary but booting from SD card instead of USB loader
>>>>> * Using the same source but switching from the OS cross compiler to
>>>>> the
>>>>> one from Yocto/OE
>>>>>
>>>>> And afterwards I get 100% failure rate with an error as described
>>>>> above.
>>>>>
>>>>> My suspicion is that there is some memory corruption/conflict. My
>>>>> SPL is
>>>>> quite large and I wonder if it exceeds some limit.
>>>>>
>>>>> SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96,
>>>>> which
>>>>> leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
>>>>> set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
>>>>> u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
>>>>> warning about exceeding the SPL_MAX_SIZE.
>>>>>
>>>>> My questions:
>>>>>
>>>>> * Why is CONFIG_SPL_MAX_SIZE set to 152 KiB?
>>>
>>> I guess the remainder between the SPL code and the SPL stack is for the
>>> DDR firmware. Which explains why I get failures with SPL exceeding 152
>>> KiB size.
>>
>> Still, it doesn't really make sense to me at the moment as the
>> u-boot-spl-ddr.bin already contains the DDR firmware it should be fine
>> to exceed the 152 KiB size. My u-boot-spl.bin (without DDR firmware) is
>> only 135 KiB.
>>
>> Sorry for spamming you by thinking out loud... ;)
>>
>>>
>>> Now I also understand the reason why the power init code was implemented
>>> using legacy non-DM drivers in other i.MX8MP boards. I probably also
>>> need to do this to save some space.
>>>
>>>>> * Why is there no warning in my case?
>>>
>>> Still, I fail to see why there isn't any error or where the size check
>>> is even implemented.
>>>
>>>>> * Any other ideas or pointers?
>>>>>
>>>>> Thanks for your help!
>>>>>
>>>>> Best regards
>>>>> Frieder
>>
> 
> Hello,
> I fall in a similar problem.
> 
> Some hints:
> - commit 5004901efb3b ("board_init: Do not reserve MALLOC_F area on stack
>   if non-zero MALLOC_F_ADDR") - but you should already have it
> - Reduce (set to something different from default value)
> SPL_SYS_MALLOC_F_LEN.
>   Normally that area is not used a lot. Stack start before heap area and,
>   if I remember well, start address of heap area depend upon this config.
>   And... its default value is equal to SYS_MALLOC_F_LEN, that normally
> is high.
> 
> Suggestions from Rasmus are precious. I adopt a rather similar approch
> to find
> that stack / gd (global data) was overlapping DDR firmware / cfg.

Thanks a lot for the additional pointers. I do have commit 5004901efb3b,
but I didn't look at MALLOC_F_ADDR before. It seems like there are some
i.MX8MP boards which use this to place the malloc area in the separate
OCRAM_S (0x184000) instead of OCRAM which is interesting and another
possibility I didn't know of.

Thanks
Frieder

Re: i.MX8MP SPL failures due to memory corruption/overflow?

[Frieder Schrempf]

Hi Rasmus,

On 15.03.23 16:59, Rasmus Villemoes wrote:
> On 15/03/2023 16.24, Frieder Schrempf wrote:
>> On 15.03.23 15:42, Frieder Schrempf wrote:
>>> On 15.03.23 15:17, Michael Nazzareno Trimarchi wrote:
>>>> Hi
>>>>
>>>> On Wed, Mar 15, 2023 at 3:13 PM Frieder Schrempf
>>>>  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to bring up a new board based on the i.MX8MP and I have an
>>>>> issue I'm hoping someone can help solving.
>>>>>
>>>>> I'm seeing failures in the early SPL code, usually in the DDR
>>>>> initialization. Often they look like:
>>>>>
>>>>>   U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +)
>>>>>   Training FAILED
>>>>>   Failed to initialize DDR RAM!
>>>>>   ### ERROR ### Please RESET the board ###
>>>>>
>>>>> But sometimes ddr_init() doesn't even return an error and only the
>>>>> get_ram_size() afterwards which tries to allocate the memory fails.
>>>>>
>>>>
>>>> In my experience you don't have space inside the cpu internal memory. It 
>>>> means
>>>> that you overlap some stack with the code. Change the printf means
>>>> move a bit. So you have
>>>> problem but depends what you are going to destroy
>>>
>>> Thanks for your reply. That's exactly what I'm thinking, too.
>>>
>>>>
>>>>> The strange thing is that the issues appear or disappear
>>>>> deterministically on the binary level. This means I sometimes get a
>>>>> U-Boot binary which runs just fine in 100% of cases. Then I change for
>>>>> example one of the following:
>>>>>
>>>>> * Adding a single printf() somewhere in the boards spl.c
>>>>> * Using the same binary but booting from SD card instead of USB loader
>>>>> * Using the same source but switching from the OS cross compiler to the
>>>>> one from Yocto/OE
>>>>>
>>>>> And afterwards I get 100% failure rate with an error as described above.
>>>>>
>>>>> My suspicion is that there is some memory corruption/conflict. My SPL is
>>>>> quite large and I wonder if it exceeds some limit.
>>>>>
>>>>> SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96, which
>>>>> leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
>>>>> set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
>>>>> u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
>>>>> warning about exceeding the SPL_MAX_SIZE.
> 
> I also ran into this problem a while back, but that was back when the
> ddr firmware files were padded to 16K and 32K each to make the magic
> offset computations work; now that binman symbols are used, they only
> take up as much space as they actually use (give or take some 4-byte
> padding perhaps), and I no longer need the debug code I put in place in
> our 2022.07 branch.
> 
> Remember that from the stack, the initial (and in SPL only) malloc arena
> is carved out, and if you haven't adjusted SPL_SYS_MALLOC_F_LEN, you
> probably have that set to the default SYS_MALLOC_F_LEN, which in turn
> (on imx8m) defaults to 0x1 aka 64KiB. So that could easily explain
> why you collide with the firmware.

Ok, that's something I missed before and it provides a good explanation
for my problems.

> 
> Maybe you can use the debug code I added to our copy of spl.c; I also
> include most of my commit-message-for-future-me. But just something as
> simple as
> 
>   int dummy;
>   printf("stack is around %p\n", );
> 
> can be quite valuable.

Thanks for all the valuable information and explanations. This helps a
lot. In the first step I disabled some DM drivers in SPL and use legacy
implementations for the PMIC, GPIO, etc. just as other i.MX8MP boards
do. This seems to shrink the SPL enough to avoid collisions.

But I will also try to optimize SPL_SYS_MALLOC_F_LEN now that I know its
role.

Thanks
Frieder

Re: i.MX8MP SPL failures due to memory corruption/overflow?

[Frieder Schrempf]

On 15.03.23 15:42, Frieder Schrempf wrote:
> On 15.03.23 15:17, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> On Wed, Mar 15, 2023 at 3:13 PM Frieder Schrempf
>>  wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to bring up a new board based on the i.MX8MP and I have an
>>> issue I'm hoping someone can help solving.
>>>
>>> I'm seeing failures in the early SPL code, usually in the DDR
>>> initialization. Often they look like:
>>>
>>>   U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +)
>>>   Training FAILED
>>>   Failed to initialize DDR RAM!
>>>   ### ERROR ### Please RESET the board ###
>>>
>>> But sometimes ddr_init() doesn't even return an error and only the
>>> get_ram_size() afterwards which tries to allocate the memory fails.
>>>
>>
>> In my experience you don't have space inside the cpu internal memory. It 
>> means
>> that you overlap some stack with the code. Change the printf means
>> move a bit. So you have
>> problem but depends what you are going to destroy
> 
> Thanks for your reply. That's exactly what I'm thinking, too.
> 
>>
>>> The strange thing is that the issues appear or disappear
>>> deterministically on the binary level. This means I sometimes get a
>>> U-Boot binary which runs just fine in 100% of cases. Then I change for
>>> example one of the following:
>>>
>>> * Adding a single printf() somewhere in the boards spl.c
>>> * Using the same binary but booting from SD card instead of USB loader
>>> * Using the same source but switching from the OS cross compiler to the
>>> one from Yocto/OE
>>>
>>> And afterwards I get 100% failure rate with an error as described above.
>>>
>>> My suspicion is that there is some memory corruption/conflict. My SPL is
>>> quite large and I wonder if it exceeds some limit.
>>>
>>> SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96, which
>>> leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
>>> set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
>>> u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
>>> warning about exceeding the SPL_MAX_SIZE.
>>>
>>> My questions:
>>>
>>> * Why is CONFIG_SPL_MAX_SIZE set to 152 KiB?
> 
> I guess the remainder between the SPL code and the SPL stack is for the
> DDR firmware. Which explains why I get failures with SPL exceeding 152
> KiB size.

Still, it doesn't really make sense to me at the moment as the
u-boot-spl-ddr.bin already contains the DDR firmware it should be fine
to exceed the 152 KiB size. My u-boot-spl.bin (without DDR firmware) is
only 135 KiB.

Sorry for spamming you by thinking out loud... ;)

> 
> Now I also understand the reason why the power init code was implemented
> using legacy non-DM drivers in other i.MX8MP boards. I probably also
> need to do this to save some space.
> 
>>> * Why is there no warning in my case?
> 
> Still, I fail to see why there isn't any error or where the size check
> is even implemented.
> 
>>> * Any other ideas or pointers?
>>>
>>> Thanks for your help!
>>>
>>> Best regards
>>> Frieder

Re: i.MX8MP SPL failures due to memory corruption/overflow?

[Frieder Schrempf]

On 15.03.23 15:17, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Wed, Mar 15, 2023 at 3:13 PM Frieder Schrempf
>  wrote:
>>
>> Hi,
>>
>> I'm trying to bring up a new board based on the i.MX8MP and I have an
>> issue I'm hoping someone can help solving.
>>
>> I'm seeing failures in the early SPL code, usually in the DDR
>> initialization. Often they look like:
>>
>>   U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +)
>>   Training FAILED
>>   Failed to initialize DDR RAM!
>>   ### ERROR ### Please RESET the board ###
>>
>> But sometimes ddr_init() doesn't even return an error and only the
>> get_ram_size() afterwards which tries to allocate the memory fails.
>>
> 
> In my experience you don't have space inside the cpu internal memory. It means
> that you overlap some stack with the code. Change the printf means
> move a bit. So you have
> problem but depends what you are going to destroy

Thanks for your reply. That's exactly what I'm thinking, too.

> 
>> The strange thing is that the issues appear or disappear
>> deterministically on the binary level. This means I sometimes get a
>> U-Boot binary which runs just fine in 100% of cases. Then I change for
>> example one of the following:
>>
>> * Adding a single printf() somewhere in the boards spl.c
>> * Using the same binary but booting from SD card instead of USB loader
>> * Using the same source but switching from the OS cross compiler to the
>> one from Yocto/OE
>>
>> And afterwards I get 100% failure rate with an error as described above.
>>
>> My suspicion is that there is some memory corruption/conflict. My SPL is
>> quite large and I wonder if it exceeds some limit.
>>
>> SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96, which
>> leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
>> set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
>> u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
>> warning about exceeding the SPL_MAX_SIZE.
>>
>> My questions:
>>
>> * Why is CONFIG_SPL_MAX_SIZE set to 152 KiB?

I guess the remainder between the SPL code and the SPL stack is for the
DDR firmware. Which explains why I get failures with SPL exceeding 152
KiB size.

Now I also understand the reason why the power init code was implemented
using legacy non-DM drivers in other i.MX8MP boards. I probably also
need to do this to save some space.

>> * Why is there no warning in my case?

Still, I fail to see why there isn't any error or where the size check
is even implemented.

>> * Any other ideas or pointers?
>>
>> Thanks for your help!
>>
>> Best regards
>> Frieder
> 
> 
> 

i.MX8MP SPL failures due to memory corruption/overflow?

[Frieder Schrempf]

Hi,

I'm trying to bring up a new board based on the i.MX8MP and I have an
issue I'm hoping someone can help solving.

I'm seeing failures in the early SPL code, usually in the DDR
initialization. Often they look like:

  U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +)
  Training FAILED
  Failed to initialize DDR RAM!
  ### ERROR ### Please RESET the board ###

But sometimes ddr_init() doesn't even return an error and only the
get_ram_size() afterwards which tries to allocate the memory fails.

The strange thing is that the issues appear or disappear
deterministically on the binary level. This means I sometimes get a
U-Boot binary which runs just fine in 100% of cases. Then I change for
example one of the following:

* Adding a single printf() somewhere in the boards spl.c
* Using the same binary but booting from SD card instead of USB loader
* Using the same source but switching from the OS cross compiler to the
one from Yocto/OE

And afterwards I get 100% failure rate with an error as described above.

My suspicion is that there is some memory corruption/conflict. My SPL is
quite large and I wonder if it exceeds some limit.

SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96, which
leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
warning about exceeding the SPL_MAX_SIZE.

My questions:

* Why is CONFIG_SPL_MAX_SIZE set to 152 KiB?
* Why is there no warning in my case?
* Any other ideas or pointers?

Thanks for your help!

Best regards
Frieder

Re: [PATCH 1/2] MAINTAINERS: Add entry for SPI NAND framework and drivers

[Frieder Schrempf]

On 27.02.23 16:24, Dario Binacchi wrote:
> Hi Frieder,
> 
> On Mon, Feb 13, 2023 at 10:47 AM Frieder Schrempf  wrote:
>>
>> From: Frieder Schrempf 
>>
>> In [1] Michael agreed on taking patches for SPI NAND through the RAW
>> NAND tree. Add a dedicated entry to the MAINTAINERS file which adds
>> Michael and Dario as maintainers and myself as reviewer.
>>
>> [1] 
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2023-February%2F508571.html=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4HDR%2BwouzdpqPFWPdvnZWRXSyjc94T%2F0pPHaXTYNrsM%3D=0
>>
>> Signed-off-by: Frieder Schrempf 
>> Cc: Jagan Teki 
>> Cc: Dario Binacchi 
>> Cc: Michael Nazzareno Trimarchi 
>> Cc: Tom Rini 
>> ---
>>  MAINTAINERS | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index b9c505d5fa..e40c401337 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1375,6 +1375,14 @@ T:   git 
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-spi.git=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RPFcfbNZYy7sKTu8PruDhcIDts7ufkzrUtPr1cR8yhw%3D=0
>>  F: drivers/spi/
>>  F: include/spi*
>>
>> +SPI NAND
>> +M: Dario Binacchi 
>> +M: Michael Trimarchi 
>> +R: Frieder Schrempf 
>> +S: Maintained
>> +T: git 
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-nand-flash.git=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pGjKSC7chQZ4%2BvT7QVNDdselY2P4llM5AeEMLTjzYUI%3D=0
>> +F: drivers/mtd/nand/spi/
>> +
> 
> Please re-send a single patch where you only consider drivers/mtd/nand
> for NAND FLASH
> in order to be as similar as possible to the Linux kernel MAINTAINERS file.
> Add to it "+R: Frieder Schrempf "

Actually, I don't really like to be listed as reviewer for the whole
NAND subsystem. I only have limited time and knowledge and SPI NAND is
an area I feel I can provide help.

> Neither SPI NAND nor  RAW NAND exists in the Linux kernel MAINTAINERS file.

Is there a requirement to have MAINTAINERS in sync with Linux?

Re: [PATCH] mtd: spinand: Fix display of unknown raw ID

[Frieder Schrempf]

On 13.02.23 18:30, Patrice Chotard wrote:
> In case ID is not found in manufacturer table, the raw ID is
> printed using %*phN format which is not supported by lib/vsprintf.c.
> The information displayed doesn't reflect the raw ID return by the
> unknown spi-nand.
> 
> Use %02x format instead, as done in spi-nor-core.c.
> 
> For example, before this patch:
>   ERROR: spi-nand: spi_nand flash@0: unknown raw ID f74ec040
> after
>   ERROR: spi-nand: spi_nand flash@0: unknown raw ID 00 c2 26 03
> 
> Fixes: 0a6d6bae0386 ("mtd: nand: Add core infrastructure to support SPI 
> NANDs")
> 
> Signed-off-by: Patrice Chotard 

Reviewed-by: Frieder Schrempf 

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> I will review
> 
> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini  wrote:
>>
>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
>>> Hi,
>>>
>>> On 10.01.23 12:58, Frieder Schrempf wrote:
>>>> From: Mikhail Kshevetskiy 
>>>>
>>>> Currently there are 3 different variants of read_id implementation:
>>>> 1. opcode only. Found in GD5FxGQ4xF.
>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>>>> 3. opcode + 1 dummy byte. Found in other currently supported chips.
>>>>
>>>> Original implementation was for variant 1 and let detect function
>>>> of chips with variant 2 and 3 to ignore the first byte. This isn't
>>>> robust:
>>>>
>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>>>> during read, chip will get a random id offset, and the entire id
>>>> buffer will shift by that offset, causing detect failure.
>>>>
>>>> 2. For chips of variant 1, if it happens to get a devid that equals
>>>> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
>>>> detected.
>>>>
>>>> This patch reworks detect procedure to address problems above. New
>>>> logic do detection for all variants separatedly, in 1-2-3 order.
>>>> Since all current detect methods do exactly the same id matching
>>>> procedure, unify them into core.c and remove detect method from
>>>> manufacture_ops.
>>>>
>>>> This is a rework of Chuanhong Guo  patch
>>>> submitted to linux kernel
>>>>
>>>> Signed-off-by: Mikhail Kshevetskiy 
>>>> Signed-off-by: Frieder Schrempf 
>>>
>>> +Cc: Jagan, Tom
>>>
>>> Who is supposed to pick up these patches? Some of them have been around
>>> for some months (before I resent them).
>>>
>>> There is no maintainer for drivers/mtd/spinand/ and no maintainer for
>>> drivers/mtd/ in general.
>>>
>>> In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't
>>> even add him to Cc, of course.
>>>
>>> Any ideas how to proceed?
>>
>> We don't have anyone dedicated to that area, yes, sadly. I've added
>> Michael and Dario as they've also been doing mtd-but-not-spi work of
>> late to see if they're interested. Or since you've long been working
>> here, would you like to more formally maintain the area? Thanks!
> 
> They can come from our tree. I will try to sort out all my duties weeked

Thanks Tom and Michael!

I just sent out a patch for the MAINTAINERS file to add Michael and
Dario as SPI NAND maintainers and myself as a reviewer. I hope that you
agree to handle it like this.

[PATCH 2/2] MAINTAINERS: Rename NAND FLASH to RAW NAND

[Frieder Schrempf]

From: Frieder Schrempf 

As there are other types of NAND flashes like SPI NAND, let's be
more specific.

Signed-off-by: Frieder Schrempf 
---
 MAINTAINERS | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e40c401337..00ad83a8c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1166,13 +1166,6 @@ S:   Maintained
 T: git https://source.denx.de/u-boot/custodians/u-boot-mmc.git
 F: drivers/mmc/
 
-NAND FLASH
-M: Dario Binacchi 
-M: Michael Trimarchi 
-S: Maintained
-T: git https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
-F: drivers/mtd/nand/raw/
-
 NETWORK
 M: Joe Hershberger 
 M: Ramon Fried 
@@ -1285,6 +1278,13 @@ S:   Maintained
 T: git https://source.denx.de/u-boot/custodians/u-boot-mpc85xx.git
 F: arch/powerpc/cpu/mpc85xx/
 
+RAW NAND
+M: Dario Binacchi 
+M: Michael Trimarchi 
+S: Maintained
+T: git https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
+F: drivers/mtd/nand/raw/
+
 RISC-V
 M: Rick Chen 
 M: Leo 
-- 
2.39.1

[PATCH 1/2] MAINTAINERS: Add entry for SPI NAND framework and drivers

[Frieder Schrempf]

From: Frieder Schrempf 

In [1] Michael agreed on taking patches for SPI NAND through the RAW
NAND tree. Add a dedicated entry to the MAINTAINERS file which adds
Michael and Dario as maintainers and myself as reviewer.

[1] https://lists.denx.de/pipermail/u-boot/2023-February/508571.html

Signed-off-by: Frieder Schrempf 
Cc: Jagan Teki 
Cc: Dario Binacchi 
Cc: Michael Nazzareno Trimarchi 
Cc: Tom Rini 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b9c505d5fa..e40c401337 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1375,6 +1375,14 @@ T:   git 
https://source.denx.de/u-boot/custodians/u-boot-spi.git
 F: drivers/spi/
 F: include/spi*
 
+SPI NAND
+M: Dario Binacchi 
+M: Michael Trimarchi 
+R: Frieder Schrempf 
+S: Maintained
+T: git https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
+F: drivers/mtd/nand/spi/
+
 SPI-NOR
 M: Jagan Teki 
 M: Vignesh R 
-- 
2.39.1

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

Hi,

On 10.01.23 12:58, Frieder Schrempf wrote:
> From: Mikhail Kshevetskiy 
> 
> Currently there are 3 different variants of read_id implementation:
> 1. opcode only. Found in GD5FxGQ4xF.
> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> 3. opcode + 1 dummy byte. Found in other currently supported chips.
> 
> Original implementation was for variant 1 and let detect function
> of chips with variant 2 and 3 to ignore the first byte. This isn't
> robust:
> 
> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> during read, chip will get a random id offset, and the entire id
> buffer will shift by that offset, causing detect failure.
> 
> 2. For chips of variant 1, if it happens to get a devid that equals
> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
> detected.
> 
> This patch reworks detect procedure to address problems above. New
> logic do detection for all variants separatedly, in 1-2-3 order.
> Since all current detect methods do exactly the same id matching
> procedure, unify them into core.c and remove detect method from
> manufacture_ops.
> 
> This is a rework of Chuanhong Guo  patch
> submitted to linux kernel
> 
> Signed-off-by: Mikhail Kshevetskiy 
> Signed-off-by: Frieder Schrempf 

+Cc: Jagan, Tom

Who is supposed to pick up these patches? Some of them have been around
for some months (before I resent them).

There is no maintainer for drivers/mtd/spinand/ and no maintainer for
drivers/mtd/ in general.

In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't
even add him to Cc, of course.

Any ideas how to proceed?

Thanks
Frieder

[PATCH] doc: sl-mx8mm: Fix mistake in merge conflict resolution

[Frieder Schrempf]

From: Frieder Schrempf 

There was a conflict between the following two commits, that wasn't
resolved correctly. Fix this.

a93985ddfcc3 ("doc: sl-mx8mm: Update the NXP TF-A source reference")
f0f461287eff ("imx: Suggest the NXP ATF github repo")

Signed-off-by: Frieder Schrempf 
Cc: Heinrich Schuchardt 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 doc/board/kontron/sl-mx8mm.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 09c50aa8b1..702db60fe3 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -40,7 +40,7 @@ There are two sources for the TF-A. Mainline and NXP. Get the 
one you prefer
 
 **NXP's imx-atf**
 
-1. Get TF-A from: https://github.com/nxp-imx/imx-atf, branch: imx_5.4.70_2.3.0
+1. Get TF-A from: https://github.com/nxp-imx/imx-atf, branch: lf_v2.6
 2. Build
 
   .. code-block:: bash
-- 
2.39.1

Re: [PATCH] imx: imx6ul: kontron-sl-mx6ul: Disable CONFIG_FSL_QSPI_AHB_FULL_MAP to fix SPI NAND read access

[Frieder Schrempf]

Hi Stefano,

On 14.11.22 13:01, Frieder Schrempf wrote:
> From: Frieder Schrempf 
> 
> The introduction of CONFIG_FSL_QSPI_AHB_FULL_MAP as default in:
> 
> def88bce094e ("spi: fsl_qspi: Support to use full AHB space on i.MX")
> 
> broke the SPI NAND read access on the Kontron SL i.MX6UL/ULL boards.
> Reading data from the flash returns garbage instead of the actual
> content. Fix this for now by disabling the introduced option.
> 
> In the long run this should be fixed globally.
> 
> Fixes: def88bce094e ("spi: fsl_qspi: Support to use full AHB space on i.MX")
> Signed-off-by: Frieder Schrempf 

Can you pick up this patch, please?

Thanks
Frieder

Re: [PATCH] imx: kontron-sl-mx8mm: Fix SD card IO voltage level

[Frieder Schrempf]

On 25.01.23 19:02, Marek Vasut wrote:
> On 1/25/23 18:30, Frieder Schrempf wrote:
>> Hi Marek,
> 
> Hi,
> 
>> On 25.01.23 18:15, Marek Vasut wrote:
>>> On 1/25/23 14:41, Frieder Schrempf wrote:
>>>> From: Frieder Schrempf 
>>>
>>> Subject tags should be ARM: dts: imx:
>>
>> Ok, how do I know? Because "git log arch/arm/dts" shows me that
>> ": :" is used quite often and it's what I used in the
>> past. But I'm happy to change it if "ARM: dts: imx:" is the way the
>> prefix should look like.
> 
> I just do what Linux does to keep things aligned.

Linux uses "arm64: dts:", but this doesn't match the directory structure
in U-Boot. Anyway keeping it the same as in Linux is probably best as
lots of DT patches are ported back and forth between the Linux and
U-Boot tree.

> 
>>>> The LDO5 of the PCA9450 PMIC can be switched between two different
>>>> voltage settings (defaulting to 1.8V and 3.3V) using an external
>>>> signal SD_VSEL that is connected to the VSELECT signal of the SD
>>>> card interface.
>>>>
>>>> As the regulator driver can't deal with both LDO registers (LDO5CTRL_H
>>>> and LDO5CTRL_L) it only uses one of them, which means reading the
>>>> voltage from the regulator can potentially return a value that does not
>>>> reflect the actual state of the LDO5 output.
>>>
>>> Can you fix the regulator driver ?
>>
>> So far, I didn't see a way how to do it, but with your suggestion below
>> it might work.
>>
>>>
>>>> In our case, after booting U-Boot we read 1.8V from the regulator
>>>> while in fact as the VSELECT signal is still low the regulator outputs
>>>> 3.3V. This confusion causes the MMC driver to think it is dealing with
>>>> a 1.8V-only device. This in turn leads to SD cards being addressed
>>>> with 1.8V IO levels even if UHS support is not available or disabled.
>>>>
>>>> Some cards with UHS support still work even if they are addressed
>>>> with 1.8V levels in non-UHS modes, but a lot of cards also fail with
>>>> timeout errors like:
>>>>
>>>>     Card did not respond to voltage select! : -110
>>>>
>>>> As a workaorund we disable the vqmmc regulator for now so we can make
>>>> sure no wrong values are read from the regulator. The switching
>>>> between 1.8V and 3.3V still works as the ESDHC driver sets the
>>>> VSELECT signal accordingly.
>>>>
>>>> Signed-off-by: Frieder Schrempf 
>>>> ---
>>>> By the way: I suspect that other boards using the PCA9450 might also
>>>> be affected
>>>> by this. I didn't find a nice generic solution so far. It would be
>>>> possible to
>>>> patch the pca9450 driver to use the PCA9450_LDO5CTRL_L instead of the
>>>> PCA9450_LDO5CTRL_H register for LDO5. This would fix this particular
>>>> case,
>>>> but still not the root problem of the regulator driver returning wrong
>>>> values.
>>>> So if anyone got some idea how to properly handle this, let me know.
>>>> The same issue is also present in Linux. While I didn't notice any
>>>> problems
>>>> with the SD card being addressed with incorrect voltage levels so far,
>>>> reading the regulator doesn't return the correct value if VSELECT is
>>>> low.
>>>
>>> Configure VSELECT pinmux such that it is a function, as it is right now,
>>> MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT or similar, (so SD controller
>>> driver can operate the pin via SD controller), but set SION bit so GPIO
>>> controller can read its state (activate bit 30), i.e.:
>>> MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x4004
>>>
>>> Use sd-vsel-gpios property of PMIC, claim the VSELECT as GPIO in PMIC
>>> driver (this won't change pinmux, the pin would still be configured as
>>> function, but SION bit would allow you to read its state), read its
>>> state, and return the correct LDO5CTRL_H/LDO5CTRL_L value based on that.
>>
>> Good idea, I will try that.
>>
>>>
>>> If this works, then:
>>>  arm64: dts: imx8mp: Drop sd-vsel-gpios from *
>>> Linux kernel patches should not be applied.
>>
>> Yes, but we could also just revert this change once the fix suggested
>> above works and is in place. Until then the sd-vsel-gpios doesn't do
>> anything.
> 
> Please give it a go, let's see if that's the way to go.

So far it looks like this would work. I came up with these patches here
[1]. I don't know if I really should send fixes for other boards (maybe
as RFC). It looks like no one else has reported such problems on other
boards so far and I can't really tell if all are affected the same way
as our Kontron boards.

So if anyone can do some tests on their hardware that would be great.

And there is also still some work to do for applying the same changes in
Linux.

[1] https://github.com/fschrempf/u-boot/commits/pca9450-sd-vsel-fixups

Re: [PATCH] imx: kontron-sl-mx8mm: Fix SD card IO voltage level

[Frieder Schrempf]

Hi Marek,

On 25.01.23 18:15, Marek Vasut wrote:
> On 1/25/23 14:41, Frieder Schrempf wrote:
>> From: Frieder Schrempf 
> 
> Subject tags should be ARM: dts: imx:

Ok, how do I know? Because "git log arch/arm/dts" shows me that
": :" is used quite often and it's what I used in the
past. But I'm happy to change it if "ARM: dts: imx:" is the way the
prefix should look like.

> 
>> The LDO5 of the PCA9450 PMIC can be switched between two different
>> voltage settings (defaulting to 1.8V and 3.3V) using an external
>> signal SD_VSEL that is connected to the VSELECT signal of the SD
>> card interface.
>>
>> As the regulator driver can't deal with both LDO registers (LDO5CTRL_H
>> and LDO5CTRL_L) it only uses one of them, which means reading the
>> voltage from the regulator can potentially return a value that does not
>> reflect the actual state of the LDO5 output.
> 
> Can you fix the regulator driver ?

So far, I didn't see a way how to do it, but with your suggestion below
it might work.

> 
>> In our case, after booting U-Boot we read 1.8V from the regulator
>> while in fact as the VSELECT signal is still low the regulator outputs
>> 3.3V. This confusion causes the MMC driver to think it is dealing with
>> a 1.8V-only device. This in turn leads to SD cards being addressed
>> with 1.8V IO levels even if UHS support is not available or disabled.
>>
>> Some cards with UHS support still work even if they are addressed
>> with 1.8V levels in non-UHS modes, but a lot of cards also fail with
>> timeout errors like:
>>
>>    Card did not respond to voltage select! : -110
>>
>> As a workaorund we disable the vqmmc regulator for now so we can make
>> sure no wrong values are read from the regulator. The switching
>> between 1.8V and 3.3V still works as the ESDHC driver sets the
>> VSELECT signal accordingly.
>>
>> Signed-off-by: Frieder Schrempf 
>> ---
>> By the way: I suspect that other boards using the PCA9450 might also
>> be affected
>> by this. I didn't find a nice generic solution so far. It would be
>> possible to
>> patch the pca9450 driver to use the PCA9450_LDO5CTRL_L instead of the
>> PCA9450_LDO5CTRL_H register for LDO5. This would fix this particular
>> case,
>> but still not the root problem of the regulator driver returning wrong
>> values.
>> So if anyone got some idea how to properly handle this, let me know.
>> The same issue is also present in Linux. While I didn't notice any
>> problems
>> with the SD card being addressed with incorrect voltage levels so far,
>> reading the regulator doesn't return the correct value if VSELECT is low.
> 
> Configure VSELECT pinmux such that it is a function, as it is right now,
> MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT or similar, (so SD controller
> driver can operate the pin via SD controller), but set SION bit so GPIO
> controller can read its state (activate bit 30), i.e.:
> MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x4004
> 
> Use sd-vsel-gpios property of PMIC, claim the VSELECT as GPIO in PMIC
> driver (this won't change pinmux, the pin would still be configured as
> function, but SION bit would allow you to read its state), read its
> state, and return the correct LDO5CTRL_H/LDO5CTRL_L value based on that.

Good idea, I will try that.

> 
> If this works, then:
>     arm64: dts: imx8mp: Drop sd-vsel-gpios from *
> Linux kernel patches should not be applied.

Yes, but we could also just revert this change once the fix suggested
above works and is in place. Until then the sd-vsel-gpios doesn't do
anything.

Thanks
Frieder

[PATCH] imx: kontron-sl-mx8mm: Fix SD card IO voltage level

[Frieder Schrempf]

From: Frieder Schrempf 

The LDO5 of the PCA9450 PMIC can be switched between two different
voltage settings (defaulting to 1.8V and 3.3V) using an external
signal SD_VSEL that is connected to the VSELECT signal of the SD
card interface.

As the regulator driver can't deal with both LDO registers (LDO5CTRL_H
and LDO5CTRL_L) it only uses one of them, which means reading the
voltage from the regulator can potentially return a value that does not
reflect the actual state of the LDO5 output.

In our case, after booting U-Boot we read 1.8V from the regulator
while in fact as the VSELECT signal is still low the regulator outputs
3.3V. This confusion causes the MMC driver to think it is dealing with
a 1.8V-only device. This in turn leads to SD cards being addressed
with 1.8V IO levels even if UHS support is not available or disabled.

Some cards with UHS support still work even if they are addressed
with 1.8V levels in non-UHS modes, but a lot of cards also fail with
timeout errors like:

  Card did not respond to voltage select! : -110

As a workaorund we disable the vqmmc regulator for now so we can make
sure no wrong values are read from the regulator. The switching
between 1.8V and 3.3V still works as the ESDHC driver sets the
VSELECT signal accordingly.

Signed-off-by: Frieder Schrempf 
---
By the way: I suspect that other boards using the PCA9450 might also be affected
by this. I didn't find a nice generic solution so far. It would be possible to
patch the pca9450 driver to use the PCA9450_LDO5CTRL_L instead of the
PCA9450_LDO5CTRL_H register for LDO5. This would fix this particular case,
but still not the root problem of the regulator driver returning wrong values.
So if anyone got some idea how to properly handle this, let me know.
The same issue is also present in Linux. While I didn't notice any problems
with the SD card being addressed with incorrect voltage levels so far,
reading the regulator doesn't return the correct value if VSELECT is low.
---
---
 arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
index 5b8b472159..8321424649 100644
--- a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
@@ -137,6 +137,12 @@
 
  {
u-boot,dm-spl;
+   /*
+* Delete the reference to the IO voltage regulator in order to prevent
+* wrong information being passed to the MMC driver by reading the 
current
+* voltage of the PCA9450 LDO5.
+*/
+   /delete-property/ vqmmc-supply;
 };
 
  {
-- 
2.39.1

Re: [PATCH] imx: Suggest the NXP ATF github repo

[Frieder Schrempf]

On 13.01.23 01:52, Fabio Estevam wrote:
> As explained in the text at the bottom of the page 
> https://source.codeaurora.org/external/imx/imx-atf:
> 
> "QUIC repositories on this site will not receive any updates after
> March 31, 2022, and will be deleted on March 31, 2023."
> 
> Point to the NXP ATF github repo instead.
> 
> Signed-off-by: Fabio Estevam 

Reviewed-by: Frieder Schrempf 

[PATCH v2 6/6] doc: sl-mx8mm: Add CROSS_COMPILE to U-Boot make call and improve comment

[Frieder Schrempf]

From: Frieder Schrempf 

Add the CROSS_COMPILE flag as we assume we build in a cross environment.
Also improve the comment about copying the binary to SD card.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index a8a3d5fc24..b7346d8cfb 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -79,9 +79,9 @@ Build U-Boot
 .. code-block:: bash
 
$ make kontron-sl-mx8mm_defconfig
-   $ make
+   $ make CROSS_COMPILE=aarch64-linux-gnu-
 
-Burn the flash.bin to SD card at an offset of 33 KiB:
+Copy the flash.bin to SD card at an offset of 33 KiB:
 
 .. code-block:: bash
 
-- 
2.39.0

[PATCH v2 5/6] doc: sl-mx8mm: Add guide for copying the bootloader to SPI NOR

[Frieder Schrempf]

From: Frieder Schrempf 

This adds a guide for copying the raw bootloader image on the SD card
to the SPI NOR using U-Boot itself.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 76cc49f9d7..a8a3d5fc24 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -90,7 +90,39 @@ Burn the flash.bin to SD card at an offset of 33 KiB:
 Boot
 
 
-Put the SD card in the slot on the board and apply power.
+Put the SD card in the slot on the board and apply power. Check the serial
+console for output.
+
+Flash the Bootloader to SPI NOR
+^^^
+
+1. Determine and note the exact size of the ``flash.bin`` image in bytes (e.g.
+   by running ``ls -l flash.bin``)
+
+2. On the U-Boot CLI copy the bootloader from SD card to RAM:
+
+   .. code-block::
+
+  mmc dev 1
+  mmc read $loadaddr 0x42 0x1000
+
+3. Erase the SPI NOR flash:
+
+   .. code-block::
+
+  sf probe
+  sf erase 0x0 0x20
+
+4. Copy the bootloader from RAM to SPI NOR. For the last parameter of the
+   command, use the size determined in step 1 in **hexadecimal notation**:
+
+   .. code-block::
+
+  sf write $loadaddr 0x400 0x13B6F0
+
+.. note::
+
+   To be able to boot from SPI NOR the OTP fuses need to be set accordingly.
 
 Further Information
 ---
-- 
2.39.0

[PATCH v2 4/6] doc: sl-mx8mm: Update references to latest DDR firmware 8.18

[Frieder Schrempf]

From: Frieder Schrempf 

Use the latest firmware available from NXP.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index bb718f104c..76cc49f9d7 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -65,10 +65,13 @@ Get the DDR firmware
 
 .. code-block:: bash
 
-   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
-   $ chmod +x firmware-imx-8.9.bin
-   $ ./firmware-imx-8.9.bin
-   $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
+   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.18.bin
+   $ chmod +x firmware-imx-8.18.bin
+   $ ./firmware-imx-8.18.bin
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem.bin 
$(builddir)
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem.bin 
$(builddir)
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem.bin 
$(builddir)
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem.bin 
$(builddir)
 
 Build U-Boot
 
-- 
2.39.0

[PATCH v2 2/6] doc: sl-mx8mm: Add note about using cross toolchain

[Frieder Schrempf]

From: Frieder Schrempf 

This clarifies the usage of a cross toolchain to build U-Boot
and TF-A.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 75ca0f174a..bcaf5de4e7 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -20,6 +20,12 @@ Quick Start
 - Build U-Boot
 - Boot
 
+.. note::
+
+   To build on a x86-64 host machine, you need a GNU cross toolchain for the
+   target architecture (aarch64). Check your distros package manager or
+   download and install the necessary tools (``aarch64-linux-gnu-*``) manually.
+
 Get and Build the Trusted Firmware-A (TF-A)
 ^^^
 
-- 
2.39.0

[PATCH v2 3/6] doc: sl-mx8mm: Update the NXP TF-A source reference

[Frieder Schrempf]

From: Frieder Schrempf 

Use the latest version of the NXP TF-A code and add a note about
quirks with GCC 12.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index bcaf5de4e7..bb718f104c 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -34,15 +34,20 @@ Note: builddir is U-Boot build directory (source directory 
for in-tree builds)
 There are two sources for the TF-A. Mainline and NXP. Get the one you prefer
 (support and features might differ).
 
+.. note::
+
+   If you are using GCC 12 and you get compiler/linker errors, try to add the
+   following arguments to your make command as workaround:
+   ``CFLAGS="-Wno-array-bounds" LDFLAGS="--no-warn-rwx-segments"``
+
 **NXP's imx-atf**
 
-1. Get TF-A from: https://github.com/nxp-imx/imx-atf, branch: imx_5.4.70_2.3.0
-2. Apply the patch to select the correct UART for the console, otherwise the 
TF-A will lock up during boot.
-3. Build
+1. Get TF-A from: https://github.com/nxp-imx/imx-atf, branch: lf_v2.6
+2. Build
 
   .. code-block:: bash
 
- $ make PLAT=imx8mm bl31
+ $ make PLAT=imx8mm CROSS_COMPILE=aarch64-linux-gnu- 
IMX_BOOT_UART_BASE="0x3088" bl31
  $ cp build/imx8mm/release/bl31.bin $(builddir)
 
 **Mainline TF-A**
-- 
2.39.0

[PATCH v2 1/6] doc: sl-mx8mm: Mention OSM 1.1 support

[Frieder Schrempf]

From: Frieder Schrempf 

The latest revision of the SoM is compliant to OSM 1.1.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 327466c536..75ca0f174a 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -9,7 +9,7 @@ with an i.MX8M-Mini SoC, 1/2/4 GB LPDDR4 RAM, SPI NOR, eMMC and 
PMIC.
 The matching evaluation boards (Board-Line, BL) have two Ethernet ports,
 USB 2.0, HDMI/LVDS, SD card, CAN, RS485, RS232 and much more.
 
-The OSM-S i.MX8MM is compliant to the Open Standard Module (OSM) 1.0
+The OSM-S i.MX8MM is compliant to the Open Standard Module (OSM) 1.1
 specification, size S (https://sget.org/standards/osm).
 
 Quick Start
-- 
2.39.0

[PATCH v2 0/6] Some documentation updates for Kontron i.MX8MM hardware

[Frieder Schrempf]

From: Frieder Schrempf 

This depends on Fabio's doc patch [1].

Changes in v2:
  * Rebase onto Fabio's patch [1]
  * Remove dot in subject line of patch 6

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20230113005223.1979599-1-feste...@denx.de/

Frieder Schrempf (6):
  doc: sl-mx8mm: Mention OSM 1.1 support
  doc: sl-mx8mm: Add note about using cross toolchain
  doc: sl-mx8mm: Update the NXP TF-A source reference
  doc: sl-mx8mm: Update references to latest DDR firmware 8.18
  doc: sl-mx8mm: Add guide for copying the bootloader to SPI NOR
  doc: sl-mx8mm: Add CROSS_COMPILE to U-Boot make call and improve
comment

 doc/board/kontron/sl-mx8mm.rst | 70 --
 1 file changed, 58 insertions(+), 12 deletions(-)

-- 
2.39.0

Re: [PATCH 3/6] doc: sl-mx8mm: Update the NXP TF-A source reference

[Frieder Schrempf]

Hi Fabio,

On 19.01.23 12:04, Fabio Estevam wrote:
> Hi Frieder,
> 
> On 19/01/2023 07:52, Frieder Schrempf wrote:
> 
>> -1. Get TF-A from:
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fimx-atf=05%7C01%7Cfrieder.schrempf%40kontron.de%7C886dc83b607c4f772e2208dafa0cebf9%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638097230646779519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=uh6vIvM4qOP%2BCjmOo849%2FfHkdnGV5vcRliuxflm6bBI%3D=0,
>> branch: imx_5.4.70_2.3.0
>> -2. Apply the patch to select the correct UART for the console,
>> otherwise the TF-A will lock up during boot.
>> -3. Build
>> +1. Get TF-A from:
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnxp-imx%2Fimx-atf.git=05%7C01%7Cfrieder.schrempf%40kontron.de%7C886dc83b607c4f772e2208dafa0cebf9%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638097230646935721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=OTGK8JxjMP%2FjphmZb96PPsUMpyMrKP%2FYRtzampVhJ64%3D=0,
>>  branch: lf_v2.6
>> +2. Build
> 
> Maybe this will conflict with the earlier patch I sent:

Indeed! I somehow missed your patch in my inbox...
I think I will just rebase my patch onto yours.

Thanks
Frieder

[PATCH 6/6] doc: sl-mx8mm: Add CROSS_COMPILE to U-Boot make call and improve comment.

[Frieder Schrempf]

From: Frieder Schrempf 

Add the CROSS_COMPILE flag as we assume we build in a cross environment.
Also improve the comment about copying the binary to SD card.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 439f70142a..d7f9930323 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -79,9 +79,9 @@ Build U-Boot
 .. code-block:: bash
 
$ make kontron-sl-mx8mm_defconfig
-   $ make
+   $ make CROSS_COMPILE=aarch64-linux-gnu-
 
-Burn the flash.bin to SD card at an offset of 33 KiB:
+Copy the flash.bin to SD card at an offset of 33 KiB:
 
 .. code-block:: bash
 
-- 
2.39.0

[PATCH 5/6] doc: sl-mx8mm: Add guide for copying the bootloader to SPI NOR

[Frieder Schrempf]

From: Frieder Schrempf 

This adds a guide for copying the raw bootloader image on the SD card
to the SPI NOR using U-Boot itself.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 8ed08a66a3..439f70142a 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -90,7 +90,39 @@ Burn the flash.bin to SD card at an offset of 33 KiB:
 Boot
 
 
-Put the SD card in the slot on the board and apply power.
+Put the SD card in the slot on the board and apply power. Check the serial
+console for output.
+
+Flash the Bootloader to SPI NOR
+^^^
+
+1. Determine and note the exact size of the ``flash.bin`` image in bytes (e.g.
+   by running ``ls -l flash.bin``)
+
+2. On the U-Boot CLI copy the bootloader from SD card to RAM:
+
+   .. code-block::
+
+  mmc dev 1
+  mmc read $loadaddr 0x42 0x1000
+
+3. Erase the SPI NOR flash:
+
+   .. code-block::
+
+  sf probe
+  sf erase 0x0 0x20
+
+4. Copy the bootloader from RAM to SPI NOR. For the last parameter of the
+   command, use the size determined in step 1 in **hexadecimal notation**:
+
+   .. code-block::
+
+  sf write $loadaddr 0x400 0x13B6F0
+
+.. note::
+
+   To be able to boot from SPI NOR the OTP fuses need to be set accordingly.
 
 Further Information
 ---
-- 
2.39.0

[PATCH 1/6] doc: sl-mx8mm: Mention OSM 1.1 support

[Frieder Schrempf]

From: Frieder Schrempf 

The latest revision of the SoM is compliant to OSM 1.1.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index f022e0979b..57143b973a 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -9,7 +9,7 @@ with an i.MX8M-Mini SoC, 1/2/4 GB LPDDR4 RAM, SPI NOR, eMMC and 
PMIC.
 The matching evaluation boards (Board-Line, BL) have two Ethernet ports,
 USB 2.0, HDMI/LVDS, SD card, CAN, RS485, RS232 and much more.
 
-The OSM-S i.MX8MM is compliant to the Open Standard Module (OSM) 1.0
+The OSM-S i.MX8MM is compliant to the Open Standard Module (OSM) 1.1
 specification, size S (https://sget.org/standards/osm).
 
 Quick Start
-- 
2.39.0

[PATCH 4/6] doc: sl-mx8mm: Update references to latest DDR firmware 8.18

[Frieder Schrempf]

From: Frieder Schrempf 

Use the latest firmware available from NXP.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 63b14230e4..8ed08a66a3 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -65,10 +65,13 @@ Get the DDR firmware
 
 .. code-block:: bash
 
-   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
-   $ chmod +x firmware-imx-8.9.bin
-   $ ./firmware-imx-8.9.bin
-   $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
+   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.18.bin
+   $ chmod +x firmware-imx-8.18.bin
+   $ ./firmware-imx-8.18.bin
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem.bin 
$(builddir)
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem.bin 
$(builddir)
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem.bin 
$(builddir)
+   $ cp firmware-imx-8.18/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem.bin 
$(builddir)
 
 Build U-Boot
 
-- 
2.39.0

[PATCH 3/6] doc: sl-mx8mm: Update the NXP TF-A source reference

[Frieder Schrempf]

From: Frieder Schrempf 

Use the latest version of the NXP TF-A code and add a note about
quirks with GCC 12.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index ff6f01d3b7..63b14230e4 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -34,15 +34,20 @@ Note: builddir is U-Boot build directory (source directory 
for in-tree builds)
 There are two sources for the TF-A. Mainline and NXP. Get the one you prefer
 (support and features might differ).
 
+.. note::
+
+   If you are using GCC 12 and you get compiler/linker errors, try to add the
+   following arguments to your make command as workaround:
+   ``CFLAGS="-Wno-array-bounds" LDFLAGS="--no-warn-rwx-segments"``
+
 **NXP's imx-atf**
 
-1. Get TF-A from: https://source.codeaurora.org/external/imx/imx-atf, branch: 
imx_5.4.70_2.3.0
-2. Apply the patch to select the correct UART for the console, otherwise the 
TF-A will lock up during boot.
-3. Build
+1. Get TF-A from: https://github.com/nxp-imx/imx-atf.git, branch: lf_v2.6
+2. Build
 
   .. code-block:: bash
 
- $ make PLAT=imx8mm bl31
+ $ make PLAT=imx8mm CROSS_COMPILE=aarch64-linux-gnu- 
IMX_BOOT_UART_BASE="0x3088" bl31
  $ cp build/imx8mm/release/bl31.bin $(builddir)
 
 **Mainline TF-A**
-- 
2.39.0

[PATCH 2/6] doc: sl-mx8mm: Add note about using cross toolchain

[Frieder Schrempf]

From: Frieder Schrempf 

This clarifies the usage of a cross toolchain to build U-Boot
and TF-A.

Signed-off-by: Frieder Schrempf 
---
 doc/board/kontron/sl-mx8mm.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 57143b973a..ff6f01d3b7 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -20,6 +20,12 @@ Quick Start
 - Build U-Boot
 - Boot
 
+.. note::
+
+   To build on a x86-64 host machine, you need a GNU cross toolchain for the
+   target architecture (aarch64). Check your distros package manager or
+   download and install the necessary tools (``aarch64-linux-gnu-*``) manually.
+
 Get and Build the Trusted Firmware-A (TF-A)
 ^^^
 
-- 
2.39.0

[PATCH 3/5] mtd/spinand: sync supported devices with linux-5.15.43

[Frieder Schrempf]

From: Mikhail Kshevetskiy 

This adds more supported spinand devices from the Linux kernel
implementation.

This does not include the latest kernel implementation as this would
require a substantial amount of extra work due to the missing
ECC engine abstraction layer in U-Boot.

Signed-off-by: Mikhail Kshevetskiy 
Signed-off-by: Frieder Schrempf  (commit message)
---
 drivers/mtd/nand/spi/Makefile |   2 +-
 drivers/mtd/nand/spi/core.c   |   1 +
 drivers/mtd/nand/spi/gigadevice.c | 223 ++
 drivers/mtd/nand/spi/macronix.c   | 145 +--
 drivers/mtd/nand/spi/micron.c | 144 +--
 drivers/mtd/nand/spi/paragon.c| 133 ++
 drivers/mtd/nand/spi/toshiba.c|  38 ++---
 drivers/mtd/nand/spi/winbond.c|   6 +-
 include/linux/mtd/nand.h  |   5 +-
 include/linux/mtd/spinand.h   |  31 +
 10 files changed, 626 insertions(+), 102 deletions(-)
 create mode 100644 drivers/mtd/nand/spi/paragon.c

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 6c65b187e86..3051de4f7ef 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
-spinand-objs := core.o gigadevice.o macronix.o micron.o toshiba.o winbond.o
+spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o toshiba.o 
winbond.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 886e66e7847..631ccfdab6a 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -824,6 +824,7 @@ static const struct spinand_manufacturer 
*spinand_manufacturers[] = {
_spinand_manufacturer,
_spinand_manufacturer,
_spinand_manufacturer,
+   _spinand_manufacturer,
_spinand_manufacturer,
_spinand_manufacturer,
 };
diff --git a/drivers/mtd/nand/spi/gigadevice.c 
b/drivers/mtd/nand/spi/gigadevice.c
index 43b353a3e7e..f2ecf47f8d4 100644
--- a/drivers/mtd/nand/spi/gigadevice.c
+++ b/drivers/mtd/nand/spi/gigadevice.c
@@ -7,13 +7,13 @@
  */
 
 #ifndef __UBOOT__
-#include 
 #include 
 #include 
 #endif
 #include 
 
 #define SPINAND_MFR_GIGADEVICE 0xC8
+
 #define GD5FXGQ4XA_STATUS_ECC_1_7_BITFLIPS (1 << 4)
 #define GD5FXGQ4XA_STATUS_ECC_8_BITFLIPS   (3 << 4)
 
@@ -22,8 +22,12 @@
 
 #define GD5FXGQXXEXXG_REG_STATUS2  0xf0
 
-/* Q4 devices, QUADIO: Dummy bytes valid for 1 and 2 GBit variants */
-static SPINAND_OP_VARIANTS(gd5fxgq4_read_cache_variants,
+#define GD5FXGQ4UXFXXG_STATUS_ECC_MASK (7 << 4)
+#define GD5FXGQ4UXFXXG_STATUS_ECC_NO_BITFLIPS  (0 << 4)
+#define GD5FXGQ4UXFXXG_STATUS_ECC_1_3_BITFLIPS (1 << 4)
+#define GD5FXGQ4UXFXXG_STATUS_ECC_UNCOR_ERROR  (7 << 4)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
@@ -31,14 +35,13 @@ static SPINAND_OP_VARIANTS(gd5fxgq4_read_cache_variants,
SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
 
-/* Q5 devices, QUADIO: Dummy bytes only valid for 1 GBit variants */
-static SPINAND_OP_VARIANTS(gd5f1gq5_read_cache_variants,
-   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
-   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+static SPINAND_OP_VARIANTS(read_cache_variants_f,
+   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X4_OP_3A(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
-   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
-   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
-   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+   SPINAND_PAGE_READ_FROM_CACHE_X2_OP_3A(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP_3A(true, 0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP_3A(false, 0, 0, NULL, 0));
 
 static SPINAND_OP_VARIANTS(write_cache_variants,
SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
@@ -48,7 +51,65 @@ static SPINAND_OP_VARIANTS(update_cache_variants,
SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
SPINAND_PROG_LOAD(false, 0, NULL, 0));
 
-static int gd5fxgqxxexxg_ooblayout_ecc(struct mtd_info *mtd, int section,
+static int gd5fxgq4xa_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+   if (section > 3)
+   return -ERANGE;
+
+   region->offset = (16 * section) + 8;
+   region->length = 8;
+
+   return 0;
+}
+
+static int gd5fxgq4xa_oob

[PATCH 5/5] mtd: spinand: winbond: add Winbond W25N02KV flash support

[Frieder Schrempf]

From: Mikhail Kshevetskiy 

Add support of Winbond W25N02KV flash

Signed-off-by: Mikhail Kshevetskiy 
Reviewed-by: Frieder Schrempf 
Signed-off-by: Miquel Raynal 
Link: 
https://lore.kernel.org/linux-mtd/20221010105110.446674-2-mikhail.kshevets...@iopsys.eu
Signed-off-by: Frieder Schrempf  (U-Boot port)
---
 drivers/mtd/nand/spi/winbond.c | 76 ++
 1 file changed, 76 insertions(+)

diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
index 3c0ae545cdb..dd4ed257a83 100644
--- a/drivers/mtd/nand/spi/winbond.c
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #endif
+#include 
 #include 
 
 #define SPINAND_MFR_WINBOND0xEF
@@ -76,6 +77,72 @@ static int w25m02gv_select_target(struct spinand_device 
*spinand,
return spi_mem_exec_op(spinand->slave, );
 }
 
+static int w25n02kv_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+   if (section > 3)
+   return -ERANGE;
+
+   region->offset = 64 + (16 * section);
+   region->length = 13;
+
+   return 0;
+}
+
+static int w25n02kv_ooblayout_free(struct mtd_info *mtd, int section,
+  struct mtd_oob_region *region)
+{
+   if (section > 3)
+   return -ERANGE;
+
+   region->offset = (16 * section) + 2;
+   region->length = 14;
+
+   return 0;
+}
+
+static const struct mtd_ooblayout_ops w25n02kv_ooblayout = {
+   .ecc = w25n02kv_ooblayout_ecc,
+   .rfree = w25n02kv_ooblayout_free,
+};
+
+static int w25n02kv_ecc_get_status(struct spinand_device *spinand,
+  u8 status)
+{
+   struct nand_device *nand = spinand_to_nand(spinand);
+   u8 mbf = 0;
+   struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, );
+
+   switch (status & STATUS_ECC_MASK) {
+   case STATUS_ECC_NO_BITFLIPS:
+   return 0;
+
+   case STATUS_ECC_UNCOR_ERROR:
+   return -EBADMSG;
+
+   case STATUS_ECC_HAS_BITFLIPS:
+   /*
+* Let's try to retrieve the real maximum number of bitflips
+* in order to avoid forcing the wear-leveling layer to move
+* data around if it's not necessary.
+*/
+   if (spi_mem_exec_op(spinand->slave, ))
+   return nand->eccreq.strength;
+
+   mbf >>= 4;
+
+   if (WARN_ON(mbf > nand->eccreq.strength || !mbf))
+   return nand->eccreq.strength;
+
+   return mbf;
+
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
 static const struct spinand_info winbond_spinand_table[] = {
SPINAND_INFO("W25M02GV",
 SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xab, 0x21),
@@ -96,6 +163,15 @@ static const struct spinand_info winbond_spinand_table[] = {
  _cache_variants),
 0,
 SPINAND_ECCINFO(_ooblayout, NULL)),
+   SPINAND_INFO("W25N02KV",
+SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xaa, 0x22),
+NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout, 
w25n02kv_ecc_get_status)),
 };
 
 static int winbond_spinand_init(struct spinand_device *spinand)
-- 
2.39.0

[PATCH 4/5] mtd: spinand: winbond: fix flash identification

[Frieder Schrempf]

From: Mikhail Kshevetskiy 

Winbond uses 3 bytes to identify flash: vendor_id, dev_id_0, dev_id_1,
but current driver uses only first 2 bytes of it for devices
identification. As result Winbond W25N02KV flash (id_bytes: EF, AA, 22)
is identified as W25N01GV (id_bytes: EF, AA, 21).

Fix this by adding missed identification bytes.

Signed-off-by: Mikhail Kshevetskiy 
Reviewed-by: Frieder Schrempf 
Signed-off-by: Miquel Raynal 
Link: 
https://lore.kernel.org/linux-mtd/20221010105110.446674-1-mikhail.kshevets...@iopsys.eu
Signed-off-by: Frieder Schrempf  (U-Boot port)
---
 drivers/mtd/nand/spi/winbond.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
index 4e5a6eaecd7..3c0ae545cdb 100644
--- a/drivers/mtd/nand/spi/winbond.c
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -78,7 +78,7 @@ static int w25m02gv_select_target(struct spinand_device 
*spinand,
 
 static const struct spinand_info winbond_spinand_table[] = {
SPINAND_INFO("W25M02GV",
-SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xab),
+SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xab, 0x21),
 NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 2),
 NAND_ECCREQ(1, 512),
 SPINAND_INFO_OP_VARIANTS(_cache_variants,
@@ -88,7 +88,7 @@ static const struct spinand_info winbond_spinand_table[] = {
 SPINAND_ECCINFO(_ooblayout, NULL),
 SPINAND_SELECT_TARGET(w25m02gv_select_target)),
SPINAND_INFO("W25N01GV",
-SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xaa),
+SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xaa, 0x21),
 NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
 NAND_ECCREQ(1, 512),
 SPINAND_INFO_OP_VARIANTS(_cache_variants,
-- 
2.39.0

[PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

From: Mikhail Kshevetskiy 

Currently there are 3 different variants of read_id implementation:
1. opcode only. Found in GD5FxGQ4xF.
2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
3. opcode + 1 dummy byte. Found in other currently supported chips.

Original implementation was for variant 1 and let detect function
of chips with variant 2 and 3 to ignore the first byte. This isn't
robust:

1. For chips of variant 2, if SPI master doesn't keep MOSI low
during read, chip will get a random id offset, and the entire id
buffer will shift by that offset, causing detect failure.

2. For chips of variant 1, if it happens to get a devid that equals
to manufacture id of variant 2 or 3 chips, it'll get incorrectly
detected.

This patch reworks detect procedure to address problems above. New
logic do detection for all variants separatedly, in 1-2-3 order.
Since all current detect methods do exactly the same id matching
procedure, unify them into core.c and remove detect method from
manufacture_ops.

This is a rework of Chuanhong Guo  patch
submitted to linux kernel

Signed-off-by: Mikhail Kshevetskiy 
Signed-off-by: Frieder Schrempf 
---
 drivers/mtd/nand/spi/core.c   | 104 +++---
 drivers/mtd/nand/spi/gigadevice.c |  30 ++---
 drivers/mtd/nand/spi/macronix.c   |  45 +
 drivers/mtd/nand/spi/micron.c |  50 ++
 drivers/mtd/nand/spi/toshiba.c|  66 +--
 drivers/mtd/nand/spi/winbond.c|  34 ++
 include/linux/mtd/spinand.h   |  66 ---
 7 files changed, 187 insertions(+), 208 deletions(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 134bf22c805..d92de9c24e3 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #else
@@ -451,9 +452,11 @@ out:
return status & STATUS_BUSY ? -ETIMEDOUT : 0;
 }
 
-static int spinand_read_id_op(struct spinand_device *spinand, u8 *buf)
+static int spinand_read_id_op(struct spinand_device *spinand, u8 naddr,
+ u8 ndummy, u8 *buf)
 {
-   struct spi_mem_op op = SPINAND_READID_OP(0, spinand->scratchbuf,
+   struct spi_mem_op op = SPINAND_READID_OP(naddr, ndummy,
+spinand->scratchbuf,
 SPINAND_MAX_ID_LEN);
int ret;
 
@@ -807,21 +810,6 @@ static int spinand_mtd_block_isreserved(struct mtd_info 
*mtd, loff_t offs)
return ret;
 }
 
-const struct spi_mem_op *
-spinand_find_supported_op(struct spinand_device *spinand,
- const struct spi_mem_op *ops,
- unsigned int nops)
-{
-   unsigned int i;
-
-   for (i = 0; i < nops; i++) {
-   if (spi_mem_supports_op(spinand->slave, [i]))
-   return [i];
-   }
-
-   return NULL;
-}
-
 static const struct nand_ops spinand_ops = {
.erase = spinand_erase,
.markbad = spinand_markbad,
@@ -836,24 +824,62 @@ static const struct spinand_manufacturer 
*spinand_manufacturers[] = {
_spinand_manufacturer,
 };
 
-static int spinand_manufacturer_detect(struct spinand_device *spinand)
+static int spinand_manufacturer_match(struct spinand_device *spinand,
+ enum spinand_readid_method rdid_method)
 {
+   u8 *id = spinand->id.data;
unsigned int i;
int ret;
 
for (i = 0; i < ARRAY_SIZE(spinand_manufacturers); i++) {
-   ret = spinand_manufacturers[i]->ops->detect(spinand);
-   if (ret > 0) {
-   spinand->manufacturer = spinand_manufacturers[i];
-   return 0;
-   } else if (ret < 0) {
-   return ret;
-   }
-   }
+   const struct spinand_manufacturer *manufacturer =
+   spinand_manufacturers[i];
 
+   if (id[0] != manufacturer->id)
+   continue;
+
+   ret = spinand_match_and_init(spinand,
+manufacturer->chips,
+manufacturer->nchips,
+rdid_method);
+   if (ret < 0)
+   continue;
+
+   spinand->manufacturer = manufacturer;
+   return 0;
+   }
return -ENOTSUPP;
 }
 
+static int spinand_id_detect(struct spinand_device *spinand)
+{
+   u8 *id = spinand->id.data;
+   int ret;
+
+   ret = spinand_read_id_op(spinand, 0, 0, id);
+   if (ret)
+   return ret;
+   ret = spinand_manufacturer_match(spinand, SPINAND_READID_METHOD_OPCODE);
+   if (!ret)
+   return 0;
+
+   ret = spinand_read_id_op(spinand, 1, 0, id);
+

[PATCH 2/5] mtd/spinand: sync core spinand code with linux-5.10.118

[Frieder Schrempf]

From: Mikhail Kshevetskiy 

This brings us closer to the current Linux kernel implementation of
the spinand core and makes backporting features and fixes easier.

This does not include the latest kernel implementation as this would
require a substantial amount of extra work due to the missing
ECC engine abstraction layer in U-Boot.

Signed-off-by: Mikhail Kshevetskiy 
Signed-off-by: Frieder Schrempf  (add commit 
message)
---
 drivers/mtd/nand/spi/core.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index d92de9c24e3..886e66e7847 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -326,6 +326,13 @@ static int spinand_write_to_cache_op(struct spinand_device 
*spinand,
u16 column = 0;
int ret;
 
+   /*
+* Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset
+* the cache content to 0xFF (depends on vendor implementation), so we
+* must fill the page cache entirely even if we only want to program
+* the data portion of the page, otherwise we might corrupt the BBM or
+* user data previously programmed in OOB area.
+*/
memset(spinand->databuf, 0xff,
   nanddev_page_size(nand) +
   nanddev_per_page_oobsize(nand));
@@ -598,12 +605,12 @@ static int spinand_mtd_read(struct mtd_info *mtd, loff_t 
from,
if (ret == -EBADMSG) {
ecc_failed = true;
mtd->ecc_stats.failed++;
-   ret = 0;
} else {
mtd->ecc_stats.corrected += ret;
max_bitflips = max_t(unsigned int, max_bitflips, ret);
}
 
+   ret = 0;
ops->retlen += iter.req.datalen;
ops->oobretlen += iter.req.ooblen;
}
@@ -669,16 +676,9 @@ static bool spinand_isbad(struct nand_device *nand, const 
struct nand_pos *pos)
.oobbuf.in = marker,
.mode = MTD_OPS_RAW,
};
-   int ret;
-
-   ret = spinand_select_target(spinand, pos->target);
-   if (ret)
-   return ret;
-
-   ret = spinand_read_page(spinand, , false);
-   if (ret)
-   return ret;
 
+   spinand_select_target(spinand, pos->target);
+   spinand_read_page(spinand, , false);
if (marker[0] != 0xff || marker[1] != 0xff)
return true;
 
@@ -722,6 +722,10 @@ static int spinand_markbad(struct nand_device *nand, const 
struct nand_pos *pos)
if (ret)
return ret;
 
+   ret = spinand_write_enable_op(spinand);
+   if (ret)
+   return ret;
+
return spinand_write_page(spinand, );
 }
 
-- 
2.39.0

[PATCH] arm64: dts: imx8mm-kontron: Add RTC aliases

[Frieder Schrempf]

From: Frieder Schrempf 

Add aliases for the RTCs on the board and on the SoC. This ensures that
the primary RTC is always the one on the board that has a buffered supply
and maximum accuracy.

This is a direct port of the pending commit from linux-next.

Signed-off-by: Frieder Schrempf 
Signed-off-by: Shawn Guo 
---
 arch/arm/dts/imx8mm-kontron-bl.dts | 4 +++-
 arch/arm/dts/imx8mm-kontron-osm-s.dtsi | 7 ++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-bl.dts 
b/arch/arm/dts/imx8mm-kontron-bl.dts
index a079322a379..dcec57c2039 100644
--- a/arch/arm/dts/imx8mm-kontron-bl.dts
+++ b/arch/arm/dts/imx8mm-kontron-bl.dts
@@ -13,6 +13,8 @@
 
aliases {
ethernet1 = 
+   rtc0 = 
+   rtc1 = _rtc;
};
 
/* fixed crystal dedicated to mcp2515 */
@@ -136,7 +138,7 @@
pinctrl-0 = <_i2c4>;
status = "okay";
 
-   rtc@32 {
+   rx8900: rtc@32 {
compatible = "epson,rx8900";
reg = <0x32>;
};
diff --git a/arch/arm/dts/imx8mm-kontron-osm-s.dtsi 
b/arch/arm/dts/imx8mm-kontron-osm-s.dtsi
index 8d10f5b4129..695da2fa7c4 100644
--- a/arch/arm/dts/imx8mm-kontron-osm-s.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-osm-s.dtsi
@@ -10,6 +10,11 @@
model = "Kontron OSM-S i.MX8MM (N802X SOM)";
compatible = "kontron,imx8mm-osm-s", "fsl,imx8mm";
 
+   aliases {
+   rtc0 = 
+   rtc1 = _rtc;
+   };
+
memory@4000 {
device_type = "memory";
/*
@@ -200,7 +205,7 @@
};
};
 
-   rtc@52 {
+   rv3028: rtc@52 {
compatible = "microcrystal,rv3028";
reg = <0x52>;
pinctrl-names = "default";
-- 
2.39.0

Re: [PATCH 1/7] mtd: replace name of 'rfree' field with 'free' in struct mtd_ooblayout_ops to better match it's description

[Frieder Schrempf]

On 07.10.22 13:58, Fabio Estevam wrote:
> On Fri, Oct 7, 2022 at 8:34 AM Michael Nazzareno Trimarchi
>  wrote:
> 
>> About this change, there was a commit from Simon 8d38a8459b0
>> that was renamed. You ask basically to revert it
> 
> Correct, what about fixing it like this?
> 
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index ff635bd716..09f5269887 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -122,7 +122,7 @@ struct mtd_oob_region {
>   * @ecc: function returning an ECC region in the OOB area.
>   *  Should return -ERANGE if %section exceeds the total number of
>   *  ECC sections.
> - * @free: function returning a free region in the OOB area.
> + * @rfree: function returning a free region in the OOB area.
>   *   Should return -ERANGE if %section exceeds the total number of
>   *   free sections.
>   */

But do we really want to stay out of sync with the Linux kernel code? Is
the reasoning behind Simon's change in 8d38a8459b0 still valid today?

[PATCH] imx: imx6ul: kontron-sl-mx6ul: Disable CONFIG_FSL_QSPI_AHB_FULL_MAP to fix SPI NAND read access

[Frieder Schrempf]

From: Frieder Schrempf 

The introduction of CONFIG_FSL_QSPI_AHB_FULL_MAP as default in:

def88bce094e ("spi: fsl_qspi: Support to use full AHB space on i.MX")

broke the SPI NAND read access on the Kontron SL i.MX6UL/ULL boards.
Reading data from the flash returns garbage instead of the actual
content. Fix this for now by disabling the introduced option.

In the long run this should be fixed globally.

Fixes: def88bce094e ("spi: fsl_qspi: Support to use full AHB space on i.MX")
Signed-off-by: Frieder Schrempf 
---
 configs/kontron-sl-mx6ul_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/kontron-sl-mx6ul_defconfig 
b/configs/kontron-sl-mx6ul_defconfig
index aa789fc6e5e..db4b684690f 100644
--- a/configs/kontron-sl-mx6ul_defconfig
+++ b/configs/kontron-sl-mx6ul_defconfig
@@ -95,6 +95,7 @@ CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
+# CONFIG_FSL_QSPI_AHB_FULL_MAP is not set
 CONFIG_MXC_SPI=y
 CONFIG_IMX_THERMAL=y
 CONFIG_USB=y
-- 
2.38.1

Re: [PATCH 2/2] spi: fsl_qspi: Support to use full AHB space on i.MX

[Frieder Schrempf]

Hi,

On 09.06.20 09:59, Ye Li wrote:
> i.MX platforms provide large AHB mapped space for QSPI, each
> controller has 256MB. However, current driver only maps small
> size (AHB buffer size) of AHB space, this implementation
> causes i.MX failed to boot M4 with QSPI XIP image.
> 
> Add config CONFIG_FSL_QSPI_AHB_FULL_MAP (default enabled for i.MX)
> to address above problem.
> 
> When the config is set:
> 1. Full AHB space is divided to each CS.
> 2. A dedicated LUT entry is used for AHB read only.
> 3. The MODE instruction in LUT is replaced to standard ADDR instruction
> 4. The address in spi_mem_op is used to SFAR and AHB read
> 
> Signed-off-by: Ye Li 
> Reviewed-by: Ashish Kumar 
> Reviewed-by: Kuldeep Singh 

I know I'm very late, but I seem to have missed this back in the days
when it was posted. Unfortunately there are some problems with this change.

1. The way the memory mapping of the attached flash (QSPI NOR?) is
implemented here is messy. In Linux we have a dirmap API for this kind
of things and it has recently been ported to U-Boot [1][2]. It would be
better to use this, similar to what was done here [3].

2. This change breaks reading from the SPI NAND flash used on the
Kontron SL i.MX6UL/ULL boards. The read operation returns garbage
instead of the actual data on the flash. When I revert this commit or set

# CONFIG_FSL_QSPI_AHB_FULL_MAP is not set

in the defconfig, it works.

Ye, can you come up with a solution for point 1 or if not can we change
the default of CONFIG_FSL_QSPI_AHB_FULL_MAP from enabled to disabled,
please?

For now I will disable CONFIG_FSL_QSPI_AHB_FULL_MAP in the boards
defconfig, but we should fix this globally.

What do you think?

Thanks
Frieder

[1]
https://source.denx.de/u-boot/u-boot/-/commit/f7e1de4c6a43beec438bce04571469145086efed
[2]
https://source.denx.de/u-boot/u-boot/-/commit/463cdf66632a0d67bf824cb43b6c1b41782d0765
[3]
https://source.denx.de/u-boot/u-boot/-/commit/992d02ea737895dc67246bbf7065084bb2721d6b

Re: [PATCH V2 37/53] ddr: imx: Add i.MX9 DDR controller driver

[Frieder Schrempf]

Hi Peng, Marcel,

On 26.07.22 10:41, Peng Fan (OSS) wrote:
> From: Ye Li 
> 
> Since i.MX9 uses same DDR PHY with i.MX8M, split the DDRPHY to a common
> directory under imx, then use dedicated ddr controller driver for each
> iMX9 and iMX8M.
> 
> The DDRPHY registers are space compressed, so it needs conversion to
> access the DDRPHY address. Introduce a common PHY address remap function
> for both iMX8M and iMX9 for all PHY registers accessing.
> 
> Signed-off-by: Ye Li 
> Signed-off-by: Peng Fan 
> ---

[...]

> +int wait_ddrphy_training_complete(void)
> +{
> + unsigned int mail;
> +
> + while (1) {
> + mail = get_mail();
> + decode_major_message(mail);
> + if (mail == 0x08) {
> + decode_streaming_message();
> + } else if (mail == 0x07) {
> + debug("Training PASS\n");
> + return 0;
> + } else if (mail == 0xff) {
> + printf("Training FAILED\n");

Our SPL for "kontron-sl-mx8mm" calls ddr_init() multiple times as it
tries multiple configurations and it is expected that it sometimes fails
and falls back to another config: [1].

Other boards like "verdin-mx8mp" seem to have a similar approach: [2].

With this change in v2022.10 we now get "Training FAILED" printed to the
console on our boards with 1GB DDR, even if the training of the fallback
configuration afterwards succeeded. This is kind of misleading for the user.

Do you have any idea what would be a good way to suppress this message
in our case? Passing a parameter like "fail_expected" all the way from
the boards spl_dram_init() down to wait_ddrphy_training_complete()
doesn't seem optimal, but removing the message in
wait_ddrphy_training_complete() and duplicating it in each
spl_dram_init() doesn't seem like a good option either.

Maybe you have some idea how to handle this!?

Thanks
Frieder

[1]
https://source.denx.de/u-boot/u-boot/-/blob/master/board/kontron/sl-mx8mm/spl.c#L79
[2]
https://source.denx.de/u-boot/u-boot/-/blob/master/board/toradex/verdin-imx8mp/spl.c#L40

Re: [PATCH v3 11/19] imx: kontron-sl-mx8mm: Remove 100mt DDR setpoint

[Frieder Schrempf]

Hi Tim,

On 21.10.22 21:24, Tim Harvey wrote:
> On Wed, Aug 24, 2022 at 7:01 AM Frieder Schrempf  wrote:
>>
>> From: Frieder Schrempf 
>>
>> The new stable configuration is missing the 100mt setpoint, remove
>> it before updating the config to make sure the changes are separated
>> cleanly.
>>
>> Signed-off-by: Frieder Schrempf 
>> Reviewed-by: Fabio Estevam 
>> ---
> 
> Frieder,
> 
> I just noticed this patch and was curious what it was about.
> 
> What do you mean by 'the new stable configuration is missing the 100mt
> setpoint'? Does this refer to something NXP has changed in their DDR
> config tools?

At some point we started using 4GB LPDDR4 chips from Nanya on our SoMs
while before we only had Micron chips. For some unknown reason (NXP
couldn't explain it either), the only configuration that works for all
used chips (Micron and Nanya) is only stable if the lowest of the three
frequency setpoints is removed.

Unfortunately I have no idea how this behavior could be explained.

Best regards
Frieder

Re: [PATCH 0/6] imx: imx6ul: kontron-sl-mx6ul: Fixes and improvements

[Frieder Schrempf]

Hi Stefano,

On 23.08.22 16:29, Frieder Schrempf wrote:
> From: Frieder Schrempf 
> 
> This series fixes some issues with the kontron-sl-mx6ul board
> configuration. It also syncs devicetrees with changes in the
> Linux kernel.
> 
> Notes:
> 
> * This series is based on imx/master and fixes the previously merged
>   sync patch from Marcel [1].
> * The devicetree changes this is based on are still pending in Linux
>   (see [2]).
> 
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20220721132748.1052244-9-mar...@ziswiler.com/
> [2] 
> https://patchwork.kernel.org/project/linux-arm-kernel/cover/20220815082814.27651-1-frie...@fris.de/
> 
> Frieder Schrempf (6):
>   Makefile: Make flash.bin target available for all platforms
>   imx: imx6ul: kontron-sl-mx6ul: Enable migrated Kconfig options
>   imx: imx6ul: kontron-sl-mx6ul: Fix CONFIG_ENV_SPI_BUS
>   imx: imx6ul: kontron-sl-mx6ul: Select correct boot and env device
>   imx: imx6ul: kontron-sl-mx6ul: Migrate to use CONFIG_EXTRA_ENV_TEXT
>   imx: imx6ul: kontron-sl-mx6ul: Sync devicetrees
> 

Can you please merge these patches so they land in v2023.01?

These have been around for two months and contain some important fixes
for the kontron-sl-mx6ul board configuration.

Thanks!
Frieder

Re: [PATCH 0/6] imx: imx6ul: kontron-sl-mx6ul: Fixes and improvements

[Frieder Schrempf]

On 24.10.22 10:16, Stefano Babic wrote:
> On 24.10.22 09:41, Frieder Schrempf wrote:
>> On 24.10.22 09:39, Frieder Schrempf wrote:
>>> Hi Stefano,
>>>
>>> On 23.08.22 16:29, Frieder Schrempf wrote:
>>>> From: Frieder Schrempf 
>>>>
>>>> This series fixes some issues with the kontron-sl-mx6ul board
>>>> configuration. It also syncs devicetrees with changes in the
>>>> Linux kernel.
>>>>
>>>> Notes:
>>>>
>>>> * This series is based on imx/master and fixes the previously merged
>>>>    sync patch from Marcel [1].
>>>> * The devicetree changes this is based on are still pending in Linux
>>>>    (see [2]).
>>>>
>>>> [1]
>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20220721132748.1052244-9-marcel%40ziswiler.com%2Fdata=05%7C01%7Cfrieder.schrempf%40kontron.de%7C4deee8897fe44b72318108dab59815ee%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638021962049269997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Sh3dZSPrhNUVmZdotMhw0r5n24fPT7UC6DRoudGBbJY%3Dreserved=0
>>>> [2]
>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F20220815082814.27651-1-frieder%40fris.de%2Fdata=05%7C01%7Cfrieder.schrempf%40kontron.de%7C4deee8897fe44b72318108dab59815ee%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638021962049269997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=q9AYIukI4fUI%2FRMY%2BFFuZslxszpHLyJcIWQOdyNDoXI%3Dreserved=0
>>>>
>>>> Frieder Schrempf (6):
>>>>    Makefile: Make flash.bin target available for all platforms
>>>>    imx: imx6ul: kontron-sl-mx6ul: Enable migrated Kconfig options
>>>>    imx: imx6ul: kontron-sl-mx6ul: Fix CONFIG_ENV_SPI_BUS
>>>>    imx: imx6ul: kontron-sl-mx6ul: Select correct boot and env device
>>>>    imx: imx6ul: kontron-sl-mx6ul: Migrate to use CONFIG_EXTRA_ENV_TEXT
>>>>    imx: imx6ul: kontron-sl-mx6ul: Sync devicetrees
>>>>
>>>
>>> Can you please merge these patches so they land in v2023.01?
>>>
>>> These have been around for two months and contain some important fixes
>>> for the kontron-sl-mx6ul board configuration.
>>
>> Ah, I just saw that they are already in imx/master. Sorry for the noise.
>> For some reason I didn't get pull notification e-mails while for my
>> other patches I got them.
> 
> 
> I have checked this - my script takes the address of the sender (see on
> ML's archive), notification were sent to frie...@fris.de, while patches
> are signed with your company's address.

True, I got all the notifications there. So probably the forwarding
rules in my mailbox don't work properly. Thanks for checking!

Re: [PATCH 0/6] imx: imx6ul: kontron-sl-mx6ul: Fixes and improvements

[Frieder Schrempf]

On 24.10.22 09:39, Frieder Schrempf wrote:
> Hi Stefano,
> 
> On 23.08.22 16:29, Frieder Schrempf wrote:
>> From: Frieder Schrempf 
>>
>> This series fixes some issues with the kontron-sl-mx6ul board
>> configuration. It also syncs devicetrees with changes in the
>> Linux kernel.
>>
>> Notes:
>>
>> * This series is based on imx/master and fixes the previously merged
>>   sync patch from Marcel [1].
>> * The devicetree changes this is based on are still pending in Linux
>>   (see [2]).
>>
>> [1] 
>> https://patchwork.ozlabs.org/project/uboot/patch/20220721132748.1052244-9-mar...@ziswiler.com/
>> [2] 
>> https://patchwork.kernel.org/project/linux-arm-kernel/cover/20220815082814.27651-1-frie...@fris.de/
>>
>> Frieder Schrempf (6):
>>   Makefile: Make flash.bin target available for all platforms
>>   imx: imx6ul: kontron-sl-mx6ul: Enable migrated Kconfig options
>>   imx: imx6ul: kontron-sl-mx6ul: Fix CONFIG_ENV_SPI_BUS
>>   imx: imx6ul: kontron-sl-mx6ul: Select correct boot and env device
>>   imx: imx6ul: kontron-sl-mx6ul: Migrate to use CONFIG_EXTRA_ENV_TEXT
>>   imx: imx6ul: kontron-sl-mx6ul: Sync devicetrees
>>
> 
> Can you please merge these patches so they land in v2023.01?
> 
> These have been around for two months and contain some important fixes
> for the kontron-sl-mx6ul board configuration.

Ah, I just saw that they are already in imx/master. Sorry for the noise.
For some reason I didn't get pull notification e-mails while for my
other patches I got them.

Re: imx patches pending

[Frieder Schrempf]

Hi Stefano,

On 19.10.22 09:56, Stefano Babic wrote:
> Hi Tim,
> 
> On 14.10.22 18:38, Tim Harvey wrote:
>> Stefano,
>>
>> With the merge window for v2023.01 closing in about a week (10/24),
>> can you please look at the pending patches for imx? I'm afraid you may
>> have some merge conflicts due to dt updates and we likely need time to
>> respond to any issues you may have.

I just want to emphasize what Tim already said. It looks like lots of
i.MX patches have accumulated over the last months and a lot of them fix
things that are currently broken in v2022.10 and master.

As no i.MX patches have been pulled for weeks it's now getting very
tight for those patches to hit v2023.01 which is not really a good
situation.

I know fixes can also be applied after the merge window has closed, but
in my case there are fixes for our board support that are part of larger
reworks and are difficult to separate from the non-fix-patches.

> I will try to sum them in next days and then post the PR to Tom.

It's really late and if any problems occur I likely won't be able to
respond before the merge window closes.

Anyway, I hope we can still sort this out somehow and thanks for your
efforts.

Frieder

[PATCH v3 19/19] imx: kontron-sl-mx8mm: Prepare for I2C display detection in environment script

[Frieder Schrempf]

From: Frieder Schrempf 

Enable the I2C bus and set a env variable for the reset GPIO of the touch
controller. This allows us to probe the panel in a script.

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v3:
* none

Changes in v2:
* new patch
---
 arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi | 13 +++--
 arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi  |  8 
 arch/arm/dts/imx8mm-kontron-bl-u-boot.dtsi|  8 
 board/kontron/sl-mx8mm/sl-mx8mm.c |  5 -
 4 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
index e7e900d4fa8..5b8b472159a 100644
--- a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
@@ -48,8 +48,17 @@
 
  {
status = "okay";
-   u-boot,dm-spl;
-   u-boot,dm-pre-reloc;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2>;
+};
+
+ {
+   pinctrl_i2c2: i2c2grp {
+   fsl,pins = <
+   MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL  0x41c3
+   MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA  0x41c3
+   >;
+   };
 };
 
 _ecspi1 {
diff --git a/arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi
index cd990b16720..fac24a21fbf 100644
--- a/arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi
@@ -4,3 +4,11 @@
  */
 
 #include "imx8mm-kontron-bl-common-u-boot.dtsi"
+
+ {
+   pinctrl_touch: touchgrp {
+   fsl,pins = <
+   MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23   0x19 /* Touch 
Reset */
+   >;
+   };
+};
diff --git a/arch/arm/dts/imx8mm-kontron-bl-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-u-boot.dtsi
index cd990b16720..e9fa8d7b2a1 100644
--- a/arch/arm/dts/imx8mm-kontron-bl-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-bl-u-boot.dtsi
@@ -4,3 +4,11 @@
  */
 
 #include "imx8mm-kontron-bl-common-u-boot.dtsi"
+
+ {
+   pinctrl_touch: touchgrp {
+   fsl,pins = <
+   MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15   0x19 /* Touch 
Reset */
+   >;
+   };
+};
diff --git a/board/kontron/sl-mx8mm/sl-mx8mm.c 
b/board/kontron/sl-mx8mm/sl-mx8mm.c
index 641130112aa..4ac430b29a9 100644
--- a/board/kontron/sl-mx8mm/sl-mx8mm.c
+++ b/board/kontron/sl-mx8mm/sl-mx8mm.c
@@ -126,8 +126,11 @@ int board_late_init(void)
if (!fdt_node_check_compatible(gd->fdt_blob, 0, 
"kontron,imx8mm-n802x-som") ||
!fdt_node_check_compatible(gd->fdt_blob, 0, 
"kontron,imx8mm-osm-s")) {
env_set("som_type", "osm-s");
-   else
+   env_set("touch_rst_gpio", "111");
+   } else {
env_set("som_type", "sl");
+   env_set("touch_rst_gpio", "87");
+   }
 
return 0;
 }
-- 
2.37.2

[PATCH v3 18/19] imx: kontron-sl-mx8mm: Add support for Kontron Electronics SoM SL i.MX8MM OSM-S

[Frieder Schrempf]

From: Frieder Schrempf 

This adds support for the Kontron Electronics SoM SL i.MX8MM OSM-S
and the matching baseboard BL i.MX8MM OSM-S.

The SoM hardware complies to the Open Standard Module (OSM) 1.0
specification, size S (https://sget.org/standards/osm).

The existing board configuration for the non-OSM SoM is reused and
allows to detect the SoM variant at runtime.

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v3:
* fix OSM-S SoM name to match official name
* fix docs to match official board names
* adjust devicetree names and compatibles
* fix printing of RAM size
* add missing Makefile entry for new dtb
* fix hex numbers and unit addresses in SPI NOR partitions

Changes in v2:
* none
---
 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mm-kontron-bl-common-u-boot.dtsi  | 139 +++
 .../dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi   |   6 +
 arch/arm/dts/imx8mm-kontron-bl-osm-s.dts  | 376 ++
 arch/arm/dts/imx8mm-kontron-bl-u-boot.dtsi| 139 +--
 arch/arm/dts/imx8mm-kontron-osm-s.dtsi| 330 +++
 board/kontron/sl-mx8mm/sl-mx8mm.c |   7 +-
 board/kontron/sl-mx8mm/spl.c  |  25 +-
 configs/kontron-sl-mx8mm_defconfig|   2 +
 doc/board/kontron/sl-mx8mm.rst|  13 +-
 10 files changed, 893 insertions(+), 145 deletions(-)
 create mode 100644 arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-kontron-bl-osm-s.dts
 create mode 100644 arch/arm/dts/imx8mm-kontron-osm-s.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1e21dbcc7ec..93982968547 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -940,6 +940,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-icore-mx8mm-ctouch2.dtb \
imx8mm-icore-mx8mm-edimm2.2.dtb \
imx8mm-kontron-bl.dtb \
+   imx8mm-kontron-bl-osm-s.dtb \
imx8mm-mx8menlo.dtb \
imx8mm-venice.dtb \
imx8mm-venice-gw71xx-0x.dtb \
diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
new file mode 100644
index 000..e7e900d4fa8
--- /dev/null
+++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2019 Kontron Electronics GmbH
+ */
+
+#include "imx8mm-u-boot.dtsi"
+
+/ {
+   aliases {
+   usb0 = 
+   usb1 = 
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   u-boot,dm-spl;
+   };
+
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_jr0 {
+   u-boot,dm-spl;
+};
+
+_jr1 {
+   u-boot,dm-spl;
+};
+
+_jr2 {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   status = "okay";
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+_ecspi1 {
+   u-boot,dm-spl;
+};
+
+_i2c1 {
+   u-boot,dm-spl;
+};
+
+_pmic {
+   u-boot,dm-spl;
+};
+
+_uart3 {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+_usdhc1 {
+   u-boot,dm-spl;
+};
+
+_usdhc1_100mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc1_200mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc2 {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_wdog {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi
new file mode 100644
index 000..cd990b16720
--- /dev/null
+++ b/arch/arm/dts/imx8mm-kontron-bl-osm-s-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+#include "imx8mm-kontron-bl-common-u-boot.dtsi"
diff --git a/arch/arm/dts/imx8mm-kontron-bl-osm-s.dts 
b/arch/arm/dts/imx8mm-kontron-bl-osm-s.dts
new file mode 100644
index 000..8b16bd68576
--- /dev/null
+++ b/arch/arm/dts/imx8mm-kontron-bl-osm-s.dts
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx8mm-kontron-osm-s.dtsi"
+
+/ {
+   model = "Kontron BL i.MX8MM OSM-S (N802X S)&q

[PATCH v3 17/19] imx: kontron-sl-mx8mm: Simplify code in spl.c

[Frieder Schrempf]

From: Frieder Schrempf 

Refactor the code a bit without any functional changes.

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v3:
* fix printing of RAM size

Changes in v2:
* fix printf warning
* remove unused pinmux definitions
---
 board/kontron/sl-mx8mm/spl.c | 31 ++-
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
index 00e63659f4a..403ab9a3ea2 100644
--- a/board/kontron/sl-mx8mm/spl.c
+++ b/board/kontron/sl-mx8mm/spl.c
@@ -39,11 +39,6 @@ static iomux_v3_cfg_t const i2c1_pads[] = {
IMX8MM_PAD_I2C1_SDA_I2C1_SDA | MUX_PAD_CTRL(I2C_PAD_CTRL) | 
MUX_MODE_SION
 };
 
-static iomux_v3_cfg_t const i2c2_pads[] = {
-   IMX8MM_PAD_I2C2_SCL_I2C2_SCL | MUX_PAD_CTRL(I2C_PAD_CTRL) | 
MUX_MODE_SION,
-   IMX8MM_PAD_I2C2_SDA_I2C2_SDA | MUX_PAD_CTRL(I2C_PAD_CTRL) | 
MUX_MODE_SION
-};
-
 int spl_board_boot_device(enum boot_device boot_dev_spl)
 {
switch (boot_dev_spl) {
@@ -109,41 +104,27 @@ static void spl_dram_init(void)
size = 1;
}
 
-   printf("Kontron SL i.MX8MM (N801X) module, %u GB RAM detected\n", size);
+   gd->ram_size = size;
writel(size, M4_BOOTROM_BASE_ADDR);
 }
 
-static int i2c_detect(u8 bus, u16 addr)
-{
-   struct udevice *udev;
-   int ret;
-
-   /*
-* Try to probe the touch controller to check if an LVDS panel is
-* connected.
-*/
-   ret = i2c_get_chip_for_busnum(bus, addr, 0, );
-   if (ret == 0)
-   return 0;
-
-   return 1;
-}
-
 int do_board_detect(void)
 {
+   gd->board_type = BOARD_TYPE_KTN_N801X;
+   printf("Kontron SL i.MX8MM (N801X) module, %u GB RAM detected\n",
+  (unsigned int)gd->ram_size);
+
/*
 * Check the I2C PMIC to detect the deprecated SoM with DA9063.
 */
imx_iomux_v3_setup_multiple_pads(i2c1_pads, ARRAY_SIZE(i2c1_pads));
 
-   if (i2c_detect(0, 0x58) == 0) {
+   if (i2c_get_chip_for_busnum(0, 0x58, 0, ) == 0) {
printf("### ATTENTION: DEPRECATED SOM REVISION (N8010 Rev0) 
DETECTED! ###\n");
printf("###  THIS HW IS NOT SUPPORTED AND BOOTING WILL PROBABLY 
FAIL  ###\n");
printf("### PLEASE UPGRADE TO LATEST MODULE 
  ###\n");
}
 
-   gd->board_type = BOARD_TYPE_KTN_N801X;
-
return 0;
 }
 
-- 
2.37.2