All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nikolai Vladychevski" <niko@isl.net.mx>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: duplicate DoC millenium with dd
Date: Tue, 11 Sep 2001 20:58:53 GMT	[thread overview]
Message-ID: <20010911205853.21285.qmail@qis> (raw)
In-Reply-To: <9772.1000243426@redhat.com>

David Woodhouse writes: 


> 
>> > What are you partitioning it for, btw?
>> It's a firewall. I place linuxbios & kernel first, then I nftl_format
>> /dev/mtd0 0xFIRST_FREE_BLOCK and place a minimal filesystem (cramfs)
>> on the  rest of the chip.....
> 
> You nftl_format it with the offset, which gives you a block device /dev/
> nftla. Then you use sfdisk rather than mkcramfs -o /dev/nftla. If you only 
> have one partition, then a partition table is just a waste of space.

right! thanks, didn't note it.... 

>  
> 
>> since you say nftl_format removes
>> original badblocks  table M-Systems put on the chip at fabrication
>> time, I kinda dislike this  util..... 
> 
> It's now better than it was. And you shouldn't need to use it more than 
> once, if the total size of your LinuxBIOS and kernel don't change (or if 
> you left enough space for a little bit of expansion).

yes, this is the problem... right now I'm leaving 1 Meg for the linuxBIOS 
and kernel and right now there is left as little as 40 K bytes free space of 
that meg. 

I beleive the kernel will grow very soon and 40 K will not be enough. 
Allocating more space, 1.5Meg for example seems to be a huge waste of space.
I think I will have to nftl_format with a variable offset every time I do an 
update..... you say nftl_format is better, but how much? If I update the 
software on the chip once a week (it's an automatic update via remote 
server), will it survive for 2 years without errors, for example ? 

> 
>>  is there any way to avoid nftl_format and boot my cramfs from /dev/
>> mtdblockX  or /dev/mtd0 with an 0xXXXX offset or something like this? 
> 
> Not out of the box. It's trivial to do that though, by using the mtd
> version of partitions, which makes it look like two (or more) separate MTD
> devices. 

Wow! that sounds cool! I have to try it, but would linuxBIOS conflict with 
it? 


Nikolai 

  reply	other threads:[~2001-09-11 21:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-11 18:26 duplicate DoC millenium with dd Nikolai Vladychevski
2001-09-11 20:17 ` David Woodhouse
2001-09-11 20:13   ` Nikolai Vladychevski
2001-09-11 21:23     ` David Woodhouse
2001-09-11 20:58       ` Nikolai Vladychevski [this message]
2001-09-11 22:00         ` David Woodhouse
2001-09-11 22:20           ` Nikolai Vladychevski

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=20010911205853.21285.qmail@qis \
    --to=niko@isl.net.mx \
    --cc=dwmw2@infradead.org \
    --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.