[PATCH master 1/3] pstore: ramoops: fix use of wrong types on 64-bit

2024-05-06 Thread Ahmad Fatoum
The kernel struct persistent_ram_buffer uses atomic_t for start and size
members in the persistent_ram_buffer chunk, which are 32-bit always,
unlike resource_size_t that we used in barebox, which is 64-bit when
CONFIG_PHYS_ADDR_T_64BIT=y.

To fix this, we could use either int32_t or atomic_t. To make
synchronization with Linux easier, let's use atomic_t.

Signed-off-by: Ahmad Fatoum 
---
 fs/pstore/ram_core.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 76b8a109be9d..24948d701744 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -14,12 +14,14 @@
 
 #define pr_fmt(fmt) "persistent_ram: " fmt
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,21 +29,22 @@
 
 struct persistent_ram_buffer {
uint32_t sig;
-   resource_size_t start;
-   resource_size_t size;
-   uint8_t data[0];
+   atomic_t start;
+   atomic_t size;
+   uint8_t data[];
 };
+static_assert(sizeof(struct persistent_ram_buffer) == 12);
 
 #define PERSISTENT_RAM_SIG (0x43474244) /* DBGC */
 
 static inline size_t buffer_size(struct persistent_ram_zone *prz)
 {
-   return prz->buffer->size;
+   return atomic_read(>buffer->size);
 }
 
 static inline size_t buffer_start(struct persistent_ram_zone *prz)
 {
-   return prz->buffer->start;
+   return atomic_read(>buffer->start);
 }
 
 /* increase and wrap the start pointer, returning the old value */
@@ -50,11 +53,11 @@ static size_t buffer_start_add(struct persistent_ram_zone 
*prz, size_t a)
int old;
int new;
 
-   old = prz->buffer->start;
+   old = atomic_read(>buffer->start);
new = old + a;
while (unlikely(new >= prz->buffer_size))
new -= prz->buffer_size;
-   prz->buffer->start = new;
+   atomic_set(>buffer->start, new);
 
return old;
 }
@@ -65,14 +68,14 @@ static void buffer_size_add(struct persistent_ram_zone 
*prz, size_t a)
size_t old;
size_t new;
 
-   old = prz->buffer->size;
+   old = atomic_read(>buffer->size);
if (old == prz->buffer_size)
return;
 
