All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan J Simon <brendan.simon@ctam.com.au>
To: Linux MTD <linux-mtd@lists.infradead.org>
Subject: Re: doc2000 nftl[abcd] devices
Date: Fri, 21 Jun 2002 16:01:46 +1000	[thread overview]
Message-ID: <3D12C14A.7050903@ctam.com.au> (raw)
In-Reply-To: 3D12BAE1.3050400@ctam.com.au

>
>
>> 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.

  reply	other threads:[~2002-06-21  6:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-20  4:52 doc2000 nftl[abcd] devices Brendan J Simon
2002-06-20  9:03 ` David Woodhouse
2002-06-21  0:41   ` Brendan J Simon
2002-06-21  0:53     ` David Woodhouse
2002-06-21  5:34       ` Brendan J Simon
2002-06-21  6:01         ` Brendan J Simon [this message]
2002-06-21  7:11           ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D12C14A.7050903@ctam.com.au \
    --to=brendan.simon@ctam.com.au \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.