Skip to contentSkip to conversation

MTD for FPGA framegrabber

DISCUSSION Clemens Koller 2 participants 4 messages Jun 3, 2005 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

Hello!

Okay, after some more reading and testing, I try to get an overview of what I am doing :-) I still have some questions which are unclear in the little documentation I've found... see below.

Well, my goal is to use an MTD to access my SRAM in my FPGA at 0xfc000000, size=0x100000 (1MByte) with direct read and write operations (and DMA later on). All that should happen on the Local Bus Controller on an MPC8540 embedded PowerPC CPU. The goal is to get direct io / bulk data transfers via DMA as fast as possible. (It looks like I need MTD_WRITEB_WRITEABLE)

Currently, all my stuff is compiled as modules to be able to play around with all that things.
First, I wrote a little module which sets my Local Bus Windows to generate the right chipselects and timings... which seems to work fine.

Then I tried to start the MTD stuff:

# modprobe mtdchar
	loads mtdcore also... okay!
# modprobe map_rom
	loads chipreg also... okay!
# modprobe physmap
	probes my SRAM area via map_rom and adds mtd_to mtdcore, so I get
	two devices: /dev/mtd/0 and /dev/mtd/0ro

Okay, I'm wondering why do I get the 0ro device, too?

Now I can read from 0 and 0ro and I get data read from my SRAM. But I cannot write to that area.

Okay, I've tried to use mtd_ram instead of mtd_rom, but then I cannot
load physmap:
FATAL: Error inserting physmap (/lib/modules/2.6.11.11/kernel/drivers/mtd/maps/physmap.ko): No such device or address

Hmm... okay, if I look into physmap.c it seems like as it won't use the mtd_ram probe for my SRAM:

First line of static int __init init_physmap(void):

	static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };

Is that correct?
Can I just use map_ram instead of the others and do I then end up with a r/w device? Or do I need more?

I also thought about a mixture of the mtdram and physmap driver? Well, I've had a look at the latest CVS and realized that there are plenty of drivers available. But do I need to write one of my own or can I just recycle some other code?
Can you give me a good starting point in the sources?

Maybe some of you can just give me some raw directions or correct me if I am at the wrong trail with my plans above?!.

Thanks in advance,
best greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

#1 lore raw
Quoted 6 lines · Clemens Koller

Then I tried to start the MTD stuff:

# modprobe mtdchar
	loads mtdcore also... okay!
# modprobe map_rom
	loads chipreg also... okay!

Bullshit!

Quoted 3 lines
# modprobe physmap
	probes my SRAM area via map_rom and adds mtd_to mtdcore, so I get
	two devices: /dev/mtd/0 and /dev/mtd/0ro

Bullshit!

Since you want to access sram, you want to create a standalone mtd driver, similar to phram. As a starter, you can simply use phram and switch from memcpy() to dma later.

Jörn

Signature · 3 lines
When you close your hand, you own nothing. When you open it up, you
own the whole world.
-- Li Mu Bai in Tiger & Dragon
#2 lore raw
Quoted 2 lines · Jörn Engel

Bullshit!

Several people accused me of being impolite. So here is a polite version of the same:

1. You're barking up the wrong tree.
2. Try phram instead.

Jörn

Signature · 3 lines
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
#3 lore raw
In reply to Jörn Engel

Hi, Joern!

Okay... it seems to be my lucky day.
I know that using map_rom was bullsomething.

Quoted 3 lines

Since you want to access sram, you want to create a standalone mtd driver, similar to phram. As a starter, you can simply use phram and switch from memcpy() to dma later.

Well, my idea was to use map_ram also instead of map_rom... and instead of patching around in physmap, I copied the code which looked essential to me out of physmap and phram and some others like the sram part of cdb89712.c... into my own driver... and... voila! It works! Which means that I get read and write accesses on my local bus. :-)

Just FYI:
-----8<----------------------------------------------------------------- static struct mtd_info *ecam_mtd;

struct map_info ecam_map = {
        .name = "eCam FPGA-SRAM",
        .phys = 0xfc000000,
        .size = 0x00100000,
        .bankwidth = 4,
        .virt = NULL,
};

static int mminfo_mtdinit(void)

{
        int err;

        DBG("----- mtdinit()\n");
        DBG("Anagramm eCam MTD: FPGA-SRAM 0x%lX at 0x%lX\n",ecam_map.size,ecam_map.phys);

        ecam_map.virt = ioremap(ecam_map.phys, ecam_map.size);
        if (!ecam_map.virt) {
                DBG("Failed to ioremap FPGA-SRAM space\n");
                err = -EIO;
                goto out;
        }
        simple_map_init(&ecam_map);
        ecam_mtd = do_map_probe("map_ram", &ecam_map);
        if (!ecam_mtd) {
                DBG("FPGA-SRAM probe failed\n");
                err = -ENXIO;
                goto out_ioremap;
        }
        ecam_mtd->owner = THIS_MODULE;
        ecam_mtd->erasesize = 16;
        if (add_mtd_device(ecam_mtd)) {
                DBG("FGPA-SRAM device addition failed\n");
                err = -ENOMEM;
                goto out_probe;
        }
        return 0;
out_probe:
        map_destroy(ecam_mtd);
        ecam_mtd = 0;
out_ioremap:
        iounmap((void *)ecam_map.virt);
out:
        return err;
}

static void mminfo_mtdexit(void)
{

        DBG("----- mtdexit()\n");
        del_mtd_device(ecam_mtd);
        map_destroy(ecam_mtd);
        iounmap((void *)ecam_map.virt);
}

-----8<-----------------------------------------------------------------

I don't have separate read and write routines yet... I'll see if there is room for more optimization as I want to copy the data from the SRAM directly to the application's memory. (via DMA) As I want to achieve some 100 MBytes/sec.

Maybe I need some special point() functions and this direct io flags? Well... I will see.

Okay, there are still some open questions, but I will have to continue to fix some other things in my hardware first.

Thanks so far,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19