mkfs.jffs2 buggy?

mkfs.jffs2 buggy?

[Holger Schurig]

When I compile mkfs.jffs2 from CVS HEAD, I get the following errors:

mkfs.jffs2.c: In function `write_regular_file':
mkfs.jffs2.c:823: incompatible types in assignment
mkfs.jffs2.c: In function `write_symlink':
mkfs.jffs2.c:925: incompatible types in assignment
mkfs.jffs2.c: In function `write_pipe':
mkfs.jffs2.c:967: incompatible types in assignment
mkfs.jffs2.c: In function `write_special_file':
mkfs.jffs2.c:1007: incompatible types in assignment

Anyway, I somehow got it working, I think with a some older version.

$ mkfs.jffs2 -d rootfs -p 262144 -e 262144 -o /tftpboot/bdi/root.jffs2

and flash the result with

$ burner.py /tftpboot/bdi/root.jffs 0x140000
...
00440000: burning 262144 bytes to flash
00480000: reading 262144 bytes from flash (68.4 %)
00480000: erase flash
00480000: burning 262144 bytes to flash
004c0000: reading 262144 bytes from flash (73.7 %)
004c0000: erase flash
004c0000: burning 262144 bytes to flash
00500000: reading 262144 bytes from flash (78.9 %)
00500000: erase flash
00500000: burning 262144 bytes to flash
...

I get a strange error. Immediately after the flashing, I pressed reset and 
booted into Linux. Then I see:

Probing flash at physical address 0x00000000 (32-bit buswidth)
Using buffer write method
Using static partition definition
Creating 3 MTD partitions on "Flash":
0x00000000-0x00040000 : "Bootloader"
0x00040000-0x00140000 : "Kernel"
0x00140000-0x02000000 : "Filesystem"
...
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
ffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0000: 0x6574 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0004: 0x665f 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0008: 0x6873 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c000c: 0x3030 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0010: 0x3030 
instead
JFFS2: Erase block at 0x004c0000 is not formatted. It will be erased

Shouldn't a sector that has been freshly created by mkfs.jffs2 have the right 
ID?

So, I re-flashed it again and looked at this address. At physically 0x4c0000 I 
see

$ telnet bdi
bdi>mdb 0x004c0000
004c0000 : 85 19 03 20 0c 00 00 00  ... ....
004c0008 : b1 b0 1e e4 85 19 02 e0  ........
004c0010 : 03 09 00 00 16 a0 e5 91  ........
004c0018 : cb 02 00 00 38 00 00 00  ....8...
004c0020 : ed 81 00 00 00 00 00 00  ........
004c0028 : 24 1d 06 00 08 40 c3 3b  $....@.;
004c0030 : 08 40 c3 3b 08 40 c3 3b  .@.;.@.;
004c0038 : 00 70 03 00 bf 08 00 00  .p......

... and that looks like a valid ID.


And also in root.fs at file offset 0x380000 = 3670016 I can see this.


Am I doing something wrong?  Maybe confusing physical and virtual addressed?

Re: mkfs.jffs2 buggy?

[George G. Davis]

Holger Schurig wrote:
> 
> When I compile mkfs.jffs2 from CVS HEAD, I get the following errors:
> 
> mkfs.jffs2.c: In function `write_regular_file':
> mkfs.jffs2.c:823: incompatible types in assignment
> mkfs.jffs2.c: In function `write_symlink':
> mkfs.jffs2.c:925: incompatible types in assignment
> mkfs.jffs2.c: In function `write_pipe':
> mkfs.jffs2.c:967: incompatible types in assignment
> mkfs.jffs2.c: In function `write_special_file':
> mkfs.jffs2.c:1007: incompatible types in assignment
> 
> Anyway, I somehow got it working, I think with a some older version.
> 
> $ mkfs.jffs2 -d rootfs -p 262144 -e 262144 -o /tftpboot/bdi/root.jffs2
> 
> and flash the result with
> 
> $ burner.py /tftpboot/bdi/root.jffs 0x140000
> ...
> 00440000: burning 262144 bytes to flash
> 00480000: reading 262144 bytes from flash (68.4 %)
> 00480000: erase flash
> 00480000: burning 262144 bytes to flash
> 004c0000: reading 262144 bytes from flash (73.7 %)
> 004c0000: erase flash
> 004c0000: burning 262144 bytes to flash
> 00500000: reading 262144 bytes from flash (78.9 %)
> 00500000: erase flash
> 00500000: burning 262144 bytes to flash
> ...
> 
> I get a strange error. Immediately after the flashing, I pressed reset and
> booted into Linux. Then I see:
> 
> Probing flash at physical address 0x00000000 (32-bit buswidth)
> Using buffer write method
> Using static partition definition
> Creating 3 MTD partitions on "Flash":
> 0x00000000-0x00040000 : "Bootloader"
> 0x00040000-0x00140000 : "Kernel"
> 0x00140000-0x02000000 : "Filesystem"
> ...
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
> ffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0000: 0x6574

