<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 

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.

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��en

Frank-Christian Kr�gel

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.

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.

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

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

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