public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Shane Nay <shane@agendacomputing.com>
To: mstumpf@pobox.com, Michael Stumpf <michaelstumpf@yahoo.com>,
	David Woodhouse <dwmw2@infradead.org>,
	shane@agendacomputing.com
Cc: Nicolas Pitre <nico@cam.org>, mstumpf@pobox.com, mtd@infradead.org
Subject: Re: MTD, generic physmap memory, MTD_BLOCK
Date: Tue, 19 Dec 2000 02:51:42 +0000	[thread overview]
Message-ID: <0012190251422T.11759@www.easysolutions.net> (raw)
In-Reply-To: <20001219133239.24180.qmail@web2103.mail.yahoo.com>


> I did some work in the direction suggested by (thanks!) Nicolas--modified
> mtdram.c to act as a conduit device for plain memory.  I did get a
> successful boot from a cramfs rootdisk.
>
> When I said XIP, I didn't realize that this crowd had a very "serious"
> definition of it.  I simply meant I was trying to get around the initrd
> buffering issue:  As far as I can tell, up until now the only mechanism
> that a CPU (with only RAM and ROM visibility) has at its disposal to boot
> from is initrd, that would copy all the ROM image into RAM buffer cache..
> and only understand three file systems (cramfs is not one of them).  I
> don't mind cramfs using a buffer page (4k, LinuxPPC) or two to do its
> work--I was trying to slay the complete-image-copy daemon.  (My embedded
> system is 6 meg RAM, 8 meg ROM.. and I want shared libraries, etc)

It's 32k BTW.  Boot from initrd?..., initial romdisk?..., nope.  Try this 
instead..., /dev/rom.  Patches are on ftp.agendacomputing.com site.  Make a 
cramfs partition with the headers necessary to tag it as a cramfs partition 
(in the scripts/ directory on linux-vr.org ..., mkromfs I think applied to a 
cramfs filesystem)  Then enable /dev/rom, and set it's address at the start 
of the rom.  Then root=/dev/rom as the boot options.

> It seems to me that for the time being and the immediate future, XIP as
> we're talking about it would be overkill.  The streamlining and elegance
> gained in the operation of XIP is probably offset by the ugliness of
> implementation and the potential loss of compression that seems so crucial
> in embedded devices, the primary target (right?) of MTD.  I like XIP but I
> don't think I'd ever use it.

With only 6MB of ram..., it might be a good thing for your device, but I 
don't know what you're planning on running on it.

> One very relevant topic that I'd like to discuss is where a generic memory
> conduit device belongs.  I would suspect it belongs as a fallback default
> if CFI devices can't be probed (I forget the file), but it also might make
> sense to give it a separate file for "neatness" sake.
Thanks,
Shane.


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

  reply	other threads:[~2000-12-19 13:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-19 13:32 MTD, generic physmap memory, MTD_BLOCK Michael Stumpf
2000-12-19  2:51 ` Shane Nay [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-12-13 16:48 Michael Stumpf
2000-12-13 19:02 ` Nicolas Pitre
2000-12-16  1:04   ` Shane Nay
2000-12-17 22:24     ` David Woodhouse
2000-12-18 21:31       ` Shane Nay
2000-12-19  9:24         ` David Woodhouse
2000-12-18 22:35           ` Shane Nay

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=0012190251422T.11759@www.easysolutions.net \
    --to=shane@agendacomputing.com \
    --cc=dwmw2@infradead.org \
    --cc=michaelstumpf@yahoo.com \
    --cc=mstumpf@pobox.com \
    --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