UnitSizeFactor of != 1 yet?

UnitSizeFactor of != 1 yet?

[Brian P. Austin]

Hello all,

I have switched from the msys driver and moved to mtd.  Everything
compiles fine and this is what I get at boot up.

Using configured DiskOnChip probe address 0xd0000
DiskOnChip 2000 found at address 0xD0000
Flash chip found: Manufacturer ID: 98, Chip ID: 75 (Toshiba TC58256FT/DC)
9 flash chips found. Total DiskOnChip size: 288 MiB
mtd: Giving out device 0 to DiskOnChip 2000
NFTL driver: nftlcore.c $Revision: 1.82 $, nftlmount.c $Revision: 1.25 $
NFTL_notify_add for DiskOnChip 2000
NFTL_setup
Sorry, we don't support UnitSizeFactor of != 1 yet.
Could not find valid boot record
Could not mount NFTL device

when I do cat /proc/mtd, I get the following.

dev:    size   erasesize  name
mtd0: 12000000 00004000 "DiskOnChip 2000"

I'm using a DOC 2000 288MB flash chip with the DOC43.exb file on it.

I guess my question is...

What does "Sorry, we don't support UnitSizeFactor of != 1 yet." mean?

thanks in advance.

Brian Austin

Re: UnitSizeFactor of != 1 yet?

[Brian P. Austin]

OK.  I got past the != 1 part.  I used the 4.2 exb file from m-sys.

When I load the mtd and nftl modules I get this message.

Mar  1 01:31:38 ba kernel: mtd: Giving out device 0 to DiskOnChip 2000 
Mar  1 01:31:38 ba kernel: NFTL_notify_add for DiskOnChip 2000 
Mar  1 01:31:38 ba kernel: NFTL_setup 
Mar  1 01:31:46 ba kernel: Cannot calculate an NFTL geometry to match size of 0x3bf80. 
Mar  1 01:31:46 ba kernel: Using C:1023 H:16 S:15 (== 0x3bf10 sects) 
Mar  1 01:31:46 ba kernel:  nftla: unknown partition table 

This was after running nftl_format, which seemed to work.

as per the mtd-jffs how-to i ran fdisk on /dev/nftla.  When I wrote the
table my message file logged this.

Mar  1 01:42:20 ba kernel: invalidate: busy buffer 
Mar  1 01:42:20 ba last message repeated 17 times
Mar  1 01:42:20 ba kernel:  nftla: nftla1 
Mar  1 01:42:22 ba kernel: invalidate: busy buffer 
Mar  1 01:42:22 ba last message repeated 17 times
Mar  1 01:42:22 ba kernel:  nftla: nftla1 

I do not get an error when doing this however.  Fdisk exits normally.

then, here's the kicker.  When i run mke2fs /dev/nftla1 I get this
message SEVERAL TIMES.

Mar  1 01:36:09 ba kernel: e==1 to find free EUN to accommodate write to VUC 7182 
Mar  1 01:36:09 ba kernel: Argh! No free blocks found! LastFreeEUN = 7679, FirstEUN = 0 
Mar  1 01:36:09 ba kernel: Cannot make free space. 
Mar  1 01:36:09 ba kernel: NFTL_writeblock(): Cannot find block to write to 
Mar  1 01:36:09 ba kernel: NFTL write request failed 
Mar  1 01:36:09 ba kernel: end_request: I/O error, dev 5d:01 (unknown), sector 229822 
Mar  1 01:36:09 ba kernel: Argh! No free blocks found! LastFreeEUN = 7679, FirstEUN = 0 
Mar  1 01:36:09 ba kernel: No Virtual Unit Chains available for folding. Failing request 

I do not get any errors when running mke2fs.  Programm exits normally.

I'm sorry for the length of the message, but I want to make sure I don't
leave anything out.  I feel I'm very close to being able to ditch the
M-SYS DOC Driver.

any help would be greatly appreciated.

Thank you in advance

P.S.  I'm using a 288MB DOC 2000



Brian Austin

Re: UnitSizeFactor of != 1 yet?

[David Woodhouse]

baustin@codemonsters.net said:

> e==1 to find free EUN to accommodate write to VUC 7182 
> Argh! No free blocks found! LastFreeEUN = 7679, FirstEUN = 0 
> Cannot make free space.
> NFTL_writeblock(): Cannot find block to write to 
> NFTL write request failed
> end_request: I/O error, dev 5d:01 (unknown), sector 229822 

Eep. I thought all the cases where that could happen had been fixed. Can 
you enable all the debugging and log it all (serial console useful)? I'll 
see if I can sort it out. Check you're using the latest NFTL code from CVS, 
but I think Marcelo has that anyway.

This code is starting to show its age - I originally threw it together to
check I understood the format, and haven't ever got round to doing the
rewrite that it needs. I've been badgering our sales people ever since I got
here to find me a customer so I can spent some real time on it, but so far
all attempts have failed. 

How keen are you to switch? It shouldn't take that much work, and I'll 
happily help you with it - I just haven't so far been able to find the time 
to do it myself.

--
dwmw2

