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
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
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
Compared to the previous loader family L7.xx the following can be noted:Code: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
- 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.
Geändert von Audioniek (14.02.2015 um 17:29 Uhr) Grund: Essential typo corrected, info updated and corrected
Receivers: Rebox: RE-4000, 8000, 9000, 2200, 2210, 2220, 4200, 4210, 4220, 8220, 8500, SAB Unix Triple, Golden Media Spark TripleX, Amiko Alien 2+, Sogno Spark Revolution, Kathrein UFS910(1 & 14W)/912/913/922(CX24116 & AVL2108 tuners), Vizyon revolution 820HD PVR, AB IPBox 91HD/9000HD/9000HD rev.2, Xsarius Alpha HD10, nBox BKSA/BSLA/BXZB/BZZB, Vitamin HD 5000
Sats: Astra 1, 2 & 3, Hotbird
Main activity: building my own E2 images for Fortis receivers
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
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.Code:fakeroot flash.sh
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.
More to follow...
Regards,
Audioniek.
PS. Please note that the duckbox/developers/flash git still has the old flash environment.
Geändert von Audioniek (14.02.2015 um 17:31 Uhr)
Receivers: Rebox: RE-4000, 8000, 9000, 2200, 2210, 2220, 4200, 4210, 4220, 8220, 8500, SAB Unix Triple, Golden Media Spark TripleX, Amiko Alien 2+, Sogno Spark Revolution, Kathrein UFS910(1 & 14W)/912/913/922(CX24116 & AVL2108 tuners), Vizyon revolution 820HD PVR, AB IPBox 91HD/9000HD/9000HD rev.2, Xsarius Alpha HD10, nBox BKSA/BSLA/BXZB/BZZB, Vitamin HD 5000
Sats: Astra 1, 2 & 3, Hotbird
Main activity: building my own E2 images for Fortis receivers
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.
Receivers: Rebox: RE-4000, 8000, 9000, 2200, 2210, 2220, 4200, 4210, 4220, 8220, 8500, SAB Unix Triple, Golden Media Spark TripleX, Amiko Alien 2+, Sogno Spark Revolution, Kathrein UFS910(1 & 14W)/912/913/922(CX24116 & AVL2108 tuners), Vizyon revolution 820HD PVR, AB IPBox 91HD/9000HD/9000HD rev.2, Xsarius Alpha HD10, nBox BKSA/BSLA/BXZB/BZZB, Vitamin HD 5000
Sats: Astra 1, 2 & 3, Hotbird
Main activity: building my own E2 images for Fortis receivers
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.
When built and flashed in an EPP8000, the console output of the kernel startup is currently this:
I sure hope you like the looks of this.Code: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
More to come (drivers and rcS for example)...
Regards,
Audioniek.
Geändert von Audioniek (16.02.2015 um 08:58 Uhr)
Receivers: Rebox: RE-4000, 8000, 9000, 2200, 2210, 2220, 4200, 4210, 4220, 8220, 8500, SAB Unix Triple, Golden Media Spark TripleX, Amiko Alien 2+, Sogno Spark Revolution, Kathrein UFS910(1 & 14W)/912/913/922(CX24116 & AVL2108 tuners), Vizyon revolution 820HD PVR, AB IPBox 91HD/9000HD/9000HD rev.2, Xsarius Alpha HD10, nBox BKSA/BSLA/BXZB/BZZB, Vitamin HD 5000
Sats: Astra 1, 2 & 3, Hotbird
Main activity: building my own E2 images for Fortis receivers