Au1500 and TI PCI1510 cardbus

Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Hello,

my Au1500 based board has a PCI1510 cardbus controller connected to the PCI
bus. So far the kernel 2.6.17 supports it as a "yenta_socket". The cardbus
is correctly seen and configured, and if I insert a wifi card in the slot I
can configure it.

The problem is that when I transfer a file, the transfer interrupts and the
system does not respond anymore to the serial console or ethernet pings. The
only way to revive it is to remove the wifi card.

I've managed to follow the problem, it seems that at some point during the
transfer "something breaks in the PCI". The effect is that no read or write
involving the PCI work anymore, So when the wifi card rises an interrupt,
the driver tries to read a register on the card to know the cause of the
interrupt but instead it reads 0xFFFFFFFF. As a test I've inserted a
"pci_read_config_dword" in the interrupt handler. Normally it reads the
correct value, but when the problem happens it reads 0xFFFFFFFF instead.

I've noticed that config_access returns 0xFFFFFFFF in case of an error, but
actually the 0xFFFFFFFF is not caused by any of those error conditions. The
pci_read_config_dword returns 0 and the 0xFFFFFFFF value is a genuine value.

Any advice on this problem?
Thanks a lot!

[-- Attachment #2: Type: text/html, Size: 1329 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Michael Stickel]

Marco Braga wrote:

> my Au1500 based board has a PCI1510 cardbus controller connected to 
> the PCI bus. So far the kernel 2.6.17 supports it as a "yenta_socket". 
> The cardbus is correctly seen and configured, and if I insert a wifi 
> card in the slot I can configure it.


There is a hint on that in the datasheet. Search for deadlock and/or 
delayed read transaction.
Read it carefully. May be you can not use you PCI-Cardbus controller. 
Have in mind, that a PCI-Cardbus controller with a cardbus card inserted 
acts like a PCI to PCI bridge.

Regards,
Michael

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

Dear Michael,

I've found the datasheet of PCI1510 and the section you pointed. Sadly I
don't understand fully the problem, so I'll discuss it with out hardware
enginers. Do you have any reference to the effects of that problem? Can it
cause the hand of reads on the bus?

Thanks a lot!

[-- Attachment #2: Type: text/html, Size: 316 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Michael Stickel]

Marco Braga wrote:

> I've found the datasheet of PCI1510 and the section you pointed. Sadly 
> I don't understand fully the problem, so I'll discuss it with out 
> hardware enginers. Do you have any reference to the effects of that 
> problem? Can it cause the hand of reads on the bus?

I am sory, I meant the datasheet of the Au1500. I do not find the 
paragraph anymore, but can tell you more on monday.
One interesting paragraph is "AMD Alchemy Au1500 Processor Data Book" - 
4.3.10 "Other Notes" first paragraph.

The note I meant descibes a situration where a delayed read transaction 
on a pci device behind a pci-pci bridge can cause to a racing condition, 
where the whole system stalls. The CPU does not get the chance to do 
anything anymore, because the PCI subsystem blocks it.

Regards,
Michael

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

> I am sory, I meant the datasheet of the Au1500. I do not find the
> paragraph anymore, but can tell you more on monday.


Thank you. I've checked the data book but I've not found anything so
explicit. Paragraph 4.3.10 "Other notes" states:

"The Au1500 PCI contoller cannot be used with external PCI-to-PCI bridges
that have PCI bus-mastering devices on the
secondary bus which target the Au1500 memory."

But this is not exactly an explanation.. I've found nothing regarding race
conditions or delayed transactions. I'll wait eagerly for monday when all
the truths will be revealed. :)

Thanks!!

[-- Attachment #2: Type: text/html, Size: 835 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Sergei Shtylyov]

Marco Braga wrote:
>> I am sory, I meant the datasheet of the Au1500. I do not find the
>> paragraph anymore, but can tell you more on monday.

    I think Michael actually mean the specification update, not datasheet.
Indeed, errata 32

> Thank you. I've checked the data book but I've not found anything so
> explicit. Paragraph 4.3.10 "Other notes" states:

> "The Au1500 PCI contoller cannot be used with external PCI-to-PCI bridges
> that have PCI bus-mastering devices on the
> secondary bus which target the Au1500 memory."

> But this is not exactly an explanation.. I've found nothing regarding race
> conditions or delayed transactions. I'll wait eagerly for monday when all
> the truths will be revealed. :)

    Hrm, this seems enough of an explanation -- it basically says that you 
can't use any decent PCI device behind the bridge.  The abovementioned errata 
tells that "any mastering device on the other side of a P2P bridge, where the 
target is the Au1500 processor, will eventually lead to a lock-up condition of 
the PCI bus or even the entire system".

> Thanks!!

WBR, Sergei

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

Hello,

Michael sent me a more elaborate answer from AMD. It seems indeed that there
is no way to make the Cardbus work without locking. I think we'll try better
luck with USB 2.0. Regarding to this, has anyone had any success with EHCI
controllers and Au1500?

Thanks!

[-- Attachment #2: Type: text/html, Size: 287 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Sergei Shtylyov]

Hello.

Marco Braga wrote:

> Michael sent me a more elaborate answer from AMD. It seems indeed that 
> there
> is no way to make the Cardbus work without locking. I think we'll try 
> better
> luck with USB 2.0. Regarding to this, has anyone had any success with EHCI
> controllers and Au1500?

    Au1500 dosn't support USB 2.0 and therefore EHCI. You may want to use Au1200.

> Thanks!

WBR, Sergei

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

Hi,

we need PCI so Au15xx is our only choice. Internal USB 1.1 is working well,
but what about adding a PCI to USB controller? Has anyone tried this?

Regards,
Marco

[-- Attachment #2: Type: text/html, Size: 214 bytes --]

Re: Re: Au1500 and TI PCI1510 cardbus

[Takeyoshi Kikuchi]

Hello.

"Marco Braga" <marco.braga@gmail.com> wrote:

>Hi,
>
>we need PCI so Au15xx is our only choice. Internal USB 1.1 is working well,
>but what about adding a PCI to USB controller? Has anyone tried this?
>
>Regards,
>Marco

Our Au1500 board works fine with Ricoh CardBus Bridge and NEC USB 
controller.
However, the board does not work stably with TI PCI1520 controller.

~# lspci 
00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 82)
00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 82)
00:0b.0 RAID bus controller: Triones Technologies, Inc. HPT371/371N (rev 02)
05:00.0 USB Controller: NEC Corporation USB (rev 43)
05:00.1 USB Controller: NEC Corporation USB (rev 43)
05:00.2 USB Controller: NEC Corporation USB 2.0 (rev 04)

-- log --
usb 4-1: USB disconnect, address 3
usb 4-1: new high speed USB device using ehci_hcd and address 4
usb 4-1: configuration #1 chosen from 1 choice
scsi2 : SCSI emulation for USB Mass Storage devices
  Vendor: USB 2.0   Model: Flash Disk        Rev: 1100
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sda: 8093696 512-byte hdwr sectors (4144 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
SCSI device sda: 8093696 512-byte hdwr sectors (4144 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
 sda: sda1
sd 2:0:0:0: Attached scsi removable disk sda

~# dd if=/dev/sda of=/dev/null bs=1048576 count=64
64+0 records in
64+0 records out
67108864 bytes (67 MB) copied, 5.04437 seconds, 13.3 MB/s

~# cat /proc/cpuinfo 
system type             : Century Systems MA420
processor               : 0
cpu model               : Au1500 V0.2
BogoMIPS                : 395.26
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes
ASEs implemented        :
VCED exceptions         : not available
VCEI exceptions         : not available

~# uname -a
Linux MA-420 2.6.18.5 #6 PREEMPT Tue Mar 20 10:22:01 JST 2007 mips GNU/Linux


---------------------------------
Takeyoshi Kikuchi

Re: Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Hello!

2007/3/20, Takeyoshi Kikuchi <kikuchi@centurysys.co.jp>:

Our Au1500 board works fine with Ricoh CardBus Bridge and NEC USB
> controller.
> However, the board does not work stably with TI PCI1520 controller.


As you have seen, we've experienced the same problem with the PCI1510. Can
you please give me the exact product number of both the controllers you use
(USB / Cardbus)? In particular your cardbus experience is interesting
because from the informations I've received until now I tought that no
cardbus controller could work on Au1500's PCI.

Thanks!

[-- Attachment #2: Type: text/html, Size: 862 bytes --]

Re: Re: Re: Au1500 and TI PCI1510 cardbus

[Takeyoshi Kikuchi]

Hi,

"Marco Braga" <marco.braga@gmail.com> wrote:

>Hello!
>
>2007/3/20, Takeyoshi Kikuchi <kikuchi@centurysys.co.jp>:
>
>Our Au1500 board works fine with Ricoh CardBus Bridge and NEC USB
>> controller.
>> However, the board does not work stably with TI PCI1520 controller.
>
>
>As you have seen, we've experienced the same problem with the PCI1510. Can
>you please give me the exact product number of both the controllers you use
>(USB / Cardbus)? In particular your cardbus experience is interesting
>because from the informations I've received until now I tought that no
>cardbus controller could work on Au1500's PCI.
>
>Thanks!

The controllers are as follows:

Cardbus Bridge:
  Ricoh R5C486  (Vendor/Device 1180:0476)
USB Controller:
  NEC uPD720101 (CardBus) (Vendor/Device 1033:00e0)

Ali IEEE1394/USB Combo (Vendor/Device 10b9:5239) also works.

The combination of Au1500(MIPS32) and EHCI code has a problem: ll/sc 
always get locked when it manipulates an atomic variable in the EHCI 
descriptor (qh_get() in ehci-mem.c). 
We applied a patch that adds a function to lib/kref.c so that it doesn't
 use ll/sc.

Linux 2.6.20 has a problem in ioremap, so we replaced the code with one in 
2.6.19.


---------------------------------
Takeyoshi Kikuchi

Re: Au1500 and TI PCI1510 cardbus

[Sergei Shtylyov]

Hello.

Takeyoshi Kikuchi wrote:

>>we need PCI so Au15xx is our only choice. Internal USB 1.1 is working well,
>>but what about adding a PCI to USB controller? Has anyone tried this?

>>Regards,
>>Marco

> Our Au1500 board works fine with Ricoh CardBus Bridge and NEC USB 
> controller.
> However, the board does not work stably with TI PCI1520 controller.

> ~# lspci 
> 00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 82)
> 00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 82)
> 00:0b.0 RAID bus controller: Triones Technologies, Inc. HPT371/371N (rev 02)
> 05:00.0 USB Controller: NEC Corporation USB (rev 43)
> 05:00.1 USB Controller: NEC Corporation USB (rev 43)
> 05:00.2 USB Controller: NEC Corporation USB 2.0 (rev 04)

    What I don't understand is why use USB card on CardBus, if the Au1500 
datasheet clearly tells us (well, at least me :-) that this is *not* going to 
work?

WBR, Sergei

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

2007/3/20, Sergei Shtylyov <sshtylyov@ru.mvista.com>:
>
>     What I don't understand is why use USB card on CardBus, if the Au1500
> datasheet clearly tells us (well, at least me :-) that this is *not* going
> to
> work?
>

I'll reply for my part: we need something hotswappable, and support for
wifi. The first idea was to use cardbus, so a board was built using PCI1510.
When the system was projected, USB2.0 was not easy to find (if even existed)
and almost every wifi card was PCMCIA or Cardbus. The PCI1510 never worked,
and it seems now that never will. So at the moment an alternative is to try
a wifi dongle on USB. USB 1.x was too slow, but USB 2.0 seems ok for our
application. Au1500 does not support USB2.0, so I am looking for a
PCI/USB2.0 controlles. Does something similar exist? Does it work on Au1500?

To make it short, we are NOT trying to make USB work on Cardbus, but to use
either cardbus OR usb. :-)

From what you've told me cardbus on PCI (being a bridge) cannot work with
AU1500's PCI device. So the next idea is to try an USB controller on PCI.
Will it work? Well, I'm hoping for some fresh hand advice on this.

Now Takeyoshi tells me that he's using both USB2.0 and Cardbus (not USB on
Cardbus), so this seems interesting. I still think that USB is the best way
to go, but still a working PCI to Cardbus controller can be interesting. But
I don't know how he's managed to make it work, since from what you have told
me it should not work. Perhaps he's not using Cardbus devices but PCMCIA.

[-- Attachment #2: Type: text/html, Size: 1870 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

2007/3/20, Sergei Shtylyov <sshtylyov@ru.mvista.com>:
>
>     What I don't understand is why use USB card on CardBus, if the Au1500
> datasheet clearly tells us (well, at least me :-) that this is *not* going
> to
> work?
>

I'll reply for my part: we need something hotswappable, and support for
wifi. The first idea was to use cardbus, so a board was built using PCI1510.
When the system was projected, USB2.0 was not easy to find (if even existed)
and almost every wifi card was PCMCIA or Cardbus. The PCI1510 never worked,
and it seems now that never will. So at the moment an alternative is to try
a wifi dongle on USB. USB 1.x was too slow, but USB 2.0 seems ok for our
application. Au1500 does not support USB2.0, so I am looking for a
PCI/USB2.0 controlles. Does something similar exist? Does it work on Au1500?

To make it short, we are NOT trying to make USB work on Cardbus, but to use
either cardbus OR usb. :-)

Re: Au1500 and TI PCI1510 cardbus

[Sergei Shtylyov]

Marco Braga wrote:
> 2007/3/20, Sergei Shtylyov <sshtylyov@ru.mvista.com>:

>>     What I don't understand is why use USB card on CardBus, if the Au1500
>> datasheet clearly tells us (well, at least me :-) that this is *not* 
>> going to work?

> I'll reply for my part: we need something hotswappable, and support for
> wifi. The first idea was to use cardbus, so a board was built using 
> PCI1510.
> When the system was projected, USB2.0 was not easy to find (if even 
> existed)
> and almost every wifi card was PCMCIA or Cardbus. The PCI1510 never worked,
> and it seems now that never will. So at the moment an alternative is to try
> a wifi dongle on USB. USB 1.x was too slow, but USB 2.0 seems ok for our
> application. Au1500 does not support USB2.0, so I am looking for a
> PCI/USB2.0 controlles. Does something similar exist? Does it work on 
> Au1500?

    Well, it all should be working fine in the board's own PCI slots, i.e. on 
the primary PCI bus.

> To make it short, we are NOT trying to make USB work on Cardbus, but to use
> either cardbus OR usb. :-)

>  From what you've told me cardbus on PCI (being a bridge) cannot work with
> AU1500's PCI device. So the next idea is to try an USB controller on PCI.
> Will it work? Well, I'm hoping for some fresh hand advice on this.

    Yes, this should work.

> Now Takeyoshi tells me that he's using both USB2.0 and Cardbus (not USB on
> Cardbus), so this seems interesting. I still think that USB is the best way

    From what I saw his USB is not on the primary bus, so he's taking the 
mentioned risks.

> to go, but still a working PCI to Cardbus controller can be interesting. 
> But
> I don't know how he's managed to make it work, since from what you have 
> told
> me it should not work.

    The layout of his PCI busses is not clear from lspci's dump he's cited but 
his USB is clearly in the "risk zone".

> Perhaps he's not using Cardbus devices but PCMCIA.

    It's not me -- it's written in the publicly available datasheet (spec. 
update I have just has more details :-)

WBR, Sergei

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

I think I'm beginning to make a lot of confusion. Is the problem that the
PCI1510 must NOT be behind a bridge, or the problem is that PCI1510 acts as
a bridge, so cardbus cards cannot work?

This is my lspci at start:

00:0c.0 RAID bus controller: Triones Technologies, Inc. HPT371/371N (rev 02)
00:0d.0 Non-VGA unclassified device: Texas Instruments TMS320DM642 (rev 01)
00:12.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller

While this is the situation when I load yenta_socket:

00:0c.0 RAID bus controller: Triones Technologies, Inc. HPT371/371N (rev 02)
00:0d.0 Non-VGA unclassified device: Texas Instruments TMS320DM642 (rev 01)
00:12.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller
01:00.0 Network controller: 3Com Corporation 3com 3CRWE154G72 [Office
Connect Wireless LAN Adapter] (rev 01)

