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
next prev parent 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 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.