doc2000 nftl[abcd] devices

doc2000 nftl[abcd] devices

[Brendan J Simon]

I'm using a powerpc linux 2.4.18-pre8 kernel with an 8MB DOC2000.  I've 
managed to create 3 virtual disks using the latest nftl_format from cvs.
$ nftl_format /dev/mtd0 0x00000000 0x02000000
$ nftl_format /dev/mtd0 0x02000000 0x04000000
$ nftl_format /dev/mtd0 0x06000000 0x02000000

I've also compiled the latest cfdisk from util-linux-2.11n.
I loaded the nftl driver (insmod nftl) and did a fdisk (cfdisk 
/dev/nftla).  It complained about having no partition table and aksed if 
I wanted to continue.  I said yes and I created a new partition and it 
recognised the size as being 2MB :)  I wrote this to disk and then 
rebooted my embedded system (power cycled).  It came back up and I could 
mkfs.ext2 it and mount it.  Another power cycle and mount to prove to 
myself everything was written to the DOC correctly.

Now I try the same thing with nftlb and I get errors saying "Cannot open 
disk drive".  It should be the same process shouldn't it ?  Any ideas of 
where to look to fix or debug this ??  I've had a look at nftldump and I 
can see the 3 sets of media headers and they seem like they are in the 
right place.

My devices are:
crw-------    1 0        0         90,   0 Jun 17  2002 /dev/mtd0
brw-------    1 0        0         93,   0 Jun 17  2002 /dev/nftla
brw-------    1 0        0         93,   1 Jun 17  2002 /dev/nftla1
brw-------    1 0        0         93,   2 Jun 17  2002 /dev/nftla2
brw-------    1 0        0         93,   3 Jun 17  2002 /dev/nftla3
brw-------    1 0        0         93,   4 Jun 17  2002 /dev/nftla4
brw-------    1 0        0         93,  16 Jun 17  2002 /dev/nftlb
brw-------    1 0        0         93,  17 Jun 17  2002 /dev/nftlb1
brw-------    1 0        0         93,  32 Jun 17  2002 /dev/nftlc
brw-------    1 0        0         93,  33 Jun 17  2002 /dev/nftlc1
brw-------    1 0        0         93,  48 Jun 17  2002 /dev/nftld
brw-------    1 0        0         93,  49 Jun 17  2002 /dev/nftld1

Do I need to patch the kernel with the latest MTD stuff or should the 
MTD stuff in linuxppc-2.4.18-pre8 be OK ??

Thanks,
Brendan Simon.

Re: doc2000 nftl[abcd] devices

[David Woodhouse]

brendan.simon@ctam.com.au said:
>  Now I try the same thing with nftlb and I get errors saying "Cannot
> open  disk drive".  It should be the same process shouldn't it ?  Any
> ideas of  where to look to fix or debug this ??  I've had a look at
> nftldump and I  can see the 3 sets of media headers and they seem like
> they are in the  right place.

It should be the same process, yes -- although perhaps you might want a 
file system directly on each NFTL device, rather than partitioning them. 

Stick some debugging printks into the nftl_open routine to see why it fails.
(Or just enable debugging so the existing ones happen.)

--
dwmw2

Re: doc2000 nftl[abcd] devices

[Brendan J Simon]

David Woodhouse wrote:

>brendan.simon@ctam.com.au said:
>
>> Now I try the same thing with nftlb and I get errors saying "Cannot
>>open  disk drive".  It should be the same process shouldn't it ?  Any
>>ideas of  where to look to fix or debug this ??  I've had a look at
>>nftldump and I  can see the 3 sets of media headers and they seem like
>>they are in the  right place.
>>
>
>It should be the same process, yes -- although perhaps you might want a 
>file system directly on each NFTL device, rather than partitioning them. 
>
>Stick some debugging printks into the nftl_open routine to see why it fails.
>(Or just enable debugging so the existing ones happen.)
>
<6>NFTL_open
<6>ENODEV: nftlnum = 1, thisNFTL = 0, minor = 16, ip = c3e56ba0, fp = 
c0192820
<6>NFTL_open
<6>ENODEV: nftlnum = 1, thisNFTL = 0, minor = 16, ip = c3e56ba0, fp = 
c0192820

I'm getting ENODEV.  It seems that the NFTLs[] array doesn't have the 
appropriate information.  How is this setup ?  I'm using modules so is 
it initialised so I assume it's initialised when I do an "insmod nftl". 
 Which routine scans the DOC2000 for NFTL devices and initialises the 
NFTLs[] array.  Interesting how nftl_open is called twice.  I'm not sure 
why ?

Here is a more detailed log:

