latest crystal driver

36 views
Skip to first unread message

Craig Whitmore

unread,
Jul 23, 2010, 10:25:47 PM7/23/10
to crystalhd-development
Hi there..

I updated last night to the latest git version of the driver. I am
getting lots of these errors now. I am using the last svn version of
xbmc.? Any ideas?


*ERR*:drivers/staging/crystalhd/crystalhd_hw.c:1792: res_buff[2] !=
C011_RET_SUCCESS
fw cmd 73763136 failed
*ERR*:drivers/staging/crystalhd/crystalhd_hw.c:1792: res_buff[2] !=
C011_RET_SUCCESS
fw cmd 7376311b failed
*ERR*:drivers/staging/crystalhd/crystalhd_hw.c:1792: res_buff[2] !=
C011_RET_SUCCESS
fw cmd 73763136 failed
*ERR*:drivers/staging/crystalhd/crystalhd_cmds.c:304: Link invalid state
1
*ERR*:drivers/staging/crystalhd/crystalhd_hw.c:1792: res_buff[2] !=
C011_RET_SUCCESS
fw cmd 73763136 failed
*ERR*:drivers/staging/crystalhd/crystalhd_hw.c:1792: res_buff[2] !=
C011_RET_SUCCESS
fw cmd 7376311b failed
*ERR*:drivers/staging/crystalhd/crystalhd_hw.c:1792: res_buff[2] !=
C011_RET_SUCCESS
fw cmd 73763136 failed
*ERR*:drivers/staging/crystalhd/crystalhd_cmds.c:304: Link invalid state
1
*ERR*:drivers/staging/crystalhd/crystalhd_hw.c:1792: res_buff[2] !=
C011_RET_SUCCESS
fw cmd 73763136 failed


Naren (Narendra) Sankar

unread,
Jul 25, 2010, 12:35:29 AM7/25/10
to crystalhd-...@googlegroups.com
Is this on the BCM970012?

Naren
--
To post to this group, send email to
crystalhd-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/crystalhd-development?hl=en

Craig Whitmore

unread,
Jul 25, 2010, 12:49:48 AM7/25/10
to crystalhd-...@googlegroups.com
On Sat, 2010-07-24 at 21:35 -0700, Naren (Narendra) Sankar wrote:
> Is this on the BCM970012?
>
> Naren
>
> ----- Original Message -----
> From: crystalhd-...@googlegroups.com <crystalhd-...@googlegroups.com>
> To: crystalhd-development <crystalhd-...@googlegroups.com>
> Sent: Fri Jul 23 19:25:47 2010
> Subject: [crystalhd-development] latest crystal driver
>

Yea.. it is the 970012. (See Specs I am using @
http://www.geekzone.co.nz/LennonNZ/7131 .

yes I can use the really old version which works but alot worse, but it
might be nice if the drivers would work properly one day :-)

Thanks

Naren (Narendra) Sankar

unread,
Jul 25, 2010, 1:15:52 AM7/25/10
to crystalhd-...@googlegroups.com
Does your card have the black heat spreader on top of it?

Thanks

Craig Whitmore

unread,
Jul 25, 2010, 1:41:24 AM7/25/10
to crystalhd-...@googlegroups.com
On Sat, 2010-07-24 at 22:15 -0700, Naren (Narendra) Sankar wrote:
> Does your card have the black heat spreader on top of it?
>

Yes it has the black bit on it .It looks like the one on

http://www.geekzone.co.nz/LennonNZ/7131

it does not look like the one on this website:

http://www.logicsupply.com/products/bcm970012

Are they not 100% the same?

Here is lspci if it helps?


02:00.0 Multimedia controller: Broadcom Corporation BCM70012 Video
Decoder [Crystal HD] (rev 01)
Subsystem: Broadcom Corporation Device 2612
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 29
Region 0: Memory at dfc00000 (64-bit, non-prefetchable)
[size=64K]
Region 2: Memory at df800000 (64-bit, non-prefetchable)
[size=4M]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [60] Vendor Specific Information <?>
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable+
Address: 00000000fee0300c Data: 4189
Capabilities: [cc] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <4us, L1 <64us
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [13c] Virtual Channel <?>
Capabilities: [160] Device Serial Number 41-63-06-24-12-18-10-00
Capabilities: [16c] Power Budgeting <?>
Kernel driver in use: Broadcom 70012 Decoder
Kernel modules: crystalhd

Naren (Narendra) Sankar

unread,
Jul 26, 2010, 6:20:10 PM7/26/10
to crystalhd-...@googlegroups.com
Craig

Unfortunately no, the boards are not exactly identical. They have different layouts. And it seems that the ones with the heat spreader were sold by someone potentially with un-reliable memory devices. We never authorized those cards for the retail market.

The one's that logicsupply carries are the official cards.

However having said that, Scott Davilla is going to be experimenting with some settings I asked him to try to see if we can get the cards all working stable.

If you want to try out something - in crystalhd_linkfuncs.c There is a write to MISC_PERST_VREG_CTRL - can you change the value to 0xF5 or 0xF6 instead of 0xF3 and see if it make the cards work?

Thanks

Naren Sankar (+1 408 218 6327)
Architect/PLM
Media PC, Broadband Communications Group
Broadcom Corp.

Scott D. Davilla

