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$(echo .)com \
--cc=dan@mvista$(echo .)com \
--cc=linuxppc-embedded@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox