Posts by chewitt

Can you see if audio works correctly if you set Kodi to "fixed" 44.1Khz output? - I need to do this on WP2 and have a theory there's a difference between S905 and newer S905X/S912 devices that's not handled in the audio driver.

If I have time over the weekend I'll create a proper device-tree for the U1, it also has an RTC chip onborad which should be simple to add. The photo of the board I found MINIX_NEO_U1_Board_Large.jpg shows 3x LEDs but the legacy kernel dtb device-trees-amlogic/gxbb_p200_2G_minix_neo_u1.dts at master · LibreELEC/device-trees-amlogic · GitHub mentions "minix_mcu" so these might not be controllable without a custom MCU driver (which doesn't exist and isn't likely to be written).

The Beelink G12B devices I have all experience some kind of kernel lockup when using vendor u-boot, with or without chainload of any recent newer u-boot as second stage; although in that case LE boots and generally runs fine until you attempt any large file transfer and then it locks up. Nobody has been able to put their finger on the issue. Beelink shared their u-boot sources so I could see the git history of their changes, but nothing stood out as unusual. Using their sources I extracted the signing FIPs and built mainline u-boot which works without any issues, so this suggests there's an issue in Amlogic u-boot code. G12A/B devices also have confirmed silicon bugs with mmc (there are workarounds in upstream kernel code). So it's hard to comment, but I generally don't trust vendor u-boot + chainload on G12A/B devices.

If you have Amlogic burning tool and an Android ROM (to restore the box with) you could zero/erase emmc to remove vendor u-boot and see if any of the mainline u-boot images I have in my test folder will boot the box from SD card. Otherwise I don't really have ideas.

Quote from milo

Is the boblight plugin ported to libreelec10.1?

It exists, but whether it works is an entirely different question.

[ 2.298762] Run /init as init process

^ the boot log stops here because of the console ordering you've defined in boot params (the order matters):

systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0 <= correct ordering

console=ttyAML0,115200n8 console=tty0 no_console_suspend systemd.debug_shell=ttyAML0 <= yours

I also use boot=LABEL=LIBREELEC, disk=LABEL=STORAGE instead of UUIDs, so see if that makes a difference?

Quote from seias

Can some1 help me distinguish which .DTB is for minix neo ui ?

NEO U1 is a GXBB (S905) device and looking at MINIX_NEO_U1_Board_Large.jpg it has Broadcom WiFi/BT and the standard RTL GB Ethernet, so the WeTek Play2 dtb is a close match and a good starting point for creating a proper device-tree. Please boot from LibreELEC-AMLGX.arm-9.95.1-box.img.gz with WP2 dtb set in uEnv.ini and assuming Ethernet worked, run "dmesg | paste" and share the URL generated. You'll need a USB keyboard attached as the predefined IR keymap will be wrong .. but we can fix that easily.

In theory we could switch to the same 64/32 arrangement we run on other ARM SoCs, but since the current 'arm' kernel still allows access to 4/8GB RAM on larger RPi4 models (not that LE needs it) and the Pi Foundation development focus remains on arm (which is highly optimised) there's no rush/need - although I expect it will happen at some point.

The fp-dev component sounds like an MCU so it's probably attached via i2c, but is also probably a custom part so you would need infos or sources from the manufacturer (or proper reverse-engineering skills) to figure it out.

Do you have any high-resolution PCB photos? - is there an RTC chip and power cell attached? - I would expect yes (to support timed wake and record) but there is no mention of this in the vendor kernel device-tree or sources.

Updated LibreELEC-AMLGX.arm-9.95.1-box.img.gz image has RC keymaps added and I removed button things as those are likely wrong too. I moved the LED to GPIOAO_3, but this is just a random guess.

Bump v4.9.113-641429-g1883b89 · emanuel4you/linux-meson64@7f99a65 · GitHub

^ this is probably why the LED doesn't work - and you can see 11/4 are in use for other things. In the absence of schematics the best thing to do is boot an original dreambox kernel and see what is set there. It might be a PWM config rather than GPIO, or a different GPIO_AO?

_emanuel_ Updated LibreELEC-AMLGX.arm-9.95.1-box.img.gz image has two device-tree files for dreambox one/two that I created earlier. Please test whether the LED/button bits work. There are no RC keymaps in the image - I can see the BSP kernel keymaps, but there are 4x maps. If you can explain which keymap is used in which box I will add them.

See last four commits here: Commits · chewitt/linux · GitHub

I moved the posts. Please share a URL to a GitHub repo with the dtb or patches (or share the patches) and I will see what changes might be needed for the LEDs and buttons. It should be simple to add.

It is technically possible but a bad idea since LE is not designed for exposing internet-facing services - both from a security and sharing protocols perspective. Don't be a shodan.io statistic!

_emanuel_ Have a play with this image LibreELEC-AMLGX.arm-9.95.1-box.img.gz .. I've no real idea what is in Oleg's images these days but I know the content of my own ones. The boot files are slightly different.. set the dtb name in uEnv.ini and leave the u-boot.ext file out for now; colours will be messed up but best to keep things simple at first.

Please test Dropbox - LibreELEC.USB-SD.Creator.macOS.dmg - Simplify your life which has changes to work on macOS Catalina, and in theory the app is signed (though not with an Apple-trusted cert). There are still issues with downloading some image types so stick with standard stuff like Generic/RPi4 .. and use 'show all' to list beta images.

_emanuel_ panfrost is used for accelerated GUI rendering and has nothing to do with hardware video decoding. The vdec drivers (which do) are still early work in progress (with not much work in progress). I looked at the vendor keernel dreamone/two dtb files and apart from IR keymaps, LED and button things, there's not much to improve upon with a dedicated dtb - you can build off the W400 dtsi the same as the existing Ugoos AM6 and various Beelink G12B devices (GT King would be a good match). The mainline kernel also takes RAM size from u-boot so this does not need to be set. What do you think is missing?

Legitimate streaming sites don't run their web marketing presence in the default Wordpress theme or need you to subscribe to their VPN service to watch their channels. Thread closed. Your problem is not our problem.

Quote from the_mouse

Am I right in thinking that the switch to GBM is switching to wayland or will kodi be acting as its own display server? Otherwise with chrome supporting wayland would that not work?

No, Kodi will render directly to the framebuffer with no windowing system. It's effectively the same arrangement we use with ARM devices. The lack of window system is the blocker. We could also run Kodi under Wayland, but then you have no "adjust refresh" support and there'd be an angry mob of pitch-fork waving villagers complaining about that

From Petitboot, "Exit to Shell" and run:

# flash_eraseall /dev/mtd0
# flash_eraseall /dev/mtd1
# flash_eraseall /dev/mtd2
# flash_eraseall /dev/mtd3

This exorcises petitboot from the SPI flash, and distro images that use modern u-boot with extlinux.conf (LE, Armbian, etc.) will now boot from SD card. I've asked HK when they plan to support extlinux.conf boot in petitboot and got a meh response. Restoring Petitboot (if you want to do that) is achieved by creating an SD card with the petitboot update file on it and booting the board. There are instructions for that in the HK wiki.