unread,
Jul 26, 2010, 6:30:39 PM7/26/10
to crystalhd-...@googlegroups.com
>Unfortunately no, the boards are not exactly identical. They have
>different layouts. And it seems that the ones with the heat spreader
>were sold by someone potentially with un-reliable memory devices. We
>never authorized those cards for the retail market.
>
>The one's that logicsupply carries are the official cards.
>
>However having said that, Scott Davilla is going to be experimenting
>with some settings I asked him to try to see if we can get the cards
>all working stable.
>
>If you want to try out something - in crystalhd_linkfuncs.c There is
>a write to MISC_PERST_VREG_CTRL - can you change the value to 0xF5
>or 0xF6 instead of 0xF3 and see if it make the cards work?

I'm on a three week trip right now. I do have an atv(linux)
w/bcm70012 and MacMini w/bcm70015 but no old layout cards with me.
Aug 5th, I'll be back and can resume fiddling with old layout cards.

hendrikb...@googlemail.com

unread,
Jul 28, 2010, 11:37:37 AM7/28/10
to crystalhd-development
I've a card with heat spreader,too and tried. 0xF5 but it didn't help.
When i compile with 0xF6 the crystalhd_linkfuncs.o is an empty file
and cannot be linked together to crystalhd.ko.

greetings

hendrikb...@googlemail.com

unread,
Jul 28, 2010, 6:42:30 PM7/28/10
to crystalhd-development
Hello,

i've compared a little bit the working libcrystalhd and the actual
one. And I've noticed that the new one sets the clock up to 200Mhz.
The old one DtsFetchOutInterruptible: Failed:a
only to 180. So I set the clock at the actually libcrystalhd to 180
and voila at least I got a few pictures decoded. So I decided to test
some clockrates. And at 150mhz I got quiet stable movie with
gstreamer. Only a few framedrops when it says:

"DtsFetchOutInterruptible: Failed:a"

On 28 Jul., 17:37, "hendrikborgho...@googlemail.com"

Scott D. Davilla

unread,
Jul 28, 2010, 7:54:04 PM7/28/10
to crystalhd-...@googlegroups.com
>Hello,
>
>i've compared a little bit the working libcrystalhd and the actual
>one. And I've noticed that the new one sets the clock up to 200Mhz.
>The old one DtsFetchOutInterruptible: Failed:a
>only to 180. So I set the clock at the actually libcrystalhd to 180
>and voila at least I got a few pictures decoded. So I decided to test
>some clockrates. And at 150mhz I got quiet stable movie with
>gstreamer. Only a few framedrops when it says:
>
>"DtsFetchOutInterruptible: Failed:a"

Try 165, the original Linux driver/lib used 165 and that seems safe
for old layout BCM970012 cards. New layout BCM970012 are fine at 200.
Unfortunately, there is no way to tell the difference via PCI regs
between old and new, some old layout versions will have 2612 as the
subsystem id but I've also seen ones that have the same subsystem id
as the new layout BCM970012.

Craig Whitmore

unread,
Jul 28, 2010, 8:34:14 PM7/28/10
to crystalhd-...@googlegroups.com

>
> Try 165, the original Linux driver/lib used 165 and that seems safe
> for old layout BCM970012 cards. New layout BCM970012 are fine at 200.
> Unfortunately, there is no way to tell the difference via PCI regs
> between old and new, some old layout versions will have 2612 as the
> subsystem id but I've also seen ones that have the same subsystem id
> as the new layout BCM970012.
>

What about the Device Serial number.. Can they be identified via that?

ie lspci -vvv (as root)

Kernel driver in use: crystalhd
Kernel modules: crystalhd



Hendrik Borghorst

unread,
Jul 28, 2010, 8:59:43 PM7/28/10
to crystalhd-...@googlegroups.com
Hello,

I don't think this will work. My Serial Number is:
00-10-18-12-24-06-38-c4 .

Another question I've asked me, how does the windows driver work on all
three variants?

greetings

Hendrik Borghorst

Scott D. Davilla

unread,
Jul 28, 2010, 9:25:04 PM7/28/10
to crystalhd-...@googlegroups.com
>I don't think this will work. My Serial Number is:

>41-63-06-24-12-18-10-00


>00-10-18-12-24-06-38-c4 .

How odd, flip the order and now they are much closer


00-10-18-12-24-06-63-41
00-10-18-12-24-06-38-c4

Naren (Narendra) Sankar

unread,
Jul 29, 2010, 9:09:51 PM7/29/10
to crystalhd-...@googlegroups.com
A question I have asked myself many times ...

I do intend to walk through the Windows HW initialization code and the Linux HW initialization code and see what could be different that causes Linux to not work as expected.

One other option is that we could ask everyone to program the SSID on their old layout cards (heat spreader) cards to use 2612 and use that to differentiate the driver. Don't exactly like that idea.

Both cards should work at 200MHz and in general 200MHz operation is desired for some extreme corner case clips (like the Allegro stress streams). But for most users 165MHz could also be ok since most "real-world" streams should decode with adequate performance at that levels.

Naren Sankar (+1 408 218 6327)
Architect/PLM
Media PC, Broadband Communications Group
Broadcom Corp.

-----Original Message-----
From: crystalhd-...@googlegroups.com [mailto:crystalhd-...@googlegroups.com] On Behalf Of Hendrik Borghorst
Sent: Wednesday, July 28, 2010 6:00 PM
To: crystalhd-...@googlegroups.com

greetings

Hendrik Borghorst

--

Reply all
Reply to author
Forward
0 new messages