GCC PPC Inline Assembly Help

GCC PPC Inline Assembly Help

[Bob Doyle]

I have an embedded platform (MPC8240) that requires flash memory
be programmed 64-bits at a time.  I believe that a floating-point
store is the only way to generate this 64-bit write.  I also
understand that floating-point usage is prohibited in the kernel
because the floating-point context is not saved.

I'm attempting to create a out64() function that will save 'fr0',
do a 64-bit write using 'fr0', and restore 'fr0'.  See below:

inline void out64(uint64 *addr, uint32 hi, uint32 lo) {
  uint64 fr0save;
  volatile uint32 mem[2];
  mem[0] = hi;
  mem[1] = lo;
  asm volatile (
    "stfd%U0%X0 0,%0\n\t"
    "lfd%U3%X3 0,%3\n\t"
    "stfd%U1%X1 0,%1\n\t"
    "lfd%U2%X2 0,%2\n\t"
    "sync"
    : "=m" (fr0save), "=m" (*addr)
    : "m" (fr0save), "m" (mem[0]), "m" (mem[1])
    : "memory", "fr0");
}

How close am I?  I've looked at the asm and it looks OK but I've
been bitten before by code with wrong constrants that worked most
of the time...  I also found out by accident that the 'volatile'
seems to make the code better.

I noticed a 'z' constraint ("`FPMEM' stack memory for FPR-GPR
transfers") in the gcc info pages but have no clue how to use it.
Any pointers?

I also noticed that 32-bit shifts (concatinating 2 32-bit values to
one 64-bit 'unsigned long long' seems to generate rather poor code.
(That's why the code above has 2 32-bit values).  Am I doing
something wrong?

I'm using gcc 2.95.2

Thanks for any help.

Bob

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GCC PPC Inline Assembly Help

[Dan Malek]

Bob Doyle wrote:
>
> I have an embedded platform (MPC8240) that requires flash memory
> be programmed 64-bits at a time.  I believe that a floating-point
> store is the only way to generate this 64-bit write.  I also
> understand that floating-point usage is prohibited in the kernel
> because the floating-point context is not saved.

Didn't you ask this not long ago?
Why does the flash memory need to be programmed 64-bits at a time?
Did you actually find some devices like this?  If you have 8 8-bit,
or 4 16-bit devices, you can program these one at a time. Oh, that's
right, you didn't design the hardware correctly.........

Why do you have to do this in the kernel?


> How close am I?

Still pretty far off the mark, even if the assembler is OK.  You need
to enable the FPU, which presents another set of problems that can
be somewhat eliminated by disabling interrupts.


If you can't write less than 64-bits, how do you ensure the memory
controller will always generate a cycle to read 64-bits?  Sounds like
you have designed around lots of luck.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GCC PPC Inline Assembly Help

[Bob Doyle]

Dan Malek wrote:
>
> Bob Doyle wrote:
> >
> > I have an embedded platform (MPC8240) that requires flash memory
> > be programmed 64-bits at a time.  I believe that a floating-point
> > store is the only way to generate this 64-bit write.  I also
> > understand that floating-point usage is prohibited in the kernel
> > because the floating-point context is not saved.
>
> Didn't you ask this not long ago?

Nope.  I'll go back through the achives more carefully though.  I'm
probably not the only one to fight this.

> Why does the flash memory need to be programmed 64-bits at a time?

The MPC8240 can only read/write 64 bits at a time when the PortX/Flash
bus is configured to be 64 bits wide.  For executing out of FLASH it's
not a problem, for reads from FLASH it's not a problem, for FLASH writes
it's an issue.  That's how it is.

> Did you actually find some devices like this?  If you have 8 8-bit,
> or 4 16-bit devices, you can program these one at a time.

No you can't!  See below.

>Oh, that's right, you didn't design the hardware correctly.........

Ouch!  I wish.  If this was my doing, I'd have fixed it by now...

The MPC8240 doesn't have 'byte-lane' signals for the FLASH and the
bottom 3 address lines don't even leave the chip in 64-bit FLASH
mode.  It's not my limitation - it's absolutely inherent in the
MPC8240 FLASH bus design.

> Why do you have to do this in the kernel?

Flash file system.

> > How close am I?
>
> Still pretty far off the mark, even if the assembler is OK.  You need
> to enable the FPU, which presents another set of problems that can
> be somewhat eliminated by disabling interrupts.

I figured that out.  I've enabled the FPU and programmed the FLASH
without saving the FP context - that all works.  I'm sure I've
trashed user-space floating-point though...  That's why I'm trying
to force the 64-bit write to use fr0, so I can save/restore it's
value.  Thus the need for inline asm in gcc.

> If you can't write less than 64-bits, how do you ensure the memory
> controller will always generate a cycle to read 64-bits?

It always does.  Even if I do a byte read, the bus cycle is always
the same - the memory controller just chucks the 7 unused bytes and
justifies the byte of interest correctly to the CPU.

> Sounds like you have designed around lots of luck.

Actually I'm using it the way that Circle-M meant it to be used.

Bob

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GCC PPC Inline Assembly Help

[Dan Malek]

Bob Doyle wrote:

> Nope.

Sorry.  I've seen a couple of questions about this lately.

> The MPC8240 can only read/write 64 bits at a time when the PortX/Flash
> bus is configured to be 64 bits wide.

Oh, you tried to find a use for PortX beyond just simple stuff :-).
I thought is was on the 60x bus.

> The MPC8240 doesn't have 'byte-lane' signals for the FLASH

Yes, yes....

> Flash file system.

I was afraid that was the answer :-).


> .....That's why I'm trying
> to force the 64-bit write to use fr0, so I can save/restore it's
> value.  Thus the need for inline asm in gcc.

Or, just write a simple assembler function and stick it in misc.S
or something.  In a past message I responded with the necessary
steps.....disable all exception, enable FPU, save data register,
do your memory operation, restore the data register, disable FPU,
enable exceptions.

The other thing that would work is to copy-back cache the space
and use cache operations to clear and push the cache line.

> Actually I'm using it the way that Circle-M meant it to be used.

Well.....If you notice in any of their documentation, they only
show ROM interfaces in 64-bit mode.  Their Flash examples are either
8- or 32-bit with external logic to decode chip enables.....

Have Fun :-)!


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/