Posts by chewitt

Quote from frakkin64

Anyways, the point of this meandering is to share that toothpick method can kill eMMC installs depending on whether they use the instaboot partition in a similar way.

LE boot scripts don't touch partitions at all, but if the boot processes aml_autoscript then we're changing the boot flow stored in the u-boot environment to use our scripts, which will "break" legacy distro booting due to them using kernel.img not KERNEL and more. Some of these differences are intentional; partly to align with LE standard namings, but also because we (me) don't want users "updating" from all kinds of unknown legacy images to AMLGX and then showing up with tricky-to-solve support issues. Boot is already "fun" before you factor in large Kodi major version bumps and the Python2 to Python3 change which causes add-on carnage. Forcing clean installs is just a sensible move.

I'm unable to see/access the pic .. imgur.com is overloaded or something.

What happens if you add the file with the required content?

1. Most S905X boxes follow the reference boards quite closely and all use internal PHY ethernet so it's hard (but not impossible) to get a non-booting box, but that assumes you can trick the box into booting LE (some require non-standard boot tricks) and things can go wrong with cheap emmc/ram parts. You might not get WiFi/BT if non-Broadcom parts are being used.

2. Once you initiate recovery boot to load LE the u-boot environment is tweaked to use LE boot files (else it won't boot). If you remove the SD card (or USB) and force recovery boot again it should rediscover the AE install. You can't swap between distros solely by removing the SD card.

3. AE contains embedded tools whose primary/sole purpose is the consumption of pirated content. That's the main objection. AE's creator also leeches 99% of their distro from others without preserving attribution and licensing (so it appears to be their meisterwerk, when in fact it's the work of others). In FOSS circles that's disrespectful, but kind of normal/expected in the pirate box space.

mount -o remount,rw /flash
nano /flash/syslinux.cfg
<save/exit>
reboot

You need to remount /flash in read-write mode before editing ^

Please share the output of "lsusb" (over SSH). Let's make sure the device can be seen on the USB bus, and what device IDs are present (which we can check against kernel driver sources).

I have fuzzy recall that it defaults to only allowing access from the local host, so clients elsewhere on the network will be blocked until that's changed to allow access from anywhere. I'm not 100% sure on that, but something to check.

It doesn't really matter whether it's the original Android kernel, or CE, or another LE release. As long as it clearly shows what make/model of WiFi chip is inside the box. The alternative is a clear picture of the board to see the SDIO module markings. The fact it doesn't probe Broadcom or QCA9377 drivers makes me think it's a Realtek chipset; so I'll warn in advance that if it requires vendor drivers that aren't in the upstream kernel I will have no interest in adding them to LE images.

There are hundreds of manufacturers of boxes branded "MXQ" so that's not going to enlighten us on WiFi specs. And lshw only shows the items that we described in device-tree so that doesn't help either. Things that would help are high-res pics of the board inside the box so we can see the chips being used, and the boot log (dmesg) from the original vendor kernel.

Anything that starts with "meson-gxbb" is a candidate. No value in trying others (won't work). As for WiFi, please share the Brand/Model of the box (hoping it's not something super-generic) and the URL from "pastekodi" so I can see what state things are in. If you have pics of the board inside it can help with chip guessing.

You don't need to execute the app as root, but Linux ultimately requires that privilege to reimage the target device so once you reach the point of writing the app must prompt for (sudo) rights. Users with a Linux desktop OS tend to be more technical in nature and thus less fazed with using dd or the need for root privs (which are unavoidable) and it's similar to a lesser extend with macOS. The goal of the tool has always been to simplify the process of acquiring and writing the latest version, and we'd prefer to make the current tool work than have different tools for different OS (consistency is good for users).

Unfortunately shared Qt builds are simple. Static is something else

BBR is not set in the 6.1 kernel either. To enable support and make an image for testing you will need to self-build an image.

See: https://wiki.libreelec.tv/development/build-basics

If you feel the distro defaults should be changed, you'll need to send a pull-request to our main GitHub repo with the required changes and a detailed explanation for why we need to change things. We're not adverse to changing defaults when there's a good reason, but you will need to impart and if necessary educate people on use-cases for/against and why the change is a good reason.

echo "options i915 enable_fbc=1 enable_guc=3" > /storage/.config/modprobe.d/i915.conf
reboot

That ^ will create a modprobe conf file with that content and reboot the system. The contents of /storage/.config/modprobe.d/ are overlaid onto /etc/modprobe.d during system start.

SSH can run on multiple ports at the same time so the 'safe' way to experiment is to configure the additional port first (leaving 22 active) and then restart the service. If you can now connect on the new port, you can make an additional change to remove port 22.

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.

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.

Quote from Da Flex

Chances to boot are better with a legacy image.

There are big differences in the kernels and userspace of Generic and Generic-Legacy but in respects to initial boot code they're both exactly the same. If the kernel cannot see the target device to install-to; you'll hit the same issue in both images.

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.