headers
Pavel Roskin | 1 Nov 2002 03:06
Picon

Adding devices at runtime

Hello!

If I understand correctly, the MTD driver allows to define two devices in
predefined memory areas - one using the CFI driver (CONFIG_MTD_PHYSMAP),
the other using the MTDRAM driver (CONFIG_MTD_MTDRAM).

What if I want more MTD devices in the known memory areas?  Can I register
them at runtime, when the kernel is loaded?  Is it possible to do it
without using modules?  Can I do it without changing the kernel (I mean 
something like "echo 200000 20000 2 >/proc/mtd").

I realize that the question is very basic, but my search for "add" and
"register" in the HOWTO from CVS didn't bring any positive results.

Can it be that I want something wrong?  I simply want to boot from one
flash device and be able to access (and possibly rewrite) that device and
another device.  Both are supported by the JEDEC driver
(CONFIG_MTD_JEDECPROBE), but they use different (not adjacent) memory
areas.  (Of course I hacked drivers/mtd/maps/physmap.c to probe
"jedec_probe", but I know that it's already done right in MTD CVS.)

Right now I have to use the MTDRAM driver on the boot device, so the I
cannot rewrite it (I haven't tried, but I don't expect it to work).  I can
only rewrite the other chip.

--

-- 
Regards,
Pavel Roskin
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jörn Engel | 1 Nov 2002 04:30
Picon

Re: Adding devices at runtime

On Thu, 31 October 2002 21:06:51 -0500, Pavel Roskin wrote:
> If I understand correctly, the MTD driver allows to define two devices in
> predefined memory areas - one using the CFI driver (CONFIG_MTD_PHYSMAP),
> the other using the MTDRAM driver (CONFIG_MTD_MTDRAM).
> 
> What if I want more MTD devices in the known memory areas?  Can I register
> them at runtime, when the kernel is loaded?  Is it possible to do it
> without using modules?  Can I do it without changing the kernel (I mean 
> something like "echo 200000 20000 2 >/proc/mtd").
> 
> I realize that the question is very basic, but my search for "add" and
> "register" in the HOWTO from CVS didn't bring any positive results.
> 
> Can it be that I want something wrong?  I simply want to boot from one
> flash device and be able to access (and possibly rewrite) that device and
> another device.  Both are supported by the JEDEC driver
> (CONFIG_MTD_JEDECPROBE), but they use different (not adjacent) memory
> areas.  (Of course I hacked drivers/mtd/maps/physmap.c to probe
> "jedec_probe", but I know that it's already done right in MTD CVS.)
> 
> Right now I have to use the MTDRAM driver on the boot device, so the I
> cannot rewrite it (I haven't tried, but I don't expect it to work).  I can
> only rewrite the other chip.

Could you be a little more verbose on what your problem is? What kind
of mtd devices do you have, what do you want to do with them, why
register one of them at runtime,...

Something really high level would be nice, too. "I want to run linux
on a d-box and write some data to a cf-card once a day.", something
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pavel Roskin | 1 Nov 2002 06:45
Picon

Re: Adding devices at runtime

Hello!

> > Right now I have to use the MTDRAM driver on the boot device, so the I
> > cannot rewrite it (I haven't tried, but I don't expect it to work).  I can
> > only rewrite the other chip.
> 
> Could you be a little more verbose on what your problem is? What kind
> of mtd devices do you have, what do you want to do with them, why
> register one of them at runtime,...

Sorry, I cannot be more verbose about the device.  I was saying "at
runtime" because I don't need the second chip for the boot process.  I
don't care if it's done at runtime or I hardcode the address into the
kernel.  However, I did check the Config.in and I know that the kernel
only takes parameters for one chip and one MTDRAM device.

> It is possible to register devices at runtime. But I don't know of any
> driver that gives you an interface to do so without insmod'ing it. A
> question of some 50 lines of code to add that functionality.

I have those lines (perhaps they are not very pretty), but I was wondering
if there is "the right way" to do it.  I gather from your that it's called
insmod.  That's fine.

I guess another solution would be writing a map for the device, just like
those little C files under drivers/mtd/maps/

Thank you for reply!

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jörn Engel | 1 Nov 2002 06:50
Picon

Re: Adding devices at runtime

On Fri, 1 November 2002 00:45:59 -0500, Pavel Roskin wrote:
> Sorry, I cannot be more verbose about the device.  I was saying "at
> runtime" because I don't need the second chip for the boot process.  I
> don't care if it's done at runtime or I hardcode the address into the
> kernel.  However, I did check the Config.in and I know that the kernel
> only takes parameters for one chip and one MTDRAM device.
> 
> > It is possible to register devices at runtime. But I don't know of any
> > driver that gives you an interface to do so without insmod'ing it. A
> > question of some 50 lines of code to add that functionality.
> 
> I have those lines (perhaps they are not very pretty), but I was wondering
> if there is "the right way" to do it.  I gather from your that it's called
> insmod.  That's fine.
> 
> I guess another solution would be writing a map for the device, just like
> those little C files under drivers/mtd/maps/

Yes, yet another mapping driver sound like the way to go, judging from
the information you provided.

Jörn

--

-- 
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000
Permalink | Reply | 0 comments |
headers
Anders Olsson | 1 Nov 2002 08:58

MTD devices at the wrong place

I'm using Linux 2.4.19-rmk4 with mtd from CVS on a 7312 (Cogent board).
I have written a JFFS2 image in the flash and tried to mount it. When
this didn't work I thought that just writing somthing to the
corresponding mtd character device could be a sensible test to do. But
that only destroyed my bootloader (ARMBoot) on address 0.

Next atempt, I reinstalled the bootloader and erased the entire flash.
Loaded linux and wrote to the mtd4 character device. Then I dumped the
entire flash with my MultiICE to see where my written file was.
The file had been written at the start of the flash memory 0x00000000
and not at 0x00240000 where I thought it would be. Whats wrong here?

Starting kernel ...

cleanup_before_linux(bd);
flush_all_caches()
going to execute: theKernel(0, 83 );
Linux version 2.4.19-rmk4 (Anders <at> Europa) (gcc version 2.95.3 20010315
(release)) #12 Thu Oct 31 15:41:23 CET 2002
CPU: ARM ARM720T revision 2
Machine: Cirrus Logic EDB7312 (EP7312 evaluation board)
Ignoring unrecognised tag 0x00000000
Security risk: creating user accessible mapping for 0x30000000 at
0xfd000000
Security risk: creating user accessible mapping for 0x20000000 at
0xfc000000
Security risk: creating user accessible mapping for 0x00000000 at
0xfb000000
On node 0 totalpages: 4096
zone(0): 4096 pages.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Eugene Surovegin | 1 Nov 2002 09:28

Re: MTD devices at the wrong place

At 11:58 PM 10/31/2002, you wrote:

>##I guess it's ok to just create one device? or do I have to create them
>all? Or a directory structure under /dev/mtd0 and /dev/mtd1
>mknod /dev/mtd4 c 90 4

/dev/mtd4 should be c 90 8

  Eugene Surovegin <mailto:ebs <at> innocent.com>
Permalink | Reply | 5 comments |
headers
Alex Bennee | 1 Nov 2002 12:24

Pointer to documentation request

Hi,

I know I've seen this somewhere before but I'm having no joy picking
through the MTD site so I'm resorting the the list.

Is there a document that describes the steps you take to configure the
partitions of an MTD device. In my case I'm using an AMD AM29LV160D but
as its a CFI device I'm assuming that all I need do is set out the
correct mapping and I should be able to access various sized blocks of
the flash as normal block devices.

Is there a pointer to a HOWTO or some such to *using* MTD devices
anywhere?

Regards,

Alex.
Permalink | Reply | 0 comments |
headers
Jörn Engel | 1 Nov 2002 23:36
Picon

Re: MTD devices at the wrong place

On Fri, 1 November 2002 00:28:22 -0800, Eugene Surovegin wrote:
> At 11:58 PM 10/31/2002, you wrote:
> 
> >##I guess it's ok to just create one device? or do I have to create them
> >all? Or a directory structure under /dev/mtd0 and /dev/mtd1
> >mknod /dev/mtd4 c 90 4
> 
> /dev/mtd4 should be c 90 8

Correction:
/dev/mtd4 *should be* c 90 4, but for historical reasons, it is c 90 8.

Jörn

--

-- 
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens
Permalink | Reply | 0 comments |
headers
Eugene Surovegin | 1 Nov 2002 23:46

Re: MTD devices at the wrong place

At 02:36 PM 11/1/2002, JЖrn Engel wrote:
>On Fri, 1 November 2002 00:28:22 -0800, Eugene Surovegin wrote:
> > At 11:58 PM 10/31/2002, you wrote:
> >
> > >##I guess it's ok to just create one device? or do I have to create them
> > >all? Or a directory structure under /dev/mtd0 and /dev/mtd1
> > >mknod /dev/mtd4 c 90 4
> >
> > /dev/mtd4 should be c 90 8
>
>Correction:
>/dev/mtd4 *should be* c 90 4, but for historical reasons, it is c 90 8.

Well, maybe I missing something, but mtdchar.c:

static int mtd_open(struct inode *inode, struct file *file)
{
         int minor = MINOR(inode->i_rdev);
         int devnum = minor >> 1;
         struct mtd_info *mtd;

....

Notice "minor >> 1".

As far as I understand, even numbers are used for rw access, odd - for ro.

Regards,

Eugene
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jörn Engel | 1 Nov 2002 23:53
Picon

Re: MTD devices at the wrong place

On Fri, 1 November 2002 14:46:53 -0800, Eugene Surovegin wrote:
> >> /dev/mtd4 should be c 90 8
> >
> >Correction:
> >/dev/mtd4 *should be* c 90 4, but for historical reasons, it is c 90 8.
> 
> Well, maybe I missing something, but mtdchar.c:
> 
> static int mtd_open(struct inode *inode, struct file *file)
> {
>         int minor = MINOR(inode->i_rdev);
>         int devnum = minor >> 1;
>         struct mtd_info *mtd;
> 
> ....
> 
> Notice "minor >> 1".
> 
> As far as I understand, even numbers are used for rw access, odd - for ro.

Yes, that is the status quo. But that is not, how is *should be*,
merely how it *is*.
There is no point in the -ro devices, they only lead to
misunderstandings like the current one.

Jörn, trying to kill those bastards sind 9/01

--

-- 
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
(Continue reading)

Permalink | Reply | 0 comments |

Gmane