new = old + a;
if (new > prz->buffer_size)
new = prz->buffer_size;
-   prz->buffer->size = new;
+   atomic_set(>buffer->size, new);
 }
 
 static void notrace persistent_ram_encode_rs8(struct persistent_ram_zone *prz,
@@ -331,8 +334,8 @@ void persistent_ram_free_old(struct persistent_ram_zone 
*prz)
 
 void persistent_ram_zap(struct persistent_ram_zone *prz)
 {
-   prz->buffer->start = 0;
-   prz->buffer->size = 0;
+   atomic_set(>buffer->start, 0);
+   atomic_set(>buffer->size, 0);
persistent_ram_update_header_ecc(prz);
 }
 
-- 
2.39.2




[PATCH master 3/3] pstore: return -ENOENT when file is missing

2024-05-06 Thread Ahmad Fatoum
The expectation with stat(2) and open(2) is that they report -ENOENT if
a file name doesn't exist. Return this instead of the unexpected -EINVAL
error code.

Signed-off-by: Ahmad Fatoum 
---
 fs/pstore/fs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/fs.c b/fs/pstore/fs.c
index 777e2448cc62..238a316e9157 100644
--- a/fs/pstore/fs.c
+++ b/fs/pstore/fs.c
@@ -148,7 +148,7 @@ static int pstore_open(struct device *dev, FILE *file, 
const char *filename)
 
d = pstore_get_by_name(head, filename);
if (!d)
-   return -EINVAL;
+   return -ENOENT;
 
file->size = d->size;
file->priv = d;
@@ -226,7 +226,7 @@ static int pstore_stat(struct device *dev, const char 
*filename,
 
d = pstore_get_by_name(, filename);
if (!d)
-   return -EINVAL;
+   return -ENOENT;
 
s->st_size = d->size;
s->st_mode = S_IFREG | S_IRWXU | S_IRWXG | S_IRWXO;
-- 
2.39.2




[PATCH master 2/3] pstore: fix size of OF fixup memory region

2024-05-06 Thread Ahmad Fatoum
struct resource::end points at the last byte of a region, but we pointed
1 byte after it instead. Fix this, so we have a proper (aligned) size
for the memory region.

It's possible this had no adverse effect.

Signed-off-by: Ahmad Fatoum 
---
 fs/pstore/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 4732bd4e3154..9ecf7ef5e901 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -478,7 +478,7 @@ static int ramoops_of_fixup(struct device_node *root, void 
*data)
int ret;
 
res.start = pdata->mem_address;
-   res.end = res.start + pdata->mem_size;
+   res.end = res.start + pdata->mem_size - 1;
res.name = "ramoops";
 
ret = of_fixup_reserved_memory(root, );
-- 
2.39.2




[PATCH v2 2/4] mtd: nand: mxc_nand: Cleanup code creating bad block table

2024-05-06 Thread Uwe Kleine-König
Let the variable "numblocks" contain the number of blocks of the NAND
device (and not twice this value). Also the loop variable counts blocks
now instead of the doubled value. Further calculate the offset of the
i-th block from i instead of incrementing in each step and pick a more
sensbile variable name for it.

Also checkbad() only makes use of *mtd which is already available in the
caller, so pass that one directly. Additionally initialize the struct
mtd_oob_ops in the declarator (which has the nice side effect of zeroing
the members not mentioned) and improve code comments.

Signed-off-by: Uwe Kleine-König 
---
 drivers/mtd/nand/raw/mxc_nand.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c
index f7ef2e4374a9..8e564fa76a33 100644
--- a/drivers/mtd/nand/raw/mxc_nand.c
+++ b/drivers/mtd/nand/raw/mxc_nand.c
@@ -1555,19 +1555,18 @@ static const struct nand_controller_ops 
mxcnd_controller_ops = {
  * From this point on we can forget about the BBMs and rely completely
  * on the flash BBT.
  */
-static int checkbad(struct nand_chip *chip, loff_t ofs)
+static int checkbad(struct mtd_info *mtd, loff_t ofs)
 {
-   struct mtd_info *mtd = nand_to_mtd(chip);
int ret;
uint8_t buf[mtd->writesize + mtd->oobsize];
-   struct mtd_oob_ops ops;
-
-   ops.mode = MTD_OPS_RAW;
-   ops.ooboffs = 0;
-   ops.datbuf = buf;
-   ops.len = mtd->writesize;
-   ops.oobbuf = buf + mtd->writesize;
-   ops.ooblen = mtd->oobsize;
+   struct mtd_oob_ops ops = {
+   .mode = MTD_OPS_RAW,
+   .ooboffs = 0,
+   .datbuf = buf,
+   .len = mtd->writesize,
+   .oobbuf = buf + mtd->writesize,
+   .ooblen = mtd->oobsize,
+   };
 
ret = mtd_read_oob(mtd, ofs, );
if (ret < 0)
@@ -1585,31 +1584,31 @@ static int imxnd_create_bbt(struct nand_chip *chip)
 {
struct mtd_info *mtd = nand_to_mtd(chip);
int len, i, numblocks, ret;
-   loff_t from = 0;
uint8_t *bbt;
 
-   len = mtd->size >> (chip->bbt_erase_shift + 2);
+   numblocks = mtd->size >> chip->bbt_erase_shift;
 
-   /* Allocate memory (2bit per block) and clear the memory bad block 
table */
+   /*
+* Allocate memory (2bit per block = 1 byte per 4 blocks) and clear the
+* memory bad block table
+*/
+   len = (numblocks + 3) >> 2;
bbt = kzalloc(len, GFP_KERNEL);
if (!bbt)
return -ENOMEM;
 
-   numblocks = mtd->size >> (chip->bbt_erase_shift - 1);
+   for (i = 0; i < numblocks; ++i) {
+   loff_t ofs = i << chip->bbt_erase_shift;
 
-   for (i = 0; i < numblocks;) {
-   ret = checkbad(chip, from);
+   ret = checkbad(mtd, ofs);
if (ret < 0)
goto out;
 
if (ret) {
-   bbt[i >> 3] |= 0x03 << (i & 0x6);
+   bbt[i >> 2] |= 0x03 << (2 * (i & 0x3));
dev_info(mtd->dev.parent, "Bad eraseblock %d at 
0x%08x\n",
-i >> 1, (unsigned int)from);
+i, (unsigned int)ofs);
}
-
-   i += 2;
-   from += (1 << chip->bbt_erase_shift);
}
 
chip->bbt_td->options |= NAND_BBT_CREATE;
-- 
2.43.0




[PATCH v2 1/4] mtd: nand: mxc_nand: Improve comment about vendor BBM and address verschwurbelung

2024-05-06 Thread Uwe Kleine-König
To better describe why the BBM is at offset 2000 describe the full
misinterpretation^Wmapping of the NAND memory that the i.MX hardware
implements.

Also adapt the comment to reality: A BBT is created automatically since
commit 2ad441bb7e78 ("mtd: nand-imx: Create BBT automatically when
necessary") which was included in v2020.03.0.

Signed-off-by: Uwe Kleine-König 
---
 drivers/mtd/nand/raw/mxc_nand.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c
index c6533b20fc0f..f7ef2e4374a9 100644
--- a/drivers/mtd/nand/raw/mxc_nand.c
+++ b/drivers/mtd/nand/raw/mxc_nand.c
@@ -1528,20 +1528,32 @@ static const struct nand_controller_ops 
mxcnd_controller_ops = {
  * 512b data + 16b OOB +
  * 512b data + 16b OOB
  *
+ * So the mapping between original NAND addressing (as intended by the chip
+ * vendor) and interpretation when accessed via the i.MX NAND controller is as
+ * follows:
+ *
+ *   original   |i.MX
+ * -+-
+ * data 0x - 0x0200 | data 0x - 0x0200
+ * data 0x0200 - 0x0210 | oob  0x - 0x0010
+ * data 0x0210 - 0x0410 | data 0x0200 - 0x0400
+ * data 0x0410 - 0x0420 | oob  0x0010 - 0x0020
+ * data 0x0420 - 0x0620 | data 0x0400 - 0x0600
+ * data 0x0620 - 0x0630 | oob  0x0020 - 0x0030
+ * data 0x0630 - 0x0800 | data 0x0600 - 0x07d0
+ * oob  0x - 0x0030 | data 0x07d0 - 0x0800
+ * oob  0x0030 - 0x0040 | oob  0x0030 - 0x0040
+ *
  * This means that the factory provided bad block marker ends up
- * in the page data at offset 2000 instead of in the OOB data.
+ * in the page data at offset 2000 = 0x7d0 instead of in the OOB data.
  *
- * To preserve the factory bad block information we take the following
- * strategy:
- *
- * - If the NAND driver detects that no flash BBT is present on 2k NAND
- *   chips it will not create one because it would do so based on the wrong
- *   BBM position
- * - This command is used to create a flash BBT then.
+ * If the NAND driver detects that no flash BBT is present on a 2k NAND
+ * chip it will create one automatically in the assumption that the NAND is
+ * pristine (that is completely erased with only vendor BBMs in the OOB) to
+ * preserve factory bad block information.
  *
  * From this point on we can forget about the BBMs and rely completely
  * on the flash BBT.
- *
  */
 static int checkbad(struct nand_chip *chip, loff_t ofs)
 {
@@ -1562,8 +1574,10 @@ static int checkbad(struct nand_chip *chip, loff_t ofs)
return ret;
 
if (buf[2000] != 0xff)
+   /* block considered bad */
return 1;
 
+   /* block considered good */
return 0;
 }
 
-- 
2.43.0




[PATCH v2 4/4] mtd: nand: mxc_nand: Only automatically create BBT if NAND seems to be pristine

2024-05-06 Thread Uwe Kleine-König
Automatically creating a BBT is the right thing to do if the NAND is
factory new. However when migrating from a barebox older than commit
v2020.03.0~28^2~1 ("mtd: nand-imx: Create BBT automatically when
necessary") on a used machine, this automatism is really bad because it
most likely marks the blocks containing the barebox image (and possibly
more) as bad. On such a system the vendor BBMs are gone, but it was
operated without that information before, so continuing to do so is a
sane option.

Add a light check for the NAND to be really pristine: If any block looks
like containing a barebox image or a UBI refuse to create a BBT.

Signed-off-by: Uwe Kleine-König 
---
 drivers/mtd/nand/raw/mxc_nand.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c
index faea1c95f95e..f8517df823e5 100644
--- a/drivers/mtd/nand/raw/mxc_nand.c
+++ b/drivers/mtd/nand/raw/mxc_nand.c
@@ -1575,6 +1575,23 @@ static int checkbad(struct mtd_info *mtd, loff_t ofs)
return ret;
}
 
+   /*
+* Automatically adding a BBT based on factory BBTs is only
+* sensible if the NAND is pristine. Abort if the first page
+* looks like a bootloader or UBI block.
+*/
+   if (is_barebox_arm_head(buf)) {
+   dev_err(mtd->dev.parent,
+   "Flash seems to contain a barebox image, refusing to 
create BBT\n");
+   return -EINVAL;
+   }
+
+   if (!memcmp(buf, "UBI#", 4)) {
+   dev_err(mtd->dev.parent,
+   "Flash seems to contain a UBI, refusing to create 
BBT\n");
+   return -EINVAL;
+   }
+
if (buf[2000] != 0xff)
/* block considered bad */
return 1;
-- 
2.43.0




[PATCH v2 0/4] mtd: nand: mxc_nand: Only automatically create BBT if NAND seems to be pristine

2024-05-06 Thread Uwe Kleine-König
Hello,

this is v2 of this series. The changes are:

 - More cleanups
 - Keep checkbad() function (Sascha)
 - Check each block if it contains a barebox image or a UBI

(implicit) v1 available at
https://lore.barebox.org/barebox/20240430094451.1038256-4-u.kleine-koe...@pengutronix.de/T/#t

This is based on master.

Best regards
Uwe

Uwe Kleine-König (4):
  mtd: nand: mxc_nand: Improve comment about vendor BBM and address 
verschwurbelung
  mtd: nand: mxc_nand: Cleanup code creating bad block table
  mtd: nand: mxc_nand: Add error message if BBT creation fails
  mtd: nand: mxc_nand: Only automatically create BBT if NAND seems to be 
pristine

 drivers/mtd/nand/raw/mxc_nand.c | 95 ++---
 1 file changed, 64 insertions(+), 31 deletions(-)

base-commit: 302db826b67c44a925a25a7b7508bc82a0fcd6a8
-- 
2.43.0




[PATCH v2 3/4] mtd: nand: mxc_nand: Add error message if BBT creation fails

2024-05-06 Thread Uwe Kleine-König
Then reading from the chip and thus aborting creation of a bad block
table, at inform the user about that with an error message.

Signed-off-by: Uwe Kleine-König 
---
 drivers/mtd/nand/raw/mxc_nand.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c
index 8e564fa76a33..faea1c95f95e 100644
--- a/drivers/mtd/nand/raw/mxc_nand.c
+++ b/drivers/mtd/nand/raw/mxc_nand.c
@@ -1569,8 +1569,11 @@ static int checkbad(struct mtd_info *mtd, loff_t ofs)
};
 
ret = mtd_read_oob(mtd, ofs, );
-   if (ret < 0)
+   if (ret < 0) {
+   dev_err(mtd->dev.parent, "Failed to read page at 0x%08x\n",
+   (unsigned int)ofs);
return ret;
+   }
 
if (buf[2000] != 0xff)
/* block considered bad */
-- 
2.43.0




Re: [PATCH 2/2] ARM: i.MX8M: add support to handle ROM SError ERR050350

2024-05-06 Thread Marco Felsch
On 24-05-03, Sascha Hauer wrote:
> On Tue, Apr 30, 2024 at 01:29:41PM +0200, Marco Felsch wrote:
> > This ports U-Boot commit:
> > 
> > | commit 2f3c92060dcd6bc9cfd3e2e344a3e1745ca39f09
> > | Author: Peng Fan 
> > | Date:   Thu Jul 9 13:39:26 2020 +0800
> > |
> > | imx8m: workaround ROM serror
> > |
> > | ROM SError happens on two cases:
> > |
> > | 1. ERR050342, on iMX8MQ HDCP enabled parts ROM writes to GPV1 
> > register, but
> > | when ROM patch lock is fused, this write will cause SError.
> > |
> > | 2. ERR050350, on iMX8MQ/MM/MN, when the field return fuse is burned, 
> > HAB
> > | is field return mode, but the last 4K of ROM is still protected and 
> > cause
> > | SError.
> > |
> > | Since ROM mask SError until ATF unmask it, so then ATF always meets 
> > the
> > | exception. This patch works around the issue in SPL by enabling SPL
> > | Exception vectors table and the SError exception, take the exception
> > | to eret immediately to clear the SError.
> > |
> > | Signed-off-by: Ye Li 
> > | Signed-off-by: Peng Fan 
> > 
> > Other than U-Boot we don't support exceptions in PBL and therefore we
> > can handle it simpler by installing an dummy exception table which does
> > nothing. The table gets overriden by TF-A later on anyway.
> > 
> > Signed-off-by: Marco Felsch 
> > ---
> > Hi all,
> > 
> > I'm not sure if the relocation should be done within the erratum
> > handler or if we should move it into the lowlevel code per default for
> > all i.MX8M platforms since the board files call it anyway after the
> > lowlevel init. In the later case this would be an separate patch to drop
> > the pattern:
> > 
> >  lowlevel_setup();
> >  relocate_to_current_adr();
> > 
> > from the board files.
> > 
> > Regards,
> >   Marco
> > 
> >  arch/arm/mach-imx/Makefile|  1 +
> >  arch/arm/mach-imx/cpu_init.c  | 12 +-
> >  arch/arm/mach-imx/errata.c| 22 ++
> >  arch/arm/mach-imx/imx8m_early_exceptions_64.S | 42 +++
> >  include/mach/imx/errata.h | 12 ++
> >  5 files changed, 88 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/mach-imx/errata.c
> >  create mode 100644 arch/arm/mach-imx/imx8m_early_exceptions_64.S
> >  create mode 100644 include/mach/imx/errata.h
> > 
> > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> > index ce8af486aed4..d182f95673f5 100644
> > --- a/arch/arm/mach-imx/Makefile
> > +++ b/arch/arm/mach-imx/Makefile
> > @@ -34,6 +34,7 @@ obj-$(CONFIG_BAREBOX_UPDATE_IMX_EXTERNAL_NAND) += 
> > imx-bbu-external-nand.o
> >  pbl-$(CONFIG_USB_GADGET_DRIVER_ARC_PBL) += imx-udc.o
> >  obj-$(CONFIG_RESET_IMX_SRC) += src.o
> >  lwl-y += cpu_init.o
> > +lwl-y += errata.o imx8m_early_exceptions_64.o
> 
> Should likely be:
> 
> lwl-$(CONFIG_ARCH_IMX8M) += imx8m_early_exceptions_64.o
> 
> Also you can drop the _64 suffix from the filename as the imx8m_ preifx
> already implies this.

Sure.

> >  pbl-y += xload-spi.o xload-common.o xload-imx-nand.o xload-gpmi-nand.o
> >  pbl-y += xload-qspi.o
> >  obj-pbl-$(CONFIG_ARCH_IMX9) += ele.o
> > diff --git a/arch/arm/mach-imx/cpu_init.c b/arch/arm/mach-imx/cpu_init.c
> > index c5a47d9b9154..aebbd3defaec 100644
> > --- a/arch/arm/mach-imx/cpu_init.c
> > +++ b/arch/arm/mach-imx/cpu_init.c
> > @@ -6,6 +6,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -75,17 +76,26 @@ void imx8mm_cpu_lowlevel_init(void)
> > imx8m_ccgr_clock_enable(IMX8M_CCM_CCGR_SCTR);
> >  
> > imx8m_cpu_lowlevel_init();
> > +
> > +   erratum_050350_imx8m();
> >  }
> >  
> >  void imx8mn_cpu_lowlevel_init(void)
> > __alias(imx8mm_cpu_lowlevel_init);
> >  
> >  void imx8mp_cpu_lowlevel_init(void)
> > -   __alias(imx8mm_cpu_lowlevel_init);
> > +{
> > +   /* ungate system counter */
> > +   imx8m_ccgr_clock_enable(IMX8M_CCM_CCGR_SCTR);
> > +
> > +   imx8m_cpu_lowlevel_init();
> > +}
> >  
> >  void imx8mq_cpu_lowlevel_init(void)
> >  {
> > imx8m_cpu_lowlevel_init();
> > +
> > +   erratum_050350_imx8m();
> >  }
> >  
> >  #define CCM_AUTHEN_TZ_NS   BIT(9)
> > diff --git a/arch/arm/mach-imx/errata.c b/arch/arm/mach-imx/errata.c
> > new file mode 100644
> > index ..ef8de91a9278
> > --- /dev/null
> > +++ b/arch/arm/mach-imx/errata.c
> > @@ -0,0 +1,22 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#ifdef CONFIG_CPU_V8
> > +
> > +extern unsigned long early_imx8m_vectors;
> > +
> > +void erratum_050350_imx8m(void)
> > +{
> > +   if (current_el() != 3)
> > +   return;
> > +
> > +   relocate_to_current_adr();
> > +
> > +   asm volatile("msr vbar_el3, %0" : : "r" (_imx8m_vectors) : "cc");
> > +   asm volatile("msr daifclr, #4;isb");
> > +}
> > +
> > +#endif /* CONFIG_CPU_V8 */
> > diff --git a/arch/arm/mach-imx/imx8m_early_exceptions_64.S 
> > 

Re: [PATCH 3/3] mtd: mxc-nand: Only automatically create BBT if NAND seems to be pristine

2024-05-06 Thread Uwe Kleine-König
Hallo Sascha,

On Fri, May 03, 2024 at 09:44:24AM +0200, Sascha Hauer wrote:
> On Tue, Apr 30, 2024 at 11:44:54AM +0200, Uwe Kleine-König wrote:
> > Automatically creating a BBT is the right thing to do if the NAND is
> > factory new. However when migrating from a barebox older than commit
> > v2020.03.0~28^2~1 ("mtd: nand-imx: Create BBT automatically when
> > necessary") on a used machine, this automatism is really bad because it
> > most likely marks the blocks containing the barebox image (and possibly
> > more) as bad. On such a system the vendor BBMs are gone, but it was
> > operated without that information before, so continuing to do so is a
> > sane option.
> > 
> > Add a light check for the NAND to be really pristine: If the first block
> > looks like containing a barebox image or a UBI refuse to create a BBT.
> > 
> > Signed-off-by: Uwe Kleine-König 
> > ---
> >  drivers/mtd/nand/raw/mxc_nand.c | 58 ++---
> >  1 file changed, 31 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/raw/mxc_nand.c 
> > b/drivers/mtd/nand/raw/mxc_nand.c
> > index a72275480144..fd5ae447a198 100644
> > --- a/drivers/mtd/nand/raw/mxc_nand.c
> > +++ b/drivers/mtd/nand/raw/mxc_nand.c
> > @@ -1555,30 +1555,6 @@ static const struct nand_controller_ops 
> > mxcnd_controller_ops = {
> >   * From this point on we can forget about the BBMs and rely completely
> >   * on the flash BBT.
> >   */
> > -static int checkbad(struct nand_chip *chip, loff_t ofs)
> > -{
> > -   struct mtd_info *mtd = nand_to_mtd(chip);
> > -   int ret;
> > -   uint8_t buf[mtd->writesize + mtd->oobsize];
> > -   struct mtd_oob_ops ops;
> > -
> > -   ops.mode = MTD_OPS_RAW;
> > -   ops.ooboffs = 0;
> > -   ops.datbuf = buf;
> > -   ops.len = mtd->writesize;
> > -   ops.oobbuf = buf + mtd->writesize;
> > -   ops.ooblen = mtd->oobsize;
> > -
> > -   ret = mtd_read_oob(mtd, ofs, );
> > -   if (ret < 0)
> > -   return ret;
> > -
> > -   if (buf[2000] != 0xff)
> > -   return 1;
> > -
> > -   return 0;
> > -}
> > -
> >  static int imxnd_create_bbt(struct nand_chip *chip)
> >  {
> > struct mtd_info *mtd = nand_to_mtd(chip);
> > @@ -1598,12 +1574,40 @@ static int imxnd_create_bbt(struct nand_chip *chip)
> >  
> > for (i = 0; i < numblocks; ++i) {
> > loff_t ofs = i << chip->bbt_erase_shift;
> > +   uint8_t buf[mtd->writesize + mtd->oobsize];
> > +   struct mtd_oob_ops ops = {
> > +   .mode = MTD_OPS_RAW,
> > +   .ooboffs = 0,
> > +   .datbuf = buf,
> > +   .len = mtd->writesize,
> > +   .oobbuf = buf + mtd->writesize,
> > +   .ooblen = mtd->oobsize,
> > +   };
> >  
> > -   ret = checkbad(chip, ofs);
> > -   if (ret < 0)
> > +   ret = mtd_read_oob(mtd, ofs, );
> > +   if (ret < 0) {
> > +   dev_err(mtd->dev.parent, "Failed to read page at 
> > 0x%08x\n", (unsigned int)ofs);
> > goto out;
> > +   }
> >  
> > -   if (ret) {
> > +   /*
> > +* Automatically adding a BBT based on factory BBTs is only
> > +* sensible if the NAND is pristine. Abort if the first page
> > +* looks like a bootloader or UBI block.
> > +*/
> > +   if (ofs == 0 && is_barebox_arm_head(buf)) {
> > +   dev_err(mtd->dev.parent, "Flash seems to contain a 
> > barebox image, refusing\n");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> > +
> > +   if (ofs == 0 && !memcmp(buf, "UBI#", 4)) {
> > +   dev_err(mtd->dev.parent, "Flash seems to contain a UBI, 
> > refusing\n");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> > +
> > +   if (buf[2000] != 0xff) {
> > bbt[i >> 2] |= 0x03 << (2 * (i & 0x3));
> > dev_info(mtd->dev.parent, "Bad eraseblock %d at 
> > 0x%08x\n",
> >  i, (unsigned int)ofs);
> 
> Could you add the new code to checkbad() instead of inlining it? That
> way it seems easier to adjust the code in case we have to change the way
> how we detect useful data on a page. Rename checkbad() in case the name
> doesn't feel appropriate anymore.

I hesitated to add the check for the chip being pristine to checkbad().
Then maybe read page 0 and check its contents before the check_bad()
loop? Then page 0 will be read twice but checkbad() can stay around and
only do what its name promises.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Re: [PATCH v2 0/5] ARM: i.MX8MP: add nominal drive mode support

2024-05-06 Thread Sascha Hauer


On Fri, 03 May 2024 12:37:12 +0200, Ahmad Fatoum wrote:
> Unlike the i.MX8MM and i.MX8MN SoCs added earlier, the early setup code
> and device tree for the i.MX8MP configures some clocks at frequencies
> that are only validated for overdrive mode, i.e. when VDD_SOC is 950 mV.
> 
> Boards may want to run their SoC at the lower voltage of 850 mV though
> to reduce heat generation and power usage. For this to work, clock rates
> need to adhere to the limits of the nominal drive mode.
> 
> [...]

Applied, thanks!

[1/5] ARM: i.MX8M: pass cpu_type parameter to __imx8m_early_clock_init
  https://git.pengutronix.de/cgit/barebox/commit/?id=ae2dd4a4850f (link may 
not be stable)
[2/5] ARM: i.MX8MP: configure PLL3 as 600MHz
  https://git.pengutronix.de/cgit/barebox/commit/?id=4a8c03958738 (link may 
not be stable)
[3/5] ARM: i.MX8MP: configure PLL3 as noc_io parent
  https://git.pengutronix.de/cgit/barebox/commit/?id=608ea0c2fa33 (link may 
not be stable)
[4/5] ARM: i.MX8MP: don't reparent GIC from BootROM default
  https://git.pengutronix.de/cgit/barebox/commit/?id=ecff33a34978 (link may 
not be stable)
[5/5] ARM: dts: i.MX8MP: Add optional nominal drive mode DTSI
  https://git.pengutronix.de/cgit/barebox/commit/?id=180337d60753 (link may 
not be stable)

Best regards,
-- 
Sascha Hauer 




Re: [PATCH 2/3] ARM: layerscape: add helpful runtime warning when firmware is missing

2024-05-06 Thread Sascha Hauer
On Fri, May 03, 2024 at 12:32:29PM +0200, Ahmad Fatoum wrote:
> Firmware compiled into barebox PBL is rarely optional, so even if
> CONFIG_MISSING_FIRMWARE_ERROR is disabled, barebox will not generate
> images with missing PBL firmware.
> 
> We can relax this for firmware compiled into barebox proper though: If
> the user disables CONFIG_MISSING_FIRMWARE_ERROR, just have the driver
> fail at runtime as not to break other boards in the same build that
> don't require the firmware.
> 
> Missing barebox proper firmware will be detectable as a 0-byte firmware
> blob in the follow-up commit, so prepare for that by printing an
> informative error message.

I changed the order of the first two patches to what this sentence
suggests.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |



Re: [PATCH 1/3] firmware: support optional firmware in barebox proper

2024-05-06 Thread Sascha Hauer


On Fri, 03 May 2024 12:32:28 +0200, Ahmad Fatoum wrote:
> For firmware used in the prebootloader, missing firmware is handled
> according to the CONFIG_MISSING_FIRMWARE_ERROR symbol:
> 
>   - If set, barebox will throw an error when assmebling the final image
> with a list of missing firmware
> 
>   - If unset, a warning will be printed for each barebox image that
> can't be built due to missing firmware and all
> 
> [...]

Applied, thanks!

[1/3] firmware: support optional firmware in barebox proper
  https://git.pengutronix.de/cgit/barebox/commit/?id=bd29a3aa7e2a (link may 
not be stable)
[2/3] ARM: layerscape: add helpful runtime warning when firmware is missing
  https://git.pengutronix.de/cgit/barebox/commit/?id=9e436059695a (link may 
not be stable)
[3/3] ci: test: remove generation of dummy firmware
  https://git.pengutronix.de/cgit/barebox/commit/?id=8dc8635d90cb (link may 
not be stable)

Best regards,
-- 
Sascha Hauer 




Re: [PATCH] dma: of_fixups: add fallbacks if /soc doesn't exist

2024-05-06 Thread Sascha Hauer


On Fri, 03 May 2024 12:29:09 +0200, Ahmad Fatoum wrote:
> The fixup was written for Layerscape LS1046A. Enabling it on i.MX8MP
> throws an initcall error, because the SoC node is called /soc@0.
> 
> Improve the situation by falling back to either /soc@0 or just plain /.
> 
> 

Applied, thanks!

[1/1] dma: of_fixups: add fallbacks if /soc doesn't exist
  https://git.pengutronix.de/cgit/barebox/commit/?id=73258bfc5c1b (link may 
not be stable)

Best regards,
-- 
Sascha Hauer 




Re: [PATCH] mfd: pca9450: don't warn if PCA9450_PWRON_STAT is 0

2024-05-06 Thread Sascha Hauer


On Fri, 03 May 2024 12:15:19 +0200, Ahmad Fatoum wrote:
> The register is zeroed on read, so network booting always prints the
> warning that the reset reason is unknown.
> 
> Skip the warning in this case.
> 
> 

Applied, thanks!

[1/1] mfd: pca9450: don't warn if PCA9450_PWRON_STAT is 0
  https://git.pengutronix.de/cgit/barebox/commit/?id=20acc8c050f6 (link may 
not be stable)

Best regards,
-- 
Sascha Hauer 




Re: [PATCH] arm: rockchip: mecsbc: drop duplicate reserved-memory node

2024-05-06 Thread Sascha Hauer


On Fri, 03 May 2024 12:11:31 +0200, Ahmad Fatoum wrote:
> The exact same node is duplicated. Drop one instance.
> 
> 

Applied, thanks!

[1/1] arm: rockchip: mecsbc: drop duplicate reserved-memory node
  https://git.pengutronix.de/cgit/barebox/commit/?id=b2ebe85e64e2 (link may 
not be stable)

Best regards,
-- 
Sascha Hauer 




Re: [PATCH master] ARM: i.MX9: tqma93xx: handle unknown form factors

2024-05-06 Thread Sascha Hauer
On Fri, May 03, 2024 at 12:09:23PM +0200, Ahmad Fatoum wrote:
> GCC warns that fdt may be uninitialized. Fix that by treating unknown
> variants as the CA variant. CA was chosen for no particular reason.
> 
> Signed-off-by: Ahmad Fatoum 
> ---
>  arch/arm/boards/tqma93xx/lowlevel.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/boards/tqma93xx/lowlevel.c 
> b/arch/arm/boards/tqma93xx/lowlevel.c
> index 8d89ee530ff8..66991fc6b03b 100644
> --- a/arch/arm/boards/tqma93xx/lowlevel.c
> +++ b/arch/arm/boards/tqma93xx/lowlevel.c
> @@ -89,6 +89,9 @@ static noinline void tqma93xx_continue(void)
>   case VARD_FORMFACTOR_TYPE_LGA:
>   fdt = __dtb_z_imx93_tqma9352_mba93xxla_start;
>   break;
> + default:
> + pr_warn("Unknown formfactor: 0%x. Assuming connector\n", 
> formfactor);
> + fallthrough;

tqma93xx_get_formfactor() always returns one of the values handled in
this switch/case, so this will never trigger. If gcc mourns about it
then adding the default: is enough, no need to add a message.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |



Re: [PATCH master] pblimage: suppress stdout output

2024-05-06 Thread Sascha Hauer


On Fri, 03 May 2024 12:08:56 +0200, Ahmad Fatoum wrote:
> Any output, stdout or stderr, during normal operation looks jarring when
> interleaved with Kbuild, so utilities should just be always silent on
> stdout and print errors to stderr if they occur.
> 
> The pblimage tool violated this and had a stdout debug print left-over and
> printed part of an error message to stdout instead of stderr. Fix both
> instances.
> 
> [...]

Applied, thanks!

[1/1] pblimage: suppress stdout output
  https://git.pengutronix.de/cgit/barebox/commit/?id=302db826b67c (link may 
not be stable)

Best regards,
-- 
Sascha Hauer