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
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to