Posts by chewitt

If you want to pirate movies you're in the wrong forum.

No schedule as it's all community "best-efforts" work. I'd guesstimate months not weeks. How long is a piece of string?

Quote from buzzmarshall

on another note... just what exact linux revision are they trying to unify to as I am thinking about spending a bit of time going back and revisiting the kernel issue. years ago a couple of us move the old meson8m up to a custom 3.14 kernel which works good but now with the newer stuff i am assuming were talking about unitfing up in the 4.xx range ?

Meson8* has reasonable support as large amounts of the platform are similar to GXBB, but the HDMI chip is different and there is no driver for that at the moment. One of the Amlogic maintainers (Martin Blumenstingl) has the intent (if not much time) to write one that hooks into the DRM/KMS code for Meson GX, but until that work bears fruit there's not much to be done. That said, if you're keen on those devices it wouldn't hurt to get them booting and send the device trees upstream. Current efforts are tracking Linux 4.20+ kernels.

Bootleg DDK access isn't the solution. We have sources with DDK access but if we ever released blobs we'd be violating ARM license/redistribution agreements and it would massively compromise our ability to engage with ARM people in other areas. Staff in their open-source group are tracking lima/panfrost and have asked for internal permission to contribute. Both projects will be fine whether it comes or not, but having ARM people with inside knowledge on the many errata in their chips would be a big bonus. Lima is very solid for Kodi use now (at least via GBM/V4L2).

Meson8/8b/8m2 hardware currently has quite good core platform support and an active kernel maintainer. The one critical component missing is the HDMI driver (Meson8 does not use the same DesignWare IP in newer GX devices). Martin has some early stage driver code but it's not functional at the moment (screens are still dark). Until his effort bears fruit there's not much point looking into making LE images, but (famous last words) it should be simple to create something once there's a eureka moment.

S912 has a bright future. See YouTube for evidence. Panfrost still has some serious bugs to solve before we can think about public testing, but considering the infancy of panfrost code it's in good shape. The lead panfrost developers have publicly stated good Kodi support is one of their goals

Ahh.. after Googling I see mention of "Dreambox One" being an 8x Core device so it has to be S912 or S922. If you are lucky the uboot bootloader is not locked and it can run LE

Interesting. Anyone launching a new TV box product with Amlogic chips today has two choices:

a) Use the current Amlogic BSP kernel .. Linux 4.9 supporting S905D/S912 and S905D2/S922 chips (S922 isn't really shipping yet).

b) Android .. based on the same Linux 4.9 codebase

c) Use the mainline kernel (4.19+)

The 4.9 vendor codebase is fully functional but based on lots of proprietary frameworks that originated in the 3.10/3.14 era and have been maintained and added to as time went forwards. It works but since half the frameworks originate before 4K, HDR, etc. existed it's not brilliantly architected and the code is not pretty in lots of places.

In comparison the mainline kernel codebase is architected around modern public frameworks and has more efficient and better written code, e.g. the mainline video decoder is about 10% the size of Amlogic's (measured in lines of code). However it's more of a community driven effort and it would be missing capabilities essential for a dreambox device.

Can you point me to sourced for the rumours?

In any case, a Meson6 box is stuck on Linux 3.10 which is prehistoric even by Amlogic standards. Get a cheap S905D box with GB Ethernet and you have a good tool for Amlogic learning

I assume you mean connecting an LE/Kodi client to the NAS (and not the reverse). Synology NAS work fine (we have 2x of them at home) and the only thing that's required is an authenticated connection to the NAS box. So create a "kodi" user and password, and give that user rights to shares. Now use that credential on the Kodi side - so a source will look like:

    <music>
      <source>
        <name>MUSIC</name>
        <path>smb://username:password@DISKSTATION/MUSIC/</path>
        <allowsharing>true</allowsharing>
      </source>
    </music>

^ or similar.. your NAS and share names will be different.

milhouse ^ can we revert the removal or re-add that firmware

Commercial entities posting in our forums are asked (under forum rules) to declare themselves so other users (and forum staff) are aware they are not normal users. So I must ask .. what company is the "we" you are representing?

Current 9.0 releases will ship on ye olde Amlogic 3.14 kernel. At some point between 9.0 and 10.0 we will switch to mainline. Depending on your needs or expectations the current state of things is either awesome or missing major/essential capabilities (grab a balbes150's test images if you like). IMHO there are still some key milestones to achieve before we encourage wider public testing.

If someone wants to PR a working Rockchip 4.4 device tree to Kwiboo on GitHub i'm sure he will merge the PR and we can add it to the current "Alpha" build roster. I wouldn't expect to see mainline images for some time yet.

Playing video doesn't generate much load (as it's hardware decoded) so I would assume it's fine. That's not a promise though

LE plans to drop support for the 3.10 kernel after LE 9.0 ships so even if your efforts succeed the code lifespan will be limited. It would be better to invest in a USB tuner that "just works" today and can be reused on a future replacement device (that should be running a mainline kernel).

Client and server functions will come from different binaries that potentially use different configs depending on how the binaries were compiled. It's unusual, but also not without precedent.

If you can tell us which chip is in the box .. we can advise how it might be supported (or not). Otherwise it's a blind guess. That probably requires you to open up the box.

The odd thing is that the 97-xorg.rules udev file should select the Intel GPU if present, as it evaluates in this order:

LibreELEC.tv/97-xorg.rules at master · LibreELEC/LibreELEC.tv · GitHub

Perhaps blacklist the AMD kernel driver and put a modified version of 97-xorg.rules in /storage/.config/udev.rules.d/ that removes the AMD criteria. In that scenario it cannot then choose the AMD card even if present.