[U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?

Robert P. J. Day rpjday at crashcourse.ca
Fri Aug 23 15:25:11 CEST 2013


On Fri, 23 Aug 2013, Stefano Babic wrote:

> Hi Robert,
>
> On 23/08/2013 14:25, Robert P. J. Day wrote:
> >
> >   i'm sure there's a simple answer to this
>
> There is
>
> >-- i built u-boot for my
> > beaglebone black using the "am335x_boneblack" config, which
> > supports saving env info to the eMMC HW partition boot1. but now
> > that it's there, is there a way i can manipulate that info with
> > fw_printenv and fw_setenv?
>
> Check in code - fw_printenv / fw_setenv are supposed to work with a
> MTD device, and the MMC is not. There are some additional checks and
> handling of NOR and NAND devices is done differently. But there is
> no code for MMC.

  yup, i can see that.  the tools i was using were an earlier version
selected by my OE build, where the code in fw_env.c was:

static int flash_read (int fd)
{
        struct mtd_info_user mtdinfo;
        int rc;

        rc = ioctl (fd, MEMGETINFO, &mtdinfo);
        if (rc < 0) {
                perror ("Cannot get MTD information"); <-- where it was failing
                return -1;
        }

        if (mtdinfo.type != MTD_NORFLASH &&
            mtdinfo.type != MTD_NANDFLASH &&
            mtdinfo.type != MTD_DATAFLASH) {
                fprintf (stderr, "Unsupported flash type %u\n", mtdinfo.type);
                return -1;
        }
        ... snip ...

i can see, in the current repo, that's been refined to distinguish
between block and character device files:

static int flash_read (int fd)
{
        struct mtd_info_user mtdinfo;
        struct stat st;
        int rc;

        rc = fstat(fd, &st);
        if (rc < 0) {
                fprintf(stderr, "Cannot stat the file %s\n",
                        DEVNAME(dev_current));
                return -1;
        }

        if (S_ISCHR(st.st_mode)) {
                rc = ioctl(fd, MEMGETINFO, &mtdinfo);
                if (rc < 0) {
                        fprintf(stderr, "Cannot get MTD information for %s\n",
                                DEVNAME(dev_current));
                        return -1;
                }
                if (mtdinfo.type != MTD_NORFLASH &&
                    mtdinfo.type != MTD_NANDFLASH &&
                    mtdinfo.type != MTD_DATAFLASH &&
                    mtdinfo.type != MTD_UBIVOLUME) {
                        fprintf (stderr, "Unsupported flash type %u on %s\n",
                                 mtdinfo.type, DEVNAME(dev_current));
                        return -1;
                }
        } else {
                memset(&mtdinfo, 0, sizeof(mtdinfo));
                mtdinfo.type = MTD_ABSENT;
        }
        ... snip ...

which, as you point out, still doesn't solve the problem.

> However, managing MMC is easier: no need of erasing flash, simply
> write into the device computing the CRC. You could add the required
> functions to rwad / write a buffer from MMC to fw_printenv (and
> posting here the patch, thanks !).

  as i read it (and i could be totally wrong here), all that needs to
be added is a way to specify to the fw_* tools that a given (block)
partition has nothing to do with flash, and that it should be treated
as pure data, bypassing any flash-related processing as you say.

  i'm assuming that this would require deciding how to specify this in
/etc/fw_env.config so the tools understand what's happening. thoughts
on that? the line will look like:

/dev/mmcblk1boot1  ... and what goes here? ...

to identify this as a non-MTD partition?

  and i guess that 16-character filename limit needs to be adjusted as
well, yes?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================


More information about the U-Boot mailing list