Posts by frakkin64

  • Rpi 4b, Odroid N2+ or other

    Quote from libreelekuer

    It seems I better look into the Amlogic chipsets since this device will be only a media center and video decoding is its main function.

    You should plan on buying an SBC and not an Android TV box, and you should definitely research which SBC you buy and how well they are supported. I have heard complaints that some SBCs are all great until it breaks (the warranty/support is sometimes non-existant, they likely suspect it is a user fault, and it probably is most of the time). Since most Amlogic devices with working video decoding are running a 4.9 kernel or older you should expect problems with device compatibility. So really make sure what you buy is 99% self contained (on-board the SBC), and any devices you intend to plug in are fully supported by the OS your planning on running. Good luck.

    Rockchip might me something worth looking at, not super familiar with those boards, but I believe a lot of it is mainline supported. Just know my experience with Amlogic is not great, RPi is great for me.

  • Libreelec from Pi 4 4gb to 8gb - update required?

    Screenshot might help and LE version your running, but my guess here is you might have an incompatibility between the EEPROM & bootloader? You could try using Raspbian to install the latest EEPROM, and try the SD again.

    IMO 8GB is way excessive for a media center, 2GB is plenty and 4GB is generous.


    There are some rev 1.6 boards that I have heard may require bootloader updates. So you might need to try to update to LE 10.0.2, if your still on LE 9.2.x and earlier then the recommend path is a fresh install.

  • Rpi 4b, Odroid N2+ or other

    At this point buy what you can find & want to spend money on, as long as it's 2GB or more and fits your intended usage. :) I can confirm 2GB is totally fine if your interests are basic media center usage, yet to find any add-on that doesn't work, but it depends on your workload. Some people like to use the RPi for everything under the sun plus a media center, but I just use it for the media center and have PVRs and storage on AMD-based servers.

    By the way, the basic media center usage with a 512MB video buffer cache doesn't use more than ~750MB of RAM in total, I also don't run Samba or Cron services as I don't need it. YMMV.

  • Vero 4K+ board bring-up and testing

    Quote from chewitt

    As long as you backup the eMMC using "dd" first it shouldn't be too hard to restore it again if things go wrong. GXL devices boot the same from eMMC and SD card so once you've erased eMMC it's simple to test u-boot(s) from SD and when you've proven it works, you can write the boot stuff to eMMC. In the event you do screw up and need to erase eMMC the worst-case scenario is shorting pins on the eMMC chip to stop it being checked during boot, and then the SOC finds u-boot on SD or USB again.

    Ah yes, I recall reading that Amlogic will fallback to booting from an SD card when the eMMC wiped. And I do have dd copies of the eMMC already, just recently had a problem where the instaboot partition was wiped and OSMC uses that partition as a part of the VG for the root disk. I am guessing there is some "Android" specific scenario that causes this, this is the 2nd time I have ran into.

    I guess I'll need 2 SD cards, one with the original Amlogic U-Boot and some sort of basic Linux OS to run DD on (sounds like LE will do), and another one with the testing U-Boot.

    Quote from chewitt

    IIRC there are some capabilities that OSMC runs from the secure world (BL32) to prevent them being copied (Dolby Vision?) so any mainline u-boot will lose those (not that upstream supports DV anyway). I can ask Sam for the boot FIPs (minus the BL32 bits I'd expect) and then it's a straightforward process to create a complete image.

    For now I used gxlimg to pull those pieces out, and they should be usable directly in aml_encrypt_gxl I would think (at least it doesn't complain). Probably the next step is to give this a shot from an SD card.

  • Vero 4K+ board bring-up and testing

    Any thoughts on how to approach mainline U-Boot? I did test the libretech-s905-pc config (which is a close match) with mainline U-Boot via chainloading:

    fatload mmc 0 1000000 u-boot.bin

    go 1000000

    Console went from the SDIO debug board (using a Adafruit SD card breakout board with a 4.7k pull-down resistor between D3 & ground, then with my USB UART its RX is on D3 and its TX is on D2) to the TV, but U-Boot does appear to work and a bit more functional than the Amlogic U-Boot in the sense that tftp is working. It did seem to recognize the eMMC, but assuming there are some tweaks to get it to use the UART. I also assume that mainline U-Boot knows nothing about the Android MPT partition table (much like mainline Linux is oblivious to it), so eventually a format of the eMMC would be in order.

    Main goal was to verify I could chainload, to verify the status of U-Boot. Does anyone else do it this way, or do you just go for broke and write U-Boot to the eMMC? :)

  • RPi firmware in 10.0.2 not updating

    Quote from Forage

    The contents of the /flash partition does not change when toggling the setting. This message tells me that it actually happens when performing the reboot. But the subsequent reboot does not manage to actually perform the update.

    The LE app only touches a file /storage/.rpi_flash_firmware with the contents of the switches selected, at reboot when this file exists LE starts a target for flashing firmware. However this only installs from the critical channel, so that's going to be the January 25th EEPROM you see with "rpi-eeprom-update". It sounds like that part is all working correctly, but perhaps the command run during the target has an issue, do you have a screen grab?

    Maybe you can run this via ssh and see if there is any error? It will just stage the eeprom updates (same as rpi-eeprom-update -a):

    USE_FLASHROM=0 /usr/bin/.rpi-eeprom-update.real -A bootloader -A vl805

    You should see the same output as rpi-eeprom-update -a, and if you can check for the existence of the flag file /storage/.rpi_flash_firmware after toggling in the LE app the contents should have one or both of these set to yes:

    BOOTLOADER=yes

    VL805=yes

  • RPi firmware in 10.0.2 not updating

    Quote from Forage

    Yes, that is what i meant with "switching on the update setting". Than at boot it does show some firmware messages, but nothing gets applied.

    If you log in via ssh, what does "rpi-eeprom-update" show? I never use the settings app, but I just updated via ssh using the stable channel and that method works fine.

    What the script does is stages a recovery.bin in /flash, and 2 files pieeprom.upd and pieeprom.sig, the rest is handled by the Raspberry Pi hardware itself. The bootloader will look for recovery.bin, which I think is the flashing program and that looks for the signature file & update file to flash.

    So perhaps, toggle the update, login via ssh, and check the /flash folder to see if these three files exist. If they do, and after rebooting it doesn't work, then maybe this issue may help with that as it sounds like maybe boot order plays a role or having USB drive & SD card may be an issue?

    rpi-eeprom-update don't flash · Issue #220 · raspberrypi/rpi-eeprom
    Hello, I was unable to flash the eprom again, the rpi-eeprom-update says that flash it ok, but then after a reboot all remains the same. This is RPI 4 b model…
    github.com

  • RPi firmware in 10.0.2 not updating

    Did you install the firmware? It's not automatic. You have to open the LE Settings app, go to firmware, and at the bottom there is 2 toggles to install the firmware on next reboot.

    I usually just jump into ssh and run "rpi-eeprom-update -a" and reboot. LE is tracking the "critical" channel, not "stable" or "beta".

  • Screen resolution & playing resolution

    Depends on whether you have "Adjust display refresh rate" enabled or not.

    https://wiki.libreelec.tv/configuration/4k-hdr

    GUI resolution should stay at 1920x1080, and adjust display refresh rate should be enabled. The guide above has recommended settings, which includes whitelisting resolutions & refresh rates to get the best experience. If you change the GUI, unless you have an x86-based device, you will probably run into stuttering during playback of non 4k content.

  • LibreELEC-RPi4.arm-11.0-nightly-20220213-fcba5db is restarting every 20 seconds

    Code
    Jan 18 22:05:43.554562 LibreELEC kernel: Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1  smsc95xx.macaddr=DC:A6:32:27:3D:FB vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  boot=UUID=2710-1204 disk=UUID=a4d75028-811f-4077-8e1e-6cd47fe5eefa quiet
Jan 18 22:05:43.554617 LibreELEC kernel: Unknown kernel command line parameters "boot=UUID=2710-1204 disk=UUID=a4d75028-811f-4077-8e1e-6cd47fe5eefa", will be passed to user space.
    Quote from Da Flex

    I have none of the params before "boot=UUID..."

    Those parameters "coherent... " are injected by the Pi boot loader based on config.txt settings, and then it takes cmdline.txt and appends it when bootstrapping the kernel. So it's normal for a Pi 4.

    Also the Unknown kernel command line parameters is harmless, it is used by the init script in the initrd to mount the disks (the "user space"). This is where $boot is used to mount the /flash partition, just below that there is mount_storage function where $disk is used:

    LibreELEC.tv/init at f42fa56ed8b98f9829d156360b71b0b18de8b86b · LibreELEC/LibreELEC.tv
    Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.
    github.com


    It might be useful if you have this log:

    Code
    Feb 15 11:47:31.835476 LibreELEC kodi.sh[1725]: Segmentation fault (core dumped)
Feb 15 11:47:34.440636 LibreELEC kodi.sh[1725]: Crash report available at /storage/.kodi/temp/kodi_crashlog_20220215114731.log

  • Radxa Zero mmc issues

    Quote from chewitt

    Okay.. I dropped that from the USB-C addition patch. That patch is a placeholder at the moment as (according to Neil) there's a polarity issue not handled in the fusb302 code that prevents the driver from probing. It's greek to me, might mean more to you?

    I have pretty minimal electronics background, took a class back in high school from some pretty awful teachers that didn't explain anything. :) I did look at the schematics, and what I found interesting is the GPIO is a 3.3Vdc power domain and it is connected to the enable pin of the regulator with a external 10k pull-up resistor to 5Vdc, so I thought that was odd. But I can't say the schematics are accurate or complete. Since the regulator enable pin has an external pull up to 5Vdc, it should be on at boot and I believe the GPIO configuration in the DT is purely for power management (being able to drive the enable bit to ground via the GPIO).

    What I didn't understand is why it caused issues with the SD card. The SD card does use a 3.3Vdc supply, so a bit lost on why that is. According to the schematics, this is the right GPIO pin.

  • Radxa Zero mmc issues

    I was able to reduce the problem to this in the DT:

  • Radxa Zero mmc issues

    Quote from chewitt

    NB: I have the impression that Armbian support for Amlogic isn't the best due to everyone on staff deliberately trying to look the other way and avoid the noise from unsupported "TV Box" users and board vendors not funding support. The net result seems to be a mixed bag of patches from various places and a generic defconfig. I respond to Q's when asked but I don't follow their development.

    Yeah, I am not super impressed with how the patches are managed. It's a hot-podge of diff's & am/format-patch styles, which of course am hates, so it's a PITA to pull it into Git and rebase the patches.

    So this same issue affects LE booted SDs, which means it's running an LE kernel & LE DTB. Mostly using Armbian kernels as a host because it is working & installed on the eMMC. So it seems like whatever the issue is related to the latest DT. So do you think there is a missing patch with LE as well?

    Edit: I actually rebuilt 5.16.9 with only patches for bootsplash/fb & patches from LE, same result. I think I also tested 5.16.9 mainline with just bootslash/fb patches, and had the same result.

  • Radxa Zero mmc issues

    Got to the bottom of it, it is actually a DT issue.

    5.16.9 works fine with this DT:

    build/arm64-dts-amlogic-add-support-for-Radxa-Zero.patch at master · armbian/build
    Armbian Linux build framework. Contribute to armbian/build development by creating an account on GitHub.
    github.com

    Same kernel (literally the same one, just swapped DTB) with this DT causes SD corrupting and HW resets on SD (This is the one that should be in stable 5.16.y, I believe, because Armbian kicks it out):

    build/arm64-dts-amlogic-add-support-for-Radxa-Zero-0001.patch at master · armbian/build
    Armbian Linux build framework. Contribute to armbian/build development by creating an account on GitHub.
    github.com

    Not quite sure why yet. Didn't see anything directly touching &sd_emmc_b, but didn't spend a lot of time looking at the full DT. Also repeated the test with 5.13 (which oddly has Wifi issues) and the 2 DTBs and found the same result.