I've no idea. Go download an old image and boot it to find out.
Posts by chewitt
-
-
I .. was wondering whether any more thought has been given to add support for Hyper-V virtual environments given the purchase of VMware by Broadcom and their apparent reduced interest in supporting the end user community ?
I can't recall the last time anyone on staff talked about using the Virtual image for development purposes, so I'm highly confident there have been zero thoughts about Hyper-V support. If people did want to run an image on something non-vmware the go-to these days would probably be Oracle Virtualbox since it's $free, already works, and doesn't require Windows. On the server side Proxmox seems to be what people are using.
-
Initial support for RK356X, RK3576, and RK3588 has been merged!
I'll give it a few days for 'the internet' to self-build and point out obvious mistakes and then we'll get some nigthlies organised for the wider unsuspecting public to break their setups with
-
I can only pseudo-read the current driver code and I'm not aware of what the underlying 4K on GXBB issue was so I can't comment on what the current dimensions cap achieves or avoids. As the current driver is in an 'abandoned' development state I'll also avoid making changes in the LE sources, although changing the max resolution to 1920 x 1920 to support portrait 1080p media is probably okay as the memory usage will remain the same. I'd say "report back if you encounter any weird stuff" but as the drivers are not in a finished state there's plenty of known weird stuff to find
-
Da Flex that's not an appropriate comment/rebuke because XR819 is an Allwinner own-brand WiFi chip found on some older Allwinner boards. The specific device/OEM is irrelevant due to the not-supported state of the chip.
-
diederik I haven't unpacked the Rock 3C board (RK3566) that Radxa sent me, so no idea if that works or what's missing. Feel free to experiment and make suggestions.
-
There is no upstream driver and no current attempt to author an upstreamable driver that I can see.
This appears to be the most widely used driver source that I can see: https://github.com/fifteenhex/xradio and this probably makes it the 'least worst' to use (the repo README is honest). This chipset has quite a reputation for being rubbish once you start looking-for and finding information on it.
LE has zero interest in adding out-of-tree drivers with no upstream plan to the buildsystem, but a self-built image can probably be done. I spotted some notes here: RE: How helpful will this be to getting LibreELEC on allwinner android boxes? and the zip file posted there contains some examples of the kernel device-tree changes that would be needed alongside the kernel driver itself. There are other threads that mention XR819 but they look to be mostly users asking for drivers and being told that it's not supported.
Unless you like the development challenge (with the likelihood of a poor experience outcome even if successful) I'd probably just get myself a USB wifi dongle or a USB-powered Ethernet/WiFi bridge dongle and not go down the self-built image route.
If you do, the Realtek out-of-tree drivers found in older LE images (LE11 for example) are probably a good starting point for cribbing the format for a simple buildsystem package that compiles the driver.
-
I pushed updated images for all Rockchip hardware to my test share. Older hardware now includes the kernel fixes recently made for LE12.2 images and a bump to 6.16.4. Newer hardware has additional realtek NIC firmware(s) to silence missing firmware messages noticed in some of the logs recently shared. Kernel for newer hardware is bumped to 6.17-rc5 .. no media capability changes.
-
The audio glitch is likely the outcome of a lack of bandwidth on the connection as reducing bits-per-pixel (bpc) from 12-bit to 10-bit will reduce bandwidth consumed by video and create headroom for audio; and this appears to work around the issue.
Colourspace and Colourdepth are different things. There is also a distinction between RGB and YUV output and these both depend on the HDMI capabilities of the hardware (including any inline converters) and the connected TV and/or AVR.
The DP cable will be mitigating the audio glitch as it forced colourdepth to 8-bit. Combined with BT2020 colourspace this is still valid for HDR, but 10-bit depth would be preferrable to 8-bit as the latter normally results in visible banding due to the lower number of colours available.
-
Which one do you recommend:
I recommend you experiment and figure out if one of them boots with the device-tree file that Armbian are using. Then (most important) you keep quiet if there are any issues, because it's a hack. I'll happily pick support for any new boards to the patchset, but it's a hard requirement to see the patches on a mailing list first.
-
The lsof command is a snapshot point in time, not a continuous historical view. So if the process accesing the drives is something that runs/stops/runs/stops you might need to run it a few times to catch/observe the process that accesses the drives.
NB: I'd expect something like 5-seconds shutdown to be ineffective. Try using a longer value like 30/60/90 seconds.
-
it didn't show up under LibreElec 12.02 Updates/Updatechannel.
Intentional, because it's not a 12.0.x release, and there are breaking changes for some hardware types.
-
hephooey The vendor kernel required a bunch of intrusive workarounds to make 4K H264 work on GXBB hardware and to keep the code cleaner this was never replicated into the upstream driver, so GXBB is intentionally capped at 1080p. GXL and onward can handle 4K H264 without the workarounds.
Original developer comment: https://github.com/Elyotna/linux/…mment-491039526
-
You are already talking to the developer: https://github.com/aassif/pvr.freebox/issues/118
Continue there. He knows more than we do about the add-on and how it works.
-
-
I've pushed some updated AMLGX images to my test share (first time in a while) which have the 'being upstreamed' VFD driver working in a near final state now. There's not much else interesting aside from a bump to Linux 6.16.5. No changes in any of the media capabilities.
-
Code
lsof | grep /media/USBDRIVEThis ^ will tell you the processes that are interacting with the disk (at the time you run the command). It might just show Kodi which is not helpful, but might also show you something else on the system that's keeping it awake.
-
Is there a way to configure these files to be put on the 8TB drive instead? Or can I fix this by changing partition sizes? Something else? in System Information, it shows mmcblk1p2 is 28G, with 28G being used 100%.
The initial image that you wrote to the SD card has 512MB for /flash (boot) files and 32MB for /storage; the second partition should be removed and resized to 100% (32GB) on first boot. If you have run out of space, either something has dumped a ton of data to the SD card and filled 32GB up, or perhaps the remove/resize didn't happen and you've filled up 32MB not 32GB?
Boot params on the SD card in extlinux/extlinux.conf show boot=UUID=<string> disk=UUID=<string> .. if you check the UUID for the partition on the USB drive using blkid you can change disk=UUID=<string> to use that UUID and on boot it should use the USB drive for /storage and you'll start with a clean Kodi instance that you can move config over to. You can also mount using disk labels, e.g. boot=LABEL=LIBREELEC disk=LABEL=MYDRIVE assuming partitions are labelled or boot=/dev/mmcblk1p1 disk=/dev/sda1 style params. Note that you will need to use a Linux filesystem on the USB drive, e.g. EXT4, else the ssh daemon will fail to start since it depends on Linux filesystem permissions, and non-Linux filesystems (NTFS, exFAT) don't support Linux permissions.
In theory the SD card image can be written direct to the USB drive and it should boot from that too; although I have fuzzy recall that the Amlogic bootrom only checks for bootable USB drives in specific ports, e.g. the OTG port.
