Posts by chewitt

  • Help to unbrick a TVbox x96 S905x

    Quote from Sniperassault

    GXL:BL1:9ac50e:a1974b;FEAT:ADFC31AC;POC:3;RCY:0;EMMC:0;READ:0;0.0;CHK:0;

    ERROR! Customer ID not match!

    The first line is what I would normally expect to see on a GXL (S905X) board indicating BL1 (silicon) cannot find BL2 (software) to boot the board. The second line i've never seen before and my first thought given the wording, is that BL1 is looking for a locked BL2, e.g. in addition to the normal FIP creation process, the boot firmware has been encrypted (signed) with a specific customer key.

    The eMMC is blank though, so you can experiment with e.g. VIM1, VIM2, LaFrite, LePotato, Radxa Zero 'board' images written to an SD card to see what happens on the UART connection. Create the SD card then change the dtb filename in extlinux.conf to meson-gxl-s905x-p212.dtb and see what happens. If any of them run u-boot without experiencing a fail/reset/reboot cycle, you got lucky and the FIP sources for that board will work with your box too. If you see the Customer ID error again BL1 is locked and the only firmware that will boot the board is the original Android ROM that's been signed with the correct key. I have a hunch it's the latter scenario, but the only way to find out is trying.

  • [x86-64] LE 12.2 doesn't boot on ASUS Chromebox (CN60)

    It's years since I booted the Generic image so I have fuzzy recall, but press keys when the syslinux prompt is showing and it should stop and allow you to correct and type 'run' and not enter the installer.

    Another idea if it's failing early is edit syslinux.cfg and remove 'quiet' from boot params and it will dump the system log to screen. If it fails with an obvious kernel splat take a picture and share it. Or take a video on a phone in slow-mo mode with a high frame rate and the resulting video can be scrolled through to look for errors.

  • [x86-64] LE 12.2 doesn't boot on ASUS Chromebox (CN60)

    In 99%+ of cases where a user reports "Kodi doesn't start" the OS is running happily in the background and if SSH has been enabled you can login via SSH to capture logs. If SSH is not enabled, drop 12.0 files in the 'Updates' Samba share and reboot to downgrade to the earlier release and enable SSH, then update to the problem version again.

    Alternatively, boot from a 12.0 installer USB, interrupt boot and type 'run' to boot/run from USB instead of installing, then enable SSH to access the console and edit syslinux.cfg in the internal drive's boot partition (mounted under /var/media/) to append 'ssh' to kernel boot params so the SSH daemon is forced to start on boot. Then shutdown and reboot to the problem OS to poke around and share logs.

    Or just do as suggested; access the 'Logfiles' share on 'a' problem box and upload the zip here. Until you share some evidence of the problem we have no idea what the issue might be, and cannot do anything more for you.

  • Equalizer, mixing control for audio device (external USB)

    Quote from thomaz

    And an EQ isnt possible?

    An 'ADSP' effort was started by one of the Team Kodi developers (alwinus) a few years ago but eventually fizzled out due to lack of time (due to work) and complexity involved. Creating an EQ is simple. Creating one that works across all the different audio sinks that Kodi supports, and a broad range of hardware, is not so simple. In theory that effort could resume, or be superseded, but as it's now known to be a large and overly complicated task, and Kodi is an all-volunteer team, it requires a skilled developer who really wants that feature to show up and code it.

  • RK3328 4K HEVC stutter frame drop

    Your can have a fast or cheap solution:

    Fast = Spend $$ on hardware that solves the problem (display that supports 4K@25, or x86_64 board with 10x the CPU resources)

    Cheap = Convert the media (Handbrake is $0, it does batch conversions)

    Choose one option and move forwards. I'm not interested in repeating myself a third time.

  • Help to unbrick a TVbox x96 S905x

    The first thing to do is wire up a UART cable to the board. The pads are in a row of four at the top-right of the board in the upper photo. The square pad is ground, the next two are TX/RX, then +3.3v which doesn't need to be wired. The UART runs at 115200 8/n/1 and allows you to see what happens during boot. Without this you are flying blind and the only response to further posts asking for help and/or saying "that didn't work" is /shrug

    If the eMMC storage is fully erased you can write an AMLGX 'board' image for another GXL/GXM hardware device., e.g VIM1, VIM2, LePotato, etc. to an SD card and see if any of them will boot; first edit the exlinux.conf file to use the p212 device-tree which should work (enough) with any Android box. If the image doesn't boot, try another. The goal is to find an image with u-boot compiled with an acs.bin (which contains RAM spec info) that works with the board. The board has SSV6051P sdio WiFi which is the cheapest of cheap WiFi modules and that normally implies low-spec (low-bin) RAM that's less likely to match against an SBC manufactured with better quality components. Experimenting is free though, and over time I've found quite a few Android boxes that will boot using e.g. LePotato or VIM2 images. If you can boot an image, then you can download the same image to /storage, uncompress it and then 'dd' the image to the /dev/mmcblk1 (eMMC) device and the box should then boot from eMMC again.

    If the board has traces of a wrong u-boot on eMMC (only visible with UART output) then you will need to desolder the eMMC chip to run the u-boot experiments as the bootrom always attempts boot from eMMC first, and the BGA packacing prevents you from doing the normal 'short pins' method (sounds like you figured that out already). The board will then be stuck booting from SD card as resoldering will reinstate the wrong u-boot, but perhaps with the BGA package removed you can see traces and figure out another way to temp short/disable the chip. If you can disable it and boot from SD then you can 'release' the short post boot. The chip can then be detected and becomes something you can erase/overwrite from the console.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    If extlinux is /FDTDIR the boot firmware auto-selects the correct device-tree to use whereas /FDT defines a specific device-tree to boot with. I'm not sure how the auto-select in u-boot works for Rockchip (I'd need to go look at current u-boot source) but I trust that Kwiboo knows/knew what he was doing when setting things up like that. To triage the problem you need to attach a UART cable to the board and capture the early boot messages.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    LE has some patches for v4l2_request and v4l2_m2m support. We cannot upstream them to Kodi because they depend upon the corresponding set of patches for ffmpeg that are also not upstream. Once the ffmpeg patches get merged and the ABI becomes defined, we'll be able to finalise the Kodi patches and get them merged.

    The issues with Jellyfin files were related to selecting the correct plane supporting 10-bit pixfmt. This is currently done with some simple patches applied to RK images only as Kodi lacks proper logic for plane selection and plane ordering. If you run Kodi under Wayland, the compositor handles this for you, but for GBM use Kodi needs to have its own similar logic.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from diederik

    Dunno if that is in some way relevant for LibreELEC, but it may provide a clue

    I'd expect Wayland to be using zero-copy rendering as this is supported by the DRM layer and Mesa on RK hardware. For zero-copy to work mpv needs to use DRMPRIME pixfmt so buffers contain a pointer to a frame (in DMA) not a decoded frame. I'm not familiar with mpv config options but I'd guess --vo=dmabuf-wayland forces the correct output buffer format (that the compositor expects) for that to work.

    LE is not using mpv or Wayland, but Kodi and ffmpeg support both zero-copy (DRMPRIME) and normal (EGL) output. DRMPRIME is the default in all our ARM SoC images as it's more efficient, which is important for ARM SoC boards.

    NB: I have no playback issues with any of your private test samples on newer RK boards (356X, 3576, 3588).

  • RK3328 4K HEVC stutter frame drop

    There is no magic Kodi configuration that will fix this problem on your hardware. The three solutions are:

    a) Use a monitor or TV that has the required 4K@25 or (doubled) 4K@50 refresh rate so the RK3328 board can play media at native refresh rates without needing CPU conversion to 4K@60 or 1080@60 that a low-spec ARM SoC chip cannot handle.

    b) Use high-spec hardware that can handle the required CPU conversion to 4K@60 or 1080@60.

    c) Convert problem media (offline, using Handbrake) from 4K@25 to something that matches monitor modes, i.e. 4K@30 so the low-spec ARM SoC hardware can play media at native rates (as with the BBB file).

  • RK3328 4K HEVC stutter frame drop

    Comments:

    a) The desktop resolution is 1080@60.

    b) The whitelist has been configured but the whitelist decision-tree (evaluating what mode from the configuration to use) is not visible when media is played and this normally means adjust-refresh and/or the whitelist are not enabled.

    c) The family-movie file is 3840x2160@25 but there is no 4K@25 mode in the whitelist or EDID data. This means Kodi cannot play media at its native rate or a 'double' of the native rate (4K@50) and must adapt the content. This does not give great results, and there is also no mention of a rate change in the log so it might be converting 4K@25 to 1080@60?

    d) The log does not show playback of the BBB file, but this media is 3840x2160@60 and there is a 3840x2160@60 mode available so Kodi will be able to output at the native resolution/refresh.

    e) The "Impossible to convert between the formats" error is unusual (first time that I see it) and I'm not sure where in code that comes from, but the mention of scaling also makes me think it might be trying to scale 4K@25 to 1080@60.

    f) EDID data shows "IIyama" which is a Monitor brand. If this is a monitor? using a TV with a full selection of modes, ensuring that adjust-refresh and whitelist are enabled and set correctly (as per the article I linked before) the results should be better. The EDID data shows 4K@25/50 and [email protected]/24/25/29.97/30 modes are missing; although enabling rate-doubling means the 25/29.97/30 modes can match with 50/59.94/60. The lack of [email protected] mode means HD movies must be CPU scaled to [email protected] and this can impact overall device performance.

    g) If this is the only screen you have, download Handbrake and convert the problem files to 4K@30 and they should play better on a device that has a 4K@30 (and 4K@60) mode. Configure the phone? to use 4K@30 and then future movies don't require you to convert them with Handbrake.

    TL/DR: Monitors make rubbish TV's /shrug