So it seems that the 3Com card is behind a bus. Should this work? From what
I've understood, it should now work.. In fact my problem is that it seems to
work if I try to ping a host, but it fails when I try some serious transfer.
In this case, at some point, any readl() on 3Com returns 0xFFFFFFFF. Just to
test I've tried a pci_config_read() on the PCI1510 and it fails. The entire
boards seems hung. The only thing I can do is to remove the 3Com card.

Thanks!

[-- Attachment #2: Type: text/html, Size: 1383 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Sergei Shtylyov]

Hello.

Marco Braga wrote:

> I think I'm beginning to make a lot of confusion. Is the problem that the
> PCI1510 must NOT be behind a bridge, or the problem is that PCI1510 acts as
> a bridge, so cardbus cards cannot work?

    The second.

> This is my lspci at start:

> 00:0c.0 RAID bus controller: Triones Technologies, Inc. HPT371/371N (rev 02)
> 00:0d.0 Non-VGA unclassified device: Texas Instruments TMS320DM642 (rev 01)
> 00:12.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus 
> Controller

    You can see yourself that PCI1510 is a bridge (Cardbus-to-PCI bridge is 
largely the same as PCI-to-PCI bridge).

> While this is the situation when I load yenta_socket:

> 00:0c.0 RAID bus controller: Triones Technologies, Inc. HPT371/371N (rev 02)
> 00:0d.0 Non-VGA unclassified device: Texas Instruments TMS320DM642 (rev 01)
> 00:12.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus 
> Controller
> 01:00.0 Network controller: 3Com Corporation 3com 3CRWE154G72 [Office
> Connect Wireless LAN Adapter] (rev 01)

> So it seems that the 3Com card is behind a bus. Should this work? From what
> I've understood, it should now work..

    Think again. :-)

> In fact my problem is that it seems to work if I try to ping a host, but it fails when I try some serious 
> transfer.
> In this case, at some point, any readl() on 3Com returns 0xFFFFFFFF. 
> Just to
> test I've tried a pci_config_read() on the PCI1510 and it fails. The entire
> boards seems hung. The only thing I can do is to remove the 3Com card.

   Sounds like what's been told in the errata 32.

> Thanks!

WBR, Sergei

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

2007/3/20, Sergei Shtylyov <sshtylyov@ru.mvista.com>:
>
> > I think I'm beginning to make a lot of confusion. Is the problem that
> the
> > PCI1510 must NOT be behind a bridge, or the problem is that PCI1510 acts
> as
> > a bridge, so cardbus cards cannot work?
>
>     The second.


Ok, at the risk of appearing totally dumb, I'll double check.. If the second
ic correct, PCI1510 is a bridce, a cardbus card cannot work.


    You can see yourself that PCI1510 is a bridge (Cardbus-to-PCI bridge is
> largely the same as PCI-to-PCI bridge).


Ok.


> So it seems that the 3Com card is behind a bus. Should this work? From
> what
> > I've understood, it should now work..
>
>     Think again. :-)


Ok, that's a typo :-) It should NOT work. Is this better?

   Sounds like what's been told in the errata 32.


It seems that  Au1500 slowly faded into the shadows. Now it is owned by
Raza, but there is no sign of an errata document, perhaps I've lost the
magic moment when a lot of documentation was available.

But still, the question remains: how can Takeyoshi's "Ricoh CardBus Bridge"
work with a cardbus card if bridges cannot work with Au1500's PCI?

Scrub scrub..

[-- Attachment #2: Type: text/html, Size: 2097 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Sergei Shtylyov]

Hello.

Marco Braga wrote:

>> > I think I'm beginning to make a lot of confusion. Is the problem that
>> the
>> > PCI1510 must NOT be behind a bridge, or the problem is that PCI1510 
>> acts
>> as
>> > a bridge, so cardbus cards cannot work?

>>     The second.

> Ok, at the risk of appearing totally dumb, I'll double check.. If the 
> second
> ic correct, PCI1510 is a bridce, a cardbus card cannot work.

    Yeah. Note that it's not totally broken -- you just can't use the "decent" 
devices on it, i.e. ones with bus mastering.

>>    You can see yourself that PCI1510 is a bridge (Cardbus-to-PCI bridge is
>> largely the same as PCI-to-PCI bridge).

> Ok.

    Yeah, that's an importnat point.  AMD docs don't say about CardBus 
bridges, So, it was probably obvious to me only. :-)

