Posts by chewitt

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.

Sorry.. no clue about config changes needed for the card, I only know where to put the file.

Quote from pletopia

chewitt .. quick question, i saw this on the LE blog "We are pretty confident RPi4 users will like the update since it brings HBR audio and initial HDR video support" .. what exactly does initial support mean?

So has anyone done "proper" passthru audio testing of the build in 502? Like does it finally fix the split second audio drop that occurs every few mintues?

Initial support means: it is the first time someone coded HBR audio for the latest RPi4 codebase (Linux 5.10+) .. not that anyone is planning to rewrite it but as with all first implementations there are likely some corner cases and issues to find. There have already been some fixes and bits which are tested and then pushed upstream. So no idea what you mean with the pithy "proper" comment. The work is being done by a group of people who care deeply about getting it right and there's been a substantial amount of testbench and people testing so it's not some "hey mum, look we make sound" half-arsed exercise. I've no idea what "the build in 502" refers to. You can look at GitHub commits if you want to track the status of development.