'At'

> instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0004: 0x665f

'b_'

> instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0008: 0x6873

'hs'

> instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c000c: 0x3030

'00'

> instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0010: 0x3030

'00'


Hmm, is that interesting or merely a coincidence?

--
Regards,
George


> instead
> JFFS2: Erase block at 0x004c0000 is not formatted. It will be erased
> 
> Shouldn't a sector that has been freshly created by mkfs.jffs2 have the right
> ID?
> 
> So, I re-flashed it again and looked at this address. At physically 0x4c0000 I
> see
> 
> $ telnet bdi
> bdi>mdb 0x004c0000
> 004c0000 : 85 19 03 20 0c 00 00 00  ... ....
> 004c0008 : b1 b0 1e e4 85 19 02 e0  ........
> 004c0010 : 03 09 00 00 16 a0 e5 91  ........
> 004c0018 : cb 02 00 00 38 00 00 00  ....8...
> 004c0020 : ed 81 00 00 00 00 00 00  ........
> 004c0028 : 24 1d 06 00 08 40 c3 3b  $....@.;
> 004c0030 : 08 40 c3 3b 08 40 c3 3b  .@.;.@.;
> 004c0038 : 00 70 03 00 bf 08 00 00  .p......
> 
> ... and that looks like a valid ID.
> 
> And also in root.fs at file offset 0x380000 = 3670016 I can see this.
> 
> Am I doing something wrong?  Maybe confusing physical and virtual addressed?
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: mkfs.jffs2 buggy?

[Holger Schurig]

> > 0x6574
>
> 'At'
>
> > 0x665f
>
> 'b_'
>
> > 0x6873
>
> 'hs'
>
> > 0x3030
>
> '00'
>
> > 0x3030
>
> '00'
>
> Hmm, is that interesting or merely a coincidence?

I think this is a conincidence.


From my flash-tester I had in every sector a text like this:

bdi>mdb 0x00a00000
00a00000 : 74 65 73 74 5f 66 6c 61  test_fla
00a00008 : 73 68 3a 20 30 30 61 30  sh: 00a0
00a00010 : 30 30 30 30 ff ff ff ff  0000....
00a00018 : ff ff ff ff ff ff ff ff  ........

bdi>mdb 0x00a00000
00a40000 : 74 65 73 74 5f 66 6c 61  test_fla
00a40008 : 73 68 3a 20 30 30 61 34  sh: 00a4
00a40010 : 30 30 30 30 ff ff ff ff  0000....
00a40018 : ff ff ff ff ff ff ff ff  ........


I used this to make sure that each sector get's address indeed, and that no 
overwrapping happens, e.g. by bad soldered address lines.

However, the found characters can't be from those sectors, so it looks very 
much like a conincidence. My memory area looks, in the flash, currently like 
this:

          00000 40000 80000 c0000
00000000:  used  used  used  used
00100000:  test  jffs  jffs  jffs
00200000:  jffs  jffs  jffs  jffs
00300000:  jffs  jffs  jffs  jffs
00400000:  jffs  jffs  jffs  jffs
00500000:  jffs  jffs  jffs  jffs
00600000:  jffs  jffs  jffs  jffs
00700000:  jffs  jffs  jffs  jffs
00800000:  jffs  jffs  jffs  jffs
00900000:  jffs  jffs  jffs  test
00a00000:  test  test  test  test
00b00000:  test  test  test  test
00c00000:  test  test  test  test
00d00000:  test  test  test  test
00e00000:  test  test  test  test
00f00000:  test  test  test  test
01000000:  test  test  test  test
01100000:  test  test  test  test
01200000:  test  test  test  test
01300000:  test  test  test  test
01400000:  test  test  test  test
01500000:  test  test  test  test
01600000:  test  test  test  test
01700000:  test  test  test  test
01800000:  test  test  test  test
01900000:  test  test  test  test
01a00000:  test  test  test  test
01b00000:  test  test  test  test
01c00000:  test  test  test  test
01d00000:  test  test  test  test
01e00000:  test  test  test  test
01f00000:  test  test  test  test

test:  means that a valid test mark like above has been found
jffs:  means that in the first byte I found 0x85 and in the second 0x19
free:  the whole page contained \xFF
used:  the page contained other stuff