public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: "Kári Davíðsson" <kd@flaga.is>
Cc: mtd@infradead.org, nico@cam.org
Subject: Re: partitions and erase regions
Date: Mon, 23 Apr 2001 15:10:36 +0100	[thread overview]
Message-ID: <12790.988035036@redhat.com> (raw)
In-Reply-To: <EADB10BAC266A14A85ECBF8686A73E310A9128@kolkrabbi.flaga.is>


kd@flaga.is said:
>  For my chip I have to fit bootrom in the first 0x20000 kb. The first
> 0x10000 are 8 0x2000 sized sectors while the next 0x10000  is one
> sector of size 0x10000. Because of the "stupid" way of reporting the
> chip with only one sectorsize (mtd.erasesize) I am  unable to erase
> and otherwaise manage this part of the chip. The natural solution to
> me is to make the first part of the chip a partition with two erase
> regions, i.e. the first with erase size 0x2000 and 8 sectors and the
> next with erase size 0x10000 and 1 sector. 

(delayed reaction)

How about the following rules/behaviour for MTD partitions:

 1. For a partition to be writable, there must be a number usable as 'major'
	erasesize (mtd->erasesize), such that a naïve user of MTD can get 
	erases at offsets such that offset % erasesize == 0 to work.
 2. If a partition covers regions of the master which have differing 
	erasesizes, the information about the exact erase regions should
	be made available in the slave.

So... given a master device with 'major' erasesize 64K, which is actually 
8*8K, 15*64K, this would be the result of some example partitions...

 Partition range   Erase size(s)      Writable?

 000000 - 020000  64K (8*8K, 1*16K)	Yes
 020000 - 100000  64K			Yes

 000000 - 008000  8K			Yes
 008000 - 100000  -			No (no usable 'major' erasesize) 

 000000 - 010000  8K			Yes
 010000 - 100000  64K			Yes

 008000 - 010000  8K			Yes

Kári, if this is acceptable for your purposes (and I think it is), then we 
should just implement this behaviour and not have any conditional code at 
all.

/me wanders off to kick some sense into the new Red Hat 7.1 installation, 
which has taken it upon itself to randomly start correcting my spelling to 
some foreign language, and no longer approves of the word 'behaviour'.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

  reply	other threads:[~2001-04-23 14:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-30 22:56 partitions and erase regions Kári Davíðsson
2001-04-23 14:10 ` David Woodhouse [this message]
     [not found] <EADB10BAC266A14A85ECBF8686A73E3145911F@kolkrabbi.flaga.is>
2001-04-27 11:20 ` David Woodhouse
  -- strict thread matches above, loose matches on Subject: below --
2001-04-25  9:36 Kári Davíðsson
2001-04-27 10:58 ` David Woodhouse
2001-04-24 10:29 Kári Davíðsson
2001-04-24 17:41 ` David Woodhouse
2001-03-30 22:47 Kári Davíðsson
2001-03-30 16:06 Kári Davíðsson
2001-03-30 17:52 ` Nicolas Pitre
2001-03-29 17:03 Kári Davíðsson

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=12790.988035036@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=kd@flaga.is \
    --cc=mtd@infradead.org \
    --cc=nico@cam.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox