RE: [PATCH v4 0/6] board: siemens: clean up subfolders
Hi Tom, > -Original Message- > From: Tom Rini > Sent: Thursday, January 18, 2024 4:16 PM > To: Leto, Enrico (SI BP R ZG FW CCP) > Cc: u-boot@lists.denx.de; Sverdlin, Alexander (SI BP R ZG FW CCP) > > Subject: Re: [PATCH v4 0/6] board: siemens: clean up subfolders > > On Wed, Jan 03, 2024 at 02:31:48PM +0100, Enrico Leto wrote: > > > This serie depends on the serie: > > [PATCH 0/6] siemens,am335x: clean up the draco board family > > Is this not applied already? If not, where is it? Can you please repost it? > Yes, it's applied. I'll remove these lines. > > > > The common folder was initialially created for the common parts of > > the products based on draco-am355x board family. We have the > > product lines 'pxm2', 'rut' and the base line unfortunately named > > 'draco'! Adding the new capricorn-imx8 board family, the files > > were enhanced without cleanup. > > > > Simplify first EEPROM probe and access that implements both i2c > > with & without driver model. Use abstraction functions for this. > > > > Move all am355x specifics to a new file 'board_am335x'. > > > > Clean-up includes, config checks, maintainer. > > > > Signed-off-by: Enrico Leto > > The problem is that I see: > > > > --- > >rm: + draco-etamin > +(draco-etamin) board/siemens/draco/../common/board.c: In function > 'board_init': > +(draco-etamin) board/siemens/draco/../common/board.c:88:9: error: > implicit declaration of function 'board_nand_cs_init' [-Werror=implicit- > function-declaration] > +(draco-etamin)88 | board_nand_cs_init(); > +(draco-etamin) | ^~ > +(draco-etamin) cc1: all warnings being treated as errors > +(draco-etamin) make[2]: *** [scripts/Makefile.build:257: > +board/siemens/draco/../common/board.o] Error 1 > +(draco-etamin) make[1]: *** [Makefile:1859: board/siemens/draco] Error > +2 > +(draco-etamin) make: *** [Makefile:177: sub-make] Error 2 I'll check why I have not seen this problem by me and fix it. >aarch64: + deneb > +(deneb) WARNING 'ahab-container.img' not found, resulting binary is > +not-functional > +(deneb) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.o: in function > `factoryset_read_eeprom': > +(deneb) > board/siemens/capricorn/../common/factoryset.c:149:(.text.factoryset_read > _eeprom+0x2c): undefined reference to `siemens_ee_read_data' > +(deneb) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:177:(.text.factoryset_read > _eeprom+0xb4): undefined reference to `siemens_ee_read_data' > +(deneb) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:172:(.text.factoryset_read > _eeprom+0x264): undefined reference to `siemens_ee_read_data' > +(deneb) make[1]: *** [Makefile:1766: u-boot] Error 139 > +(deneb) make[1]: *** Deleting file 'u-boot' > +(deneb) make: *** [Makefile:177: sub-make] Error 2 >aarch64: + giedi > +(giedi) WARNING 'ahab-container.img' not found, resulting binary is > +not-functional > +(giedi) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.o: in function > `factoryset_read_eeprom': > +(giedi) > board/siemens/capricorn/../common/factoryset.c:149:(.text.factoryset_read > _eeprom+0x2c): undefined reference to `siemens_ee_read_data' > +(giedi) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:177:(.text.factoryset_read > _eeprom+0xb4): undefined reference to `siemens_ee_read_data' > +(giedi) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:172:(.text.factoryset_read > _eeprom+0x264): undefined reference to `siemens_ee_read_data' > +(giedi) make[1]: *** [Makefile:1766: u-boot] Error 139 > +(giedi) make[1]: *** Deleting file 'u-boot' > +(giedi) make: *** [Makefile:177: sub-make] Error 2 'giedi' & 'deneb' are based on imx8x board. This is another family that are not affected from this patch serie. This patch serie is not the cause of these warnings and will not resolve them. Additional info. We also have everywhere this warning since u-boot version 2020 or 2021. This doesn't affect the u-boot/SPL outputs. The complete boot container incl. 'ahab-container.img' is built separately with the mkimage tool of NXP. On first appearing of this warning we asked NXP. They didn't improve any solution. Maybe there is now a setting to remove this warning. A patch serie is planned for our imx8x boards. > > When building. > > -- > Tom Enrico
RE: [PATCH v4 0/6] board: siemens: clean up subfolders
> -Original Message- > From: Tom Rini > Sent: Thursday, January 18, 2024 4:16 PM > To: Leto, Enrico (SI BP R ZG FW CCP) > Cc: u-boot@lists.denx.de; Sverdlin, Alexander (SI BP R ZG FW CCP) > > Subject: Re: [PATCH v4 0/6] board: siemens: clean up subfolders > > On Wed, Jan 03, 2024 at 02:31:48PM +0100, Enrico Leto wrote: > > > This serie depends on the serie: > > [PATCH 0/6] siemens,am335x: clean up the draco board family > > Is this not applied already? If not, where is it? Can you please repost it? > Yes, it's applied. I'll remove these lines. > > > > The common folder was initialially created for the common parts of > > the products based on draco-am355x board family. We have the > > product lines 'pxm2', 'rut' and the base line unfortunately named > > 'draco'! Adding the new capricorn-imx8 board family, the files > > were enhanced without cleanup. > > > > Simplify first EEPROM probe and access that implements both i2c > > with & without driver model. Use abstraction functions for this. > > > > Move all am355x specifics to a new file 'board_am335x'. > > > > Clean-up includes, config checks, maintainer. > > > > Signed-off-by: Enrico Leto > > The problem is that I see: > > > > --- > >rm: + draco-etamin > +(draco-etamin) board/siemens/draco/../common/board.c: In function > 'board_init': > +(draco-etamin) board/siemens/draco/../common/board.c:88:9: error: > implicit declaration of function 'board_nand_cs_init' [-Werror=implicit- > function-declaration] > +(draco-etamin)88 | board_nand_cs_init(); > +(draco-etamin) | ^~ > +(draco-etamin) cc1: all warnings being treated as errors > +(draco-etamin) make[2]: *** [scripts/Makefile.build:257: > +board/siemens/draco/../common/board.o] Error 1 > +(draco-etamin) make[1]: *** [Makefile:1859: board/siemens/draco] Error > +2 > +(draco-etamin) make: *** [Makefile:177: sub-make] Error 2 I'll check why I have not seen this problem by me and fix it. >aarch64: + Deneb > +(deneb) WARNING 'ahab-container.img' not found, resulting binary is > +not-functional > +(deneb) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.o: in function > `factoryset_read_eeprom': > +(deneb) > board/siemens/capricorn/../common/factoryset.c:149:(.text.factoryset_read > _eeprom+0x2c): undefined reference to `siemens_ee_read_data' > +(deneb) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:177:(.text.factoryset_read > _eeprom+0xb4): undefined reference to `siemens_ee_read_data' > +(deneb) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:172:(.text.factoryset_read > _eeprom+0x264): undefined reference to `siemens_ee_read_data' > +(deneb) make[1]: *** [Makefile:1766: u-boot] Error 139 > +(deneb) make[1]: *** Deleting file 'u-boot' > +(deneb) make: *** [Makefile:177: sub-make] Error 2 >aarch64: + giedi > +(giedi) WARNING 'ahab-container.img' not found, resulting binary is > +not-functional > +(giedi) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.o: in function > `factoryset_read_eeprom': > +(giedi) > board/siemens/capricorn/../common/factoryset.c:149:(.text.factoryset_read > _eeprom+0x2c): undefined reference to `siemens_ee_read_data' > +(giedi) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:177:(.text.factoryset_read > _eeprom+0xb4): undefined reference to `siemens_ee_read_data' > +(giedi) aarch64-linux-ld.bfd: > board/siemens/capricorn/../common/factoryset.c:172:(.text.factoryset_read > _eeprom+0x264): undefined reference to `siemens_ee_read_data' > +(giedi) make[1]: *** [Makefile:1766: u-boot] Error 139 > +(giedi) make[1]: *** Deleting file 'u-boot' > +(giedi) make: *** [Makefile:177: sub-make] Error 2 'giedi' & 'deneb' are based on imx8x board. This is another family that are not affected from this patch serie. This patch serie is not the cause of these warnings and will not resolve them. Additional info. We also have everywhere this warning since u-boot version 2020 or 2021. This doesn't affect the u-boot/SPL outputs. The complete boot container incl. 'ahab-container.img' is built separately with the mkimage tool of NXP. On first appearing of this warning we asked NXP. They didn't improve any solution. Maybe there is now a setting to remove this warning. A patch serie is planned for our imx8x boards. > > When building. > > -- > Tom
RE: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
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
> > 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]);
&g
RE: [PATCH] mtd: rawnand: omap_gpmc: fix BCH8 HW based correction
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:
>
> 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
