[U-Boot-Users] jffs2 view u-boot/linux

[U-Boot-Users] jffs2 view u-boot/linux

[Jonas Dietsche]

Hi all,

I'm wondering why linux and u-boot are seeing different files when I use 
a jjfs2 image on my nand flash.

This is what I've done.
I partitioned my nand flash with 3 partitions (u-boot, jffs2, user)
Then I flashed the jffs2 image with nand write.jffs2
booted the uImage from my jffs2 with fsload
That all worked fine (although fsload is extreamly slow) and I can use 
my linux.
Then I created a new file in my root. A "ls" from linux displays that 
file. With a "ls" from u-boot the file is not visible...
So what went wrong?
Who is cheating on me?

Thanks for your help.
Jonas

[U-Boot-Users] jffs2 view u-boot/linux

[Jonas Dietsche]

Jonas Dietsche wrote on 05/17/05 10:39:
> Hi all,
> 
> I'm wondering why linux and u-boot are seeing different files when I use 
> a jjfs2 image on my nand flash.
> 
> This is what I've done.
> I partitioned my nand flash with 3 partitions (u-boot, jffs2, user)
> Then I flashed the jffs2 image with nand write.jffs2
> booted the uImage from my jffs2 with fsload
> That all worked fine (although fsload is extreamly slow) and I can use 
> my linux.
> Then I created a new file in my root. A "ls" from linux displays that 
> file. With a "ls" from u-boot the file is not visible...
> So what went wrong?
> Who is cheating on me?
> 

Some additional info:
I use the mtd stuff from mtd-snapshot-20050524.tar.bz2 with a 2.6.11 
kernel. I executed patchkernel.sh from the mtd package.
I created a jffs2 image with
mkfs.jffs2 -e  16384 -qnd my_rootfs -o jffs2.img
Then I flashed the image with nand write.jffs2 (or from linux with 
nandwrite).
A "ls" shows me the contents of the image as expected.
Scanning JFFS2 FS: .. done.
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 bin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 dev
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 etc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 initrd
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 lib
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 mnt
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 nfs
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 proc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 ram
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 sbin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 sys
  lrwxrwxrwx        4 Mon May 30 10:09:25 2005 tmp ->
  -rw-r--r--  1330220 Mon May 30 10:09:24 2005 uImage
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 usr
  lrwxrwxrwx        4 Mon May 30 10:09:25 2005 var ->
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 www

Then I boot linux and mount my jffs2 partiton. I deleted the uImage from 
  it. A "ls" from linux shows me that it is deleted.
Then I rebooted and did a "ls" from u-boot.
Scanning JFFS2 FS: .. done.
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 bin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 dev
  drwxr-xr-x        0 Thu Aug 26 08:34:34 2004 etc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 initrd
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 lib
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 mnt
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 nfs
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 proc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 ram
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 sbin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 sys
  lrwxrwxrwx        4 Mon May 30 10:09:25 2005 tmp ->
  -rw-r--r--  1330220 Mon May 30 10:09:24 2005 uImage
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 usr
  lrwxrwxrwx        4 Mon May 30 10:09:25 2005 var ->
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 www
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 bin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 dev
  drwxr-xr-x        0 Thu Aug 26 08:34:34 2004 etc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 initrd
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 lib

The uImage is still there. And "bin, dev, etc, initrd, lib" are listed 
twice.
Then I deleted the "www directory" and the ls of u-boot gives me
Scanning JFFS2 FS: ... done.
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 bin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 dev
  drwxr-xr-x        0 Thu Aug 26 08:34:34 2004 etc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 initrd
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 lib
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 mnt
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 nfs
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 proc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 ram
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 sbin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 sys
  lrwxrwxrwx        4 Mon May 30 10:09:25 2005 tmp ->
  -rw-r--r--  1330220 Mon May 30 10:09:24 2005 uImage
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 usr
  lrwxrwxrwx        4 Mon May 30 10:09:25 2005 var ->
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 www
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 bin
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 dev
  drwxr-xr-x        0 Thu Aug 26 08:34:34 2004 etc
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 initrd
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 lib
  drwxr-xr-x        0 Mon May 30 10:09:25 2005 usr
  lrwxrwxrwx        4 Mon May 30 10:09:25 2005 var ->

"bin, dev, etc, initrd, lib, usr var" are listed twice.

What I'm doing wrong?

Jonas

[U-Boot-Users] jffs2 view u-boot/linux

[Wolfgang Denk]

Dear Jonas,

