On Fri, 23 Aug 2013, Andreas Bießmann wrote:

Dear Robert P. J. Day,

On 08/23/2013 02:25 PM, Robert P. J. Day wrote:

<snip>

...

so it's clearly there, but i have no idea what i'd put in /etc/fw_env.config to refer to that partition.

i tried adding the simple line:

/dev/mmcblk1boot1 0x0 0x4000

to (allegedly) represent a block device, but i got the error:

# fw_printenv Cannot access MTD device /dev/mmcblk1boot: No such file or directory #

I think you stumble over this:

---8<--- abiessmann@punisher % grep -C 4 'struct envdev_s' tools/env/fw_env.c typeof(y) _min2 = (y); \ (void) (&_min1 == &_min2); \ _min1 < _min2 ? _min1 : _min2; })

struct envdev_s { char devname[16]; /* Device name */ ulong devoff; /* Device offset */ ulong env_size; /* environment size */ ulong erase_size; /* device erase size */ ulong env_sectors; /* number of environment sectors */ uint8_t mtd_type; /* type of the MTD device */ }; --->8---

An device name can only have 16 char by this declaration ;)

good lord, you're right, that explains why the last character of the device file was getting mysteriously dropped. :-( so as a quick hack, i just did a "mknod" (i suspect a symlink would have worked just as well) to invent a shorter name, "/dev/mmcboot1", and got (predictably):

# fw_printenv Cannot get MTD information: Invalid argument #

which leads me into stefano's response which i just saw.

rday

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

On Fri, 23 Aug 2013, Luka Perkov wrote:

On Fri, Aug 23, 2013 at 08:25:07AM -0400, Robert P. J. Day wrote:

...

i'm sure there's a simple answer to this -- 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?

I have put this in OpenWrt:

https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/11... https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/11...

With those two you will be able to use fw_{printenv,setenv} on MMC devices.

and how would you specify the partition in the /etc/fw_env.config file?

rday

On Fri, Aug 23, 2013 at 05:11:01PM -0400, Robert P. J. Day wrote:

On Fri, 23 Aug 2013, Luka Perkov wrote:

...

On Fri, Aug 23, 2013 at 08:25:07AM -0400, Robert P. J. Day wrote:

...

i'm sure there's a simple answer to this -- 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?

I have put this in OpenWrt:

https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/11... https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/11...

With those two you will be able to use fw_{printenv,setenv} on MMC devices.

i'll get a chance to test the above this weekend, but i just want to make absolutely sure we're talking about the same thing. are you saying that with the above patches, the u-boot-tools will be able to manipulate an eMMC HW partition just as easily as a regular MTD partition?

Yes.

and, if so, what is the format of the entry one would add to /etc/fw_env.config to refer to that eMMC HW partition (in this case, boot1)?

I have done this for imx6 wandboard in OpenWrt:

https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/files/imx6

So example config would look like:

/dev/mmcblk0 0x60000 0x2000 0x2000

Luka

On Sat, Aug 24, 2013 at 12:01:25AM -0400, Robert P. J. Day wrote:

On Sat, 24 Aug 2013, Luka Perkov wrote:

...

/dev/mmcblk0 0x60000 0x2000 0x2000

ah, there's the misunderstanding. i thought we were discussing how to be able to refer *directly* to the eMMC partition "boot1", as in /dev/mmcblk1boot1. it looks like what you're describing would refer instead simply to /dev/mmcblk1, correct?

Even though the config is actually refering to /dev/mmcblk1 in fact it's writing/reading to /dev/mmcblk1p1 (or /dev/mmcblk1boot1) in your case. But you need to configure it properly for your MMC device.

Luka

Hi,

right, i can see that and that clarifies things for me. my *original* question was whether there was a way to set up /etc/fw_env.config to refer to the eMMC partition /dev/mmcblk1boot1 *directly*, treating it as a regular block partition and bypassing all the MTD-related processing. (perhaps stefano can weigh in and say whether that's how he understood what i was asking.)

if you instead refer to /dev/mmcblk1, as i understand it, you're just back to the standard MTD-based access, yes?

the /dev/mmcblk... devices are block devices and do not provide the MTD API of the kernel. I guess this is the cause for the error message you've seen. You could try strace to verify. And this is the problem why the patches Luka mentioned are required: they make fw_{printenv,setenv} aware of opening such block devices by-passing the MTD-specific stuff, that means simply open the file, write/read the data and close the file descriptor. Without these patches these tools assume that the file descriptor opened are MTD-based.

You can pass what ever you want via your config, so your file could look like: /dev/mmcblk1boot1 0x0 0x4000 Since the partition is somewhere placed on the eMMC device, you can also refer to the same location using /dev/mmcblk1. In the latter case you have to calculate the offset correctly to not overwrite other data (e.g. on other partitions). Using /dev/mmcblk1boot1 as "entry point" the kernel should reject write requests which go beyond the partition size.

BR, Michael

Hi Luka,

On 24/08/2013 19:33, Luka Perkov wrote:

AFAIK there is no fw_{printenv,setenv} support for MMC. Except if you use the patches I pointed out. Somebody please correct me if I'm wrong.

Because you have already done the work, do you plan to push official patches to the ML ? It is a pity if they will not be integrated in mainline.

Best regards, Stefano Babic