From: Neil Russell <hidden> Date: 2000-05-25 03:17:43
We have an FPGA that implements part of the ISA spec, enough to do
programmed I/O to an IDE device. The FPGA has its own chip select and uses
the UPM for timing. It doesn't work correctly yet because what the 8260
documentation says and what the 8260 does are different. When it works,
it will be slow, but we probably don't care - we are not building a
file server.
I'm not sure that we care enough to redesign the logic to make it fast,
but I do care that it doesn't slow everything else down, so at some point
I plan to look to using some form of DMA; perhaps the SDMA that the CPM
provides. It will probably still be slow, but he CPU will no longer be
held up.
Got any better ideas? (no PCI, no expensive chips...).
Neil.
On Wed, May 24, 2000 at 09:22:10PM -0400, Dan Malek wrote:
quoted
console = SMC1. First ported to SBC8260 (EST board), then to custom h/w.
The custom h/w has an IDE interface; I hope to get the whole linux-1999 Q3
working on it; that should be interesting.
Oh oh.....You opened the flood gates for questions now :-). How did
you connect the IDE?
--
Neil Russell [off-list ref]
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-05-25 03:45:27
Neil Russell wrote:
We have an FPGA that implements part of the ISA spec, enough to do
programmed I/O to an IDE device. The FPGA has its own chip select and uses
the UPM for timing.
Interesting....I have used an FPGA or the UPM to provide the ISA
bus timing, but not both at the same time. I have UPM programming
for the 8xx that creates ISA bus timing, so I guess I could try that
on the 8260 as well.....I think it needs an external signal inversion,
but that is all.
......... When it works,
it will be slow, but we probably don't care - we are not building a
file server.
Hmmmm....I'll bet it can be made to work with compact flash as well....
.... It will probably still be slow, but he CPU will no longer be
held up.
Depending upon the data flow, they may still share a common internal
bus....Plus you tie up the CPM.
Got any better ideas? (no PCI, no expensive chips...).
I just gave it away, and I have another project on the pile :-).
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
We have an FPGA that implements part of the ISA spec, enough to do
programmed I/O to an IDE device. The FPGA has its own chip select and uses
the UPM for timing. It doesn't work correctly yet because what the 8260
documentation says and what the 8260 does are different. When it works,
it will be slow, but we probably don't care - we are not building a
file server.
You tell me your HW designers can't operate a logic analyzer?
Be nice. My guess is that they are experiencing some transmission
line failures. It is also hard to reach the /TA line timing
requirements with FPGA. Logical errors are simple to correct.
Reflected waves or responstime errors not quite so. BTW, when you
already have a full FPGA installed then why waste a UPM? A full
local bus decoder does not take that much FPGA space.
And if you do share a /CSn line and only decodes the LS address
bits, then the gates reqirement can be cut in half. This is not
even that hard to do. We do it already in both Altera and Xilinx.
I'm not sure that we care enough to redesign the logic to make it fast,
but I do care that it doesn't slow everything else down, so at some point
I plan to look to using some form of DMA; perhaps the SDMA that the CPM
provides. It will probably still be slow, but he CPU will no longer be
held up.
Got any better ideas? (no PCI, no expensive chips...).
HW FIFOs are always nice to have, even with HDD caches.
Concatenating 16 bit IDE PIO stobes into 32/64 bit PowerPC burst
transfers are likewise not to be foresaken. But this works best for
large datatransfers or else the overhead from "data ready"
interrupts will be expensive. Or one could hook the "data ready"
line up against an IDMA_REQ line instead.
Actually, I am about to implemet this kind of interface for the
MPC860. I have just recived a go from our management on designing
our own scalable MBX860 board. Which means it will be awhile
before I get around to the IDE interface. But to keep power
drain low I will probabely use the second PCMCIA port for it
by means of Xilinx Coolrunner and an AVR for autoconfiguration.
Then I could (but will not) expand this into a full ISA bus.
BTW, VxWorks can not easily handle more than 32 MBytes of local RAM
as the eabi specification (as a result of the PowerPC architecure)
rules for 26 bit (signed) relative addressing. Hence, I will design
in exactly 32 MBytes of soldered low power SDRAM on UPMA and assign
UPMB to a DIMM socket. How does PPC/Linux handle this addressing
problem?
One more - if anyone has the specification for Sony Memorystick
I would be interested. I am pretty certain that this flashstick
has a serial interface on it. Most probabely SPI since Sony use
SPI extensively in the Playstation among others. This would suite
a PowerQUICC just fine, thus avoiding those ATA flash disks
completely. As you should be aware of by now, I am absolutely
no fan of ATA from a HW point of view. And since struggling
with the ATA device drivers in VxWorks, neither from a SW point
of view. Thank you for your attention. But I will nevertheless
design ATA interfaces for the interested parties.
--
******************************************************
Never ever underestimate the power of human stupidity.
-Robert Anson Heinlein
GeirFRS@invalid.and.so.forth
******************************************************
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-05-25 17:30:54
Geir Frode Raanes wrote:
You tell me your HW designers can't operate a logic analyzer?
Hardware designers? This is just software and a few wires :-).
...... BTW, when you
already have a full FPGA installed then why waste a UPM?
You know, I keep hearing this question and continually find boards
with external hardware and no one using the integrated control logic.
Everyone is "saving it for something else". Geeze, these are embedded
systems that will probably never change. After I use up all of the
GP I/O and internal control logic, I will start looking for alternatives.
The 8260 is even better. Separate DRAM controllers so you don't even
use up the UPMs for that, more chip selects, more I/O, multiple busses.
You bought it, may as well use it.
.... But to keep power
drain low I will probabely use the second PCMCIA port for it
by means of Xilinx Coolrunner and an AVR for autoconfiguration.
Then I could (but will not) expand this into a full ISA bus.
Why bother with the Xilinx? Just connect the IDE to the PCMCIA.
I think you could even DMA over the port.
.... How does PPC/Linux handle this addressing
problem?
What addressing problem? The 860 supports 32 bits of address, so
does Linux. No problem. I started to add support for multiple real
memory spaces (which isn't hard, you just have to detect it), and then
realized it isn't necessary. With the 8xx memory controller you can
make external RAM one linear space, unless you wire it up really stupid.
One more - if anyone has the specification for Sony Memorystick
I would be interested. I am pretty certain that this flashstick
has a serial interface on it.
Maybe it is similar to the SanDisk MMC interface? That is an SPI
interface, perhaps there is some access standard.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Adrian Cox <hidden> Date: 2000-05-26 10:01:47
Geir Frode Raanes wrote:
BTW, VxWorks can not easily handle more than 32 MBytes of local RAM
as the eabi specification (as a result of the PowerPC architecure)
rules for 26 bit (signed) relative addressing. Hence, I will design
in exactly 32 MBytes of soldered low power SDRAM on UPMA and assign
UPMB to a DIMM socket. How does PPC/Linux handle this addressing
problem?
The current release of VxWorks is prepared to use a long jump sequence
to jump to a 32 bit address. Tornado 2 out of the box has worked fine
for me on a 128MByte 7400.
The problem only ever occurs when your code occupies an address range
greater than 32MBytes. VxWorks doesn't support virtual addressing
without some add-ons. It always placed the kernel at the bottom of
memory and dynamically loaded code at the top, so that calls from the
dynamically loaded code into the kernel had offsets that couldn't fit in
a relative branch.
Linux, however, never had this problem. Linux uses virtual memory, which
keeps the application within a smaller address range.
- Adrian Cox, AG Electronics
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BTW, VxWorks can not easily handle more than 32 MBytes of local RAM
as the eabi specification (as a result of the PowerPC architecure)
rules for 26 bit (signed) relative addressing. Hence, I will design
in exactly 32 MBytes of soldered low power SDRAM on UPMA and assign
UPMB to a DIMM socket. How does PPC/Linux handle this addressing
problem?
The current release of VxWorks is prepared to use a long jump sequence
to jump to a 32 bit address. Tornado 2 out of the box has worked fine
for me on a 128MByte 7400.
Yes, one can always use the "-mlongcall" flag to GCC.
Or boot the kernel with only 32 MBytes in sysLib.c, load
the application (defaults to top of memory, while the kernel
sits in low memory) and then "memAddToPool(sysMemTop(),0x2000000)"
This is a FAQ issue. I have not verified the existence of the
problem myself.
It always placed the kernel at the bottom of
memory and dynamically loaded code at the top, so that calls from the
dynamically loaded code into the kernel had offsets that couldn't fit
in a relative branch.
Yeees, this will not fit into 26 bit signed relative addressing.
But are you telling me that VxWorks do use longcalls per default...
or not? (Ie. did this >32MByte separation work or not?)
Linux, however, never had this problem. Linux uses virtual memory, which
keeps the application within a smaller address range.
I am aware that the MMU makes the question of addressing ranges
somewhat lame. But I am scared of the dark and in this case I can
not see past the MMU and into Linux addressing modes.
Actually, I have obviousely a blind-spot in my understanding
of how API calls work on Linux. User space is 4 GBytes linear.
At the bottom is the enviroment tables copied prom the parent
process. If I remember correctly, then the stack is at the
lowest addresses above this, then comes the ELF text segment,
then BSS, then data and the rest goes into the memory heap.
API calls results in violation exceptions which the OS will
service. But to provoce an violation exception the user
application must be able to address supervisor owned space
in the first place. Meaning that some part of of the User
space must be shared with the kernel and that this space
must contain the API functions entrypoints. Correct?
--
******************************************************
Never ever underestimate the power of human stupidity.
-Robert Anson Heinlein
GeirFRS@invalid.and.so.forth
******************************************************
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Adrian Cox <hidden> Date: 2000-05-26 13:52:52
Geir Frode Raanes wrote:
Yes, one can always use the "-mlongcall" flag to GCC.
Or boot the kernel with only 32 MBytes in sysLib.c, load
the application (defaults to top of memory, while the kernel
sits in low memory) and then "memAddToPool(sysMemTop(),0x2000000)"
This is a FAQ issue. I have not verified the existence of the
problem myself.
[...]
I've just performed a test, and what happens is that VxWorks dynamic
loading now starts in low memory rather than high memory. You may still
need to specify longcall in development, but as deployed applications
don't use dynamic loading, the problem has pretty well gone away.
Actually, I have obviousely a blind-spot in my understanding
of how API calls work on Linux. User space is 4 GBytes linear.
At the bottom is the enviroment tables copied prom the parent
process. If I remember correctly, then the stack is at the
lowest addresses above this, then comes the ELF text segment,
then BSS, then data and the rest goes into the memory heap.
The user space on PowerPC is only 3GB at the moment. This means that
only 1GB of RAM is supported, as all RAM must be mapped into the
remaining address space (0xc0000000 to 0xffffffff). This image of all
physical RAM is only accessible in supervisor mode. We'll soon need
somebody to come up with a trick comparable to the way large memory x86
systems work, so that we can have 2GB PPC systems.
(In a perfect world, a follow up message would tell me that I've not
been paying attention, and this has already happened.)
API calls results in violation exceptions which the OS will
service. But to provoce an violation exception the user
application must be able to address supervisor owned space
in the first place. Meaning that some part of of the User
space must be shared with the kernel and that this space
must contain the API functions entrypoints. Correct?
From a brief examination of head.S, system calls work by an application
performing the sc instruction, which starts execution from physical
address 0xc00 in supervisor mode. Once address translation is turned
back on the kernel sees kernel address space starting at virtual address
0xc0000000, and user space starting at virtual address 0x0.
- Adrian Cox, AG Electronics
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/