Adrian Filipi <[EMAIL PROTECTED]> wrote:
> Yeah, I agree it's bogus for the pointer to be volatile. There
> shouldn't be anything unusual about that.
>
> The assembler does show several additional memory accesses, so I
> think your theory is right. I'm at a loss for what to to on t
Yeah, I agree it's bogus for the pointer to be volatile. There
shouldn't be anything unusual about that.
The assembler does show several additional memory accesses, so I
think your theory is right. I'm at a loss for what to to on the sync().
Adrian
--
Linux Software E
Adrian Filipi <[EMAIL PROTECTED]> wrote:
> diff -u -r1.1.1.2.2.2 cfi_flash.c
> --- cfi_flash.c 23 Apr 2008 17:02:47 - 1.1.1.2.2.2
> +++ cfi_flash.c 29 Apr 2008 18:55:47 -
> @@ -464,7 +464,7 @@
>uint offset, uchar cmd)
> {
>
> - void *addr;
On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> SOC drivers are encouraged to use them. What a waste :(
sync is needed in some of the cases, to sync I/O accesses with DMA buffer
accesses. Ideally, we cou
On Wed, 2008-04-30 at 11:02 -0500, Scott Wood wrote:
> On Wed, Apr 30, 2008 at 05:34:56PM +0200, Joakim Tjernlund wrote:
> >
> > On Wed, 2008-04-30 at 10:21 -0500, Scott Wood wrote:
> > > On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> > > > Yet the in_bex()/out_bex() function
On Wed, Apr 30, 2008 at 05:34:56PM +0200, Joakim Tjernlund wrote:
>
> On Wed, 2008-04-30 at 10:21 -0500, Scott Wood wrote:
> > On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> > > Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> > > SOC drivers are encou
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> The solution in the PowerPC world is to add a "eieio" or "sync"
>> instruction[1] appropriately[2], which prevents the bus interface unit
>> from reordering the memory operations.
>
> No, the solution for ALL architectures is
In message <[EMAIL PROTECTED]> you wrote:
>
> There need be a get-the-endian-right-but-no-sync. After all
> 2.4 managed well without using the in/out be() functions.
Yes, but try building it with a recent version of GCC and run the
code on some PPC systems. There may be some nasty surp
In message <[EMAIL PROTECTED]> you wrote:
>
> The solution in the PowerPC world is to add a "eieio" or "sync"
> instruction[1] appropriately[2], which prevents the bus interface unit
> from reordering the memory operations.
No, the solution for ALL architectures is to use the appropriate
ac
On Wed, 2008-04-30 at 10:21 -0500, Scott Wood wrote:
> On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> > Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> > SOC drivers are encouraged to use them. What a waste :(
>
> sync is needed in some of the cases,
>
> [1] Sync is a big hammer, eieio is a medium size hammer. Don't use
> both, PPC people will know you don't know what you are doing. ;-)
Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
SOC drivers are encouraged to use them. What a waste :(
Jocke
-
Adrian Filipi wrote:
> On Tue, 29 Apr 2008, Jerry Van Baren wrote:
>
>> Adrian Filipi wrote:
>>> On Tue, 29 Apr 2008, Wolfgang Denk wrote:
>>>
In message <[EMAIL PROTECTED]> you
wrote:
> I narrowed down the source of the problem to the loss of the
> volatile qualifier on th
Adrian Filipi wrote:
> On Tue, 29 Apr 2008, Wolfgang Denk wrote:
>
>> In message <[EMAIL PROTECTED]> you wrote:
>>> I narrowed down the source of the problem to the loss of the
>>> volatile qualifier on the addr pointer in flash_write_cmd(). Adding the
>>> qualifier gets rid of the corruption
Sure, reducing the reliance on volatile is a good idea, but I'm at
a loss for anything better to do.
I'm seeing a real problem that is only fixed by qualifying the
container of the pointer as volatile, i.e. "void *volatile". "volatile
void *" has no effect as expected given th
In message <[EMAIL PROTECTED]> you wrote:
>
> I narrowed down the source of the problem to the loss of the
> volatile qualifier on the addr pointer in flash_write_cmd(). Adding the
> qualifier gets rid of the corruption. In the older 1.2.0 sources, addr was
> declared as "volatile cfipt
hi folks,
I've come across a case on one of our PXA250 boards where the
flash was getting corrupted when using the 1.3.2 version of cfi_flash.c,
while the 1.2.0 version worked just fine.
Here's what happens:
1. Reprogram uboot.
2. Compare uboot in flash against
16 matches
Mail list logo