Re: UnitSizeFactor of != 1 yet?

[Mark Meade]

On Thu, 7 Mar 2002, David Woodhouse wrote:

> Did anyone test the patches for UnitSizeFactor != 1 yet?

David,

I have been trying the UnitSizeFactor patches, and have seen two issues:

1) On line 131 of nftlmount.c, ReplUnitTable is accessed before it is 
allocated, causing an oops message.  

2) A freshly formatted DoC Millennium (with doc504.exb firmware) returns a 
UnitSizeFactor of 0x00.

Mark

Re: UnitSizeFactor of != 1 yet?

[David Woodhouse]

mark@lakeshoremicro.com said:
>  1) On line 131 of nftlmount.c, ReplUnitTable is accessed before it is
>  allocated, causing an oops message.  

That one should be fixed.

> 2) A freshly formatted DoC Millennium (with doc504.exb firmware)
> returns a  UnitSizeFactor of 0x00. 

Er, as in "Sorry, we don't support UnitSizeFactor 0x00" ?
I don't think that's legal according to the docs I have. Vadim?



--
dwmw2

RE: UnitSizeFactor of != 1 yet?

[Vadim Khmelnitsky]

Can you tell where did you get this info from ?
For Millennium 8M Virtual Unit size is always equal to a physical unit size
.

Vadim

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tue, March 12, 2002 2:59 PM
To: Mark Meade
Cc: linux-mtd@lists.infradead.org
Subject: Re: UnitSizeFactor of != 1 yet? 



mark@lakeshoremicro.com said:
>  1) On line 131 of nftlmount.c, ReplUnitTable is accessed before it is
>  allocated, causing an oops message.  

That one should be fixed.

> 2) A freshly formatted DoC Millennium (with doc504.exb firmware)
> returns a  UnitSizeFactor of 0x00. 

Er, as in "Sorry, we don't support UnitSizeFactor 0x00" ?
I don't think that's legal according to the docs I have. Vadim?



--
dwmw2



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: UnitSizeFactor of != 1 yet?

[David Woodhouse]

VadimK@m-sys.com said:
> Can you tell where did you get this info from ? For Millennium 8M
> Virtual Unit size is always equal to a physical unit size 

Right.... so UnitSizeFactor should be 0xFF, not 0x00. Perhaps I did 
something stupid?

--
dwmw2

Re: UnitSizeFactor of != 1 yet?

[Mark Meade]

David Woodhouse wrote:

> Er, as in "Sorry, we don't support UnitSizeFactor 0x00" ?

Yes, that was the message I got with the latest cvs code, after relocating the
ReplUnitTable assignment.

Just to make sure I didn't have something else screwed up, I went back to the source in
2.4.18, and added a printk of the UnitSizeFactor.  In that case, it also said 0.

The procedure that led up to this was a "DFORMAT /WIN:D000 /S:DOC504.EXB" in DOS, power
down, boot up Linux 2.4.18, and insmod.  The dformat command ends up putting a formatted
fat partition on the DoC.

Mark

Re: UnitSizeFactor of != 1 yet?

[David Woodhouse]

mark@lakeshoremicro.com said:
> Yes, that was the message I got with the latest cvs code, after
> relocating the ReplUnitTable assignment.

> Just to make sure I didn't have something else screwed up, I went back
> to the source in 2.4.18, and added a printk of the UnitSizeFactor.  In
> that case, it also said 0. 

Eep. OK, if you put a check in just before we deal with UnitSizeFactor, 
setting it to 0xFF if it was 0x00 - does that make it work? Don't break the 
memcmp with the later MediaHeader - use a local variable of something.

Vadim, is this expected? Is a UnitSizeFactor of zero _always_ going to mean 
that the Virtual Unit size matches the physical unit size?

--
dwmw2

Re: UnitSizeFactor of != 1 yet?

[Mark Meade]

David,

With the latest revision of nfltmount.c (1.28), I was able to mount the DoC and create
files on the fat partition -- everything seems OK.  I didn't put in any additional checks
on UnitSizeFactor == 0, as it looks like the code has already assumed that 0 is equivalent
to 0xFF.

I created an ext2 partition, and attempted to boot from it.  The kernel booted, but I got
the following panic:

    NFTL: UnitSizeFactor 0x00 detected. This violates the spec but we think we know what
it means...
    nftla:<0>Kernel panic: unknown: request list destroyed

Attempting to mount this ext2 partition is successful, but I'm seeing multiple messages
like:

    NFTL_findfreeblock: there are too few free EUNs
    Write Inhibited on EUN 919
    Folding chain 8 into unit 559
    Want to erase

Vadim - I noticed that during a nftl_format, there were messages about "skipping factory
marked bad zones".  Does the latest version of DFORMAT create a new bad block table?  I
was under the impression that my bad block table was long gone...

Mark

David Woodhouse wrote:

> Eep. OK, if you put a check in just before we deal with UnitSizeFactor,
> setting it to 0xFF if it was 0x00 - does that make it work? Don't break the
> memcmp with the later MediaHeader - use a local variable of something.

Re: UnitSizeFactor of != 1 yet?

