Re: doc2000 nftl[abcd] devices

[Brendan J Simon <brendan.simon@ctam.com.au>]

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.