in message <429AFC63.2070205@fsforth.de> you wrote:
> 
> I use the mtd stuff from mtd-snapshot-20050524.tar.bz2 with a 2.6.11 
> kernel. I executed patchkernel.sh from the mtd package.

We use a snapshot from MTD CVS of March 13, 2005 in our 2.4.25 kernel
tree, and this is what U-Boot was tested against.

> I created a jffs2 image with
> mkfs.jffs2 -e  16384 -qnd my_rootfs -o jffs2.img

Are you absolutely sure that 16 kB is the correct  erase  block  size
for your hardware?

> Then I boot linux and mount my jffs2 partiton. I deleted the uImage from 
>   it. A "ls" from linux shows me that it is deleted.
> Then I rebooted and did a "ls" from u-boot.

And when booting Linux again the state is again as expected?

> What I'm doing wrong?

Can you try the March 13 MTD snapshot?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.

[U-Boot-Users] jffs2 view u-boot/linux

[Jonas Dietsche]

Hello Wolfgang,

thanks for your reply.

> We use a snapshot from MTD CVS of March 13, 2005 in our 2.4.25 kernel
> tree, and this is what U-Boot was tested against.
can you send it or give me a link?

>>I created a jffs2 image with
>>mkfs.jffs2 -e  16384 -qnd my_rootfs -o jffs2.img
> 
> 
> Are you absolutely sure that 16 kB is the correct  erase  block  size
> for your hardware?
Yes, it is a Samsung K9F1208U0B.

>>Then I boot linux and mount my jffs2 partiton. I deleted the uImage from 
>>  it. A "ls" from linux shows me that it is deleted.
>>Then I rebooted and did a "ls" from u-boot.
> 
> 
> And when booting Linux again the state is again as expected?
Yes, it looks as expected.

Jonas

[U-Boot-Users] jffs2 view u-boot/linux

[Wolfgang Denk]

In message <429B103E.3040802@fsforth.de> you wrote:
> 
> > We use a snapshot from MTD CVS of March 13, 2005 in our 2.4.25 kernel
> > tree, and this is what U-Boot was tested against.
> can you send it or give me a link?

Send what? Our kernel tree? It's the linuxppc_2_4_devel module on our
CVS server; see http://www.denx.de/re/linux.html

But it should be sufficient to check out the MTD code as of March 13.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As in certain cults it is possible to kill a process if you know  its
true name.                      -- Ken Thompson and Dennis M. Ritchie

[U-Boot-Users] jffs2 view u-boot/linux

[Jonas Dietsche]

 > Send what? Our kernel tree? It's the linuxppc_2_4_devel module on our
 > CVS server; see http://www.denx.de/re/linux.html

Ok, bad question... ;-)

 >
 > But it should be sufficient to check out the MTD code as of March 13.

I tested it with the MTD code of march 13 with the same result. Files I 
deleted are still there.

Regards,
Jonas

[U-Boot-Users] jffs2 view u-boot/linux

[Jonas Dietsche]

Hi,

I created a 1MB partition to speed up the testing.
Maybe someone can do the same tests and tell me if he sees the same 
results...

* under linux I erased the partition with
	flash_eraseall -j /dev/mtd/2
* then I mounted it with
	mount -t jffs2 /dev/mtdblock/2 /mnt
* and created a file on the partition
	cd /mnt/
	echo test >testfile
* reboot linux
* under u-boot I did a ls and got the following (DEBUG_DIRENT and 
DEBUG_FRAGMENTS in jffs2_1pass.c are enabled)
Scanning JFFS2 FS: . done.


******The directory Entries******

testfile
         build_list: magic =  00001985
         build_list: nodetype =  0000e001
         build_list: hdr_crc =  fa3ebe78
         build_list: pino =  00000001
         build_list: version =  00000001
         build_list: ino =  00000002
         build_list: mctime =  00000074
         build_list: nsize =  00000008
         build_list: type =  00000008
         build_list: node_crc =  c489d275
         build_list: name_crc =  ddab2c44
         build_list: offset =  004f8044


******The fragment Entries******

         build_list: FLASH_OFFSET =  004f8000
         build_list: totlen =  00000044
         build_list: inode =  00000002
         build_list: version =  00000001
         build_list: isize =  00000000
         build_list: atime =  00000074
         build_list: offset =  00000000
         build_list: csize =  00000000
         build_list: dsize =  00000000
         build_list: compr =  00000000
         build_list: usercompr =  00000000
         build_list: flags =  00000000
         build_list: offset =  004f8000

         build_list: FLASH_OFFSET =  004f8074
         build_list: totlen =  00000049
         build_list: inode =  00000002
         build_list: version =  00000002
         build_list: isize =  00000005
         build_list: atime =  00000074
         build_list: offset =  00000000
         build_list: csize =  00000005
         build_list: dsize =  00000005
         build_list: compr =  00000000
         build_list: usercompr =  00000000
         build_list: flags =  00000000
         build_list: offset =  004f8074
  -rw-r--r--        5 Thu Jan 01 00:01:56 1970 testfile