[David Woodhouse]

mark@lakeshoremicro.com said:
> <0>Kernel panic: unknown: request list destroyed 

Weird. Can you revert to the older version, just remove the check for 
UnitSizeFactor and see if it exhibits the same behaviour? Maybe I broke 
something else in the process?

--
dwmw2

RE: UnitSizeFactor of != 1 yet?

[Vadim Khmelnitsky]

Vadim - I noticed that during a nftl_format, there were messages about
"skipping factory
marked bad zones".  Does the latest version of DFORMAT create a new bad
block table?  I
was under the impression that my bad block table was long gone...

[Vadim]
This message means that we do not touch block that marked as bad in BBT (
bad block table ). If there is no BBT
fomat will treat DOC as a virgin device , meaning the first thing would be
to scan the whole media to find the bad blocks . On the virgin media bad
blocks are the blocks that are not fully erased .( at least one byte in data
or extra area is not 0xFF ) 

Vadim 
-----Original Message-----
From: Mark Meade [mailto:mark@lakeshoremicro.com]
Sent: Wed, March 13, 2002 7:05 AM
To: David Woodhouse
Cc: Vadim Khmelnitsky; linux-mtd@lists.infradead.org
Subject: Re: UnitSizeFactor of != 1 yet? 


David,

With the latest revision of nfltmount.c (1.28), I was able to mount the DoC
and create
files on the fat partition -- everything seems OK.  I didn't put in any
additional checks
on UnitSizeFactor == 0, as it looks like the code has already assumed that 0
is equivalent
to 0xFF.

I created an ext2 partition, and attempted to boot from it.  The kernel
booted, but I got
the following panic:

    NFTL: UnitSizeFactor 0x00 detected. This violates the spec but we think
we know what
it means...
    nftla:<0>Kernel panic: unknown: request list destroyed

Attempting to mount this ext2 partition is successful, but I'm seeing
multiple messages
like:

    NFTL_findfreeblock: there are too few free EUNs
    Write Inhibited on EUN 919
    Folding chain 8 into unit 559
    Want to erase

Vadim - I noticed that during a nftl_format, there were messages about
"skipping factory
marked bad zones".  Does the latest version of DFORMAT create a new bad
block table?  I
was under the impression that my bad block table was long gone...

Mark

David Woodhouse wrote:

> Eep. OK, if you put a check in just before we deal with UnitSizeFactor,
> setting it to 0xFF if it was 0x00 - does that make it work? Don't break
the
> memcmp with the later MediaHeader - use a local variable of something.

Re: UnitSizeFactor of != 1 yet?

[Mark Meade]

Reverting back to nftlmount 1.25 and removing check seems to have similar problems.
Attempting to boot gets past NFTL_setup and "nftla: nftla1", but locks up soon after that.
Mounting ext2 partition works, but still gives error messages described earlier.

David Woodhouse wrote:

> Weird. Can you revert to the older version, just remove the check for
> UnitSizeFactor and see if it exhibits the same behaviour? Maybe I broke
> something else in the process?

RE: UnitSizeFactor of != 1 yet?

[Vadim Khmelnitsky]

Here is how VirtualUnitSize calculated by dformat for DOC2000 or Millennium.

/*originally virtual unit size is equal to erasable unit size*/
  unitSizeBits = erasableBlockSizeBits;
 /*Calculate No of erasable units on the diskonchip*/
  noOfUnits = (unsigned short)(noOfChips /*No of flash devices */ * chipSize
/* size of each flash device */) >>unitSizeBits);

  /* Adjust virtual unit size so Media header with BBT  fit in one virtual
unit */
  while (noOfUnits + SECTOR_SIZE > (1UL << unitSizeBits)) {
    unitSizeBits++;
    noOfUnits >>= 1;
  }
  /* Bound number of units to find room in 64 Kbytes Segment */
  if( (noOfUnits >= MAX_UNIT_NUM) && (unitSizeBits < MAX_UNIT_SIZE_BITS) ) {
    unitSizeBits++;
    noOfUnits >>= 1;
  }  ,

where MAX_UNIT_NUM = 12KB and MAX_UNIT_SIZE_BITS = 15 .


Vadim

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tue, March 12, 2002 5:14 PM
To: Mark Meade
Cc: Vadim Khmelnitsky; linux-mtd@lists.infradead.org
Subject: Re: UnitSizeFactor of != 1 yet? 



mark@lakeshoremicro.com said:
> Yes, that was the message I got with the latest cvs code, after
> relocating the ReplUnitTable assignment.

> Just to make sure I didn't have something else screwed up, I went back
> to the source in 2.4.18, and added a printk of the UnitSizeFactor.  In
> that case, it also said 0. 

Eep. OK, if you put a check in just before we deal with UnitSizeFactor, 
setting it to 0xFF if it was 0x00 - does that make it work? Don't break the 
memcmp with the later MediaHeader - use a local variable of something.

Vadim, is this expected? Is a UnitSizeFactor of zero _always_ going to mean 
that the Virtual Unit size matches the physical unit size?

--
dwmw2