initial commit from dddvb-0.9.19c

docs/adapter_alloc

@@ -0,0 +1,7 @@
+The module parameter adapter_alloc lets you choose how adapter names are allocated.
+
+0 = one adapter per io if modules are present
+1 = one adapter for each tab on which a module was detected
+2 = one per tab even if no modules were detected
+3 = one adapter for all devices of one card
+

docs/ci

@@ -0,0 +1,31 @@
+The caX device associated with a CI device behaves just like any other 
+caX interface. You usually use it through a library like libdvben50221 
+which is part of the dvb-apps package available at linuxtv.org.
+
+But contrary to other hardware where the CI module is physically placed
+in the data path between the the demod and PCIe bridge, in the Digital
+Devices cards the CI module is separate hardware.
+So, you have to feed data to the CI module by writing to the secX
+(in later kernel ci0) device and read it back from the same secX device.
+The advantage is that the CI module can be used with any data coming from
+any frontend or file. The disadvantage is that the user application has to
+write/read the data to/from the module by itself. 
+
+The sample application apps/cit.c shows how to pipe a stream through
+the CI interface. In its ouput it will show discontinuities. Those should 
+only occur at the start of the program (due to old packets inside the CI 
+interface hardware and the CI module itself) and when a CI module is
+inserted or removed.
+
+Since some users have problems using standard software which cannot use 
+the CI interface in this way, there is now the redirect feature which allows 
+you to tell the driver to automatically pass the data coming from one 
+demod through a CI before offering it through the normal demux/dvr interface.
+But note that this is a kludge to support old software until they can
+use the new interface.
+See docs/redirect for more info.
+
+
+
+
+

docs/modulator

@@ -0,0 +1,29 @@
+
+Modulator channels will automatically be enabled if you redirect data 
+from a demodulator to it. 
+E.g._:
+
+first demod on bridge 0 TAB1, modulator on bridge 1.
+
+echo "00 10" > /sys/class/ddbridge/ddbridge0/redirect
+
+Currently it is fixed to QAM256. Controls will be added later.
+Rate control is experimental and PCR correction also not
+implemented yet. So, depending on the reception device
+there can be disturbances in playback.
+
+It is now also possible to chain redirects.
+E.g., demod and modulator as above, CI on bridge 0 TAB 2:
+
+echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect
+echo "02 10" > /sys/class/ddbridge/ddbridge0/redirect
+
+The stream is also still available at the demux device 
+belonging to the demod devices.
+
+Now write and start an application (not provided) that 
+talks to the CI to decrypt the desired services.
+For testing one can use a standard application that
+supports decryption. Additionally to seeing the
+decoded service on the PC it will then also be streamed
+into cable by the modulator.

docs/octopusnet

@@ -0,0 +1,89 @@
+OctopusNet
+----------
+
+Hardware:
+
+- SoC Atmel SAM9G45 400MHz ARM 926
+  64 MB DRAM
+  256 MB NAND flash
+
+- FPGA Lattice ECP3 17
+  data flash
+
+- 5 port switch Marvell 88E6175R
+
+
+The FPGA is connected to the memory bus of the G45 and maps control registers into the memory space
+of the G45. This is mainly to control the data flow on the FPGA. Only minimal data can be transferred
+(e.g. single sections). Transport streams cannot be transferred to the G45 this way!
+The FPGA can receive up to 8 TS from up to 4 Duo-Flex cards. You can also can alternatively connect
+CI modules to port 2 and 3 (TAP 3 and 4).
+
+The FPGA is also connected to one of the ports of the gigabit switch.
+There are up to 12 channels. Each channel can select one input TS, which is then passed through
+a PID filter (8192 bit array) and sent to the switch as a UDP/RTP stream.
+
+The G45 is connected to another port of the switch (but only with 100 MBit)
+
+
+Booting:
+
+The G45 does not boot from the NAND flash but from the dataflash connected to the FPGA. The G45
+does not support error correction for the boot sector and NAND with zero error boot pages
+is no longer easily available.
+Newer Atmel SoCs support 4-bit error correction in boot ROM but not the G45.
+
+So, the G45 boot looks like this:
+
+- Run a minimal boot rom mapped by the FPGA.
+- Boot rom loads a modified bootstrap via SPI (provided via FPGA ports) from the dataflash.
+- Bootstrap loads u-boot via SPI from dataflash.
+- u-boot boots Linux ...
+
+If you remove jumper XX, boot rom is disabled and the G45 will boot from NAND flash like this:
+
+- Internal G45 boot rom bootstrap from NAND flash.
+- Bootstrap boots u-boot from NAND flash
+- u-boot boots Linux ...
+
+This is just a fall-back since page 0 can contain errors which cannot be corrected by the G45 boot ROM
+and the bootstrap code which loads u-boot also does not contain error correction.
+
+
+
+- SPI dataflash
+
+0x000000 - 0x003fff FPGA config data
+0x004000 - 0x005fff G45 bootstrap
+0x010000 - 0x0affff FPGA bitstream
+0x0b0000 - 0x15ffff G45 u-boot
+0x160000 - 0x1fefff FPGA golden image
+0x1ff000 - 0x1fffff FPGA jump to golden image
+
+
+- NAND flash 256MB, block size 128K (0x20000)
+
+0x00000000 - 0x0001ffff G45 bootstrap (fallback bootstrap if SPI corrupted, pull jumper to use)
+0x00020000 - 0x0007ffff G45 u-boot (fallback u-boot if SPI corrupted)
+0x00080000 - 0x0009ffff spare (e.g. for bigger u-boot)
+0x000a0000 - 0x000bffff G45 u-boot environment
+0x000c0000 - 0x000dffff G45 u-boot redundant environment
+0x000e0000 - 0x000fffff spare
+0x00100000 - 0x01ffffff G45 Linux recovery
+0x02000000 - 0x0fffffff Linux UBI
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

