[U-Boot] omap: Looking to dynamically setup ECC and nand settings during boot
Jon Cormier
jcormier at criticallink.com
Wed Jul 16 14:59:43 CEST 2014
Pekon,
Thanks for the response.
On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon <pekon at ti.com> wrote:
> Hi Jon,
>
>
> >From: Jon Cormier [mailto:jcormier at criticallink.com]
>
> > We have a product based on the 335x that has several different models
> where the only difference is the nand part. We would like to have a
> unified u-boot that can dynamically configure the nand's ECC, page size,
> block size, etc using a spi eeprom containing a model number. Both the UBL
> and u-boot image are stored in nand. We already do this in the kernel.
> Currently in the UBL all the nand information is setup in #defines during
> compile time which makes it hard to change at runtime. I am unsure how to
> go about changing this. Has anyone tried doing this dynamic setup?
>
> (1) For NAND device parameters (like Block-size, Page-size, data-width)
> These parameter are anyways dynamically determined by reading on chip
> ONFI page during omap_board_init(). But that's only for u-boot
> (second-stage).
> - For SPL these are still #defined based to keep the code-footprint small.
>
> Sure makes sense. Could this be an area where I could experiment to see
if adding ONFI support makes the SPL too large? Alternatively without ONFI
support could I fallback to using a nand flash table like in the kernel for
older nand parts. This could allow me to switch between a few parts after
either reading the eeprom or reading the nand part number.
>
> (2) For dynamically selection of ecc-scheme, you need to re-add
> 'nandecc' command which is kind of deprecated now. Though its
> driver side support is still present in omap_gpmc.c.
> - But again, this is not supported for SPL.
> If everyone agrees, we should add this to main NAND framework
> instead of cluttering individual board-files.
> ------------------------------------------------------------------
> File: arch/arm/cpu/armv7/omap3/board.c
>
> #if defined(CONFIG_NAND_OMAP_GPMC) & !defined(CONFIG_SPL_BUILD)
>
> /******************************************************************************
> * OMAP3 specific command to switch between NAND HW and SW ecc
>
> *****************************************************************************/
> static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char *
> const argv[])
> {
> if (argc < 2 || argc > 3)
> goto usage;
>
> if (strncmp(argv[1], "hw", 2) == 0) {
> if (argc == 2) {
> omap_nand_switch_ecc(1, 1);
> } else {
> if (strncmp(argv[2], "hamming", 7) == 0)
> omap_nand_switch_ecc(1, 1);
> else if (strncmp(argv[2], "bch8", 4) == 0)
> omap_nand_switch_ecc(1, 8);
> else
> goto usage;
> }
> } else if (strncmp(argv[1], "sw", 2) == 0) {
> omap_nand_switch_ecc(0, 0);
> } else {
> goto usage;
> }
>
> return 0;
>
> usage:
> printf ("Usage: nandecc %s\n", cmdtp->usage);
> return 1;
> }
>
> U_BOOT_CMD(
> nandecc, 3, 1, do_switch_ecc,
> "switch OMAP3 NAND ECC calculation algorithm",
> "hw [hamming|bch8] - Switch between NAND hardware 1-bit hamming
> and"
> " 8-bit BCH\n"
> " ecc calculation (second parameter may"
> " be omitted).\n"
> "nandecc sw - Switch to NAND software ecc algorithm."
> );
>
> #endif /* CONFIG_NAND_OMAP_GPMC & !CONFIG_SPL_BUILD */
> ------------------------------------------------------------------
>
> Ok I would probably just call the omap_nand_switch_ecc function directly
after determining which part was in use.
>
> (3) If you need to have generic SPL too, then you might need to try
> NANDI2C boot-mode of AM335x. (please refer AM335x TRM).
>
> According to the TRM this is to setup the ROM when it can't autodetect the
nands setup. Currently the ROM auto discovers each of the nands without
problems. Since the ROM is already setting up the gpmc and ecc for the
nand, would it be possible to setup the SPL to use the already setup
hardware as is?
>
> > We are currently based off of the 2013.10 tag but will move forward if
> needed.
> Yes, I would suggest to move to latest u-boot which has support
> for BCH16 ecc-scheme, as higher ecc-scheme work better with newer
> technology NAND and MLC NAND devices which are more prone
> to bit-flips.
>
> Thanks. We've already got BCH16 support in our u-boot. It was needed to
program the 4k page size nands so the ROM would boot them.
>
> with regards, pekon
>
> > --
> > Jonathan Cormier
> > CriticalLink
>
I noticed this commit when looking for nand changes in the latest u-boot
but I'm not sure how this actually affects the SPL nand support. And
whether it helps me move towards my goal.
(6dd3b566893a99629771e076dca1ce8db7b77dc1) mtd: Add a
CONFIG_SPL_MTD_SUPPORT for a more full NAND subsystem in SPL
--
Jonathan Cormier
CriticalLink
More information about the U-Boot
mailing list