CityK wrote:
Hi Curt,
maillist wrote:
I hope that I can capture the firmware download, but yesterday I did
not see any large block write to the board after windows booted, so I
need to investigate this.
I got a PCI bus analyzer and was trying to capture the firmware
download when booting under windows. The problem is that there isn't
any firware download.
So, I started to suspect that either my board has an EEPROM with the
firmware or it is internal to the nxt2004, maybe they have flash memory?
I modified my nxt200x driver so that it skips the firmware download,
powered off my machine waited a minute, turned it back on and guess
what. It still works!
This is using a KWorld ATSC-110 card which has the Philips tuv1236
module on it. There is a visible eeprom on the board near the saa7135.
Maybe the driver in windows reads something from the nxt2004 to
confirm the version of firmware loaded and if it matches then it
doesn't bother downloading the firmware? That is the way we do things
where I work.
I'd speculate that the situation is similar to that described in the
following posts:
http://www.linuxtv.org/pipermail/linux-dvb/2006-January/007654.html
http://www.linuxtv.org/pipermail/linux-dvb/2006-January/007861.html
I'd imagine that, in the case of Windows, it is only when
installing/updating new drivers that a firmware version check & update
routine is included. For Linux, I imagine that to update the firmware
in the eeprom you'd have to do similar to Giampiero's efforts.
Although, you mention:
Makes sense.
Here is a picture (high res) of the Kworld card:
http://cmeyers.boilerbots.com/KworldPics/dscf0877.jpg
I modified the python script to extract the code you identified from
the current KWorld driver and it does not work with the nxt2004
driver. I can no longer lock onto a station, it comes and goes. Maybe
this new firmware has a few internal registers that are different? Or
maybe there are more bytes to the firmware. Possibly there is some
type of header in the firmware that indicates it's size.
I'm not certain how you forced the firmware upload.
As for the KS007 IC, I have no idea who makes this 18 pin IC.
Looking at some pics of the other cards which employ the Nxt2004, it
appears that:
EEPROM-Less
-Aver A180 (Michael K can confirm this for the A180)
- MDP-130 ... not positive, but it looks that way.
EEPROM
- ATI HDTV Wonder --- there is a small eeprom chip (position U2 on the
pcb) to the left of the Conexant A/V decoder (position U1), I can't make
out the logo
- ADS Instant ... not sure if that's an eeprom to the right of the can
or not ... need better pic
- Twinhan/Fujiplus ... certainly looks like they've used something
similar to THDTV20023 ... (doesn't Manu have one of these cards in his
possession? Perhaps he can confirm)
The driver doesn't burn the new firmware to the eeprom, as far as I can
tell, it doesn't even check what is already loaded. My speculation is
that it is uploading it to the RAM of the nxt2004 because it does a lot
of halts and resets to the processor after the upload. I do not believe
that the nxt2004 driver or the saa7134 driver is able to identify that
KS007 IC which I too believe is an eeprom on the serial bus.
When I replaced the "normal" firmware retrieved by the script with what
I extracted from the windows driver the firmware was loaded to the
nxt2004 but I could no longer tune any ATSC channels. The lock would
come and go. So either I didn't get the number of bytes extract right,
or this causes some changes to the interface.
Interesting claim in this forum that they received new firmware that
isn't available publicly yet:
http://forums.gbpvr.com/showpost.php?p=88231&postcount=14
Curt
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
