Brian P. Austin | 1 Mar 2002 02:03

UnitSizeFactor of != 1 yet?

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.

(Continue reading)

Ilguiz Latypov | 1 Mar 2002 03:44

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

Yoshinori,

1. I cleaned up the patch with regard to the debugging leftovers.  Do you 
think I need to remove extra debug information activated by the DOC_DEBUG 
switch (dprintf calls)?  What other adjustments are necessary?

2. Besides, I changed stage1/doc_stage1{,b}.S so that the GRUB firmware
will correctly replace the BIOS extension initialization code of DoC
Millennium.

DoC Millennium maps its BIOS extension initialization code to the
beginning of flash memory.  When --enable-diskonchip-ipl option is
supplied to the configure script in addition to --enable-diskonchip, the
necessary 3 byte BIOS signature will be generated in the beginning of the
code.

Unfortunately, the signature cannot be tolerated with DoC 2000 where IPL
is in ROM. This is because the ROM IPL will jump to offset 0 of GRUB
firmware.  The signature 0x55, 0xAA would be executed as "push bp; stosb"  
which is dangerous.

3. I wish to assign my copyright to FSF.  This refers only to the changes
that were not copyrighted by others, of course.  Hopefully, I didn't break
things in the existing code.

Most of the new code in the patch has a copyright notice.  The only
exception is stage2/bdev_diskonchip.c.

David, would you like to put your copyright notice in the above file?  I
can do this for you.
(Continue reading)

Michael Michael | 1 Mar 2002 04:58
Picon
Favicon

New Release

Would it be possible to get some idea of the current
status of Jff2.

What done?

What needs to be done?

Whats wanted ?

It looks like a lot of work has been done lately and
I'd like to know how the core developers feel about
the current status of the File system.  Should I
upgrade now ! or wait a bit. Also this is off topic
but is there a web site group dedicated to the
"fastest" boot time for linux. I'm down around 2 min.
I think its pretty good but I don't know.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

Brian P. Austin | 1 Mar 2002 08:49

Re: UnitSizeFactor of != 1 yet?

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 
(Continue reading)

David Woodhouse | 1 Mar 2002 08:19
Favicon

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

ilatypov <at> superbt.com said:
>  3. I wish to assign my copyright to FSF.  This refers only to the
> changes that were not copyrighted by others, of course.  Hopefully, I
> didn't break things in the existing code.

> Most of the new code in the patch has a copyright notice.  The only
> exception is stage2/bdev_diskonchip.c.

> David, would you like to put your copyright notice in the above file?
> I can do this for you. 

Er, did I write that? Yeah - looks like my scribblings. I think it predates 
my employment with Red Hat, who own my new output and have FSF copyright 
assignment stuff all sorted out. If it's optional, then I can't be bothered 
with the paperwork - yes, please do add
	(C) 2000  David Woodhouse  <dwwm2 <at> infradead.org>

If only emacs would complain at you when you edit a file which doesn't have 
a copyright for the current year, and possibly even update it for you :)

--
dwmw2

David Woodhouse | 1 Mar 2002 10:52
Favicon

Re: New Release

<moved to jffs list>

memmel2 <at> yahoo.com said:
>  Would it be possible to get some idea of the current status of Jff2.
> What done?

The code in the 2.4.19 kernel, and on the jffs2-2_4-branch of CVS, should be 
stable and reliable enough to use in production. 

> What needs to be done?
> Whats wanted ?

See fs/jffs2/TODO in the CVS tree. The NAND support is mostly implemented, 
and needs lots and lots of testing. Joakim has made some good optimisations 
for speeding up the mount, and checkpointing will be helpful too if we can 
manage to get that implemented at last.

In roughly increasing order of required competence...

Just installing the code on the trunk and giving good bug reports if/when 
it fails is an extremely useful thing to do - don't underestimate the 
benefit of that even if looking at the code makes you run away screaming.
(Thomas keeps complaining that my documentation - or lack of it - sucks :)

Fixing i_nlink on directories ought to be a fairly reasonable introduction
to the code, and quite simple. Track the number of child directories that 
each directory has (you have a d_type in the dirent nodes so you don't need 
to actually look at the children at all) and increase i_nlink for each one 
in read_inode. I wouldn't increase the nlink in the jffs2_inode_cache 
itself, just in the vfs_inode. 
(Continue reading)

David Woodhouse | 1 Mar 2002 11:03
Favicon

Re: UnitSizeFactor of != 1 yet?

baustin <at> 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

Brian P. Austin | 1 Mar 2002 20:59

Reproduction of NFTL Bug with DOC 2000 288MB FULL DEBUG

Ok.  I was able to get to the same point as before.

here is my terminal input.
-----------------------------------------------------------------------
MODULE INSERTS

[root <at> ba /root]# depmod -a
[root <at> ba /root]# modprobe -a doc2000 nftl mtdchar mtdcore
[root <at> ba /root]# modprobe -a docprobe
[root <at> ba /root]# cat /proc/mtd       
dev:    size   erasesize  name
mtd0: 12000000 00004000 "DiskOnChip 2000"

-----------------------------------------------------------------------
FDISK

[root <at> ba /root]# fdisk /dev/nftla

Device contains neither a valid DOS partition table, nor Sun or SGI
disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

Command (m for help): p

Disk /dev/nftla: 16 heads, 15 sectors, 1023 cylinders
Units = cylinders of 240 * 512 bytes

     Device Boot    Start       End    Blocks   Id  System
(Continue reading)

Brian P. Austin | 1 Mar 2002 21:01

Reproduction of NFTL Bug with DOC 2000 288MB FULL DEBUG (fwd)


This should have the attachment

Ok.  I was able to get to the same point as before.

here is my terminal input.
-----------------------------------------------------------------------
MODULE INSERTS

[root <at> ba /root]# depmod -a
[root <at> ba /root]# modprobe -a doc2000 nftl mtdchar mtdcore
[root <at> ba /root]# modprobe -a docprobe
[root <at> ba /root]# cat /proc/mtd       
dev:    size   erasesize  name
mtd0: 12000000 00004000 "DiskOnChip 2000"

-----------------------------------------------------------------------
FDISK

[root <at> ba /root]# fdisk /dev/nftla

Device contains neither a valid DOS partition table, nor Sun or SGI
disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

Command (m for help): p

Disk /dev/nftla: 16 heads, 15 sectors, 1023 cylinders
(Continue reading)

David Woodhouse | 1 Mar 2002 20:14
Favicon

Re: Reproduction of NFTL Bug with DOC 2000 288MB FULL DEBUG

Hmm. Did you do this from scratch, starting by reformatting the NFTL again? 
It doesn't look like it.

Use the M-Systems DFORMAT (version 4.2) if you can, rather than nftl_format.
If you do use nftl_format, make sure the NFTL kernel module isn't loaded 
while you do so.

Then get logs again, preferably over a serial console, because syslog is 
lossy.

I may have a 288MiB unit here, in fact - I'll see if I can reproduce it 
myself.

--
dwmw2


Gmane