* then I booted linux, mounted the jffs2 partition, deleted the file and 
rebooted
* ls in u-boot displays
Scanning JFFS2 FS: . done.


******The directory Entries******

testfile
         build_list: magic =  00001985
         build_list: nodetype =  0000e001
         build_list: hdr_crc =  fa3ebe78
         build_list: pino =  00000001
         build_list: version =  00000001
         build_list: ino =  00000002
         build_list: mctime =  00000074
         build_list: nsize =  00000008
         build_list: type =  00000008
         build_list: node_crc =  c489d275
         build_list: name_crc =  ddab2c44
         build_list: offset =  004f8044

testfile
         build_list: magic =  00001985
         build_list: nodetype =  0000e001
         build_list: hdr_crc =  fa3ebe78
         build_list: pino =  00000001
         build_list: version =  00000002
         build_list: ino =  00000000
         build_list: mctime =  00000023
         build_list: nsize =  00000008
         build_list: type =  00000000
         build_list: node_crc =  508a537f
         build_list: name_crc =  ddab2c44
         build_list: offset =  004f8200


******The fragment Entries******

         build_list: FLASH_OFFSET =  004f8000
         build_list: totlen =  00000044
         build_list: inode =  00000002
         build_list: version =  00000001
         build_list: isize =  00000000
         build_list: atime =  00000074
         build_list: offset =  00000000
         build_list: csize =  00000000
         build_list: dsize =  00000000
         build_list: compr =  00000000
         build_list: usercompr =  00000000
         build_list: flags =  00000000
         build_list: offset =  004f8000

         build_list: FLASH_OFFSET =  004f8074
         build_list: totlen =  00000049
         build_list: inode =  00000002
         build_list: version =  00000002
         build_list: isize =  00000005
         build_list: atime =  00000074
         build_list: offset =  00000000
         build_list: csize =  00000005
         build_list: dsize =  00000005
         build_list: compr =  00000000
         build_list: usercompr =  00000000
         build_list: flags =  00000000
         build_list: offset =  004f8074
  -rw-r--r--        5 Thu Jan 01 00:01:56 1970 testfile


How can I manage it that the deleted testfile isn't displayed anymore?
Is this a NAND specific problem?

Thanks.
Jonas

[U-Boot-Users] jffs2 view u-boot/linux

[Wolfgang Denk]

In message <429DD07D.1080305@fsforth.de> you wrote:
> 
> I created a 1MB partition to speed up the testing.
> Maybe someone can do the same tests and tell me if he sees the same 
> results...

Did you verify that your partition definitions in Linux and in U-Boot
(CONFIG_JFFS2_NAND_OFF, CONFIG_JFFS2_NAND_SIZE) are exactly the same?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If it happens once, it's a bug.
If it happens twice, it's a feature.
If it happens more than twice, it's a design philosophy.

[U-Boot-Users] jffs2 view u-boot/linux

[Dave Ellis]

Jonas Dietsche wrote:

> ******The directory Entries******
> 
> testfile

>          build_list: version =  00000001
>          build_list: ino =  00000002
 
> testfile

>          build_list: version =  00000002
>          build_list: ino =  00000000

> How can I manage it that the deleted testfile isn't displayed anymore?

Have you tried using CFG_JFFS2_SORT_FRAGMENTS? I use it and I tried a
similar test and testfile is deleted for u-boot (for U-Boot 1.1.0).
Both jffs2_1pass.c and README.JFFS2 say it is needed if the boot 
partition is writable.