# insmod nftl
Using /lib/modules/2.4.18-pre8/kernel/drivers/mtd/nftl.o
NFTL driver: nftlcore.c $Revision: 1.3 $, nftlmount.c $Revision: 1.6 $
NFTL_notify_add for DiskOnChip 2000
mtd->read = c500ac6c, size = 8388608, erasesize = 8192
NFTL_setup
Partition check:
 (== 0x%lx sects)
a:<6>NFTL_request
NFTL Read  request, from sector 0x0000 for 0x0002 sectors
Waiting for mutex
Got mutex
NFTL read request of 0x2 sectors @ 0 (req->nr_sectors == 8)
NFTL read request completed OK
end_request(1)
NFTL_request
NFTL Read  request, from sector 0x0002 for 0x0002 sectors
Waiting for mutex
Got mutex
NFTL read request of 0x2 sectors @ 2 (req->nr_sectors == 6)
NFTL read request completed OK
end_request(1)
NFTL_request
NFTL Read  request, from sector 0x0004 for 0x0002 sectors
Waiting for mutex
Got mutex
NFTL read request of 0x2 sectors @ 4 (req->nr_sectors == 4)
NFTL read request completed OK
end_request(1)
NFTL_request
NFTL Read  request, from sector 0x0006 for 0x0002 sectors
Waiting for mutex
Got mutex
NFTL read request of 0x2 sectors @ 6 (req->nr_sectors == 2)
NFTL read request completed OK
end_request(1)
 p1
devfs_register(disc): NULL ops, got c5017c8c from major table
devfs_register(part1): NULL ops, got c5017c8c from major table

#
#
# /util-linux/bin/fdisk /dev/nftlb
NFTL_open
ENODEV: nftlnum = 1, thisNFTL = 0, minor = 16, ip = c3e56ba0, fp = c0192820
NFTL_open
ENODEV: nftlnum = 1, thisNFTL = 0, minor = 16, ip = c3e56ba0, fp = c0192820

Unable to open /dev/nftlb
# grep -i nftl /proc/kmsg
<6>NFTL driver: nftlcore.c $Revision: 1.3 $, nftlmount.c $Revision: 1.6 $
<6>NFTL_notify_add for DiskOnChip 2000
<6>NFTL_setup
<4>a:<6>NFTL_request
<6>NFTL Read  request, from sector 0x0000 for 0x0002 sectors
<6>NFTL read request of 0x2 sectors @ 0 (req->nr_sectors == 8)
<6>NFTL read request completed OK
<6>NFTL_request
<6>NFTL Read  request, from sector 0x0002 for 0x0002 sectors
<6>NFTL read request of 0x2 sectors @ 2 (req->nr_sectors == 6)
<6>NFTL read request completed OK
<6>NFTL_request
<6>NFTL Read  request, from sector 0x0004 for 0x0002 sectors
<6>NFTL read request of 0x2 sectors @ 4 (req->nr_sectors == 4)
<6>NFTL read request completed OK
<6>NFTL_request
<6>NFTL Read  request, from sector 0x0006 for 0x0002 sectors
<6>NFTL read request of 0x2 sectors @ 6 (req->nr_sectors == 2)
<6>NFTL read request completed OK
<6>NFTL_open
<6>ENODEV: nftlnum = 1, thisNFTL = 0, minor = 16, ip = c3e56ba0, fp = 
c0192820
<6>NFTL_open
<6>ENODEV: nftlnum = 1, thisNFTL = 0, minor = 16, ip = c3e56ba0, fp = 
c0192820

Thanks,
Brendan Simon.

Re: doc2000 nftl[abcd] devices

[David Woodhouse]

brendan.simon@ctam.com.au said:
> I'm getting ENODEV.  It seems that the NFTLs[] array doesn't have the
> appropriate information.  How is this setup ?  I'm using modules so is
>  it initialised so I assume it's initialised when I do an "insmod
> nftl". 
>  Which routine scans the DOC2000 for NFTL devices and initialises the
> NFTLs[] array. 

NFTL_setup() from nftlcore.c and NFTL_mount() from nftlmount.c.

Looking at them more closely, I see that I was mistaken -- we _don't_ 
continue the scan after finding the first NFTL on the device. Patching 
NFTL_mount() and find_boot_record() to take a 'start' argument for where to 
start scanning is simple enough -- you just need to fix NFTL_setup() to 
loop till NFTL_mount() stops working.

--
dwmw2

Re: doc2000 nftl[abcd] devices

[Brendan J Simon]

David Woodhouse wrote:

