Problems mounting ubifs from u-boot

Samuel Egli

Hi All

I’m having some problems mounting ubifs from u-boot with the “ubifsmount” command. I had some initial difficulties with creating ubi image so I don’t know if there is still something not perfectly right.

1) Image generation

I used the following parameters to generate the image on the host:

mkfs.ubifs -r /home/projects/systemone/rootfs/ -F -o ubifs.img -m 2048 -e 126976 -c 1900

ubinize -o ubi.img -m 2048 -p 128KiB -s 512 -O 2048 my_ubinize.cfg

my_ubinize.cfg looks like this:

[ubifs]

mode=ubi

image=/home/projects/systemone/oe/build/deploy/glibc/images/am335x-evm/ubifs.img

vol_id=0

vol_type=dynamic

vol_name=am335x-evm-rootfs

vol_flags=autoresize

2) Writing image to partition

On the web it looks like most of the people would write the ubi.img file with Linux to NAND. So I did the same.

For this I used the following commands on the target:

ubiformat /dev/mtd7 -f ubi.img -s 512 -O 2048

And the following commands to check if it works to mount:

ubiattach /dev/ubi_ctrl -m 7 -O 2048

mount -t ubifs ubi0:am335x-evm-rootfs /mnt/ubi/

So far, so good.

3) Mounting ubifs from u-boot to read out kernel [FAILS]

I found out that it is paramount to select in u-boot the ECC HW 2 before reading from NAND. Otherwise I get lots of ECC errors. It is important,too, to set the VID offset when selecting the ubi partition.So that's what I did:

U-boot# mtdparts default

U-boot# nandecc hw 2

U-boot# ubi part nand0,7 2048

UBI: attached mtd1 to ubi0

UBI: MTD device name: "mtd=7"

UBI: MTD device size: 248 MiB

UBI: number of good PEBs: 1988

UBI: number of bad PEBs: 0

UBI: max. allowed volumes: 128

UBI: wear-leveling threshold: 4096

UBI: number of internal volumes: 1

UBI: number of user volumes: 1

UBI: available PEBs: 0

UBI: total number of reserved PEBs: 1988

UBI: number of PEBs reserved for bad PEB handling: 19

UBI: max/mean erase counter: 9/4

U-Boot## ubifsmount am335x-evm-rootfs

Error reading superblock on volume 'ubi:am335x-evm-rootfs'!

However, as you can see, the ubifsmount doesn’t succeed.

4) Questions

I’m wondering why does it work on linux and not in u-boot. Obviously, there is some difference that I’m not aware. Some reading tells you that the superblock node contains information about eraseblock size, number of eraseblocks, etc. This makes me think that the parameters at the image generation are wrong. But I tried also some other configurations that did not work either.

I tried as well to set VID offset at 512 since the NAND flash supports subpages and, as far as I understood, it should work as well. However, in this case I had problems to mount the ubi volume from linux and nothing changed from u-boot point of view.

The other parameters seem right to me and correspond as well to what is presented on the ubifs support page.

What seems a bit strange to me is that I get two volums listed when I use “ubi info l” in u-boot:

U-Boot# ubi info l

UBI: volume information dump:

UBI: vol_id 0

UBI: reserved_pebs 1965

UBI: alignment 1

UBI: data_pad 0

UBI: vol_type 3

UBI: name_len 17

UBI: usable_leb_size 126976

UBI: used_ebs 1965

UBI: used_bytes 249507840

UBI: last_eb_bytes 126976

UBI: corrupted 0

UBI: upd_marker 0

UBI: name am335x-evm-rootfs

UBI: volume information dump:

UBI: vol_id 2147479551

UBI: reserved_pebs 2

UBI: alignment 1

UBI: data_pad 0

UBI: vol_type 3

UBI: name_len 13

UBI: usable_leb_size 126976

UBI: used_ebs 2

UBI: used_bytes 253952

UBI: last_eb_bytes 2

UBI: corrupted 0

UBI: upd_marker 0

UBI: name layout volume

Why do I get two?

I’m stuck at this point. Could it be that there something wrong with my u-boot configuration for “ubifsmount” command? I have the following defines active in my am335x_evm.h board file:

…

/* UBI Support */

#define CONFIG_CMD_MTDPARTS

#define CONFIG_MTD_PARTITIONS

#define CONFIG_MTD_DEVICE

#define CONFIG_RBTREE

#define CONFIG_LZO

#define CONFIG_CMD_UBI

#define CONFIG_CMD_UBIFS

…

Any hint is welcome!

over 12 years ago

0 Renjith Thomas over 12 years ago

Guru 31670 points

Samuel,

I have debugged NAND driver in kernel to support UBIFS. I've not tried u-boot + UBIFS. Why do you need to use filesystem for storing kernel image, rather you can use raw partition and copy it using "nand read" command itself? Are you looking for upgrade support using UBIFS?

0 Samuel Egli over 12 years ago in reply to Renjith Thomas

Intellectual 370 points

Hi Renjith

Thanks for asking. The main idea is to have the uImage in the rootfs. This way we reduce the amount of partitions and wearing out of NAND flash is reduced. Thus, I need to mount ubifs file system to load the kernel.

Sam

0 Renjith Thomas over 12 years ago in reply to Samuel Egli

Guru 31670 points

Sam,

I don't think wearing of NAND flash can be reduced by keeping uImage in rootfs. Wearing occurs when you perform more erase/write cycles. I don't think read will affect NAND wearing. If you keep uImage in rootfs, you eventually end up reading more NAND pages than the size of uImage.

0 Samuel Egli over 12 years ago in reply to Renjith Thomas

Intellectual 370 points

Hi Renjith

Of course I agree that its because of erase/write cycles that NAND wears out. But wear leveling is more effective if you have big partitions because you can distribute usage of NAND block better. If I have uImage in a separate partition it will remain there and these NAND blocks will not be available to UBIFS. I think the gain is not huge but still not insignificant.

Sam

0 Renjith Thomas over 12 years ago in reply to Samuel Egli

Guru 31670 points

Sam,

I don't really think its worth taking the pain. Kernel will be at a constant location, and you'll know the approximate size also. So, you can create a partition which is just enough for storing kernel without leaving any free space. So this model will not have a significant difference in terms of wearing.

0 Samuel Egli over 12 years ago in reply to Renjith Thomas

Intellectual 370 points

Hi Renjith

Thanks for your reply. I finally found out what the problem was: Memory allocation for u-boot, defined by

CONFIG_SYS_MALLOC_LEN

was to small. Ubifs looks like a greedy thing ;-)

Sam

Processors

Processors forum

Problems mounting ubifs from u-boot