From: Bob Doyle <doyle@primenet.com>
To: Dan Malek <dan@mvista.com>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: GCC PPC Inline Assembly Help
Date: Mon, 15 Jan 2001 19:47:16 -0700 [thread overview]
Message-ID: <3A63B634.44E32CF8@primenet.com> (raw)
In-Reply-To: 3A629111.3F36CDE8@mvista.com
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/
next prev parent reply other threads:[~2001-01-16 2:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-15 4:59 GCC PPC Inline Assembly Help Bob Doyle
2001-01-15 5:56 ` Dan Malek
2001-01-16 2:47 ` Bob Doyle [this message]
2001-01-16 4:39 ` Dan Malek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A63B634.44E32CF8@primenet.com \
--to=doyle@primenet.com \
--cc=dan@mvista.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.