New Raspberry Pi 4 VLI Firmware Lowers Temperature by 3-5°C

The other day I tested Raspberry Pi 4 with an heatsink since previous multi-threaded benchmarks clearly made the board throttle when running those without any cooling solution.

The guys at the Raspberry Pi Foundation somehow noticed my post, and I received an email from Eben Upton explaining a new Raspberry Pi 4 VLI firmware had “some thermal optimizations that are not installed by default on early production units.” I did not understand VLI at first, but eventually understood this referred to the firmware for VIA VL805 PCIe USB 3.0 controller on the board.

The Raspberry Pi Foundation provided me with a test version of the firmware, which they’ll release in the next few days, or weeks after testing is completed.

Now if you’re going to test a platform that will throttle due to overheating, it’s very important you do so at constant room temperature. I work in a office where the air conditioner is set to 28°C, so that’s about the temperature I have here.

Before going on with the test I’ve installed rpi-monitor to have nice CPU temperature charts later on:


Let’s run sbc-bench without heatsink with old VLI firmware (version 00013701):


7-zip never completed, as it was killed three times due to running out of memory. Maybe it happened because with a 1GB RPi 4, we’re right at the limit. Enabling ZRAM may help.

But we do have our temperature data for the full benchmark. We started at 67°C idle, and the spike to over 80°C (11:26 to 11:30) is exactly during 7-zip multi-threaded benchmark:

Raspberry Pi 4 SBC Bench Temperature
Tempeature during sbc-bench – Click to Enlarge

Now let’s install the firmware in a terminal in the Raspberry Pi 4:


For reference the tool can also be used to backup the firmware, and write to any location in the EEPROM:


If you mess up you’ll lose USB connectivity, but user could have to ssh or serial into the device and re-run the tool to flash an older firmware to recover. It’s unclear whether early adapter will have to update the firmware manually, or it will be done automatically as part of the update process. That’s one of the reason I can’t share the files now.

Raspberry Pi 4 VLI Firmware Idle Temperature
Click to Enlarge

Nevertheless it does seem to have some effect on idle temperature. Previously I got just under 65°C, but now I get just above 61°C once it stabilizes, so the new firmware does lower the temperature by 3 to 4°C thanks to lower power consumption. Sadly, I can’t measure the latter as my power meter is dead.

Now let’s run sbc-bench again without heatsink and the new VLI firmware (version 0137a8):


This time all three runs for 7-zip could complete for some reasons, and while throttling still did occur, it did to a lesser extent, and the temperature was clearly lower during to single thread benchmarks (~70°C vs 75°C with old firmware).

Raspberry Pi 4 VLI-805 Firmware Temperature
Click to Enlarge

For reference, 7-zip benchmark score with heatsink averaged 5,397 points, without heatsink + old VLI firmware 4,423 points, but the “no heatsink with new VLI firmware” results are much better at 5,298 points. You’ll also note the first two runs were as good as the results with heatsink, but the last one dropped to just under 5,000 points, so for full load under and extended period of time a heatsink is still recommended for full performance. It’s still impressive what a new firmware can achieve.

You may wonder what the Raspberry Pi Foundation has changed. Thomas Kaiser may have found the reason in advance, as now ASPM (Active-State Power Management) seems to be enabled:


This was not the case with the old VLI firmware. The full lspci output can be found here.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

50 Replies to “New Raspberry Pi 4 VLI Firmware Lowers Temperature by 3-5°C”

  1. Technically speaking, VLI/VIA Labs, is a separate business entity from VIA, I don’t know why they did this, but a lot business things like this makes little to no sense.

    Usually upgrading USB host controller firmwares is painless, as long as you don’t lost power, not much to mess up imho. Back in the days, NEC used to release firmwares on an almost bi-monthly schedule, but I guess that was when USB 3.0 was far from as mature as it is today. This is still an odd thing, as USB host controllers are generally not all that power hungry on their own. It looks like it has more to do with the SoC going bonkers when ASPM isn’t enabled on PCIe peripherals connected to it and it outputs more power than the PCIe device needs.

  2. Curios whether this USB storage torture test will still work with the new firmware: https://forum.openmediavault.org/index.php/Thread/27710-Raspberry-pi-4-announced-better-than-3/?postID=207330#post207330

    BTW: A simple way to improve performance on Raspbian especially with those 1GB variants running low on memory and then starting to swap on SD card is:

    Modifying zram-swap-config.conf is optional. I changed COMP_ALG=lzo and SWAPPINESS=100.

      1. Thanks, didn’t know that.

        Hmm… just installed it. But I don’t like the defaults and will keep zram-swap-config on non Armbian SBC (on Armbian zram is enabled by default).

        1. Are there suggestions to speed up zram device changes if swapoff is slow (refreshing swap storage by changing swap priority from device zram0 to zram1 needs swapoff)?

          1. The multiple zram devices is a legacy thing way back to 3.14 think armbian still support 3.14.
            But nope swap priority is the same and the system will handle swap with what is available without need to swapoff.

  3. It is interesting how other users like ETA PRIME on YouTube talk about having over clocked both CPU and GPU but don’t mention throttling issues, odd ? Confusing at least.

    1. It depends how they tested it. If they didn’t check multi-threaded workloads then it may be fine.
      Room temperature also matters. If the board is in a 20C room it may not suffer from throttling at all (TBC).

        1. Yes, it’s true. I like that temperature. It’s around 32-35C outside, so it feels cool enough. Humidity matters too, so if weather outside is not that hot, and humid, I may lower it to 26 degrees C.
          Lower than that I start wearing a sweater and woolly hat :).

    2. Because they are amateurs. They watch other YouTubers and make the same videos. Never found anything new on ETA PRIME channel.

  4. Just waiting for idle at 2.5W and i will buy this nice board or his sister!
    Hope firmware update will put idle under 2.5W!
    With an USB Network boot this board is a killer… Who want to wait 5 years or more to have h264 encode, get usable GPU acceleration for browser or QT framework?
    Real opensource soc like H3 or RK3399 miss something important, maybe crow-founding Dev delivering lib binary to be paid and after release the code when it’s finish?

    1. This is why the people will buy the RPis. The support and community is just fantastic. H265 4k desktop and bit banging i3c using pure python provided by the same board. You could even use the same board as a NAS (containers).

    2. Didn’t they start an allwinner kickstarter but there’s still no h264 support out of the box? HDMI audio pass through and cec are still missing ?

      1. > allwinner … there’s still no h264 support out of the box?

        BS. There was h.264 support from the very beginning, h.265 and Allwinner works since 2015. But in the past only with BLOBs which is pretty much the same situation as on the RPi. The Kickstarter is about to get HW accelerated video encoding on some Allwinner SoCs without any proprietary BLOBs usable with mainline kernel.

        Something that’s impossible on the RPi since the whole video thing happens completely inside the closed source proprietary domain called ThreadX. The only area of change with RPi 4 is now 3D/GPU acceleration being based on Eric Anholt’s open source driver. But wrt video/VPU nothing has changed with Raspberries (AFAIK — hopefully I’m wrong).

        1. From a potential user’s point of view, the most important question is, whether the board supports fully GPU accelerated video when using Kodi, mplayer, Firefox, or Chromium. I don’t think LibreELEC provided images for Allwinner boards even if they provided some of these blobs.

          Furthermore, Kodi users expect full HDMI CEC support. Odroid C1 users learnt the hard way that the advertised CEC is not true CEC. That’s why they released C1+. Just like RPi3 gigabit ethernet is only 300 Mbps, the HDMI CEC on Odroid C1 is no CEC. http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix also mentions no HDMI audio passthrough support. DD/DTS audio support is very crucial for the consumers who prefer ripped or stolen pirate movies.

          1. Just like RPI 4 4K YouTube video playing screws up, even 1080p full screen hurts the eyes.

            Many tester showing the truth on YouTube.

          2. > consumers who prefer ripped or stolen pirate movies

            Silly me always forgetting about the RPi’s main use case…

          3. > I don’t think LibreELEC provided images for Allwinner boards even if they provided some of these blobs.

            There are LibreELEC nightly images for Allwinner A64, H3 and H6 that use mainline V4L2 stateless decoder + additional patches to provide HW accelerated MPEG-2, H264 and HEVC free from blobs. (libmali blobs is used for GUI acceleration). MPEG-2 decoder is already in mainline linux and initial H264 decoder should land in v5.3.

            > Something that’s impossible on the RPi since the whole video thing happens completely inside the closed source proprietary domain called ThreadX.

            There is a V4L2 stateful interface (bcm2835-codec) in rpi-4.19.y that wraps the MMAL interface and is what is going to used on Kodi GBM platform for HW acceleration, someone just have to create a fully working ffmpeg V4L2 stateful decoder that can produce DRM PRIME frame descriptors (instead of the currently used proof-of-concept ffmpeg code for V4L2 stateful).
            If I understand correctly a new V4L2 driver for HEVC on RPi4 is on the to-do list, rpi-4.19.y is missing V4L2 stateless (request api) support, such new driver should target 5.x.

            > DD/DTS audio support is very crucial for the consumers

            Multi-channel LPCM should already cover most use-cases.

          4. > MMAL interface

            MMAL means ‘video done on the VideoCore by ThreadX’? And interaction happens through /dev/vchiq?

          5. > And interaction happens through /dev/vchiq?

            The bcm2835-codec driver accesses the multimedia service running on VideoCore using the vchiq-mmal driver, see https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/staging/vc04_services/bcm2835-codec/bcm2835-v4l2-codec.c for bcm2835-codec details.

            User-space only needs to interact with a standard V4L2 m2m stateful decoder instead of using the mmal/omx library. Like other V4L2 m2m stateful decoders proprietary firmware is part of the video decoding/encoding pipeline.

          6. > Like other V4L2 m2m stateful decoders proprietary firmware is part of the video decoding/encoding pipeline

            Thanks a lot for all the explanations. Highly appreciated.

            But what I still don’t understand: BLOBs are needed everywhere? Even on Allwinner hardware?

          7. > But what I still don’t understand: BLOBs are needed everywhere? Even on Allwinner hardware?

            There is generally two types of decoders, stateful and stateless, and V4L2 have two API flavors to access them, regular V4L2 m2m stateful and the new V4L2 m2m stateless (request api) added in v4.20+.

            For stateful decoders the user-space have to provide the full bitstream and will receive decoded frames in display order. Bitstream parsing can be done in firmware code with possible assistance from HW block or the firmware could just work as a mailbox to expose HW block to ARM core or anything in between. Amlogic and RPi is stateful decoders that both require firmware, what the firmware does is unclear to me.

            For stateless decoders user-space have to do bitstream parsing and provide v4l2 controls with parsed codec headers in addition to the bitstream for a single frame/slice. Generally no firmware is required and driver configures hw regs and trigger decoding of a single frame/slice, no state is generally being kept between decoding runs. Allwinner cedrus driver and Rockchip/iMX8 hantro driver is both stateless and do not require any firmware.

          8. are you refering to https://lwn.net/Articles/790006/ ?

            oops ocn, Allwinner is not Amlogic… still interesting.

            Add Amlogic video decoder driver
            From: Maxime Jourdan
            To: Mauro Carvalho Chehab , Hans Verkuil
            Subject: [PATCH v7 0/4] Add Amlogic video decoder driver
            Date: Fri, 31 May 2019 11:31:22 +0200

            …[V7] The Driver was moved to staging until it can pass future
            specification & compliance tools.

            [V6] Good news, the firmware situation is resolved. We have received a
            redistributable license from Amlogic and the firmwares have been merged
            in linux-firmware[5].

            …It was tested primarily with ffmpeg’s v4l2-m2m implementation. For instance:
            $ ffmpeg -c:v mpeg2_v4l2m2m -i sample_mpeg2.mkv -f rawvideo out.nv12

            The v4l2-compliance results are available below the patch diff.
            Tests start failing when v4l2-compliance tries to dequeue the
            V4L2_EVENT_SOURCE_CHANGE event, which is not supported for MPEG2 currently.

    3. The Raspberry Pi foundation is working on further thermal/power optimizations with the SDRAM controller.

      1. Would be funny if this would result in lower memory performance scores. Same with the new VL805 firmware and USB3 performance.

        The benchmark numbers generated last week will be those that remain. Even if further attempts to get the RPi in a sane consumption range will slow the board down from then on.

        Something similar has happened last year with the RPi 3B+ — with ThreadX release 4800f08a139d6ca1c5ecbee345ea6682e2160881 from Jun 7 2018 RPi Trading guys trashed performance on all RPi 3B+ out there by downclocking the CPU cores to 1200 MHz when 70°C have been exceeded. Details in the Explanations section of https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md

  5. it would be nice if Eben got someone on the docs team to update their pages as no bcm2711 library or bcm2711 reference for that matter is found, in a search for “qspi” bcm2711 library

    only https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md#hardware
    mentions Hardware
    The BCM2835 on the Raspberry Pi has 3 SPI Controllers. Only the SPI0 controller is available on the header. Chapter 10 in the BCM2835 ARM Peripherals datasheet describes this controller.

    Master modes
    Signal name abbreviations

    SCLK – Serial CLocK
    CE – Chip Enable (often called Chip Select)
    MOSI – Master Out Slave In
    MISO – Master In Slave Out
    MOMI – Master Out Master In

    can pi4/ bcm2711 even talk the faster “qspi” modes,think quad-SPI mram uses etc

      1. oc the obvious problem there is to even tell them theres a problem,you need to actually register a github account… not going to happen for the casual user, why do you think we use cnx as our prefered point of contact.. no fuss, simply post your issue and talk about it,simples

        1. The development happens on Github, so it makes sense to post issues in the tracker over there. Not all developers will read CNX Software comment section, and it’s not the most convenient way to handle bugs.

          I’m also not sure it’s good for casual users to report bugs in Github, because as casual users they may not know what they are doing, so it’s going to add noise. Most skilled people on CNX, likely already have an account on Github.

          1. thats all true jean, but oc using the cnx no fuss way ,even Eben can come here pick a handle, talk,learn and get down to the things that bug people and so make changes at his end if he wants, and no one would be any the wiser.

            something to consider on their part at least, to get away from the yes men etc

  6. That’s all fine and dandy but the Foundation has to somehow shave another 20-30C at idle. I wish them luck in that.

  7. >Now let’s run sbc-bench again without heatsink and the new VLI firmware (version 0137a8):
    Is it true that the second test was tested without the heat sink or the new firmware?
    If so, why did the temperature drop in the second test?

    1. Quick test using iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 and iozone -e -I -a -s 1000M -r 16384k -i 0 -i 1.

      Before:

      And after:

      Well done. Sequential transfer speeds decreased by 25MB/s write and 40 MB/s read but more importantly random IO performance especially with small block sizes totally destroyed.

      I’m not testing with Raspbian Buster but Armbian Stretch on the RPi 4. But this doesn’t matter since prior tests with Raspbian Buster and the old firmware showed similar results with my storage test setup (ext4 formatted Samsung EVO840 in JMS567 enclosure with UAS active)

      1. Is it just me but if I ignore the Raspberry foundation guff, the the Pi4 is a Broadcom set top box failure and the worst fit for a Pi yet.
        I keep reading and seeing youtube reviews gushing with how this thing is amazing and it would seem the oppisite is true.
        Upton said 2020 for a reason, is this the most rushed non design Raspberry yet? The form factor is totally broken, the GPU is still bad ole VC4, the PSU is 5.1v! on usb-C.
        I have to be really critical because with the resources Raspberry have they could of been setting the new standard, it should of been a killer product.
        The product is reasonably priced but for every other expectation the Pi4 for me is a huge let down that seems completely at odds to the snake oil reviews it is getting.
        I don’t get it as in any other arena Raspberry would be absolutely slaughtered for releasing something like this, but instead seem to get huge plaudits on this supposed game changer?

        Someone explain as I am trying but, just failing to understand?

        1. The GPU is VC6, which is totally different, for one. Form factor is meant to stay the same, as is backwards compatibility with older software. The I/O bottleneck is fixed. The myriad of other improvements are self explanatory. These are at least some of the things you fail to understand.

        1. https://gist.github.com/lucabelluccini/9a11c48dcf1d627bbcbd8213f6de3eae
          Raspberry 4B – Boot from SD and rootfs on USB
          6.3. If you’re using this USB drive adapter (use lsusb):

          Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
          The disk is slow and reports errors in dmesg like the following:

          [ 543.071702] sd 0:0:0:0: [sda] tag#16 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN
          [ 543.071719] sd 0:0:0:0: [sda] tag#16 CDB: opcode=0x28 28 00 00 42 80 88 00 00 08 00
          [ 543.111634] scsi host0: uas_eh_device_reset_handler start
          [ 543.262296] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
          [ 543.297294] scsi host0: uas_eh_device_reset_handler success
          [ 573.776061] sd 0:0:0:0: [sda] tag#25 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD IN
          [ 573.776079] sd 0:0:0:0: [sda] tag#25 CDB: opcode=0x28 28 00 00 09 d4 40 00 00 08 00
          Add usb-storage.quirks=152d:0578:u (link to Github, redhat bug report).

          It must be disabled via kernel flags as it is built-in (sudo modprobe configs && zcat /proc/config.gz | grep USB_UAS).

          6.4. Remove the init script to resize the drive. It doesn’t work as the /boot and / do not belong to the same drive.

          1. > The disk is slow and reports errors in dmesg like the following

            Then don’t make the mistake and blame UAS or the UAS driver if strings containing ‘uas’ appear in dmesg output. Most probably it’s just the usual ‘USB peripherals underpowered’ shit show or some firmware mismatches.

            Transcend TS120GMTS420 SSD in JMS578 ‘enclosure’ with JMS578 firmware v173.1.0.2 and VL805 firmware 013701 (the old one) no problems whatsoever: https://pastebin.com/raw/a1riqqu1

            The net is full of stupid recommendations to disable UAS, please don’t add another one…

          2. people also seem to forget it wasnt that long ago they where debating how to optimise linux scsi as it was limiting thoughput…
            https://lwn.net/Articles/548368/
            LSFMM: Reducing SCSI latency
            …By Jonathan Corbet
            April 25, 2013
            LSFMM Summit 2013

            As was noted often during the 2013 LSFMM Summit, the speed of storage devices is increasing rapidly, with the result that the Linux storage stack is having a hard time driving those devices at their full speed. For much of that hardware, one of the more significant parts of the stack is the SCSI layer. A session led by Bart van Assche examined ways in which the SCSI code could be made to perform better with fast hardware.
            The discussion quickly honed in on the issue of the SCSI queue depth parameter, which limits the number of outstanding I/O operations. Bart complained that..

  8. I find my Pi4 gets pretty hot simply trying to stream h264 video at 1080p60 off a TVHeadend server, and I have to set VLC to render at half size otherwise the Pi can’t keep up and drops a lot of frames.

  9. what about disabling CPU cores?
    for x in /sys/devices/system/cpu/cpu[1-3]*/online; do
    echo 0 >”$x”
    done
    can decrease temperature?

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC