PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Fortis 4th generation HD receivers: some info



Audioniek
25.01.2015, 17:17
At the moment I am working on Enigma2 for 3 models of the Fortis 4th generation HD receivers, often referred to (but not altogether correctly) as the Cardiff models. Here is some info I came across while researching these receivers; info on the net is rather scarse and scattered all over the place.



Model
ResellerID
Display (width)
SoC
Tuner(s)
RAM
Flash
SATA
USB
CI slots
Cardreaders
Loader
Successor of
Marketed as (XX=)


DP6010
29XX0000
LED (4)
StiH237 (Cardiff)
1xS2
512MB DDR3
256MB NAND
No
3
1
1
L8.05,
L1.0.0
HS7110,
HS7119
Fortis DS220
XCruiser XDSR385HD Avant (01)
Visionnet Hawk (02)
Openbox SX4 HD (03)
Skyway Nano 3 (04)
SuperBox Elite 4+ (05)
Rebox RE-2220HD S-PVR (06)
Dreamsky HD4X (08)
Forever HD Nano Smart PVR Cardiff (09)
Drake 7500HD Mini (12)
HD Box 4500 plus (13)
Star Track Grand HD (14)
Octagon SF928GX CA CI+ HD (24)



DP7001
29XX0100
LED (4)
StiH237 (Cardiff)
1xS2
512MB DDR3
256MB NAND
No
4
2
1
L8.05,
L1.0.0
HS7810A,
HS7819
Fortis DS260
Rebox RE-4220HD S-PVR (06)
HD Box 6500 plus (13)
Star Track DeLuxe HD (14)


DP7000
29XX0200
VFD (8)
StiH237 (Cardiff)
1xS2
512MB DDR3
256MB NAND
No
4
2
2
L8.14,
L8.15,
L4.0.0
HS7420,
HS7429
Fortis DS260N
Openbox SX6 HD (03)
Skyway Classic 4 (04)
Dreamsky HD6 Duo (08)
Forever HD 9898 PVR Cardiff (09)


DP2010
29XX0300
VFD (8)
StiH237 (Cardiff)
1xS2
512MB DDR3
256MB NAND
No
3
0
1 or 2
L8.14,
L8.15,
L4.0.0

Forever HD 3434 PVR Cardiff (09)
Drake 7500HD-V3 (12)


DP7050
29XX1000
LED (4)
StiH237 (Cardiff)
1xS2
256MB DDR3
128MB NAND
No
3
1
1
L8.24,
L8.25,
L3.0.0

XCruiser XDSR2600HD Avant (01)
Visionnet Nova (02)
Openbox SX4 Base (03)
Skyway Light 2 (04)
SuperBox Elite TV (05)
Forever HD 2424 PVR Cardiff (09)
HD Box 3500 plus (13)
Star Track SRT 2014 HD Premium (14)
Dynavision DV6000HDPVR (17)


EPP8000
2AXX0000
VFD (8)
StiH239 (Newport)
2xS2
512MB DDR3
256MB NAND
Yes
4
2
2
L8.37,
L2.0.0
HS8200
Fortis ESS300
Rebox RE-8220HD S-PVR (02)
Openbox SX9 HD (04)
Icecrypt S6600HD PVR (05)


EP8000
2AXX0100
VFD (8)
StiH239 (Newport)
1xS2
512MB DDR3
256MB NAND
Yes
4
2
2
L8.37,
L2.0.0

XCruiser XDSR420HD Avant (01)


EP8000
2AXX0101
VFD (8)
StiH239 (Newport)
1xS2
512MB DDR3
256MB NAND
Yes
4
2
2
L8.37,
L2.0.0

XCruiser XDSR400HD Avant (01)
Proween STI-820HD Grand (03)


GPV8000
29XX2000
VFD (8)
StiH253 (Firenze)
1xS2
1xT2
512MB DDR3
256MB NAND
Yes
4
2
2
L8.15,
L4.0.0
(HS8200)
Skyway Droid 2 (04)
Openbox SX9 HD Combo (03)



The DP6010 uses an external 12V DC power supply, the others have built-in 100-240V AC power supplies that internally only deliver 12VDC. The mainboard itself creates all other voltages, including the ones for the frontpanel and the LNB(s).

All these models no longer have an intelligent frontprocessor, but a relatively dumb display/keyboard driver.

The remote control shipped with these receivers is very dependent on the reseller involved. The remote control codes and the available keys have not changed however compared to the previous Fortis HD generations.

The loader has been improved greatly as it now uses USB 2.0 drivers (no more hassles with older sticks, very fast flashing) and displays a video picture directly upon powering on. The picture can be reflashed. The Fortis .IRD flash file format has not been changed. Although the sub-version numbers suggest booting an USB image is supported, running an image directly off an USB stick is not possible without changing the bootargs.

Main CPU clock speed is reported as 650 MHz on all models. The main CPU in the SoC seems to be an STxH205 cut B in all cases.

More to follow in upcoming posts...

Regards,

Audioniek.

Update (December 4th 2019)
In the past weeks I came across some new info, mainly gathered from .config kernel files in official Fortis flash files. In addition to the models listed above, there is also a DP2010, a low cost model without capabiities for CI-slots, but with a VFD display. At this moment no further information is known by me about this model, however it is quite possible that the Forever HD 3434 PVR Cardiff and the Drake 7500HD-V3 are DP2010's.
The same kernel .config files do not have an entry for the EP8000. It may well be that this model is simply an EPP8000 with one tuner left out and a different backpanel. The assigned resellerID seems to confirm this as it uses the 3rd byte to distinguish it from the EPP8000. The other models with some differences in hardware follow the same practice; the 4th byte was apparently used to indicate a different cabinet.

The DP6010 is called the FX6010 in the .config files, but DP6010 on its main board. This has lead me to conclude that the title 4th generation may not be entirely correct. Upon closer scrutiny it may well be that Fortis used the first letter of the type name as generation indicator. If so, there are 7 generations, with the following setup:

