Re: [PATCH v2 0/6] Introduce UBI block device
Hi We queue them this afternoon Michael On Thu, May 23, 2024 at 12:49 PM Alexey Romanov wrote: > > > Hi Michael, > > On Mon, May 06, 2024 at 03:59:52PM +0200, Michael Nazzareno Trimarchi wrote: > > Hi Alexey > > > > Sorry will will put on CI > > Any news? > > > > > Michael > > > > On Mon, May 6, 2024 at 3:58 PM Alexey Romanov > > wrote: > > > > > > Hello! Ping. > > > > > > On Mon, Mar 25, 2024 at 05:41:42PM +0300, Alexey Romanov wrote: > > > > Hello! > > > > > > > > This series adds support for the UBI block 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 ubi 0 part_name > > > > > > > > Tested only on SPI NAND, so bind is made only for > > > > SPI NAND drivers. Can be used with mtdblock device [1]. > > > > > > > > --- > > > > > > > > Changes V1 -> V2 [2]: > > > > > > > > - Rebased over mtdblock v2 patchset [3]. > > > > - Compile UBI partitions support only if CONFIG_BLK option > > > >is enabled. > > > > > > > > - Links: > > > > > > > > [1] > > > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > > > [2] > > > > https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/ > > > > [3] > > > > https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/ > > > > > > > > Alexey Romanov (6): > > > > ubi: allow to read from volume with offset > > > > ubi: allow to write to volume with offset > > > > drivers: introduce UBI block abstraction > > > > disk: don't try search for partition type if already set > > > > disk: support UBI partitions > > > > spinand: bind UBI block > > > > > > > > cmd/ubi.c | 77 +++-- > > > > disk/part.c | 7 ++ > > > > drivers/block/blk-uclass.c | 1 + > > > > drivers/mtd/nand/spi/core.c | 8 ++- > > > > drivers/mtd/ubi/Makefile | 1 + > > > > drivers/mtd/ubi/block.c | 130 > > > > drivers/mtd/ubi/part.c | 99 +++ > > > > env/ubi.c | 16 ++--- > > > > include/part.h | 2 + > > > > include/ubi_uboot.h | 8 ++- > > > > 10 files changed, 332 insertions(+), 17 deletions(-) > > > > create mode 100644 drivers/mtd/ubi/block.c > > > > create mode 100644 drivers/mtd/ubi/part.c > > > > > > > > -- > > > > 2.34.1 > > > > > > > > > > -- > > > Thank you, > > > Alexey > > > > > > > > -- > > Michael Nazzareno Trimarchi > > Co-Founder & Chief Executive Officer > > M. +39 347 913 2170 > > mich...@amarulasolutions.com > > __ > > > > Amarula Solutions BV > > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > > T. +31 (0)85 111 9172 > > i...@amarulasolutions.com > > www.amarulasolutions.com > > -- > Thank you, > Alexey -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [EXTERNAL] Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
Hi Dario Can you add to next pull? Michael On Tue, May 21, 2024, 4:31 PM Ravi Minnikanti wrote: > Hi, > > Can you please merge this PR, if there are no more review comments? > > Thanks, > Ravi > On 5/6/24 11:28, Michael Nazzareno Trimarchi wrote: > > > -- > > Hi Ravi > > > > On Mon, May 6, 2024 at 7:33 PM Ravi Minnikanti > wrote: > >> > >> On 5/6/24 00:35, Michael Nazzareno Trimarchi wrote: > >>> Hi Ravi > >>> > >>> On Tue, Apr 30, 2024 at 6:25 AM Ravi Minnikanti < > rminnika...@marvell.com> wrote: > >>>> > >>>> On 4/29/24 09:59, Michael Nazzareno Trimarchi wrote: > >>>> > >>>>> > -- > >>>>> On Mon, Apr 29, 2024 at 6:22 PM Chris Packham < > judge.pack...@gmail.com> wrote: > >>>>>> > >>>>>> On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti < > rminnika...@marvell.com> wrote: > >>>>>>> > >>>>>>> Once a page is read with higher bitflips all subsequent reads > >>>>>>> are returning the same bitflip value even though they have none. > >>>>>>> max_bitflip variable is not being reset to 0 across page reads. > >>>>>>> > >>>>>>> This is causing problems like incorrectly > >>>>>>> marking erase blocks bad by UBI and causing read failures. > >>>>>>> > >>>>>>> Verified the change with both MTD reads and UBI. > >>>>>>> This change is inline with other NFC drivers. > >>>>>>> > >>>>>>> Sample error log where a block is marked bad incorrectly: > >>>>>>> > >>>>>>> ubi0: fixable bit-flip detected at PEB 125 > >>>>>>> ubi0: run torture test for PEB 125 > >>>>>>> ubi0: fixable bit-flip detected at PEB 125 > >>>>>>> ubi0 error: torture_peb: read problems on freshly erased PEB 125, > >>>>>>> must be bad > >>>>>>> ubi0 error: erase_worker: failed to erase PEB 125, error -5 > >>>>>>> ubi0: mark PEB 125 as bad > >>>>>>> > >>>>>>> Signed-off-by: rminnikanti > >>>>>> > >>>>>> Looks good to me > >>>>>> > >>>>>> Reviewed-by: Chris Packham > >>>>>> > >>>>>>> --- > >>>>>>> drivers/mtd/nand/raw/pxa3xx_nand.c | 5 + > >>>>>>> 1 file changed, 5 insertions(+) > >>>>>>> > >>>>>>> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c > b/drivers/mtd/nand/raw/pxa3xx_nand.c > >>>>>>> index 1d9a6d107b..d2a4faad56 100644 > >>>>>>> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c > >>>>>>> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c > >>>>>>> @@ -800,6 +800,11 @@ static void prepare_start_command(struct > pxa3xx_nand_info *info, int command) > >>>>>>> info->ecc_err_cnt = 0; > >>>>>>> info->ndcb3 = 0; > >>>>>>> info->need_wait = 0; > >>>>>>> + /* > >>>>>>> +* Reset max_bitflips to zero. Once command is complete, > >>>>>>> +* max_bitflips for this READ is returned in > ecc.read_page() > >>>>>>> +*/ > >>>>>>> + info->max_bitflips = 0; > >>>>>>> > >>>>> > >>>>> Why this should not be put to 0 in read_page instead on > prepare_start_command? > >>>>> > >>>>> Michael > >>>>> > >>>> > >>>> ecc.read_page is invoked after the read command execution. > >>>> First chip->cmdfunc is executed with NAND_CMD_READ0 and then > ecc.read_page is invoked > >>>> to read the page from buffer. So, by the time read_page is invoked, > info->max_bitflips > >>>> must already have the bit flip value. > >>>> > >>> > >>> All the other implementation has a slight different way to handle. &
Re: imx8mp: Flashing U-Boot into eMMC hardware partition via UUU
Hi Fabio
On Fri, May 10, 2024 at 5:10 PM Fabio Estevam wrote:
>
> Hi Michael,
>
> On Fri, May 10, 2024 at 11:28 AM Michael Nazzareno Trimarchi
> wrote:
>
> > You can just change as you want. We have this file in buildroot, uuu
> > can run command on the device
> > using FB command. Example how call it
>
> Thanks for sharing the example.
>
> I adapted the UUU script like this:
>
> SDPS: boot -f flash.bin
> FB: ucmd setenv fastboot_buffer ${loadaddr}
> FB: ucmd mmc dev 2 1
> FB: download -f flash.bin
> FB: ucmd setexpr blkcnt $filesize + 0x1ff
> FB: ucmd setexpr blkcnt $blkcnt / 0x200
> FB: ucmd mmc write $loadaddr 0 $blkcnt
My suggestion is use timeout of some command when is possible
> FB: reboot
> FB: done
>
> Did the following changes based on imx8mn_bsh_smm_s2pro:
>
> index 024b46ef8bc2..0b6026c34309 100644
> --- a/board/freescale/imx8mp_evk/imx8mp_evk.c
> +++ b/board/freescale/imx8mp_evk/imx8mp_evk.c
> @@ -3,6 +3,8 @@
> * Copyright 2019 NXP
> */
>
> +#include
> +#include
> #include
>
> int board_init(void)
> @@ -17,5 +19,11 @@ int board_late_init(void)
> env_set("board_rev", "iMX8MP");
> #endif
>
> + if (is_usb_boot()) {
> + printf("* Entering in USB download mode\n");
> + env_set("bootcmd", "fastboot usb 0");
> + env_set("bootdelay", "0");
> + }
> +
I think that is kind of good example
> return 0;
> }
> diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h
> index 1759318fdd35..148b36bd3169 100644
> --- a/include/configs/imx8mp_evk.h
> +++ b/include/configs/imx8mp_evk.h
> @@ -25,8 +25,17 @@
>
> #include
>
> +#define EMMCARGS \
> + "fastboot_partition_alias_all=" \
> + __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) ".0:0\0" \
> + "fastboot_partition_alias_bootloader=" \
> + __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) ".1:0\0" \
> + "emmc_dev=" __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) "\0" \
> + "emmc_ack=1\0" \
> +
> /* Initial environment variables */
> #define CFG_EXTRA_ENV_SETTINGS \
> + EMMCARGS \
> BOOTENV \
> "scriptaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> "kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
>
> and now UUU correctly flashes the eMMC hardware partition.
>
> Thanks a lot,
No problem
Micheal
>
> Fabio Estevam
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: imx8mp: Flashing U-Boot into eMMC hardware partition via UUU
On Fri, May 10, 2024 at 4:19 PM Fabio Estevam wrote:
>
> Hi,
>
> I am using an imx8mp-evk board and I can flash the U-Boot into the
> eMMC hardware partition 0 by running:
>
>=> tftpboot $loadaddr flash.bin
>=> setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
>=> mmc dev 2 1
>=> mmc write $loadaddr 0 $blkcnt
>
> Now I want to do the same via UUU.
>
> I tried to create a script called emmc_flash:
>
> uuu_version 1.5.21
>
> SDPS: boot -f flash.bin
> SDPS: done
> FB: ucmd setenv fastboot_dev mmc
> FB: ucmd mmc dev 2 1
> FB: flash bootloader flash.bin
> FB: Done
>
> Then on the PC: uuu emmc_flash
>
> U-Boot is loaded to RAM, but the eMMC hardware partition is not programmed.
>
> What is the correct script for doing this?
>
> Any suggestions?
Create an lst file
Hi Fabio
Top posting
# @_flash.bin| bootloader
# @_image [_flash.bin] | image burn to nand, default is the same as bootloader
# @_filesystem | filesystem to burn
# @_kernel | kernel image
# @_dtb | dtb image
# This command will be run when ROM support stream mode
# i.MX8QXP, i.MX8QM
SDPS: boot -f _flash.bin
FB: ucmd setenv fastboot_buffer ${loadaddr}
FB: download -f _image
# Burn image to nandfit partition if needed
FB: ucmd if env exists nandfit_part; then nand erase.part nandfit;
nand write ${fastboot_buffer} nandfit ${filesize}; else true; fi;
FB: ucmd nandbcb init ${fastboot_buffer} nandboot ${filesize}
FB[-t 1]: ucmd ubi part nandrootfs
FB[-t 1]: ucmd ubi create root -
FB: download -f _filesystem
FB[-t 6]: ucmd ubi write ${loadaddr} root ${filesize}
FB: download -f _kernel
FB[-t 1]: ucmd nand write ${loadaddr} nandkernel ${filesize}
FB: download -f _dtb
FB[-t 8000]: ucmd nand write ${loadaddr} nanddtb ${filesize}
FB: reboot
FB: done
You can just change as you want. We have this file in buildroot, uuu
can run command on the device
using FB command. Example how call it
${OUTPUT_DIR}/host/bin/uuu -v -b ${IMAGES_DIR}/nand-full.lst \
${IMAGES_DIR}/flash.bin \
${IMAGES_DIR}/flash.bin \
${IMAGES_DIR}/rootfs.ubifs \
${IMAGES_DIR}/Image \
${IMAGES_DIR}/freescale/imx8mn-bsh-smm-s2.dtb
Michael
>
> Thanks
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
Hi Ravi On Mon, May 6, 2024 at 7:33 PM Ravi Minnikanti wrote: > > On 5/6/24 00:35, Michael Nazzareno Trimarchi wrote: > > Hi Ravi > > > > On Tue, Apr 30, 2024 at 6:25 AM Ravi Minnikanti > > wrote: > >> > >> On 4/29/24 09:59, Michael Nazzareno Trimarchi wrote: > >> > >>> -- > >>> On Mon, Apr 29, 2024 at 6:22 PM Chris Packham > >>> wrote: > >>>> > >>>> On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti > >>>> wrote: > >>>>> > >>>>> Once a page is read with higher bitflips all subsequent reads > >>>>> are returning the same bitflip value even though they have none. > >>>>> max_bitflip variable is not being reset to 0 across page reads. > >>>>> > >>>>> This is causing problems like incorrectly > >>>>> marking erase blocks bad by UBI and causing read failures. > >>>>> > >>>>> Verified the change with both MTD reads and UBI. > >>>>> This change is inline with other NFC drivers. > >>>>> > >>>>> Sample error log where a block is marked bad incorrectly: > >>>>> > >>>>> ubi0: fixable bit-flip detected at PEB 125 > >>>>> ubi0: run torture test for PEB 125 > >>>>> ubi0: fixable bit-flip detected at PEB 125 > >>>>> ubi0 error: torture_peb: read problems on freshly erased PEB 125, > >>>>> must be bad > >>>>> ubi0 error: erase_worker: failed to erase PEB 125, error -5 > >>>>> ubi0: mark PEB 125 as bad > >>>>> > >>>>> Signed-off-by: rminnikanti > >>>> > >>>> Looks good to me > >>>> > >>>> Reviewed-by: Chris Packham > >>>> > >>>>> --- > >>>>> drivers/mtd/nand/raw/pxa3xx_nand.c | 5 + > >>>>> 1 file changed, 5 insertions(+) > >>>>> > >>>>> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c > >>>>> b/drivers/mtd/nand/raw/pxa3xx_nand.c > >>>>> index 1d9a6d107b..d2a4faad56 100644 > >>>>> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c > >>>>> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c > >>>>> @@ -800,6 +800,11 @@ static void prepare_start_command(struct > >>>>> pxa3xx_nand_info *info, int command) > >>>>> info->ecc_err_cnt = 0; > >>>>> info->ndcb3 = 0; > >>>>> info->need_wait = 0; > >>>>> + /* > >>>>> +* Reset max_bitflips to zero. Once command is complete, > >>>>> +* max_bitflips for this READ is returned in ecc.read_page() > >>>>> +*/ > >>>>> + info->max_bitflips = 0; > >>>>> > >>> > >>> Why this should not be put to 0 in read_page instead on > >>> prepare_start_command? > >>> > >>> Michael > >>> > >> > >> ecc.read_page is invoked after the read command execution. > >> First chip->cmdfunc is executed with NAND_CMD_READ0 and then ecc.read_page > >> is invoked > >> to read the page from buffer. So, by the time read_page is invoked, > >> info->max_bitflips > >> must already have the bit flip value. > >> > > > > All the other implementation has a slight different way to handle. > > From what you said the reset should > > be done on for NAND_CMD_READ0 command and should be sufficient. > > Technically should be moved > > in switch and not unconditionally. > > > > Michael > > > > max_bitflip is not being reset to 0 across page reads. > Once a page is read with higher bitflips all subsequent reads > are returning the same bitflip value even though they have none. > > This is causing problems like incorrectly > marking erase blocks bad by UBI and read failures. > > Tested it with both MTD reads and UBI attach. > This change is inline with other NFC drivers. > > Sample error log where a block is marked bad incorrectly: > > ubi0: fixable bit-flip detected at PEB 125 > ubi0: run torture test for PEB 125 > ubi0: fixable bit-flip detected at PEB 125 > ubi0 error: torture_peb: read problems on freshly erased PEB 125, > must be bad > ubi0 err
Re: [PATCH v2 0/6] Introduce UBI block device
Hi Alexey Sorry will will put on CI Michael On Mon, May 6, 2024 at 3:58 PM Alexey Romanov wrote: > > Hello! Ping. > > On Mon, Mar 25, 2024 at 05:41:42PM +0300, Alexey Romanov wrote: > > Hello! > > > > This series adds support for the UBI block 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 ubi 0 part_name > > > > Tested only on SPI NAND, so bind is made only for > > SPI NAND drivers. Can be used with mtdblock device [1]. > > > > --- > > > > Changes V1 -> V2 [2]: > > > > - Rebased over mtdblock v2 patchset [3]. > > - Compile UBI partitions support only if CONFIG_BLK option > >is enabled. > > > > - Links: > > > > [1] > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > [2] > > https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/ > > [3] > > https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/ > > > > Alexey Romanov (6): > > ubi: allow to read from volume with offset > > ubi: allow to write to volume with offset > > drivers: introduce UBI block abstraction > > disk: don't try search for partition type if already set > > disk: support UBI partitions > > spinand: bind UBI block > > > > cmd/ubi.c | 77 +++-- > > disk/part.c | 7 ++ > > drivers/block/blk-uclass.c | 1 + > > drivers/mtd/nand/spi/core.c | 8 ++- > > drivers/mtd/ubi/Makefile| 1 + > > drivers/mtd/ubi/block.c | 130 > > drivers/mtd/ubi/part.c | 99 +++ > > env/ubi.c | 16 ++--- > > include/part.h | 2 + > > include/ubi_uboot.h | 8 ++- > > 10 files changed, 332 insertions(+), 17 deletions(-) > > create mode 100644 drivers/mtd/ubi/block.c > > create mode 100644 drivers/mtd/ubi/part.c > > > > -- > > 2.34.1 > > > > -- > Thank you, > Alexey -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [EXTERNAL] Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
Hi Ravi
On Tue, Apr 30, 2024 at 6:25 AM Ravi Minnikanti wrote:
>
> On 4/29/24 09:59, Michael Nazzareno Trimarchi wrote:
>
> > --
> > On Mon, Apr 29, 2024 at 6:22 PM Chris Packham
> > wrote:
> >>
> >> On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti
> >> wrote:
> >>>
> >>> Once a page is read with higher bitflips all subsequent reads
> >>> are returning the same bitflip value even though they have none.
> >>> max_bitflip variable is not being reset to 0 across page reads.
> >>>
> >>> This is causing problems like incorrectly
> >>> marking erase blocks bad by UBI and causing read failures.
> >>>
> >>> Verified the change with both MTD reads and UBI.
> >>> This change is inline with other NFC drivers.
> >>>
> >>> Sample error log where a block is marked bad incorrectly:
> >>>
> >>> ubi0: fixable bit-flip detected at PEB 125
> >>> ubi0: run torture test for PEB 125
> >>> ubi0: fixable bit-flip detected at PEB 125
> >>> ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> >>> must be bad
> >>> ubi0 error: erase_worker: failed to erase PEB 125, error -5
> >>> ubi0: mark PEB 125 as bad
> >>>
> >>> Signed-off-by: rminnikanti
> >>
> >> Looks good to me
> >>
> >> Reviewed-by: Chris Packham
> >>
> >>> ---
> >>> drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
> >>> 1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> >>> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> >>> index 1d9a6d107b..d2a4faad56 100644
> >>> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> >>> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> >>> @@ -800,6 +800,11 @@ static void prepare_start_command(struct
> >>> pxa3xx_nand_info *info, int command)
> >>> info->ecc_err_cnt = 0;
> >>> info->ndcb3 = 0;
> >>> info->need_wait = 0;
> >>> + /*
> >>> +* Reset max_bitflips to zero. Once command is complete,
> >>> +* max_bitflips for this READ is returned in ecc.read_page()
> >>> +*/
> >>> + info->max_bitflips = 0;
> >>>
> >
> > Why this should not be put to 0 in read_page instead on
> > prepare_start_command?
> >
> > Michael
> >
>
> ecc.read_page is invoked after the read command execution.
> First chip->cmdfunc is executed with NAND_CMD_READ0 and then ecc.read_page is
> invoked
> to read the page from buffer. So, by the time read_page is invoked,
> info->max_bitflips
> must already have the bit flip value.
>
All the other implementation has a slight different way to handle.
>From what you said the reset should
be done on for NAND_CMD_READ0 command and should be sufficient.
Technically should be moved
in switch and not unconditionally.
Michael
> Thanks, Ravi.
>
> >>> switch (command) {
> >>> case NAND_CMD_READ0:
> >>> --
> >>> 2.17.1
> >
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: imx8mn: bootcount does not increment
Hi Fabio On Thu, May 2, 2024 at 2:45 PM Fabio Estevam wrote: > > Hi Heiko, > > On Fri, Apr 26, 2024 at 12:40 AM Heiko Schocher wrote: > > > No chance for a bootcounter in a register? > > Yes, this is a better approach. I changed it to: > > CONFIG_BOOTCOUNT_LIMIT=y > CONFIG_SYS_BOOTCOUNT_MAGIC=0xB0C4 > CONFIG_SYS_BOOTCOUNT_ADDR=0x30370090 > CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y > > and now bootcount increments. > Maybe you have anyway a bug on the evk when was not incrementing on environment Michael > Thanks, > > Fabio Estevam -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 030/149] board: bsh: Remove and add needed includes
Hi On Wed, May 1, 2024 at 4:43 AM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Michael Trimarchi > --- > board/bsh/imx6ulz_smm_m2/imx6ulz_smm_m2.c | 1 - > board/bsh/imx6ulz_smm_m2/spl.c| 1 - > board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c | 1 - > 3 files changed, 3 deletions(-) > > diff --git a/board/bsh/imx6ulz_smm_m2/imx6ulz_smm_m2.c > b/board/bsh/imx6ulz_smm_m2/imx6ulz_smm_m2.c > index c82eabbfbea1..c03e390762a9 100644 > --- a/board/bsh/imx6ulz_smm_m2/imx6ulz_smm_m2.c > +++ b/board/bsh/imx6ulz_smm_m2/imx6ulz_smm_m2.c > @@ -14,7 +14,6 @@ > #include > #include > #include > -#include > #include > #include > > diff --git a/board/bsh/imx6ulz_smm_m2/spl.c b/board/bsh/imx6ulz_smm_m2/spl.c > index 5b4812e129e3..724841b57456 100644 > --- a/board/bsh/imx6ulz_smm_m2/spl.c > +++ b/board/bsh/imx6ulz_smm_m2/spl.c > @@ -1,6 +1,5 @@ > // SPDX-License-Identifier: GPL-2.0+ > > -#include > #include > #include > #include > diff --git a/board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c > b/board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c > index 0ebf208be82a..c99896873991 100644 > --- a/board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c > +++ b/board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c > @@ -3,7 +3,6 @@ > * Copyright 2021 Collabora Ltd. > */ > > -#include > #include > #include > > -- > 2.34.1 > Reviewed-by: Michael Trimarchi -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
On Mon, Apr 29, 2024 at 6:22 PM Chris Packham wrote:
>
> On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti
> wrote:
> >
> > Once a page is read with higher bitflips all subsequent reads
> > are returning the same bitflip value even though they have none.
> > max_bitflip variable is not being reset to 0 across page reads.
> >
> > This is causing problems like incorrectly
> > marking erase blocks bad by UBI and causing read failures.
> >
> > Verified the change with both MTD reads and UBI.
> > This change is inline with other NFC drivers.
> >
> > Sample error log where a block is marked bad incorrectly:
> >
> > ubi0: fixable bit-flip detected at PEB 125
> > ubi0: run torture test for PEB 125
> > ubi0: fixable bit-flip detected at PEB 125
> > ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> > must be bad
> > ubi0 error: erase_worker: failed to erase PEB 125, error -5
> > ubi0: mark PEB 125 as bad
> >
> > Signed-off-by: rminnikanti
>
> Looks good to me
>
> Reviewed-by: Chris Packham
>
> > ---
> > drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > index 1d9a6d107b..d2a4faad56 100644
> > --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > @@ -800,6 +800,11 @@ static void prepare_start_command(struct
> > pxa3xx_nand_info *info, int command)
> > info->ecc_err_cnt = 0;
> > info->ndcb3 = 0;
> > info->need_wait = 0;
> > + /*
> > +* Reset max_bitflips to zero. Once command is complete,
> > +* max_bitflips for this READ is returned in ecc.read_page()
> > +*/
> > + info->max_bitflips = 0;
> >
Why this should not be put to 0 in read_page instead on prepare_start_command?
Michael
> > switch (command) {
> > case NAND_CMD_READ0:
> > --
> > 2.17.1
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] ubi: Depend on MTD
Hi Dario On Fri, Apr 26, 2024 at 5:52 PM Tom Rini wrote: > > On Fri, Apr 26, 2024 at 07:18:18AM +0200, Heiko Schocher wrote: > > Hello Tom, > > > > On 11.04.24 08:09, Michael Nazzareno Trimarchi wrote: > > > Hi > > > > > > On Thu, Apr 11, 2024 at 7:06 AM John Watts wrote: > > > > > > > > UBI required MTD to build correctly, add it as a Kconfig dependency. > > > > > > > > Signed-off-by: John Watts > > > > --- > > > > While working with UBI on my SPI NAND patch series I found it was > > > > possible to enable it without enabling the MTD subsystem. > > > > Add a Kconfig option to solve this. > > > > --- > > > > drivers/mtd/ubi/Kconfig | 1 + > > > > 1 file changed, 1 insertion(+) > > > > Seems I am too dummy to find this patch in Patchwork, nor is it > > applied in master ... can you pick it up, or should I do this and > > send you a pull request? > > It's over at > https://patchwork.ozlabs.org/project/uboot/patch/20240411-mtd-v1-1-fe300f6ab...@jookia.org/ > currently but you can take it up and send it to me if you like. > Can you pick it up? Seems that you are delegate and was already reviewed by me Michael > -- > Tom -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] clk: imx8mn: add video clocks support
Hi Fabio On Sun, Apr 21, 2024 at 10:54 PM Michael Nazzareno Trimarchi wrote: > > Hi Fabio > > On Sun, Apr 21, 2024 at 10:24 PM Fabio Estevam wrote: > > > > Hi Michael, > > > > On Sun, Apr 21, 2024 at 11:07 AM Michael Trimarchi > > wrote: > > > > > > Add clocks support for the video subsystem. > > > > > > Signed-off-by: Michael Trimarchi > > > > Which target will make use of these clocks? > > > > As-is this patch adds only dead code. > > > > Adding a defconfig that uses these newly introduced clocks would be nice. > > > > You are right, I will wrap it and enable only on CONFIG_VIDEO > > > Also, to avoid size increase, please protect this code against > > CONFIG_VIDEO or something, like done here: > > https://source.denx.de/u-boot/custodians/u-boot-imx/-/commit/2b3310ef13998dfd03196a0806e03035212b102c > > Working on display panel integration on imx8m, trying to progress > merging things up. > Are you considering if I wrap properly with VIDEO IS_ENABLED? Michael > Michael > > > > -- > Michael Nazzareno Trimarchi > Co-Founder & Chief Executive Officer > M. +39 347 913 2170 > mich...@amarulasolutions.com > ______ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > i...@amarulasolutions.com > www.amarulasolutions.com -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] clk: imx8mn: add video clocks support
Hi Fabio On Sun, Apr 21, 2024 at 10:24 PM Fabio Estevam wrote: > > Hi Michael, > > On Sun, Apr 21, 2024 at 11:07 AM Michael Trimarchi > wrote: > > > > Add clocks support for the video subsystem. > > > > Signed-off-by: Michael Trimarchi > > Which target will make use of these clocks? > > As-is this patch adds only dead code. > > Adding a defconfig that uses these newly introduced clocks would be nice. > You are right, I will wrap it and enable only on CONFIG_VIDEO > Also, to avoid size increase, please protect this code against > CONFIG_VIDEO or something, like done here: > https://source.denx.de/u-boot/custodians/u-boot-imx/-/commit/2b3310ef13998dfd03196a0806e03035212b102c Working on display panel integration on imx8m, trying to progress merging things up. Michael -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH v1] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
Hi Dario did you add those patches in CI and test them again? Michael On Wed, Apr 17, 2024 at 8:44 PM Arseniy Krasnov wrote: > > Hello, > > Sorry, pls ping > > Thanks, Arseniy > > On 13.03.2024 09:46, Michael Nazzareno Trimarchi wrote: > > Hi Dario > > > > Can apply this series and put in CI? > > > > Michael > > > > On Wed, Mar 13, 2024 at 7:43 AM Arseniy Krasnov > > wrote: > >> > >> Sorry, please ping > >> > >> Thanks, Arseniy > >> > >> On 11.02.2024 02:16, Arseniy Krasnov wrote: > >>> Sorry, pls ping > >>> > >>> Thanks, Arseniy > >>> > >>> On 08.01.2024 21:33, Arseniy Krasnov wrote: > >>>> Sorry, pls ping > >>>> > >>>> Thanks, Arseniy > > > > > > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 1/1] net: wget: fix TCP sequence number wrap around issue
Hi On Mon, Apr 15, 2024 at 3:55 PM Michael Nazzareno Trimarchi wrote: > > Hi > > On Mon, Apr 15, 2024 at 3:48 PM Yasuharu Shibata > wrote: > > > > Hi Michael, > > > > On Mon, 15 Apr 2024 at 22:03, Michael Nazzareno Trimarchi > > wrote: > > > > > > I think I have sent some time ago ;) > > > > > > Anyway look sane. I was having the same feeling on code inspection > > > > > > Reviewed-by: Michael Trimarchi > > > > Thank you for your review. > > I already checked the thread, sorry I couldn't find your patch and > > I couldn't see whether it is the same. > > In any case, I consider there is a potential issue about > > wrap around, so I submitted a patch. > > > > Very good job ;) to fix it. Just add Suggest-by: ;) > https://lore.kernel.org/all/caomzo5ao5x3ahr0ayriijya309usua0hj6okrhtqqvhw7i8...@mail.gmail.com/T/ Mine was here Michael > Michael > > > -- > > Best regards, > > Yasuharu Shibata > > > > -- > Michael Nazzareno Trimarchi > Co-Founder & Chief Executive Officer > M. +39 347 913 2170 > mich...@amarulasolutions.com > __ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > i...@amarulasolutions.com > www.amarulasolutions.com -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 1/1] net: wget: fix TCP sequence number wrap around issue
Hi On Mon, Apr 15, 2024 at 3:48 PM Yasuharu Shibata wrote: > > Hi Michael, > > On Mon, 15 Apr 2024 at 22:03, Michael Nazzareno Trimarchi > wrote: > > > > I think I have sent some time ago ;) > > > > Anyway look sane. I was having the same feeling on code inspection > > > > Reviewed-by: Michael Trimarchi > > Thank you for your review. > I already checked the thread, sorry I couldn't find your patch and > I couldn't see whether it is the same. > In any case, I consider there is a potential issue about > wrap around, so I submitted a patch. > Very good job ;) to fix it. Just add Suggest-by: ;) Michael > -- > Best regards, > Yasuharu Shibata -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 1/1] net: wget: fix TCP sequence number wrap around issue
Hi
On Mon, Apr 15, 2024 at 3:01 PM Yasuharu Shibata
wrote:
>
> If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
> isn't satisfied and store_block() isn't called.
> The condition has a wrap around issue, so it is fixed in this patch.
>
> Signed-off-by: Yasuharu Shibata
> ---
> net/wget.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/wget.c b/net/wget.c
> index 71bac92d84..abab371e58 100644
> --- a/net/wget.c
> +++ b/net/wget.c
> @@ -404,9 +404,7 @@ static void wget_handler(uchar *pkt, u16 dport,
> }
> next_data_seq_num = tcp_seq_num + len;
>
> - if (tcp_seq_num >= initial_data_seq_num &&
> - store_block(pkt, tcp_seq_num - initial_data_seq_num,
> - len) != 0) {
> + if (store_block(pkt, tcp_seq_num - initial_data_seq_num, len)
> != 0) {
> wget_fail("wget: store error\n",
> tcp_seq_num, tcp_ack_num, action);
> net_set_state(NETLOOP_FAIL);
I think I have sent some time ago ;)
Anyway look sane. I was having the same feeling on code inspection
Reviewed-by: Michael Trimarchi
> --
> 2.25.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v3 0/3] Introduce mtdblock device
Hi I will review tomorrow, I need have a time window to test even on my board Mihcael On Thu, Apr 11, 2024 at 6:09 PM Alexey Romanov wrote: > > Hello! Ping. > > On Thu, Apr 04, 2024 at 01:58:10PM +0300, 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. > > > > --- > > > > Changes V1 -> V2 [1]: > > > > - Drop patch [2]. > > - Add warning if bind NAND mtdblock device. > > - Move documentation of mtdblock implementation > > from commit message to the source code. > > - Remove __maybe_unused from mtd partition functions > > description. > > - Use blk_enabled() instead of #ifdefs. > > > > Changes V2 -> V3 [2]: > > > > - Rebased over [3]. > > - Rename mtd_bread/bwrite -> mtd_blk_read/write. > > - Fix GPL-2.0 license short name definiton in headers. > > - Add empty line after MTD_ENTRY_NUMBERS define. > > > > Links: > > > > - [1] > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > - [2] > > https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ > > - [3] > > https://lore.kernel.org/u-boot/20240403114047.84030-1-heinrich.schucha...@canonical.com/T/#u > > > > Alexey Romanov (3): > > disk: support MTD partitions > > drivers: introduce mtdblock abstraction > > spinand: bind mtdblock > > > > disk/part.c | 3 +- > > drivers/block/blk-uclass.c | 1 + > > drivers/mtd/Kconfig | 1 + > > drivers/mtd/Makefile| 1 + > > drivers/mtd/mtdblock.c | 227 > > drivers/mtd/mtdpart.c | 69 +++ > > drivers/mtd/nand/spi/core.c | 20 > > include/linux/mtd/mtd.h | 12 ++ > > include/part.h | 3 + > > 9 files changed, 336 insertions(+), 1 deletion(-) > > create mode 100644 drivers/mtd/mtdblock.c > > > > -- > > 2.34.1 > > > > -- > Thank you, > Alexey -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] ubi: Depend on MTD
Hi On Thu, Apr 11, 2024 at 7:06 AM John Watts wrote: > > UBI required MTD to build correctly, add it as a Kconfig dependency. > > Signed-off-by: John Watts > --- > While working with UBI on my SPI NAND patch series I found it was > possible to enable it without enabling the MTD subsystem. > Add a Kconfig option to solve this. > --- > drivers/mtd/ubi/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig > index 5783d36c04..fd446d6efb 100644 > --- a/drivers/mtd/ubi/Kconfig > +++ b/drivers/mtd/ubi/Kconfig > @@ -9,6 +9,7 @@ config UBI_SILENCE_MSG > > config MTD_UBI > bool "Enable UBI - Unsorted block images" > + depends on MTD > select RBTREE > select MTD_PARTITIONS > help > > --- Reviewed-by: Michael Trimarchi > base-commit: 777c28460947371ada40868dc994dfe8537d7115 > change-id: 20240411-mtd-d2e811e17cc8 > > Best regards, > -- > John Watts > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH v2 6/6] cmd: nand: Add new optional sub-command 'onfi'
HI On Fri, Mar 22, 2024 at 1:02 PM Alexander Dahl wrote: > > Hello Michael, > > Am Fri, Mar 22, 2024 at 12:54:27PM +0100 schrieb Michael Nazzareno Trimarchi: > > HI > > > > On Fri, Mar 22, 2024 at 12:46 PM Alexander Dahl wrote: > > > > > > Hello Mihai, > > > > > > Am Fri, Mar 22, 2024 at 10:02:29AM + schrieb mihai.s...@microchip.com: > > > > Hi Michael, > > > > > > > > --- > > > > > > > > I think this command can be really useful. > > > > Let try to have more testing on more boards > > > > > > > > - > > > > > > > > I managed to test the command on sama7g54-curiosity board. > > > > > > Thanks for that. Nice to see it works on other variants of the SoC > > > family. > > > > > > > I also forced timing mode 5 from controller driver > > > > (conf->timings.sdr.tRC_min < 2). > > > > > > You did a similar thing for the sam9x75. These boards/socs seem to > > > have a newer SMC / HSMC controller than sama5d2 or sam9x60? The > > > driver claims all the (H)SMC incarnations do _not_ support these EDO > > > modes 4 and 5. Maybe someone could have a deeper look at the > > > datasheets of the newer SoCs and propose a patch to support those > > > newer controllers in the atmel nand-controller driver? I guess the > > > problem is the same in Linux, right? > > > > > > Greets > > > Alex > > > > > > > > > > > => nand onfi 0 > > > > => hsmc decode > > > > > > > > MCK rate: 200 MHz > > > > > > > > HSMC_SETUP3:0x0004 > > > > HSMC_PULSE3:0x140a140a > > > > HSMC_CYCLE3:0x00140014 > > > > HSMC_TIMINGS3: 0x880805f4 > > > > HSMC_MODE3: 0x001f0003 > > > > NCS_RD: setup: 0 (0 ns), pulse: 20 (100 ns), hold: 0 (0 ns), cycle: 20 > > > > (100 ns) > > > >NRD: setup: 0 (0 ns), pulse: 10 (50 ns), hold: 10 (50 ns), cycle: 20 > > > > (100 ns) > > > > NCS_WR: setup: 0 (0 ns), pulse: 20 (100 ns), hold: 0 (0 ns), cycle: 20 > > > > (100 ns) > > > >NWE: setup: 4 (20 ns), pulse: 10 (50 ns), hold: 6 (30 ns), cycle: 20 > > > > (100 ns) > > > > TDF optimization enabled > > > > TDF cycles: 15 (75 ns) > > > > Data Bus Width: 8-bit bus > > > > NWAIT Mode: 0 > > > > Write operation controlled by NWE signal > > > > Read operation controlled by NRD signal > > > > NFSEL (NAND Flash Selection) is set > > > > OCMS (Off Chip Memory Scrambling) is disabled > > > > TWB (WEN High to REN to Busy): 64 (320 ns) > > > > TRR (Ready to REN Low Delay): 64 (320 ns) > > > > TAR (ALE to REN Low Delay):5 (25 ns) > > > > TADL (ALE to Data Start): 71 (355 ns) > > > > TCLR (CLE to REN Low Delay): 4 (20 ns) > > > > > > > > => time nand torture 0x100 0x100 > > > > > > > > NAND torture: device 0 offset 0x100 size 0x100 (block size > > > > 0x4) > > > > Passed: 64, failed: 0 > > > > > > > > time: 22.638 seconds > > > > > > > > => nand onfi 5 > > > > => hsmc decode > > > > > > > > MCK rate: 200 MHz > > > > > > > > HSMC_SETUP3:0x0001 > > > > HSMC_PULSE3:0x07040502 > > > > HSMC_CYCLE3:0x00070005 > > > > HSMC_TIMINGS3: 0x880402f2 > > > > HSMC_MODE3: 0x001f0003 > > > > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 > > > > ns) > > > >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 > > > > (35 ns) > > > > NCS_WR: setup: 0 (0 ns), pulse: 5 (25 ns), hold: 0 (0 ns), cycle: 5 (25 > > > > ns) > > > >NWE: setup: 1 (5 ns), pulse: 2 (10 ns), hold: 2 (10 ns), cycle: 5 > > > > (25 ns) > > > > TDF optimization enabled > > > > TDF cycles: 15 (75 ns) > > > > Data Bus Width: 8-bit bus > > > > NWAIT Mode: 0 > > > > Write operation controlled by NWE signal > > > > Read operation controlled by NRD signal > > > > NFSEL (NAND Flash Selection) is set > > > > OCMS (Off Chip Memory Scrambl
Re: [PATCH v2 6/6] cmd: nand: Add new optional sub-command 'onfi'
HI On Fri, Mar 22, 2024 at 12:46 PM Alexander Dahl wrote: > > Hello Mihai, > > Am Fri, Mar 22, 2024 at 10:02:29AM + schrieb mihai.s...@microchip.com: > > Hi Michael, > > > > --- > > > > I think this command can be really useful. > > Let try to have more testing on more boards > > > > - > > > > I managed to test the command on sama7g54-curiosity board. > > Thanks for that. Nice to see it works on other variants of the SoC > family. > > > I also forced timing mode 5 from controller driver > > (conf->timings.sdr.tRC_min < 2). > > You did a similar thing for the sam9x75. These boards/socs seem to > have a newer SMC / HSMC controller than sama5d2 or sam9x60? The > driver claims all the (H)SMC incarnations do _not_ support these EDO > modes 4 and 5. Maybe someone could have a deeper look at the > datasheets of the newer SoCs and propose a patch to support those > newer controllers in the atmel nand-controller driver? I guess the > problem is the same in Linux, right? > > Greets > Alex > > > > > => nand onfi 0 > > => hsmc decode > > > > MCK rate: 200 MHz > > > > HSMC_SETUP3:0x0004 > > HSMC_PULSE3:0x140a140a > > HSMC_CYCLE3:0x00140014 > > HSMC_TIMINGS3: 0x880805f4 > > HSMC_MODE3: 0x001f0003 > > NCS_RD: setup: 0 (0 ns), pulse: 20 (100 ns), hold: 0 (0 ns), cycle: 20 (100 > > ns) > >NRD: setup: 0 (0 ns), pulse: 10 (50 ns), hold: 10 (50 ns), cycle: 20 > > (100 ns) > > NCS_WR: setup: 0 (0 ns), pulse: 20 (100 ns), hold: 0 (0 ns), cycle: 20 (100 > > ns) > >NWE: setup: 4 (20 ns), pulse: 10 (50 ns), hold: 6 (30 ns), cycle: 20 > > (100 ns) > > TDF optimization enabled > > TDF cycles: 15 (75 ns) > > Data Bus Width: 8-bit bus > > NWAIT Mode: 0 > > Write operation controlled by NWE signal > > Read operation controlled by NRD signal > > NFSEL (NAND Flash Selection) is set > > OCMS (Off Chip Memory Scrambling) is disabled > > TWB (WEN High to REN to Busy): 64 (320 ns) > > TRR (Ready to REN Low Delay): 64 (320 ns) > > TAR (ALE to REN Low Delay):5 (25 ns) > > TADL (ALE to Data Start): 71 (355 ns) > > TCLR (CLE to REN Low Delay): 4 (20 ns) > > > > => time nand torture 0x100 0x100 > > > > NAND torture: device 0 offset 0x100 size 0x100 (block size 0x4) > > Passed: 64, failed: 0 > > > > time: 22.638 seconds > > > > => nand onfi 5 > > => hsmc decode > > > > MCK rate: 200 MHz > > > > HSMC_SETUP3:0x0001 > > HSMC_PULSE3:0x07040502 > > HSMC_CYCLE3:0x00070005 > > HSMC_TIMINGS3: 0x880402f2 > > HSMC_MODE3: 0x001f0003 > > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) > >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns) > > NCS_WR: setup: 0 (0 ns), pulse: 5 (25 ns), hold: 0 (0 ns), cycle: 5 (25 ns) > >NWE: setup: 1 (5 ns), pulse: 2 (10 ns), hold: 2 (10 ns), cycle: 5 (25 ns) > > TDF optimization enabled > > TDF cycles: 15 (75 ns) > > Data Bus Width: 8-bit bus > > NWAIT Mode: 0 > > Write operation controlled by NWE signal > > Read operation controlled by NRD signal > > NFSEL (NAND Flash Selection) is set > > OCMS (Off Chip Memory Scrambling) is disabled > > TWB (WEN High to REN to Busy): 64 (320 ns) > > TRR (Ready to REN Low Delay): 4 (20 ns) > > TAR (ALE to REN Low Delay):2 (10 ns) > > TADL (ALE to Data Start): 71 (355 ns) > > TCLR (CLE to REN Low Delay): 2 (10 ns) > > > > => time nand torture 0x100 0x100 > > > > NAND torture: device 0 offset 0x100 size 0x100 (block size 0x4) > > Passed: 64, failed: 0 > > > > time: 11.661 seconds > > > > => nand info > > > > Device 0: nand0, sector size 256 KiB > > Manufacturer MACRONIX > > Model MX30LF4G28AD > > Device size512 MiB > > Page size 4096 b > > OOB size 256 b > > Erase size 262144 b > > ecc strength 8 bits > > ecc step size 512 b > > subpagesize 4096 b > > options 0x40004200 > > bbt options 0x00028000 > > > > Best regards, > > Mihai Sain I'm in favor to have it even cover by one soc family. I would like to confirm on imx6 and imx8. If you are not in a rush. Let's us test too Michael -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH v4] cmd: mtd: OTP access support
Hi Arseniy
On Fri, Mar 22, 2024 at 9:14 AM Arseniy Krasnov
wrote:
>
> Hi,
>
> On 22.03.2024 11:12, Michael Nazzareno Trimarchi wrote:
> > Hi Arseniy
> >
> > On Wed, Mar 20, 2024 at 8:14 PM Arseniy Krasnov
> > wrote:
> >>
> >> Add access to OTP region. It supports info, dump, write and lock
> >> operations. Usage example:
> >>
> >> 'mtd otpread nand0 u 0 1024' - dump 1024 bytes of user area starting
> >> from offset 0 of device 'nand0'.
> >>
> >> 'mtd otpwrite nand0 10 11223344' - write binary data 0x11, 0x22, 0x33,
> >> 0x44 to offset 10 to user area of device 'nand0'.
> >>
> >> 'mtd otplock nand0 0 1024' - lock 1024 bytes of user area starting
> >> from offset 0 of device 'nand0'.
> >>
> >> 'mtd otpinfo nand0 f' - show info about factory area of device 'nand0'.
> >>
> >> Signed-off-by: Arseniy Krasnov
> >> Reviewed-by: Michael Trimarchi
> >> ---
> >> Changelog:
> >> v1 -> v2:
> >> * Remove warning that OTP can't be erased after write.
> >> v2 -> v3:
> >> * Commit message updated by adding usage.
> >> * R-b added.
> >> v3 -> v4:
> >> * Fix build failure due to invalid format strings for 'printf()'.
> >> * Rebase over latest version of cmd/mtd.c.
> >>
> >> cmd/Kconfig | 1 +
> >> cmd/mtd.c | 224
> >> 2 files changed, 225 insertions(+)
> >>
> >> diff --git a/cmd/Kconfig b/cmd/Kconfig
> >> index 7292a150f5..f218dc6cf2 100644
> >> --- a/cmd/Kconfig
> >> +++ b/cmd/Kconfig
> >> @@ -1363,6 +1363,7 @@ config CMD_MTD
> >> bool "mtd"
> >> depends on MTD
> >> select MTD_PARTITIONS
> >> + select HEXDUMP
> >
> > Make those change forced in increase the size of uboot and break this build
> >
> > https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/jobs/802378
> >
> > I think that those command could be optional and not forced to be
> > included by default
> >
>
> Ah, Ok:) I'll add it as config option which depends on CMD_MTD in the next
> version
>
I am really glad how you interact with the mailing list ;) and how you
are fast on feedback
Michael
> Thanks
>
> > Michael
> >
> >
> >> help
> >> MTD commands support.
> >>
> >> diff --git a/cmd/mtd.c b/cmd/mtd.c
> >> index e63c011e79..2b03a85ef0 100644
> >> --- a/cmd/mtd.c
> >> +++ b/cmd/mtd.c
> >> @@ -11,6 +11,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -202,6 +203,219 @@ static bool mtd_oob_write_is_empty(struct
> >> mtd_oob_ops *op)
> >> return true;
> >> }
> >>
> >> +static int do_mtd_otp_read(struct cmd_tbl *cmdtp, int flag, int argc,
> >> + char *const argv[])
> >> +{
> >> + struct mtd_info *mtd;
> >> + size_t retlen;
> >> + off_t from;
> >> + size_t len;
> >> + bool user;
> >> + int ret;
> >> + u8 *buf;
> >> +
> >> + if (argc != 5)
> >> + return CMD_RET_USAGE;
> >> +
> >> + if (!strcmp(argv[2], "u"))
> >> + user = true;
> >> + else if (!strcmp(argv[2], "f"))
> >> + user = false;
> >> + else
> >> + return CMD_RET_USAGE;
> >> +
> >> + mtd = get_mtd_by_name(argv[1]);
> >> + if (IS_ERR_OR_NULL(mtd))
> >> + return CMD_RET_FAILURE;
> >> +
> >> + from = simple_strtoul(argv[3], NULL, 0);
> >> + len = simple_strtoul(argv[4], NULL, 0);
> >> +
> >> + ret = CMD_RET_FAILURE;
> >> +
> >> + buf = malloc(len);
> >> + if (!buf)
> >> + goto put_mtd;
> >> +
> >> + printf("Reading %s OTP from 0x%lx, %zu bytes\n",
> >> + user ? "user" : "factory", from, len);
> >> +
> >> + if (user)
> >> + ret = mtd_read_user_prot_reg(mtd, from, len, , buf);
> >> + else
> >> + ret = mtd_read_fact_prot_reg(mtd,
Re: [PATCH v4] cmd: mtd: OTP access support
;
> + goto put_mtd;
> + }
> +
> + ret = CMD_RET_SUCCESS;
> +
> +put_mtd:
> + put_mtd_device(mtd);
> +
> + return ret;
> +}
> +
> +static int do_mtd_otp_write(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct mtd_info *mtd;
> + size_t retlen;
> + size_t binlen;
> + u8 *binbuf;
> + off_t from;
> + int ret;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> +
> + mtd = get_mtd_by_name(argv[1]);
> + if (IS_ERR_OR_NULL(mtd))
> + return CMD_RET_FAILURE;
> +
> + from = simple_strtoul(argv[2], NULL, 0);
> + binlen = strlen(argv[3]) / 2;
> +
> + ret = CMD_RET_FAILURE;
> + binbuf = malloc(binlen);
> + if (!binbuf)
> + goto put_mtd;
> +
> + hex2bin(binbuf, argv[3], binlen);
> +
> + printf("Will write:\n");
> +
> + print_hex_dump("", 0, 16, 1, binbuf, binlen, true);
> +
> + printf("to 0x%lx\n", from);
> +
> + printf("Continue (y/n)?\n");
> +
> + if (confirm_yesno() != 1) {
> + pr_err("OTP write canceled\n");
> + ret = CMD_RET_SUCCESS;
> + goto put_mtd;
> + }
> +
> + ret = mtd_write_user_prot_reg(mtd, from, binlen, , binbuf);
> + if (ret) {
> + pr_err("OTP write failed: %d\n", ret);
> + ret = CMD_RET_FAILURE;
> + goto put_mtd;
> + }
> +
> + if (retlen != binlen)
> + pr_err("OTP write returns %zu, but %zu expected\n",
> + retlen, binlen);
> +
> + ret = CMD_RET_SUCCESS;
> +
> +put_mtd:
> + free(binbuf);
> + put_mtd_device(mtd);
> +
> + return ret;
> +}
> +
> +static int do_mtd_otp_info(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct otp_info otp_info;
> + struct mtd_info *mtd;
> + size_t retlen;
> + bool user;
> + int ret;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + if (!strcmp(argv[2], "u"))
> + user = true;
> + else if (!strcmp(argv[2], "f"))
> + user = false;
> + else
> + return CMD_RET_USAGE;
> +
> + mtd = get_mtd_by_name(argv[1]);
> + if (IS_ERR_OR_NULL(mtd))
> + return CMD_RET_FAILURE;
> +
> + if (user)
> + ret = mtd_get_user_prot_info(mtd, sizeof(otp_info), ,
> +_info);
> + else
> + ret = mtd_get_fact_prot_info(mtd, sizeof(otp_info), ,
> +_info);
> + if (ret) {
> + pr_err("OTP info failed: %d\n", ret);
> + ret = CMD_RET_FAILURE;
> + goto put_mtd;
> + }
> +
> + if (retlen != sizeof(otp_info)) {
> + pr_err("OTP info returns %zu, but %zu expected\n",
> + retlen, sizeof(otp_info));
> + ret = CMD_RET_FAILURE;
> + goto put_mtd;
> + }
> +
> + printf("%s OTP region info:\n", user ? "User" : "Factory");
> + printf("\tstart: %u\n", otp_info.start);
> + printf("\tlength: %u\n", otp_info.length);
> + printf("\tlocked: %u\n", otp_info.locked);
> +
> + ret = CMD_RET_SUCCESS;
> +
> +put_mtd:
> + put_mtd_device(mtd);
> +
> + return ret;
> +}
> +
> static int do_mtd_list(struct cmd_tbl *cmdtp, int flag, int argc,
>char *const argv[])
> {
> @@ -551,6 +765,10 @@ U_BOOT_LONGHELP(mtd,
> "\n"
> "Specific functions:\n"
> "mtd bad \n"
> + "mtd otpread[u|f] \n"
> + "mtd otpwrite\n"
> + "mtd otplock \n"
> + "mtd otpinfo[u|f]\n"
> "\n"
> "With:\n"
> "\t: NAND partition/chip name (or corresponding DM device name
> or OF path)\n"
> @@ -561,10 +779,16 @@ U_BOOT_LONGHELP(mtd,
> "\t: length of the operation in bytes (default: the entire
> device)\n"
> "\t\t* must be a multiple of a block for erase\n"
> "\t\t* must be a multiple of a page otherwise (special case: default
> is a page with dump)\n"
> + "\t: hex string without '0x' and spaces. Example:
> ABCD1234\n"
> + "\t[u|f]: user or factory OTP region\n"
> "\n"
> "The .dontskipff option forces writing empty pages, don't use it if
> unsure.\n");
>
> U_BOOT_CMD_WITH_SUBCMDS(mtd, "MTD utils", mtd_help_text,
> + U_BOOT_SUBCMD_MKENT(otpread, 5, 1, do_mtd_otp_read),
> + U_BOOT_SUBCMD_MKENT(otpwrite, 4, 1, do_mtd_otp_write),
> + U_BOOT_SUBCMD_MKENT(otplock, 4, 1, do_mtd_otp_lock),
> + U_BOOT_SUBCMD_MKENT(otpinfo, 3, 1, do_mtd_otp_info),
> U_BOOT_SUBCMD_MKENT(list, 1, 1, do_mtd_list),
> U_BOOT_SUBCMD_MKENT_COMPLETE(read, 5, 0, do_mtd_io,
> mtd_name_complete),
> --
> 2.35.0
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 6/6] cmd: nand: Add new optional sub-command 'onfi'
Hi I think this command can be really useful. On Wed, Mar 20, 2024 at 3:09 PM wrote: > > Hi Alex, > > > > Override the ONFI timing mode at runtime. > > Signed-off-by: Alexander Dahl > --- > > I used the same board sam9x75-curiosity to test mode 5 > > I forced in nfc driver the mode 5: > + if (conf->timings.sdr.tRC_min < 2) > > And I ran the nand torture on 16 MiB: > > => nand onfi 0 > => hsmc decode > > MCK rate: 270 MHz > > SMC_SETUP2: 0x0007 > SMC_PULSE2: 0x22112211 > SMC_CYCLE2: 0x00220022 > SMC_MODE2: 0x001f0003 > NCS_RD: setup: 0 (0 ns), pulse: 34 (102 ns), hold: 0 (0 ns), cycle: 34 (102 > ns) >NRD: setup: 0 (0 ns), pulse: 17 (51 ns), hold: 17 (51 ns), cycle: 34 (102 > ns) > NCS_WR: setup: 0 (0 ns), pulse: 34 (102 ns), hold: 0 (0 ns), cycle: 34 (102 > ns) >NWE: setup: 7 (21 ns), pulse: 17 (51 ns), hold: 10 (30 ns), cycle: 34 (102 > ns) > Standard read applied > TDF optimization enabled > TDF cycles: 15 (45 ns) > Data Bus Width: 8-bit bus > NWAIT Mode: 0 > Write operation controlled by NWE signal > Read operation controlled by NRD signal > > => time nand torture 0x80 0x100 > > NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4) > Passed: 64, failed: 0 > > time: 30.152 seconds > > => nand onfi 5 > => hsmc decode > > MCK rate: 270 MHz > > SMC_SETUP2: 0x0001 > SMC_PULSE2: 0x0b060804 > SMC_CYCLE2: 0x000b0008 > SMC_MODE2: 0x001f0003 > NCS_RD: setup: 0 (0 ns), pulse: 11 (33 ns), hold: 0 (0 ns), cycle: 11 (33 ns) >NRD: setup: 0 (0 ns), pulse: 6 (18 ns), hold: 5 (15 ns), cycle: 11 (33 ns) > NCS_WR: setup: 0 (0 ns), pulse: 8 (24 ns), hold: 0 (0 ns), cycle: 8 (24 ns) >NWE: setup: 1 (3 ns), pulse: 4 (12 ns), hold: 3 (9 ns), cycle: 8 (24 ns) > Standard read applied > TDF optimization enabled > TDF cycles: 15 (45 ns) > Data Bus Width: 8-bit bus > NWAIT Mode: 0 > Write operation controlled by NWE signal > Read operation controlled by NRD signal > > => time nand torture 0x80 0x100 > > NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4) > Passed: 64, failed: 0 > > time: 15.891 seconds > Let try to have more testing on more boards Michael > Best regards, > Mihai Sain -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 1/1] fs: ext4: all file paths are absolute
On Wed, Mar 20, 2024 at 2:25 PM Heinrich Schuchardt
wrote:
>
> U-Boot only knows absolute file paths. It is inconsistent to require that
> saving to an ext4 file system should use a leading '/' wile reading does
> not. Remove the superfluous check.
>
Just a typo, "wile reading"
Michael
> Reported-by: Patrice Chotard
> Signed-off-by: Heinrich Schuchardt
> ---
> fs/ext4/ext4_common.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index ea9b92298ba..9eac6beef3b 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -765,11 +765,6 @@ int ext4fs_get_parent_inode_num(const char *dirname,
> char *dname, int flags)
> struct ext2_inode *first_inode = NULL;
> struct ext2_inode temp_inode;
>
> - if (*dirname != '/') {
> - printf("Please supply Absolute path\n");
> - return -1;
> - }
> -
> /* TODO: input validation make equivalent to linux */
> depth_dirname = zalloc(strlen(dirname) + 1);
> if (!depth_dirname)
> --
> 2.43.0
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v3] cmd: mtd: OTP access support
char *const argv[])
> +{
> + struct mtd_info *mtd;
> + size_t retlen;
> + size_t binlen;
> + u8 *binbuf;
> + off_t from;
> + int ret;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> +
> + mtd = get_mtd_by_name(argv[1]);
> + if (IS_ERR_OR_NULL(mtd))
> + return CMD_RET_FAILURE;
> +
> + from = simple_strtoul(argv[2], NULL, 0);
> + binlen = strlen(argv[3]) / 2;
> +
> + ret = CMD_RET_FAILURE;
> + binbuf = malloc(binlen);
> + if (!binbuf)
> + goto put_mtd;
> +
> + hex2bin(binbuf, argv[3], binlen);
> +
> + printf("Will write:\n");
> +
> + print_hex_dump("", 0, 16, 1, binbuf, binlen, true);
> +
> + printf("to 0x%zx\n", from);
> +
> + printf("Continue (y/n)?\n");
> +
> + if (confirm_yesno() != 1) {
> + pr_err("OTP write canceled\n");
> + ret = CMD_RET_SUCCESS;
> + goto put_mtd;
> + }
> +
> + ret = mtd_write_user_prot_reg(mtd, from, binlen, , binbuf);
> + if (ret) {
> + pr_err("OTP write failed: %d\n", ret);
> + ret = CMD_RET_FAILURE;
> + goto put_mtd;
> + }
> +
> + if (retlen != binlen)
> + pr_err("OTP write returns %zu, but %zu expected\n",
> + retlen, binlen);
> +
> + ret = CMD_RET_SUCCESS;
> +
> +put_mtd:
> + free(binbuf);
> + put_mtd_device(mtd);
> +
> + return ret;
> +}
> +
> +static int do_mtd_otp_info(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct otp_info otp_info;
> + struct mtd_info *mtd;
> + size_t retlen;
> + bool user;
> + int ret;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + if (!strcmp(argv[2], "u"))
> + user = true;
> + else if (!strcmp(argv[2], "f"))
> + user = false;
> + else
> + return CMD_RET_USAGE;
> +
> + mtd = get_mtd_by_name(argv[1]);
> + if (IS_ERR_OR_NULL(mtd))
> + return CMD_RET_FAILURE;
> +
> + if (user)
> + ret = mtd_get_user_prot_info(mtd, sizeof(otp_info), ,
> +_info);
> + else
> + ret = mtd_get_fact_prot_info(mtd, sizeof(otp_info), ,
> +_info);
> + if (ret) {
> + pr_err("OTP info failed: %d\n", ret);
> + ret = CMD_RET_FAILURE;
> + goto put_mtd;
> + }
> +
> + if (retlen != sizeof(otp_info)) {
> + pr_err("OTP info returns %zu, but %zu expected\n",
> + retlen, sizeof(otp_info));
> + ret = CMD_RET_FAILURE;
> + goto put_mtd;
> + }
> +
> + printf("%s OTP region info:\n", user ? "User" : "Factory");
> + printf("\tstart: %u\n", otp_info.start);
> + printf("\tlength: %u\n", otp_info.length);
> + printf("\tlocked: %u\n", otp_info.locked);
> +
> + ret = CMD_RET_SUCCESS;
> +
> +put_mtd:
> + put_mtd_device(mtd);
> +
> + return ret;
> +}
> +
> static int do_mtd_list(struct cmd_tbl *cmdtp, int flag, int argc,
>char *const argv[])
> {
> @@ -552,6 +766,10 @@ static char mtd_help_text[] =
> "\n"
> "Specific functions:\n"
> "mtd bad \n"
> + "mtd otpread[u|f] \n"
> + "mtd otpwrite\n"
> + "mtd otplock \n"
> + "mtd otpinfo[u|f]\n"
> "\n"
> "With:\n"
> "\t: NAND partition/chip name (or corresponding DM device name
> or OF path)\n"
> @@ -562,11 +780,17 @@ static char mtd_help_text[] =
> "\t: length of the operation in bytes (default: the entire
> device)\n"
> "\t\t* must be a multiple of a block for erase\n"
> "\t\t* must be a multiple of a page otherwise (special case: default
> is a page with dump)\n"
> + "\t: hex string without '0x' and spaces. Example:
> ABCD1234\n"
> + "\t[u|f]: user or factory OTP region\n"
> "\n"
> "The .dontskipff option forces writing empty pages, don't use it if
> unsure.\n";
> #endif
>
> U_BOOT_CMD_WITH_SUBCMDS(mtd, "MTD utils", mtd_help_text,
> + U_BOOT_SUBCMD_MKENT(otpread, 5, 1, do_mtd_otp_read),
> + U_BOOT_SUBCMD_MKENT(otpwrite, 4, 1, do_mtd_otp_write),
> + U_BOOT_SUBCMD_MKENT(otplock, 4, 1, do_mtd_otp_lock),
> + U_BOOT_SUBCMD_MKENT(otpinfo, 3, 1, do_mtd_otp_info),
> U_BOOT_SUBCMD_MKENT(list, 1, 1, do_mtd_list),
> U_BOOT_SUBCMD_MKENT_COMPLETE(read, 5, 0, do_mtd_io,
> mtd_name_complete),
> --
> 2.35.0
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 5/6] mtd: nand: raw: atmel: Fix comment in timings preparation
On Wed, Mar 20, 2024 at 10:02 AM Alexander Dahl wrote:
>
> Introduced with commit 6a8dfd57220d ("nand: atmel: Add DM based NAND
> driver") when driver was initially ported from Linux. The context
> around this and especially the code itself suggests 'read' is meant
> instead of write.
>
> The fix is the same as accepted in Linux already with mainline Linux
> kernel commit 1c60e027ffde ("mtd: nand: raw: atmel: Fix comment in
> timings preparation").
>
> Link:
> https://lore.kernel.org/linux-mtd/20240307172835.3453880-1-miquel.ray...@bootlin.com/T/#t
> Signed-off-by: Alexander Dahl
> ---
>
> Notes:
> v2:
> - initial patch version (not present in v1)
>
> drivers/mtd/nand/raw/atmel/nand-controller.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c
> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index 75da15c157b..bbafc88e44c 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -1271,7 +1271,7 @@ static int atmel_smc_nand_prepare_smcconf(struct
> atmel_nand *nand,
> return ret;
>
> /*
> -* The write cycle timing is directly matching tWC, but is also
> +* The read cycle timing is directly matching tRC, but is also
> * dependent on the setup and hold timings we calculated earlier,
> * which gives:
> *
> --
Reviewed-by: Michael Trimarchi
> 2.39.2
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2] cmd: mtd: OTP access support
;> + char *const argv[])
> >>> +{
> >>> + struct mtd_info *mtd;
> >>> + off_t from;
> >>> + size_t len;
> >>> + int ret;
> >>> +
> >>> + if (argc != 4)
> >>> + return CMD_RET_USAGE;
> >>> +
> >>> + mtd = get_mtd_by_name(argv[1]);
> >>> + if (IS_ERR_OR_NULL(mtd))
> >>> + return CMD_RET_FAILURE;
> >>> +
> >>> + from = simple_strtoul(argv[2], NULL, 0);
> >>> + len = simple_strtoul(argv[3], NULL, 0);
> >>> +
> >>> + ret = mtd_lock_user_prot_reg(mtd, from, len);
> >>> + if (ret) {
> >>> + pr_err("OTP lock failed: %d\n", ret);
> >>> + ret = CMD_RET_FAILURE;
> >>> + goto put_mtd;
> >>> + }
> >>> +
> >>> + ret = CMD_RET_SUCCESS;
> >>> +
> >>> +put_mtd:
> >>> + put_mtd_device(mtd);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static int do_mtd_otp_write(struct cmd_tbl *cmdtp, int flag, int argc,
> >>> + char *const argv[])
> >>> +{
> >>> + struct mtd_info *mtd;
> >>> + size_t retlen;
> >>> + size_t binlen;
> >>> + u8 *binbuf;
> >>> + off_t from;
> >>> + int ret;
> >>> +
> >>> + if (argc != 4)
> >>> + return CMD_RET_USAGE;
> >>> +
> >>> + mtd = get_mtd_by_name(argv[1]);
> >>> + if (IS_ERR_OR_NULL(mtd))
> >>> + return CMD_RET_FAILURE;
> >>> +
> >>> + from = simple_strtoul(argv[2], NULL, 0);
> >>> + binlen = strlen(argv[3]) / 2;
> >>> +
> >>> + ret = CMD_RET_FAILURE;
> >>> + binbuf = malloc(binlen);
> >>> + if (!binbuf)
> >>> + goto put_mtd;
> >>> +
> >>> + hex2bin(binbuf, argv[3], binlen);
> >>> +
> >>> + printf("Will write:\n");
> >>> +
> >>> + print_hex_dump("", 0, 16, 1, binbuf, binlen, true);
> >>> +
> >>> + printf("to 0x%zx\n", from);
> >>> +
> >>> + printf("Continue (y/n)?\n");
> >>> +
> >>> + if (confirm_yesno() != 1) {
> >>> + pr_err("OTP write canceled\n");
> >>> + ret = CMD_RET_SUCCESS;
> >>> + goto put_mtd;
> >>> + }
> >>> +
> >>> + ret = mtd_write_user_prot_reg(mtd, from, binlen, , binbuf);
> >>> + if (ret) {
> >>> + pr_err("OTP write failed: %d\n", ret);
> >>> + ret = CMD_RET_FAILURE;
> >>> + goto put_mtd;
> >>> + }
> >>> +
> >>> + if (retlen != binlen)
> >>> + pr_err("OTP write returns %zu, but %zu expected\n",
> >>> + retlen, binlen);
> >>> +
> >>> + ret = CMD_RET_SUCCESS;
> >>> +
> >>> +put_mtd:
> >>> + free(binbuf);
> >>> + put_mtd_device(mtd);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static int do_mtd_otp_info(struct cmd_tbl *cmdtp, int flag, int argc,
> >>> + char *const argv[])
> >>> +{
> >>> + struct otp_info otp_info;
> >>> + struct mtd_info *mtd;
> >>> + size_t retlen;
> >>> + bool user;
> >>> + int ret;
> >>> +
> >>> + if (argc != 3)
> >>> + return CMD_RET_USAGE;
> >>> +
> >>> + if (!strcmp(argv[2], "u"))
> >>> + user = true;
> >>> + else if (!strcmp(argv[2], "f"))
> >>> + user = false;
> >>> + else
> >>> + return CMD_RET_USAGE;
> >>> +
> >>> + mtd = get_mtd_by_name(argv[1]);
> >>> + if (IS_ERR_OR_NULL(mtd))
> >>> + return CMD_RET_FAILURE;
> >>> +
> >>> + if (user)
> >>> + ret = mtd_get_user_prot_info(mtd, sizeof(otp_info), ,
> >>> +_info);
> >>> + else
> >>> + ret = mtd_get_fact_prot_info(mtd, sizeof(otp_info), ,
> >>> +_info);
> >>> + if (ret) {
> >>> + pr_err("OTP info failed: %d\n", ret);
> >>> + ret = CMD_RET_FAILURE;
> >>> + goto put_mtd;
> >>> + }
> >>> +
> >>> + if (retlen != sizeof(otp_info)) {
> >>> + pr_err("OTP info returns %zu, but %zu expected\n",
> >>> + retlen, sizeof(otp_info));
> >>> + ret = CMD_RET_FAILURE;
> >>> + goto put_mtd;
> >>> + }
> >>> +
> >>> + printf("%s OTP region info:\n", user ? "User" : "Factory");
> >>> + printf("\tstart: %u\n", otp_info.start);
> >>> + printf("\tlength: %u\n", otp_info.length);
> >>> + printf("\tlocked: %u\n", otp_info.locked);
> >>> +
> >>> + ret = CMD_RET_SUCCESS;
> >>> +
> >>> +put_mtd:
> >>> + put_mtd_device(mtd);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> static int do_mtd_list(struct cmd_tbl *cmdtp, int flag, int argc,
> >>>char *const argv[])
> >>> {
> >>> @@ -552,6 +766,10 @@ static char mtd_help_text[] =
> >>> "\n"
> >>> "Specific functions:\n"
> >>> "mtd bad \n"
> >>> + "mtd otpread[u|f] \n"
> >>> + "mtd otpwrite\n"
> >>> + "mtd otplock \n"
> >>> + "mtd otpinfo[u|f]\n"
> >>> "\n"
> >>> "With:\n"
> >>> "\t: NAND partition/chip name (or corresponding DM device name
> >>> or OF path)\n"
> >>> @@ -562,11 +780,17 @@ static char mtd_help_text[] =
> >>> "\t: length of the operation in bytes (default: the entire
> >>> device)\n"
> >>> "\t\t* must be a multiple of a block for erase\n"
> >>> "\t\t* must be a multiple of a page otherwise (special case: default
> >>> is a page with dump)\n"
> >>> + "\t: hex string without '0x' and spaces. Example:
> >>> ABCD1234\n"
> >>> + "\t[u|f]: user or factory OTP region\n"
> >>> "\n"
> >>> "The .dontskipff option forces writing empty pages, don't use it if
> >>> unsure.\n";
> >>> #endif
> >>>
> >>> U_BOOT_CMD_WITH_SUBCMDS(mtd, "MTD utils", mtd_help_text,
> >>> + U_BOOT_SUBCMD_MKENT(otpread, 5, 1, do_mtd_otp_read),
> >>> + U_BOOT_SUBCMD_MKENT(otpwrite, 4, 1, do_mtd_otp_write),
> >>> + U_BOOT_SUBCMD_MKENT(otplock, 4, 1, do_mtd_otp_lock),
> >>> + U_BOOT_SUBCMD_MKENT(otpinfo, 3, 1, do_mtd_otp_info),
> >>> U_BOOT_SUBCMD_MKENT(list, 1, 1, do_mtd_list),
> >>> U_BOOT_SUBCMD_MKENT_COMPLETE(read, 5, 0, do_mtd_io,
> >>> mtd_name_complete),
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v1] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
Hi Dario Can apply this series and put in CI? Michael On Wed, Mar 13, 2024 at 7:43 AM Arseniy Krasnov wrote: > > Sorry, please ping > > Thanks, Arseniy > > On 11.02.2024 02:16, Arseniy Krasnov wrote: > > Sorry, pls ping > > > > Thanks, Arseniy > > > > On 08.01.2024 21:33, Arseniy Krasnov wrote: > >> Sorry, pls ping > >> > >> Thanks, Arseniy -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] mtd: nand: raw: mt7621-nand: allow writing ecc region in raw mode
Hi On Wed, Mar 13, 2024 at 4:38 AM Weijie Gao wrote: > > Allow writing ecc parity region in raw mode. This makes sure the > nand write.raw command can write the flash data as-is. > > Change-Id: Ibed3bdf13c9cf81e54041c5ac7a78192b97dcedc > Signed-off-by: Weijie Gao > CR-Id: WCNCR00180092 I think this is for internal tracking > --- > drivers/mtd/nand/raw/mt7621_nand.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mtd/nand/raw/mt7621_nand.c > b/drivers/mtd/nand/raw/mt7621_nand.c > index f6eddb84a9..341ef0bf2d 100644 > --- a/drivers/mtd/nand/raw/mt7621_nand.c > +++ b/drivers/mtd/nand/raw/mt7621_nand.c > @@ -1003,9 +1003,9 @@ static int mt7621_nfc_write_page_raw(struct mtd_info > *mtd, > mt7621_nfc_write_data(nfc, oob_fdm_ptr(nand, i), > NFI_FDM_SIZE); > > - /* Write dummy ECC parity data */ > - mt7621_nfc_write_data_empty(nfc, nfc->spare_per_sector - > - NFI_FDM_SIZE); > + /* Write ECC parity data */ > + mt7621_nfc_write_data(nfc, oob_ecc_ptr(nfc, i), > + nfc->spare_per_sector - NFI_FDM_SIZE); > } > Please describe better what regression you are trying to fix in the commit message Reviewed-by: Michael Trimarchi Michael > mt7621_nfc_wait_write_completion(nfc, nand); > -- > 2.34.1 > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 3/4] mtd: nand: raw: Fix (most) Kconfig indentation
SPL_SYS_NAND_SELF_INIT > imply CMD_NAND > - ---help--- > - Enable support for NAND. This option enables the standard and > - SPL drivers. > - The SPL driver only supports reading from the NAND using DMA > - transfers. > + help > + Enable support for NAND. This option enables the standard and > + SPL drivers. > + The SPL driver only supports reading from the NAND using DMA > + transfers. > > if NAND_SUNXI > > @@ -577,16 +577,16 @@ config NAND_OCTEONTX > select SYS_NAND_SELF_INIT > imply CMD_NAND > help > -This enables Nand flash controller hardware found on the OcteonTX > -processors. > + This enables Nand flash controller hardware found on the OcteonTX > + processors. > > config NAND_OCTEONTX_HW_ECC > bool "Support Hardware ECC for OcteonTX NAND controller" > depends on NAND_OCTEONTX > default y > help > -This enables Hardware BCH engine found on the OcteonTX processors to > -support ECC for NAND flash controller. > + This enables Hardware BCH engine found on the OcteonTX processors to > + support ECC for NAND flash controller. > > config NAND_STM32_FMC2 > bool "Support for NAND controller on STM32MP SoCs" > @@ -751,37 +751,37 @@ config SYS_NAND_BAD_BLOCK_POS > config SYS_NAND_U_BOOT_LOCATIONS > bool "Define U-Boot binaries locations in NAND" > help > - Enable CONFIG_SYS_NAND_U_BOOT_OFFS though Kconfig. > - This option should not be enabled when compiling U-Boot for boards > - defining CONFIG_SYS_NAND_U_BOOT_OFFS in their > include/configs/.h > - file. > + Enable CONFIG_SYS_NAND_U_BOOT_OFFS though Kconfig. > + This option should not be enabled when compiling U-Boot for boards > + defining CONFIG_SYS_NAND_U_BOOT_OFFS in their > include/configs/.h > + file. > > config SYS_NAND_U_BOOT_OFFS > hex "Location in NAND to read U-Boot from" > default 0x80 if NAND_SUNXI > depends on SYS_NAND_U_BOOT_LOCATIONS > help > - Set the offset from the start of the nand where u-boot should be > - loaded from. > + Set the offset from the start of the nand where u-boot should be > + loaded from. > > config SYS_NAND_U_BOOT_OFFS_REDUND > hex "Location in NAND to read U-Boot from" > default SYS_NAND_U_BOOT_OFFS > depends on SYS_NAND_U_BOOT_LOCATIONS > help > - Set the offset from the start of the nand where the redundant u-boot > - should be loaded from. > + Set the offset from the start of the nand where the redundant u-boot > + should be loaded from. > > config SPL_NAND_AM33XX_BCH > bool "Enables SPL-NAND driver which supports ELM based" > depends on SPL_NAND_SUPPORT && NAND_OMAP_GPMC && !OMAP34XX > default y > -help > + help > Hardware ECC correction. This is useful for platforms which have ELM > hardware engine and use NAND boot mode. > Some legacy platforms like OMAP3xx do not have in-built ELM h/w > engine, > so those platforms should use CONFIG_SPL_NAND_SIMPLE for enabling > - SPL-NAND driver with software ECC correction support. > + SPL-NAND driver with software ECC correction support. > > config SPL_NAND_DENALI > bool "Support Denali NAND controller for SPL" > @@ -810,6 +810,6 @@ config SYS_NAND_HW_ECC_OOBFIRST > bool "In SPL, read the OOB first and then the data from NAND" > depends on SPL_NAND_SIMPLE > > -endif > +endif # if SPL > > -endif # if NAND > +endif # if MTD_RAW_NAND > -- > 2.39.2 > Reviewed-by: Michael Trimarchi -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 2/4] mtd: nand: raw: Port another option flag from Linux
Hi
On Thu, Mar 7, 2024 at 10:10 AM Alexander Dahl wrote:
>
> Introduced in upstream Linux with commit 7a08dbaedd365 for release v5.0.
>
> When the new atmel nand driver was backported to U-Boot with commit
> 6a8dfd57220d ("nand: atmel: Add DM based NAND driver") that definition
> was added to the driver instead of the header file. Move it over to the
> other definitions with the same help text it has in Linux.
>
> Code actually using this has not been ported over to raw nand base yet.
>
> Signed-off-by: Alexander Dahl
> ---
> drivers/mtd/nand/raw/atmel/nand-controller.c | 2 --
> include/linux/mtd/rawnand.h | 7 +++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c
> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index 0e0441472b8..e06523f3298 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -1429,8 +1429,6 @@ static int atmel_nand_setup_data_interface(struct
> mtd_info *mtd, int csline,
> return nc->caps->ops->setup_data_interface(nand, csline, conf);
> }
>
> -#define NAND_KEEP_TIMINGS 0x0080
> -
> static void atmel_nand_init(struct atmel_nand_controller *nc,
> struct atmel_nand *nand)
> {
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index fb002ae6411..4abaf4734cf 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -249,6 +249,13 @@ enum nand_ecc_algo {
> */
> #define NAND_USE_BOUNCE_BUFFER 0x0010
>
> +/*
> + * Do not try to tweak the timings at runtime. This is needed when the
> + * controller initializes the timings on itself or when it relies on
> + * configuration done by the bootloader.
> + */
> +#define NAND_KEEP_TIMINGS 0x0080
> +
> /* Options set by nand scan */
> /* bbt has already been read */
> #define NAND_BBT_SCANNED 0x4000
Reviewed-by: Michael Trimarchi
> --
> 2.39.2
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 1/4] mtd: nand: raw: Use macro nand_to_mtd() where appropriate
On Thu, Mar 7, 2024 at 10:10 AM Alexander Dahl wrote:
>
> In every other place in this file the macro is used, make it consistent.
>
> Fixes: 9d1806fadc24 ("mtd: nand: Get rid of mtd variable in function calls")
> Signed-off-by: Alexander Dahl
> ---
> drivers/mtd/nand/raw/nand_base.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index c40a0f23d7b..688d17ba3c2 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4118,7 +4118,7 @@ static int nand_get_bits_per_cell(u8 cellinfo)
> */
> void nand_decode_ext_id(struct nand_chip *chip)
> {
> - struct mtd_info *mtd = >mtd;
> + struct mtd_info *mtd = nand_to_mtd(chip);
> int extid;
> /* The 3rd id byte holds MLC / multichip data */
> chip->bits_per_cell = nand_get_bits_per_cell(chip->id.data[2]);
> @@ -4185,7 +4185,7 @@ static int nand_manufacturer_init(struct nand_chip
> *chip)
> */
> static void nand_decode_id(struct nand_chip *chip, struct nand_flash_dev
> *type)
> {
> - struct mtd_info *mtd = >mtd;
> + struct mtd_info *mtd = nand_to_mtd(chip);
>
> mtd->erasesize = type->erasesize;
> mtd->writesize = type->pagesize;
> @@ -4265,7 +4265,7 @@ static const struct nand_manufacturer
> *nand_get_manufacturer_desc(u8 id)
> int nand_detect(struct nand_chip *chip, int *maf_id,
> int *dev_id, struct nand_flash_dev *type)
> {
> - struct mtd_info *mtd = >mtd;
> + struct mtd_info *mtd = nand_to_mtd(chip);
> const struct nand_manufacturer *manufacturer_desc;
> int busw, ret;
> u8 *id_data = chip->id.data;
> --
> 2.39.2
>
Reviewed-By: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] cmd: sf: Fix sf probe crash
Hi
On Mon, Mar 4, 2024 at 4:44 PM Heinrich Schuchardt wrote:
>
> On 04.03.24 15:47, Weizhao Ouyang wrote:
> > Gentle ping. Not merged yet.
> >
> > BR,
> > Weizhao
>
> Hello Dario,
>
> that patch is in your patchwork review queue. Could you, please, have a
> look.
He is with me, I will ping about all the patches that we need to queue
Michael
>
> Best regards
>
> Heinrich
>
> >
> > On Thu, Jan 4, 2024 at 7:46 PM Weizhao Ouyang wrote:
> >>
> >> Handle the return value of spi_flash_probe_bus_cs() to avoid sf probe
> >> crashes.
> >>
> >> Signed-off-by: Weizhao Ouyang
> >> ---
> >> cmd/sf.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/cmd/sf.c b/cmd/sf.c
> >> index 730996c02b..e3866899f6 100644
> >> --- a/cmd/sf.c
> >> +++ b/cmd/sf.c
> >> @@ -135,8 +135,9 @@ static int do_spi_flash_probe(int argc, char *const
> >> argv[])
> >> }
> >> flash = NULL;
> >> if (use_dt) {
> >> - spi_flash_probe_bus_cs(bus, cs, );
> >> - flash = dev_get_uclass_priv(new);
> >> + ret = spi_flash_probe_bus_cs(bus, cs, );
> >> + if (!ret)
> >> + flash = dev_get_uclass_priv(new);
> >> } else {
> >> flash = spi_flash_probe(bus, cs, speed, mode);
> >> }
> >> --
> >> 2.39.2
> >>
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx
_cache_variants),
> >> +0,
> >> +SPINAND_ECCINFO(_ooblayout,
> >> +xt26xxxd_ecc_get_status)),
> >> + SPINAND_INFO("XT26G12D",
> >> +SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x35),
> >> +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,
> >> +xt26xxxd_ecc_get_status)),
> >> + SPINAND_INFO("XT26Q02D",
> >> +SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x52),
> >> +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,
> >> +xt26xxxd_ecc_get_status)),
> >> + SPINAND_INFO("XT26G04D",
> >> +SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x33),
> >> +NAND_MEMORG(1, 4096, 256, 64, 2048, 40, 1, 1, 1),
> >> +NAND_ECCREQ(8, 512),
> >> + SPINAND_INFO_OP_VARIANTS(_cache_variants,
> >> + _cache_variants,
> >> + _cache_variants),
> >> +0,
> >> +SPINAND_ECCINFO(_ooblayout,
> >> +xt26xxxd_ecc_get_status)),
> >> + SPINAND_INFO("XT26Q04D",
> >> +SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x53),
> >> +NAND_MEMORG(1, 4096, 256, 64, 2048, 40, 1, 1, 1),
> >> +NAND_ECCREQ(8, 512),
> >> +SPINAND_INFO_OP_VARIANTS(_cache_variants,
> >> + _cache_variants,
> >> + _cache_variants),
> >> +0,
> >> +SPINAND_ECCINFO(_ooblayout,
> >> +xt26xxxd_ecc_get_status)),
> >> +};
> >> +
> >> +static const struct spinand_manufacturer_ops xtx_spinand_manuf_ops = {
> >> +};
> >> +
> >> +const struct spinand_manufacturer xtx_spinand_manufacturer = {
> >> + .id = SPINAND_MFR_XTX,
> >> + .name = "XTX",
> >> + .chips = xtx_spinand_table,
> >> + .nchips = ARRAY_SIZE(xtx_spinand_table),
> >> + .ops = _spinand_manuf_ops,
> >> +};
> >> diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
> >> index e8d6feb970..bf7696a981 100644
> >> --- a/include/linux/mtd/spinand.h
> >> +++ b/include/linux/mtd/spinand.h
> >> @@ -251,6 +251,7 @@ extern const struct spinand_manufacturer
> >> micron_spinand_manufacturer;
> >> extern const struct spinand_manufacturer paragon_spinand_manufacturer;
> >> extern const struct spinand_manufacturer toshiba_spinand_manufacturer;
> >> extern const struct spinand_manufacturer winbond_spinand_manufacturer;
> >> +extern const struct spinand_manufacturer xtx_spinand_manufacturer;
> >>
> >> /**
> >>* struct spinand_op_variants - SPI NAND operation variants
> >> --
> >> 2.34.1
> >>
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] arm: dts: k3-binman: Make optee optional as requirement
Hi
On Mon, Feb 26, 2024 at 4:17 AM Neha Malcom Francis wrote:
>
> Hi Michael
>
> + Vignesh
>
> On 25/02/24 23:08, Michael Trimarchi wrote:
> > Boards can use the ti_spl_template but avoid to define a tee
> > node to be loaded. This is true form board with 512Mb or less
>
> s/form board/for boards? I am guessing that is what was meant. I am not really
> understanding the commit message... does <512MB memory always mean no using
> OPTEE? (AM62 SIP would be an exception) The commit message is putting out a
> misleading reason why we don't need OPTEE in some cases, I don't think memory
> is
> the primary reason.
>
I will adjust commit message. In general when you have module with 256
Mb of memory you
try to arrange the available memory to put the essential components.
Anyway having still not
submitted board I found out that is convenient to use the template but
in the same time remove
from my configuration what is not mandatory and let binman to warning
and not to fail
Michael
> > memory. We can limit this in configuation removing the tee
>
> s/configuation/configuration
>
> > node
> >
> > configurations {
> > default = "conf-0";
> >
> > conf-0 {
> > description = "k3-am62_ccm_m3";
> > firmware = "atf";
> > loadables = "dm", "spl";
> > fdt = "fdt-0";
> > };
> > };
> >
> > Signed-off-by: Michael Trimarchi
> > ---
> > arch/arm/dts/k3-binman.dtsi | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
> > index 758c8bf6ea..5ef5af315a 100644
> > --- a/arch/arm/dts/k3-binman.dtsi
> > +++ b/arch/arm/dts/k3-binman.dtsi
> > @@ -293,6 +293,7 @@
> > keyfile = "custMpk.pem";
> > };
> > tee: tee-os {
> > + optional;
> > };
> > };
> >
> > @@ -360,6 +361,7 @@
> > entry = <0x9e80>;
> > tee-os {
> > filename = "tee-raw.bin";
> > + optional;
> > };
> > };
> >
>
> The patch excluding the commit message LGTM.
>
> --
> Thanking You
> Neha Malcom Francis
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v3] mtd: rawnand: Meson NAND controller support
} > + > + meson_chip->nsels = nsels; > + nand = _chip->nand; > + > + nand->flash_node = node; > + nand_set_controller_data(nand, nfc); > + /* Set the driver entry points for MTD */ > + nand->cmdfunc = meson_nfc_nand_cmd_function; > + nand->cmd_ctrl = meson_nfc_cmd_ctrl; > + nand->select_chip = meson_nfc_nand_select_chip; > + nand->read_byte = meson_nfc_nand_read_byte; > + nand->write_byte = meson_nfc_nand_write_byte; > + nand->dev_ready = meson_nfc_dev_ready; > + > + /* Buffer read/write routines */ > + nand->read_buf = meson_nfc_read_buf; > + nand->write_buf = meson_nfc_write_buf; > + nand->options |= NAND_NO_SUBPAGE_WRITE; > + > + nand->ecc.mode = NAND_ECC_HW; > + nand->ecc.hwctl = NULL; > + nand->ecc.read_page = meson_nfc_read_page_hwecc; > + nand->ecc.write_page = meso
Re: [PATCH] lib: sparse: Fix error checking for write_sparse_chunk_raw
On Thu, Feb 1, 2024 at 7:19 PM Sean Anderson wrote:
>
> The return value of write_sparse_chunk_raw is unsigned, so the existing
> check has no effect. Use IS_ERR_VALUE to detect error instead, which is
> what write_sparse_chunk_raw does itself.
>
> Fixes: 62649165cb0 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
> Reported-by: Dan Carpenter
> Link:
> https://lore.kernel.org/u-boot/1b323ec3-59b0-490b-a2f0-fd961dafcf49@moroto.mountain/
> Signed-off-by: Sean Anderson
> ---
>
> lib/image-sparse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/image-sparse.c b/lib/image-sparse.c
> index f8289064692..09225692e9b 100644
> --- a/lib/image-sparse.c
> +++ b/lib/image-sparse.c
> @@ -211,7 +211,7 @@ int write_sparse_image(struct sparse_storage *info,
>
> blks = write_sparse_chunk_raw(info, blk, blkcnt,
> data, response);
> - if (blks < 0)
> + if (IS_ERR_VALUE(blks))
> return -1;
>
> blk += blks;
> --
> 2.35.1.1320.gc452695387.dirty
>
Reviewed-by: Michael Trimarchi
Michael
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 07/14] mtdparts: use negative error codes
gt; {
> @@ -1493,7 +1493,7 @@ static int spread_partitions(void)
> dev = list_entry(dentry, struct mtd_device, link);
>
> if (get_mtd_info(dev->id->type, dev->id->num, ))
> - return 1;
> + return -EINVAL;
>
> part_num = 0;
> cur_offs = 0;
> @@ -1519,7 +1519,7 @@ static int spread_partitions(void)
>
> if (generate_mtdparts_save(last_parts, MTDPARTS_MAXLEN) != 0) {
> printf("generated mtdparts too long, resetting to null\n");
> - return 1;
> + return -EINVAL;
> }
> return 0;
> }
> @@ -1547,7 +1547,7 @@ static const char *env_get_mtdparts(char *buf)
> * for each entry. Add created devices to the global devices list.
> *
> * @param mtdparts string specifing mtd partitions
> - * Return: 0 on success, 1 otherwise
> + * Return: 0 on success, -errno otherwise
> */
> static int parse_mtdparts(const char *const mtdparts)
> {
> @@ -1605,7 +1605,7 @@ static int parse_mtdparts(const char *const mtdparts)
> * to the global mtdids list.
> *
> * @param ids mapping string
> - * Return: 0 on success, 1 otherwise
> + * Return: 0 on success, -errno otherwise
> */
> static int parse_mtdids(const char *const ids)
> {
> @@ -1646,7 +1646,7 @@ static int parse_mtdids(const char *const ids)
>
> /* check if requested device exists */
> if (mtd_device_validate(type, num, ) != 0)
> - return 1;
> + return -EINVAL;
>
> /* locate */
> mtd_id = p;
> @@ -1704,7 +1704,7 @@ static int parse_mtdids(const char *const ids)
> list_del(entry);
> free(id_tmp);
> }
> - return 1;
> + return -EINVAL;
> }
>
> return 0;
> @@ -1715,7 +1715,7 @@ static int parse_mtdids(const char *const ids)
> * Parse and initialize global mtdids mapping and create global
> * device/partition list.
> *
> - * Return: 0 on success, 1 otherwise
> + * Return: 0 on success, -errno otherwise
> */
> int mtdparts_init(void)
> {
> @@ -1768,12 +1768,12 @@ int mtdparts_init(void)
> env_set("mtdids", (char *)ids);
> } else {
> printf("mtdids not defined, no default present\n");
> - return 1;
> + return -ENXIO;
> }
> }
> if (strlen(ids) > MTDIDS_MAXLEN - 1) {
> printf("mtdids too long (> %d)\n", MTDIDS_MAXLEN);
> - return 1;
> + return -EINVAL;
> }
>
> /* use defaults when mtdparts variable is not defined
> @@ -1789,7 +1789,7 @@ int mtdparts_init(void)
>
> if (parts && (strlen(parts) > MTDPARTS_MAXLEN - 1)) {
> printf("mtdparts too long (> %d)\n", MTDPARTS_MAXLEN);
> - return 1;
> + return -EINVAL;
> }
>
> /* check if we have already parsed those mtdids */
> @@ -1800,7 +1800,7 @@ int mtdparts_init(void)
>
> if (parse_mtdids(ids) != 0) {
> mtd_devices_init();
> - return 1;
> + return -EINVAL;
> }
>
> /* ok it's good, save new ids */
> @@ -1810,11 +1810,11 @@ int mtdparts_init(void)
> /* parse partitions if either mtdparts or mtdids were updated */
> if (parts && ((last_parts[0] == '\0') || ((strcmp(last_parts, parts)
> != 0)) || ids_changed)) {
> if (parse_mtdparts(parts) != 0)
> - return 1;
> + return -EINVAL;
>
> if (list_empty()) {
> printf("mtdparts_init: no valid partitions\n");
> - return 1;
> + return -ENXIO;
> }
>
> /* ok it's good, save new parts */
> @@ -2022,7 +2022,7 @@ static int do_mtdparts(struct cmd_tbl *cmdtp, int flag,
> int argc,
> debug("add tmpbuf: %s\n", tmpbuf);
>
> if ((device_parse(tmpbuf, NULL, ) != 0) || (!dev))
> - return 1;
> + return -EINVAL;
>
> debug("+ %s\t%d\t%s\n", MTD_DEV_TYPE(dev->id->type),
> dev->id->num, dev->id->mtd_id);
> --
> 2.30.1
>
Reviewed-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 0/2] mtd: nand: omap_gpmc: Fix NAND for AM335x
Hi Il gio 11 gen 2024, 14:06 Roger Quadros ha scritto: > Hi, > > On 11/12/2023 13:45, Roger Quadros wrote: > > Hi, > > > > These patches fix NAND and ELM for AM335x and related legacy platforms > > that use HW BCH and ELM modules. > > > > All CI tests pass: https://github.com/u-boot/u-boot/pull/453 > > > > Changelog: > > > > v2: > > - added __maybe_unused to omap_calculate_ecc_bch. fixes CI tests > > - Added Tested-by Tags > > - Explained about omap_elm single sector support in commit log > > > > cheers, > > -roger > > > > Roger Quadros (2): > > mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x > > mtd: rawnand: omap_elm: Fix elm_init definition > > > > drivers/mtd/nand/raw/omap_elm.c | 4 +- > > drivers/mtd/nand/raw/omap_elm.h | 6 -- > > drivers/mtd/nand/raw/omap_gpmc.c | 95 ++-- > > 3 files changed, 31 insertions(+), 74 deletions(-) > > > > > > base-commit: 2f0282922b2c458eea7f85c500a948a587437b63 > > If no objections can this be Acked and picked up please? > Without these NAND is broken on some TI platforms. > We will queue them and send over the weekend Michael > > > > Thanks! > > -- > cheers, > -roger >
Re: [PATCH v2] mtd: rawnand: Meson NAND controller support
e;
> + nand->write_byte = meson_nfc_nand_write_byte;
> + nand->dev_ready = meson_nfc_dev_ready;
> +
> + /* Buffer read/write routines */
> + nand->read_buf = meson_nfc_read_buf;
> + nand->write_buf = meson_nfc_write_buf;
> + nand->options |= NAND_NO_SUBPAGE_WRITE;
> +
> + nand->ecc.mode = NAND_ECC_HW;
> + nand->ecc.hwctl = NULL;
> + nand->ecc.read_page = meson_nfc_read_page_hwecc;
> + nand->ecc.write_page = meson_nfc_write_page_hwecc;
> + nand->ecc.read_page_raw = meson_nfc_read_page_raw;
> + nand->ecc.write_page_raw = meson_nfc_write_page_raw;
> +
> + nand->ecc.read_oob = meson_nfc_read_oob;
> + nand->ecc.write_oob = meson_nfc_write_oob;
> + nand->ecc.read_oob_raw = meson_nfc_read_oob_raw;
> + nand->ecc.write_oob_raw = meson_nfc_write_oob_raw;
> +
> + nand->ecc.algo = NAND_ECC_BCH;
> +
> + mtd = nand_to_mtd(nand);
> +
> + ret = nand_scan_ident(mtd, 1, NULL);
> + if (ret) {
> + dev_err(dev, "'nand_scan_ident()' failed: %d\n", ret);
> + goto err_chip_free;
> + }
> +
> + ret = meson_nfc_init_ecc(nand, node);
> + if (ret) {
> + dev_err(dev, "failed to init ECC settings: %d\n", ret);
> + goto err_chip_free;
> + }
> +
> + ret = meson_chip_buffer_init(nand);
> + if (ret) {
> + dev_err(dev, "failed to init DMA buffers: %d\n", ret);
> + goto err_chip_free;
> + }
> +
> + /* 'nand_scan_tail()' needs ECC parameters to be already
> +* set and correct.
> +*/
Can you split in
/*
*
?
> + ret = nand_scan_tail(mtd);
> + if (ret) {
> + dev_err(dev, "'nand_scan_tail()' failed: %d\n", ret);
> + goto err_chip_buf_free;
> + }
> +
> + ret = nand_register(0, mtd);
> + if (ret) {
> + dev_err(dev, "'nand_register()' failed: %d\n", ret);
> + goto err_chip_buf_free;
> + }
> +
> + list_add_tail(_chip->node, >chips);
> +
> + return 0;
> +
> +err_chip_buf_free:
> + dma_free_coherent(meson_chip->info_buf);
> + dma_free_coherent(meson_chip->data_buf);
> +
> +err_chip_free:
> + free(meson_chip);
> +
> + return ret;
> +}
> +
> +static int meson_nfc_nand_chips_init(struct udevice *dev,
> +struct meson_nfc *nfc)
> +{
> + ofnode parent = dev_ofnode(dev);
> + ofnode node;
> +
> + ofnode_for_each_subnode(node, parent) {
> + int ret = meson_nfc_nand_chip_init(dev, nfc, node);
> +
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void meson_nfc_clk_init(struct meson_nfc *nfc)
> +{
> + u32 bus_cycle = NFC_DEFAULT_BUS_CYCLE;
> + u32 bus_timing = NFC_DEFAULT_BUS_TIMING;
> + u32 bus_cfg_val;
> +
> + writel(CLK_ALWAYS_ON_NAND | CLK_SELECT_NAND | CLK_ENABLE_VALUE,
> nfc->reg_clk);
> + writel(0, nfc->reg_base + NFC_REG_CFG);
> +
> + bus_cfg_val = (((bus_cycle - 1) & 31) | ((bus_timing & 31) << 5));
> + writel(bus_cfg_val, nfc->reg_base + NFC_REG_CFG);
> + writel(BIT(31), nfc->reg_base + NFC_REG_CMD);
> +}
> +
> +static int meson_probe(struct udevice *dev)
> +{
> + struct meson_nfc *nfc = dev_get_priv(dev);
> + void *addr;
> + int ret;
> +
> + addr = dev_read_addr_ptr(dev);
> + if (!addr) {
> + dev_err(dev, "base register address not found\n");
> + return -EINVAL;
> + }
> +
> + nfc->reg_base = addr;
> +
> + addr = dev_read_addr_index_ptr(dev, 1);
> + if (!addr) {
> + dev_err(dev, "clk register address not found\n");
> + return -EINVAL;
> + }
> +
> + nfc->reg_clk = addr;
> + nfc->dev = dev;
> +
> + meson_nfc_clk_init(nfc);
> +
> + ret = meson_nfc_nand_chips_init(dev, nfc);
> + if (ret) {
> + dev_err(nfc->dev, "failed to init chips\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct udevice_id meson_nand_dt_ids[] = {
> + {.compatible = "amlogic,meson-axg-nfc",},
> + { /* sentinel */ }
> +};
> +
> +U_BOOT_DRIVER(meson_nand) = {
> + .name = "meson_nand",
> + .id = UCLASS_MTD,
> + .of_match = meson_nand_dt_ids,
> + .probe = meson_probe,
> + .priv_auto = sizeof(struct meson_nfc),
> +};
> +
> +void board_nand_init(void)
> +{
> + struct udevice *dev;
> + int ret;
> +
> + ret = uclass_get_device_by_driver(UCLASS_MTD,
> + DM_DRIVER_GET(meson_nand), );
> +
> + if (ret && ret != -ENODEV)
> + pr_err("Failed to initialize: %d\n", ret);
> +}
> --
> 2.35.0
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2] mtd: rawnand: Meson NAND controller support
BB
> > + * 0x10: AA AA CC CC CC CC CC CC CC CC CC CC CC CC CC CC
> > + * 0x20: AA AA DD DD DD DD DD DD DD DD DD DD DD DD DD DD
> > + * 0x30: AA AA EE EE EE EE EE EE EE EE EE EE EE EE EE EE
> > + *
> > + * AA - user bytes.
> > + * BB, CC, DD, EE - ECC code bytes for each step.
> > + */
> > +static struct nand_ecclayout nand_oob;
> > +
> > +static void meson_nfc_init_nand_oob(struct nand_chip *nand)
> > +{
> > + int section_size = 2 + nand->ecc.bytes;
> > + int i;
> > + int k;
> > +
> > + nand_oob.eccbytes = nand->ecc.steps * nand->ecc.bytes;
> > + k = 0;
> > +
> > + for (i = 0; i < nand->ecc.steps; i++) {
> > + int j;
> > +
> > + for (j = 0; j < nand->ecc.bytes; j++)
> > + nand_oob.eccpos[k++] = (i * section_size) + 2 + j;
> > +
> > + nand_oob.oobfree[i].offset = (i * section_size);
> > + nand_oob.oobfree[i].length = 2;
> > + }
> > +
> > + nand_oob.oobavail = 2 * nand->ecc.steps;
> > + nand->ecc.layout = _oob;
> > +}
> > +
> > +static int meson_nfc_init_ecc(struct nand_chip *nand, ofnode node)
> > +{
> > + const struct mtd_info *mtd = nand_to_mtd(nand);
> > + int ret;
> > + int i;
> > +
> > + ret = nand_check_ecc_caps(nand, _axg_ecc_caps, mtd->oobsize -
> > 2);
> > + if (ret)
> > + return ret;
> > +
> > + for (i = 0; i < ARRAY_SIZE(meson_ecc); i++) {
> > + if (meson_ecc[i].strength == nand->ecc.strength &&
> >
Re: inconsistent wget behavior
Hi Fabio
On Sun, Jan 7, 2024 at 5:19 PM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> Il dom 7 gen 2024, 17:08 Fabio Estevam ha scritto:
>>
>> Hi Michael,
>>
>> On Sat, Jan 6, 2024 at 5:49 AM Michael Nazzareno Trimarchi
>> wrote:
>> >
>> > Hi
>> >
>> > Is this code correct?
>> >
>> > if (tcp_seq_num >= initial_data_seq_num &&
>> > store_block(pkt, tcp_seq_num - initial_data_seq_num,
>> > len) != 0) {
>> > wget_fail("wget: store error\n",
>> > tcp_seq_num, tcp_ack_num, action);
>> > return;
>> > }
>> >
>> > Can not be seq_num wrap around? Another point seems that is not
>> > guarantee packet reassembly
>>
>> If you submit a patch, I will be glad to test it.
>>
>> Cheers
>
>
> I have already wrote something but I can not test. Will send tonight. My
> feeling is that sometime the initial sequence number of TCP ip is next to
> wrap around but not sure.
>
I have sent but not sure about it, just compile for now ;)
> Michael
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: inconsistent wget behavior
Hi
Il dom 7 gen 2024, 17:08 Fabio Estevam ha scritto:
> Hi Michael,
>
> On Sat, Jan 6, 2024 at 5:49 AM Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi
> >
> > Is this code correct?
> >
> > if (tcp_seq_num >= initial_data_seq_num &&
> > store_block(pkt, tcp_seq_num - initial_data_seq_num,
> > len) != 0) {
> > wget_fail("wget: store error\n",
> > tcp_seq_num, tcp_ack_num, action);
> > return;
> > }
> >
> > Can not be seq_num wrap around? Another point seems that is not
> > guarantee packet reassembly
>
> If you submit a patch, I will be glad to test it.
>
> Cheers
>
I have already wrote something but I can not test. Will send tonight. My
feeling is that sometime the initial sequence number of TCP ip is next to
wrap around but not sure.
Michael
>
Re: inconsistent wget behavior
Hi
On Sat, Jan 6, 2024 at 9:49 AM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> Is this code correct?
>
> if (tcp_seq_num >= initial_data_seq_num &&
> store_block(pkt, tcp_seq_num - initial_data_seq_num,
> len) != 0) {
> wget_fail("wget: store error\n",
> tcp_seq_num, tcp_ack_num, action);
> return;
> }
>
> Can not be seq_num wrap around? Another point seems that is not
> guarantee packet reassembly
>
And what happen if you are going to generate out of sequence packet
and with large seq_number on purpose?
I think that lwip has much more sense
Michael
> Michael
>
> On Fri, Jan 5, 2024 at 8:53 PM Fabio Estevam wrote:
> >
> > On Fri, Jan 5, 2024 at 4:49 PM Michael Nazzareno Trimarchi
> > wrote:
> >
> > > I was thinking that was lwip integration
> >
> > That's a different issue.
> >
> > If you want to test lwip integration, you can try it from:
> > https://github.com/muvarov/u-boot/tree/master_lwip_test_v10
>
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> ______
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: inconsistent wget behavior
Hi
Is this code correct?
if (tcp_seq_num >= initial_data_seq_num &&
store_block(pkt, tcp_seq_num - initial_data_seq_num,
len) != 0) {
wget_fail("wget: store error\n",
tcp_seq_num, tcp_ack_num, action);
return;
}
Can not be seq_num wrap around? Another point seems that is not
guarantee packet reassembly
Michael
On Fri, Jan 5, 2024 at 8:53 PM Fabio Estevam wrote:
>
> On Fri, Jan 5, 2024 at 4:49 PM Michael Nazzareno Trimarchi
> wrote:
>
> > I was thinking that was lwip integration
>
> That's a different issue.
>
> If you want to test lwip integration, you can try it from:
> https://github.com/muvarov/u-boot/tree/master_lwip_test_v10
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: inconsistent wget behavior
Hi Fabio On Fri, Jan 5, 2024 at 8:32 PM Fabio Estevam wrote: > > Hi Michael, > > On Fri, Jan 5, 2024 at 4:12 PM Michael Nazzareno Trimarchi > wrote: > > > Can you reproduce with dcache off? > > I haven't tried it. > > > Where are the patches to test? > > The wget issue can be reproduced with U-Boot master. > > No need for extra patches. Please see the first message of this thread > where Tim explains how to reproduce it. I was thinking that was lwip integration Michael -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: inconsistent wget behavior
Hi On Fri, Jan 5, 2024 at 7:57 PM Paul Liu wrote: > > Hi Fabio, > > I tried to investigate this by U-boot sandbox. But it seems to me that I > cannot reproduce this issue. > I put a file on localhost apache server and tried to download it from > localhost. > I might need a more persistent way to reproduce this bug. > Can you reproduce with dcache off? Where are the patches to test? Michael
Re: [PATCH] cmd: sf: Fix sf probe crash
Hi
On Thu, Jan 4, 2024 at 1:40 PM Weizhao Ouyang wrote:
>
> On Thu, Jan 4, 2024 at 8:29 PM Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi
> >
> > On Thu, Jan 4, 2024 at 1:16 PM Weizhao Ouyang wrote:
> > >
> > > On Thu, Jan 4, 2024 at 8:00 PM Michal Simek wrote:
> > > >
> > > >
> > > >
> > > > On 1/4/24 12:46, Weizhao Ouyang wrote:
> > > > > Handle the return value of spi_flash_probe_bus_cs() to avoid sf probe
> > > > > crashes.
> > > > >
> > > > > Signed-off-by: Weizhao Ouyang
> > > > > ---
> > > > > cmd/sf.c | 5 +++--
> > > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/cmd/sf.c b/cmd/sf.c
> > > > > index 730996c02b..e3866899f6 100644
> > > > > --- a/cmd/sf.c
> > > > > +++ b/cmd/sf.c
> > > > > @@ -135,8 +135,9 @@ static int do_spi_flash_probe(int argc, char
> > > > > *const argv[])
> > > > > }
> > > > > flash = NULL;
> > > > > if (use_dt) {
> > > > > - spi_flash_probe_bus_cs(bus, cs, );
> > > > > - flash = dev_get_uclass_priv(new);
> > > > > + ret = spi_flash_probe_bus_cs(bus, cs, );
> > > >
> > > > if (ret)
> > > > return ret;
> > > >
> > > > don't you want to rather propagate that error?
> > > >
> > >
> > > Well, since the spi_flash is empty, the following code will
> > > print the error message and return.
> > >
> >
> > flash = NULL;
> >
> > if (!flash) {
> > printf("Failed to initialize SPI flash at %u:%u (error
> > %d)\n",
> > bus, cs, ret);
> > return 1;
> > }
> >
> > This code does not change error handling that is already present here.
>
> Hi Michael,
>
> Sorry I didn't get your point. This patch is designed to avoid
> spi_flash_probe_bus_cs() crash by null pointer, and let the
> current existing error handling to prompt it. So I'm not
> trying to change the current error handling.
>
I have said exactly the same so I agree with you.
Michael
> BR,
> Weizhao
>
> > Michael
> >
> > > BR,
> > > Weizhao
> >
> >
> >
> > --
> > Michael Nazzareno Trimarchi
> > Co-Founder & Chief Executive Officer
> > M. +39 347 913 2170
> > mich...@amarulasolutions.com
> > __
> >
> > Amarula Solutions BV
> > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> > T. +31 (0)85 111 9172
> > i...@amarulasolutions.com
> > www.amarulasolutions.com
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] cmd: sf: Fix sf probe crash
Hi
On Thu, Jan 4, 2024 at 1:16 PM Weizhao Ouyang wrote:
>
> On Thu, Jan 4, 2024 at 8:00 PM Michal Simek wrote:
> >
> >
> >
> > On 1/4/24 12:46, Weizhao Ouyang wrote:
> > > Handle the return value of spi_flash_probe_bus_cs() to avoid sf probe
> > > crashes.
> > >
> > > Signed-off-by: Weizhao Ouyang
> > > ---
> > > cmd/sf.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/cmd/sf.c b/cmd/sf.c
> > > index 730996c02b..e3866899f6 100644
> > > --- a/cmd/sf.c
> > > +++ b/cmd/sf.c
> > > @@ -135,8 +135,9 @@ static int do_spi_flash_probe(int argc, char *const
> > > argv[])
> > > }
> > > flash = NULL;
> > > if (use_dt) {
> > > - spi_flash_probe_bus_cs(bus, cs, );
> > > - flash = dev_get_uclass_priv(new);
> > > + ret = spi_flash_probe_bus_cs(bus, cs, );
> >
> > if (ret)
> > return ret;
> >
> > don't you want to rather propagate that error?
> >
>
> Well, since the spi_flash is empty, the following code will
> print the error message and return.
>
flash = NULL;
if (!flash) {
printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
bus, cs, ret);
return 1;
}
This code does not change error handling that is already present here.
Michael
> BR,
> Weizhao
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] cmd: sf: Fix sf probe crash
Hi
On Thu, Jan 4, 2024 at 12:46 PM Weizhao Ouyang wrote:
>
> Handle the return value of spi_flash_probe_bus_cs() to avoid sf probe
> crashes.
>
> Signed-off-by: Weizhao Ouyang
> ---
> cmd/sf.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/sf.c b/cmd/sf.c
> index 730996c02b..e3866899f6 100644
> --- a/cmd/sf.c
> +++ b/cmd/sf.c
> @@ -135,8 +135,9 @@ static int do_spi_flash_probe(int argc, char *const
> argv[])
> }
> flash = NULL;
> if (use_dt) {
> - spi_flash_probe_bus_cs(bus, cs, );
> - flash = dev_get_uclass_priv(new);
> + ret = spi_flash_probe_bus_cs(bus, cs, );
> + if (!ret)
> + flash = dev_get_uclass_priv(new);
> } else {
> flash = spi_flash_probe(bus, cs, speed, mode);
> }
> --
> 2.39.2
>
Reviewed-by: Michael Trimarchi
Suggest to add documentation of spi_flash_probe_bus_cs in a separated patch
Michael
Re: [PATCH v1 07/12] mtdparts: use negative error codes
Hi
On Thu, Dec 28, 2023 at 4:39 PM Alexey Romanov
wrote:
>
> It is bad practice to use such error codes. Error codes
> must be negative.
>
> Also, fastboot code expects that if successful, mtdparts
> functions will return a value greater than 0. You can see
> fastboot_nand_get_part_info() functions calls inside
> getvar_get_part_info().
>
> And use 'return CMD_RET_FAILURE' define instead of 'return 1'.
>
Can you split the CMD_RET_FAILURE in a separate patch?
> Signed-off-by: Alexey Romanov
> ---
> cmd/mtdparts.c | 154 -
> 1 file changed, 77 insertions(+), 77 deletions(-)
>
> diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
> index 0984158f41..08e5b794db 100644
> --- a/cmd/mtdparts.c
> +++ b/cmd/mtdparts.c
> @@ -299,7 +299,7 @@ static void current_save(void)
> * @param type mtd type
> * @param num mtd number
> * @param mtd a pointer to an mtd_info instance (output)
> - * Return: 0 if device is valid, 1 otherwise
> + * Return: 0 if device is valid, -errno otherwise
> */
> static int get_mtd_info(u8 type, u8 num, struct mtd_info **mtd)
> {
> @@ -309,7 +309,7 @@ static int get_mtd_info(u8 type, u8 num, struct mtd_info
> **mtd)
> *mtd = get_mtd_device_nm(mtd_dev);
> if (IS_ERR(*mtd)) {
> printf("Device %s not found!\n", mtd_dev);
> - return 1;
> + return -ENODEV;
> }
> put_mtd_device(*mtd);
>
> @@ -323,7 +323,7 @@ static int get_mtd_info(u8 type, u8 num, struct mtd_info
> **mtd)
> *
> * @param id of the parent device
> * @param part partition to validate
> - * Return: 0 if partition is valid, 1 otherwise
> + * Return: 0 if partition is valid, -errno otherwise
> */
> static int part_validate_eraseblock(struct mtdids *id, struct part_info
> *part)
> {
> @@ -333,7 +333,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part)
> u64 offset, size;
>
> if (get_mtd_info(id->type, id->num, ))
> - return 1;
> + return -EINVAL;
>
> part->sector_size = mtd->erasesize;
>
> @@ -347,14 +347,14 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part)
> printf("%s%d: partition (%s) start offset"
>"alignment incorrect\n",
>MTD_DEV_TYPE(id->type), id->num, part->name);
> - return 1;
> + return -EINVAL;
> }
>
> size = part->size;
> if (do_div(size, mtd->erasesize)) {
> printf("%s%d: partition (%s) size alignment
> incorrect\n",
>MTD_DEV_TYPE(id->type), id->num, part->name);
> - return 1;
> + return -EINVAL;
> }
> } else {
> /*
> @@ -374,7 +374,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part)
>
> printf("%s%d: partition (%s) start offset alignment
> incorrect\n",
>MTD_DEV_TYPE(id->type), id->num, part->name);
> - return 1;
> + return -EINVAL;
>
> start_ok:
>
> @@ -393,7 +393,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part)
>
> printf("%s%d: partition (%s) size alignment incorrect\n",
>MTD_DEV_TYPE(id->type), id->num, part->name);
> - return 1;
> + return -EINVAL;
>
> end_ok:
> return 0;
> @@ -410,7 +410,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part)
> *
> * @param id of the parent device
> * @param part partition to validate
> - * Return: 0 if partition is valid, 1 otherwise
> + * Return: 0 if partition is valid, -errno otherwise
> */
> static int part_validate(struct mtdids *id, struct part_info *part)
> {
> @@ -420,18 +420,18 @@ static int part_validate(struct mtdids *id, struct
> part_info *part)
> if (part->offset > id->size) {
> printf("%s: offset %08llx beyond flash size %08llx\n",
> id->mtd_id, part->offset, id->size);
> - return 1;
> + return -EINVAL;
> }
>
> if ((part->offset + part->size) <= part->offset) {
> printf("%s%d: partition (%s) size too big\n",
> MTD_DEV_TYPE(id->type), id->num, part->name);
> - return 1;
> + return -EINVAL;
> }
>
> if (part->offset + part->size > id->size) {
> printf("%s: partitioning exceeds flash size\n", id->mtd_id);
> - return 1;
> + return -EINVAL;
> }
>
> /*
> @@ -446,7 +446,7 @@ static int part_validate(struct mtdids *id, struct
> part_info *part)
> *
> * @param dev device
Re: [PATCH v1 04/12] nand: move nand_erase_opts() to core NAND folder
Hi Alexey
On Thu, Dec 28, 2023 at 4:39 PM Alexey Romanov
wrote:
>
> Currently nand_erase_opts() placed in the nand/raw/ folder,
> because it uses the RAW NAND specific API (struct nand_chip).
> This patch move it to core NAND folder and make function generic,
> for both RAW/SPI NAND's usage.
>
> Also, nand_erase_opts() used in fastboot/fb_nand.c, cmd/nand.c
> and env/nand.c code. This is also the reason why we should move
> it to core folder and make it more general.
>
> Signed-off-by: Alexey Romanov
> ---
> drivers/mtd/nand/raw/nand_util.c | 153
> drivers/mtd/nand/util.c | 166 +++
> 2 files changed, 166 insertions(+), 153 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_util.c
> b/drivers/mtd/nand/raw/nand_util.c
> index 9c18ce63b9..f7704d4697 100644
> --- a/drivers/mtd/nand/raw/nand_util.c
> +++ b/drivers/mtd/nand/raw/nand_util.c
> @@ -32,159 +32,6 @@
> #include
> #include
> #include
> -#include
> -
> -typedef struct erase_info erase_info_t;
> -
> -/* support only for native endian JFFS2 */
> -#define cpu_to_je16(x) (x)
> -#define cpu_to_je32(x) (x)
> -
> -/**
> - * nand_erase_opts: - erase NAND flash with support for various options
> - * (jffs2 formatting)
> - *
> - * @param mtd nand mtd instance to erase
> - * @param opts options, @see struct nand_erase_options
> - * Return: 0 in case of success
> - *
> - * This code is ported from flash_eraseall.c from Linux mtd utils by
> - * Arcom Control System Ltd.
> - */
> -int nand_erase_opts(struct mtd_info *mtd,
> - const nand_erase_options_t *opts)
> -{
> - struct jffs2_unknown_node cleanmarker;
> - erase_info_t erase;
> - unsigned long erase_length, erased_length; /* in blocks */
> - int result;
> - int percent_complete = -1;
> - const char *mtd_device = mtd->name;
> - struct mtd_oob_ops oob_opts;
> - struct nand_chip *chip = mtd_to_nand(mtd);
> -
> - if ((opts->offset & (mtd->erasesize - 1)) != 0) {
> - printf("Attempt to erase non block-aligned data\n");
> - return -1;
> - }
> -
> - memset(, 0, sizeof(erase));
> - memset(_opts, 0, sizeof(oob_opts));
> -
> - erase.mtd = mtd;
> - erase.len = mtd->erasesize;
> - erase.addr = opts->offset;
> - erase_length = lldiv(opts->length + mtd->erasesize - 1,
> -mtd->erasesize);
> -
> - cleanmarker.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK);
> - cleanmarker.nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER);
> - cleanmarker.totlen = cpu_to_je32(8);
> -
> - /* scrub option allows to erase badblock. To prevent internal
> -* check from erase() method, set block check method to dummy
> -* and disable bad block table while erasing.
> -*/
> - if (opts->scrub) {
> - erase.scrub = opts->scrub;
> - /*
> -* We don't need the bad block table anymore...
> -* after scrub, there are no bad blocks left!
> -*/
> - if (chip->bbt) {
> - kfree(chip->bbt);
> - }
> - chip->bbt = NULL;
> - chip->options &= ~NAND_BBT_SCANNED;
> - }
> -
> - for (erased_length = 0;
> -erased_length < erase_length;
> -erase.addr += mtd->erasesize) {
> -
> - schedule();
> -
> - if (opts->lim && (erase.addr >= (opts->offset + opts->lim))) {
> - puts("Size of erase exceeds limit\n");
> - return -EFBIG;
> - }
> - if (!opts->scrub) {
> - int ret = mtd_block_isbad(mtd, erase.addr);
> - if (ret > 0) {
> - if (!opts->quiet)
> - printf("\rSkipping %s at "
> - "0x%08llx "
> - " \n",
> - ret == 1 ? "bad block" : "bbt
> reserved",
> - erase.addr);
> -
> - if (!opts->spread)
> - erased_length++;
> -
> - continue;
> -
> - } else if (ret < 0) {
> - printf("\n%s: MTD get bad block failed: %d\n",
> - mtd_device,
> - ret);
> - return -1;
> - }
> - }
> -
> - erased_length++;
> -
> - result = mtd_erase(mtd, );
> - if (result != 0) {
> - printf("\n%s: MTD Erase
Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
lect_ecc_scheme(struct nand_chip *nand, > nand->ecc.hwctl = omap_enable_hwecc_bch; > nand->ecc.correct = omap_correct_data_bch_sw; > nand->ecc.calculate = omap_calculate_ecc_bch; > + nand->ecc.steps = eccsteps; > /* define ecc-layout */ > ecclayout->eccbytes = nand->ecc.bytes * eccsteps; > ecclayout->eccpos[0]= BADBLOCK_MARKER_LENGTH; > @@ -987,6 +948,7 @@ static int omap_select_ecc_scheme(struct nand_chip *nand, > nand->ecc.correct = omap_correct_data_bch; > nand->ecc.calculate = omap_calculate_ecc_bch; > nand->ecc.read_page = omap_read_page_bch; > + nand->ecc.steps = eccsteps; > /* define ecc-layout */ > ecclayout->eccbytes = nand->ecc.bytes * eccsteps; > for (i = 0; i < ecclayout->eccbytes; i++) > @@ -1020,6 +982,7 @@ static int omap_select_ecc_scheme(struct nand_chip *nand, > nand->ecc.correct = omap_correct_data_bch; > nand->ecc.calculate = omap_calculate_ecc_bch; > nand->ecc.read_page = omap_read_page_bch; > + nand->ecc.steps = eccsteps; > /* define ecc-layout */ > ecclayout->eccbytes = nand->ecc.bytes * eccsteps; > for (i = 0; i < ecclayout->eccbytes; i++) > > base-commit: 9e53e45292ee2f1d9d2ccc59914b161bef9b10d7 > -- > 2.34.1 > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
gt; > - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, 0, -1); > > - chip->read_buf(mtd, buf, mtd->writesize); > > + /* read data */ > > + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, data_pos, -1); > > + chip->read_buf(mtd, p, eccsize); > > > > - /* read all ecc bytes from oob area */ > > - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_pos, -1); > > - chip->read_buf(mtd, oob, ecctotal); > > + /* read respective ecc from oob area */ > > + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_pos, -1); > > + chip->read_buf(mtd, oob, eccbytes); > > + /* read syndrome */ > > + chip->ecc.calculate(mtd, p, _calc[i]); > > > > - /* Calculate ecc bytes */ > > - omap_calculate_ecc_bch_multi(mtd, buf, ecc_calc); > > + data_pos += eccsize; > > + oob_pos += eccbytes; > > + } > > > > for (i = 0; i < chip->ecc.total; i++) > > ecc_code[i] = chip->oob_poi[eccpos[i]]; > > @@ -945,6 +905,7 @@ static int omap_select_ecc_scheme(struct nand_chip > > *nand, > > nand->ecc.hwctl = omap_enable_hwecc_bch; > > nand->ecc.correct = omap_correct_data_bch_sw; > > nand->ecc.calculate = omap_calculate_ecc_bch; > > + nand->ecc.steps = eccsteps; > > /* define ecc-layout */ > > ecclayout->eccbytes = nand->ecc.bytes * eccsteps; > > ecclayout->eccpos[0]= BADBLOCK_MARKER_LENGTH; > > @@ -987,6 +948,7 @@ static int omap_select_ecc_scheme(struct nand_chip > > *nand, > > nand->ecc.correct = omap_correct_data_bch; > > nand->ecc.calculate = omap_calculate_ecc_bch; > > nand->ecc.read_page = omap_read_page_bch; > > + nand->ecc.steps = eccsteps; > > /* define ecc-layout */ > > ecclayout->eccbytes = nand->ecc.bytes * eccsteps; > > for (i = 0; i < ecclayout->eccbytes; i++) > > @@ -1020,6 +982,7 @@ static int omap_select_ecc_scheme(struct nand_chip > > *nand, > > nand->ecc.correct = omap_correct_data_bch; > > nand->ecc.calculate = omap_calculate_ecc_bch; > > nand->ecc.read_page = omap_read_page_bch; > > + nand->ecc.steps = eccsteps; > > /* define ecc-layout */ > > ecclayout->eccbytes = nand->ecc.bytes * eccsteps; > > for (i = 0; i < ecclayout->eccbytes; i++) > > > > base-commit: 9e53e45292ee2f1d9d2ccc59914b161bef9b10d7 > > -- > cheers, > -roger -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH v1] mtd: rawnand: Meson NAND controller support
CC CC CC CC CC CC CC CC CC CC CC CC CC
> + * 0x20: AA AA DD DD DD DD DD DD DD DD DD DD DD DD DD DD
> + * 0x30: AA AA EE EE EE EE EE EE EE EE EE EE EE EE EE EE
> + *
> + * AA - user bytes.
> + * BB, CC, DD, EE - ECC code bytes for each step.
> + */
> +static struct nand_ecclayout nand_oob;
> +
> +static void meson_nfc_init_nand_oob(struct nand_chip *nand)
> +{
> + int section_size = 2 + nand->ecc.bytes;
> + int i;
> + int k;
> +
> + nand_oob.eccbytes = nand->ecc.steps * nand->ecc.bytes;
> + k = 0;
> +
> + for (i = 0; i < nand->ecc.steps; i++) {
> + int j;
> +
> + for (j = 0; j < nand->ecc.bytes; j++)
> + nand_oob.eccpos[k++] = (i * section_size) + 2 + j;
> +
> + nand_oob.oobfree[i].offset = (i * section_size);
> + nand_oob.oobfree[i].length = 2;
> + }
> +
> + nand_oob.oobavail = 2 * nand->ecc.steps;
> + nand->ecc.layout = _oob;
> +}
> +
> +static int meson_nfc_init_ecc(struct nand_chip *nand, ofnode node)
> +{
> + const struct mtd_info *mtd = nand_to_mtd(nand);
> + int ret;
> + int i;
> +
> + ret = nand_check_ecc_caps(nand, _axg_ecc_caps, mtd->oobsize -
> 2);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < ARRAY_SIZE(meson_ecc); i++) {
> + if (meson_ecc[i].strength == nand->ecc.strength &&
> + meson_ecc[i].size == nand->ecc.size) {
> + struct meson_nfc_nand_chip *meson_chip =
> to_meson_nand(nand);
> +
> + nand->ecc.steps = mtd->writesize / nand->ecc.size;
> + meson_chip->bch_mode = meson_ecc[i].bch;
> +
> + meson_nfc_init_nand_oob(nand);
> +
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int meson_nfc_nand_chip_init(struct udevice *dev, struct meson_nfc
> *nfc,
> + ofnode node)
> +{
> + struct meson_nfc_nand_chip *meson_chip;
> + struct nand_chip *nand;
> + struct mtd_info *mtd;
> + u32 cs[MAX_CE_NUM];
> + u32 nsels;
> + int ret;
> + int i;
> +
> + if (!ofnode_get_property(node, "reg", )) {
> + dev_err(dev, "\"reg\" property is not found\n");
> + return -ENODEV;
> + }
> +
> + nsels /= sizeof(u32);
> + if (nsels >= MAX_CE_NUM) {
> + dev_err(dev, "invalid size of CS array, max is %d\n",
> + MAX_CE_NUM);
> + return -EINVAL;
> + }
> +
> + ret = ofnode_read_u32_array(node, "reg", cs, nsels);
> + if (ret < 0) {
> + dev_err(dev, "failed to read \"reg\" property\n");
> + return ret;
> + }
> +
> + for (i = 0; i < nsels; i++) {
> + if (test_and_set_bit(cs[i], >assigned_cs)) {
> + dev_err(dev, "CS %d already assigned\n", cs[i]);
> + return -EINVAL;
> + }
> + }
> +
> + meson_chip = malloc(sizeof(*meson_chip) + nsels *
> sizeof(meson_chip->sels[0]));
> + if (!meson_chip) {
> + dev_err(dev, "failed to allocate memory for chip\n");
> + return -ENOMEM;
> + }
> +
> + meson_chip->nsels = nsels;
> + nand = _chip->nand;
> +
> + nand->flash_node = node;
> + nand_set_controller_data(nand, nfc);
> + /* Set the driver entry points for MTD */
> + nand->cmdfunc = meson_nfc_nand_cmd_function;
> + nand->cmd_ctrl = meson_nfc_cmd_ctrl;
> + nand->select_chip = meson_nfc_nand_select_chip;
> + nand->read_byte = meson_nfc_nand_read_byte;
> + nand->write_byte = meson_nfc_nand_write_byte;
> + nand->dev_ready = meson_nfc_dev_ready;
> +
> + /* Buffer read/write routines */
> + nand->read_buf = meson_nfc_read_buf;
> + nand->write_buf = meson_nfc_write_buf;
> + nand->options |= NAND_NO_SUBPAGE_WRITE;
> +
> + nand->ecc.mode = NAND_ECC_HW;
> + nand->ecc.hwctl = NULL;
> + nand->ecc.read_page = meson_nfc_read_page_hwecc;
> + nand->ecc.write_page = meson_nfc_write_page_hwecc;
> + nand->ecc.read_page_raw = meson_nfc_read_page_raw;
> + nand->ecc.write_page_raw = meson_nfc_write_page_raw;
> +
> + nand->
Re: [PATCH v1] mtd: rawnand: Meson NAND controller support
Hi Arseniy Il lun 4 dic 2023, 20:31 Arseniy Krasnov ha scritto: > cc: Miquel Raynal > > On 30.11.2023 14:21, Arseniy Krasnov wrote: > > Basic support for Amlogic Meson NAND controller on AXG. > > > > Signed-off-by: Arseniy Krasnov > > --- > We are going to review your patches. It will be done this week Michael > drivers/mtd/nand/raw/Kconfig |9 + > > drivers/mtd/nand/raw/Makefile |1 + > > drivers/mtd/nand/raw/meson_nand.c | 1231 + > > 3 files changed, 1241 insertions(+) > > create mode 100644 drivers/mtd/nand/raw/meson_nand.c > > > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > > index d624589a89..7b7b0226ab 100644 > > --- a/drivers/mtd/nand/raw/Kconfig > > +++ b/drivers/mtd/nand/raw/Kconfig > > @@ -488,6 +488,15 @@ config NAND_ARASAN > > controller. This uses the hardware ECC for read and > > write operations. > > > > +config NAND_MESON > > + bool "Meson NAND support" > > + select SYS_NAND_SELF_INIT > > + depends on DM_MTD && ARCH_MESON > > + imply CMD_NAND > > + help > > + This enables Nand driver support for Meson raw NAND flash > > + controller. > > + > > config NAND_MXC > > bool "MXC NAND support" > > depends on CPU_ARM926EJS || CPU_ARM1136 || MX5 > > diff --git a/drivers/mtd/nand/raw/Makefile > b/drivers/mtd/nand/raw/Makefile > > index add2b4cf65..5b4efd52c9 100644 > > --- a/drivers/mtd/nand/raw/Makefile > > +++ b/drivers/mtd/nand/raw/Makefile > > @@ -61,6 +61,7 @@ obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o > > obj-$(CONFIG_NAND_LPC32XX_MLC) += lpc32xx_nand_mlc.o > > obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o > > obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o > > +obj-$(CONFIG_NAND_MESON) += meson_nand.o > > obj-$(CONFIG_NAND_MXC) += mxc_nand.o > > obj-$(CONFIG_NAND_MXS) += mxs_nand.o > > obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o > > diff --git a/drivers/mtd/nand/raw/meson_nand.c > b/drivers/mtd/nand/raw/meson_nand.c > > new file mode 100644 > > index 00..f1d49887ee > > --- /dev/null > > +++ b/drivers/mtd/nand/raw/meson_nand.c > > @@ -0,0 +1,1231 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > > +/* > > + * Amlogic Meson Nand Flash Controller Driver > > + * > > + * Copyright (c) 2023 SaluteDevices, Inc. > > + * Author: Arseniy Krasnov > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define NFC_CMD_IDLE (0xc << 14) > > +#define NFC_CMD_CLE (0x5 << 14) > > +#define NFC_CMD_ALE (0x6 << 14) > > +#define NFC_CMD_DWR (0x4 << 14) > > +#define NFC_CMD_DRD (0x8 << 14) > > +#define NFC_CMD_ADL ((0 << 16) | (3 << 20)) > > +#define NFC_CMD_ADH ((1 << 16) | (3 << 20)) > > +#define NFC_CMD_AIL ((2 << 16) | (3 << 20)) > > +#define NFC_CMD_AIH ((3 << 16) | (3 << 20)) > > +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) > > +#define NFC_CMD_M2N ((0 << 17) | (2 << 20)) > > +#define NFC_CMD_N2M ((1 << 17) | (2 << 20)) > > +#define NFC_CMD_RB BIT(20) > > +#define NFC_CMD_SCRAMBLER_ENABLE BIT(19) > > +#define NFC_CMD_SCRAMBLER_DISABLE0 > > +#define NFC_CMD_SHORTMODE_DISABLE0 > > +#define NFC_CMD_RB_INT BIT(14) > > +#define NFC_CMD_RB_INT_NO_PIN((0xb << 10) | BIT(18) | > BIT(16)) > > + > > +#define NFC_CMD_GET_SIZE(x) (((x) >> 22) & GENMASK(4, 0)) > > + > > +#define NFC_REG_CMD 0x00 > > +#define NFC_REG_CFG 0x04 > > +#define NFC_REG_DADR 0x08 > > +#define NFC_REG_IADR 0x0c > > +#define NFC_REG_BUF 0x10 > > +#define NFC_REG_INFO 0x14 > > +#define NFC_REG_DC 0x18 > > +#define NFC_REG_ADR 0x1c > > +#define NFC_REG_DL 0x20 > > +#define NFC_REG_DH 0x24 > > +#define NFC_REG_CADR 0x28 > > +#define NFC_REG_SADR 0x2c > > +#define NFC_REG_PINS 0x30 > > +#define NFC_REG_VER 0x38 > > + > > +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages)\ > > + ( \ > > + (cmd_dir) | \ > > + ((ran) << 19) | \ > > + ((bch) << 14) | \ > > + ((short_mode) << 13)| \ > > + (((page_size) & 0x7f) << 6) | \ > > + ((pages) & 0x3f)\ > > + ) > > + > > +#define GENCMDDADDRL(adl, addr) ((adl) | ((addr) &
Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
Hi dario
On Mon, Nov 27, 2023 at 3:00 PM Leto, Enrico wrote:
>
> Hi,
>
> Works on my draco thuban AM335x based boards booting from NAND with ECC BCH8
> code.
>
> Tested-by: Enrico Leto
>
> Thanks
>
>
> > -Original Message-
> > From: Michael Nazzareno Trimarchi
> > Sent: Saturday, November 25, 2023 2:07 PM
> > To: Roger Quadros
> > Cc: dario.binac...@amarulasolutions.com; Schocher, Heiko (EXT) (DENX
> > Software Engineering GmbH) ; Leto, Enrico (SI BP R ZG FW
> > CCP) ; tr...@konsulko.com; prane...@ti.com;
> > n...@ti.com; vigne...@ti.com; u-boot@lists.denx.de
> > Subject: Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
> >
> > Hi Roger
> >
> > On Sat, Nov 25, 2023 at 12:16 PM Roger Quadros
> > wrote:
> > >
> > > AM335x uses a special driver "am335x_spl_bch.c" as SPL NAND loader.
> > > This driver expects 1 sector at a time ECC and doesn't work well with
> > > multi-sector ECC that was implemented in commit 04fcd2587321 ("mtd:
> > > rawnand: omap_gpmc: Fix BCH6/16 HW based correction")
> > >
> > > Switch back to 1 sector at a time read/ECC.
> > >
> > > Fixes: 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
> > > correction")
> > > Signed-off-by: Roger Quadros
> > > ---
> > > drivers/mtd/nand/raw/omap_gpmc.c | 95
> > > ++--
> > > 1 file changed, 29 insertions(+), 66 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> > > b/drivers/mtd/nand/raw/omap_gpmc.c
> > > index 1a5ed0de31..2d2d2c2b6d 100644
> > > --- a/drivers/mtd/nand/raw/omap_gpmc.c
> > > +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> > > @@ -293,7 +293,7 @@ static void __maybe_unused
> > omap_enable_hwecc_bch(struct mtd_info *mtd,
> > > break;
> > > case OMAP_ECC_BCH8_CODE_HW:
> > > bch_type = 1;
> > > - nsectors = chip->ecc.steps;
> > > + nsectors = 1;
> > > if (mode == NAND_ECC_READ) {
> > > wr_mode = BCH_WRAPMODE_1;
> > > ecc_size0 = BCH8R_ECC_SIZE0; @@ -306,7 +306,7
> > > @@ static void __maybe_unused omap_enable_hwecc_bch(struct mtd_info
> > *mtd,
> > > break;
> > > case OMAP_ECC_BCH16_CODE_HW:
> > > bch_type = 0x2;
> > > - nsectors = chip->ecc.steps;
> > > + nsectors = 1;
> > > if (mode == NAND_ECC_READ) {
> > > wr_mode = 0x01;
> > > ecc_size0 = 52; /* ECC bits in nibbles per
> > > sector */ @@ -345,17 +345,16 @@ static void __maybe_unused
> > > omap_enable_hwecc_bch(struct mtd_info *mtd, }
> > >
> > > /**
> > > - * _omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
> > > + * omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
> > > * @mtd:MTD device structure
> > > * @dat:The pointer to data on which ecc is computed
> > > * @ecc_code: The ecc_code buffer
> > > - * @sector: The sector number (for a multi sector page)
> > > *
> > > * Support calculating of BCH4/8/16 ECC vectors for one sector
> > > * within a page. Sector number is in @sector.
> > > */
> > > -static int _omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
> > > - u8 *ecc_code, int sector)
> > > +static int omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
> > > + u8 *ecc_code)
> > > {
> > > struct nand_chip *chip = mtd_to_nand(mtd);
> > > struct omap_nand_info *info = nand_get_controller_data(chip);
> > > @@ -368,7 +367,7 @@ static int _omap_calculate_ecc_bch(struct mtd_info
> > *mtd, const u8 *dat,
> > > case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
> > > #endif
> > > case OMAP_ECC_BCH8_CODE_HW:
> > > - ptr = _cfg->bch_result_0_3[sector].bch_result_x[3];
> > > + ptr = _cfg->bch_result_0_3[0].bch_result_x[3];
> > > val = readl(ptr);
> > > ecc_code[i++] = (val >> 0) & 0xFF;
> > > ptr--;
> > > @@ -383,21 +382,21 @@ static int _omap_calculate_ecc_bch(struct
> > >
Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
Hi Roger
On Sat, Nov 25, 2023 at 12:16 PM Roger Quadros wrote:
>
> AM335x uses a special driver "am335x_spl_bch.c" as SPL
> NAND loader. This driver expects 1 sector at a time ECC
> and doesn't work well with multi-sector ECC that was implemented in
> commit 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
> correction")
>
> Switch back to 1 sector at a time read/ECC.
>
> Fixes: 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
> correction")
> Signed-off-by: Roger Quadros
> ---
> drivers/mtd/nand/raw/omap_gpmc.c | 95 ++--
> 1 file changed, 29 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> b/drivers/mtd/nand/raw/omap_gpmc.c
> index 1a5ed0de31..2d2d2c2b6d 100644
> --- a/drivers/mtd/nand/raw/omap_gpmc.c
> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> @@ -293,7 +293,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
> mtd_info *mtd,
> break;
> case OMAP_ECC_BCH8_CODE_HW:
> bch_type = 1;
> - nsectors = chip->ecc.steps;
> + nsectors = 1;
> if (mode == NAND_ECC_READ) {
> wr_mode = BCH_WRAPMODE_1;
> ecc_size0 = BCH8R_ECC_SIZE0;
> @@ -306,7 +306,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
> mtd_info *mtd,
> break;
> case OMAP_ECC_BCH16_CODE_HW:
> bch_type = 0x2;
> - nsectors = chip->ecc.steps;
> + nsectors = 1;
> if (mode == NAND_ECC_READ) {
> wr_mode = 0x01;
> ecc_size0 = 52; /* ECC bits in nibbles per sector */
> @@ -345,17 +345,16 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
> mtd_info *mtd,
> }
>
> /**
> - * _omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
> + * omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
> * @mtd:MTD device structure
> * @dat:The pointer to data on which ecc is computed
> * @ecc_code: The ecc_code buffer
> - * @sector: The sector number (for a multi sector page)
> *
> * Support calculating of BCH4/8/16 ECC vectors for one sector
> * within a page. Sector number is in @sector.
> */
> -static int _omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
> - u8 *ecc_code, int sector)
> +static int omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
> + u8 *ecc_code)
> {
> struct nand_chip *chip = mtd_to_nand(mtd);
> struct omap_nand_info *info = nand_get_controller_data(chip);
> @@ -368,7 +367,7 @@ static int _omap_calculate_ecc_bch(struct mtd_info *mtd,
> const u8 *dat,
> case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
> #endif
> case OMAP_ECC_BCH8_CODE_HW:
> - ptr = _cfg->bch_result_0_3[sector].bch_result_x[3];
> + ptr = _cfg->bch_result_0_3[0].bch_result_x[3];
> val = readl(ptr);
> ecc_code[i++] = (val >> 0) & 0xFF;
> ptr--;
> @@ -383,21 +382,21 @@ static int _omap_calculate_ecc_bch(struct mtd_info
> *mtd, const u8 *dat,
>
> break;
> case OMAP_ECC_BCH16_CODE_HW:
> - val =
> readl(_cfg->bch_result_4_6[sector].bch_result_x[2]);
> + val = readl(_cfg->bch_result_4_6[0].bch_result_x[2]);
> ecc_code[i++] = (val >> 8) & 0xFF;
> ecc_code[i++] = (val >> 0) & 0xFF;
> - val =
> readl(_cfg->bch_result_4_6[sector].bch_result_x[1]);
> + val = readl(_cfg->bch_result_4_6[0].bch_result_x[1]);
> ecc_code[i++] = (val >> 24) & 0xFF;
> ecc_code[i++] = (val >> 16) & 0xFF;
> ecc_code[i++] = (val >> 8) & 0xFF;
> ecc_code[i++] = (val >> 0) & 0xFF;
> - val =
> readl(_cfg->bch_result_4_6[sector].bch_result_x[0]);
> + val = readl(_cfg->bch_result_4_6[0].bch_result_x[0]);
> ecc_code[i++] = (val >> 24) & 0xFF;
> ecc_code[i++] = (val >> 16) & 0xFF;
> ecc_code[i++] = (val >> 8) & 0xFF;
> ecc_code[i++] = (val >> 0) & 0xFF;
> for (j = 3; j >= 0; j--) {
> - val =
> readl(_cfg->bch_result_0_3[sector].bch_result_x[j]
> + val =
> readl(_cfg->bch_result_0_3[0].bch_result_x[j]
> );
> ecc_code[i++] = (val >> 24) & 0xFF;
> ecc_code[i++] = (val >> 16) & 0xFF;
> @@ -431,22 +430,6 @@ static int _omap_calculate_ecc_bch(struct mtd_info *mtd,
> const u8 *dat,
> return 0;
> }
>
> -/**
> - * omap_calculate_ecc_bch - ECC generator for 1 sector
> - * @mtd:MTD device structure
> - * @dat: The pointer to data on which ecc is
Re: [PATCH] binman: doc: fix typo
Hi On Thu, Nov 23, 2023 at 2:10 PM Dario Binacchi wrote: > > s/use set/set/ > > Signed-off-by: Dario Binacchi > --- > > tools/binman/binman.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst > index 020988d955f0..230e055667f3 100644 > --- a/tools/binman/binman.rst > +++ b/tools/binman/binman.rst > @@ -2060,7 +2060,7 @@ don't have access to the blobs. > If the blobs are in a different directory, you can specify this with the `-I` > option. > > -For U-Boot, you can use set the BINMAN_INDIRS environment variable to > provide a > +For U-Boot, you can set the BINMAN_INDIRS environment variable to provide a > space-separated list of directories to search for binary blobs:: > > BINMAN_INDIRS="odroid-c4/fip/g12a \ > -- > 2.42.0 > Reviewed-By: Michael Trimarchi
Re: [PATCH] mtd: rawnand: omap_gpmc: fix BCH8 HW based correction
Hi
On Wed, Nov 15, 2023 at 11:37 AM Leto, Enrico wrote:
>
> Patch is working by me.
>
> > -Original Message-
> > From: Heiko Schocher
> > Sent: Wednesday, November 15, 2023 6:41 AM
> > To: U-Boot Mailing List ; Leto, Enrico (SI BP R ZG
> > FW
> > CCP)
> > Cc: Schocher, Heiko (EXT) (DENX Software Engineering GmbH) ;
> > Dario Binacchi ; Michael Trimarchi
> >
> > Subject: [PATCH] mtd: rawnand: omap_gpmc: fix BCH8 HW based correction
> >
> > commit 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
> > correction")
> >
> > broke AM335x based boards booting from NAND with ECC BCH8 code.
> >
> > Use omap_enable_hwecc() instead of omap_enable_hwecc_bch() in SPL
> > restores correct SPL nand_read_page functionality.
> >
> > Tested on draco thuban board.
> >
> > Signed-off-by: Heiko Schocher
> >
> > ---
> > fix NAND boot for BCH8 based TI AM335x boards
> >
> > Fix is based on series from Enrico:
> >
We need test the boards that Roger add here.
Michael
> > https://lists.d/
> > enx.de%2Fpipermail%2Fu-boot%2F2023-
> > November%2F536793.html=05%7C01%7Cenrico.leto%40siemens.com
> > %7Cbd939f15167c49cc97b708dbe59d6e9e%7C38ae3bcd95794fd4addab4
> > 2e1495d55a%7C1%7C0%7C638356236545245361%7CUnknown%7CTWFp
> > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> > CI6Mn0%3D%7C3000%7C%7C%7C=IUqjryYUtp%2Fdm9GgCALPTl8f%
> > 2BlcrO0ErXjkvoDwz7v4%3D=0
> >
> > and fixes NAND boot for the draco thuban board. But this patch apply also
> > without the patches from above patchseries, see azure build:
> >
> > https://dev.a/
> > zure.com%2Fhs0298%2Fhs%2F_build%2Fresults%3FbuildId%3D111%26vie
> > w%3Dresults=05%7C01%7Cenrico.leto%40siemens.com%7Cbd939f15
> > 167c49cc97b708dbe59d6e9e%7C38ae3bcd95794fd4addab42e1495d55a%
> > 7C1%7C0%7C638356236545245361%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C3000%7C%7C%7C=S2itRHsR49lD9TlBexYw9J5waXiuFcS%2BhUp
> > %2B7Yi60MA%3D=0
> >
> > which is clean.
> >
> > Above commit seems to change only U-Boot code and did not adapt
> > am335x_spl_bch.c, which breaks nand_read_page in SPL code for AM335x
> > based boards. So use in SPL "old" hw setup and reading page from NAND in
> > SPL works again.
> >
> >
> > drivers/mtd/nand/raw/omap_gpmc.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> > b/drivers/mtd/nand/raw/omap_gpmc.c
> > index 1a5ed0de31..c9b66dadbd 100644
> > --- a/drivers/mtd/nand/raw/omap_gpmc.c
> > +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> > @@ -983,7 +983,11 @@ static int omap_select_ecc_scheme(struct
> > nand_chip *nand,
> > nand->ecc.strength = 8;
> > nand->ecc.size = SECTOR_BYTES;
> > nand->ecc.bytes = 14;
> > +#if defined(CONFIG_SPL_BUILD)
> > + nand->ecc.hwctl = omap_enable_hwecc;
> > +#else
> > nand->ecc.hwctl = omap_enable_hwecc_bch;
> > +#endif
> > nand->ecc.correct = omap_correct_data_bch;
> > nand->ecc.calculate = omap_calculate_ecc_bch;
> > nand->ecc.read_page = omap_read_page_bch;
> > --
> > 2.37.3
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] mtd: rawnand: omap_gpmc: remove unneeded variable
On Tue, Nov 14, 2023 at 8:48 AM Heiko Schocher wrote:
>
> remove unneeded variable ecc_flag in omap_correct_data_bch
>
> Signed-off-by: Heiko Schocher
> ---
> azure build is fine with this patch:
>
> https://dev.azure.com/hs0298/hs/_build/results?buildId=110=results
>
> drivers/mtd/nand/raw/omap_gpmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> b/drivers/mtd/nand/raw/omap_gpmc.c
> index 1a5ed0de31..1fe8b1671e 100644
> --- a/drivers/mtd/nand/raw/omap_gpmc.c
> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> @@ -637,13 +637,13 @@ static int omap_correct_data_bch(struct mtd_info *mtd,
> uint8_t *dat,
> uint32_t error_count = 0, error_max;
> uint32_t error_loc[ELM_MAX_ERROR_COUNT];
> enum bch_level bch_type;
> - uint32_t i, ecc_flag = 0;
> + uint32_t i;
> uint8_t count;
> uint32_t byte_pos, bit_pos;
> int err = 0;
>
> /* check calculated ecc */
> - for (i = 0; i < ecc->bytes && !ecc_flag; i++) {
> + for (i = 0; i < ecc->bytes; i++) {
> if (calc_ecc[i] != 0x00)
> goto not_ecc_match;
> }
> --
> 2.37.3
>
Reviewed-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] mtd: nand: check nand_mtd_to_devnum() argument
On Thu, Nov 2, 2023 at 12:38 PM Dario Binacchi
wrote:
>
> If the "mtd" parameter is NULL, the search will definitely yield a
> negative result. In that case, it's better to exit immediately.
>
> Signed-off-by: Dario Binacchi
>
> ---
>
> drivers/mtd/nand/raw/nand.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/nand.c b/drivers/mtd/nand/raw/nand.c
> index eacd99c4e275..55c00ac815dd 100644
> --- a/drivers/mtd/nand/raw/nand.c
> +++ b/drivers/mtd/nand/raw/nand.c
> @@ -41,8 +41,11 @@ int nand_mtd_to_devnum(struct mtd_info *mtd)
> {
> int i;
>
> + if (!mtd)
> + return -ENODEV;
> +
> for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
> - if (mtd && get_nand_dev_by_index(i) == mtd)
> + if (get_nand_dev_by_index(i) == mtd)
> return i;
> }
>
> --
> 2.42.0
>
Reviewed-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] mtd: nand: complete nand_register() arguments check
On Thu, Nov 2, 2023 at 12:27 PM Dario Binacchi
wrote:
>
> The patch checks that the "mtd" parameter is accessible before
> proceeding.
>
> Signed-off-by: Dario Binacchi
>
> ---
>
> drivers/mtd/nand/raw/nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/nand.c b/drivers/mtd/nand/raw/nand.c
> index eacd99c4e275..d31bb580c46a 100644
> --- a/drivers/mtd/nand/raw/nand.c
> +++ b/drivers/mtd/nand/raw/nand.c
> @@ -52,7 +52,7 @@ int nand_mtd_to_devnum(struct mtd_info *mtd)
> /* Register an initialized NAND mtd device with the U-Boot NAND command. */
> int nand_register(int devnum, struct mtd_info *mtd)
> {
> - if (devnum >= CONFIG_SYS_MAX_NAND_DEVICE)
> + if (!mtd || devnum >= CONFIG_SYS_MAX_NAND_DEVICE)
> return -EINVAL;
>
> nand_info[devnum] = mtd;
> --
> 2.42.0
>
Reviewed-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 04/15] nand: spl_loaders: Only read enough pages to load the image
Hi
On Sun, Oct 29, 2023 at 4:48 AM Sean Anderson wrote:
>
> All other implementations of nand_spl_load_image only read as many pages as
> are necessary to load the image. However, nand_spl_loaders.c loads the full
> block. Align it with other load functions so that it is easier to
> determine how large of a load buffer we need.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/mtd/nand/raw/nand_spl_loaders.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_spl_loaders.c
> b/drivers/mtd/nand/raw/nand_spl_loaders.c
> index 8848cb27db9..f071b5b57f5 100644
> --- a/drivers/mtd/nand/raw/nand_spl_loaders.c
> +++ b/drivers/mtd/nand/raw/nand_spl_loaders.c
> @@ -12,8 +12,11 @@ int nand_spl_load_image(uint32_t offs, unsigned int size,
> void *dst)
> while (block <= lastblock) {
> if (!nand_is_bad_block(block)) {
> /* Skip bad blocks */
> - while (page < SYS_NAND_PAGE_COUNT) {
> + while (size && page < SYS_NAND_PAGE_COUNT) {
> nand_read_page(block, page, dst);
> +
> + size -= min(size, CONFIG_SYS_NAND_PAGE_SIZE -
> + page_offset);
> /*
> * When offs is not aligned to page address
> the
> * extra offset is copied to dst as well. Copy
> --
> 2.37.1
>
Reviewed-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 02/15] nand: Don't dereference NULL manufacturer_desc
Hi
On Sun, Oct 29, 2023 at 4:48 AM Sean Anderson wrote:
>
> When no manufacturer is matched, manufacturer_desc is NULL. Avoid
> dereferencing it in that case.
>
> Fixes: 4e67c571252 ("mtd,ubi,ubifs: sync with linux v3.15")
> Signed-off-by: Sean Anderson
> ---
>
> drivers/mtd/nand/raw/nand_base.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 6b4adcf6bdc..44b6cb63a01 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4462,17 +4462,14 @@ ident_done:
> else if (chip->jedec_version)
> pr_info("%s %s\n", manufacturer_desc->name,
> chip->jedec_params.model);
> - else
> + else if (manufacturer_desc)
> pr_info("%s %s\n", manufacturer_desc->name, type->name);
> #else
> if (chip->jedec_version)
> pr_info("%s %s\n", manufacturer_desc->name,
> chip->jedec_params.model);
> - else
> + else if (manufacturer_desc)
> pr_info("%s %s\n", manufacturer_desc->name, type->name);
> -
> - pr_info("%s %s\n", manufacturer_desc->name,
> - type->name);
> #endif
>
> pr_info("%d MiB, %s, erase size: %d KiB, page size: %d, OOB size:
> %d\n",
> --
> 2.37.1
>
Reviewed-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 02/26] spl: nor: Don't allocate header on stack
On Thu, Oct 12, 2023 at 5:45 AM Simon Glass wrote:
>
> On Wed, 11 Oct 2023 at 18:56, Sean Anderson wrote:
> >
> > spl_image_info.name contains a reference to legacy_img_hdr. If we allocate
> > the latter on the stack, it will be clobbered after we return. This was
> > addressed for NAND back in 06377c5a1fc ("spl: spl_legacy: Fix NAND boot on
> > OMAP3 BeagleBoard"), but that commit didn't fix NOR.
> >
> > Signed-off-by: Sean Anderson
> > ---
> >
> > common/spl/spl_nor.c | 11 ---
> > 1 file changed, 4 insertions(+), 7 deletions(-)
>
> Reviewed-by: Simon Glass
Reviewed-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 1/1] mtd: nand: raw: atmel: Add error handling when rb-gpios missing
On Fri, Sep 22, 2023 at 11:40 AM Eugen Hristev
wrote:
>
> On 9/22/23 12:08, Alexander Dahl wrote:
> > Adapt behaviour to Linux kernel driver.
> >
> > The return value of gpio_request_by_name_nodev() was not checked before,
> > and thus in case 'rb-gpios' was missing in DT, rb.type was set to
> > ATMEL_NAND_GPIO_RB nevertheless, leading to output like this for
> > example (on sam9x60-curiosity with the line removed from dts):
> >
> > NAND: Could not find valid ONFI parameter page; aborting
> > device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
> > Macronix NAND 512MiB 3,3V 8-bit
> > 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 64
> > atmel-nand-controller nand-controller: NAND scan failed: -22
> > Failed to probe nand driver (err = -22)
> > Failed to initialize NAND controller. (error -22)
> > 0 MiB
> >
> > Note: not having that gpio assigned in dts is possible, the driver does
> > not override nand_chip->dev_ready() then and a generic solution is used.
> >
> > Fixes: 6a8dfd57220d ("nand: atmel: Add DM based NAND driver")
> > Signed-off-by: Alexander Dahl
> > ---
>
> Reviewed-by: Eugen Hristev
>
> >
> > Notes:
> > v1 -> v2:
> >
> > - Only issue error message if error is not ENOENT. If the node just is
> >missing, move on without error message.
> >
> > drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
>
Acked-by: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 2/2] mtd: nand: raw: atmel: Add error handling when rb-gpios missing
Hi
Il mer 20 set 2023, 08:13 Alexander Dahl ha scritto:
> Hello Eugen, hello Michael,
>
> Am Wed, Aug 23, 2023 at 01:59:58PM +0300 schrieb Eugen Hristev:
> > On 8/23/23 09:54, Michael Nazzareno Trimarchi wrote:
> > > Hi
> > >
> > > On Wed, Aug 23, 2023 at 8:28 AM Eugen Hristev
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 8/8/23 18:03, Alexander Dahl wrote:
> > > > > Hello Michael,
> > > > >
> > > > > Am Tue, Aug 08, 2023 at 03:49:45PM +0200 schrieb Michael Nazzareno
> Trimarchi:
> > > > > > Hi
> > > > > >
> > > > > > On Tue, Aug 8, 2023 at 3:03 PM Alexander Dahl
> wrote:
> > > > > > >
> > > > > > > Adapt behaviour to Linux kernel driver.
> > > > > > >
> > > > > > > The return value of gpio_request_by_name_nodev() was not
> checked before,
> > > > > > > and thus in case 'rb-gpios' was missing in DT, rb.type was set
> to
> > > > > > > ATMEL_NAND_GPIO_RB nevertheless, leading to output like this
> for
> > > > > > > example (on sam9x60-curiosity with the line removed from dts):
> > > > > > >
> > > > > > > NAND: Could not find valid ONFI parameter page; aborting
> > > > > > > device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
> > > > > > > Macronix NAND 512MiB 3,3V 8-bit
> > > > > > > 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB
> size: 64
> > > > > > > atmel-nand-controller nand-controller: NAND scan failed:
> -22
> > > > > > > Failed to probe nand driver (err = -22)
> > > > > > > Failed to initialize NAND controller. (error -22)
> > > > > > > 0 MiB
> > > > > > >
> > > > > > > Note: not having that gpio assigned in dts is fine, the driver
> does not
> > > > > > > override nand_chip->dev_ready() then and a generic solution is
> used.
> > > > > > >
> > > > > > > Fixes: 6a8dfd57220d ("nand: atmel: Add DM based NAND driver")
> > > > > > > Signed-off-by: Alexander Dahl
> > > > > > > ---
> > > > > > >drivers/mtd/nand/raw/atmel/nand-controller.c | 11
> +++
> > > > > > >1 file changed, 7 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c
> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> > > > > > > index 2b29c8def6..8e745a5111 100644
> > > > > > > --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> > > > > > > +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> > > > > > > @@ -1600,10 +1600,13 @@ static struct atmel_nand
> *atmel_nand_create(struct atmel_nand_controller *nc,
> > > > > > > nand->cs[i].rb.type =
> ATMEL_NAND_NATIVE_RB;
> > > > > > > nand->cs[i].rb.id = val;
> > > > > > > } else {
> > > > > > > - gpio_request_by_name_nodev(np,
> "rb-gpios", 0,
> > > > > > > -
> >cs[i].rb.gpio,
> > > > > > > -
> GPIOD_IS_IN);
> > > > > > > - nand->cs[i].rb.type =
> ATMEL_NAND_GPIO_RB;
> > > > > > > + ret = gpio_request_by_name_nodev(np,
> "rb-gpios", 0,
> > > > > > > +
> >cs[i].rb.gpio,
> > > > > > > +
> GPIOD_IS_IN);
> > > > > > > + if (ret)
> > > > > > > + dev_err(nc->dev, "Failed to
> get R/B gpio (err = %d)\n", ret);
> > > > > >
> > > > > > Should not then an error here
> > > > >
> > > > > Different log level or no message at all?
> > > > >
> > > > > Note: Linux prints the same message with error level in that case.
> > > > >
> > > > > Greets
> > > > > Alex
> > > > >
> > > >
> > > > Since the rb-gpios is optional, we can continue probing without it.
> > > > Throwing an error message is
Re: [PATCH 2/2] mtd: nand: raw: atmel: Add error handling when rb-gpios missing
Hi
On Wed, Aug 23, 2023 at 8:28 AM Eugen Hristev
wrote:
>
> Hi,
>
> On 8/8/23 18:03, Alexander Dahl wrote:
> > Hello Michael,
> >
> > Am Tue, Aug 08, 2023 at 03:49:45PM +0200 schrieb Michael Nazzareno
> > Trimarchi:
> >> Hi
> >>
> >> On Tue, Aug 8, 2023 at 3:03 PM Alexander Dahl wrote:
> >>>
> >>> Adapt behaviour to Linux kernel driver.
> >>>
> >>> The return value of gpio_request_by_name_nodev() was not checked before,
> >>> and thus in case 'rb-gpios' was missing in DT, rb.type was set to
> >>> ATMEL_NAND_GPIO_RB nevertheless, leading to output like this for
> >>> example (on sam9x60-curiosity with the line removed from dts):
> >>>
> >>> NAND: Could not find valid ONFI parameter page; aborting
> >>> device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
> >>> Macronix NAND 512MiB 3,3V 8-bit
> >>> 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 64
> >>> atmel-nand-controller nand-controller: NAND scan failed: -22
> >>> Failed to probe nand driver (err = -22)
> >>> Failed to initialize NAND controller. (error -22)
> >>> 0 MiB
> >>>
> >>> Note: not having that gpio assigned in dts is fine, the driver does not
> >>> override nand_chip->dev_ready() then and a generic solution is used.
> >>>
> >>> Fixes: 6a8dfd57220d ("nand: atmel: Add DM based NAND driver")
> >>> Signed-off-by: Alexander Dahl
> >>> ---
> >>> drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++
> >>> 1 file changed, 7 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> index 2b29c8def6..8e745a5111 100644
> >>> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> @@ -1600,10 +1600,13 @@ static struct atmel_nand
> >>> *atmel_nand_create(struct atmel_nand_controller *nc,
> >>> nand->cs[i].rb.type = ATMEL_NAND_NATIVE_RB;
> >>> nand->cs[i].rb.id = val;
> >>> } else {
> >>> - gpio_request_by_name_nodev(np, "rb-gpios", 0,
> >>> - >cs[i].rb.gpio,
> >>> - GPIOD_IS_IN);
> >>> - nand->cs[i].rb.type = ATMEL_NAND_GPIO_RB;
> >>> + ret = gpio_request_by_name_nodev(np, "rb-gpios",
> >>> 0,
> >>> +
> >>> >cs[i].rb.gpio,
> >>> +GPIOD_IS_IN);
> >>> + if (ret)
> >>> + dev_err(nc->dev, "Failed to get R/B gpio
> >>> (err = %d)\n", ret);
> >>
> >> Should not then an error here
> >
> > Different log level or no message at all?
> >
> > Note: Linux prints the same message with error level in that case.
> >
> > Greets
> > Alex
> >
>
> Since the rb-gpios is optional, we can continue probing without it.
> Throwing an error message is optional and pure informative. So I am fine
> with it
>
Yes ok, but I'm not sure linux give an error if the gpio is get as
optional and condition
is IS_ERR. Am I right?
For the rest is fine
Michael
> What I wanted to ask is what happens with nand->cs[i].rb.type , is it 0
> by default ?
>
> Other than that, I can apply this patch, Michael, do you have any more
> comments on it ?
>
> Thanks,
> Eugen
> >>
> >> Michael
> >>
> >>> + else
> >>> + nand->cs[i].rb.type = ATMEL_NAND_GPIO_RB;
> >>> }
> >>>
> >>> gpio_request_by_name_nodev(np, "cs-gpios", 0,
> >>> --
> >>> 2.30.2
> >>>
> >>
> >>
> >> --
> >> Michael Nazzareno Trimarchi
> >> Co-Founder & Chief Executive Officer
> >> M. +39 347 913 2170
> >> mich...@amarulasolutions.com
> >> __
> >>
> >> Amarula Solutions BV
> >> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> >> T. +31 (0)85 111 9172
> >> i...@amarulasolutions.com
> >> www.amarulasolutions.com
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 2/2] mtd: nand: raw: atmel: Add error handling when rb-gpios missing
Hi
On Tue, Aug 8, 2023 at 3:03 PM Alexander Dahl wrote:
>
> Adapt behaviour to Linux kernel driver.
>
> The return value of gpio_request_by_name_nodev() was not checked before,
> and thus in case 'rb-gpios' was missing in DT, rb.type was set to
> ATMEL_NAND_GPIO_RB nevertheless, leading to output like this for
> example (on sam9x60-curiosity with the line removed from dts):
>
> NAND: Could not find valid ONFI parameter page; aborting
> device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
> Macronix NAND 512MiB 3,3V 8-bit
> 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 64
> atmel-nand-controller nand-controller: NAND scan failed: -22
> Failed to probe nand driver (err = -22)
> Failed to initialize NAND controller. (error -22)
> 0 MiB
>
> Note: not having that gpio assigned in dts is fine, the driver does not
> override nand_chip->dev_ready() then and a generic solution is used.
>
> Fixes: 6a8dfd57220d ("nand: atmel: Add DM based NAND driver")
> Signed-off-by: Alexander Dahl
> ---
> drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c
> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index 2b29c8def6..8e745a5111 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -1600,10 +1600,13 @@ static struct atmel_nand *atmel_nand_create(struct
> atmel_nand_controller *nc,
> nand->cs[i].rb.type = ATMEL_NAND_NATIVE_RB;
> nand->cs[i].rb.id = val;
> } else {
> - gpio_request_by_name_nodev(np, "rb-gpios", 0,
> - >cs[i].rb.gpio,
> - GPIOD_IS_IN);
> - nand->cs[i].rb.type = ATMEL_NAND_GPIO_RB;
> + ret = gpio_request_by_name_nodev(np, "rb-gpios", 0,
> +>cs[i].rb.gpio,
> +GPIOD_IS_IN);
> + if (ret)
> + dev_err(nc->dev, "Failed to get R/B gpio (err
> = %d)\n", ret);
Should not then an error here
Michael
> + else
> + nand->cs[i].rb.type = ATMEL_NAND_GPIO_RB;
> }
>
> gpio_request_by_name_nodev(np, "cs-gpios", 0,
> --
> 2.30.2
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 1/2] mtd: nand: raw: atmel: Remove duplicate line
Hi On Tue, Aug 8, 2023 at 3:03 PM Alexander Dahl wrote: > > Signed-off-by: Alexander Dahl > --- > drivers/mtd/nand/raw/atmel/nand-controller.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c > b/drivers/mtd/nand/raw/atmel/nand-controller.c > index 9873d11254..2b29c8def6 100644 > --- a/drivers/mtd/nand/raw/atmel/nand-controller.c > +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c > @@ -1474,7 +1474,6 @@ static void atmel_nand_init(struct > atmel_nand_controller *nc, > > mtd->dev->parent = nc->dev; > nand->controller = >base; > - nand->controller = >base; > > chip->cmd_ctrl = atmel_nand_cmd_ctrl; > chip->read_byte = atmel_nand_read_byte; > -- > 2.30.2 > Reviewed-by: Michael Trimarchi -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] get_maintainer.pl: Add an ignore list for git history
On Mon, Aug 7, 2023 at 3:21 PM Tom Rini wrote: > > As Pali Rohár has asked to not be copied on changes to files he is not > a specific maintainer of, add his address to .get_maintainer.ignore. > > Signed-off-by: Tom Rini > --- > Cc: "Pali Rohár" > --- > .get_maintainer.ignore | 1 + > .gitignore | 1 + > 2 files changed, 2 insertions(+) > create mode 100644 .get_maintainer.ignore > Reviewed-by: Michael Trimarchi > diff --git a/.get_maintainer.ignore b/.get_maintainer.ignore > new file mode 100644 > index ..899a1469b2ae > --- /dev/null > +++ b/.get_maintainer.ignore > @@ -0,0 +1 @@ > +"Pali Rohár" > diff --git a/.gitignore b/.gitignore > index 3a4d056edfc3..002f95de4feb 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -53,6 +53,7 @@ fit-dtb.blob* > # > !.gitignore > !.mailmap > +!.get_maintainer.* > > # > # Generated files > -- > 2.34.1 > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 00/22] x86: Move some boards to text environment
Hi Andy On Mon, Aug 7, 2023 at 3:04 PM Andy Shevchenko wrote: > > On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote: > > Hi Pali > > > > Can you just filter emails on your side? > > Independently on the question is default setup is good or not > (from _this_ point of view, I *disagree* with Pali), we have to > have a possibility to filter on _our_ side the email addresses > to make people happy. If Pali by some reasons does not want to > see, it must be easy to keep some deny list in the repository. > > What you are suggesting is not polite I believe. I understand what you mean, I never consider emails to me as a problem if I'm working on an opensource project and mostly of the time I'm happy to receive them Michael > > > On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár wrote: > > > > > > So remove me from that list of dram.c file. I'm not interested to > > > receive emails from people who are ignoring me about unrelated things. > > > > > > On Monday 07 August 2023 09:43:01 Bin Meng wrote: > > > > Hi Pali, > > > > > > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár wrote: > > > > > > > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote: > > > > > > Hi Pali, > > > > > > > > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár wrote: > > > > > > > > > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So > > > > > > > please > > > > > > > do not send me these emails. I have expressed it many times. > > > > > > > > > > > > You were sent one patch (and the cover letter) because you are the > > > > > > second committer on arch/x86/cpu/qemu/dram.c > > > > > > > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have > > > > > to > > > > > repeat it? You do not understand? Or what you are trying to do now? > > > > > > > > I believe this cc list comes from patman which calls get_maintainer.pl > > > > to get the cc list. > > > > get_maintainer.pl determines the person names from 1. MAINTAINERS of > > > > the changed file 2. git commit history of the changed file. > > > > > > > > I can see the philosophy was that someone who touched the changed file > > > > should be copied for review. > > > > We certainly could argue that and just get the list solely from the > > > > MAINTAINERS file. > > > > > > > > Regards, > > > > Bin > > > > > > > > -- > > Michael Nazzareno Trimarchi > > Co-Founder & Chief Executive Officer > > M. +39 347 913 2170 > > mich...@amarulasolutions.com > > __ > > > > Amarula Solutions BV > > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > > T. +31 (0)85 111 9172 > > i...@amarulasolutions.com > > www.amarulasolutions.com > > -- > With Best Regards, > Andy Shevchenko > > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 00/22] x86: Move some boards to text environment
Hi Pali Can you just filter emails on your side? Michael On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár wrote: > > So remove me from that list of dram.c file. I'm not interested to > receive emails from people who are ignoring me about unrelated things. > > On Monday 07 August 2023 09:43:01 Bin Meng wrote: > > Hi Pali, > > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár wrote: > > > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote: > > > > Hi Pali, > > > > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár wrote: > > > > > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So please > > > > > do not send me these emails. I have expressed it many times. > > > > > > > > You were sent one patch (and the cover letter) because you are the > > > > second committer on arch/x86/cpu/qemu/dram.c > > > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have to > > > repeat it? You do not understand? Or what you are trying to do now? > > > > I believe this cc list comes from patman which calls get_maintainer.pl > > to get the cc list. > > get_maintainer.pl determines the person names from 1. MAINTAINERS of > > the changed file 2. git commit history of the changed file. > > > > I can see the philosophy was that someone who touched the changed file > > should be copied for review. > > We certainly could argue that and just get the list solely from the > > MAINTAINERS file. > > > > Regards, > > Bin -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 1/1] cmd: avoid overflow in mtd_is_aligned_with_min_io_size
Hi
On Mon, Jul 31, 2023 at 10:10 AM Heinrich Schuchardt <
heinrich.schucha...@canonical.com> wrote:
>
>
>
> On 7/31/23 09:00, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Sun, Jul 30, 2023 at 3:03 PM Heinrich Schuchardt
> > wrote:
> >>
> >> Multiplication of u32 factors has an u32 result even if an overflow
occurs.
> >> An overflow may occur in
> >>
> >> u64 data_off = page * mtd->writesize;
> >>
> >> The size of the flash device may exceed 4 GiB.
> >>
> >
> > Instead of force variables to u64 just cast where expansion is needed
before
> > multiple. Why we should thinking to have u64 number of nand pages?
>
> Does anything stop MTD devices from reaching 2^32 pages?
>
Pages is integer right now in the code. What is the problem just to fix
what you are claim
Michael
> The driver layer uses loff_t for 'from'. I can't see any limitation there.
>
> Best regards
>
> Heinrich
>
> >
> > Michael
> >
> >> Play it safe and use u64 consistently.
> >>
> >> Signed-off-by: Heinrich Schuchardt
> >> ---
> >> cmd/mtd.c | 17 +++--
> >> 1 file changed, 7 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/cmd/mtd.c b/cmd/mtd.c
> >> index eb6e2d6892..fb6e2bb047 100644
> >> --- a/cmd/mtd.c
> >> +++ b/cmd/mtd.c
> >> @@ -33,11 +33,9 @@ static struct mtd_info *get_mtd_by_name(const char
*name)
> >> return mtd;
> >> }
> >>
> >> -static uint mtd_len_to_pages(struct mtd_info *mtd, u64 len)
> >> +static u64 mtd_len_to_pages(struct mtd_info *mtd, u64 len)
> >> {
> >> - do_div(len, mtd->writesize);
> >> -
> >> - return len;
> >> + return lldiv(len, mtd->writesize);
> >> }
> >>
> >> static bool mtd_is_aligned_with_min_io_size(struct mtd_info *mtd,
u64 size)
> >> @@ -72,8 +70,7 @@ static void mtd_dump_device_buf(struct mtd_info
*mtd, u64 start_off,
> >> {
> >> bool has_pages = mtd->type == MTD_NANDFLASH ||
> >> mtd->type == MTD_MLCNANDFLASH;
> >> - int npages = mtd_len_to_pages(mtd, len);
> >> - uint page;
> >> + u64 page, npages = mtd_len_to_pages(mtd, len);
> >>
> >> if (has_pages) {
> >> for (page = 0; page < npages; page++) {
> >> @@ -251,12 +248,12 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int
flag, int argc,
> >> char *const argv[])
> >> {
> >> bool dump, read, raw, woob, write_empty_pages, has_pages =
false;
> >> - u64 start_off, off, len, remaining, default_len;
> >> + u64 start_off, off, len, oob_len, remaining, default_len;
> >> struct mtd_oob_ops io_op = {};
> >> - uint user_addr = 0, npages;
> >> + uint user_addr = 0;
> >> + u64 npages;
> >> const char *cmd = argv[0];
> >> struct mtd_info *mtd;
> >> - u32 oob_len;
> >> u8 *buf;
> >> int ret;
> >>
> >> @@ -322,7 +319,7 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int
flag, int argc,
> >> }
> >>
> >> if (has_pages)
> >> - printf("%s %lld byte(s) (%d page(s)) at offset
0x%08llx%s%s%s\n",
> >> + printf("%s %lld byte(s) (%lld page(s)) at offset
0x%08llx%s%s%s\n",
> >> read ? "Reading" : "Writing", len, npages,
start_off,
> >> raw ? " [raw]" : "", woob ? " [oob]" : "",
> >> !read && write_empty_pages ? " [dontskipff]" :
"");
> >> --
> >> 2.40.1
> >>
Re: [PATCH 1/1] cmd: avoid overflow in mtd_is_aligned_with_min_io_size
Hi
On Sun, Jul 30, 2023 at 3:03 PM Heinrich Schuchardt
wrote:
>
> Multiplication of u32 factors has an u32 result even if an overflow occurs.
> An overflow may occur in
>
> u64 data_off = page * mtd->writesize;
>
> The size of the flash device may exceed 4 GiB.
>
Instead of force variables to u64 just cast where expansion is needed before
multiple. Why we should thinking to have u64 number of nand pages?
Michael
> Play it safe and use u64 consistently.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/mtd.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/cmd/mtd.c b/cmd/mtd.c
> index eb6e2d6892..fb6e2bb047 100644
> --- a/cmd/mtd.c
> +++ b/cmd/mtd.c
> @@ -33,11 +33,9 @@ static struct mtd_info *get_mtd_by_name(const char *name)
> return mtd;
> }
>
> -static uint mtd_len_to_pages(struct mtd_info *mtd, u64 len)
> +static u64 mtd_len_to_pages(struct mtd_info *mtd, u64 len)
> {
> - do_div(len, mtd->writesize);
> -
> - return len;
> + return lldiv(len, mtd->writesize);
> }
>
> static bool mtd_is_aligned_with_min_io_size(struct mtd_info *mtd, u64 size)
> @@ -72,8 +70,7 @@ static void mtd_dump_device_buf(struct mtd_info *mtd, u64
> start_off,
> {
> bool has_pages = mtd->type == MTD_NANDFLASH ||
> mtd->type == MTD_MLCNANDFLASH;
> - int npages = mtd_len_to_pages(mtd, len);
> - uint page;
> + u64 page, npages = mtd_len_to_pages(mtd, len);
>
> if (has_pages) {
> for (page = 0; page < npages; page++) {
> @@ -251,12 +248,12 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag,
> int argc,
> char *const argv[])
> {
> bool dump, read, raw, woob, write_empty_pages, has_pages = false;
> - u64 start_off, off, len, remaining, default_len;
> + u64 start_off, off, len, oob_len, remaining, default_len;
> struct mtd_oob_ops io_op = {};
> - uint user_addr = 0, npages;
> + uint user_addr = 0;
> + u64 npages;
> const char *cmd = argv[0];
> struct mtd_info *mtd;
> - u32 oob_len;
> u8 *buf;
> int ret;
>
> @@ -322,7 +319,7 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag, int
> argc,
> }
>
> if (has_pages)
> - printf("%s %lld byte(s) (%d page(s)) at offset
> 0x%08llx%s%s%s\n",
> + printf("%s %lld byte(s) (%lld page(s)) at offset
> 0x%08llx%s%s%s\n",
>read ? "Reading" : "Writing", len, npages, start_off,
>raw ? " [raw]" : "", woob ? " [oob]" : "",
>!read && write_empty_pages ? " [dontskipff]" : "");
> --
> 2.40.1
>
Re: [PATCH] mtd: nand: pxa3xx: Fix buffer overflow during raw reads
Hi Chris
On Sun, Jul 30, 2023 at 11:21 PM Chris Packham wrote:
>
> Hi Pierre,
>
> On Sun, Jul 30, 2023 at 6:08 AM Pierre Bourdon wrote:
> >
> > Chunked raw reads get accumulated to the data buffer, but in some
> > ECC configurations they can end up being larger than the originally
> > computed size (write page size + OOB size). For example:
> >
> > 4K page size, ECC strength 8:
> > - Normal reads: writesize (4096B) + oobsize (128B) = 4224 bytes.
> > - Chunked raw reads: 4 chunks of 1024B + 1 final spare area of 64B + 5
> > ECC areas of 32B = 4320B.
>
> I'm not a NAND expert and I haven't sat down and fully grasped the
> math but I was curious to see what the Linux kernel did. It looks like
> it uses the same mtd->writesize + mtd->oobsize calculation (see
> nand_scan_tail() in nand_base.c). So either Linux has the same bug or
> maybe there's something off in u-boot's nfc_layouts[]. I'll see if I
> can get one of my boards to trigger a KASAN report (I'm not sure if
> any of the NAND chips we use will hit the cases you're pointing out).
>
I have already seen the code about it and this buffer is used only by
uboot to get the result on fake interrupt implementation. The problem
that I have seem is why buf_count is not affected on this change. Is possible
to have a trace down on what happen with more info?
MIchael
> >
> > Fixes: 6293b0361d9 ("mtd: nand: pxa3xx: add raw read support")
> > Signed-off-by: Pierre Bourdon
> > ---
> >
> > drivers/mtd/nand/raw/pxa3xx_nand.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > index d502e967f9..2894ababbe 100644
> > --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > @@ -1471,6 +1471,19 @@ static void pxa3xx_nand_detect_config(struct
> > pxa3xx_nand_info *info)
> >
> > static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
> > {
> > + unsigned int chunk_size;
> > + unsigned int last_chunk_size;
> > +
> > + /*
> > +* The data buffer needs to not only be large enough for normal +
> > OOB
> > +* reads, but also for raw reads. The raw reads can end up taking
> > more
> > +* space due to the chunking scheme.
> > +*/
> > + chunk_size = info->chunk_size + info->spare_size + info->ecc_size;
> > + last_chunk_size =
> > + info->last_chunk_size + info->last_spare_size +
> > info->ecc_size;
> > + info->buf_size = info->nfullchunks * chunk_size + last_chunk_size;
> > +
> > info->data_buff = kmalloc(info->buf_size, GFP_KERNEL);
> > if (info->data_buff == NULL)
> > return -ENOMEM;
> > @@ -1661,7 +1674,6 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
> > kfree(info->data_buff);
> >
> > /* allocate the real data + oob buffer */
> > - info->buf_size = mtd->writesize + mtd->oobsize;
> > ret = pxa3xx_nand_init_buff(info);
> > if (ret)
> > return ret;
> > --
> > 2.41.0
> >
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 3/6] mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC
Hi
On Thu, Jul 13, 2023 at 10:17 AM Stefan Roese wrote:
>
> On 7/10/23 00:47, Chris Packham wrote:
> > The NAND flash controller (NFC) on the AC5/AC5X SoC is the same as
> > the NFC used on other Marvell SoCs. It does have the additional
> > restriction of only supporting SDR timing modes up to 3.
> >
> > Signed-off-by: Chris Packham
>
> Reviewed-by: Stefan Roese
>
Reviewed-by: Michael Trimarchi
Michael
> Thanks,
> Stefan
>
> > ---
> > drivers/mtd/nand/raw/pxa3xx_nand.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > index fcd1b9c63614..9dee580ab9c2 100644
> > --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > @@ -167,6 +167,7 @@ enum pxa3xx_nand_variant {
> > PXA3XX_NAND_VARIANT_PXA,
> > PXA3XX_NAND_VARIANT_ARMADA370,
> > PXA3XX_NAND_VARIANT_ARMADA_8K,
> > + PXA3XX_NAND_VARIANT_AC5,
> > };
> >
> > struct pxa3xx_nand_host {
> > @@ -391,6 +392,10 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
> > .compatible = "marvell,armada-8k-nand-controller",
> > .data = PXA3XX_NAND_VARIANT_ARMADA_8K,
> > },
> > + {
> > + .compatible = "marvell,mvebu-ac5-pxa3xx-nand",
> > + .data = PXA3XX_NAND_VARIANT_AC5,
> > + },
> > {}
> > };
> >
> > @@ -505,6 +510,9 @@ static int pxa3xx_nand_init_timings(struct
> > pxa3xx_nand_host *host)
> > if (mode < 0)
> > mode = 0;
> >
> > + if (info->variant == PXA3XX_NAND_VARIANT_AC5)
> > + mode = min(mode, 3);
> > +
> > timings = onfi_async_timing_mode_to_sdr_timings(mode);
> > if (IS_ERR(timings))
> > return PTR_ERR(timings);
> > @@ -730,7 +738,8 @@ static irqreturn_t pxa3xx_nand_irq(struct
> > pxa3xx_nand_info *info)
> >
> > /* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
> > if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
> > - info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
> > + info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
> > + info->variant == PXA3XX_NAND_VARIANT_AC5)
> > nand_writel(info, NDCB0, info->ndcb3);
> > }
> >
> > @@ -1579,7 +1588,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
> >
> > /* Device detection must be done with ECC disabled */
> > if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
> > - info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
> > + info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
> > + info->variant == PXA3XX_NAND_VARIANT_AC5)
> > nand_writel(info, NDECCCTRL, 0x0);
> >
> > if (nand_scan_ident(mtd, 1, NULL))
> > @@ -1630,7 +1640,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
> >*/
> > if (mtd->writesize > info->chunk_size) {
> > if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
> > - info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
> > + info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
> > + info->variant == PXA3XX_NAND_VARIANT_AC5) {
> > chip->cmdfunc = nand_cmdfunc_extended;
> > } else {
> > dev_err(mtd->dev,
>
> Viele Grüße,
> Stefan Roese
>
> --
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: U-Boot OMAP GPMC ECC change
Hi all Il sab 20 mag 2023, 19:28 Colin Foster ha scritto: > On Fri, May 19, 2023 at 03:41:34PM +0300, Roger Quadros wrote: > > Hi Colin, > > > > On 19/05/2023 02:19, Colin Foster wrote: > > > Hi Roger, > > > > > >> Can you please share your spl/u-boot.cfg? > > > > > > Attached > > > > Couple of questions there > > > > 1) CONFIG_MTDPARTS_DEFAULT > "mtdparts=nandflash:0x2(xload_raw),0x18(u-boot),0x18(u-boot-2),0x1fce(main)" > > Is this correct and matches with what kernel sees? > > I couldn't see the NAND partition table in the Kernel Device tree patch. > > Yes, this is correct. I intentionally left my MTD Partitions out of the > kernel patch, since I don't want any changes I might make to the flash > partitions to require further patches. I'm currently at this structure > (SPL, 2x U-Boot, and main UBI with A/B partitions and 2x U-Boot Envs) > > The SD Boot version of U-Boot doesn't use NAND, so it might have a stale > partition layout that I'll need to remove / modify. > Was any end up here? Michael > > > > > 2) > > #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x2 > > #define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND 0x1a > > > > These don't seem to match what you have defined in MTDPARTS_DEFAULT. > > Which one is correct? > > This matches the above partition layout. 0x18 + 0x2 = 0x1a. > > It wasn't until recently I realized I needed to remove > CONFIG_SPL_RAW_IMAGE_SUPPORT in order for this fallback to succeed. > > > > > How do you flash the MLO and u-boot image to NAND? > > I boot to from SD card, then run a commissioning script that contains: > > ``` > echo "Erasing MLO partition $MLO_PART" > flash_erase $MLO_PART 0 0 > > echo "Programming MLO partition" > nandwrite -a -p $MLO_PART $MLO_FILE > > echo "Erasing U-Boot partition $U_BOOT_PART" > flash_erase $U_BOOT_PART 0 0 > > echo "Programming U-Boot partition" > nandwrite -a -p $U_BOOT_PART $U_BOOT_FILE > > echo "Erasing U-Boot redundant partition $U_BOOT_PART_REDUND" > flash_erase $U_BOOT_PART_REDUND 0 0 > > echo "Programming U-Boot redund partition" > nandwrite -a -p $U_BOOT_PART_REDUND $U_BOOT_FILE > > echo "Clearing UBI partition" > flash_erase $UBI_PART 0 0 > > echo "Formatting UBI partition" > ubiformat $UBI_PART -y > ubiattach -p $UBI_PART > > echo "Making UBI volumes" > ubimkvol /dev/ubi0 -N env1 -s 0x4 > ubimkvol /dev/ubi0 -N env2 -s 0x4 > ubimkvol /dev/ubi0 -N rootfs-a -s 0xc00 > ubimkvol /dev/ubi0 -N rootfs-b -s 0xc00 > > echo "Writing rootfs partitions" > ubiupdatevol /dev/ubi0_2 $ROOTFS_FILE > ubiupdatevol /dev/ubi0_3 $ROOTFS_FILE > ``` > > For all these tests I've been manually running the flash_erase / > nandwrite process for the SPL / U-Boot partitions. > > > > > I tried on AM335x-EVM and it works fine both before and after commit > 04fcd25873. > > > > Once change I had to do was to increase the u-boot partition size > > as u-boot image does not fit in original partition size. > > > > -boot log follows- > > > > U-Boot SPL 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 > +0300) > > Trying to boot from NAND > > > > > > U-Boot 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 +0300) > > > > CPU : AM335X-GP rev 1.0 > > Model: TI AM335x EVM > > DRAM: 512 MiB > > Core: 156 devices, 17 uclasses, devicetree: separate > > WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout) > > NAND: 256 MiB > > MMC: OMAP SD/MMC: 0 > > Loading Environment from FAT... Unable to read "uboot.env" from > mmc0:1... > > not set. Validating first E-fuse MAC > > Net: eth2: ethernet@4a10, eth3: usb_ether > > Hit any key to stop autoboot: 0 > > => > > > > => mtd > > > > device nand0 , # parts = 10 > > #: namesizeoffset mask_flags > > 0: NAND.SPL0x0002 0x 0 > > 1: NAND.SPL.backup10x0002 0x0002 0 > > 2: NAND.SPL.backup20x0002 0x0004 0 > > 3: NAND.SPL.backup30x0002 0x0006 0 > > I need to go back to the 4460 datasheet. I looked and don't remember > seeing anything about an SPL search. I'd sleep better at night knowing > that when the day comes I need to update the SPL, I can do so with some > redundancy. Sorry - I'm getting off topic. > > I'll be back with hardware on Monday to keep looking at this. > > > 4: NAND.u-boot-spl-os 0x0004 0x0008 0 > > 5: NAND.u-boot 0x0020 0x000c 0 > > 6: NAND.u-boot-env 0x0002 0x002c 0 > > 7: NAND.u-boot-env.backup10x0002 0x002e 0 > > 8: NAND.kernel 0x0070 0x0030 0 > > 9: NAND.file-system0x0f60 0x00a0 0 > > > > > > -- > > cheers, > > -roger >
Re: ELCE 2023 - Prague
Hi Dario should be there too. You can have in our office if you want Michael On Fri, Jun 16, 2023 at 2:55 PM Eugen Hristev wrote: > > On 6/16/23 15:13, Michal Simek wrote: > > Hi, > > > > I have had a chat with Marek that ELCE 2023 in Prague is coming. > > It is good opportunity to talk to each other in person. > > That's why we are interested to know who from U-Boot community is going. > > > > Me, Marek and Simon are going to be there. Who else is coming? > > > > Cheers, > > Michal > > I will be there as well if you want to meet. I saw Simon has a talk > about U-boot scheduled. It's likely most of the U-boot folks will be > attending > > Eugen -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 4/6] mtd: nand: zynq_nand: Change datatype of status and ecc_status to int
Hi
On Fri, Jun 9, 2023 at 11:22 AM Ashok Reddy Soma
wrote:
>
> From: Algapally Santosh Sagar
>
> status and ecc_status are of unsigned type where they are compared for
> negative value. This is pointed by below sparse warning. Change datatype
> to int to fix this.
> warning: comparison of unsigned expression in '< 0' is always false
> [-Wtype-limits]
>
> Signed-off-by: Algapally Santosh Sagar
> Signed-off-by: Ashok Reddy Soma
> ---
>
> drivers/mtd/nand/raw/zynq_nand.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/zynq_nand.c
> b/drivers/mtd/nand/raw/zynq_nand.c
> index 9e3ee7412d..545fdd7b69 100644
> --- a/drivers/mtd/nand/raw/zynq_nand.c
> +++ b/drivers/mtd/nand/raw/zynq_nand.c
> @@ -285,7 +285,7 @@ static int zynq_nand_init_nand_flash(struct mtd_info
> *mtd, int option)
> {
> struct nand_chip *nand_chip = mtd_to_nand(mtd);
> struct nand_drv *smc = nand_get_controller_data(nand_chip);
> - u32 status;
> + int status;
>
> /* disable interrupts */
> writel(ZYNQ_NAND_CLR_CONFIG, >reg->cfr);
> @@ -332,7 +332,7 @@ static int zynq_nand_calculate_hwecc(struct mtd_info
> *mtd, const u8 *data,
> struct nand_drv *smc = nand_get_controller_data(nand_chip);
> u32 ecc_value = 0;
> u8 ecc_reg, ecc_byte;
> - u32 ecc_status;
> + int ecc_status;
>
> /* Wait till the ECC operation is complete */
> ecc_status = zynq_nand_waitfor_ecc_completion(mtd);
> --
Reviewed-By: Michael Trimarchi
> 2.17.1
>
Re: [PATCH v2] dfu: mtd: mark bad the MTD block on erase error
Hi
On Fri, Jun 2, 2023 at 3:23 PM Patrick Delaunay
wrote:
>
> In the MTD DFU backend, it is needed to mark the NAND block bad when the
> erase failed with the -EIO error, as it is done in UBI and JFFS2 code.
>
> This operation is not done in the MTD framework, but the bad block
> tag (in BBM or in BBT) is required to avoid to write data on this block
> in the next DFU_OP_WRITE loop in mtd_block_op(): the code skip the bad
> blocks, tested by mtd_block_isbad().
>
> Without this patch, when the NAND block become bad on DFU write operation
> - low probability on new NAND - the DFU write operation will always failed
> because the failing block is never marked bad.
>
> This patch also adds a test to avoid to request an erase operation on a
> block already marked bad; this test is not performed in MTD framework
> in mtd_erase().
>
> Signed-off-by: Patrick Delaunay
> ---
>
> Changes in v2:
> - fixe mtd_block_isbad offset parameter for erase check
> - Add trace when bad block are skipped in erase loop
> - Add remaining byte in trace "Limit reached"
>
> drivers/dfu/dfu_mtd.c | 32 ++--
> 1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
> index c7075f12eca9..a4a3e91be23e 100644
> --- a/drivers/dfu/dfu_mtd.c
> +++ b/drivers/dfu/dfu_mtd.c
> @@ -86,27 +86,39 @@ static int mtd_block_op(enum dfu_op op, struct dfu_entity
> *dfu,
>
> while (remaining) {
> if (erase_op.addr + remaining > lim) {
> - printf("Limit reached 0x%llx while erasing at
> offset 0x%llx\n",
> - lim, off);
> + printf("Limit reached 0x%llx while erasing at
> offset 0x%llx, remaining 0x%llx\n",
> + lim, erase_op.addr, remaining);
This can be in a different change
> return -EIO;
> }
>
> + /* Skip the block if it is bad, don't erase it again
> */
> + if (mtd_block_isbad(mtd, erase_op.addr)) {
> + printf("Skipping bad block at 0x%08llx\n",
> + erase_op.addr);
This print is wrong. If ret is 1 it's a bad block if it's 2 the block
is reserved
> + erase_op.addr += mtd->erasesize;
> + continue;
> + }
> +
> ret = mtd_erase(mtd, _op);
>
> if (ret) {
> - /* Abort if its not a bad block error */
> - if (ret != -EIO) {
> - printf("Failure while erasing at
> offset 0x%llx\n",
> - erase_op.fail_addr);
> - return 0;
> + /* If this is not -EIO, we have no idea what
> to do. */
> + if (ret == -EIO) {
> + printf("Marking bad block at 0x%08llx
> (%d)\n",
> + erase_op.fail_addr, ret);
> + ret = mtd_block_markbad(mtd,
> erase_op.addr);
> + }
> + /* Abort if it is not -EIO or can't mark bad
> */
> + if (ret) {
> + printf("Failure while erasing at
> offset 0x%llx (%d)\n",
> + erase_op.fail_addr, ret);
> + return ret;
> }
> - printf("Skipping bad block at 0x%08llx\n",
> - erase_op.addr);
> } else {
> remaining -= mtd->erasesize;
> }
>
> - /* Continue erase behind bad block */
> + /* Continue erase behind the current block */
> erase_op.addr += mtd->erasesize;
> }
> }
Otherwise
Reviewed-by: Michael Trimarchi
> --
> 2.25.1
>
Re: [PATCH v2 2/2] common/memsize.c: Fix get_ram_size() when cache is enabled
Hi
On Tue, May 30, 2023 at 3:49 PM Francesco Dolcini wrote:
>
> On Tue, May 30, 2023 at 03:42:18PM +0200, Michael Nazzareno Trimarchi wrote:
> > On Tue, May 30, 2023 at 3:34 PM Francesco Dolcini
> > wrote:
> > >
> > > From: Emanuele Ghidoli
> > >
> > > Ensure that every write is flushed to memory and afterward reads are
> > > from memory.
> > > Since the algorithm rely on the fact that accessing to not existent
> > > memory lead to write at addr / 2 without this modification accesses
> > > to aliased (not physically present) addresses are cached and
> > > wrong size is returned.
> > >
> > > This was discovered while working on a TI AM625 based board
> > > where cache is normally enabled, see commit c02712a74849 ("arm: mach-k3:
> > > Enable dcache in SPL").
> > >
> > > Signed-off-by: Emanuele Ghidoli
> > > Signed-off-by: Francesco Dolcini
> > > ---
> > > v2:
> > > * check if CONFIG_SYS_CACHELINE_SIZE is defined
> > > * do flush only when cache is enabled
> > > ---
> > > common/memsize.c | 24
> > > 1 file changed, 24 insertions(+)
> > >
> > > diff --git a/common/memsize.c b/common/memsize.c
> > > index 66d5be6a1ff3..d646df8b04cb 100644
> > > --- a/common/memsize.c
> > > +++ b/common/memsize.c
> > > @@ -7,9 +7,18 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > >
> > > DECLARE_GLOBAL_DATA_PTR;
> > >
> > > +#ifdef CONFIG_SYS_CACHELINE_SIZE
> > > +# define MEMSIZE_CACHELINE_SIZE CONFIG_SYS_CACHELINE_SIZE
> > > +#else
> > > +/* Just use the greatest cache flush alignment requirement I'm aware of
> > > */
> > > +# define MEMSIZE_CACHELINE_SIZE 128
> > > +#endif
> > > +
> > > #ifdef __PPC__
> > > /*
> > > * At least on G2 PowerPC cores, sequential accesses to non-existent
> > > @@ -20,6 +29,15 @@ DECLARE_GLOBAL_DATA_PTR;
> > > # define sync()/* nothing */
> > > #endif
> > >
> > > +static void dcache_flush_invalidate(volatile long *p)
> > > +{
> > > + uintptr_t start, stop;
> > > + start = ALIGN_DOWN((uintptr_t)p, MEMSIZE_CACHELINE_SIZE);
> > > + stop = start + MEMSIZE_CACHELINE_SIZE;
> > > + flush_dcache_range(start, stop);
> > > + invalidate_dcache_range(start, stop);
> > > +}
> > > +
> > > /*
> > > * Check memory range for valid RAM. A simple memory test determines
> > > * the actually available RAM size between addresses `base' and
> > > @@ -34,6 +52,7 @@ long get_ram_size(long *base, long maxsize)
> > > long val;
> > > long size;
> > > inti = 0;
> > > + intdcache_en = dcache_status();
> > >
> > > for (cnt = (maxsize / sizeof(long)) >> 1; cnt > 0; cnt >>= 1) {
> > > addr = base + cnt; /* pointer arith! */
> > > @@ -41,6 +60,8 @@ long get_ram_size(long *base, long maxsize)
> > > save[i++] = *addr;
> > > sync();
> > > *addr = ~cnt;
> > > + if (dcache_en)
> > > + dcache_flush_invalidate(addr);
> >
> > Why this should be done on every increment if the invalidate keep a
> > range of address?
>
> We do invalidate/flush the current write, the granularity of the
> flush/invalidate is the page size.
>
> This is required since we need to ensure ordering of the writes. How
> would you know where the aliasing is going to happen if you flush all at
> once at the end?
>
I see, I read the code properly of get_mem_size now.
> > Can be possible just to enable/disable cache around memory test?
> In theory yes. In practice this proved some architecture to just crash
> badly because the stack was "corrupted" after re-enabling the cache.
>
> We'll submit a separate bug fix for that, bug given that this pattern
> (disable AND enable) is normally not done in U-Boot it seems like
> looking for trouble doing it in such a commonly used routine.
>
Thank you
Re: [PATCH v2 2/2] common/memsize.c: Fix get_ram_size() when cache is enabled
Hi
Few questions
On Tue, May 30, 2023 at 3:34 PM Francesco Dolcini wrote:
>
> From: Emanuele Ghidoli
>
> Ensure that every write is flushed to memory and afterward reads are
> from memory.
> Since the algorithm rely on the fact that accessing to not existent
> memory lead to write at addr / 2 without this modification accesses
> to aliased (not physically present) addresses are cached and
> wrong size is returned.
>
> This was discovered while working on a TI AM625 based board
> where cache is normally enabled, see commit c02712a74849 ("arm: mach-k3:
> Enable dcache in SPL").
>
> Signed-off-by: Emanuele Ghidoli
> Signed-off-by: Francesco Dolcini
> ---
> v2:
> * check if CONFIG_SYS_CACHELINE_SIZE is defined
> * do flush only when cache is enabled
> ---
> common/memsize.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/common/memsize.c b/common/memsize.c
> index 66d5be6a1ff3..d646df8b04cb 100644
> --- a/common/memsize.c
> +++ b/common/memsize.c
> @@ -7,9 +7,18 @@
> #include
> #include
> #include
> +#include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#ifdef CONFIG_SYS_CACHELINE_SIZE
> +# define MEMSIZE_CACHELINE_SIZE CONFIG_SYS_CACHELINE_SIZE
> +#else
> +/* Just use the greatest cache flush alignment requirement I'm aware of */
> +# define MEMSIZE_CACHELINE_SIZE 128
> +#endif
> +
> #ifdef __PPC__
> /*
> * At least on G2 PowerPC cores, sequential accesses to non-existent
> @@ -20,6 +29,15 @@ DECLARE_GLOBAL_DATA_PTR;
> # define sync()/* nothing */
> #endif
>
> +static void dcache_flush_invalidate(volatile long *p)
> +{
> + uintptr_t start, stop;
> + start = ALIGN_DOWN((uintptr_t)p, MEMSIZE_CACHELINE_SIZE);
> + stop = start + MEMSIZE_CACHELINE_SIZE;
> + flush_dcache_range(start, stop);
> + invalidate_dcache_range(start, stop);
> +}
> +
> /*
> * Check memory range for valid RAM. A simple memory test determines
> * the actually available RAM size between addresses `base' and
> @@ -34,6 +52,7 @@ long get_ram_size(long *base, long maxsize)
> long val;
> long size;
> inti = 0;
> + intdcache_en = dcache_status();
>
> for (cnt = (maxsize / sizeof(long)) >> 1; cnt > 0; cnt >>= 1) {
> addr = base + cnt; /* pointer arith! */
> @@ -41,6 +60,8 @@ long get_ram_size(long *base, long maxsize)
> save[i++] = *addr;
> sync();
> *addr = ~cnt;
> + if (dcache_en)
> + dcache_flush_invalidate(addr);
Why this should be done on every increment if the invalidate keep a
range of address?
> }
>
> addr = base;
> @@ -50,6 +71,9 @@ long get_ram_size(long *base, long maxsize)
> *addr = 0;
>
> sync();
> + if (dcache_en)
> + dcache_flush_invalidate(addr);
> +
> if ((val = *addr) != 0) {
> /* Restore the original data before leaving the function. */
> sync();
Can be possible just to enable/disable cache around memory test?
Michael
> --
> 2.25.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation
Hi Il lun 15 mag 2023, 23:12 Tom Rini 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 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? > > 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. Michael > > -- > Tom >
Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation
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 Michael > > Mikhail Kshevetskiy > > On 18.04.2023 16:48, Michael Nazzareno Trimarchi wrote: > > [External email] > > > > > > > > > > > > Hi Frieder > > > > On Tue, Apr 18, 2023 at 3:46 PM 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? > >> > >> Thanks > >> Frieder > > Yes, waiting for Jagan, please way 1 day more > > > > Michael -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation
Hi Frieder On Tue, Apr 18, 2023 at 3:46 PM 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? > > Thanks > Frieder Yes, waiting for Jagan, please way 1 day more Michael
Re: [PATCH v2 6/6] mtd: nand: sunxi: Pass the device to the init function
On Fri, Apr 14, 2023 at 12:23 PM Andre Przywara wrote:
>
> On Sun, 22 Jan 2023 16:06:36 -0600
> Samuel Holland wrote:
>
> > This more closely matches the U-Boot driver to the Linux version.
> >
> > Signed-off-by: Samuel Holland
>
> Reviewed-by: Andre Przywara
>
> Thanks!
> Andre
>
> > ---
> >
> > (no changes since v1)
> >
> > drivers/mtd/nand/raw/sunxi_nand.c | 39 ---
> > 1 file changed, 20 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/sunxi_nand.c
> > b/drivers/mtd/nand/raw/sunxi_nand.c
> > index dda51a39b0..c0fa1e310c 100644
> > --- a/drivers/mtd/nand/raw/sunxi_nand.c
> > +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> > @@ -1604,7 +1604,8 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd,
> > struct nand_ecc_ctrl *ecc)
> > return 0;
> > }
> >
> > -static int sunxi_nand_chip_init(ofnode np, struct sunxi_nfc *nfc, int
> > devnum)
> > +static int sunxi_nand_chip_init(struct udevice *dev, struct sunxi_nfc *nfc,
> > + ofnode np, int devnum)
> > {
> > const struct nand_sdr_timings *timings;
> > struct sunxi_nand_chip *chip;
> > @@ -1620,7 +1621,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> >
> > nsels /= sizeof(u32);
> > if (!nsels || nsels > 8) {
> > - dev_err(nfc->dev, "invalid reg property size\n");
> > + dev_err(dev, "invalid reg property size\n");
> > return -EINVAL;
> > }
> >
> > @@ -1628,7 +1629,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > (nsels * sizeof(struct sunxi_nand_chip_sel)),
> > GFP_KERNEL);
> > if (!chip) {
> > - dev_err(nfc->dev, "could not allocate chip\n");
> > + dev_err(dev, "could not allocate chip\n");
> > return -ENOMEM;
> > }
> >
> > @@ -1638,19 +1639,19 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > for (i = 0; i < nsels; i++) {
> > ret = ofnode_read_u32_index(np, "reg", i, );
> > if (ret) {
> > - dev_err(nfc->dev, "could not retrieve reg property:
> > %d\n",
> > + dev_err(dev, "could not retrieve reg property: %d\n",
> > ret);
> > return ret;
> > }
> >
> > if (tmp > NFC_MAX_CS) {
> > - dev_err(nfc->dev,
> > + dev_err(dev,
> > "invalid reg value: %u (max CS = 7)\n", tmp);
> > return -EINVAL;
> > }
> >
> > if (test_and_set_bit(tmp, >assigned_cs)) {
> > - dev_err(nfc->dev, "CS %d already assigned\n", tmp);
> > + dev_err(dev, "CS %d already assigned\n", tmp);
> > return -EINVAL;
> > }
> >
> > @@ -1661,9 +1662,9 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > chip->sels[i].rb.type = RB_NATIVE;
> > chip->sels[i].rb.info.nativeid = tmp;
> > } else {
> > - ret = gpio_request_by_name_nodev(np, "rb-gpios", i,
> > -
> > >sels[i].rb.info.gpio,
> > - GPIOD_IS_IN);
> > + ret = gpio_request_by_name(dev, "rb-gpios", i,
> > +
> > >sels[i].rb.info.gpio,
> > +GPIOD_IS_IN);
> > if (ret)
> > chip->sels[i].rb.type = RB_GPIO;
> > else
> > @@ -1674,7 +1675,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > timings = onfi_async_timing_mode_to_sdr_timings(0);
> > if (IS_ERR(timings)) {
> > ret = PTR_ERR(timings);
> > - dev_err(nfc->dev,
> > + dev_err(dev,
> > "could not retrieve timings for ONFI mode 0: %d\n",
> > ret);
> > return ret;
> > @@ -1682,7 +1683,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> >
> > ret = sunxi_nand_chip_set_timings(nfc, chip, timings);
> > if (ret) {
> > - dev_err(nfc->dev, "could not configure chip timings: %d\n",
> > ret);
> > + dev_err(dev, "could not configure chip timings: %d\n", ret);
> > return ret;
> > }
> >
> > @@ -1717,25 +1718,25 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> >
> > ret = sunxi_nand_chip_init_timings(nfc, chip);
> > if (ret) {
> > - dev_err(nfc->dev, "could not configure chip timings: %d\n",
> > ret);
> >
Re: [PATCH] nand: raw: octeontx: Make list static
Hi
On Wed, Apr 5, 2023 at 4:38 PM Bin Meng wrote:
>
> octeontx_bch_devices and octeontx_pci_nand_deferred_devices are only
> referenced in the files where they are defined. Make them static.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/mtd/nand/raw/octeontx_bch.c | 2 +-
> drivers/mtd/nand/raw/octeontx_nand.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/octeontx_bch.c
> b/drivers/mtd/nand/raw/octeontx_bch.c
> index fc16b77416..056a685782 100644
> --- a/drivers/mtd/nand/raw/octeontx_bch.c
> +++ b/drivers/mtd/nand/raw/octeontx_bch.c
> @@ -27,7 +27,7 @@
> #include
> #include "octeontx_bch.h"
>
> -LIST_HEAD(octeontx_bch_devices);
> +static LIST_HEAD(octeontx_bch_devices);
> static unsigned int num_vfs = BCH_NR_VF;
> static void *bch_pf;
> static void *bch_vf;
> diff --git a/drivers/mtd/nand/raw/octeontx_nand.c
> b/drivers/mtd/nand/raw/octeontx_nand.c
> index 1ffadad9ca..65a03d22c1 100644
> --- a/drivers/mtd/nand/raw/octeontx_nand.c
> +++ b/drivers/mtd/nand/raw/octeontx_nand.c
> @@ -354,7 +354,7 @@ struct octeontx_probe_device {
>
> static struct bch_vf *bch_vf;
> /** Deferred devices due to BCH not being ready */
> -LIST_HEAD(octeontx_pci_nand_deferred_devices);
> +static LIST_HEAD(octeontx_pci_nand_deferred_devices);
>
> /** default parameters used for probing chips */
> #define MAX_ONFI_MODE 5
> --
Acked-by: Michael Trimarchi
Michael
> 2.34.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: i.MX8MP SPL failures due to memory corruption/overflow?
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 Michael > 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 -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH v7 01/23] mtd: nand: raw: rockchip_nfc: use dev_read_addr_ptr
Hi John
On Fri, Mar 10, 2023 at 5:40 PM Johan Jonker wrote:
>
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expext 64-bit data from the device tree parser,
> so use dev_read_addr_ptr in the rockchip_nfc.c file.
>
> Signed-off-by: Johan Jonker
> Reviewed-by: Michael Trimarchi
> ---
>
> Changed V6:
> use -EINVAL on return
> ---
> drivers/mtd/nand/raw/rockchip_nfc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c
> b/drivers/mtd/nand/raw/rockchip_nfc.c
> index d016d255..9f424a25 100644
> --- a/drivers/mtd/nand/raw/rockchip_nfc.c
> +++ b/drivers/mtd/nand/raw/rockchip_nfc.c
> @@ -1180,9 +1180,9 @@ static int rk_nfc_probe(struct udevice *dev)
> nfc->cfg = (void *)dev_get_driver_data(dev);
> nfc->dev = dev;
>
> - nfc->regs = (void *)dev_read_addr(dev);
> - if (IS_ERR(nfc->regs)) {
> - ret = PTR_ERR(nfc->regs);
> + nfc->regs = dev_read_addr_ptr(dev);
> + if (!nfc->regs) {
> + ret = -EINVAL;
> goto release_nfc;
> }
>
> --
> 2.20.1
>
Patches will be queued for nand as soon as you get the review on
change of dts part
Michael
Re: [PATCH v6 06/22] mtd: nand: add support for the Sandisk SDTNQGAMA chip
On Fri, Mar 3, 2023 at 1:13 AM Johan Jonker wrote:
>
> Sandisk SDTNQGAMA is a 8GB size, 3.3V 8 bit chip with 16KB page size,
> 1KB write size and 40 bit ecc support
>
> Signed-off-by: Paweł Jarosz
> Signed-off-by: Johan Jonker
> Reviewed-by: Kever Yang
> ---
> drivers/mtd/nand/raw/nand_ids.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
> index d0cfacc6..22ea5e2f 100644
> --- a/drivers/mtd/nand/raw/nand_ids.c
> +++ b/drivers/mtd/nand/raw/nand_ids.c
> @@ -48,6 +48,9 @@ struct nand_flash_dev nand_flash_ids[] = {
> {"TC58NVG6D2 64G 3.3V 8-bit",
> { .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
> SZ_8K, SZ_8K, SZ_2M, 0, 8, 640, NAND_ECC_INFO(40, SZ_1K) },
> + {"SDTNQGAMA 64G 3.3V 8-bit",
> + { .id = {0x45, 0xde, 0x94, 0x93, 0x76, 0x57} },
> + SZ_16K, SZ_8K, SZ_4M, 0, 6, 1280, NAND_ECC_INFO(40, SZ_1K)
> },
> {"SDTNRGAMA 64G 3.3V 8-bit",
> { .id = {0x45, 0xde, 0x94, 0x93, 0x76, 0x50} },
> SZ_16K, SZ_8K, SZ_4M, 0, 6, 1280, NAND_ECC_INFO(40, SZ_1K)
> },
> --
> 2.20.1
>
Acked-by: Michael Trimarchi
Re: [PATCH v2] mtd: rawnand: nand_base: Handle algorithm selection
Hi
On Wed, Mar 8, 2023 at 10:29 PM Linus Walleij wrote:
>
> For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the
> D-Link DIR-885L and DIR-890L routers, we need to explicitly
> select the ECC like this in the device tree:
>
> nand-ecc-algo = "bch";
> nand-ecc-strength = <1>;
> nand-ecc-step-size = <512>;
>
> This is handled by the Linux kernel but U-Boot core does
> not respect this. Fix it up by parsing the algorithm and
> preserve the behaviour using this property to select
> software BCH as far as possible.
>
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - Drop pointless check for ecc_algo >= 0, it is always
> >= 0.
> ---
> drivers/mtd/nand/raw/nand_base.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 9eba360d55f3..c173fd09237a 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4487,6 +4487,7 @@ EXPORT_SYMBOL(nand_detect);
> static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, ofnode
> node)
> {
> int ret, ecc_mode = -1, ecc_strength, ecc_step;
> + int ecc_algo = NAND_ECC_UNKNOWN;
> const char *str;
>
> ret = ofnode_read_s32_default(node, "nand-bus-width", -1);
> @@ -4512,10 +4513,13 @@ static int nand_dt_init(struct mtd_info *mtd, struct
> nand_chip *chip, ofnode nod
> ecc_mode = NAND_ECC_SOFT_BCH;
> }
>
> - if (ecc_mode == NAND_ECC_SOFT) {
> - str = ofnode_read_string(node, "nand-ecc-algo");
> - if (str && !strcmp(str, "bch"))
> + str = ofnode_read_string(node, "nand-ecc-algo");
> + if (str && !strcmp(str, "bch")) {
> + ecc_algo = NAND_ECC_BCH;
> + if (ecc_mode == NAND_ECC_SOFT)
> ecc_mode = NAND_ECC_SOFT_BCH;
> + } else if (!strcmp(str, "hamming")) {
> + ecc_algo = NAND_ECC_HAMMING;
> }
>
> ecc_strength = ofnode_read_s32_default(node,
> @@ -4529,6 +4533,8 @@ static int nand_dt_init(struct mtd_info *mtd, struct
> nand_chip *chip, ofnode nod
> return -EINVAL;
> }
>
> + chip->ecc.algo = ecc_algo;
> +
> if (ecc_mode >= 0)
> chip->ecc.mode = ecc_mode;
>
> --
> 2.39.1
>
Reviewed-by: Michael Trimarchi
Michael
Re: [PATCH] nand: brcmnand: add iproc support
Hi
On Sun, Jan 22, 2023 at 12:45 AM Linus Walleij wrote:
>
> Add support for the iproc Broadcom NAND controller,
> used in Northstar SoCs for example. Based on the Linux
> driver.
>
> Cc: Philippe Reynes
> Signed-off-by: Linus Walleij
> ---
> drivers/mtd/nand/raw/Kconfig | 7 +
> drivers/mtd/nand/raw/brcmnand/Makefile | 1 +
> drivers/mtd/nand/raw/brcmnand/iproc_nand.c | 141 +
> 3 files changed, 149 insertions(+)
> create mode 100644 drivers/mtd/nand/raw/brcmnand/iproc_nand.c
>
> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> index 5b35da45f584..6a13bc1e228a 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -156,6 +156,13 @@ config NAND_BRCMNAND_63158
> help
> Enable support for broadcom nand driver on bcm63158.
>
> +config NAND_BRCMNAND_IPROC
> + bool "Support Broadcom NAND controller on the iproc family"
> + depends on NAND_BRCMNAND
> + help
> + Enable support for broadcom nand driver on the Broadcom
> + iproc family such as Northstar (BCM5301x, BCM4708...)
> +
> config NAND_DAVINCI
> bool "Support TI Davinci NAND controller"
> select SYS_NAND_SELF_INIT if TARGET_DA850EVM
> diff --git a/drivers/mtd/nand/raw/brcmnand/Makefile
> b/drivers/mtd/nand/raw/brcmnand/Makefile
> index f46a7edae321..0c6325aaa618 100644
> --- a/drivers/mtd/nand/raw/brcmnand/Makefile
> +++ b/drivers/mtd/nand/raw/brcmnand/Makefile
> @@ -6,5 +6,6 @@ obj-$(CONFIG_NAND_BRCMNAND_6753) += bcm6753_nand.o
> obj-$(CONFIG_NAND_BRCMNAND_68360) += bcm68360_nand.o
> obj-$(CONFIG_NAND_BRCMNAND_6838) += bcm6838_nand.o
> obj-$(CONFIG_NAND_BRCMNAND_6858) += bcm6858_nand.o
> +obj-$(CONFIG_NAND_BRCMNAND_IPROC) += iproc_nand.o
> obj-$(CONFIG_NAND_BRCMNAND) += brcmnand.o
> obj-$(CONFIG_NAND_BRCMNAND) += brcmnand_compat.o
> diff --git a/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
> b/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
> new file mode 100644
> index ..c61a120b6d27
> --- /dev/null
> +++ b/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Code borrowed from the Linux driver
> + * Copyright (C) 2015 Broadcom Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "brcmnand.h"
> +
> +struct iproc_nand_soc {
> + struct brcmnand_soc soc;
> + void __iomem *idm_base;
> + void __iomem *ext_base;
> +};
> +
> +#define IPROC_NAND_CTLR_READY_OFFSET 0x10
> +#define IPROC_NAND_CTLR_READY BIT(0)
> +
> +#define IPROC_NAND_IO_CTRL_OFFSET 0x00
> +#define IPROC_NAND_APB_LE_MODE BIT(24)
> +#define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
> +
> +static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)
> +{
> + struct iproc_nand_soc *priv =
> + container_of(soc, struct iproc_nand_soc, soc);
> + void __iomem *mmio = priv->ext_base + IPROC_NAND_CTLR_READY_OFFSET;
> + u32 val = brcmnand_readl(mmio);
> +
> + if (val & IPROC_NAND_CTLR_READY) {
> + brcmnand_writel(IPROC_NAND_CTLR_READY, mmio);
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void iproc_nand_intc_set(struct brcmnand_soc *soc, bool en)
> +{
> + struct iproc_nand_soc *priv =
> + container_of(soc, struct iproc_nand_soc, soc);
> + void __iomem *mmio = priv->idm_base + IPROC_NAND_IO_CTRL_OFFSET;
> + u32 val = brcmnand_readl(mmio);
> +
> + if (en)
> + val |= IPROC_NAND_INT_CTRL_READ_ENABLE;
> + else
> + val &= ~IPROC_NAND_INT_CTRL_READ_ENABLE;
> +
> + brcmnand_writel(val, mmio);
> +}
> +
> +static void iproc_nand_apb_access(struct brcmnand_soc *soc, bool prepare,
> + bool is_param)
> +{
> + struct iproc_nand_soc *priv =
> + container_of(soc, struct iproc_nand_soc, soc);
> + void __iomem *mmio = priv->idm_base + IPROC_NAND_IO_CTRL_OFFSET;
> + u32 val;
> +
> + val = brcmnand_readl(mmio);
> +
> + /*
> +* In the case of BE or when dealing with NAND data, always configure
> +* the APB bus to LE mode before accessing the FIFO and back to BE
> mode
> +* after the access is done
> +*/
> + if (IS_ENABLED(CONFIG_SYS_BIG_ENDIAN) || !is_param) {
> + if (prepare)
> + val |= IPROC_NAND_APB_LE_MODE;
> + else
> + val &= ~IPROC_NAND_APB_LE_MODE;
> + } else { /* when in LE accessing the parameter page, keep APB in BE */
> + val &= ~IPROC_NAND_APB_LE_MODE;
> + }
> +
> + brcmnand_writel(val, mmio);
> +}
> +
> +static int iproc_nand_probe(struct udevice *dev)
> +{
> + struct udevice *pdev = dev;
> + struct
Re: [PATCH] mtd: rawnand: nand_base: Handle algorithm selection
Hi Linus
On Sun, Jan 22, 2023 at 12:44 AM Linus Walleij
wrote:
> For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the
> D-Link DIR-885L and DIR-890L routers, we need to explicitly
> select the ECC like this in the device tree:
>
> nand-ecc-algo = "bch";
> nand-ecc-strength = <1>;
> nand-ecc-step-size = <512>;
>
> This is handled by the Linux kernel but U-Boot core does
> not respect this. Fix it up by parsing the algorithm and
> preserve the behaviour using this property to select
> software BCH as far as possible.
>
> Signed-off-by: Linus Walleij
> ---
> drivers/mtd/nand/raw/nand_base.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 9eba360d55f3..872b58ec5f23 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4487,6 +4487,7 @@ EXPORT_SYMBOL(nand_detect);
> static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip,
> ofnode node)
> {
> int ret, ecc_mode = -1, ecc_strength, ecc_step;
> + int ecc_algo = NAND_ECC_UNKNOWN;
> const char *str;
>
> ret = ofnode_read_s32_default(node, "nand-bus-width", -1);
> @@ -4512,10 +4513,13 @@ static int nand_dt_init(struct mtd_info *mtd,
> struct nand_chip *chip, ofnode nod
> ecc_mode = NAND_ECC_SOFT_BCH;
> }
>
> - if (ecc_mode == NAND_ECC_SOFT) {
> - str = ofnode_read_string(node, "nand-ecc-algo");
> - if (str && !strcmp(str, "bch"))
> + str = ofnode_read_string(node, "nand-ecc-algo");
> + if (str && !strcmp(str, "bch")) {
> + ecc_algo = NAND_ECC_BCH;
> + if (ecc_mode == NAND_ECC_SOFT)
> ecc_mode = NAND_ECC_SOFT_BCH;
> + } else if (!strcmp(str, "hamming")) {
> + ecc_algo = NAND_ECC_HAMMING;
> }
>
> ecc_strength = ofnode_read_s32_default(node,
> @@ -4529,6 +4533,9 @@ static int nand_dt_init(struct mtd_info *mtd, struct
> nand_chip *chip, ofnode nod
> return -EINVAL;
> }
>
> + if (ecc_algo >= 0)
> + chip->ecc.algo = ecc_algo;
> +
>
I don't see any path where the algo can be < 0
Michael
> if (ecc_mode >= 0)
> chip->ecc.mode = ecc_mode;
>
> --
> 2.39.0
>
>
Re: [PATCH] mtd: rawnand: nand_base: Handle algorithm selection
Hi On Wed, Mar 8, 2023 at 5:55 PM Tom Rini wrote: > On Wed, Mar 08, 2023 at 12:05:37AM +0100, Linus Walleij wrote: > > On Sun, Jan 22, 2023 at 12:43 AM Linus Walleij > wrote: > > > > > For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the > > > D-Link DIR-885L and DIR-890L routers, we need to explicitly > > > select the ECC like this in the device tree: > > > > > > nand-ecc-algo = "bch"; > > > nand-ecc-strength = <1>; > > > nand-ecc-step-size = <512>; > > > > > > This is handled by the Linux kernel but U-Boot core does > > > not respect this. Fix it up by parsing the algorithm and > > > preserve the behaviour using this property to select > > > software BCH as far as possible. > > > > > > Signed-off-by: Linus Walleij > > > > It's been 1 1/2 month, could we apply this patch? > > Can we get an ack/review from someone that chimed in earlier in the > thread with comments please? > > I was waiting from William Zhang but I will review and queue the patch Michael -- > Tom >
Re: [PATCH 0/4] Fix arasan nand driver issues
Hi On Tue, Mar 7, 2023 at 2:35 PM Michal Simek wrote: > > > On 2/24/23 06:07, Ashok Reddy Soma wrote: > > In this patch series > > - Remove hardcoding of NAND_BBT_USE_FLASH in nand->bbt_options > > - Find and update nand ofnode. > > - Fix nand node in zynqmp-zc1751-xm017-dc3.dts file > > - Enable nand-on-flash-bbt flag in zynqmp DT's by default > > > If we are not fast to pick our part, please ping us Thank you to pick them anyway Michael > > > > Ashok Reddy Soma (4): > >mtd: nand: arasan: Remove hardcoded bbt option > >mtd: nand: arasan: Set ofnode value > >arm64: dts: zynqmp: Fix nand dt node > >arm64: dts: zynqmp: Enable nand-on-flash-bbt in DT by default > > > > arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 2 + > > arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts | 119 ++- > > drivers/mtd/nand/raw/arasan_nfc.c| 5 +- > > 3 files changed, 78 insertions(+), 48 deletions(-) > > > > Applied, > M > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] mtd: spinand: Fix display of unknown raw ID
Hi
On Tue, Feb 14, 2023 at 11:52 AM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Tue, Feb 14, 2023 at 9:14 AM Frieder Schrempf
> wrote:
> >
> > 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
>
> Acked-by: Michael Trimarchi
>
Applied thanks
Michael
Re: [RFC PATCH v1 4/4] drivers: use devfdt_get_addr_index_ptr when cast to pointer
spi_priv *priv = dev_get_priv(bus); > ofnode subnode; > > - plat->regbase = (void *)devfdt_get_addr_index(bus, 0); > + plat->regbase = devfdt_get_addr_index_ptr(bus, 0); > plat->ahbbase = devfdt_get_addr_size_index_ptr(bus, 1, > >ahbsize); > plat->is_decoded_cs = dev_read_bool(bus, "cdns,is-decoded-cs"); > plat->fifo_depth = dev_read_u32_default(bus, "cdns,fifo-depth", 128); > diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb-new/ti-musb.c > index 91042935..3be3f93d 100644 > --- a/drivers/usb/musb-new/ti-musb.c > +++ b/drivers/usb/musb-new/ti-musb.c > @@ -88,7 +88,7 @@ static int ti_musb_of_to_plat(struct udevice *dev) > int usb_index; > struct musb_hdrc_config *musb_config; > > - plat->base = (void *)devfdt_get_addr_index(dev, 1); > + plat->base = devfdt_get_addr_index_ptr(dev, 1); > > phys = fdtdec_lookup_phandle(fdt, node, "phys"); > ctrl_mod = fdtdec_lookup_phandle(fdt, phys, "ti,ctrl_mod"); > -- > 2.20.1 > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