docs/octopusnet.multicast

@@ -0,0 +1,104 @@
+Multicast
+---------
+
+Multicast setup supports 2 file formats.
+1) Simple variant for the avarage home user
+2) More parameters for the expert.
+
+The file is in csv (comma seperated values) format, which can be created with any plain text editor or imported/exported
+to/from Microsoft Office Excel or OpenOffice Scalc. With Excel or Scalc care for character set (should be UTF-8) and
+column formats is required. First line is contain then column headers.
+
+Standard parameters
+-------------------
+
+TITLE: Stream Title
+
+REQUEST: SAT>IP tune request string without the pid parameter. Exact format depends on frontend (DVB-S,DVB-T ..)
+use "-" to stream another program from the previous full entry (tuner sharing)
+
+PIDS: Pid list. Must start with a P, the values separated with a colon. "Pall" streams the whole transponder.
+(The P is there to ensure Excel or Scalc don't do some fancy format detection, like time conversion)
+
+LANPORTS: Empty or a list with colon separated lan ports starting with L, "Lall" = all ports.
+If empty, the stream will only be activated when subscribed with an IGMPv3 request. It will also
+only be active on the lan ports through which an IGMPv3 request for the stream has benn received.
+(For details how IGMPv3 works look up the relevant RFCs.)
+If not empty the stream will be preactived on the listed lan ports (and permanently using bandwidth!).
+It still can be subscribed with IGMPv3 on the other ports.
+
+
+TITLE,REQUEST,PIDS,LANPORTS
+"Das Erste","?freq=346&msys=dvbc&sr=6900&mtype=256qam","P0:100:101:104:102:103:106",""
+"Bayerisches FS Nord","-","P0:500:201:204:202:203:206",""
+"hr-fernsehen","-","P0:300:301:304:302:303",""
+"SWR Fernsehen BW","-","P0:800:801:804:802:803:806",""
+"WDR Köln","-","P0:600:601:604:602:603",""
+"ZDF","?freq=370&msys=dvbc&sr=6900&mtype=256qam","P0:100:110:130:120:121:122:125",""
+"ZDF HD","-","P0:6100:6110:6130:6120:6121:6122:6123",""
+"zdf neo","-","P0:650:660:680:670:671:672:675",""
+"zdf kultur","-","P0:1100:1110:1130:1120:1121:1122:1125",""
+"ZDFInfo","-","P0:600:610:630:620:621:622:625",""
+"KiKA","-","P0:300:310:330:320:321:325","L3:4:5"
+"3sat","-","P0:200:210:230:220:221:222:225",""
+
+
+Expert parameters:
+------------------
+
+PROTO: Protocol, must be "RTP" or "UDP". If you don't know what this means use "RTP".
+
+IP: Multicast IP address, recommended range 239.5.0.0 - 239.126.255.255, see notes below 
+about selecting a multicast IP address.
+
+PORT: Destination port. If you don't know what this means set it to 6670
+
+TTL: Time to live used in the IP headers. If you don't know what this means set it to 5.
+
+
+TITLE,REQUEST,PIDS,PROTO,IP,PORT,TTL,LANPORTS
+"Das Erste","?freq=346&msys=dvbc&sr=6900&mtype=256qam","P0:100:101:104:102:103:106","UDP","239.7.7.100",1234,7,""
+"Bayerisches FS Nord","-","P0:500:201:204:202:203:206","UDP","239.7.7.101",1234,7,""
+"hr-fernsehen","-","P0:300:301:304:302:303","UDP","239.7.7.102",1234,7,""
+"SWR Fernsehen BW","-","P0:800:801:804:802:803:806","UDP","239.7.7.103",1234,7,""
+"WDR Köln","-","P0:600:601:604:602:603","UDP","239.7.7.104",1234,7,""
+"ZDF","?freq=370&msys=dvbc&sr=6900&mtype=256qam","P0:100:110:130:120:121:122:125","UDP","239.7.8.100",1234,7,""
+"ZDF HD","-","P0:6100:6110:6130:6120:6121:6122:6123","UDP","239.7.8.101",1234,7,""
+"zdf neo","-","P0:650:660:680:670:671:672:675","UDP","239.7.8.102",1234,7,""
+"zdf kultur","-","P0:1100:1110:1130:1120:1121:1122:1125","UDP","239.7.8.103",1234,7,""
+"ZDFInfo","-","P0:600:610:630:620:621:622:625","UDP","239.7.8.104",1234,7,""
+"KiKA","-","P0:300:310:330:320:321:325","UDP","239.7.8.105",1234,7,"L3:4:5"
+"3sat","-","P0:200:210:230:220:221:222:225","UDP","239.7.8.106",1234,7,""
+
+
+Selecting a multicast IP address.
+---------------------------------
+
+It is obvious that there should be no conflicts with other services (like UPnP, Windows network ...)
+which also use Multicast for communication and advertisments.
+
+For media streaming usually an IP in the range 239.0.0.0 - 239.255.255.255 is used and
+will usually only conflict with other media sources. But this is not the whole truth!
+
+The complete IP multicast range is 224.0.0.0 - 255.255.255.254,  that is 536870911 different values.
+But there are only 8388608 different Ethernet MAC addresses allocated for IPv4 multicast. That
+means a lot of collisions. For example, 239.0.0.22 uses the same MAC address as 224.0.0.22 (IGMP).
+This means that 239.0.0.22 can't be blocked in an Ethernet switch without breaking IGMP.
+An IP from the range 239.5.0.0 - 239.126.255.255 does not collide with most documented
+services, and should be safe to use in most situations and the benefit from IGMPv3 
+snooping Ethernet switches.
+
+Multicast and WLAN
+------------------
+
+As there is no real support for it (due to encryption) Multicast over WLAN will not work very well.
+Therefor it should be avoided to send a out a multicast stream on a lan port there a WLAN router
+is connected (at least when the WLAN router is configured as LAN-WLAN bridge).
+
+As long there are free streams on the OctopusNet a RTSP player (including WLAN connected players)
+can request any service from a configured multicast source.
+For exmaple RTSP://<onetip>/stream=2?pids=0,300,310,330,320,321,325 will request KIKA
+as single cast stream from the above example. This is possible even if the entry for KIKA
+is removed from the multicast setup.
+(the above sample has no free streams left, but it should be clear what is meant)
+

docs/octopusnetpro

@@ -0,0 +1,9 @@
+- NAND flash
+
+0x00000000 - 0x0025ffff U-boot
+0x00260000 - 0x0027ffff ENV
+0x00300000 - 0x00ffffff Linux image
+
+0x01000000 - 0x01ffffff Linux recovery
+0x02000000 - 0x1fffffff Linux UBI
+

docs/redirect

@@ -0,0 +1,30 @@
+NOTE: This is an unsupported hack so that legacy software works
+      with the hardware!
+      To properly pass data through a CI CAM you should read
+      the TS from a dvr device and write it to a ci device
+      in user space!
+
+Redirection of TS streams through CI modules is now supported 
+through /sys/class/ddbridge/ddbridge0/redirect.
+It only works with cards based on the ddbridge PCIe bridge, not
+with nGene based cards.
+
+It is set up in such a way that you can write "AB CD" to
+a "redirect" attribute and data from input B of card A is then piped through
+port D (meaning TAB (D+1) which uses output D and input 2*D for CI io)
+of card C and then shows up in the demux device belonging to
+input B (input (B&1) of TAB (B/2+1)) of card A.
+
+E.g.:
+
+echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect
+
+will pipe input 0 of card 0 through CI at port 1 (TAB 2) of card 0.
+
+Redirection should only be done right after loading the driver 
+(or booting if the driver is built-in) and before using the
+devices in any way.
+
+adapter_alloc=3 is rcommended when using redirect
+The ci device will then show up in the same adapter directory and most
+software will then assume it belongs to the frontend in the same directory.