Generation 1: FS9000, FS9200, HS9510;
Generation 2a: HS7110, HS7420, HS7810A, HS8200 (loader 5.XX);
Generation 2b: HS7110, HS7420, HS7810A, HS8200 (loader 6.XX);
Generation 3: HS7119, HS7429, HS7819 (loader 7.XX);
Generation 4: DP2010, DP7000, DP7001, DP7050 (loader 8.XX or 3.0.0/4.0.0);
Generation 5: EP8000, EPP8000 (loader 8.XX or 2.0.0);
Generation 6: FX6010 (loader 8.XX or 1.0.0);
Generation 7: GPV8000 (loader 8.XX or 4.0.0).


Lastly I have come across an untouched EPP8000 which loader signs on with the unusual version number 2.00.

Update (December 26th 2019)
It appears Fortis changed the version numbering of the bootloaders during the production run of these models. Later receivers have three-digit version numbers in stead of the usual two. Numbering starts at 1.0.0. As before, no bootloaders have been seen that support booting from USB.
The DP7050 is appearently intended as a low cost entry model; it is the only one with 256 Mbyte RAM and 128 Mbyte of flash, half of the other models.

solala
25.01.2015, 20:03
thanks for the informations, they should have done this

The loader has been improved greatly as it now uses USB 2.0 drivers (no more hassles with older sticks, very fast flashing) and displays a video picture directly upon powering on
a few years before :36_2_49:

souhai
25.01.2015, 22:12
thnks ...

Forever HD 3434 PVR Cardiff Loader v 8.15

XCRUISER XDSR385HD AVANT Loader v8.05
XCRUISER XDSR2600HD AVANT Loader v8.25
XCRUISER XDSR420HD AVANT Loader v8.37 1xS2
XCRUISER XDSR400HD AVANT Loader v8.37 1xS2

PROWEEN STI820HD_GRAND Loader v 8.37 1xS2

Dreamsky HD6 Duo Loader v8.15

SuperBox Elite TV = Openbox SX4 Base Loader v8.25
SuperBox Elite 4+ Loader v8.05

Hd box 3500 plus = OPENBOX SX4 Base Loader v 8.25
Hd box 4500 plus Loader v8.05
Hd box 6500 plus Loader v8.15

Drake 7500HDV3
Drake 7500HD Mini

altayeb
25.01.2015, 23:25
thnks ...

XCRUISER XDSR385HD AVANT Loader v8.05
XCRUISER XDSR2600HD AVANT Loader v8.25
XCRUISER XDSR420HD AVANT Loader v8.37 1xS2
XCRUISER XDSR400HD AVANT Loader v8.37 1xS2

AND
FOREVER HD 9898
FOREVER HD 3434
FOREVER HD 2424
FOREVER NANO Smart

altayeb
26.01.2015, 13:54
ALL Reseller fortis cpu StiH237 (Cardiff) ,StiH239 (Newport),StiH253 (Firenze)

Drake 7500HD Mini:29120001
Drake 7500HDV3:29120300
DREAMSKY HD4X:29080000
DREAMSKY HD6DUO:29080200
DYNAVISION DV6000HDPVR:29171100
FOREVER HD2424PVR:29091000
FOREVER HD3434PVR:29090300
FOREVER HD9898PVR:29090200
FOREVER NANOSMART CARDIFF:29090000
HD Box 3500 plus:29131100
HD Box 4500 plus:29130001
HD Box 6500 Plus:29130100
Icecrypt S6600 HD PVR:???????
OPENBOX SX4:29030000
OPENBOX SX4 BASE:29031000
OPENBOX SX6:29030200
OPENBOX SX9:2A040000
OPENBOX SX9COMBO:29032000
PROWEEN STI820HD GRAND:2A030101
Rebox RE-2220 HD PVR:29060000
Rebox RE-4220 HD PVR:29060100
Rebox RE-8220 HD PVR:2A020000
SKYWAY CLASSIC4:29040200
SKYWAY DROID2:29042000
SKYWAY LIGHT2:29041000
SKYWAY NANO3:29040000
Star Track Grand HD:29140000
Star Track Premium HD:29141100
Star Track Deluxe HD:29140101
SUPERBOX ELITE4PLUS:29050000
SUPERBOX ELITETV:29051000
VISIONNET HAWK:29020000
VISIONNET NOVA:29021100
XCRUISER XDSR2600HD AVANT:29011000
XCRUISER XDSR385HD AVANT:29010000
XCRUISER XDSR400HD AVANT:2A010101
XCRUISER XDSR420HD AVANT:2A010100

Thank you

souhai
26.01.2015, 17:53
Sw official site Fortis
http://1.234.6.235/xx/v3.01.93.list

To download sw for example

http://1.234.6.235/xx/v3.01.93/29171100.ird

Audioniek
01.02.2015, 11:56
The L8.XX bootloader

With the fourth generation of Fortis HD receivers, the major bootloader version number has been changed to 8. Compared to the previous version 7 loaders there are two new features, as already mentioned:

USB drivers have been improved and now use USB specification 2.0. The net result is that almost any USB stick can now be used to flash the receiver, and that reading the flash file is quite a bit faster.
Immediately on power up the loader outputs a picture on all available video outputs. The picture is stored in flash memory in mtd3 as a .gz file and can be (re)flashed using IRD-partition 9. Inside the .gz file is a file called resellername.Booting.gam which seems to be a 24-bit uncompressed bitmap file without a colour table. The picture size is 1280x720 pixels.

As customary with Fortis, flashing can be induced by powering up the receiver with a depressed channel-up key on the frontpanel. The current 8.XX loaders do not support switching to booting directly from USB by holding channel-down; at least I have not seen such loaders yet.

The flash memory map

By memory address:

Start End Size Type Purpose MTD IRD fixed DecSt DecSz
0x000000000 - 0x0000FFFFF 0x000100000 Flash, bootloader 0 0 Y 0 MB 1 MB
0x000180000 - 0x00037FFFF 0x000200000 Flash, logo 3 9 Y 1.5 MB 2 MB
0x000380000 - 0x0003FFFFF 0x000080000 Flash, EEPROM 4 - Y 3.5 MB 0.5 MB
0x000400000 - 0x0007FFFFF 0x000400000 Flash, kernel 1 6 Y 4 MB 4 MB
0x000800000 - 0x00BDFFFFF 0x00B600000 Flash, rootfs (UBI) 2 1 Y 8 MB 182 MB
0x008000000 - 0x0080FFFFF 0x000100000 Flash, Configuration 5 - Y 128 MB 1 MB
0x00BE00000 - 0x00FDFFFFF 0x004000000 Flash, User 6 - Y 190 MB 64 MB
0x00FE00000 - 0x00FFFFFFF 0x000020000 Flash, config1 8 - Y 254 MB 2 MB

By MTD:

MTD Start End Size Type Purpose IRD fixed DecSt DecSz
0 0x000000000 - 0x0000FFFFF 0x000100000 Flash, bootloader 0 Y 0 MB 1 MB
1 0x000400000 - 0x0007FFFFF 0x000400000 Flash, kernel 6 Y 4 MB 4 MB
2 0x000800000 - 0x00BDFFFFF 0x00B600000 Flash, rootfs (UBI) 1 Y 8 MB 182 MB
3 0x000180000 - 0x00037FFFF 0x000200000 Flash, logo 9 Y 1.5 MB 2 MB
4 0x000380000 - 0x0003FFFFF 0x000080000 Flash, EEPROM - Y 3.5 MB 0.5 MB
5 0x008000000 - 0x0080FFFFF 0x000100000 Flash, Configuration - Y 128 MB 1 MB
6 0x00BE00000 - 0x00FDFFFFF 0x004000000 Flash, User - Y 190 MB 64 MB
7 0x000000000 - 0x00FFFFFFF 0x010000000 Flash, entire - Y 0 MB 256 MB
8 0x00FE00000 - 0x00FFFFFFF 0x000020000 Flash, config1 - Y 254 MB 2 MB

By IRD partition:

IRD Start End Size Type Purpose MTD fixed DecSt DecSz
0 0x000000000 - 0x0003FFFFF 0x000100000 Flash, bootloader 0 Y 0 MB 1 MB
1 0x000800000 - 0x00BDFFFFF 0x00B600000 Flash, rootfs (UBI) 2 Y 8 MB 182 MB
6 0x000400000 - 0x0007FFFFF 0x000400000 Flash, kernel 1 Y 4 MB 4 MB
9 0x000180000 - 0x00037FFFF 0x000200000 Flash, logo 3 Y 1.5 MB 2 MB


Compared to the previous loader family L7.xx the following can be noted:


The configuration partition mtd5 still exists, but cannot be flashed, and is also located in the exact middle of the flash memory, inside the rootfs. It seems to be not used but it apparently exists for compatibility reasons.
The storage for the logo picture is in mtd3, which used to be the dev-partition. It can be (re)flashed using IRD partition 9. I have not yet figured out the precise file format of the picture file apart from the info given above, but solala has given some info towards that goal (see his posting below).
Although it cannot be deduced from the info above, the user-partition is no longer used to hold the var folder. The Fortis stock firmware used it to store additional modules such as FreeTV and the plugins. The var folder is now part of the rootfs.
The maximum bootloader size has been increased from 256 kbyte to 1 Mbyte.
The maximum kernel size has been increased from 3 MB to 4 MB.
The maximum rootfs size has been almost doubled from 96 MB to 182 MB. The filesystem in use is still UBI.
The user partition has been shrunk from 144 MB to 64 MB and does seem to be used anymore: on all receivers I have seen so far is it is in its erased state. It is however still large enough to hold Neutrino, so maybe someone can figure out a dual boot system in the future.
The set of mtd blocks do not cover the entire flash memory; these is a hole of 512 kbyte at 0x00100000 (1 Mbyte).

This memory layout can also be used to hold/run Enigma2 or Neutrino without resorting to exotic tricks like remapping and/or mtd partition concatenation. So far I have used this layout to develop Enigma2 with because with this approach Enigma2/Neutrino can be run in flash without changing anything in the bootloader.

As usual, Fortis uses the tens of the minor version number to indicate the receiver model(s). The earliest minor unit number I have seen is 4, with 5 being current.
At the moment all receivers with a resellerID starting with 0x2A use loader L8.37.

The bootloader environment is held at 0x00100000 (1Mbyte) and has a size of 0x20000 (128 kbyte), This memory area is not part of any mtd block.

Flashing from an .IRD file (loader 8.XX)
The flash process seems to be as follows. First, the loader will load the entire contents of the .IRD in to RAM, starting at address 0x84000000. Each partition will be loaded into RAM in the order they occur in the .IRD file.
The loader will check the CRC checksums in the .IRD against the data read and unpacked (the partitions in the .IRD are Zlib-compressed). The order in which the partitions are flashed is: 0, 1, 6 and 9. Partitions that are absent in the .IRD file are skipped and it does not matter in which order the partitions are present in the .IRD file.
Prior to flashing a partition, the whole partition will be erased. With loader 6.00 and earlier this used to be only the erase blocks that were going to be written to (observed with partitions 6 and 1).

Partition 0 (boot loader) if present in the .IRD will always be flashed at address 0x0 and has a maximum size of 0x00100000 (1 Mbyte).
The kernel partition (6) is always flashed at address 0x00400000.
The next flashable partition (1) will be flashed at the fixed address 0x00800000. This partition must contain a valid UBI file system with the entire rootfs in it.
Partitions 2, 3, 4, 5, 7 and 8 cannot be flashed: if any of them are present in the .IRD file, the flashing process aborts with an Er.11 on the display (size error).
Partition 9 is optional; flashing a boot picture is not mandatory.
As usual, there is no way to change the bootargs by flashing an .IRD file.

More to follow...

Regards,

Audioniek.

Audioniek
01.02.2015, 15:54
Creating a .IRD flash file or the flash environment