>brendan.simon@ctam.com.au said:
>
>>I'm getting ENODEV.  It seems that the NFTLs[] array doesn't have the
>>appropriate information.  How is this setup ?  I'm using modules so is
>> it initialised so I assume it's initialised when I do an "insmod
>>nftl". 
>> Which routine scans the DOC2000 for NFTL devices and initialises the
>>NFTLs[] array. 
>>
>
>NFTL_setup() from nftlcore.c and NFTL_mount() from nftlmount.c.
>
>Looking at them more closely, I see that I was mistaken -- we _don't_ 
>continue the scan after finding the first NFTL on the device. Patching 
>NFTL_mount() and find_boot_record() to take a 'start' argument for where to 
>start scanning is simple enough -- you just need to fix NFTL_setup() to 
>loop till NFTL_mount() stops working.
>
I expect it's not as easy as you suggest (at least for me as all this 
MTD, NFTL stuff is doing my head in).
In NFTL_mount, it uses the number of blocks supplied to it as 
nftl->nb_blocks.  This is set in NFTP_setup() just before NFTL_mount is 
called.  I think this is currently set to the entire mtd device (ie. the 
DOC).  I'll put some more printks to find out exactly what it is doing :)
I guess the alternative to is to scan from some start address till the 
next media headers are found, then the size is known and it can be 
passed backed to NFTL_setup (directly or indirectly).

Does this sound right ?

What about holes in the DOC.  ie.  What if I have nftl_formatted between 
0x00000000-0x01FFFFFF & 0x04000000-0x7FFFFFFF.  This has a hole between 
0x02000000-0x03FFFFFF.  Does NFTL_mount cater for this ?  Should it ? 
 If so, does this mean that the Media Header needs to be searched to 
find the start of the partition and then the next Media Header to find 
the end of the partition.  This seems wrong because the first partition 
would be recognised as 4MB instead of 2MB.  There must be some info in 
the media headers that give the size of the partition.  Any clues ? 
 I'll do some more research in the mean time.

Thanks,
Brendan Simon.

Re: doc2000 nftl[abcd] devices

[Brendan J Simon]

>
>
>> Looking at them more closely, I see that I was mistaken -- we _don't_ 
>> continue the scan after finding the first NFTL on the device. 
>> Patching NFTL_mount() and find_boot_record() to take a 'start' 
>> argument for where to start scanning is simple enough -- you just 
>> need to fix NFTL_setup() to loop till NFTL_mount() stops working.
>>
> I expect it's not as easy as you suggest (at least for me as all this 
> MTD, NFTL stuff is doing my head in).
> In NFTL_mount, it uses the number of blocks supplied to it as 
> nftl->nb_blocks.  This is set in NFTP_setup() just before NFTL_mount 
> is called.  I think this is currently set to the entire mtd device 
> (ie. the DOC).  I'll put some more printks to find out exactly what it 
> is doing :)
> I guess the alternative to is to scan from some start address till the 
> next media headers are found, then the size is known and it can be 
> passed backed to NFTL_setup (directly or indirectly).
>
> Does this sound right ?
>
> What about holes in the DOC.  ie.  What if I have nftl_formatted 
> between 0x00000000-0x01FFFFFF & 0x04000000-0x7FFFFFFF.  This has a 
> hole between 0x02000000-0x03FFFFFF.  Does NFTL_mount cater for this ?  
> Should it ? If so, does this mean that the Media Header needs to be 
> searched to find the start of the partition and then the next Media 
> Header to find the end of the partition.  This seems wrong because the 
> first partition would be recognised as 4MB instead of 2MB.  There must 
> be some info in the media headers that give the size of the 
> partition.  Any clues ? I'll do some more research in the mean time. 


Does it make sense to put an nb_block_start in the NFTLRecord structure 
or would it better to pass this information to the NFTL_mount() and 
find_boot_records() functions.

When reading information from nftlb, nftlbc, etc, how does the device 
driver know where the first block of the device is ?
Does it need to know or does it use some of the other variables such as 
EUN, VUN, etc.

Thanks,
Brendan Simon.

Re: doc2000 nftl[abcd] devices

[David Woodhouse]

brendan.simon@ctam.com.au said:
>  Does it make sense to put an nb_block_start in the NFTLRecord
> structure  or would it better to pass this information to the
> NFTL_mount() and  find_boot_records() functions.

> When reading information from nftlb, nftlbc, etc, how does the device
> driver know where the first block of the device is ? Does it need to
> know or does it use some of the other variables such as  EUN, VUN,
> etc.

In general, the MediaHeader block is the first block of the NFTL. The 
MediaHeader does contain information on the size of the NFTL, so in the 
case you described before, you should get the correct results.

Suggested plan for NFTL_setup is to start scanning at the beginning, 
calling find_boot_record(s, 0), then if find_boot_record finds one, then 
set it up accordingly and then call find_boot_record(s, <xxx>) again, where 
<xxx> is the sector after the end of the NFTL it just found.

Obviously you need to extend find_boot_record() to take a second argument
too. That's a two-line change.

--
dwmw2