Forums

Embedded Linux and PCI (over AT91?)

Started by Unknown December 28, 2007
Hello,

I'm currently making the initial design decisions (and hence the most
important ones) about a project, which will involve a processor
running Linux. The project's initial definition is to take data from
an MPEG video chipset and store the stream in a long file on a Disk-on-
Key.

So the concept is simple: Write a driver for whatever video hardware
we're going to choose (still not defined), and make use of the Linux
environment to handle all the USB and filesystem magic. Left on the
todo-list is to write a simple application to copy the data. Neat and
simple. Or so I thought.

The first headache was to choose the processor. I was told that ARM9
is the preferred architecture (for historic reasons, so this issue is
open) and I'm pretty much in favor of Atmel AT91RM9200, mainly because
it appears to have some community mileage (see http://maxim.org.za/at91_26.html
).

And now to the point: I'd like the processor to talk with some of its
peripherals over a PCI bus. For example, the on-chip USB 2.0 is only
full-speed, which may be too slow for a video stream, so I'd like the
option to connect a high-speed USB chipset over the PCI bus (I suppose
such are available).

Another thing is that my company is pretty responsive to customer's
bizarre demands, so we need the flexibility to quickly acquire some
Linux-supported PCI chipset, which implements some unexpected
interface (firewire? IDE? SCSI?). Then make some small changes to the
board (basically hook the device on the on-board bus), and have the
product up quickly and painlessly.

In a survey I made, I found out that this is not something people do:
Very few processors I found have 16-bit PCMCIA, which is the closest I
got to PCI. I think I saw some PCI connectivity on Intel's IOP
(XScale), but there were too many Gigas mentioned in the datasheet to
make it look like a fitting solution for a small module.

So this leads me to basically two questions:

