Hi List!
I have a slight problem with UBIFS on the OpenRD base board (an ARM board very similar to sheevaplug). Loading files which have been compressed with LZO by ubifs fails:
OpenRD>> ubi part root; ubifsmount rootfs Creating 1 MTD partitions on "nand0": 0x0000001e0000-0x000020000000 : "mtd=1" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=1" UBI: MTD device size: 510 MiB UBI: number of good PEBs: 4081 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: 54 UBI: total number of reserved PEBs: 4027 UBI: number of PEBs reserved for bad PEB handling: 40 UBI: max/mean erase counter: 6/4 UBIFS: mounted UBI device 0, volume 0, name "rootfs" UBIFS: mounted read-only UBIFS: file system size: 511967232 bytes (499968 KiB, 488 MiB, 3968 LEBs) UBIFS: journal size: 25675776 bytes (25074 KiB, 24 MiB, 199 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 5182151 bytes (5060 KiB)
OpenRD>> ubifsload 0x8000000 /boot/primary/uImage Loading file '/boot/primary/uImage' to addr 0x08000000 with size 7196920 (0x006dd0f8)... UBIFS error (pid 0): ubifs_decompress: cannot decompress 3204 bytes, compressor LZO, error -6 UBIFS error (pid 0): read_block: bad data node (block 0, inode 88) UBIFS error (pid 0): do_readpage: cannot read page 0 of inode 88, error -22 Error reading file '/boot/primary/uImage'
I've created the filesystem in Linux on the target (v2.6.31). The compression error -6 is LZO_E_LOOKBEHIND_OVERRUN, and it fails because of this test in lzo1x_decompress.c:
if (HAVE_LB(m_pos, out, op)) goto lookbehind_overrun;
where HAVE_LB is defined as (m_pos < out || m_pos >= op) and the m_pos, out and op values are 0x07ffde77, 0x08000000, 0x08000083 (i.e., the first test fails).
The lzo1x_decompress.c file is identical to that in Linux, so something is fishy here. Does it work for the rest of you?
In our case it doesn't matter very much since the file (an uImage) is compressed anyway and we therefore save work anyway by marking it as using no compression, but it would be nice if this would work anyhow.
// Simon