[ELDK] mmap: first byte always wrong

[Alberto Caballero]

Hi,

Ok. As I told you, I checked with another board. So I will try to check
which flash type was there, and then maybe move to the use of /dev/ram to
the MTD driver.

If the code is more complicated than using /dev/ram, it is worthless.

Regards,

Alberto

2010/11/26 Stefano Babic <sbabic at denx.de>

> 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: office at denx.de
> =====================================================================
>