Hi Stefano, I am trying to read the Flash using the predefined MTD partitions. Although my board it is not the Sequoia one, the Memory Map for the NOR Flash memory is the same.
I am using the partitions scheme defined at the drivers/mtd/maps/sequoia.c file, although I will update it with my own scheme. After booting the system, only "mtd" and "mtd1" are present at /dev folder. As far as I have found at the Internet, I can use a filesystem over those partitions or use them as a character device. But I have not found yet how to create a device for the MTD partitions. Should I have to create a new character device at /dev folder and then mount the MTD partitions? If I try the provided command "dd if=/dev/mtd1 | hexdump -C"I get a kernel panic error, so this mtd1 device is not correct. Regards, Alberto 2010/11/26 Stefano Babic <[email protected]> > On 11/26/2010 09:16 AM, Alberto Caballero wrote: > > Hi, > > > > Hi, > > > Just a clarification: I used U-Boot to store the image at the Flash > memory. > > Then, using the U-Boot command line I am able to see the contents of the > > memory. > > At this point we are sure that the flash has the correct contents and > can be accessed. However, we cannot make any assumptions about what > happens in linux. > > > So the U-Boot operation has nothing to do with any memory mapping. > > Right. The kernel driver is then responsible to work with the flash. > Surely the flash is accessed by MTD when the system boots to recognize > the chip type, and at least the CFI-Query command is sent. > > > This is just a way of checking that the bytes are there directly > accessing > > the physical memory. > > > > Although the EP440xS board is currently unsupported, I cannot understand > why > > the access to the mmap returned pointer is wrong. Is there a particular > mmap > > code for each board type? Would it have something to do with issuing > > commands to the flash memory? > > You are thinking that your flash memory works exactly as RAM, and even > with NOR flash this is not always the case. As example, I already told > you that if the MTD driver let the flash in a different status as result > of the CFI-Query command, you do not read the flash contents. And you > are not taking care that the flash cannot be accessed if another > operation (for example, erasing sectors: do you have jffs2 on another > partition ?) is running. The MTD take care with a mutex on a whole chip > if there are operations that do not allow to access the chip, and the > calling process is blocked until the chip becomes available. Maybe there > is a race condition, or maybe support for your board is broken. Reading > the flash via MTD you can check that. > > Accessing the flash with mmap on /dev/men is a fast way to get into > trouble, as you have two actors (your code and the MTD driver) working > on the same physical resource, maybe at the same time. > > Best regards, > Stefano Babic > > -- > ===================================================================== > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [email protected] > ===================================================================== >
_______________________________________________ eldk mailing list [email protected] http://lists.denx.de/mailman/listinfo/eldk
