ambiguity in u-boot: what exactly does "CONFIG_CMD_NAND" mean?

GoogleGroups
1

while waiting for a fresh pot of coffee, i'll ponder a bit more on
some of the untidiness i found related to deselecting NAND for the
beagle xm. not so much looking for a solution as thinking out loud.

  in my earlier experiment, simply undefining the symbol
CONFIG_CMD_NAND didn't deselect all NAND functionality. for example,
i got in trouble here in the source 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)
                goto usage;
        if (strncmp(argv[1], "hw", 2) == 0)
                omap_nand_switch_ecc(1);
        else if (strncmp(argv[1], "sw", 2) == 0)
                omap_nand_switch_ecc(0);
        else
                goto usage;

        return 0;

usage:
        printf ("Usage: nandecc %s\n", cmdtp->usage);
        return 1;
}

  the problem is that, even though CONFIG_CMD_NAND was undefined, the
symbol CONFIG_NAND_OMAP_GPMC is defined independently in the config
file include/configs/omap3_beagle.h:

/*
* Board NAND Info.
*/
#define CONFIG_SYS_NAND_QUIET_TEST 1
#define CONFIG_NAND_OMAP_GPMC
... and so on ...

so the build attempts to compile a routine which itself no longer
exists (omap_nand_switch_ecc) because of a lack of proper dependencies
between those symbols.

  one solution would be to properly surround chunks in the
omap3_beagle.h file with, for example:

#ifdef CONFIG_CMD_NAND
... all NAND-related stuff ...
#endif

that would certainly clean up *some* of the mess.

  a second issue is what something like "CONFIG_CMD_NAND" even
*means*. in the top-level README file, there is:

    CONFIG_CMD_NAND * NAND support

well, no, that's not what that means at all. there's a real
difference in whether a feature is *supported* in u-boot, and whether
you're selecting to build in its *command*. theoretically, i might
not need command-line access to the "nand" subsystem, but i might
still need access to it *programatically* from other parts of u-boot.

  i'd never actually noticed this before, and i'm sure i'm not the
first person who's tripped over this. does this make sense?
thoughts?

rday

2

It makes some sense.

Why would you want programmatic access to NAND if you don't want the
NAND commands? I'd assume you'd not want either if you have a board
without NAND (aka: all am335x_evm / beaglebone as of 2012.10 u-boot).
If you have NAND on board, I'd assume you want both programmatic and
commands access to it.

Sounds like you're finding some fun things to fix :slight_smile:

-Andrew

3

... snip ...

Why would you want programmatic access to NAND if you don't want the
NAND commands? I'd assume you'd not want either if you have a board
without NAND (aka: all am335x_evm / beaglebone as of 2012.10
u-boot). If you have NAND on board, I'd assume you want both
programmatic and commands access to it.

  i was admittedly speaking hypothetically, but it's entirely possible
that you want to build a version of u-boot for a client that doesn't
allow him/her certain commands, but still has the underlying
functionality for proper operation of other parts of the system.

  anyway, i'll keep poking around and maybe submit a patch at some
point. it's certainly been a learning experience so far.

rday