In this case it may just be masking a bug in jffs2_1pass_find_inode().
The search  for the most recent directory entry ignores a directory 
entry with an inode of 0 (unlinked file) even if the version is newer, 
so deletion directory entries are ignored. This doesn't look right 
to me: 

	for(b = pL->dir.listHead; b; b = b->next, counter++) {
		jDir = (struct jffs2_raw_dirent *) (b->offset);
		if ((pino == jDir->pino) && (len == jDir->nsize) &&
		    (jDir->ino) &&	/* 0 for unlink */
		    ^^^^^^^^^^^
		    (!strncmp(jDir->name, name, len))) {	/* a
match */
			if (jDir->version < version)
				continue;

With your test this would find version 1 of the directory entry and
ignore version 2, which unlinks the file.

With CFG_JFFS2_SORT_FRAGMENTS all directory entries except the most 
recent version have their inode set to 0 during the sort, so the
obsolete directory entry would be ignored too.  

> Is this a NAND specific problem?

Probably not.

Dave Ellis

~~~~~~~~~~~~~~~~~~~~~~~~~~
SIXNET - "Leading the Industrial Ethernet Revolution"
331 Ushers Road,   P.O. Box 767, Clifton Park, NY 12065 USA
Tel +1 (518) 877-5173   Fax +1 (518) 877-8346
Email me at: dge at sixnetio.com 
Detailed product info: www.sixnetio.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~

[U-Boot-Users] jffs2 view u-boot/linux

[Jonas Dietsche]

Hello Dave,

thanks for your helpful reply.

> Have you tried using CFG_JFFS2_SORT_FRAGMENTS? I use it and I tried a
> similar test and testfile is deleted for u-boot (for U-Boot 1.1.0).
> Both jffs2_1pass.c and README.JFFS2 say it is needed if the boot 
> partition is writable.
Yes and I had the same behaviour.
Then I did the following test.
Defined CFG_JFFS_CUSTOM_PART,  and used
struct part_info* jffs2_part_info(int part_num)
{
	DECLARE_GLOBAL_DATA_PTR;
	bd_t *bd = gd->bd;
	char* s;
	char readcmd[60];
	
	int i;

	if (part_num != 0)
		return 0;	/* only support one partition */

	if (part.usr_priv == (void*)1)
		return ∂	/* already have part info */

	memset(&part, 0, sizeof(part));

	/* boot info in NAND flash, get and use copy in RAM */
	
	/* override info from environment if present */
	s = getenv("fsaddr");
	part.offset = s ? (void *)simple_strtoul(s, NULL, 16)
		: (void *)CFG_JFFS2_RAMBASE;
	s = getenv("fssize");
	part.size = s ? simple_strtoul(s, NULL, 16)
		: CFG_JFFS2_RAMSIZE;
	
	/* read from nand flash */
	sprintf(readcmd, "nand read.jffs2 %x 0 %x",
		(uint32_t)part.offset, part.size);
	run_command(readcmd, 0);

	part.erasesize = 0;	/* unused */
	part.usr_priv=(void*)1;	/* ready */

	return ∂
}

I undefined CONFIG_JFFS2_NAND and did the same tests again.
And the results are what they should be like. Deleted files are not 
displayed anymore. If CFG_JFFS2_SORT_FRAGMENTS is disabled they are 
displayed.
So the NAND functions of jffs2_1pass.c seem not deliver not the values 
they should.
The comparison of the version -where the inode is set to 0 if it is an 
older version- is never reached and that is why deleted files are always 
displayed.

Have you tested it with NAND or NOR?

Regards,
Jonas

[U-Boot-Users] jffs2 view u-boot/linux

[Dave Ellis]

Jonas Dietsche wrote: 
 
> > Have you tried using CFG_JFFS2_SORT_FRAGMENTS? I use it and I tried
a
> > similar test and testfile is deleted for u-boot (for U-Boot 1.1.0).
> > Both jffs2_1pass.c and README.JFFS2 say it is needed if the boot 
> > partition is writable.
> Yes and I had the same behaviour.
> Then I did the following test.
> Defined CFG_JFFS_CUSTOM_PART,  and used
> struct part_info* jffs2_part_info(int part_num)
> {
[ snip - copy NAND to RAM ]
> }> 
> I undefined CONFIG_JFFS2_NAND and did the same tests again.
> And the results are what they should be like. Deleted files are not 
> displayed anymore. If CFG_JFFS2_SORT_FRAGMENTS is disabled they are
displayed.
> So the NAND functions of jffs2_1pass.c seem not deliver not the values

> they should.
> The comparison of the version -where the inode is set to 0 if it is an

> older version- is never reached and that is why deleted files are
always 
> displayed.
> 
> Have you tested it with NAND or NOR?

I am copying from NAND to RAM and using CFG_JFFS_CUSTOM_PART. I have
never
tried using the direct NAND functions. They were added after 1.1.0 so I
had to copy to RAM.

I have a 2MiB boot partition that is copied to RAM. It takes too long to
read
the entire NAND FLASH (one of our products has 128MiB). It is faster to
load
the kernel from a RAM copy, otherwise the entire kernel is read twice
from NAND,
once for the initial scan and again for the load.

Dave Ellis