About 7 months ago I was asked by the HDMU team to rewrite the flash environment found in the duckbox-developers git. The environment has been made consistent in particular in the aspects of screen output and terminology, and where applicable support for creating files for running an image off an USB stick has been added.
There is now only one command to start to create the output file after a build has been completed; just run

fakeroot flash.sh
in the flash folder. The script will use the file X/cdk/LastChoice to determine most of the information required and will proceed to ask some straightforward questions pertaining the destination of the result files. After that, the output file(s) asked for can be found in the directory X/flash/out. If on start it is determined that (some of) the flash tools needed are missing they are retrieved from the net, compiled and added.

When doing this job, I also added the then non-existent flash support for the 3rd generation Fortis receivers for both Enigma2 and Neutrino. In addition flash support for Neutrino for the 2nd generation of Fortis models with loader 6.XX was added, based on the experience gained developing the flash solution for the HS8200 with loader 6.00. Enigma2 is too large for these models as they only have 32 Mbyte of flash memory.

Because the 3rd and 4th generation of Fortis receivers effectively only differ in flash layout but not in technical approach and the 4th generation has been simplified by Fortis, it was relatively easy to add flash support for the latter. This environment has been in use during the ongoing development of Enigma2 for about 4 months now and I consider it stable and relatively bug free. As far as I know all HDMU images are created with a previous version of it.

Update (14/02/2015): the flash environment has been updated to support flashing the power on bootloader picture.

