Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.

Hello Konstantyn,

Am 21.01.2015 15:57, schrieb Konstantyn Prokopenko:

Hello Heiko,

I'll try the patch today. Thank you very much!

Did you found time for trying it? I want to prepare a pull-request for ubi, and it would be nice to have fixed your problem too ;-)

bye, Heiko

Regards, Konstantyn

-----Original Message----- From: Heiko Schocher [mailto:hs@denx.de] Sent: Wednesday, January 21, 2015 12:57 AM To: Konstantyn Prokopenko Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.

Hello Konstantyn,

Am 20.01.2015 17:09, schrieb Konstantyn Prokopenko:

...

Hello,

I'm using the latest u-boot on our custom board. The u-boot is located on the NAND flash in the first 4MB partition. I break 256MB NAND into 4 MTD partitions: u-boot(4MB), kernel(4MB), rootfs(100MB), safefs(40MB), varfs(108MB). We are using Freescale iMX6 processor (nitrogen6x BSP in u-boot). I've modified board support code to include our pad configurations and additional hardware. Also I added misc driver for our system initialization. The driver would mount rootfs UBI fs on rootfs MTD partition and validate system. If failed, it would unmounts it and mount UBI fs on safefs MTD partition and load it. The problem was with unmounting rootfs and initializing safefs partition. Here is the relevant portion of my initialization script: "echo Loading just in case, default kernel from installation partition...;" \ "nand read 10800000 400000 400000;" \ "echo Configuring NAND flash for MTD...;" \ "mtdparts default; mtdparts;" \ "echo Mounting Root filesystem;" \ "ubi part rootfs;" \ "ubifsmount ubi0:rootfs;" \ "echo Verifying if filesystem and kernel is OK...;" \ "parallax validate 1 kernel;" \ "if test ${parallax_result} = 0; then " \ "echo Reading kernel file from rootfs....;" \ "else " \ "echo ROOTFS or Rootfs Kernel appears to be BAD. Trying SAFEFS...;" \ "ubifsumount;" \ "ubi part safefs;" \ "ubifsmount ubi0:safefs;" \ "parallax validate 2 kernel;" \ "if test ${parallax_result} = 0; then " \ "echo Reading kernel file from safefs....;" \ "else " \ "echo All FILESYSTEMS are bad, booting from MTD1 kernel partition;" \ "nand read 10800000 400000 400000; bootm 10800000;" \ "fi;" \ "fi;" \ "ubifsload 10800000 kernel;" \ "ubifsumount;" \ "bootm 10800000;\0 " \

The parallax module is our own driver which is relevant to our system operations. It tests for validity currently mounted partition. Nothing fancy, just a bunch of MD5 checks. OK, I've digged into the MTD/UBI code and found the problem. When mounting the first partition, no matter which one, the mtd_dev_param[] array is populated with the MTD device parameters entry (the first mounted partition). The ubi_init() finds it first and successfully attaches it. When unmounting this partition, the mtd_dev_param[] array still includes the same entry and when attempting to mount the second partition, the array includes two mtd_dev_param enties: The first one for already unmounted MTD partition and the second for the next candidate. The ubi_init start accessing this array from ID0 and after trying to attach entry 0 errors out ignoring the second entry. I've added a temporary hack to avoid this problem. Because UBIFS can mount only a signgle partition at a time, I've introduced a global parameter: Char *device_to_attach[] which is populated when ubi_mtd_param_parse() is called. Now, in ubi_init() I check if the current entry to the mtd_dev_array matches the device to attach. Also I added check for NULL if we are out of devices. ........... /* Attach MTD devices */ for (i = 0; i < mtd_devs; i++) { struct mtd_dev_param *p = &mtd_dev_param[i]; struct mtd_info *mtd;

              if(p == NULL) {
                  printk(KERN_INFO "UBI_INIT: Could not find device: %s\n", device_to_attach);
                  err = -ENODEV;
                  goto out_slab;
              }
              if(strcmp(p->name, device_to_attach) != 0)
                      continue;

................ This is a temp hack, just to make it work for our needs. Please advice if there are better ways or maybe we can just clean the mtd_dev_param array after unmounts being called.

Can you try this patch?

http://patchwork.ozlabs.org/patch/430909/

bye, Heiko