>> So it seems that the 3Com card is behind a bus. Should this work? From
>> what
>> > I've understood, it should now work..

>>     Think again. :-)

> Ok, that's a typo :-) It should NOT work. Is this better?

>   Sounds like what's been told in the errata 32.

> It seems that  Au1500 slowly faded into the shadows. Now it is owned by
> Raza, but there is no sign of an errata document, perhaps I've lost the
> magic moment when a lot of documentation was available.

    The errata has been available only from the AMD's developer site.

> But still, the question remains: how can Takeyoshi's "Ricoh CardBus Bridge"
> work with a cardbus card if bridges cannot work with Au1500's PCI?

> Scrub scrub..

WBR, Sergei

Re: Au1500 and TI PCI1510 cardbus

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

To sum it up, Cardbus bridge is not a viable solution on Au1500 for
hotswapping devices, since any decent one (bus mastering) will not work.
USB2.0 should instead work with PCI based controllers, that must be
connected to the main PCI device (directly to Au1500).

Well, I think that this closes the issue. As a last note, Au1200 is not a
solution since we really need PCI.

I'd like to thank everyone here, you've been very patient with me. :-)

Regards,
Marco

[-- Attachment #2: Type: text/html, Size: 505 bytes --]

Re: Au1500 and TI PCI1510 cardbus

[Attila Kinali]

On Tue, 20 Mar 2007 17:33:54 +0100
"Marco Braga" <marco.braga@gmail.com> wrote:

> To sum it up, Cardbus bridge is not a viable solution on Au1500 for
> hotswapping devices, since any decent one (bus mastering) will not work.
> USB2.0 should instead work with PCI based controllers, that must be
> connected to the main PCI device (directly to Au1500).

We are using a board with a Au1550 with cardbus (PCI1520) and
USB2.0. The USB controller is directly connected to PCI.
Although cardbus isn't fully tested yet, USB seems to work fine
(atleast i haven't heard of any problems), but i don't know
from the top of my head which chip they used.

Also, the Au1550 doesn't seem to have the master-behind-bridge
bug as the 1500 does (at least according to the datasheet),
so i guess cardbus should work also with "decent" cards :)


HTH 
			Attila Kinali


-- 
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
                        -- Daniel Hottinger

Re: Au1500 and TI PCI1510 cardbus

[Sergei Shtylyov]

Hello.

Attila Kinali wrote:

>>To sum it up, Cardbus bridge is not a viable solution on Au1500 for
>>hotswapping devices, since any decent one (bus mastering) will not work.
>>USB2.0 should instead work with PCI based controllers, that must be
>>connected to the main PCI device (directly to Au1500).

> We are using a board with a Au1550 with cardbus (PCI1520) and
> USB2.0. The USB controller is directly connected to PCI.
> Although cardbus isn't fully tested yet, USB seems to work fine
> (atleast i haven't heard of any problems), but i don't know
> from the top of my head which chip they used.

> Also, the Au1550 doesn't seem to have the master-behind-bridge
> bug as the 1500 does (at least according to the datasheet),

    Reading revisions C and D of the Au1550 datasheet, I see:

4.3.9 System Considerations

The Au1550 PCI controller cannot be used with external PCI-to-PCI bridges that 
have PCI bus-mastering devices on the secondary bus which target the Au1550 
memory.

> so i guess cardbus should work also with "decent" cards :)

    OTOH, Au1550 errata I have is silent about the P2P bridges.

> HTH 
> 			Attila Kinali

WBR, Sergei

Re: Au1500 and TI PCI1510 cardbus

[Attila Kinali]

On Sat, 24 Mar 2007 17:16:31 +0300
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

> 4.3.9 System Considerations
> 
> The Au1550 PCI controller cannot be used with external PCI-to-PCI bridges that 
> have PCI bus-mastering devices on the secondary bus which target the Au1550 
> memory.

Damn, i overlooked that.
I guess we have to make some provisions that cardbus
cards don't do DMA into the alchemy :(

Thanks
			Attila Kinali

-- 
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
                        -- Daniel Hottinger