I'm aware of a well known SOM board manufacturer who's nearing launch of an A311D based product, and an early customer wants upstream kernel and working video on Linux so I've been connecting their lead developer to all the right sources and bits, and he's preparing to start looking at the code although we need to be patient as there's some other tasks on the board bring-up list right now. How much overlap there is between his customer's needs and our needs remains to be seen, but I'm hopeful that we can get another lurch forwards on the newer hardware out of it. Otherwise we're at the mercy of community development. It needs one or two 'community' developers with some driver skills and time on their hands who are prepared to experiment and learn. Some of the changes needed probably aren't too big .. it just needs the will to fiddle and do trial/error testing.
Posts by chewitt
-
-
Do these types of bugs need to be reported somewhere or assume that the developers know about them?
Who is developing this codec? Is this project available somewhere like github, or is it integrated with Kodi?
If you've anything insightful about codecs to share, please share it. If you've just got a "this doesn't work" to report, we already know it.
The code is in the upstream Linux kernel staging area: drivers/staging/media/meson/vdec
Nobody is currently developing this code. That should change soon, but we have to be patient.
-
I don't see any mention of the GPIOs in the original dts files either, but "If it works, don't fix it" so I think we're good. Can you share a final dmesg with that applied please.
It would also be good to validate the 4K dts as well, although ethernet on that should be trivial as all S905X use internal PHY and there's nothing to configure. I suspect only the usb fix might be needed.
Sadly the next round of improvements will be all about media codecs, which is beyond my code-skills.
-
MPD Client is not working with Matrix KODI because of dependency issue
What dependency issue?
-
^ cmdline.txt normally looks like this, with both "boot" and "disk" using UUID identifier. I'm not sure why yours is using =label for the "disk" but it can be changed. The UUID will be unique to each .img.gz file that we release so ^ above is NOT something you can use, as it's for an image I've created that you don't have. You can find the UUIDs for your image using "blkid" command. It will look something like:
Code/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="LIBREELEC" LABEL="LIBREELEC" UUID="0602-0454" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a0ebf7ce-01" /dev/mmcblk0p2: LABEL="STORAGE" UUID="a7ecf32f-d897-4f8e-b760-03d219e31c88" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="a0ebf7ce-02"
You can see that the /dev/mmcblk0p1 (partition 1) needs UUID=0602-0454 and /dev/mmcblk0p2 (partition 2) has a much longer UUID=
a7ecf32f-d897-4f8e-b760-03d219e31c88 .. and in cmdline.txt there is a space between the boot=UUID=<string> and disk=UUID=<string> sections.
-
Ahh, thanks for the correction
-
The HEVC decoder has poor memory and buffer management which impacts resource usage and seeking; the legacy of it never being finished by its original developer (and beyond making the unfinished code run, nobody really touched it since). My semi-educated guess is that HEVC doesn't release CMA memory correctly and then when you play media requring a different codec the new codec can't reserve enough CMA and things start to fall (and hence a clean boot works around the issue). It all buckets under "HEVC needs work" and I also confirm MPEG2 is not working right now (packets go into the driver, nothing comes out).
S912's have always run hot so a good heatsink is never a bad thing. I've a VIM2 + heatsink which runs around 60-65ºC so I'd be wondering what add-ons you're using that chew CPU in the background (some do) to keep cores busy.
-
RE: Zero see https://github.com/radxa/kernel/p…ment-1013592761 .. although I'm not sure whether A311D (more compute, but also more power needed, more heat given off, etc.) is a good fit of the small package size. A sample is in the post so I get to have a play someone soon in theory. I do like the S905Y2 version as I can power it off the UART pins and it runs well except for the state of playback on newer devices (there are some problems). There's a plan for fixing things but we need to be patient while developers work through other items on a long board bring-up list .. and eventually they reach the subset of media topics we care about.
4K and HDR works quite well on GXL/GXM devices although GXL internally processes at 10-bit but outputs only 8-bit (GXM can do 10-bit).
Latest attempt at the IRQ splat with suggestions from maintainers - see if it works:
WIP: arm64: dts: meson: add support for OSMC Vero 4K/4K+ · chewitt/linux@12d9c05The OSMC Vero 4K device is based on the Amlogic S905X (P212) reference design with 10/100 Ethernet. The Vero4K+ is based on the S905D (P230) reference design…github.com^ also see if that works for the USB error?
EDIT: I've pushed updated box/tar files with those changes.
-
-
Put batteries in the remote, put it in "pair" mode. Go into LE settings add-on, bluetooth settings, see the device, select > pair
-
-
fixup · chewitt/linux@2cc8c94github.com
^ Can you try with that. If no change please drop the IRQ 29>30 change and try again.
-
Last I heard it was generally working well on RPi3 boards (1GB RAM) and we were thinking to release LE 10.0.2 with support. I'm less sure of the state that RPi2 is in .. lots of those boards have less RAM which will be more of an issue.
-
Utiliser une clavier USB pour navigation en Kodi et connection de la télécommande Logitech
Use a USB keyboard for Kodi navigation and to connect the Logitech remote.
NB: Langue de la forum est Anglais. Il n'y a pas beaucoup des person ici qui parle Français.
-
On a Raspberry Pi the error means it booted from the KERNEL file and executed the init script inside, but this cannot find disk=?? device that was specified in kernel boot params (from cmdline.txt on a Pi device).
If cmdline.txt has disk=UUID=xxxx then perhaps change it to disk=LABEL=STORAGE and see if that works?
If you have a USB keyboard you can create a directory, mount the SD card to the directory, then use cat/sed to read/change the content of the cmdline.txt file and reboot. If you don't, remove the SD card and edit it from another computer. It's in the root folder of the SD card.
-
I updated the box/tar files with https://github.com/chewitt/linux/…6b2f58878cb5c41 based on the original dts content and the 4.9 IRQ dump. Does that resolve the splat?
I'm also interested to know if this patch improves speed (untested): https://github.com/superna9999/li…1a72fb03b85d099
-
Sam shared the original "vero3_2g_16g.dts" and "vero3plus_2g_16g.dts" dts files with me earlier which explains why I couldn't find Vero"4"k files in the OSMC GitHub kernel repos. Vero4k is indeed p212 and Vero4k+ claims to be p231 but looks like the upstream p230 and inherits most of it's content from the Vero4k/p212 tree so
but at least we have the truth on buttons (one reset, in the AV jack) and LEDs (one red) now. I suspect the blue + on the 4K is hard-wired, hence past user complaints. I can't see anything unusual in the external_mdio node but then I have no clue about IRQ/interrupt stuff.. it sounds likee you know way more than me
I've updated the box image and tar file in my share and pushed updated patches to kernel/LE branches. Boot logs appreciated..
-