public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Riipinen Petri <riipinen@nic.fi>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [Novice] Few simple questions on DOC.
Date: Fri, 17 Aug 2001 10:08:09 +0100	[thread overview]
Message-ID: <20660.998039289@redhat.com> (raw)
In-Reply-To: <Pine.GSO.4.31.0108171144030.404-100000@netti.nic.fi>

riipinen@nic.fi said:
>  1) I found a DOC driver for Linux from M-Systems website. Do I need
> this at all or is everything included in the 2.4.7 kernel? I have read
> the mtd-jffs-HOWTO and configured the kernel accordingly. 

The DiskOnChip driver on the M-Systems website is a different driver. It's 
binary-only, so if you're going to distribute the box you're making, it's 
illegal to link it into the kernel, and it's dubious even whether it's 
legal to use it as a module.

The code in 2.4.7 is slightly out of date - you should update to the latest 
code from CVS which has a couple of useful bug fixes in it. 


>  2) Do I really need to use Lilo/Grub, or can I just write the kernel
> directly into beginning of the DOC to make it boot? I don't need to
> give any parameters to the kernel when booting from hd, so I don't
> really see a need for a boot manager from my point of view.

If you just write the kernel to the beginning of the device, what's going 
to load it? The bootsector built into the kernel is old, probably broken, 
and only designed for use on floppies - I don't think it'll do the job.


>  3) How should I partition the DOC? First a small partition for the
> kernel, and then another partition for the rest of the files? Do I use
> fdisk for that? 

Don't partition it. Just make a filesystem on /dev/nftla and put the kernel 
in that filesystem.


>  4) Maybe I should use jffs on the DOC, can I just make it with mkfs
> -t jffs ...?

JFFS doesn't work on it yet. 

>  5) If I want to write some data into the DOC to keep between boots,
> would it be a good idea to make a small partition (and mount it to /
> var?) and mount that RW and then mount the other partition with other
> files as RO?

No point. NFTL uses the whole device anyway, and partitions within the 
block device wouldn't buy you anything. The NFTL write code ought to be 
fine now anyway - don't be too scared by the help text for CONFIG_NFTL_RW

> 6) To write the kernel bzImage to DOC boot sector, would I just use dd
> if=input of=/dev/mtd ... or what? 

Don't do that. Just use the patched LILO and pretend it's a hard drive.


--
dwmw2

  reply	other threads:[~2001-08-17  9:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-17  9:01 [Novice] Few simple questions on DOC Riipinen Petri
2001-08-17  9:08 ` David Woodhouse [this message]
2001-08-17  9:52   ` Riipinen Petri
2001-08-17  9:57     ` David Woodhouse
2001-08-17 10:05       ` Riipinen Petri
2001-08-17 10:06         ` 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=20660.998039289@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=riipinen@nic.fi \
    /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