Posts by chewitt

    The right firmware should already be in the image so you can delete that file.

    On eMMC: Amlogic invented their own partition scheme which is only used and understood by their own legacy kernels and tools so upstream Linux and utils used for partitioning and formatting in modern LE cannot can see any valid partitions on the eMMC device. Any attempt to repartition the device with tools that don't know about the special scheme will break the device-specific u-boot that is booting the box.

    If you have the original vendor u-boot sources for the specific box it's possible to extract things and make custom images, but these days nobody still has the sources for boxes made in 2015 so that option is almost always a non-starter. The technical challenge is that the process of signing u-boot with Amlogic magic uses files with box/device specific RAM timings so generic support for e.g. p200/p201 doesn't exist. We have the signing sources for the original p201 reference board; but there is zero guarantee your p201 derived box uses the exact same RAM chips as the Amlogic reference board (more likely you can guarantee it doesn't) and if the RAM timings are wrong you've "bricked" the box and now have a complicated process to recover it to a usable state (most users baulk at the idea of opening the box and shorting pins to disable eMMC and thus force boot from SD/USB) and that also assumes you have a working u-boot binary (and you probably don't).

    So we don't support internal installs unless the sources do exist, i.e. the WeTek boxes and a couple of SBC boards. NB: From my own testing the real-world difference between a modern SD card and most eMMC chips in boxes of this era is marginal.

    Code
    Jan 01 00:00:10 pain kernel: usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
    Jan 01 00:00:10 pain kernel: usbcore: registered new interface driver ath9k_htc
    Jan 01 00:00:11 pain kernel: usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
    Jan 01 00:00:12 pain kernel: usb 1-1: Service connection timeout for: 257
    Jan 01 00:00:12 pain kernel: ath9k_htc 1-1:1.0: ath9k_htc: Unable to initialize HTC services
    Jan 01 00:00:12 pain kernel: ath9k_htc: Failed to initialize the device
    Jan 01 00:00:12 pain kernel: usb 1-1: ath9k_htc: USB layer deinitialized

    ^ The kernel supports the driver and we already include the correct firmware (listed in the driver code) so the device is probed, but fails to load the firmware. I've Googled the error and it doesn't show up much (no clues, and nothing current).

    I'd suggest experimenting with other device trees. GXBB boxes deviate more from reference designs than newer S905X/D and S912 do.

    RPi4 is excelently supported, but DVB is an icky topic regardless of hardware. The general recommendation is to separate tuners from the playback device so you can run whatever OS and hacked version of drivers and firmware that works reliably .. with playback on something simple that you can OS bump whenever LE puts out a new release. The moment you put both functions on the same device you can have a reliable player or DVB that works; they are generally mutually exclusive and you have to chose one.

    That means you could revert to a legacy image, e.g. CE or dtech's LE 9.2.8 one for the TVH side. RPi4 is a nice playback device if you can get your hands on one.

    There is no hardware deinterlace in any codec, forcing software deinterlace which is limited (else you hit the CPU limits). I've disabled support for MPEG2/MPEG4 hardware decoding in the latest images (as the hardware decoder is broken) which is why those 'work' now. However, ff those codecs and interlacing are important for your media; you aren't in the narrow band of users who should be using the AMLGX image. I have low expectations on progress because it's basically me solo supporting Amlogic these days, and I don't write driver code.

    Code
    touch /storage/.cache/services/sshd.conf
    systemctl start sshd
    connmanctl
    agent on
    services
    connect <service_string>
    (enter pw when prompted)

    Running ^ that sequence of commands form the textmode console should enable SSH, start it, then connect you to a WiFi network instead of Ethernet, although from logs it appears SSH is running (as it was forced) and the Ethernet NIC is up/active and assigned 192.2168.1.76. Make sure that you're using a current version of PuTTY as support for ciphers does change over time.

    Then, to have more info on why Kodi isn't working, create /storage/.kodi/userdata/advancedsettings.xml with the following content (to put Kodi into debug mode) then reboot and run "pastekodi" and share the URL:

    XML
    <?xml version="1.0" encoding="utf-8" ?>
    <advancedsettings version="1.0">
      <!-- enable debug logging -->
      <loglevel hide="false">1</loglevel>
    </advancedsettings>

    Then maybe we get some insights on the problem..

    If you add "textmode" to boot params in uEnv.ini the box boots to a text console instead of Kodi and you can attach/use a USB keyboard to run commands. To retrieve the logs, make the SD card read-write with "mount -o remount,fw /flash" and then dump the boot log content to /flash with "journalctl > /flash/journal.log" .. then connect the SD back to something you can retrieve and pastebin the log file from.

    AFAIK all the atheros USB chips are enabled in the kernel but we are probably missing the firmware, which should be obvious if you look in dmesg for the chip being probed. This might get it working: "mkdir -p /storage/.config/firmware && cd /storage/.config/firmware && wget https://git.kernel.org/pub/scm/linux/…plain/ar9271.fw && reboot"

    There is no driver code in-common between the Legacy image and AMLGX image so there is no value in making comparisons. It's like pointing at a Nissan car and a Ford car and saying .. "they're different" .. because they are.

    I'll add the investigation to my list, but these days Amlogic support is largely a one-man team (and I don't write driver code) so these things take time.

    The "reboot update" triggers recovery boot mode causing the SoC to search for boot scripts in the first partition on the SD card. The LE boot scripts are then found, which sets params in the vendor u-boot environment to use LE boot files and if you reach Kodi then everything has worked. To revert to CE you will need to trigger recovery boot mode again. In most cases that's done with the toothpick method, which (with SD card removed) will find their boot scripts and set boot params to use CE boot files. On most boxes (but it depends on what customisation was done in vendor u-boot) both OS are tweaking the same boot params to suit themselves which prevents a simple swap between OS(es) by removing the SD card.

    The ethmactool-config service creates a unique MAC address based on the CPU serial to avoid issues where vendor code sets the same MAC for all boxes (and users have more than one of the same box causing conflicts) or where the MAC was not set in the factory and changes on each boot. As long as you have a static MAC address "systemctl mask ethmactool-config" will disable the service on future boots and stop the message from showing up.

    Not sure about the blue tint, but as long as it doesn't happen on the TV it's not something I'll be interested in chasing. Vendor u-boot does a few weird things.

    NB: If the S805 image is AMLMX .. it is pre-Alpha state and is not even remotely supported.