Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 5404

HATs and other add-ons • Pi4 TV-HAT continuity errors when ARM clock <1500MHz

$
0
0
I have replaced a Pi3B+ wearing a TV-HAT with a Pi4B v1.1 but this has a strange issue. All is fine and normal if there is enough load on 1 of the CPU cores such that a constant 1500MHz is deployed. For testing: gzip < /dev/random > /dev/null
As soon as there is not much to do, like only recording a radio or TV channel, massive amount of continuity errors. SNR and SignalStrength are still fine. mpv more or less locks up on playing a TV channel, so totally useless. It looks to me that data packets are lost/corrupted or so in the lower layers of the Sony driver (SPI, I2C).
The setup is run from NFSroot, I basically only changed the MAC/serial in the TFTP server. OS is up-to-date RPiOS Bookworm. That is also where I fear the problem comes from, some regression. In btop I see ARM clock changing 600 700 when 2x ffmpeg transcoders HE-AAC to opus, load is just a few percent.

Code:

EEPROM------BOOTLOADER: up to date   CURRENT: Mon Apr 15 01:12:14 PM UTC 2024 (1713186734)    LATEST: Mon Apr 15 01:12:14 PM UTC 2024 (1713186734)   RELEASE: default (/lib/firmware/raspberrypi/bootloader-2711/default)            Use raspi-config to change the release.  VL805_FW: Dedicated VL805 EEPROM     VL805: up to date   CURRENT: 000138c0    LATEST: 000138c0config.txt----------arm_64bit=1arm_freq=1500audio_pwm_mode=514auto_initramfs=1camera_auto_detect=-1config_hdmi_boost=5core_freq=500core_freq_min=200disable_commandline_tags=2disable_l2cache=1display_hdmi_rotate=-1display_lcd_rotate=-1dvfs=3enable_gic=1enable_uart=1force_eeprom_read=1force_pwm_open=1framebuffer_ignore_alpha=1framebuffer_swap=1gpu_freq=500gpu_freq_min=250init_uart_clock=0x2dc6c00lcd_framerate=60mask_gpu_interrupt0=3072mask_gpu_interrupt1=25635max_framebuffers=2over_voltage_avs=-36250pause_burst_frames=1pciex4_reset=1pmic_turbo_threshold=600power_force_3v3_pwm=1program_serial_random=1total_mem=2048hdmi_force_cec_address:0=65535hdmi_force_cec_address:1=65535hdmi_pixel_freq_limit:0=0x11e1a300hdmi_pixel_freq_limit:1=0x11e1a300device_tree=-overlay_prefix=overlays/hdmi_cvt:0=hdmi_cvt:1=hdmi_edid_filename:0=hdmi_edid_filename:1=hdmi_timings:0=hdmi_timings:1=
# cat /boot/firmware/config.txt

Code:

# kernel and initrdarm_64bit=1auto_initramfs=1# see also cmdline.txtenable_uart=1# only eth0 needed, best to disable RF via DeviceTree, otherwise via  rfkill blockalldtoverlay=disable-wifidtoverlay=disable-bt# raise max clock to 2GHz#arm_freq=2000# uncomment this if your display has a black border of unused pixels visible# and your display can output without overscan#disable_overscan=1# uncomment to force a console size. By default it will be display's size minus# overscan.#framebuffer_width=1920#framebuffer_height=1080# Enable DRM VC4 V3D#dtoverlay=vc4-kms-v3d,cma-512dtoverlay=vc4-kms-v3d# both HDMI0 and HDMI1 connected on this RPi4, so this needs to match (=2)max_framebuffers=2
HW connections/cables are USB-C PSU, RJ45, RF antenna

I did already several tests, but it turns out the basic config.txt I initially used, so the unmodified one for Pi3B+, also does not work. 2GHz or 1.5GHz does not matter.
Use-case is transcoding now as well HEVC->H264. That actually hides the problem as it occupies 1 core max (is known behavior). So first was very happy that I can now play TV in webbrowser, until next day I saw all recorded content outside the timeframes of webplayer/transcoder active was rubbish.

What could be wrong?
Anyone else who sees this on a Pi4?

Statistics: Posted by redvli — Sun Nov 03, 2024 2:17 pm — Replies 0 — Views 30



Viewing all articles
Browse latest Browse all 5404

Latest Images

Trending Articles



Latest Images