It can be found here: Audionieks Fortis-4G git (https://github.com/Audioniek/Fortis-4G).

More to follow...

Regards,


Audioniek.

PS. Please note that the duckbox/developers/flash git still has the old flash environment.

Audioniek
03.02.2015, 20:34
The 4th generation hardware

As mentioned above, the fourth generation Fortis HD receivers are technically quite different compared to their predecessors:

The dedicated front panel processor is gone. This processor handled the front panel keyboard, the front panel display and the remote control and could be addressed by sending it a specific command and reading the answer for all three tasks;
The power management is different, especially with regard to deep standby. The SoC (Sytem on Chip) features a hibernation mode which is now used as deep standby mode. The previous generations powered down everything but the frontpanel processor to achieve deep standby;
External chips for the wired network and the extra USB ports are no longer there, as these are all present inside the SoC. The SATA interface in the upscale models is also part of the SoC;
The LNB power driver has been changed. So far Fortis used the A8293 I2C driven LNB power controller, but has switched to the STM manufactured LNBH25PQR for the single tuner models. The EPP8000 uses the sister variant LNBH26PQR that has two LNB outputs. The new STM chips are also I2C controlled, and even occupy the same I2C address, but are not code compatible with the A8293;
The satellite tuner(s) seem to be technically the same and based on an STx0903 chip, because a reconnaissance of the I2C addresses finds a device on I2C address 0x68 as before and the tuners look the same as in generation 3. The exception is the DP6010 which has lost its LNB out connector compared to the HS7119. At the moment I do not have any info regarding the DVB-T/C tuner of the GPV8000;
The card reader(s) seem to be the same as previously used in the HS7810A/7819 and are based on the ST8024C (also known as TDA8024T). I hope the driver for it needs little or even no modification;
The controller for the CI-slot(s) in the DP6010 and DP7001 is still the Coreriver CICORE10 also present in the HS7810A/7819, so hopefully the same or slightly modified driver code can be used. The EPP8000 uses a PMT4401B-GC2 chip. In my EPP8000 receiver it has SmarDTV stamped on it as manufacturer, although it is also made by others. As far as I know this chip has not been used by Fortis before, which means a whole new driver or using one from another receiver. For the moment I assume the EP8000 uses the same arrangement, although it is possible it has the CICORE10;
Fortis has switched back to fixed tuners: no model of the fourth generation has pluggable tuners, which I think is a missed opportunity. Apparently the market dictates low pricing over technically advanced. In the same respect I had hoped for a triple tuner model, but that has not appeared either.

The net result is that the mainboard has even less chips on it than before.

The front panel
The front processor, which in the first generations was usually made by Nuvoton (hence the name of the driver module), has been replaced with a relatively dumb display keyboard driver IC. The LED models use an ET6226, which is I2C driven, the VFD models use a ET16315, that is GPIO pin driven (bit banged). For these chips equivalent versions from various manufacturers with other type numbers are available as well.
The driver chip takes over two of the three original front processor tasks: driving the display and reading the front panel keyboard. Because it is not as intelligent as the original front processor the driver is much more complicated and code intensive.

Because of the changed power management, the power key cannot be handled by the display/keyboard driver anymore but is handled by the SoC directly. It is connected to a GPIO pin and not part of the front panel key matrix. Pressing the key grounds the GPIO pin.

The remote control
Fortis has connected the data output of the IR receiver module to a GPIO pin of the SoC and uses LIRc (Linux Infra Red controller) to receive and decode the remote control keys in their stock firmwares. For Enigma2 and Neutrino the same approach looks as the obvious way to go.

The power management
Because of this whole new approach to the power states standby and especially deep standby, the code for handling the various power states probably needs elaborate changes. At the moment of writing this is largely unexplored territory for me as the SoC data sheets are unfortunately confidential.

Conclusion
New drivers are to be written for:

The front panel driver chips ET6226 and ET16315;
The STM LNB power controllers;
The PMT4401B-GC2 CI controller;
The remote control;
The power management.


More on that in an upcoming post (yes, some of that work has been done)...

Regards,

Audioniek.

younesetre
06.02.2015, 18:50
Thanks you are incredible

Audioniek
10.02.2015, 17:22
The project approach

The reason I started to try and bring Enigma2/Neutrino to the 4th generation Fortis receivers is twofold:

The duckbox-developers-git has an entry for the DP7000, so somebody (j00zek) already had provided a starting point;
I owned a DP7001 at that point in time.


I first set out to explore the DP7000 stuff in the git mentioned, and soon found out that it probably contained some files directly originated from Fortis, but also that apart from some basic aspects, not much had been done with regard to receiver specific development. In addition, apart from the initial commit, the git has been stationary with regard to the DP7000 up to now.

Then I devised an approach of my own. The first step was to build a debug kernel that can be loaded and started with the stock bootloader already present in the receiver. Once the printk output can be seen on the serial port of the receiver, its config can be tuned and the required features can be added one by one. This has led to the .config I am using for about two months now, although it is not finished and/or optimized. The current kernel loads (with one error remaining) and starts the /etc/init.d/.rcS. Later on in the project I succeeded in retrieving the .config used by Fortis from the kernel in one of the their stock firmwares and used that info to further tune the .config I use. So far I have only built with patch level 215.

The next step is one I foresaw I could not finish on my own (and one of the reasons I started this thread): try and get/build all the drivers. Some are simply missing and not created yet in any git like the frontpanel driver, others do probably exist but are not available publicly or not found yet (like the FDMA firmware). I have tried to write the missing drivers on my own, and succeeded for some. The order of building is simply the order the rcS script uses to install them.

When the essential drivers are all ready, the next step would be to adapt Enigma2/Neutrino to the receiver(s), but that point has not been reached yet.

More to come, the kernel is in the next posting...

Regards,

Audioniek.

Audioniek
12.02.2015, 22:54
The kernel

As explained in the previous posting, the kernel .config has been determined through trial and error at first, after which the .config used by Fortis themselves was retrieved from a stock firmware kernel. This led to both a further refinement of the .config as well as confirmation of most of the choices made so far. The .config currently used is not final and can certainly be optimized, but my first goal was to build a kernel that would start and try to execute the /etc/init.d/rcS, and that first goal has been achieved.

The second part that is receiver specific is the modification of the kernel source files to adapt them to the main board specifics. Here the files already provided for the DP7000 in the duckbox-developer git came in handy, as they seemed to originate from Fortis directly.

Fortis has based the models DP6010 and DP7001 on the B2067 Rev C board; the EPP8000 is based on the similar B2064 board. For the moment I assume that the DP7000 and DP7050 are based on the B2067C as well, but this needs confirmation. For the EP8000 which is possibly a stripped EPP8000 and the GPV8000 which is also a twin tuner model, your guess is as good as mine. My guess is the B2067C for the moment until confirmed otherwise, although the loader version 8.37 points to the B2064 board.
These boards use the TM1668 driver chip as display/keyboard driver for the front panel as standard. As reported, Fortis uses an ET6226 for the LED models and an ET16315 for the VFD ones. I removed the TM1668 code from the kernel, and decided to add the driver code to the frontpanel driver to be loaded by the /etc/init.d/rcS script, which has been the usual approach with Enigma2/Neutrino.

I added the usual patch to add the MAC address from the bootargs into the kernel command line and proceeded with adding the mtd blocks, which are the same as the setup used by Fortis. This approach is needed to be able to use the factory supplied boot loader, and as explained before yield a memory layout that is quite suitable for both Enigma2 and Neutrino. I was lucky with respect to printk output through the RS-232 console connection, as the setting of the DP7000 .config and setup patches worked immediately.
The GPIO numbers were determined by adding a temporary test programme to the initial kernel code and observing the behaviour of the LEDs and control lines of the front panel driver. In some setup patches it is still present, but will be removed of course when things get more definitive.
As of this posting, the result of all this can be found in the Fortis-4G git (https://github.com/Audioniek/Fortis-4G).

When built and flashed in an EPP8000, the console output of the kernel startup is currently this:

Error: Bad gzipped data -> normal boot loader message when no valid boot up picture .gz file is present in mtd3 block
FrTs###*#2
Linux version 2.6.32.61_stm24_0215 (ndv@TEST-PC) (gcc version 4.8.2 20131016 (STMicroelectronics/Linux Base 4.8.2-131) (GCC) ) #1 PREEMPT Thu Feb 12 17:51:19 CET 2015
Boot params:
... MOUNT_ROOT_RDONLY - 00000001
... RAMDISK_FLAGS - 00000000
... ORIG_ROOT_DEV - 00000200
... LOADER_TYPE - 00000000
... INITRD_START - 00000000
... INITRD_SIZE - 00000000
Booting machvec: epp8000
Node 0: start_pfn = 0x40000, low = 0x52800
Zone PFN ranges:
Normal 0x00040000 -> 0x00052800
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00040000 -> 0x00052800
Fortis EPP8000 board initialisation
STxH205 version 2.x
bpa2: partition 'bigphysarea' created at 0x48000000, size 32768 kB (0x02000000 B)
bpa2: partition 'LMI_IO' created at 0x4a000000, size 65536 kB (0x04000000 B)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 75184
Kernel command line: console=ttyAS0,115200 root=/dev/mtdblock2 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs rw init=/bin/devinit coprocessor_mem=4m@0x40000000,4m@0x40400000 printk=1 console_loglevel=7 stmmaceth=ethaddr:00:1e:b8:0f:e9:92
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
PVR=04909420 CVR=60880000 PRR=0000aa00
I-cache : n_ways=2 n_sets=512 way_incr=16384
I-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
D-cache : n_ways=2 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
Memory: 188160k/303104k available (3478k kernel code, 1692k data, 128k init)
Hierarchical RCU implementation.
NR_IRQS:600
Console: colour dummy device 80x25
console [ttyAS0] enabled
sh_tmu: TMU0 used for clock events
sh_tmu: TMU0 used for periodic clock events
sh_tmu: TMU1 used as clock source
Calibrating delay loop... 645.12 BogoMIPS (lpj=322560)
Mount-cache hash table entries: 512
CPU: STxH205
[STM][PM-Sys]: ilc3 @ 4096
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
SCSI subsystem initialized
Generic PHY: Registered new driver (0xffffffff)
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
DMA: Registering DMA API.
Switching to clocksource TMU1
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
[STM]: [PM]: Suspend support registered
[STM]: [PM]: HoM support registered
[STM]: [PM]: [HoM]: Early console @ fe530000
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Slow work thread pool: Starting up
Slow work thread pool: Ready
NTFS driver 2.1.29 [Flags: R/W].
fuse init (API version 7.13)
msgmni has been set to 367
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
lirc_dev: IR Remote Control driver registered, major 61
lirc-stm: probe found data for platform device lirc-stm
lirc-stm: STM LIRC plugin using IRQ 181 in IR mode
lirc_dev: lirc_register_driver: sample_rate: 0
STMicroelectronics LIRC driver initialized.
STMicroelectronics ASC driver initialized
stm-asc.0: ttyAS0 at MMIO 0xfe530000 (irq = 219) is a stm-asc
loop: module loaded
MiPHY driver style MiPHYA40X probed successfully
MiPHYA40X, c2.1 Claimed by ahci
ahci ahci: forcing PORTS_IMPL to 0x1
ahci ahci: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
ahci ahci: flags: ncq sntf pm led clo only pmp pio slum part ccc apst
scsi0 : ahci
ata1: SATA max UDMA/133 mmio [0xfd548000-0xfd548fff] port 0x100 irq 234
ONFI flash detected
ONFI param page 0 valid
NAND device: Manufacturer ID: 0x01, Chip ID: 0xda (AMD S34ML02G1)
stm-nand-flex: Using legacy platform timing data
stm-nand-flex: Using boot partition name [boot] (from kernel config)
cmdlinepart partition parsing not available
Creating 9 MTD partitions on "stm-nand-flex":
0x000000000000-0x000000100000 : "boot"
0x000000400000-0x000000800000 : "kernel"
0x000000800000-0x00000be00000 : "rootfs"
0x000000180000-0x000000380000 : "logo"
0x000000380000-0x000000400000 : "eeprom"
0x000008000000-0x000008100000 : "config"
0x00000be00000-0x00000fe00000 : "user"
0x000000000000-0x000010000000 : "ALL"
0x00000fe00000-0x000010000000 : "config1"
stm-nand-flex: Found BOOT parition[boot], updating ECC paramters
boot-ECC 0x00000000->0x00100000
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: attached mtd2 to ubi0
UBI: MTD device name: "rootfs"
UBI: MTD device size: 182 MiB
UBI: number of good PEBs: 1456
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 1456
UBI: number of PEBs reserved for bad PEB handling: 14
UBI: max/mean erase counter: 1/0
UBI: image sequence number: 184918554
UBI: background thread "ubi_bgt0d" started, PID 403
ICPlus IP1001: Registered new driver (0x02430d90)
ICPlus IP101A: Registered new driver (0x02430c54)
ICPlus IP175C: Registered new driver (0x02430d80)
stmmac - user ID: 0x10, Synopsys ID: 0x36
DMA HW capability register supported
Enhanced/Alternate descriptors
RX Checksum Offload Engine supported
TX Checksum insertion supported
Wake-Up On Lan supported
mdio_bus 0:00: IC+101G: disable EEE advertise
STMMAC MII Bus: probed
eth0: PHY ID 02430c54 at 0 IRQ 201 (0:00) active
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
stm_usb_probe: usb_phy_clk clock not found for stm-usb.0
stm-ehci stm-ehci.0: STMicroelectronics EHCI Host Controller
stm-ehci stm-ehci.0: new USB bus registered, assigned bus number 1
stm-ehci stm-ehci.0: irq 235, io mem 0xfe0ffe00
stm-ehci stm-ehci.0: USB 0.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
stm-ohci stm-ohci.0: STMicroelectronics OHCI Host Controller
stm-ohci stm-ohci.0: new USB bus registered, assigned bus number 2
stm-ohci stm-ohci.0: irq 238, io mem 0xfe0ffc00
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-9: WDC WD10JPVX-22JC3T0, 01.01A01, max UDMA/133
ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA WDC WD10JPVX-22J 01.0 PQ: 0 ANSI: 5 -> my EPP8000 has indeed a WD hard drive built in...
sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
sd 0:0:0:0: [sda] 4096-byte physical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda:
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
stm_usb_probe: usb_phy_clk clock not found for stm-usb.1
stm-ehci stm-ehci.1: STMicroelectronics EHCI Host Controller
stm-ehci stm-ehci.1: new USB bus registered, assigned bus number 3
stm-ehci stm-ehci.1: irq 236, io mem 0xfe1ffe00
sda1
sd 0:0:0:0: [sda] Attached SCSI disk
stm-ehci stm-ehci.1: USB 0.0 started, EHCI 1.00
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 1 port detected
stm-ohci stm-ohci.1: STMicroelectronics OHCI Host Controller
stm-ohci stm-ohci.1: new USB bus registered, assigned bus number 4
stm-ohci stm-ohci.1: irq 239, io mem 0xfe1ffc00
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
Linux video capture interface: v2.00
sh_tmu: TMU0 kept as earlytimer
sh_tmu: TMU1 kept as earlytimer
[STM][PM-Sys]: emi @ 40
[STM][PM-Sys]: gpio @ 20
[STM][PM-Sys]: sysconf @ 10
[STM][PM-Sys]: clk @ 30
stm-lpm stm-lpm.0: firmware: using built-in firmware lpm_fwSTxH205.elf
LPM: Found sbc f/w
STM_LPM driver registered
Memory region request failed for stm-sysconf.4! -> only remaining kernel startup error (memory allocation problem)
stm-sysconf: probe of stm-sysconf.4 failed with error -16
DMA: Registering fdma_dmac.0 handler (16 channels).
IRQ 203/fdma_dmac.0: IRQF_DISABLED is not guaranteed on shared IRQs
stm-fdma stm-fdma.0: firmware: requesting fdma_STxH205_0.elf
DMA: Registering fdma_dmac.1 handler (16 channels).
IRQ 205/fdma_dmac.1: IRQF_DISABLED is not guaranteed on shared IRQs
stm-fdma stm-fdma.1: firmware: requesting fdma_STxH205_1.elf
stm-rng hardware driver 1.0 configured
stm-rtc stm-rtc: rtc core: registered stm-rtc as rtc0
Advanced Linux Sound Architecture Driver Version 1.0.21.
sound/stm/stx7200.c:215: Not supported (other than STx7200) SOC detected!
ALSA device list:
No soundcards found. -> No solution for sound driver yet
TCP cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
stm-rtc stm-rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
UBIFS: recovery needed
stm lpm: configuring gpio_power: GPIO[3][7]
stm-rtc-sbc stm-rtc-sbc.0: rtc core: registered stm-rtc-sbc as rtc1
usb 3-1: new high speed USB device using stm-ehci and address 2
UBIFS: recovery completed
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: file system size: 184117248 bytes (179802 KiB, 175 MiB, 1427 LEBs)
UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: zlib
UBIFS: reserved for root: 0 bytes (0 KiB)
VFS: Mounted root (ubifs filesystem) on device 0:12.
Freeing unused kernel memory: 128k freed
INIT: version 2.88 booting
usb 3-1: configuration #1 chosen from 1 choice
hub 3-1:1.0: USB hub found
hub 3-1:1.0: 3 ports detected
[rcS] Start

I sure hope you like the looks of this.

More to come (drivers and rcS for example)...

Regards,

Audioniek.

solala
13.02.2015, 17:53
hi audioniek,
i use this one to display iboot logo, but i merged it to i-boot binary. maybe its worth a try to cat it to mtd3 so we would know if fortis uses the same coding
9369

Audioniek
14.02.2015, 18:21
Hello solala,

Thank you for your input, and you were spot on. File size and header info are exactly the same as the pictures used by Fortis. If I rename the unpacked .gam picture to duckbox.Booting.gam and gzip it, then add the .gz as user data (partition type 9) to the fup arguments, flash the .ird, then the Linux and Atemio logos (plus the text Titanit) are shown on power on. Can you enlighten me on how to create my own .gam pictures?

Meanwhile I have added support for the bootpicture to the flash environment: if X/cdk/root/bootscreen/bootscreen.gz is found, that file is used as the bootpicture file.

Regards,

Audioniek.

zozman
03.04.2015, 00:13
what's new

Kodov
06.04.2015, 20:50
Hello.
I have Xcruiser XDSR 420 Avant receiver.
I want to change channels via Up and Down buttons (they are on the top and bottom of the OK button). I mean that I want these buttons to do CH+/CH- functions.
But when I press Up or Down there is channel menu on the screen.
How to change that, because it is very uncomfortable?

Audioniek
06.04.2015, 22:12
@zozman

At the moment I am, very busy solving problems on Spark7162, as many HDMU users are affected by them. So that takes precedence at the moment.

@Kodov
Assuming your are talking about the original Xcruiser firmware: all Fortis firmwares have this behaviour by design, and it cannot be changed as these firmwares are closed source. And why do you want to have functions on these keys that have their own keys quite nearby on the remote?

Regards,

Audioniek.

Kodov
07.04.2015, 17:03
@Kodov
Assuming your are talking about the original Xcruiser firmware: all Fortis firmwares have this behaviour by design, and it cannot be changed as these firmwares are closed source. And why do you want to have functions on these keys that have their own keys quite nearby on the remote?

Regards,

Audioniek.

I want to change this because I use to have functions on these keys.
But I solved the problem. You can use plugin SX key_redefine to change the keys.
Best regards, Kodov.

harryhase
08.04.2015, 21:56
can you please send a link for this plugin?

souhai
13.04.2015, 10:25
@ harryhase (http://www.hdmedia-universe.com/board/member.php?u=5660)
http://www.gulfup.com/?2tUQuQ

souhai
12.05.2015, 17:06
@ Audioniek
Any news?

Audioniek
12.05.2015, 18:27
Not at the moment. I have been busy with the Spark7162 display problems and kernel patch level 217. My work on the latter has been taken over in the Duckbox Developers git and HDMU now builds with it.

I hope to be able to do something about the 4G Fortis stuff beginning of next week. I think I have found the cure for the last remaining kernel startup error message but have yet to test it.

There is some bad news though. In the mean time I have discovered that the tuners do not contain the STV093 chips but the newer STV6111. This means a new tuner driver, which I have not been able to find yet.

As soon I have something to report, you will find it here.

Regards,

Audioniek.

harryhase
13.05.2015, 21:55
i don't understand what you' rr exactly looking for, did you looked here: click (https://github.com/flensrocker/dddvb/tree/master/frontends) ?

Audioniek
19.05.2015, 17:09
I found that one, but it is not the "official" STM driver. Currently I am trying to incorporate that driver.

Regards,

Audioniek.

eng_hti
20.05.2015, 13:51
Waiting for Enigma 2 on Drake 7500 HD V3 , What is the expected date to release it ?

salahmoursy
12.06.2015, 12:49
Hello, What's new

e4b22
12.06.2015, 23:45
hello..
there is a new boot loader on the latest production of ep8000 devices....any comment on that??what are the changes and why its done??? l8.37 to l2.00

TopSat UltraVip
20.06.2015, 19:21
enigma2 sur forever 9898

harryhase
20.06.2015, 22:42
enigma2 sur forever 9898


do you have a link for download?

souhai
21.06.2015, 12:05
@harryhase



http://www.foreverhd.com/update/

harryhase
21.06.2015, 12:51
Can't find engima 2 there ... only updates / bootloaders etc.

I'm waiting for enigma on cardiff ...

Schischu
27.06.2015, 22:07
Wie soll enigma2 darauf laufen? Havana unterstützt die Chips definitiv nicht.
Bei SDK2 war es vor einem Jahr mal angedacht auch diese Chips zu unterstützen, weis aber nicht ob sie das mittlerweile getan haben.
Nachdem die Entwicklung nach Frankreich verlagert worden ist glaube ich mal nicht daran.

Mein Kentnisstand:
h2xx -> SDK1=STAPI.
h3xx und h4xx -> SDK2=Havana

zozman
16.07.2015, 21:22
what's new

altayeb
21.07.2015, 14:43
what's new

TopSat UltraVip
22.07.2015, 15:57
engima 2:ba3:

Schischu
22.07.2015, 20:15
Hab mir dort mal ein Image runtergeladen und extrahiert.
Nix enigma2. Außerdem STAPI.

Falls es jemand überprüfen will, ird mit fup entpacken und mtd1 mit ubi_reader extrahieren.


@harryhase



http://www.foreverhd.com/update/

eng_hti
23.07.2015, 09:42
We are waiting Enigma 2 for Drake 7500 HD V3 >>>> When it will be available ???

zozman
24.07.2015, 22:35
There is no hope

These devices great trick

Audioniek
26.07.2015, 20:29
@Schischu

This is very important information, and exactly the kind I hoped to elicit when I started this thread. It also means that my approach so far (copying the existing environment and then adapting it to the particulars of these receivers) will not work as support and drivers at the basic level do not exist (yet) in some cases, at least they are not provided by STM. Developing them myself is beyond my means and knowledge.

In essence, in order to port E2 tot these receivers more inside information is needed. Hopefully somebody can provide this.

For the time being I will put this project to rest. Everybody is of course free to use the git, I will leave it available, but it will be static in at least the near future.

Regards,

Audioniek.
Regards

salahmoursy
27.07.2015, 14:30
it's bad news

altayeb
27.07.2015, 16:15
HI.

Do you need a change on Software for it to run with you.

What are the things that you want to be an example of the change ............


Thank you

konfetti
27.07.2015, 19:49
Ich fasse die Informationen und daraus resultierenden Probleme noch mal zusammen. Havana ist derzeit die Basis für die e2 Anbindung für die sh4 Receiver. Diese Implementierung von STM endet mit den STi7108 Prozessoren. Danach wurde für die STxH2XX Prozessoren nur noch die STAPI weiter implementiert, auf jedenfall ist das unser Kenntnisstand. Für die STiH3/4XX Prozessoren (ST meets ARM) gibt es das sogenannte SDK2, es gibt aber derzeit keinen mir bekannten Receiver mit dieser Architektur.

Aus diesen Informationen ergeben sich folgende Probleme (nicht vollständig!):

- keine Audio/Video Firmware vorhanden
->ggf. könnte man Havana noch beibringen mit den STAPI - FW's zusammenzuarbeiten, aber das ist nur Theorie
- stmfb für STxH205 fehlt
->ggf. eines der größten Treiber-Probleme
- STXH205 setzt sofern ich weiß auf pti5 und nicht pti4 auf, somit müßte ein neue PTI Treiber her

Vermutlich wird noch einiges mehr fehlen bzw. anders sein, hierzu müßte man aber tiefer einsteigen.

Wenn man das alles gelöst hätte, könnte man sich an die receiverspezifischen Anpassungen machen:

- Tuner-/Demodtreiber
- LNB
- Frontcontroller
- AVS
- ...

lg
konfetti

Audioniek
28.07.2015, 17:30
Thank you konfetti for this very comprehensive summary, which basically matches my own analysis.

Regards,

Audioniek.

eng_hti
20.08.2015, 13:52
Audioniek (http://www.hdmedia-universe.com/board/member.php?1349-Audioniek)

Any new news about Drake 7500 HD V3 Enigma 2 ?

Thanks,
Ahmed Turk

zozman
24.08.2015, 22:36
no hope

Audioniek
25.08.2015, 16:25
Regarding the two last posts, the current situation is that the required support by the SoC manufacturer STM is missing at the moment regarding a few things that are needed for Enigma2. I do not have the capability to solve this, and apparently people with a great deal more knowledge than I have feel the same.

Therefore I have laid the project to rest. The git will be there or all to use/study but will be static, until new developments by STM occur. This however may never happen.

Regards,

Audioniek.

zozman
12.12.2015, 16:49
what's new

Audioniek
30.01.2016, 10:55
The news here (http://www.hdmedia-universe.com/board/showthread.php?9734-ST-stellt-die-Entwicklung-neuer-Chip-Plattformen-f%FCr-Receiver-ein&p=110098#post110098) means probably that we will never have the ST stuff needed to port Enigma2 to these receivers; therefore the project is now officially closed as far as I am concerned. It was fun to do and I learned a tremendous lot.

Regards,

Audioniek.

turulbird
25.08.2016, 19:05
Hi!

Can this be done in usb Enigma2?

http://www.citycom.tv/en/products/digital-receivers/dvb-s2-hdtv/ccr-550-hd.html



touch .deps/diverse-tools
touch .deps/bare-os
make: *** No rule to make target `/home/turulbird/Start_Fortis-4G-master/cdk/Patches/build-enigma2/linux-sh4-2.6.32.61_0217_dp6010.config', needed by `.deps/linux-kernel'. Stop.

Audioniek
25.08.2016, 23:28
No. Read post #46 and preferably this whole thread. Also read README.md in home/turulbird/Start_Fortis-4G-master.

Regards,

Audioniek.

turulbird
25.08.2016, 23:36
I read. Just came across a weekend I bought in flea, it was only €2.
That was a pretty fast machine and it is the lan.
The serial port is no rear, only somewhere in motherboard.

Pity, said the crows...

chaban
12.03.2018, 12:16
Hello
Any news about enigma 2 for fortis 4th generation ??? pls. !!!!

Audioniek
13.03.2018, 13:31
As can be read some posts back, the project has been laid to rest. To be able to run E2 or Neutrino on these receivers drivers a framebuffer-based solution is needed, and chipset manufacturer STM has not developed it. In addition, STM has stopped all activity regarding SH4 for settop boxes some time ago, so these essential software components will probably never appear. As an alternative, the community could attempt to write these ourselves, but that would involve detailed chipset knowledge (info is still confidential) and the effort compared to the actual use of the unsure result would be humongous.

For these receivers, stick to the (meanwhile excellent and very stable) factory firmware.

Regards,

Audioniek.

chaban
13.03.2018, 15:54
Thank you my brother. goog like !