TW2866 i2c driver and solo6x10

TW2866 i2c driver and solo6x10

[Marty Plummer]

[-- Attachment #1.1: Type: text/plain, Size: 935 bytes --]

I have one of those rebranded chinese security dvrs, the ones with all the gaping
security holes. I'd like to fix that up and setup a good rtsp server on it, but
first comes low-level stuff, drivers and such. I've been squinting at the pcb and
ID'ing chips for a bit now, and I've figured most of them out. Looks like the actual
video processing is done on 4 tw2866 chips, though the kernel module has symbols
referring to tw2865. I've seen another driver in the kernel tree, the bluecherry
solo6x10, but that's on the pci bus. as far as I can figure, the dvr uses i2c for
them. So, what I'm wondering is would it be feasible to factor out some of the solo
functionality into a generic tw2865 driver and be able to pull from that for an i2c
kernel module? I'd really hate to have to rewrite the whole thing, duplicated code
and overworking are generally a bad idea, even if I do have a datasheet for the chip
in question


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: TW2866 i2c driver and solo6x10

[Andrey Utkin]

On Wed, Jul 27, 2016 at 11:51:22PM -0500, Marty Plummer wrote:
> I have one of those rebranded chinese security dvrs, the ones with all the gaping
> security holes. I'd like to fix that up and setup a good rtsp server on it, but
> first comes low-level stuff, drivers and such. I've been squinting at the pcb and
> ID'ing chips for a bit now, and I've figured most of them out. Looks like the actual
> video processing is done on 4 tw2866 chips, though the kernel module has symbols
> referring to tw2865. I've seen another driver in the kernel tree, the bluecherry
> solo6x10, but that's on the pci bus. as far as I can figure, the dvr uses i2c for
> them. So, what I'm wondering is would it be feasible to factor out some of the solo
> functionality into a generic tw2865 driver and be able to pull from that for an i2c
> kernel module? I'd really hate to have to rewrite the whole thing, duplicated code
> and overworking are generally a bad idea, even if I do have a datasheet for the chip
> in question


Hi Matt,

Bluecherry LLC software developer here (barely knowing about tw28xx stuff).

If I was you, I'd restrain from such project unless I had a bulk of such
hardware, not just single unit. This is because things are hard to get
right without tinkering step by step. Also somebody would still need to
do fair amount of coding. And unless you are already qualified to do it
alone, you'd need many cycles of asking questions and providing lots of
details of your actual system. If you are interested in merging your
results upstream, then there's even more efforts to put.
As a developer affiliated with Bluecherry LLC, I will do my best to help
you, but I am mere mortal with all sorts of constraints - knowledge,
time, etc. But I or Bluecherry won't just make everything for you, even
if you send us a sample of hardware (which would be a good start for a
volunteer willing to take that challenge).
So feel free to post here your specific questions if you go for it.

Re: TW2866 i2c driver and solo6x10

[Marty Plummer]

[-- Attachment #1.1: Type: text/plain, Size: 2960 bytes --]

On 08/03/2016 02:28 PM, Andrey Utkin wrote:
> On Wed, Jul 27, 2016 at 11:51:22PM -0500, Marty Plummer wrote:
>> I have one of those rebranded chinese security dvrs, the ones with all the gaping
>> security holes. I'd like to fix that up and setup a good rtsp server on it, but
>> first comes low-level stuff, drivers and such. I've been squinting at the pcb and
>> ID'ing chips for a bit now, and I've figured most of them out. Looks like the actual
>> video processing is done on 4 tw2866 chips, though the kernel module has symbols
>> referring to tw2865. I've seen another driver in the kernel tree, the bluecherry
>> solo6x10, but that's on the pci bus. as far as I can figure, the dvr uses i2c for
>> them. So, what I'm wondering is would it be feasible to factor out some of the solo
>> functionality into a generic tw2865 driver and be able to pull from that for an i2c
>> kernel module? I'd really hate to have to rewrite the whole thing, duplicated code
>> and overworking are generally a bad idea, even if I do have a datasheet for the chip
>> in question
> 
> 
> Hi Matt,
> 
> Bluecherry LLC software developer here (barely knowing about tw28xx stuff).
> 
> If I was you, I'd restrain from such project unless I had a bulk of such
> hardware, not just single unit. This is because things are hard to get
> right without tinkering step by step. Also somebody would still need to
> do fair amount of coding. And unless you are already qualified to do it
> alone, you'd need many cycles of asking questions and providing lots of
> details of your actual system. If you are interested in merging your
> results upstream, then there's even more efforts to put.
> As a developer affiliated with Bluecherry LLC, I will do my best to help
> you, but I am mere mortal with all sorts of constraints - knowledge,
> time, etc. But I or Bluecherry won't just make everything for you, even
> if you send us a sample of hardware (which would be a good start for a
> volunteer willing to take that challenge).
> So feel free to post here your specific questions if you go for it.
> 
An understanable sentement, but its not just about me (though I actually own two
of the same dvr's). There is a large number, if reports are to be believed, of
more or less identical dvr systems with the same security holes and hard-coded
credentials, with no vendor firmware updates. In addition, I am also in possesion
of the chip vendor sdk with full source code for the kernel and modules and a
host of pertenant datasheets. My end goal is something along the line of openwrt
or lede for these systems in the interest of the community at large.

I'm not averse to the concept of hard work, and while I'm very experienced when
it comes to kernel hacking I think I can manage well enough with relevant source
and examples, of which there is a large amount.

One concern I have is dealing with devicetree, but I think I can manage.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: TW2866 i2c driver and solo6x10

[Andrey Utkin]

On Wed, Aug 03, 2016 at 03:26:39PM -0500, Marty Plummer wrote:
> An understanable sentement, but its not just about me (though I actually own two
> of the same dvr's). There is a large number, if reports are to be believed, of
> more or less identical dvr systems with the same security holes and hard-coded
> credentials, with no vendor firmware updates. In addition, I am also in possesion
> of the chip vendor sdk with full source code for the kernel and modules and a
> host of pertenant datasheets. My end goal is something along the line of openwrt
> or lede for these systems in the interest of the community at large.
> 
> I'm not averse to the concept of hard work, and while I'm very experienced when
> it comes to kernel hacking I think I can manage well enough with relevant source
> and examples, of which there is a large amount.
> 
> One concern I have is dealing with devicetree, but I think I can manage.
> 

That's intriguing. I'm interested to know what this model is and where
it can be bought, and also to see all the sdk. BTW have you got sdk from
manufacturer after asking for it, or otherwise? Are manufacturers keen
to answer technical questions?

Re: TW2866 i2c driver and solo6x10

[Marty Plummer]

[-- Attachment #1.1: Type: text/plain, Size: 2714 bytes --]

On 08/03/2016 04:01 PM, Andrey Utkin wrote:
> On Wed, Aug 03, 2016 at 03:26:39PM -0500, Marty Plummer wrote:
>> An understanable sentement, but its not just about me (though I actually own two
>> of the same dvr's). There is a large number, if reports are to be believed, of
>> more or less identical dvr systems with the same security holes and hard-coded
>> credentials, with no vendor firmware updates. In addition, I am also in possesion
>> of the chip vendor sdk with full source code for the kernel and modules and a
>> host of pertenant datasheets. My end goal is something along the line of openwrt
>> or lede for these systems in the interest of the community at large.
>>
>> I'm not averse to the concept of hard work, and while I'm very experienced when
>> it comes to kernel hacking I think I can manage well enough with relevant source
>> and examples, of which there is a large amount.
>>
>> One concern I have is dealing with devicetree, but I think I can manage.
>>
> 
> That's intriguing. I'm interested to know what this model is and where
> it can be bought, and also to see all the sdk. BTW have you got sdk from
> manufacturer after asking for it, or otherwise? Are manufacturers keen
> to answer technical questions?
> 
The particular device in question was sold by an american company called
Night Owl (nightowlsp.com) and is the zeus-dvr5/10 (otherwise identical
except for the installed hdd size). The main board bears the markings
"rs-dm-77a" and the main webserver type binary is called 'raysharp_dvr',
and only operates in IE using activex and reduced security settings.

I'm not certain if you can outright buy it new anymore, as it is very
old and out of warranty, but a million new clones pop up each day, all
based on the same hi35xx chipset (mine is hi3520 in particular).

I've uploaded most of the source files to https://github.com/Hi-Spy/hi3520
with exception to the PDFs and binary blobs. The sdk is based around
kernel version 2.6.24, so it's quite old, but only has around 10k lines
of diff files between it and stock.

No, I was in communication with a few people with @hisilicon.com emails
that I managed to find on the kernel mailing list (see arch/arm/mach-hisi)
who eventually pointed me at mobile@huawei.com, but I've yet to recieve
a response. In the meanwhile I was trawling the chinese internet for
data, and managed to come across someone selling it for 5yuan, which is
too cheap to pass up. I don't know how cooperative they are going to be,
considering they've been using linux, u-boot, and a host of other GPL'd
software without mention or license for at least 5 years, the release
date of my particular SoC.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: TW2866 i2c driver and solo6x10

[Marty Plummer]

[-- Attachment #1.1: Type: text/plain, Size: 2948 bytes --]

On 08/03/2016 04:35 PM, Marty Plummer wrote:
> On 08/03/2016 04:01 PM, Andrey Utkin wrote:
>> On Wed, Aug 03, 2016 at 03:26:39PM -0500, Marty Plummer wrote:
>>> An understanable sentement, but its not just about me (though I actually own two
>>> of the same dvr's). There is a large number, if reports are to be believed, of
>>> more or less identical dvr systems with the same security holes and hard-coded
>>> credentials, with no vendor firmware updates. In addition, I am also in possesion
>>> of the chip vendor sdk with full source code for the kernel and modules and a
>>> host of pertenant datasheets. My end goal is something along the line of openwrt
>>> or lede for these systems in the interest of the community at large.
>>>
>>> I'm not averse to the concept of hard work, and while I'm very experienced when
>>> it comes to kernel hacking I think I can manage well enough with relevant source
>>> and examples, of which there is a large amount.
>>>
>>> One concern I have is dealing with devicetree, but I think I can manage.
>>>
>>
>> That's intriguing. I'm interested to know what this model is and where
>> it can be bought, and also to see all the sdk. BTW have you got sdk from
>> manufacturer after asking for it, or otherwise? Are manufacturers keen
>> to answer technical questions?
>>
> The particular device in question was sold by an american company called
> Night Owl (nightowlsp.com) and is the zeus-dvr5/10 (otherwise identical
> except for the installed hdd size). The main board bears the markings
> "rs-dm-77a" and the main webserver type binary is called 'raysharp_dvr',
> and only operates in IE using activex and reduced security settings.
> 
> I'm not certain if you can outright buy it new anymore, as it is very
> old and out of warranty, but a million new clones pop up each day, all
> based on the same hi35xx chipset (mine is hi3520 in particular).
> 
> I've uploaded most of the source files to https://github.com/Hi-Spy/hi3520
> with exception to the PDFs and binary blobs. The sdk is based around
> kernel version 2.6.24, so it's quite old, but only has around 10k lines
> of diff files between it and stock.
> 
> No, I was in communication with a few people with @hisilicon.com emails
> that I managed to find on the kernel mailing list (see arch/arm/mach-hisi)
> who eventually pointed me at mobile@huawei.com, but I've yet to recieve
> a response. In the meanwhile I was trawling the chinese internet for
> data, and managed to come across someone selling it for 5yuan, which is
> too cheap to pass up. I don't know how cooperative they are going to be,
> considering they've been using linux, u-boot, and a host of other GPL'd
> software without mention or license for at least 5 years, the release
> date of my particular SoC.
> 
> 
> 
Ah crap. I meant to include a 'not' or 'in' in the "While I'm very experienced"
sentence. Brain not working.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: TW2866 i2c driver and solo6x10

[Andrey Utkin]

I'm going to have quite constrained time for participation in this
driver development, but still I think this is perspective project which
is in line with trend of exposing internal details of complex media
hardware for configuration by V4L2 framework. Also tw286x are used in
both tw5864 and solo6x10 boards, and in both cases it could be
controlled better from userspace.
I think first thing to do is expose tw286x chips as i2c- (or more
precisely SMBus-) controllable devices. I have accomplished that in some
way for tw5864, and hopefully I'll manage that for solo6x10.
But beyond that, I currently don't know.
A senior mentor would be very appreciated :)

Re: TW2866 i2c driver and solo6x10

[Marty Plummer]

[-- Attachment #1.1: Type: text/plain, Size: 1388 bytes --]

On 09/19/2016 01:20 PM, Andrey Utkin wrote:
> I'm going to have quite constrained time for participation in this
> driver development, but still I think this is perspective project which
> is in line with trend of exposing internal details of complex media
> hardware for configuration by V4L2 framework. Also tw286x are used in
> both tw5864 and solo6x10 boards, and in both cases it could be
> controlled better from userspace.
> I think first thing to do is expose tw286x chips as i2c- (or more
> precisely SMBus-) controllable devices. I have accomplished that in some
> way for tw5864, and hopefully I'll manage that for solo6x10.
> But beyond that, I currently don't know.
> A senior mentor would be very appreciated :)
> 
I do appreciate the assistance. In most of this I'm already in water
above my head for the most part, but I'm making progress. Currently have
a booting kernel (4.8-rc4) and usb support, taking a go at the gmac/phy
driver atm. Its mostly similar to an existing driver, but I'd like to
get it up and running since the primary use of this device is over the
network, so even if we did have proper v4l2 devices it would not be
available over the network. One other thing I'm slightly worried about
is the sii/sil9034 hdmi chip included. Apparently its rather tricky to
get a datasheet for this without a NDA due to the drm stuff built in.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: TW2866 i2c driver and solo6x10

[Andrey Utkin]

So is the actual machine x86 or ARM?
Do the tw28xx chips behind the bus (i2c as you said) show up in any way
at all? Is something like i2c controller available? Or it's ARM and we
should tell kernel how to "find" the i2c line by feeding correct
devicetree to it?

Re: TW2866 i2c driver and solo6x10

[Marty Plummer]

[-- Attachment #1.1: Type: text/plain, Size: 858 bytes --]

On 09/22/2016 05:17 PM, Andrey Utkin wrote:
> So is the actual machine x86 or ARM?
> Do the tw28xx chips behind the bus (i2c as you said) show up in any way
> at all? Is something like i2c controller available? Or it's ARM and we
> should tell kernel how to "find" the i2c line by feeding correct
> devicetree to it?
> 
This particular device is ARM. I can't be certain right now, as I've not
gotten to the point of handling the i2c bus; In the kernel module that
it currently uses it has hard-coded i2c addresses for each chip and does
a small for-loop to do the setup i2c stuffs. I could see about getting
the i2c bus running really quick and see if the various i2c tools
buildroot provides can see them, if that's helpful.

If you could provide a list of useful info and how to acquire it I'd be
more than willing to probe stuff for it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]