mmio[0] = address;
mmio[1] = data;
mb();
eieio is enough here.
mmio[3] |= 0x01; /* This triggers an operation -> address=data */
/* probably also need an mb() here, if the following code
* depends on the operation to be triggered. */
No, a sync does not guarantee the device has seen the sto
Michael Buesch wrote on 31/10/2009 21:35:31:
>
> On Saturday 31 October 2009 21:14:07 Joakim Tjernlund wrote:
> > Michael Buesch wrote on 31/10/2009 17:42:54:
> > >
> > > On Saturday 31 October 2009 14:26:48 Joakim Tjernlund wrote:
> > > > >
> > > > > > On Friday 30 October 2009 16:08:55 Alessand
On Saturday 31 October 2009 21:14:07 Joakim Tjernlund wrote:
> Michael Buesch wrote on 31/10/2009 17:42:54:
> >
> > On Saturday 31 October 2009 14:26:48 Joakim Tjernlund wrote:
> > > >
> > > > > On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote:
> > > > > > > asm("eieio; sync");
> > > > >
Michael Buesch wrote on 31/10/2009 17:42:54:
>
> On Saturday 31 October 2009 14:26:48 Joakim Tjernlund wrote:
> > >
> > > > On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote:
> > > > > > asm("eieio; sync");
> > > > >
> > > > > Hmm...
> > > > >: : : "memory"
> > > > >
> > > > > And, do
On Saturday 31 October 2009 14:26:48 Joakim Tjernlund wrote:
> >
> > > On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote:
> > > > > asm("eieio; sync");
> > > >
> > > > Hmm...
> > > >: : : "memory"
> > > >
> > > > And, doesn't ";" start a comment in assembly? (no, not on powerpc
> > > i
>
> > On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote:
> > > > asm("eieio; sync");
> > >
> > > Hmm...
> > >: : : "memory"
> > >
> > > And, doesn't ";" start a comment in assembly? (no, not on powerpc
> > it seems)
> >
> > Yes, I think the barrier is wrong.
> > Please try with
> >
> >
On Fri, Oct 30, 2009 at 10:46:46AM -0600, Jonathan Haws wrote:
> > Michael Buesch wrote:
> > > Yes, I think the barrier is wrong.
> > > Please try with
> > >
> > > #define mb() __asm__ __volatile__("eieio\n sync\n" : : :
> > "memory")
> >
> >
> > For uncached memory, eieio should be enough.
> Michael Buesch wrote:
> > Yes, I think the barrier is wrong.
> > Please try with
> >
> > #define mb()__asm__ __volatile__("eieio\n sync\n" : : :
> "memory")
>
>
> For uncached memory, eieio should be enough.
I tried eieio alone and it did not work. It needed the above command to take
On Fri, Oct 30, 2009 at 04:08:55PM +0100, Alessandro Rubini wrote:
> > asm("eieio; sync");
>
> Hmm...
> : : : "memory"
>
> And, doesn't ";" start a comment in assembly? (no, not on powerpc it seems)
';' is an instruction separator on all GNU as targets that I'm familiar
with (though a quic
Michael Buesch wrote:
Yes, I think the barrier is wrong.
Please try with
#define mb()__asm__ __volatile__("eieio\n sync\n" : : : "memory")
For uncached memory, eieio should be enough.
Micha
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlab
> On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote:
> > > asm("eieio; sync");
> >
> > Hmm...
> > : : : "memory"
> >
> > And, doesn't ";" start a comment in assembly? (no, not on powerpc
> it seems)
>
> Yes, I think the barrier is wrong.
> Please try with
>
> #define mb() __asm__ __
On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote:
> > asm("eieio; sync");
>
> Hmm...
> : : : "memory"
>
> And, doesn't ";" start a comment in assembly? (no, not on powerpc it seems)
Yes, I think the barrier is wrong.
Please try with
#define mb()__asm__ __volatile__("eieio\n
> asm("eieio; sync");
Hmm...
: : : "memory"
And, doesn't ";" start a comment in assembly? (no, not on powerpc it seems)
Just to make sure, if you replace msync() with another system call,
like "kill(1, 0);" you can verify wether it's really useful or if it's
only acting as a barrier.
/a
> On Friday 30 October 2009 15:50:22 Jonathan Haws wrote:
> > > I suspect that the msync() was merely serving as a very
> heavyweight
> > > memory barrier.
> >
> > I did try hacking the mb() calls from the kernel source to use
> them in user space, but they had no effect. I still had to include
>
On Friday 30 October 2009 15:50:22 Jonathan Haws wrote:
> > I suspect that the msync() was merely serving as a very heavyweight
> > memory barrier.
>
> I did try hacking the mb() calls from the kernel source to use them in user
> space, but they had no effect. I still had to include the calls to
> On Thu, Oct 29, 2009 at 10:00:28AM +0100, Joakim Tjernlund wrote:
> > > I have found the problem. It occurred to me in the shower (okay
> not really,
> > > but most good ideas happen there).
> > >
> > > What was happening is that I was in fact able to write to the
> correct
> > > registers. How
On Thu, Oct 29, 2009 at 10:00:28AM +0100, Joakim Tjernlund wrote:
> > I have found the problem. It occurred to me in the shower (okay not really,
> > but most good ideas happen there).
> >
> > What was happening is that I was in fact able to write to the correct
> > registers. However, I would tr
> Looking through our notes and talking with the engineer
> who was performing the tests, it was exactly that - MTD was waiting
> for a signal that was produced differently than the hardware
> ready signal. By simply polling the flash until the hardware
> ready signal toggled we were able to get
Jonathan,
On 10/28/2009 03:45 PM, Jonathan Haws wrote:
> Looking through our notes and talking with the engineer
> who was performing the tests, it was exactly that - MTD was waiting
> for a signal that was produced differently than the hardware
> ready signal. By simply polling the flash until
> > > Anyway, to make a long story short, I inserted an msync() after
> each
> > > assignment to the flash. This resolved my problem and I can now
> program my flash.
> >
> > Ouch, this was news to me too. Calling msync() after every write
> kills performance.
> > We use mmap(/dev/mem) to access H
> Does O_DIRECT help? (you may need to define _GNU_SOURCE before
> #include)
Nope, O_DIRECT did not help - in fact it caused the application to crash. Why
that is I am not sure, but it crashed.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.o
> On Tue, Oct 27, 2009 at 04:52:40PM -0600, Jonathan Haws wrote:
> > > Will the device respond to 0x1234 being written at offset zero?
> You
> > > generally have to poke these things pretty specifically in order
> to
> > > get
> > > them to go into command mode.
> > >
> >
> > It should because that
On Tue, Oct 27, 2009 at 04:52:40PM -0600, Jonathan Haws wrote:
> > Will the device respond to 0x1234 being written at offset zero? You
> > generally have to poke these things pretty specifically in order to
> > get
> > them to go into command mode.
> >
>
> It should because that is the first dat
On Thu, 2009-10-29 at 10:00 +0100, Joakim Tjernlund wrote:
> >
> > > > On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> > > > >> >>> How can I get that pointer? Unfortunately I cannot simply
> > > > use
> > > > >> the
> > > > >> >>>
> > > > >> >> address of the flash. Is there som
>
> >
> > > > On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> > > > >> >>> How can I get that pointer? Unfortunately I cannot simply
> > > > use
> > > > >> the
> > > > >> >>>
> > > > >> >> address of the flash. Is there some magical function call
> > > > that
> > > > >> >> gives
>
> > > On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> > > >> >>> How can I get that pointer? Unfortunately I cannot simply
> > > use
> > > >> the
> > > >> >>>
> > > >> >> address of the flash. Is there some magical function call
> > > that
> > > >> >> gives me access to that po
> > On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> > >> >>> How can I get that pointer? Unfortunately I cannot simply
> > use
> > >> the
> > >> >>>
> > >> >> address of the flash. Is there some magical function call
> > that
> > >> >> gives me access to that portion of the memor
> On Tue, 2009-10-27 at 16:52 -0600, Jonathan Haws wrote:
> > > Jonathan Haws wrote:
> > > > I had thought about using MTD, but decided against it because
> with
> > > > previous benchmarking that we did with MTD and our custom
> driver,
> > > we
> > > > found that our custom driver was about 10x f
> On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> >> >>> How can I get that pointer? Unfortunately I cannot simply
> use
> >> the
> >> >>>
> >> >> address of the flash. Is there some magical function call
> that
> >> >> gives me access to that portion of the memory space?
> >> >>
On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
>> >>> How can I get that pointer? Unfortunately I cannot simply use
>> the
>> >>>
>> >> address of the flash. Is there some magical function call that
>> >> gives me access to that portion of the memory space?
>> >>
>> >> $ man 2 mma
On Tue, 2009-10-27 at 16:52 -0600, Jonathan Haws wrote:
> > Jonathan Haws wrote:
> > > I had thought about using MTD, but decided against it because with
> > > previous benchmarking that we did with MTD and our custom driver,
> > we
> > > found that our custom driver was about 10x faster.
> >
> >
> Jonathan Haws wrote:
> >>> flash[0] = 0x1234;
> >>> msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> >>> printf("flash[0] = %#04x\n", flash[0]);
> >>>
> >>> That prints flash[0] = 0x7f45. I have verified that I am
> reading
> >> the correct values. I can display the flash contents
> I realize that. I have a driver written that does exactly that.
> However, I need to be able to write to certain registers to setup
> the erasure. The driver works perfectly in VxWorks, now I am
> porting it to Linux.
Most likey you are hit by the compiler reordering the accesses and
caching d
Jonathan Haws wrote:
flash[0] = 0x1234;
msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
printf("flash[0] = %#04x\n", flash[0]);
That prints flash[0] = 0x7f45. I have verified that I am reading
the correct values. I can display the flash contents in U-Boot and
7f
> Okay, I now have access to the flash memory, however when I write to
> it the writes do not take.
> (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local
in-ram copy of the data, not to the original one.
/alessandro
> > Okay, I now have access to the flash memory, however when I write
> to it the writes do not take. I have tried calling msync() on the
> mapping to no avail. I have opened the fd with O_SYNC, but cannot
> get things to work right.
> >
> > Here are the calls:
> >
> > int fd = open("/dev/mem
> > Okay, I now have access to the flash memory, however when I write
> to
> > it the writes do not take.
>
>
> > (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
>
> MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local
> in-ram copy of the data, not to the original on
Jonathan Haws wrote:
Okay, I now have access to the flash memory, however when I write to it the
writes do not take. I have tried calling msync() on the mapping to no avail.
I have opened the fd with O_SYNC, but cannot get things to work right.
Here are the calls:
int fd = open("/de
> >>> How can I get that pointer? Unfortunately I cannot simply use
> the
> >>>
> >> address of the flash. Is there some magical function call that
> >> gives me access to that portion of the memory space?
> >>
> >> $ man 2 mmap
> >>
> >> You want MAP_SHARED and O_SYNC.
> >>
> >
> >
> > To use th
> Jonathan Haws wrote:
> >>> How can I get that pointer? Unfortunately I cannot simply use
> the
> >>>
> >> address of the flash. Is there some magical function call that
> >> gives me access to that portion of the memory space?
> >>
> >> $ man 2 mmap
> >>
> >> You want MAP_SHARED and O_SYNC.
> >
Jonathan Haws wrote:
>>> How can I get that pointer? Unfortunately I cannot simply use the
>>>
>> address of the flash. Is there some magical function call that
>> gives me access to that portion of the memory space?
>>
>> $ man 2 mmap
>>
>> You want MAP_SHARED and O_SYNC.
>>
>
>
> > How can I get that pointer? Unfortunately I cannot simply use the
> address of the flash. Is there some magical function call that
> gives me access to that portion of the memory space?
> >
>
> $ man 2 mmap
>
> You want MAP_SHARED and O_SYNC.
To use that I need to have a file descriptor t
Jonathan Haws wrote:
>
> How can I get that pointer? Unfortunately I cannot simply use the address of
> the flash. Is there some magical function call that gives me access to that
> portion of the memory space?
>
$ man 2 mmap
You want MAP_SHARED and O_SYNC.
b.g.
--
Bill Gatliff
b...@bi
I know this is probably a really dumb question, but a wise man once said that
the only stupid question is the one that is not asked.
So, I have written a flash driver in VxWorks that simply addresses the flash
directly and handles all the hardware accesses just fine. I am porting that to
Linux
44 matches
Mail list logo
