Posts by chewitt

    I already tried to upstream first patch to [email protected] on Feb 3, but no answer. It was pinctrl for tsin pins.

    LibreELEC.tv/linux-99999-pinmux.patch at master · 150balbes/LibreELEC.tv · GitHub

    The kernel maintainers provided feedback on the patch submission so you need to submit v2 with the requested changes. For that patch I can see the following issues:

    a) Lines over 80-characters

    b) Subject line should be something like "pinctl: meson: add tsin pins for meson gxbb/gxl/gxm"

    c) No "Signed-of-by Jan Afl <[email protected]>" line

    One of the lessons everyone learns the hard way is there is zero negotiation on kernel code style .. and typo's count :)

    Run scripts/checkpatch.pl on patches to check for common style/format errors before resending. Run scripts/get_maintainer.pl on the the file being changed to get the list of email addresses to send the patch to.

    I recommend you reach out to Neil Armstrong and Kevin HiIlman to discuss how to submit the driver. I know Neil has looked at the current changes in your repo and there are some structural issues to resolve. It will be easier to know what the main objections are (and address them) before you send the next set of changes.

    p.s. If you need any assistance please just ask. We all want this code to go upstream and we greatly appreciate the effort it will take.

    escalade what's the plan to submit an Exynos build project? .. GBM/V4L2 will improve with the stateful decoder work that's planned/pending for Amlogic and Rasbperry Pi (which share the same code path).

    Kestouf I normally ask HK directly if we need board samples; then they're aware of who's active within their developer community.

    LE images for RPi use a tweaked version of ffmpeg and Kodi that contains work done by the Raspberry Pi foundation to optimise HEVC performance on Pi hardware. I'm a little suprised that Raspbian doesn't include the same given who created (and maintains) those sources.

    LibreELEC.tv/package.mk at master · LibreELEC/LibreELEC.tv · GitHub <= should have everything needed.

    OSMC uses the same upstream (AFAIK) so might be worth investigating too - as it's Debian based under the hood.

    It basically works on Gemini lake + hardware and various patch-series got merged upstream in the kernel and mesa. The next LE release will be LE 9.2 .. but still based on Kodi v18(.2 or .3 maybe) and with not-quite the bits needed. TL/DR; HDR will be a Kodi v19 thing and alpha releases for that are still some way off. Milhouse nightlies are pre-Alpha and there's are still some large plumbing changes to drop (old stuff being removed, some new stuff to come in) before the codebase starts to show the outlines of what the final release might be.

    ^ bad translation - I've no idea what point you're trying to make

    If you want to install LibreELEC on the devvice we can help. If you want to restore Android on it .. that's someone else's problem and you're asking for help in the wrong forum. I'm not trying to be awkward, but our expertise is all about erasing Android not installing and recovering it.

    Tuner drivers are not installed.

    If you (and the persistent +1/me-too tuner-using collective) want tuner drivers in mainline kernel images please petition afl1 to reach-out to the linux-amlogic kernel maintainers and start upstreaming them. It's the only way forwards. There are people who are willing to help/assist this activity.. but it's his code and responsibilty to initiate the process. As the saying goes "the ball is in his hands" (not ours).

    Is hw decoding working on the N2 with mainline?

    And how about hdmi audio and ethernet?

    Yes .. with caveats for 4K and HEVC which have dependencies on 10-bit video work (which is now active work-in-progress again). HDMI audio is 2.0 at the moment but we've started looking into what's needed for multi-channel .. although bizarely 7.1 pass-through (AC3/DTS) also appears to be working as long as you set 'optimised' not 'best match' in Kodi. Ethernet is no problem.

    I see both HK and Khadas as different shades of the same grey when it comes to software support. HK definitely have a more active user community around their products and some reasonable staff, but you can count the number of upstream kernel/u-boot/etc. commits from those staff on the same lack of fingers as Khadas (and several other SBC vendors). At the end of the day they all have the same business model which relies on seeding free samples among the Linux community in the hope that enthusiasts will do most of the work for them. The *only* board manufacturer who gets my vote for contribution is LibreComputer; who don't code anything themselves, but have been bankrolling Amlogic GX mainline development for some time - which has directly benefitted the entire community in addition to their own products. LibreComputer customers don't need much vendor support because you can just grab the latest upstream source for kernel, u-boot, etc. and everything is already supported.

    VIM3 has a reworked heatsink and fan; there are taller vanes on the heatsink and the fan (which is allegedly silent now) has swapped sides to improve the cooling .. although I wouldn't know as Khadas forgot to include one in the sample kit. I have the board in one of their fancy cases (which I think are a bit crap, but they do the job) and it's warmer than cool (and the N2) but also shows no signs of overheating and it's still nowhere near the "raging inferno" temp that mk1 AppleTV's used to reach. Once G12 devices start running at full speed I might need to check the temps - right now they're on minimum clock at 1.2GHz (and still faster than previous generations) - but then adding the fan is the obvious addition. I wouldn't want to run one for long without the heatsink.

    NB: The initial VIM3 device-tree that I made was literally a 10 mins copy/paste exercise (in a Hotel room .. no special tools needed). Once we have a few more devices under our belt I think G12A/B will be an identikit exercise.