1. Is trying to connect a PCI bus to a AT91 inherently stupid? If so,
why? (I mean, if it was such a good idea, I would expect it
implemented on development boards)
2. What is the simplest way to get any simple processor to have a PCI
bus, in such a way that Linux will recognize it naturally? (Assuming
the answer to question #1 is "no")

And, by the way, the first thing I suggested was a simple i386-based
single board computer. Judging by the allergic response I got, I found
no reason to investigate this direction further.

Thanks in advance (and a happy new hangover)
    Bill
bill.valores@gmail.com wrote:

> I'm currently making the initial design decisions (and hence the most > important ones) about a project, which will involve a processor > running Linux. The project's initial definition is to take data from > an MPEG video chipset and store the stream in a long file on a Disk-on- > Key. > > So the concept is simple: Write a driver for whatever video hardware > we're going to choose (still not defined), and make use of the Linux > environment to handle all the USB and filesystem magic. Left on the > todo-list is to write a simple application to copy the data. Neat and > simple. Or so I thought. > > The first headache was to choose the processor. I was told that ARM9 > is the preferred architecture (for historic reasons, so this issue is > open) and I'm pretty much in favor of Atmel AT91RM9200, mainly because > it appears to have some community mileage (see http://maxim.org.za/at91_26.html > ). > > And now to the point: I'd like the processor to talk with some of its > peripherals over a PCI bus. For example, the on-chip USB 2.0 is only > full-speed, which may be too slow for a video stream, so I'd like the > option to connect a high-speed USB chipset over the PCI bus (I suppose > such are available).
Have you considered getting an ARM9 with integrated high speed USB ? For instance: http://www2.okisemi.com/site/productscatalog/mcumpu/availabledocs/Intro-5430.html
On Dec 28, 4:50 pm, bill.valo...@gmail.com wrote:

> For example, the on-chip USB 2.0 is only > full-speed, which may be too slow for a video stream
I thought 'full speed' applied to USB 1 / 1.1 and that 2.0 devices had to be able to go faster than that? Anyway, to talk to a usb disk you also need a device which implements the USB host and not simply a USB device interface. Assuming you are writing compressed video data, USB full speed probably is fast enough for most purposes. If I recall correctly USB full speed is 12 mbit/second minus overhead, wheras the official limit for DVD's is a little under 10 mbit/second. But if you can't do good compression before writing it you might have to go faster. Most current usb flash disks will write on the order of 5 MByte/second when used with USB2.0, but those a little older may be substantially slower. Looking at your requirements, an embedded x86 platform probably is the best choice. You can buy an entire micro laptop with usb2.0, 2g internal storage, and display (Asus EeePC 2g) for the $300 we're paying for an embedded blackfin module
cs_posting@hotmail.com wrote:
> On Dec 28, 4:50 pm, bill.valo...@gmail.com wrote: > >> For example, the on-chip USB 2.0 is only >> full-speed, which may be too slow for a video stream > > I thought 'full speed' applied to USB 1 / 1.1 and that 2.0 devices had > to be able to go faster than that?
No. USB 2.0 is just a standard. It supports low, full and high speed devices. The USB 1.1 standard, on the other hand only supports low and full speed devices. To comply with the USB 2.0 standard, a device only needs a couple more descriptors.
> Assuming you are writing compressed video data, USB full speed > probably is fast enough for most purposes. If I recall correctly USB > full speed is 12 mbit/second minus overhead, wheras the official limit > for DVD's is a little under 10 mbit/second. But if you can't do good > compression before writing it you might have to go faster.
The overhead on USB is quite big. I don't think you can get 10 Mbps effective throughput on a full speed device, even if you completely saturate the bus.
Thanks for your answers. Now,

On Dec 29, 12:07=A0am, Arlet Ottens <usene...@c-scape.nl> wrote:
> Have you considered getting an ARM9 with integrated high speed USB ? > > For instance: > > http://www2.okisemi.com/site/productscatalog/mcumpu/availabledocs/Int...- =
Hide quoted text -
>
Not this specific chip (which looks like it has a USB peripheral port and not a host), but I did have a peek on Freescale's i.MX27/i.MX31 and TI's DaVinci (TMS320DM6446). They also have some added value regarding video compression, and their price is high but OK. But while these chips have official Linux support, they don't appear to have a Linux community backing them up, which means using Linux without Linux' main advantage. Anyhow, this doesn't address the original issue of flexibility. Which brings me to On Dec 29, 12:37 am, cs_post...@hotmail.com wrote:
> Looking at your requirements, an embedded x86 platform probably is the > best choice. You can buy an entire micro laptop with usb2.0, 2g > internal storage, and display (Asus EeePC 2g) for the $300 we're > paying for an embedded blackfin module
The solution should still be a tiny card in another piece of electronics, and pretty honestly I don't have much of a say in this matter. All mini-PC solutions are out of the question. I may be able to push a x86-based solution, in case it has a embedded-like feel, but I haven't found any developmend board which doesn't scream "Computer", both in spec and design. Thanks so far, Bill.
On Fri, 28 Dec 2007 13:50:57 -0800 (PST), bill.valores@gmail.com wrote:

>The first headache was to choose the processor. I was told that ARM9 >is the preferred architecture (for historic reasons, so this issue is >open) and I'm pretty much in favor of Atmel AT91RM9200, mainly because >it appears to have some community mileage (see http://maxim.org.za/at91_26.html >).
[...]
>1. Is trying to connect a PCI bus to a AT91 inherently stupid? If so, >why? (I mean, if it was such a good idea, I would expect it >implemented on development boards)
Not exactly stupid, but hard. None of the AT91 members has native PCI, and so the AT91 Linux port doesn't. You'll have to add a LocalBus-PCI Host Bridge (fixed-function chip or FPGA), and you'll have to add PCI support to your Linux kernel. Good luck. I can't guantantee that you are even able to implement the full PCI 2.2 standard, eg. when it comes to items like busmaster DMA from/to DRAM. I'd strongly advise you to stay away from this. If you feel you need PCI, choose a controller with native PCI support. Even with ARM9 there are several ones. And MIPS, PPC, Coldfire exist. And if you need high-speed USB2.0 or Gigabit Ethernet, don't forget performance. I'm unsure about high-speed USB, but at least for Ethernet the controller won't gain much from a gigabit phy. Mit freundlichen Gr&#2013266172;&#2013265951;en Frank-Christian Kr&#2013266172;gel
bill.valores@gmail.com wrote:
> Thanks for your answers. Now, > > On Dec 29, 12:07 am, Arlet Ottens <usene...@c-scape.nl> wrote: >> Have you considered getting an ARM9 with integrated high speed USB ? >> >> For instance: >> >> http://www2.okisemi.com/site/productscatalog/mcumpu/availabledocs/Int...- Hide quoted text - >> > > Not this specific chip (which looks like it has a USB peripheral port > and not a host), but I did have a peek on Freescale's i.MX27/i.MX31 > and TI's DaVinci (TMS320DM6446). They also have some added value > regarding video compression, and their price is high but OK. But while > these chips have official Linux support, they don't appear to have a > Linux community backing them up, which means using Linux without > Linux' main advantage. > > Anyhow, this doesn't address the original issue of flexibility. Which > brings me to > > On Dec 29, 12:37 am, cs_post...@hotmail.com wrote: >> Looking at your requirements, an embedded x86 platform probably is the >> best choice. You can buy an entire micro laptop with usb2.0, 2g >> internal storage, and display (Asus EeePC 2g) for the $300 we're >> paying for an embedded blackfin module > > The solution should still be a tiny card in another piece of > electronics, and pretty honestly I don't have much of a say in this > matter. All mini-PC solutions are out of the question. I may be able > to push a x86-based solution, in case it has a embedded-like feel, but > I haven't found any developmend board which doesn't scream "Computer", > both in spec and design.
That is a rather subjective criterion. It would help if you provided some more objective criteria which could be used to determine what is acceptable and what not.
<bill.valores@gmail.com> skrev i meddelandet 
news:4c4f110a-adf1-460d-9c79-5da072b03ab1@e23g2000prf.googlegroups.com...
> Hello, > > I'm currently making the initial design decisions (and hence the most > important ones) about a project, which will involve a processor > running Linux. The project's initial definition is to take data from > an MPEG video chipset and store the stream in a long file on a Disk-on- > Key. > > So the concept is simple: Write a driver for whatever video hardware > we're going to choose (still not defined), and make use of the Linux > environment to handle all the USB and filesystem magic. Left on the > todo-list is to write a simple application to copy the data. Neat and > simple. Or so I thought. > > The first headache was to choose the processor. I was told that ARM9 > is the preferred architecture (for historic reasons, so this issue is > open) and I'm pretty much in favor of Atmel AT91RM9200, mainly because > it appears to have some community mileage (see > http://maxim.org.za/at91_26.html > ). > > And now to the point: I'd like the processor to talk with some of its > peripherals over a PCI bus. For example, the on-chip USB 2.0 is only > full-speed, which may be too slow for a video stream, so I'd like the > option to connect a high-speed USB chipset over the PCI bus (I suppose > such are available). > > Another thing is that my company is pretty responsive to customer's > bizarre demands, so we need the flexibility to quickly acquire some > Linux-supported PCI chipset, which implements some unexpected > interface (firewire? IDE? SCSI?). Then make some small changes to the > board (basically hook the device on the on-board bus), and have the > product up quickly and painlessly. > > In a survey I made, I found out that this is not something people do: > Very few processors I found have 16-bit PCMCIA, which is the closest I > got to PCI. I think I saw some PCI connectivity on Intel's IOP > (XScale), but there were too many Gigas mentioned in the datasheet to > make it look like a fitting solution for a small module. > > So this leads me to basically two questions: > > 1. Is trying to connect a PCI bus to a AT91 inherently stupid? If so, > why? (I mean, if it was such a good idea, I would expect it > implemented on development boards) > 2. What is the simplest way to get any simple processor to have a PCI > bus, in such a way that Linux will recognize it naturally? (Assuming > the answer to question #1 is "no") > > And, by the way, the first thing I suggested was a simple i386-based > single board computer. Judging by the allergic response I got, I found > no reason to investigate this direction further. > > Thanks in advance (and a happy new hangover) > Bill
Check out www.ajeco.com which has implemented a PCI bridge to an AT91RM9200 using an FPGA. They have a Linux port for it. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB